エンジニアリングマネージャーのロードマップ

エンジニアリングマネジメントの4次元と生成AI時代の戦い方

株式会社レクター 代表取締役 広木大地

自己紹介

広木 大地

株式会社レクター代表取締役

1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに入社 アーキテクトとして、技術戦略から組織構築などに携わる 同社メディア開発部長、開発部部長、サービス本部長執行役員を務めた後、2015年退社 現在は、株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている。 一般社団法人日本CTO協会理事、朝日新聞社社外CTO。

エンジニアリングマネージャーとはなんなのか。

目次

1
EMの誕生と進化
2
EMの本質と4つのP
3
生成AI時代のエンジニアリング組織

「エンジニアの管理職」の時代

  • かつては「課長/部長/リーダー」とだけ呼ばれていた。
  • 「とりあえずマネージャやってね」の時代
  • マネジメント職になりたがらない技術者たち。
    • 技術の現場から離れるとおいて行かれるのではないかという恐怖。
    • 役割定義があいまい。各社で異なる状況。
    • ポータブルスキルが身につかないのではないかという懸念。

エンジニアリングマネージャーの登場

  • 2018年頃から「エンジニアリングマネージャー(EM)」という肩書きが普及
    • 人材育成・技術戦略・プロジェクト管理・プロダクト連携の専門職
    • ジョブディスクリプションや求められる知識・スキルも次第に明確に。


✅ エンジニア"リング"マネージャ

❌ エンジニアのマネージャ

EMコミュニティの活性化

  • 2018年頃より活発化
    • EM Meetup(毎回多くのEMが参加)
    • EM.FM(累計再生数10万回超)
    • Engineering Manager Advent Calendar(年間100記事以上)
  • 大規模カンファレンス(EOF2019)
    • 700名以上が参加するムーブメントに
    • 「EMあるある」で盛り上がる文化も

バズワード化への懸念と重要性

「EMって結局なんなの?」問題

  • EMという役割が「一時の流行語」で終わらないために
    • 「ただのバズワード」という批判も
  • 多角的なスキルと継続的に企業を支える専門職としての意義
  • 日本企業のビジネス環境変化に伴う必要性
    • ソフトウェアを中核とする経営の加速
    • 人材育成・組織設計・技術マネジメントの重要性

バズワードで終わらないためには、
エンジニアリングマネジメントの
知識体系が整備されることが重要。

エンジニアリングの過程を捉える

「曖昧」から始まり「具体」で終わる。

エンジニアリングは「実現する」ための試行錯誤

  • 不確実性が前提

    • タスクの積み重ねではなく、わからないことのリスクが本丸。
    • 具体化&明確化の意思決定が重要
  • 不確実性との戦い

    • 人間関係:チームの関係性やコミュニケーション
    • プロジェクト:進捗やリスク、スケジュール
    • 技術:負債の蓄積やアーキテクチャの選択
    • マーケット:顧客価値や市場の仮説検証

エンジニアリングの本質

不確実性との対決

  • 蓋を開けてみないと解らない。
  • その蓋を開く勇気。
  • 小さな実験の積み重ね
  • 小さく、そして早く失敗して成功する。

フェイルファストの原理

スタートアップでよく使われたフェイルファストという言葉。
「失敗しても良いから、とりあえずやってみよう」という意味に矮小化して捉えられがち。
このフェイルファストはテクノロジー企業のマントラになって、ソフトウェア産業の文化を創り上げてきた。モダンなソフトウェアプロダクト開発においては、「早く失敗する」つまり
「リスクに早期に曝露する」 という原理に基づいて様々な技術や文化、そして組織のあり方が作られている。その結果、強力で強靱、高いレジリエンスのプロダクト開発を実現している。

フェイルファストの原理

  • リスクを早期に曝露するには、課題を言い合える関係と学び合える文化が必要
  • リスクを早期に曝露するには、短いタイミングで動くものを確認した方が良い。
  • 品質改善するには、シフトレフトによって早期にエラーが発見される方が良い。
  • リスクを早期に曝露するには、顧客や市場に早めに見てもらう方が良い。

エンジニアリングマネジメントは、この原理によって駆動されている。

エンジニアリングマネジメントの「4つのP」

People Management

不確実性に向き合うマインドセットをつくる

Platform Management

早期に失敗できる技術的土台をつくる

Project Management

リスクに向き合い真の進捗をつくる

Product Management

プロダクト仮説検証サイクルをつくる

4つのP > People Management

ピープルマネジメント

People Management

4つのP > People Management

ピープルマネジメント

  • 人の成長が不確実性を減らす
  • 人の思考の中にバグが潜んでいる。
  • 人の思考をリファクタリングして、成功に導く
4つのP > People Management

心理的安全性と1on1の重要性

  • 心理的安全性の確保

    • チームが対人リスクを取っても問題ないという信念の共有
    • 人が不安を隠さず相談できる文化を作るほど,潜在的なリスクや課題が早期発見される。
  • 1on1の重要性

    • 1対1で細かな悩みを吸い上げる場を設けることで,個人が抱える疑問やリスクをチーム全体で解決できる。
    • 機嫌取りではない問題解決を促す場
4つのP > People Management

不確実性に向き合うこと

仕事でついつい後回しにしてしまう事こそ取り組む

4つのP > People Management

人は、不確実性に出くわすと「逃避」「攻撃」を選ぶ

だから、本能を乗り越えるための思考力と関係性をつくる。

4つのP > People Management

チームビルディングとチーム設計

  • キャリア支援はチームの長期安定化

    • メンバーのキャリアと成長を支援すれば,離職リスクや個人の成長不足リスクが下がる。
    • 思考する力、言語化する力
  • 権限委譲で自主性を醸成

    • リーダーが全部を決めると,チームの学習機会を奪い,プロジェクト後半で大きな不安を招く。
4つのP > People Management

メンタリングと文化形成

  • メンタリングとコーチング

    • 不透明な状況に陥っているメンバーを導く「対話のスキル」。
    • ラポールの構築:傾聴、承認、自己開示
    • 課題の再設定:可視化、明晰化、リフレーミング
    • ゴール設定:ゴール認識とセルフマスタリー
  • "失敗を共有"するカルチャー

    • 失敗を個人の責任にせず,学習の糧に変えられれば,未知のリスクがどんどん開示される。
    • 学び続ける文化をつくる。
4つのP > Project Management

プロジェクトマネジメント

Project Management

4つのP > Project Management

プロジェクトと不確実性コーン

4つのP > Project Management

プロジェクトマネジメントの本質

タスクを管理するのではなく、リスクを管理する。

4つのP > Project Management

プロジェクトの終了確率は対数正規分布

たし算の世界は正規分布、かけ算の世界は対数正規分布に。

4つのP > Project Management

プロジェクトマネジメント

リスク要素を小さくして「たし算の世界」に閉じ込める

4つのP > Project Management

ソフトウェアの嘘の進捗

プロジェクトの進捗は、ソフトウェアの不可視性によって隠される

4つのP > Project Management

アジャイルソフトウェア宣言

隠せない真の進捗に定期的な曝露をもたらす。

4つのP > Project Management

プロジェクトマネジメント

  • タスクではなくリスクを中心に捉える。
  • 小さくスコープを保ち、足し算の世界に閉じ込める。
  • 嘘の進捗に惑わされないように動くソフトウェアに価値を置く。
  • 認識の不一致がないように早く「見せる」=リスクへの曝露
  • 真の進捗にフォーカスを与える。
4つのP > Platform Management

プラットフォームマネジメント

Platform Management

4つのP > Platform Management

プラットフォームマネジメント

プラットフォームマネジメントとは、ソフトウェアを効率的に開発、発展させるためにその基礎となる土台を管理して、開発者体験を向上させることです。

技術的負債を管理し、アーキテクチャ設計を更新し、ソフトウェアシステムの不確実性を早期に検出し、問題発生時には速やかに「失敗(fail)」させる仕組みを取り入れた、堅牢な技術基盤の構築を継続的に行う営みです。

4つのP > Platform Management

プラットフォームマネジメントのキーワード

  • 品質のシフトレフト、CI/CD、静的解析、SAST/IAST
  • 技術的負債のマネジメント
  • フィーチャートグルや依存性の注入
  • カナリアリリースやブルーグリーンデプロイメント
  • オブザーバビリティ(可観測性)
  • フォルトインジェクション/カオスエンジニアリング(失敗の注入)
  • アーキテクチャのオプション的価値
4つのP > Platform Management

品質のシフトレフトは30倍以上の効率

早期発見を生み出すメカニズムが必要

4つのP > Platform Management

フロー効率を高める技術的投資

継続的デリバリーを前提に自動化や効率化を徹底的に進めることで品質と価値効率を最大化する

4つのP > Platform Management

失敗できる環境を技術的に作る

≒コード修正の心理的安全性が開発者体験を作る

4つのP > Platform Management

技術的負債を問題化する非対称性

ソフトウェアの課題が見えるものと見えないもの

4つのP > Platform Management

プラットフォームマネジメント

技術的負債とアーキテクチャは対の存在

4つのP > Platform Management

技術的負債は見えてしまえば、管理できる。

  • 非機能要件の可視化
  • 静的解析、コード分析環境の構築
  • アーキテクチャテストの整備
  • ADRの管理
  • ユビキタス言語の管理とドメインモデルの抽出
4つのP > Platform Management

プロダクトマネジメント

Product management

4つのP > Platform Management

プロダクトマネジメント

プロジェクトマネジメントとの違い

  • プロジェクトはHOW
    • それが終わることが大事
  • プロダクトはWHAT
    • それが終わらないことが大事
4つのP > Platform Management

プロダクトマネジメント

終わらせないために仮説検証サイクルを管理する

  • 大きく成長するために仮説検証を管理する
  • 短期的な売上や機能ではなく、顧客価値によるグロースサイクルの構築を目指す
  • 探索と活用のジレンマを乗り越える。
4つのP > Platform Management

仮説思考とは何か。

仮説と検証にわかれるのではなく、
大胆な仮説が検証行動をドライブする思考法。

4つのP > Platform Management

仮説検証のエビデンスモデル

より精度の高い証拠を得るために「介入」実験する。

4つのP > Platform Management

プロダクトマネジメントとグロースサイクル

  • プロダクトが自走的に成長させるサイクルのこと。
    • プロダクトマネジメントでは、グロースサイクルを健全に回るように構築していく必要があります。
    • 「機能をつくることではなくて、プロダクトの自律的な成長サイクルをつくること」がプロダクトマネジメントの本質。
  • 弾み車が回り始めれば、資源が継続的に透過でき、マーケットフィットの限界までオーガニックに成長していける。
4つのP > Platform Management

グロースサイクルの種類

顧客体験のサイクル

🟨 そのサービスを使えば使うほど、(便利になって、より)使いたくなる。

認知拡大のサイクル

🟨 知られるほどに、(使われて口コミがひろがるので) 多くの人に知られる。

データ活用のサイクル

🟪 データが溜まるほどに、(使われるほどに、レコメンドの精度が上がり使われるので、) データが溜まるようになる。

収益のサイクル

収益を得られるほど、(広告や機能に投資できて) 収益を得られるようになる。

4つのP > Platform Management

探索と活用のジレンマ

より大きな果実をもとめて冒険するか、確実な利益を得るか。

探索 (Exploration)

  • 新規顧客の探索
  • 新機能や新市場の仮説検証
  • 大きな不確実性
  • 大きな利益

活用 (Exploitation)

  • 既存顧客の拡大
  • 利用しやすさや不具合の解消
  • 小さな不確実性
  • 小さな利益

4つのP > Platform Management

プロダクトマネジメント

  • プロダクトを終わらせないために行うこと
  • 顧客価値を作り、それがさらなる価値を生むサイクルを作ること
  • それを実現するために実験をして、証拠をつみあげていくこと
  • 価値を探すこととと、見つけた価値を伸ばすことの優先順位を見極めること。

4つのPは、全部できないとダメなんですか?

スーパーマンである必要ない。

マネジメントの元の意味は「なんとかする」こと。

エンジニアリングマネジメント

「価値を実現する」ために「なんとかする」こと。

  • 自分ひとりがすべてを「できる」必要は無い。
  • 必要なものを理解して、「調達」してくる必要がある。
  • そのために「できる」必要はないが「わかる」必要がある。

生成AIの登場で、
エンジニアリングマネージャはどう変わるんだろうか

賢者は歴史に学ぶ。

ソフトウェアは常に簡単に成り続けている。

同時にソフトウェアの複雑性も増え続けている。

それに従い、社会の適応領域も拡大し続けている。

自動プログラミングとして言及されてきた技法は、
つまるところ高水準プログラミング言語を
使ったプログラミングの婉曲的表現である。

(デイビッド・パーナス)

人の価値は高くなり、半導体は安くなり続けている

より少ない労働力で、多くのことをコンピュータに任せる必要

組織の一部の労働は、半導体に置き換りつつある

これは生成AI以前からのマクロトレンド

目的と手段の梯子、不確実性の低いものから置換

人が関わるのは運営から成長と変革に変わる。

組織が求められるものが変わっていく

均質なチームから多様なチームが当たり前に

組織が求められるものが変わっていく

近年のワークスタイルシフトはソフトウェアによって起きた。

私の最近の開発体制

メンバーが生産的になるようにひたすら課題の整理と意思決定

終わったら声かけて

  • AI Agentの設定としてsayコマンドを使う例
  • いろいろ頼んでおいて、終わったら声かけてもらう。

メンバーが提案し、マネージャが決める。

課題を整理し、意思決定し、環境を整える。

AIが提案し、人間が決める

課題を整理し、意思決定し、環境を整える。

すべてのエンジニアは、AIをメンバーに持つ
エンジニアリングマネージャになる。

ソフトウェアの偶有的複雑性と本質的複雑性

本質的複雑性に対する"試行錯誤"がエンジニアリング

なぜ、エンジニアリング組織論への 「招待」なのか。

2018年のビジネス書大賞受賞インタビュー

僕はこの本を『エンジニアリング組織論への招待』っていうタイトルにして「招待」を加えたのも、この先の話を考えていくべき時期だと思っていたんです。

今まで「エンジニア」からしてみると、指示を出す対象は「コンピュータ」です。.. 仮に、この「指示を出す対象」は、「コンピュータ」か「人間」かを問わないで、「部下の数」なんだとすると、AWSなどのクラウドを使ってしまえば、一瞬でとんでもない数の「部下の数」を用意することができる。

今のコンピュータは、かなり細かい指示を出さないと動いてくれないけれども、徐々にそこの指示出しが曖昧でも、抽象性が高いようなものでも、簡単に動いてくれるようになる。

「コンピュータ」か「人間」かという区別をしない組織への招待ー広木大地さんブクログ大賞受賞記念インタビュー前編

「人間」をたくさん雇用してビジネスをスケールしていくという考え方が通用しなくなってくる。(..) となれば「コンピュータ」か「人間」かという区別をしないシステム設計や組織設計というものが確実に増えてくるでしょう。

資本だけで簡単にスケールできる状態になる「コンピュータ」と「人間」の区別がない組織設計というものは、もう今でも本当は現実に起きていることです。

今はまだ、コンピュータの設計、システムの設計をする人、組織の設計をする人も、それぞれ違った知識や目線でそれを行っている。(..) ソフトウェアのアーキテクチャの理論と組織設計の理論というのはかなり近しい部分がある。(中略)

だから、今後、アーキテクチャと組織の統一理論が出てくるための入り口として「招待」というタイトルをつけたんです。

「コンピュータ」か「人間」かという区別をしない組織への招待ー広木大地さんブクログ大賞受賞記念インタビュー前編

エンジニアリングマネージャーのロードマップ、

「アーキテクチャと組織の統一」を目指そう。

ご清聴ありがとうございました