こんにちは、スタメンでエンジニアリングマネージャーをしているasashin（@asashin227）です。
近頃は暖かくなり、もうすっかり春の気候ですね。 最近、桜の盆栽を手に入れて、視覚的にも春を感じられるようになりました。
EMConfに参加してから1ヶ月ほど経過しましたが、日々の業務の中でもEMConfでの学びを振り返る事があり、自分の考えとして定着したものや腹落ちしたものなどありましたので、改めて登壇された方のスライドを見ながら振り返っていこうと思います。
EMConf2025は2025/02/27に開催されました。（実は当日は誕生日でした）
参加レポートとしては、@hisaが執筆した非EMがEMConf JP 2025に参加して学んだこと 〜エンジニア視点で見るEMの役割と未来〜をご覧ください。
EMの役割
一般的にはEMの役割として以下の項目を挙げられることが多いです。
- プロダクトマネジメント
- プロジェクトマネジメント
- テクノロジーマネジメント
- ピープルマネジメント
これは、EMConfでキーノートを務められた広木大地さんが執筆したエンジニアリングマネージャー/プロダクトマネージャーのための知識体系と読書ガイドによって広く知られるようになりました。
今回、広木さん自らこれをアップデートし、テクノロジーマネジメントからプラットフォームマネジメントとなりました。
- プロダクトマネジメント
- プロジェクトマネジメント
- プラットフォームマネジメント
- ピープルマネジメント
プラットフォームマネジメントという考え方
これまでの役割として提示されていたテクノロジーマネジメントとしては、技術負債のコントロールや、技術戦略、アーキテクチャ選定、モニタリングなど、エンジニアリングに対して直接的に関与するようなことが多かったように考えていますが、プラットフォームマネジメントという表現では、エンジニアリングはメンバーに任せつつ一歩引いたマネジメントを行う表現になったように感じています。
直接的に技術的負債を解消するための働きかけも必要ですが、技術的負債を生み出さないためのデリバリーフローの構築や、ツールの整備などを主戦場とすることと、これらが必要なタイミングでチームに提供できるように、定点観測したり、早期に失敗できる（Fail fast）できるように準備しておくことが必要となります。
また、スタメンではプラットフォーム部が存在し、プロダクト部全体に対して開発者体験の向上を行っていますが、EMの役割としても管掌組織に対しての、開発者体験と生産性の向上を担っていくとことが、プラットフォームマネジメントと捉えました。
開発者体験の向上のためのツールの導入支援やCI/CDの構築などが具体的な方法論としてはありますが、これらを戦略的に導入しつつ、メンバーにかかるコストを中長期で低下させるための技術基盤を構築、維持し続けることが、プラットフォームマネジメントと言えるのではないでしょうか。
現在の私の管掌チームでは、CI/CDの整備などのデリバリーフローの効率化を行えていますが、技術的負債のマネジメントまで踏み込むことができていないため、今後の課題となってきそうです。
エンジニアリングの価値をどう考えるか
開発生産性を語る上で、どのように経営指標と接続していくのか、例えば機能がどれほど売り上げに貢献したのかや、DXによってコスト削減し、利益率を上げるなどありますが、エンジニアリング価値を黒字化する、バリューベース戦略を用いた技術戦略策定の道のり(by Kazuki Maeda)の中でも損益計算書（P/L）のように捉えて開発組織内で黒字化させるという手法について、以前から頭の中にはあったのですが、視覚化されることで改めて、気づきがありました。
経営との接続を考えるとどうしても金額的なものに置き換えて語りたくなってしまうのですが、そうではなく価値提供速度を挙げていた点が、腹落ちしました。 価値のボリュームを計ろうとするとどうしても利益率や売り上げに紐付いてきてしまい、変数が多くエンジニアリングの貢献度合いが曖昧になってしまうため、この観点は非常に良いものだと感じました。 開発や運用コストを抑えつつ、早く早く価値を届けることがエンジニアリングの価値として定義してみるという試みがありそうと考えています。
サバイバルフェーズの心得
ここでの文脈でのサバイバルフェーズとはKPIの未達成や事業計画のビハインド、収益構造の悪化など事業面の事象やメンバーの疲弊と離職という状態を指しており、過去の似たような状況に遭遇したため思い出しながらセッションを聴いていました。 足元の数値改善は当然として、根本的なコスト構造改善のための方針を打ち出されていたとお話を聞くだけでかなりハードな状況だった事が伺えました。 その中でも大変参考になったのが、考える時間軸を伸ばすというお話でした。 目の前の課題に取り組み続けることのみに注力するとメンバーやマネージャー自身の目線が下がり、すべての施策が後手に回ってしまうという事が経験上ありました。
やるべきタスクが消化されず目先のわかりやすい問題に目がいってしまい、本質的な課題解決ができない状態となってしまいます。 こにふぁーさんの発表では１年半先に向けて組織とプロダクトの目線を合わせることでその中で必要な役割にチャレンジしてもらったり、重要度の高いが緊急性の低い問題に取り組む事ができるようになったと紹介されていました。 また、少し先のチャレンジングな目標が共有されることでメンバーの熱量が大きくなり、自らチャレンジしてくれるメンバーもいたとのことでした。
直近のプロジェクトが半年以内に終了するサイズ感のものが多く、１年以上先の話をメンバーとする機会が少なくなっているので（現状サバイバルモードというほどでもないですが、）私自身もっとメンバーと未来の話をせねばと思いました。
これからのエンジニアリングマネジメント
キーノートの広木さん、岩瀬さんがお二人とも触れていたことでもありますが、昨今のAIの成長によってエンジニアリングマネジメントはEMだけが行うものではなくなっていくと感じました。 スタメン社内でもAIを用いた開発が徐々に浸透し始め、私自身も、ClaudeやGithub Copilotを活用しながら開発を行なっています。
チームの一部メンバーはDevin.aiを使い始めており、人間が指示して、AIが実装するということが現実になっています。
コミュニケーションしている様はまさに先輩エンジニアと後輩エンジニアのオンボーディグのように見えます。
このように、意図せずとも、AIに対しての教育やタスクの分解、指示だし、進捗管理など、マネジメントの要素は徐々にエンジニアメンバーの業務にも染み出してきています。
広木さんのキーノートにも記されている通りすべてのエンジニアは、AIをメンバーに持つエンジニアリングマネージャーになる。 ということが現実的にすでに起こっていると考えています
EMでなくともEMっぽいことが求められるという未来がそう遠くない中で、我々、現在のEMはメンバーに対して、EMっぽいことをできるようになろうということを伝えていかなければなりません。
プロジェクトマネジメントやAI教育と指示出しのための言語化能力は必ず必須スキルになっていきますし、簡単な実装はAIに置き換わっていくため、より高度な技術を身につけなければなりません。
最後に
テック系のカンファレンスに参加することはありますが、マネジメント系のカンファレンスは（現地参加としては）初めてだったため、他の参加者の方との交流ができたことが、最も良かったと感じる部分でした。
特に、スタメンでは専任のEMが私一人ということもあり、同じ立場だからこその悩みや具体的な取り組みの事例などのお話を聞くことができて、楽しい1日となりました。
スタメンでは、プロダクト開発に関わる全ての領域でプロダクト職種の採用をしています。 もしご興味を持っていただけたら、下記からご応募ください！ herp.careers
