EMコンフの概要
はい、趣味でOSSをやっている者だ。引き続き、スズケンさんをゲストにお話を伺っていきたいと思います。
じゃあ、前半は、そうですね、AIコーディングの話をしていましたが、後半は、EMコンフの話をしていきますか。
僕はちょっと行かなかったんですけれども、どういうのが印象的でしたか。
そうですね、EMコンフ全体が、エンジニアリングマネジメントに関わる人に向けたカンファレンスなので、結構トピックは広くて、
基本、エンジニアの組織マネジメント、組織をどう成長させるかっていう話であったり、
あと、ものによっては本当にプロジェクトマネジメント、プロダクトマネジメントの実践の話っていう形でした。
僕は結構廊下にいて、廊下にいてってあれですけど、いろんな、久々にはマネジメントの人たちと話すっていうのをよくやってましたが、
キーノートでひろきさんが話されていたのと、あとクロージングのキーノートっていうのもあって、そっちはいわしさんが話されていたので、
その2つは聞いていて、両方ともトークとしてはすごく印象的だなと思って聞いていました。
ひろきさんのほうのトークは本当、このエンジニアリングマネジメントってつまり何なんだっけっていう定義を与えるっていうところを枠組みの紹介と、
あとやっぱり人によってエンジニアリングマネージャーって言っても結構ラベルが広いけど、やってることってこういう分類があるよねみたいな話をされたりとか、
あと結果的に何とかする人だよねみたいな、結局そこに落ち着くんかって感じですけど、そういう話をされてたりしました。
いわしさんのほうは本当、個人の体験談というか、エンジニアリングマネージメントされてた中でこういう苦労があってとか、
こういう方法を学んだからやってみたけど失敗してとか、例えばスラッグチャンネル、研修時にスラッグチャンネルパブリックにしたらみんな書き込みあって、
すごいそこに書き込みが残ると、あとの人学びになるよねって言ったら誰も書き込まなくて、プライベートにしたら盛り上がったとか、
そういう分かるみたいな、細かな失敗の話から、最終的にはなんでマネジメントをするかっていう大義を持とうって話があったんですけど、
そういうとこに向けたメッセージもあって、すごくいいトークだなと思って聞いたりしてました。
そうですよね。確かに僕もスライドは拝見しましたけれども、両方とも。そうですね、マネジメント、そうですね、EMは何とかする人ってのは本当そうで、
てかそのマネージがそういう意味だから、コントロールではなくてマネージはそういう、とにかくこう状況を何とかするっていうことなので、
なんか表現がやっぱ難しいですよね。まあ何とかするっていうのはそういう意味でやっぱしっくりくるなっていう感じがしますけど。
体験談の共有
うん、いや本当そうですね。で、トークはトークで象徴的なんですけど、僕は結構その個々の人と話す。
ブースの雑談もそうですし、あと駆け足さんがコーヒーのブース出しされていて、そこの前でなんかコーヒー飲みながら雑談ずっとしたんですけど、
そこでいろんな人が都会議会来て、こんにちはみたいな、どういうのやってんすかって聞くと、やっぱりそこにはN1のストーリーがたくさんあって、
それがすごい楽しかったですね。なんかこう、何悩んでるんですかとか、作業大変なんでとかいう話もあれば、いやーなかなか業務委託の契約の話が云々関連とかから、
本当に本当にバラバラで、でもなんかみんなこう事業成長させるためにコミットしてるっていうのは、なんかそれぞれメインの役割とかフェーズが違ったり組織フェーズ、
サイズ違ったりとか全然変わってくるんですけど、なんかそれがこう、いろんなN1があったのが一番面白かったですね。
たしかに、そうですよね。そう、え、その、駆け足さんって、あれ、その小木淳さんが入れられてました?コーヒー。
なんか、ねるドリップで。
あ、ねるドリップでした。で、なんか鎌倉のコーヒー屋さん、なんだっけあのお屋さん言っちゃったんですけど、美味しかったですよ。が、入れてくれ、くださっていた。
あ、そうなんですね。
いや、そうそう、ああいうやっぱ、そう、コーヒー出す場とかあるといいですよね。そういう立ち止まって会話が生まれるとか、そういうのが。
ああ、そうそう、そうですね。なんか、そのバリスタの方々が言ってたんですけど、なんか、駆け足さんの名前は誰も覚えてくれなくて、私たちのコーヒーの店の名前、なんか、覚えて帰ってくんですって言ってて、すみませんみたいな気持ちで。
でもすごいよかったです、なんか、場として。
でも駆け足さんいつもコーヒー出してるから、もうそこでだいぶブランディングができてる感じがするな。
あ、そうなんですね。なんか、そうそう、まさに僕、物理参加が久々だったんで、そう、あ、そういうもんなんですね。
そうですね、僕も去年ぐらいから久しぶりにカンファレンス行き出して、まあ、というのも、それこそ、今の会社で、ヘンリーっていう会社で、
そうですね、コトリンフェストとかでブースを出したりとか、そういうのをこう、去年ぐらいからリアルイベントでブース出すみたいなのを初めてやって、じゃあ私はどういう感じでやってるのかなみたいなのをこう、
眺めに行ったりとか、そういうのはするようになりました。
いいですね。そう、僕ブース、今回ブースメインでやってたわけじゃなかったんで、結構ブースの方々ともいろいろお話しして、
なんかそれはそれですごく、ブース、なんていうんですか、企画側の中を見てると、いろんなブースを見るときにすごくいろんな発見があるとかね、その辺も楽しいですよね。
そう、いや、今、なんか大変ですからね、ブース出すの。
普段ね、ソフトウェアでね、あのことばっかりやってるのに、急に出展すると物理のボード用しなきゃいけないとかね、そう、その辺がありますよ。
ボードやらテーブルクロスやら、出し物みたいなものも考えないといけないし、とか、ノベルティーどうするとか、いろいろね、
どんどん各社差別化のためにしのぎを削って頑張ってるから、結構こう、ちゃんとしたチームがないとつらいなあ、大変だなあ、みたいな、こう思いで。
そうですよね。うちも技術広報っていうチームがあって、まあ、こういうカンファレンスとか出展のところはやってるんですけど、まあ大変ですね。
やっぱり、なんかこう時期が重なるんですよね。3月忙しいとか、なかなかうまく笑けてくれないなあ、みたいなことはよく言ってますけどね。
たしかに、そういうふうにたくさん出すと、それこそ資材とかを、再利用したい資材をどうこう動かすかみたいな話とかも出てきそう。テーブルクロスとか、スタンドバナー的なやつとかを。
ブースとか出して、出すハードルが上がるのも、いろいろ考えものだなあ、みたいなのはこう思ったりはしますね。
最初なんかふざけてっていうか、ブースどうしますか、鈴木さんって言われて、まあじゃあエンジニアリングマネージャーの人たちは来るんだったら、
たぶん相談会みたいになるから、カジットのロゴ置いて相談会会場にしたらって言ったら、それは却下されました。
ブースとしての運用コストと見栄えといろんなマーケティングの狙いとの兼ね合いとか考えるとね、それただ鈴木さんが雑談して終わるやつですよね、みたいな。
なるほど。え、でも鈴木さんと雑談できるなら絶対いいと思うんですよな。
うーん、怒られるかもしれない。
幸寄る人とかも結構いる気がする。
あ、でもなんかいいですよね。結構あの大きいカンファレンスとかだとね、ブースでセッションやってるみたいなとこあったりするんで。場所によってはありかもしれないですよね。
そうですよね。ブースといえば、去年技術書店になんかうちの有志のメンバーが出展したんですけど、あれはね、もうめちゃくちゃ楽でしたね。ブースがすごく楽で。
いろんな資材とか必要なものを技術書店の運営の人が用意してくれるし、決済とか決済システムはもう技術書店さん側が用意してるものがあるので、もうそれで決済もやろうと思えばできるので、それこそ現金も用意しなくていいみたいな感じなので。
本を吸って、で、もうイベント会場に直納するようにしておけば、もう手ぶらで行ったらブースで本が売れるみたいな感じになってて、これはすごい体験がいいなっていうのを思いました。
マネジメントの課題
すごい良いですね。出展コストを下げる仕組みですね、それはかなり。すごい、ちゃんとそういう、なんていうか、ちゃんと一般の同人活動をしてる人たちの、やっぱそういうコストを下げるっていうのをかなり気にされてるんだなって思って、良いものだなって思いました。
いやー、そうですね。いわしさんの、いわせさんのやつはかなり生々しい話で、やっぱこういう生々しい話いいですよね。
いいですよね。やっぱりなんかこの具体があると理解が変わるし、あと何だろうな。そう、いわしさん僕も久々にお会いして、深掘りで、あー、アジトFもやってるんですねみたいな感じで、お互い声はしてたけど初めましてでしたねみたいなのが結構前にあって、そこから久々にお会いしたんで、なんかそう、いわしさん最近何やらやってるんですかみたいな話の中で、そう、まさにこのスライドの話聞いて、
あー、みたいな。いやそう、なんか結構ゴリゴリに、その、エンジニアしてた時代からやっぱりマネジメンティングってわかんないことたくさんあるし、みたいな。そこでこう、なんか悩んできた、やっぱりこう、悩んできたこと、ミスったこととか、ワンオンで、こう、どんなに教えたらいいかみたいな、めちゃくちゃ本読んで、こうやってみるとか、あ、わかるわかるみたいな話がすごいあったんで、そう、やっぱいいですよね。
そう、やっぱさっき話してたような、その、こう、透明性みたいな、その、そう、なんか、こう、パブリックチャンネル発言しづらい問題みたいなのはすごくあるから、そう、どういうふうにそういうふうに、こう、発言しやすいようにしていくかみたいな話は、こう、あるなーっていう、こう、のはあるし、やっぱそういうパブリックチャンネルのマネジメントみたいなの、こう、難しい、
いやー、難しいです。僕もこれはもう本当に前直面して、特に経営統合の時がそうで、カルタの、なんか、親父グループっていう単位から変わった時に、一気に知らない人が同じスラックにドーンって増えた時の、パブリックチャンネルのドキドキ感って、これすごいあって、けど、やっぱりエンジニアとか、まあウェブに慣れてるメンバーは、まあウェブ上になんか書く、みたいな感じでしょ、みたいな感じでバンバン書くんですよね。
けどやっぱりその文化の、なんていうんですか、バックグラウンドがない人たちって、パブリックチャンネルってすごい、なんか、ウェブのオープンのとこに書くぐらい怖いことっていうか、うん。で、あとまあもちろんマネージャーも見てるし、とかも含めて。だからそこは最初すごい、なんでパブリックのとこに書かないんだろうって僕もずっと思ってて、けど、あの、一周して、ああ、なるほど、なるほどって、いや、あの、やっぱり話を聞いていくとわかるように、最初わかんなかったですね。
いやもうめちゃくちゃわかります。なんかあと、やっぱりパブリックチャンネルであっても、やっぱそのコンテキストがあるから、より発言が難しいみたいなのもあったりするから、まあそういう空気を読んで発言しなきゃみたいなのがあると、やっぱ難しいですよね、人が多いと。
なんか僕も、なんかやっぱり、そのパブリックチャンネルであっても、こう発言しづらいなーって思うときはあるし、むしろなんかツイッターに雑に書いたほうが、ノーコンテキストで適当なこと言えるから楽だなっていうぐらい思っちゃうこともある。
そもそもなんかこう、ねえ、Xツイッター上ですごい自由に書いているから、すごいいつも見て楽しさ、今日も、そもそもさん、またバズりそうななんかツイートとか思った気がありますよ。
まあでもちゃんと、そうですよね、発言しやすい環境とか、まあ発言していいんだっていうふうに思ってもらうみたいなのがないと、やっぱ発言する人が偏っちゃって、嘘、なんか良くないっていうのはありますね。逆に収束、変な形で偏っちゃうっていうのはありますよね。
あーそうですね、そうですね。まあオフィスと一緒ですけど、やっぱり場作りっていうか、そこは意識して設計してるかアイドライン作ったりとかやってましたね。
まあやっぱり和やかな雰囲気を作るとか、そういうのもある。誰かがそれをやるみたいなのがあって、なんかこう、そう、今の会社だとその技術的な雑談とかもうちょっとしたいなみたいに思うことがあって、そのチャットとかでも。
で、こう、社内に、のすらっくにバイクシェットっていうチャンネルがあるんですよ。てかまあ僕が作ったんですけど、こう、まあ自転車置き場の議論のバイクシェットですけど、でもなんかそんな盛り上がってなくて、かつなんか割とやっぱ新しく入ったエンジニアにとっては、こう、話題を投げ込むのにハードルが高いみたいな話もあるみたいで、
あ、そうなのかーと思って、結構まあミスったなーって思う部分もあって、まあつまり結構誰かが話題を投げ込んだ時に、結構ちゃんとそこに対して反応するとか返事をするとか、なんかそういうのはやっぱ、もっと僕もやんないとダメだったなーとか、なんかそういう、こう、いうのをなんか反省をしました。
いやそうそう、なんか社内スラックだし気軽に書こうって言って書いた結果、雑談して、いやこれはみんな面白いんじゃないかって思ったけど、反応がない時の寂しさみたいなのありますよね。
うん、そういうのありますよね。なんかコミュニティチャットとかコミュニティスラックとか、もう盛り上がってるチャットとかって、なんかこう、自ずとちゃんと反応するような人がいて、なんかそういう人がいるから結構盛り上がってるワイワイしているみたいなのがあったりしますよね。
いやー、そうっすね。これなんで結構あれかも、スラックだと、なんかリアクションめっちゃつけてますね。いろんなところに。書けなくてもなんか目のワークつけたりとか、いいねーとか、ハートつけたりとか、結構そういうことよくやってますね。
エンジニアリングマネジメントの複雑さ
いや、リアクションつけるのはすごい大事、大事ですね。はい。カルタ社って、PMって何人ぐらいいるんですか。数え切れない気がしますが。
実はなんか明確にエンジニアリングマネージャーっていう、実は職務はないんですよ。なんで、なんだろうな、組織によってそれを本部長って呼んだり、部長って呼んだり、リーダーって呼んだり、エンジニアリングマネージャーとも言うか、みたいな人も言ったりはするんですけど、なんか明確にEMのスペシャリストみたいな人っていないかったりするんですよ。
なんか結果、その事業の、事業会社のCTOっていうのもいて、っていう人たちが結局マネージメントのまとめをしたりとかっていうようなことなんか多かったりします。ただ、いわゆるエンジニアリングマネージメント的行いっていうのは当然組織内でなされてまして、なんでこう、結構ですね、機能を作ってると。
で、カルタだと、例えば評価とか採用みたいなところは前者でやってるんですよ。なんでこう、同じグレード制度っていうのがあって、そこは横の基準でやってますし、あと技術力評価会みたいな、その半年に1回他の事業のエンジニアからレビューしてもらうっていう会を作ってるんですけど、それ自体はどの事業かどうかに関わらず横串でやってるんですね。
なので評価採用のところはそういうふうに横軸。ただ、普段のメンバーの目標設定とかやったことの振り返りとか、ワンオンワンみたいなことは現場のそれぞれの事業でやっているので、その中でエンジニアリングマネージメントの要素が回ってってるっていう、ちょっと複合的な構成になってる感じですね。
じゃあそこのチームマネージメントの方法はもう、それこそそのチームだったり事業会社ごとに任せてるっていう感じなんですかね。
そうですそうです。ただ一定の型というか、マネージャー向けの研修とかもあるので、ワンオンワンはこういうふうの考え方でやろうなとか、フレームワークこういうのがあるよみたいなインプットとかをしたりとか、あとエンジニアリングの中でどういうことをそもそも考えてやっていこうねみたいなのはテックビジョンっていう共通のビジョン、バリューを作ってるんで、
そこで例えば本質的にちゃんと考えて作ろうねとか、あと多席指向じゃなくて次席というか、他人選しないでやっぱり自分でどうやってできるか考えてみましょうみたいなこととか、その辺はこう共通して伝えて、あとはそれぞれのチームちょっとマイナーチェンジしながらやるみたいなふうにしてますね。
なるほどね。そのマネージャー向けの研修っていうふうにおっしゃってましたけど、そこで言うマネージャーってどういう定義で決められてるんですか。東急ではないですよね。
東急とは別ですね。それは本当組織のマネージメントっていういわゆるロールがあって、これはエンジニアに限らずなんですけど、なんでエンジニアもだし、いろんなセールスとかオペレーションの人たちとかいろんな職種の人がいるんで、その人たちに対してマネージャーって人たちには同じ研修をやってるんですよ。
それはこの組織、そもそもローム管理って何みたいな話もしますし、あと目標管理って何とかどうやってモニタリングするのとか、そういうちょっとジェネリックな、あとモチベーションに対してどう向けるかとかそういうところをちょっとメタなテーマっていうか、これは人事のチームが主催しちゃってるんですけど、そういうところは横串でやってますね。
なるほど。じゃあそこでマネージャーっていうのは結構そのピープルマネージメントみたいなところをやる人っていうようなイメージですかね。
ですね。公式な組織図上のマネージャーはピープルマネージメントっていう感じですね。ただなんかプロダクトマネージャーみたいな人とか、いわゆるPMの人たちっていうのは直のマネージメントラインじゃないケースもあったりするんで、そのほうが全然多いですけど。
っていう風にしてますね。
なるほど。なるほどね。いや、ピープルマネージメントってローム管理とか大事だからな。
そうなんですよ。結局大事。僕もそんなものは堅苦しいしいらんやろみたいな感じで最初やってたらあるタイミングでやっぱダメだなと思って、結局ちゃんとやるっていうのが大事だということ。
それがあって初めて型を崩しにいけるっていうか、型を知らないままエンジニアのマネージメントはこうみたいな感じでやると、
なんかお前の言ってるマネージメントはマネージメントじゃないよっていう話になっちゃうなと思って。そこはなんか共通言語やっぱりマネージャー陣があったほうがやっぱりいいなと思いますね。
まあそうですね。僕も結構マネージャーとかそういう人を見るポジションについてから結構会社の就業規則とかしっかり読むようになったりとか、そういうこう休みの取ってもらうときにどうすればいいのかとか、
そういうこう全然こう、なんか自分一人のことだったらなあなあにしてよかったことをちゃんと調べるようにこうなりましたね。有給がいつどのタイミングで。
そういう。 そうそうそう。大事ですよ。ちゃんとインプットすると、うちだとHRVPっていうHRのビジネスパートナーって人たちがいるんですけど、彼らともすごく話が通じやすくなるっていうか、
なんでこうこういうシチュエーションなんですってこういう状態なんですっていうのを共通の言葉で横で連携できるようになるんで、やっぱりその辺も含めてすごくなんかインプットのクオリティを上げていくっていうのはなんか有効だなあとはやってて思いますね。
いやもうそれは絶対そうですよね。お互いの状況を理解して、じゃあどういうふうにまあいい感じの落とし所を作りますかっていうのをやらないと、絶対そのお互いが安全側に倒し始めて、めちゃくちゃこう堅苦しい仕組みなりルールができちゃうみたいなのがあるから、
なんかこうしたいんですけどなんとかなりませんかみたいなそういうところを腹を割って話せるようになるといいですよね。
そうですね。まああんな感じかな。なんすかね、なんかEM全体に関してはでも課題化もやっぱりありまして、なんかEMっていうかエンジニアリングマネジメント全体、結局そのなんていうんですかね、だいたい僕もそうだったんですけど、やっぱりなんかマネージャーやってって言われたらマネジメントの勉強めっちゃして、組織論とかすごいインプットして、なんかワンワンの話とかすごいやるんですけど、結果なんか事業成果出ないと結局意味ないみたいな世界じゃないですか。
なんかこう再現性上げようぜとか言ってるけど、いや再現性の前にさ、今この番の成果出してって言ってるのにみたいなことになりやすくて、だから僕結局どうなるかっていうと自分でやるってなってプレイングマネジメント化して、で結局メンバーの面倒はあまり見れないみたいな、だいたい僕は最初のマネージャーとそういう感じだったんで、すごいそういう感覚があって、
だから、いや難しいですよね、なんかEMのオンボーディング、EMっていうかマネージメントのオンボーディングって本当に難しいから、なるべく初めてマネージメントやる人は2人目マネージャーとか3人目マネージャーみたいな感じで、一人でしないっていうのは結構よくやってるんですけど、なんかそういうのは試行錯誤中って感じですね。
そうですよね。難しい、ほんと難しいですよね。本当に今お話してたことがそうだと思ってて、やっぱり基本的には価値創造とか価値を提供してるところに対して、もしくはそこに期待していただいてるから、何らかの形で会社にお金がやってきて、
価値創造とマネジメント
そこで報酬が僕たちに得られるっていう形になっているので、まずちゃんと事業価値が出せてるかどうかっていうところが、まず主眼に置かれないといけないなっていうのは僕もすごく思ってるところなんですよね。
そういう事業価値みたいなのが先で、その後のマネジメント論とか、そういうところは後だと思っているし、むしろそう思ったほうがいいと思ってる理由がいくつかあって、やっぱり自分たちのチームで正しいことやってるみたいなのを思いすぎると、内集団バイアスみたいなのがたくさんあって、
要はカルト化するみたいな、自分たちは正しいことをやってるのに世の中は認めてくれないみたいな、そういう、身内は守るけど外とは喧嘩してもいいみたいな、ともすればそういうカルト的な考え方に陥りがちだと思っているっていうのと、
あと、僕らエンジニアなんで、エンジニアってオーバーエンジニアリング好きだから、すごい組織、自分の行動でやってる分には別にいいと思うんですけど、趣味の行動とかそういうのは、組織作りとかそういうところにおいて、そういうオーバーエンジニアリング、ビルドトラップみたいなことをやるの、めちゃくちゃ罪深いなっていうふうに思っているので、
やっぱそこにどうしても傾倒したくなっちゃう重力が働くから、そこにいかに冷静にドライになれるかみたいなところがかなりあるよなって思ったりしていますね。
いやー、あるあるですね。やっぱりエンジニアからマネージャーやると、おー、そうかそうか、ここにこういう構造があってなみたいな、ここにこういう作業があって、分かってきたぞみたいな、分解すればいいんやみたいな、そういう気持ちになってくるんですけど、いきなりそれをやるとね、大体こう、よくないことが起きるっていうのはすごくいます。
やっぱその働きやすさとか、チームの心理的安全性みたいなのは、とにかくめちゃくちゃ大事ではあるんだけど、そういうのを、やっぱりコードと同じですよね。整えすぎてるのが本当に大事なのかどうかっていうところはかなり自問しながらやっていかないと、そういったところをちゃんとやる、
こう、なんか、なんだろうな、こう、正当性みたいなのをあんまり主張しすぎないほうが良いなあ、まあだからその辺ちゃんとバランスってあれですけど、そういう、なんかでも自分たちとしてちゃんとこう価値が出すためにやってるんだよねっていうのにしないと、こう、すごくこう、なんか、よくない、よくないよなってな。
わかりますね。
こう、自解する部分ではありますね。
なんか結構感覚的になんですけど、こう、マネージャーをやるタイミング、メンバーもそうなんですけど、なんか、心理的安全性のテーマとかまさにそうで、問題を見つけやすいんですよね。なんか、あ、私言いづらいと思ってるとか、なんかその主観的な感じで見て、課題にアプローチしちゃうみたいなところがあって、いや、なんか確かに多分改善できるんですけど、でもそれに今チームの例えば、それを学んだり実践することにすごく役立ちますよね。
本当にすごく時間を使ってしまうんだったら、多分それはあなたが説く課題としてベストじゃないよねみたいな。なんか、課題のベストオーナーとまでは言わないけど、なんかこう、それはなんかもともと、もっとこう、もしかしたら、まあ経営の根本の話かもしれないし、なんかそのエダ派でやろうとしてもすごくインパクトが小っちゃいことをやろうとしてるかもしれないとか、なんかそこは結構客観的に何に取り組むかを決めないと、
なんか長い目で見るとやっぱり、自分もなんか昔やったことを振り返って、これはちょっと当時は自分ですごく必要だと思ってやったけど、なんか自分が今の立場だったらそれは今第一プライベートに挙げなかったなみたいなこととかをやっぱりやってたんで、なんかそれはすごく思います。
そう、なんかそれこそ同僚に感謝されるようなことをするのって、まあすごい良いことなんですけど、なんかそういうのってすごい距離が近い人だし、すぐにフィードバックが返ってくることだから、そういうのをやっちゃいがちみたいなのがあると思うんですけど、でもなんかそうじゃなくて、やっぱちゃんとお客様に感謝されることをしないとダメですよねっていうのが、
あるっていうか、そういうふうに思わないと、やっぱどうしてもそういう人の問題とか、なんかそういう人間関係もそうだけど、そういう問題ってどうしたって絶対出てくるものだから、でもだからこそちゃんと自分たちはそのお客様に喜んでもらうためとか、世の中への価値提供のためにやってるんだっていうところを、やっぱりこう自分として強く思っておくとか、そういうのをちゃんとチームにも言い続けるみたいなことをしないと、
いけないよなっていうのは思ってるところですね。
ゴール設定の重要性
いや、ほんとそうっすね。
なんか結構そういう、こう一番大事なゴール設定みたいなところが、なんかむしろしっかりしてたら、なんかあとはみんなが勝手に考えてくれるみたいな状況に結構なると思っていて、
それもチームづくりの雰囲気づくりの問題だと思うんですけど、でもなんかそういうこうゴール設定とか、それのメッセージングみたいなところを、なんかうまくいってないのに、すごくこう、どうマネジメントするかみたいなところを言っても、なんかその、まあうまくいかんよなっていう、なんかそういう気持ちがあります。
いや、ほんとそうっすね。そう思います。
まあ、見えやすい数字とか実績はやっぱり、ハックしたくなっちゃうから、意思を持って、そうじゃないよっていうことの方が結構、マネジメントの仕事としては重要な場面が多い気がしますね。
そうですね、ハックされちゃったらこう、なんかよくないというか、まあなんかやっぱ一番上段には、一番上には結構訂正的な目標みたいなのを掲げた方がいいなっていうのは僕は思っていて、で、その上での定量目標みたいなのがあるので、そこをハックされたら、なんかその訂正目標的なもので、ちゃんと帰却するっていうか、
なんかそれって別にその訂正目標のためになってないよね、みたいな、そういうこう、なんか、こう、そういうのがあるよなっていうのはこう、思ったりします。
売上増えてもそれやるの?みたいなのとかね、なんかこう、いろんな場面で。まあ価値基準はやっぱり決めとくっていうのは王道だと思いますね。
そう、なんかこれはありますね。なんかそう、最近、そう、ツイート、僕ツイートしてたんですけど、最近ちょっと息子と結構サッカーをやっていて、まあドリブの練習とかを、
ってかまあ練習っていうか、まあドリブルしたりしてるんですけど、なんかドリブルちゃんとこう、早くするためには、こう、タイムを測ったりした方がいいのかなとか、なんかそんなことをこう、思い始めて、まあやんないんですけど、別に。
で、なんか昔僕ちょっとサッカーやってたから、なんかそれでドリブル競争とかそういう練習とかたまにするときあるんですけど、なんかそういうときに、なんかこう、なんかすごいボールをポーンって蹴って、すごいダッシュするやつとかいたなーっていうふうに、
なんか思い出して、なんかそれってなんていうか、すごいハックじゃないですか。つまりその、早くドリブルしてるようにこう、見せかけるために、まあボールをとにかくこう、10メートルぐらい蹴って、それに追いつくみたいなことをして、ドリブル早かったですっていうふうに、
いうやつとかがいたなーみたいなのを思い出して、そう、でもそれってなんかドリブルになってないですよねっていう、なんかその、っていうのをどういうふうに伝えるかっていうのが難しいなっていうか、そういうハックに対してどう向かうかっていうときに、ドリブルの定義みたいなことをするのは絶対良くないなって思ったんですよ。だからドリブルはつまり、みたいな、こう、ボールは何メートル以内のみたいな、なんかこう、
それってその、あなたはこう、相手を抜きたいとか、ちゃんとこう、からドリブルしてるんですよねとか、試合に勝ちたいからドリブル早くなりたいんですよねっていう、だからこれはドリブルになってないですよねっていう、それだけでいいと思うんですよ。なんかその、そこにその、ドリブルを言語化するみたいなことをするのはやっぱ意味がないなっていう、そう、そういう、でもなんかそこですごい頑張って言語化しちゃおうとするような人が結構、
世の中には多いな。し、なんかそれはやっぱ、なんか相手のペースにやられちゃってるなんじゃないかな、みたいな、なんかそういうのをふと思ったんですよね。なんかすいません、なんか急に。
いやー、ほんとでもそうっすよね。結果指向で言うとね、ドリブルで相手抜ければいいとかね。
そう、そう、時にはそういうロングボール蹴ってバーって走り込んでもいいわけじゃないですか。だからなんか逆に、ドリブルは3メートル以内しかボールを前に出しちゃいけませんみたいなことをやると、なんか、その肩の中にはまったドリブルしかできなくなって、余計良くないから、みたいなね。
いやー、そうっすよね。いやー、だからこれもうね、定義したり測ったりとかね、やりたくなるわけですけどね。
あんま溜まればね、まあ持続的にはそれがあったか再現性はあるんでしょうけど、まあ確かに。
それはだからそう、測ったりしてもいいと思うんですけど、なんかその時に、あなたこれドリブルになってないですよねっていう話をちゃんとできればいいし、でも向こうは逆に、いやこれは僕としてはドリブルになってるつもりだっていう、まあそういうたぶん擦り合わせをするみたいなのが結構大事なので、そこでなんか変にこう、まあそこで本当にお互い合わなかったら、まあさよならするしかないみたいなこともあると思うんですけど、
やっぱそういう、なんかそこで変にこう、変な定義付けをすることで他の人も縛っちゃうと良くないよなって思いますね。
おだしょー うんうんうん。そう、そんな感じかな。なんか結構ゴール設定がやっぱ大事だなって思うんですよね。だからOKRとかも、KRの話をする前にちゃんとオブジェクティブがいかにちゃんと訂正的で野心的であるかみたいな、
なんかワクワクするオブジェクティブがあれば、割とみんなで、じゃあこういうKRを定めてトライしてみようってなると思うし、そう、スクラムとかもね、なんかその、こう、うまくいかない理由としてはやっぱりプロダクトバックログのメンテナンスが難しすぎるっていうのがあると思ってて、
なんかそこが、スクラムガイドとかでもさらっとしか書かれてないけど、そこがとにかくめちゃくちゃ急所だと思ってて、そこがうまくいけば、うまくなされてれば、なんか別、スクラムうまく回ると思うんだけど、うまくいかないなっていうのは思ったりしてます。
価値提供のためのチームづくり
し、なんか、まあ、めちゃくちゃ理想的にいってる現場を見たこともないし、僕もうまくできたと思ったこともあるわけじゃないけど、まあ難しいなって思う。
なんか回し方?まあ、スクラムとか置き合いとかもあれですけど、なんか、大体、まあ社内でかな、まあいろんなチームと話してると、結局ゴールが見えないパターンってお客さんの話しか聞けてないんですよね。なんか、本当にそれ言ってた?とか、なんか本当にそんなニズあった?みたいなとこに対して答えられる人がそこに誰もいないみたいな。
それは大体失敗するんですよね。だから、なんかもう開発が始まる前からこけてるっていうか、だから、そういうケースってもうどんな方法を使っても救いようがなくて、だからもうゴール決めれないっていう。で、ゴール決めてるけど、形式上、それゴールになってないみたいな。だから、もうそういうチームから相談もらった時に、どうしようかなってありますよね。
だから、まあ評価の面とかでも、まあ結局これみんな向かってるとこ間違ってたら、結局みんな失敗してることになっちゃうから、早めに救いたいけど、だからそれに早めに気づけるようにしたいなーはいつも思っていて。でも、開発だけ見てるとやっぱ分かんないですよね。なんか、やっぱりなんか全部の事業ドメインっていうのはある程度、本当にこのゴールに向かって正しそうだってことの、なんか当てどころがないとそれを指摘できないんで、そこはねすごいなんか難しいなーと思っていつも。
見てますね。
その、スクラムとかOKRとかってやってます?
いや、もうね、言ってないです。スクラムでやりますみたいなことも絶対言わないようにし。バックログでチケット管理もするし、ゴール設定もするんですけど、スクラムですって言うと、スクラムをみんなやろうとするから、一番うまくいってるチームはスクラムですって言ってないチームがうまくいく。もう、長らく言ってないですね。スクラムをやりましょうみたいなことは。
なるほどなー。そうだよなー。
これはなんか言葉があると、そのようにはめようとしちゃうっていうのが多分あって、でも本当は方法じゃなくて、価値提供に、さっき園さん言った通りな、価値提供を一番やりたいのに、価値提供の話がどんどん減っていって、方法の話がどんどん増えていってっていうのが失敗パターンだと思ってて、いつもっていうか、多くの聞いてると。
なるべくそういう、いい方の場合はいいんですけど、OKRもOKRって言わないで、本当目標設定ねって言っちゃってるケースが多くて、それは真のOKRの考え方すると弱いんですけど、でも、そういう風にしてるケースの方が多い気がします。
いや、そうなんだよな。そう、わかります。結局、そうなんだよな。結局、言葉ができるとハウにこだわりすぎる人が増えてくるっていうか、どうしてもハウにとらわれてしまうみたいなのはすごくやっぱりあるなっていうのは思っていて、けっこうEMとかもそういう節があるよなっていうのはちょっと感じるところではあるんですよね。
そうなんです。だから、たぶん本当にお客さんの方向いてとか課題に向き合ってやってる人ほどそういう言葉が邪魔になるっていうことがたぶんあって、でも一方そういう言葉がないと、外の世界で起きてることを共通の知識にしたりとか、同じフレームで話して、ああ、この場面はそうだよねって話もしづらくなったりとか、それが起きることもわかるというか、なんですね。
なるほど。そうですね。だから、フレームワークですからね。スクラムもOKRも。だから、それをどれぐらい運用するか、とらわれずにやるかみたいな。
そうですね。理想はマネジメントとか仕組み作ってる人は勉強して知ってるんだけど、なんか自分の言葉でそれを、その言葉を使わずに話せるっていう方が理想的かなと思ってますね。やっぱりでもある程度、いろんなやり方のインプットがあると、
バイアス、さっきの認知バイアスの話もそうですけど、一人おがりとか、このチームだけに本当にサイロ化したやり方とかっていうものじゃなく、ちゃんと振り返れたりしますし、それはすごいことだと思ってるんで、それをいいとこ取りしたいって感じですかね。
スクラムとOKRの重要性
それはわかりますね。スクラムとかOKR、共通言語としては、わりと便利なんじゃないかなっていうのは僕は思っていて。ただ、そうですよね。でも、なんかそれが悪いんじゃなくて、うまく使えない人が多いのが問題だし、そもそもうまく使いきれないものだっていうふうに思ってます。
思わないといけないなーっていうのはこう思ってます。僕としては、わりとスクラムとかOKRっていう言葉に乗っかった方が説明が楽な部分もあるから、使っても良いんじゃないかなっていうふうに思ってはいるんですけど、
なんか、やっぱりオレオレのやり方みたいなのが乱立しても良くないとは思っているんで。
そうなんですよ、本当に。まあ、それもそうなんですよね。本当にそこにいるチームメンバー全員がOKRを本当に理解して、OKRのものをみんなで読んで、同じ熱量でやっぱり取り組んでる場所ってことなんですけど、それを1000人規模とかでやらせると、絶対ムラが出て、お前の言ってるOKRがOKRじゃないみたいな話とか、もうすごい。
そうそう、そういうね、自転車置き場の議論がね、たくさん出てきちゃうっていう、難しいよな。
結構やっぱスクラムもOKRも、なんかやっぱ魂が込められてるかどうかがやっぱ大事だと思うので、むしろ魂が込められていれば、別に候補論は多少アラがあっても、なんか上手く回ると思ってるんですよね。
でも、魂がこもってないのに、こう、方法論の話ばっかするから、大体上手くいかないみたいなのがあるよなっていうのはこう思ってる。
そういう魂が、スクラムの場合は明示的なプロダクトゴールだったり、多分明確で優先付けされたプロダクトバックログアイテム、透明性見えるか理解されるようにするみたいなのが、スクラムガイドに書いてあるんですけど、
なんかそういうのだったり、まあOKRだと、やっぱちゃんと訂正的で野心的なオブジェクティブみたいなところが、みんながちゃんと達成したいっていうワクワクするオブジェクティブがないと、なんかみんな、こう、なんかそう、
うまくいかないですが、結局そこが一番難しいんですよね。なんかそういう方法論のよりかは。言葉で言うのは簡単だがみたいな。はい、だいぶマネージャー的な話ですが。
言葉的にいろんな、そうですね、マネージャーの話するとたくさん出てきますよね、ネタがね。
最後にちょっとなんかそうさっき、たぶんなんか鈴木恵さんが言及されようとしてたかもしれない、僕の今日の、昨日のかな、ツイートの話をしようかなと思うんですけど、なんかこう、バックエンドタイプスクリプト最近話題になりがちだなっていうふうにこう思っているんですが、
今、僕が勤めてるヘンリーっていう会社は、コトリンがバックエンドなんですけど、まあ一部ノード使ってるとこもあったりなかったりみたいな感じなんですけど、こう、カルタだと技術スタックどういう感じなんですか?バラバラな感じはする?
バラバラです。うちは授業によって10選定任せてる。一方で結構収束っていうか、ある程度まとまってきてるなーって感じはありまして、JVM系で固めてるとこは基本JVM系の言語、コトリン、サーバーサイトコトリンですからっていうのはあります。
そうじゃないとこはやっぱりGoとタイプスクリプトが多いですね。タイプスクリプトで全部、表も裏も固めてるっていうプロダクトもありますが、まだまだやっぱりそこは少なくて、サーバーサイトはやっぱり新しいのってやっぱりGoは相変わらず多いかな、増えてますね。
で、やっぱり昔からのWeb授業で続いてるとこはPHPが引き続きすごく多くて、PHPもだんだん、PHPはどんどん進化してて、ほんと静的型言語化していって、もう何だろうな、昔の僕が見たらこれは邪魔なんじゃないかって多分もう10年以上前で僕が見たらっていう感じになってるから、そういうふうになっていってますかね、今だと。
おだしょー なるほど、そうですよね。バックエンド言語何がいいのかみたいな話ってずっとしてる感じがしますよね。それこそ、僕が業界入った頃、2010年前後とかは、まだパールが比較的強いけど若干社用になってきてて、Rubyとか多分PHPがかなり使われてて、みたいな時代だったと思うんですけど、
その後Goが出てきてとか、スカラが結構盛り上がってとか、なかなかこの辺のところは用途もあるっていうのもあるけど収束しないよなっていうのはこう思ってるところですね。PHPはもう邪魔みたいな見た目になったし、コードの。
あともう完全にもうこれは逸られない感じだなっていうのは最近感じています。普通にそのPHPコミュニティも盛り上がってるし、PHPすごい好きな人も多いし、PHPで問題解決してる人たちも多いから、これはなかなか定着した、Javaと同じように定着した感じだなっていうふうには見えてますね。
いや本当そうと思いますね。他なんだかんだPHPもキャリアの中で一番長く触ってたので、やっぱりPHPストームっていうかJetBrains系のIDでさ、PHP触る感じって本当になんだろう、本当最初にPHP触った人が全然違ってっていう体験をしてからは、まあなんていうかちゃんと堅牢にかけるし、何ていうのかな、まあ確かにGoとかと比べると標準ライブラリが大きすぎて、正直多分僕も多分2割とか1割しか知らないんですけど、標準ライブラリが機能。
でもそれでも本当に実用的なものをどんどん作れるし、例外の使い方とか全体のHPリクエストを定くところの構成とか、やっぱり一回理解しちゃえばある程度使っていけるんで、そこはなんか結構仲良くなってるなという感じは働く感としてはありますね。
そう。なんか僕のツイートが、最近サーバーサイトタイプスクリプトをやる理由がよくわかんないみたいなこと言う人が結構いるので、え、そうなの?みたいな気持ちになって、なんかTS以外で静的片付け言語でバックエンドを書こうと思うと、Go、Java、Kotlinsからラスト、Cシャープあたりが候補だと思うけど、
なんか別にどれも一丁一単だから、TSと比べてこれがいいみたいなの特にないよなーみたいに思ってて。なのでTSは今、現代だとすごく有力な選択肢だなって僕は思っているので、なんかそのあたり、鈴木恵さんとしてはどう思われます?
いやー僕はもうこの辺の言語選定の先端に立ってるっていう感覚は全くないんですが、でもTSは有力な選択肢ってのはそうだろうなーと思ってます。なんかTSの、どうなんだろう、本当に最新の型の扱いっていうところについて、なんかもう正直僕もキャッチアップできないところがたくさんあって、
なのでGoの一点何とか系を使っている感覚で、まぁこんな感じでそのままでいけるんでしょっていうものから、どんどんいい機能が増えて、あ、なんだこういう書き方もできるんだっていうものを、なんかそこが今TSどうなってるのか正直あんまりわかんないですよね。
ただまぁフロントエンドからとバックエンドでやっぱり言語を合わせるっていうことのメリットは結構その感じ始めてまして、去年もあのうちの学生向けのインターシップを全部フロントとバックのタイプスクリプトでやったんですけど、やっぱなんかすごいキャッチアップがスムーズだったんですよね。
短期間っていうのもあるんですけど3週間しかないんでけど、やっぱ揃えるとその言語以外の問題に集中できるっていうのは、なんかその時にすごい感じて、なんでそれはなんか良かったなーという記憶があるんですよね。
たしかにそれはありますね。僕とか鈴木恵さんとかだったらバックエンド書くときパッとやるなら語を使いそうだけど、普通にチームでやるなら結構TSでやりたいってチームが言ってきたら、じゃあそれでええかみたいな僕はなる気がします。
ファンの場合なんかネットSATPで何をすればいいかって言われたら、まあだいたいこうでしょってすぐわかるけど、それは語に慣れてるからだけっていう感じがします。
TS、まあそうですね、処理系もいろいろ出てきて、あとTSっていうかJSのすごいところは、V8がなぜか異常に早いので、その他の静的片付け言語と遜色ないパフォーマンスが出る謎の処理系なので、他の動的片付けの言語ってなんだかんだでその10倍ぐらいのオーダーでパフォーマンスの差が出ると思ってるけど、
V8が異常に早いからJSは処理系が早いっていう謎の凄さがありますよね。
いやもうそれはもう資本の力でしかないというか、使われれば使われるほど早くなるっていう、ありますよね。
そうですよね。まあ普通にそういうブラウザとか作られる中とかでも、エンジンの中でもやっぱりパフォーマンス劣化にすごい厳しい開発をしてるっぽいから、そういうのはありますよね。
いやそうですよね。ノードはもう何年ぐらい経つんだろう。2010年ぐらいでしたっけね。もうちょっと前だったかな。2008年ぐらいだったかな。
まあなんか気づけばもうそんな経つっていうはずだから。いやノードは本当、世界をこう、概念、JSの世界を広げたものすごい功労者ですよね。
そうですよね。なんかもうちょっとそれこそ当時はバックエンドもJSで素早く埋め尽くされるのかなっていう感じはしてたんですけど、なかなか定着しなかったなみたいなところはあったりとか。
エコシステムとか、あとやっぱアシンクアウェイトが出てくるまで、やっぱりなんかコールバック減るみたいになるのが辛いからみたいなところで、やっぱ書くのが結構辛かったみたいなのがあると思うんですけど、やっぱアシンクアウェイトが出てきて、本当全然そういう普通の、普通のっていうか割と手続きっぽくて、順序立てて書くみたいなのもやりやすくなったから、
だいぶそれで取っ付きやすくなったなっていうのもあるのかなっていうのは思ってるし、あと炎が出てきて、バックエンドのフレームワークが、エクスプレスがやっぱなんだかんだで強かったところから、結構そういういい感じのサーバーフレームワークが出てきたっていうのもかなり、やっぱ今、比喩力になってきてる原動力かなっていうのを僕は思ってます。
本当ですよね。炎すごいですよね。なんか市民権をすごい得てるなと思って。
なので、普通にTS、それこそフロントの人とかTS書ける人がバックエンド何で書くかって言ったら、サクッと炎とかTSでやっちゃえばいいよなっていうのは思ってる次第です。
最新の技術動向
狙い通りたくさんみんないいねしてくれてるんで、たぶん今日考えてるわ。
まあまあでも別に僕のツイートはこんなもんです。200いいねぐらいなんで。そういうあんまり。運用とかがどうなのかなっていうとこはちょっと気になるとこですけどね。まあでもコンテナに閉じ込めちゃえば別にみたいなところも最近あるからなっていうのはちょっと思ったりしています。
そこはそうですね。
今なんか気になってる言語とか技術とかないですか。それこそPythonでいろいろ、むしろそういうところをやってるっていう感じだと思うんですけど。
そうですね。最近は言語自体というよりは本当にLLM系のエコシステムとかそれにまつわる周辺ツールとかっていうところをよく見てるんで。
開発こと開発って感じで言うとさっき言ったクラインとかカーソルとかもそうですけど、大きくやっぱりソフトウェアのパイプラインの中にデータとそれを扱うAIがパイプラインになっていって、それが自然とソフトウェアエンジニングの集団の1個に馴染んでいくっていうのを今過程として見てるんで、それ全般がすごく楽しいっていう感覚を持ってますね。
今までロジック1個モデル作るとめんどくさいなと思ったところが1つ簡単なフィルターできるようになったりとかっていうのが結構起きてたりするんで、そういう結構置き換えであったりとか機能性をLLMが置き換えていくっていうのはすごく今興味を持って見てますね。
パイソンは確かにそれはすごいやりやすいんですけど、他の言語でもそうですけどね。
なるほど。そうか。なんかその辺の取り組みの話とか、やってることみたいなのをどっかで話を聞きたいっていうような。
そうですね。なんか事例とかテクトークみたいなのがどっかで出せるといいですね。いろんなチームがトライしてるんで。
パイソン そうですよね。やっぱりそういうCTOみたいな人がそういったところをちゃんと別途して取り組んでるみたいなところとか、あと事業体としていろいろ事業を抱えてる会社だと思うので、いろいろそういうふうにねじ込めるっていうか、ちょっと実践の場みたいなものもあるような環境で、そういうラボ的なことをやられてるっていうのはすごい面白そうだなっていうのを思いました。
パイソン 嬉しいです。
それこそ松本さんとかがね、レイアXの松本さんとかがね、最近そういうのをやっぱりいろいろトライして発信とかもされてるから、鈴木園さんもそういう発信をいろいろしてくれると嬉しいなっていうのを思いました。
パイソン はい。わかりました。ちょっと最近あんまりかけてないから、ちょっと今年はもうちょっと頑張ろうかなと思ってます。
じゃあそんな感じかな。話したい話は話せた感じなので終わろうと思います。
ということで、趣味でOSSをやっているものだ、鈴木園さんをゲストにお迎えしていろいろお話しました。ありがとうございました。
パイソン ありがとうございました。
