晴れて初開催となったEMConf JPに参加してきた。
私はEMという肩書ではないものの、一般にEMが行う役割に回ることがあるため、普段の活動に活かせればと思い参加した。
気づき、学び、新たな人とのつながりが得られ、EMConf JPの掲げるテーマ「増幅」と「触媒」を感じられる一日だった。
登壇者、運営、スポンサー、参加者、みなさまありがとうございました。
私の中で学びを「増幅」し、誰かの学びの「触媒」となることを目指して、参加記を残す。
キーノート:
レクター代表、広木さん(@hiroki_daichi)のセッション。
前半は著書の「エンジニアリング組織論への招待」から、エンジニアリングマネジメントの全体感について提示された。当日の各セッションが、エンジニアリングマネジメントのどの領域の話をしているか、マッピングできるようになった。
People Management
Project Management
Platform Management
Product Management
心に残ったのが、エンジニアリングとはFail Fastの原理をもちいて不確実と向き合うことだよね、という話。
ちょうど最近、エンジニアリングの技法やマインドセットを非エンジニアに展開していくにはどうしたらよいか考えたことがあり、そうか、根っこの部分はFail Fastなんだなと言う気付きが得られた。
後半は生成AIが盛り上がりを見せる中、エンジニアリングマネジメントがどう変わっていくかを予見するようなセッションだった。
「すべてのエンジニアはAIをメンバーにもつEMになる」、というパンチラインは納得感があった。実際社内はそうなっている、そうかこれってEMじゃんとハッとした。
とはいえ、人間をマネジメントするのと、AIエージェントをマネジメントするのは少し違う気がする。何が違うのだろう？
生成AI活用について、懇親会のときにログラスshioyanさん(@shioyang)とDevinの活用について話した時、人間とAIエージェントの違いとして、ドライに接することができるよねという話しになった。
ある人が進めているタスクを途中で巻き取るとか、出したPRを出し直してもらうとか、任せるの諦めて自分で書く、といった行為は、人間相手に行うと信頼関係を毀損する。
が、AI相手だとむしろそうしたほうが生産性が上がる。モチベーションのマネジメントが必要ない分、ドライに結果に最短距離で向かうことができる。
人向けのEMと、AI向けのEMは似ているところもありつつ、おもにPeople Managementの側面で大きな違いがありそうだ。そりゃそうだ、人間じゃないもの。
プロダクト部門のマネージャー全員でマネジメントポリシーを宣言した記録 〜後日、実践できているか？内容は妥当か？を評価できる仕掛けを添えて〜
Stanby VPoE piroさん(@piro12vortis)のセッション。
セッション資料は後日公開のため、関連ブログ。
ミドルマネジメントのポリシーを策定した話。
マネージャー間の情報共有がなされづらかったり、あまりマネージャー同士の活動に乗り気でなかったそう。
マネージャーとして育ってきた環境が違うのだから、チーム感がないのは当然。アジャイルと同じで「マネージャーのあるべき姿」という共通言語を作ることで、チームとしての力を発揮していく話だった。
マネージャー全員を巻き込んでの推進の仕方や、作ったあとの使い方(ポリシーに沿った活動の共有、新任マネージャーのオンボーディングでの利用)が参考になった。
Nstockでもまだエンジニアが3人の頃に、エンジニアリングマニフェストを作ったことがある。面接での評価にも利用していたが、最近は全くメンテナンスできておらず、オンボーディングにも利用できていない。
新しいメンバーが増え、面接に入るエンジニアも多様になりつつある中で、今こそどういうエンジニアに来てもらいたいか、共通言語を作る時期なのかもしれないと思った。
エンジニアリング価値を黒字化する、バリューベース戦略を用いた技術戦略策定の道のり
atama plus VPoE maedaさん(@kzk_maeda)のセッション。
視座上がった。
value = WTP - WTS
WTP(willing to pay)
払っても良い最大金額
e.g. 事業貢献につながる価値創出
WTS(willing to sell)
提供してもいい最低の金額
e.g. 開発・組織の運営コスト
というシンプルなモデルで、経営の言葉で技術的課題を解く必要性を説明するという試みで、非常に面白かった。
日々直面する課題の中で、どの課題は解かないと会社が潰れてしまい、どの課題は放置しても大丈夫なのか考えるうえで、非エンジニアでもわかりやすい。
Nstockでは技術的負債がいくつか上がってきている。今抱えている課題をエンジニアで整理する試みは行えていたが、それを開発チーム全体、あるいは組織に向けて開示していくうえで、よいフレームワークだと思った。
まずは現状把握している課題を、バリューベース戦略に当てはめるエクササイズをして、先送りにする課題と、そうでない課題の共通認識をつくりたい。
ちなみに、バリューベース戦略は定量化することを目指すのですかとAst the Speakerで聞いてみたところ、Noだった。あくまで定性的な判断を行う際の、概念整理として使うそう。
これは納得感がある。こうした定量化が難しい領域を無理に定量化しようとすると、労力がかかる割に、説得力も納得感もないなにか、ができあがる。定性的に確からしい判断ができるならばそれで良い。
Nstockでクラウド選定をする際に、「元AWSの私がいるんでAWSにしましょう！」と言えず、ダラダラ時間を使って各クラウドのPros/Consをまとめたことがあったのを思い出した。
1行のコードから社会課題の解決へ： EMの探究、事業・技術・組織を紡ぐ実践知
READYFOR VPoE Kumanさん(@KUMAN_R)のセッション。
今今の自分にとっては、かなり背伸びした内容のセッションだった。が、今後学んでいけると良い領域をザーッと見れた感じで、ワクワクする内容だった。Appendixは課題図書としたい。
特に関心の引いたのは、やはり生成AIのパート。
今年度から今まで採用していなかった等級のエンジニア採用をはじめようと画策していたが、生成AIエージェントの登場によって流れてしまった。
エンジニア一人あたりの生産性が上がり、コミュニケーションパスを抑えた少人数のチームが普通になっていく。
なんなら広木さんのセッションでもあったように、人間はボトルネックになり続けるだろうから、人間よりも生成AIがスケールしやすい組織を目指すのかもしれない。
高い水準のメンバーを集め、少人数で勝つというNstockの思想が実現しやすい世界になりつつある。
一定レベルまでのスペシャリティを獲得するのが生成AIにより容易になり、益々エンジニアは広範な知識を求められる。
知識の習得に必要な、自分に足りていないものを考えるメタ認知や、学習への意欲、なんでもやってみるマインドセットなどが今後求められていくんだろう。
この図を見ながら、いろんな妄想が膨らんで楽しかった。
アンカンファレンス: フラットな組織の功罪
私が書いたセッション。
セッションと言っても、資料もなにもないので、参加者の方と円を作って、対話ベースで色々話した。
Nstockが現在フラットな組織=マネージャーのいない組織を運営する仕組み、気付いた課題や、良さ、次のステップなど、参加者の方に問われるがままに話していった。
例えば
マネージャーがいない中で、給与や等級はどう決まるのか
なぜマネージャーを置く議論がでてきているのか
人と人の問題の解消できるよう、当人同士の対話の背中を押す文化を作りたい
全社に関わる意思決定を行う、委員会活動
フラットな組織で情報と熱量を伝えきるためのラジオやオフライン活動
マネージャーと言うラベルをできれば使わず、狭い語彙を使いたい
パウリさんの、HogeManagerというクラス名はアンチパターンだよね、って話がわかりやすかった
といった話をした。
自分の学びになったのは、
ログラス松岡さん(@little_hand_s)からいただいた、実は組織コーチングで解決する問題なんじゃない？という視点
自分が見えていなかったマネージャーの役割
サバイバルモード下でのトップダウンの意思決定
PIP含めたオフボーディングの判断と実施
と言った点。
平時は良いが、厳しい状況に置かれたときにこそ、マネージャー(=なんとかする人)が手腕をふるい、全員の合意を得られずとも可及的速やかに意思決定してくことが必要になる。
とはいえ、どこかでサバイバルモードが来るからマネージャーを置く、というのは早すぎる最適化にも思える。
サバイバルモード下でもトップの意思決定が伝わりやすいよう、あるいはサバイバル用のマネージャーを置いてもワークするよう、透明性と熱伝導性の高い組織でい続けることを考えるのが今は良いのかもしれない。
10分の予定が、気づいたら40分話していた。あっという間だった。
フラットな組織というテーマは引き合いのある内容なんだ、とわかったので、取りまとめてどこかで話してみたい。
サバイバルモード下でのエンジニアリングマネジメント
Kyash VPoE こにふぁーさん(@konifar)のセッション。
会社がサバイバルモード下での、生々しい体験と学びを共有する、赤裸々で貴重なセッションだった。ちょうどアンカンファレンスでサバイバルモード下でのマネージャーの役割を聞いた直後だった。
一番刺さったのは、「放置さえしなければ問題は前に進む」という話。
誰が見ても明らかに対処しなければいけなくて、対処しやすい問題は誰かしら対処する。一方で短期的には必要ないが、中長期的には必要な課題や、やるのに骨が折れる課題は放置されうる。
自分自身の考える時間軸を伸ばし、周りのメンバーの考える時間軸を伸ばすことで、「でかい課題」が放置されなくなる。
Nstockでは年4回ほどオフラインで全員が一同で会する機会がある。その機会を活かし、時間軸を引き伸ばして考える定期的な仕組みづくりをしていきたい。
ちょうど最近、それって向き直りだよねみたいな話をラジオでしたのを思い出した。時間軸を伸ばして向き直りしたい。
n=1の経験が紡ぐエンジニアリングマネジメントの可能性
NTT Com EM/PdM iwashiさん(@iwashi86)のセッション。
fukabori.fm の声そのまんまだ...！(当たり前)
2つほど心に残ったことをピックアップする。
１つ目はHIGH OUTPUT MANAGEMENT から引用の式。本で読んだときはほーんて感じだったが、改めてみると、とても良くできているなと驚いた。
組織のアウトプット
= メンバーの能力 x メンバーの熱量 - チームや組織の摩擦・制約など
いかにメンバーの能力・熱量を上げ、チームや組織の摩擦・制約を減らすか。確かに私が最近考えていることがそのまま当てはまる。
2つ目は、ポエムドリブンマネジメント。チームにアイデアを届けるのは何度もさまざまなチャネルで伝える必要がある。
思考過程を共有する目的で、さっと読める文章(ポエム)を書き、それについてコメントを貰う、という手法。
ちょうど最近、人数が増え会社のフェーズが変わり、思考過程を共有するのが大事になりつつあるよね、という話が上がっていた。
その具体的な方法としてとてもよいかもしれない。
いろんなセッションを聞く中で、「マネージャー = なんとかする人」という定義が直接的・間接的に利用されていた。実は自分はこの表現に漠然とした違和感を抱えていた。
その正体がようやくわかった。
「マネージャー=なんとかする人」ということは、裏を返せば「メンバー=なんとかしてもらう人」ということだ。
特にスタートアップでは「なんとかする人」が集まる。Nstockがそうだ。その中で、「なんとかする人」と「なんとかしてもらう人」というラベリングをしてしまうのはもったいない。
あくまで「なんとかする」領域が異なるだけで、いざとなったらみんな「なんとかする」のである。そんな自分、組織でありたいと思うから、違和感があったのだろう。