02/27に開催されたEMConf JP 2025に行ってきました。
夢のような時間でした。
少し時間が空いてしまいましたが、この記事では印象に残ったセッションを中心に感想を書いていきます。
- エンジニアリングマネージャーのロードマップ
- エンジニアリング価値を黒字化する、バリューベース戦略を用いた技術戦略策定の道のり
- Two Blades, One Journey: Engineering While Managing
- サバイバルモード下でのエンジニアリングマネジメント
- イベントをふりかえって
- わたしの「増幅」
エンジニアリングマネージャーのロードマップ
圧巻でした。
フェイルファストの原理を軸にEMの職責を4つのPに集約させ、主要な方法論を整理。それに続いて生成AIを前提としたエンジニアリングの未来。
「エンジニアリング組織論への招待」から7年（！）、広木さんの主張が全くブレていないのがよく分かります。
プログラム化しえない意思決定がどんどん小さくなっていく
最近ハーバート・サイモンの「プログラム化しうる・しえない意思決定」を知り、近しいものを感じました。
コンピュータが経営上の意思決定を代行する考え方は昔から、それこそ職場に入り始めた時代からあったようです。
その後ソフトウェア開発が簡単になり続けたことでコンピュータの担える、すなわち「プログラム化しうる意思決定」の範囲はどんどん広がっていった。ついには生成AIなんてものまで出てきた。
経営において「プログラム化しえない意思決定」として最後に残る領域は、おそらく目標を決めることです。会社が何をゴールとするかは、おそらくアートの領域なのでしょう。
一方で、決められた目標の達成は定式化が可能です。これまたサイモン（とニューウェル）によると、目標達成（問題解決）とは、目標とのギャップを問題として認識し、解決可能な粒度まで分割してそれを解くというプロセスとのこと1。
「4つのP」は問題解決の過程
問題を認識して、分割して、それを解く。これってまさしくエンジニアリング組織の仕事ですよね。
目標が小さい場合はすでにAIに任せればおしまいですが、大きい場合だとまだまだ人間の出る幕がありそうです。
ここで広木さんの発表を思い返すと、
- ピープル/プラットフォームマネジメントによって心理的安全性を確保し、問題が小さいうちに発見する
- プロジェクトマネジメントによってリスクを管理し、問題を解決しやすい粒度に分割する
- プロダクトマネジメントによって顧客価値を検証し、目標とのギャップ、すなわち問題を認識する
というように「4つのP」はいずれも目標を設定し、問題を認識し、分割する過程に寄与することがわかります。
そして分割された問題を解くのがエンジニア、もしくはAIなわけです。
両者が解決できる問題の大きさはだいぶ近づいているわけですから、区別しない組織が最適解になるのですね。
発表前半と後半のつながり
「プログラム化しえない意思決定」が小さくなっていく中でも、目標を達成する過程はまだ人間の仕事。
目標達成は、目標設定・問題認識・問題分割によって行える。
EMの4つのPは上記に寄与するもの。
分割した後の問題は人間かAIに解いてもらえばよい。
人間とAIが解決できる問題の大きさはだいぶ近づいている。
問題解決のために両者を区別する必要は小さいのだから、組織とアーキテクチャを統一しよう。
話を聴いているときは前半と後半のつながりにピンと来なかったのですが、よくよく考えてみると全くそんなことはなかったですね。
サイモンとニューウェルが行った問題解決の定式化を縦軸にすることで、両者が繋がりました。
エンジニアリング価値を黒字化する、バリューベース戦略を用いた技術戦略策定の道のり
エンジニアリング価値を黒字化する バリューベース戦略を用いた 技術戦略策定の道のり - Speaker Deck
EMをやるにあたって「経営とエンジニアリングの接続」は永遠のテーマだと思っています。
開発とビジネスのディスコミュニケーションを解決したい。そのためには共通言語を作ってプロトコルを整備するのがよい。ただ、それが分かっていても簡単には行かず、EMが間に入って「通訳」するケースが多いように思います。
この発表では「価値」を共通言語に、「バリューベース戦略」をプロトコルにする方法が語られていました。発想はシンプルながら理にかなっています。しかも拠り所にできる"原典"もある。スマートさに舌を巻きました。
また、トップダウンで決めるだけでなくボトムアップに戦略を考えているのもすごい。知恵を集めることで隙を減らした上で、メンバーの視座まで上げる一挙両得のアプローチです。
「マネージャーは翻訳業」2と言われることがありますが、最高峰の事例を見ました。
実行のためのリソースをどうやって獲得したかはぜひ聴いてみたいです。リソース獲得は翻訳家というより外交官ですね。
Two Blades, One Journey: Engineering While Managing
Two Blades, One Journey: Engineering While Managing - Speaker Deck
よくRubyコミュニティでお会いしている@ohbarye さんの発表でした。
ICとEM、両立の難しさ
ICとしての腕が下がっている気がする。というか仕事でコードを書いていない上にプライベートでも本ばかり読んでいるので、間違いなく下がっています。それが普通。もともと高くはないけど。
かといって、仕事でマネジメントに向き合っているのだからプライベートでコードを書けばよいかと言われれば、そうでもない。
ICと比べるとEMの仕事はハイコンテキストです。そのためポータブルスキルを身につけづらい。経験則から帰納的にスキルを身につけていこうとしても、コンテキスト依存で潰しが効きづらい。ですから理論を覚えて実践し、演繹的にスキルを身につける方向性になる。
そこでプライベートの時間が読書に奪われ、コードに向き合う時間は減ります。マネジメントの仕事に向き合うほど腕は落ちていくジレンマがあるわけです。
だからこそ、両立は本当に難しい。
「螺旋」
そういう意味で、個人的なこのトークでのポイントは「螺旋」の話でした。
ICとEMの両方を交互に経験することで、相互補完的にスキルが築かれていく。期間で区切ることで両方を取りに行くアプローチがあるとは考えもしていませんでした。
また、生活に大きな影響を出さないためにはICとEMで市場価値の差を抑える必要があるので、現実解としても優れた方法だと思いました。
自分の場合はEMにスキルセットを寄せすぎていて、ICとして同じくらいのお金を要求できる自信はないなあ。
EMだけが使える知の高速道路
自分の現状を打破するために「EMになったことで技術力が上がった」話がヒントになるだろうと思って、Ask The Speakerで詳しく聴いてみました。
すると「メンバーが調べて実装してくれたことを、知の高速道路として活用するとよい」とのこと。
なるほど、確かにメンバーが調べた情報は自分のもとに上がってきています。
そのおかげで知識の幅は広がっているのですが「自分の技術」にできている感触がなかった。大事なのはここに一手間足して手を動かすことかも知れません。
「思考の整理学」で盛り上がった話
ところで、EMConfで一番嬉しかったのはこのブログの記事を参考文献に入れていただいていたことです。
これまたAsk The Speakerで、「思考の整理学」の話で盛り上がりました。
「メンバーが調べて実装してくれたこと」を形式知に変えて社外ブランディングに活用するアイデアを思いつきで言ったら「それエディターシップですね」と返してくださった下り、あれがあの一日のハイライトでした。
「エディターシップ」の章では原稿の順列が語られていて正直ピンと来てなかったのですが、あれは編集者の立場でのみ知り得ることがある美味しさを語っていたのですね。
プレゼンターとしての大場さん
そういえば、プレゼンターとしてのパフォーマンスも素晴らしかったです。
要所要所で視線をスライドに集めるためのパフォーマンス、構造化され視覚化されたアジェンダ、かなり詰め込んでいるのに情報がどの順に重要かがわかるスライドデザイン、内容を大胆に飛ばすタイムキープ。
スライドデザインは昨年夏のデブサミで大いに参考にさせてもらったのですが、他も見習うべき点が多いなあ。
最近、プレゼンの本を読んでるんですよね。
サバイバルモード下でのエンジニアリングマネジメント
サバイバルモード下でのエンジニアリングマネジメント - Speaker Deck
これはもう……胃が痛くなる発表でした。
経験知を5つに集約させたシンプルな構造で、感情に訴えかけるパートはそこまでなかったにも関わらずです。
この発表を聞いたEMに他人事として捉えた人はいなかったと思います。
黄金の精神
あえて感想を一言でまとめるならば「こにふぁーさんから『黄金の精神』を感じた」です。
事態がどんなに悪くても、覚悟を決めて一歩一歩打開へと進んでいく生き様が眩しかった。
ジョジョからの引用はネタとして擦られすぎててふざけて見えちゃうのですけど、真面目にそう思いました。
事態を改善するのは結果だけではなく過程の積み重ねなのですよね。積み重ねの後に道が開ける。第5部で語られたテーマです。
「越境」の難しさ
内容にもう少し立ち入ると「越境」に関する話が刺さりました。
「開発がどう実行するか」に視野を絞りすぎず、必要な情報は自分で取りに行く。
発表中では「サバイバルモード下では」というエクスキューズがついていましたが、確かにこれは悩むことが多くて。
むやみに越境するのは人の仕事へのリスペクトを欠いた行為なので簡単にはできない。下手を打てば余計な恨みを買う。しかも、放置したとしても自分の責任にはなりにくいので、基本的には利益を得ることが少ない行為です。
しかし、組織の結果に責任を持つのがマネージャーなわけです。自分が悪くなくても事態を改善する責任は取らなくてはいけない。だったら対処は早い方が良い。
実際、だいぶ火が大きくなってから自分のところにお鉢が回ってきたことがあり、ものすごく共感できるパートでした。
イベントをふりかえって
イベント全体の感想を一言でいうと「n=1の経験知の価値を見直した」です。
正直なところ、これまでの自分はn=1の価値を低く見積もりすぎていました。しかし、EMConfで考えが変わった。
やっぱり自分の言葉で熱く語っているトークは聞き応えと説得力があります。結局、誰かの経験談が人を動かすのですよね。
n=1を過小評価していた背景
n=1を低く見ていたのには背景があって、EMコミュニティではピープルマネジメントの話題が語られがちなんです。
実際、会期中にX(Twitter)上でこんなやり取りがありました。
わかるー
— expa / Shu Oogawara (@expajp) 2025年2月27日
他3つのPはソフトウェアエンジニアの知見として確立されてるけどピープルはそうでないから出てきやすいのかな
経営学や認知心理学で研究されてるから、もっとアカデミックな話題を増やしたいと思ってる #emconf_jp #emconf_jp_a https://t.co/DeNeLJ9PMK
ピープルマネジメントは大事なんですが、この話題はハイコンテキストかつお気持ち談義になりがちです。悪ければ、コミュニティが「傷の舐め合い」となってしまうのではないかと感じていました。
自分が認知科学や経営学からアカデミックな知識を引いてきて、EMコミュニティで発信しているのはこのあたりに理由があります。
これだけなら良かったのですが、そこに「n=1の過小評価」が混ざってしまった。反省です。
n=1が「増幅」を生む
ナラティブな情報を過大評価してしまうのは確かに危険です。
しかし、それで皆が学び現場での実践が行われるならば、n=1だろうが大きな意味があるものだと考え直しました。
誰かの語りを聴いて自分も実践してみる。それが「増幅」であり、EMConfという場所はその「触媒」となるよう設計されていたのだと思います。少なくとも僕はそう解釈しました。
改めて、素晴らしいイベントでした。スタッフ・スピーカー・スポンサーの皆さん、そして他の参加者の皆さんも、ありがとうございました。
わたしの「増幅」
上記の通り「もっと幅広く読書しようぜ」とEMコミュニティに投げかけるのは変わらずやっていくと思います（今やれてるかどうかは知らない）。
マネジメント、すなわち経営学はコンピュータよりもよほど歴史が長い。皆が一番困っている「人間」の性質だってアカデミアでは様々な報告が行われている。ここから情報を取らないのはもったいないです。
一方でn=1の価値を見直した結果、これらを自分の実践に変えて発信する活動が足りないことに気が付きました。
読書を続けながら現場に適用して、どうにか発信を続けていけるようにしたいと思います。
重ねてになりますが、本当に素晴らしいイベントでした。
出したプロポーザルが3本とも落ちたのは残念ですが、トークを聴いていてなんとなく落選理由はわかったかな。来年はどうにか通せるようにしたい。
ここまでいって落ちたらめっちゃダサいですけどね。まあそれはそれ。
引き続きよろしくお願いします。それでは。
