感覚頼りのマネジメントから脱却。事業/技術/組織を全て構造化して、複雑性を解きほぐす思考法

EM（エンジニアリングマネージャー、以下EM）は、事業目標への貢献、技術的な課題解決、チームメンバーの育成、組織文化の醸成…と、日々複雑に絡み合う多様な課題に直面します。その全体像を正確に把握し、的確な打ち手を導き出すのは容易ではありません。「感覚」や「経験則」に頼るマネジメントに限界を感じることもあるでしょう。

複雑な課題をシンプルに捉え直し、本質的な解決策を見出すために、READYFORのVPoEとEMを兼務する熊谷遼平氏は「構造化」と「可視化」を徹底しています。「事業」「技術」「組織」を徹底的に分解して構造化し、それらのつながりを可視化するのです。

事業価値とエンジニアリングの接続から、開発生産性の体系的な分析・改善、チームや組織運営におけるビジネスフレームワークの活用まで。「Engineering Manager Conference Japan 2025」の登壇時に、豊富な図解と具体的な試行錯誤を詰め込んで紹介された内容を、一部再編集してお届けします。

• keyboard_arrow_down 1. 事業軸
• keyboard_arrow_down 1-1. 「戦略」と「事業価値」の構造を解き明かす
• keyboard_arrow_down 1-2. 「事業価値」と「エンジニアリング戦略」の関係とは
• keyboard_arrow_down 1-3. 事業軸のまとめ｜事業価値とエンジニアリングの「距離」を理解する
• keyboard_arrow_down 2. 技術軸
• keyboard_arrow_down 2-1. 「定性」「定量」どちらも使って計測する
• keyboard_arrow_down 2-2. Four Keysのレポーティングで、課題発生の「傾向」が見える
• keyboard_arrow_down 2-3. QCDと信頼性を可視化し、改善する方法
• keyboard_arrow_down 2-4. 技術軸のまとめ｜FourKeysは遅行指標
• keyboard_arrow_down 3. 組織軸
• keyboard_arrow_down 3-1. EMの役割、認識合わせのための「構造化」「可視化」
• keyboard_arrow_down 3-2. AI時代のEMは「カルチャーをつくる人」になる
• keyboard_arrow_down さいごに｜ビジネスフレームワークを駆使して「構造化」する

READYFORでEMおよびVPoEを5年ほど務めている熊谷といいます。今日は、事業価値とエンジニアリングを融合させ価値を生み出していくために、これまで試行錯誤してきたことを、事業軸、技術軸、組織軸の3部構成で紹介します。

まず、事業軸について。戦略や事業価値とはそもそも何なのか、私なりに構造化してきた内容を紹介します。

戦略、とは何を指す言葉なのでしょうか。この定義は意外と曖昧かもしれません。そこで、「戦略」の巨匠であるマイケル・ポーターの定義を引用します。彼は「戦略」と「業務効果」を明確に区別しています。

この考え方をエンジニアリングに適用すると、こんな感じになるんじゃないかと考えています。当社では下記のように「戦略」「業務効果」を定義しています。

では、事業価値とは何か。戦略の定義がふわっとしている一方、事業価値には一定の定義があります。

計算方法はいくつかありますが、オーソドックスなDCF（Discounted Cash Flow）法では、将来生み出す利益（フリーキャッシュフロー）の予測値を、WACC（加重平均資本コスト）と呼ばれる割引率を用いて、現在価値に割り戻したものの合計で表されます。

図で示すと以下のような形です。

ここで大事なポイントは「事業価値を高める主な変数は、フリーキャッシュフローであること」です。フリーキャッシュフローにも方程式があり、損益計算書（PL）や貸借対照表（BS）の項目を用いて、下の図のようにさらに分解できます。

上記の、フリーキャッシュフローを構成する変数は、企業価値を構造化した以下の表での赤い文字にあたります。事業価値を分解すると、こんな構造になっているわけですね。

でもここで、この計算式を覚えてほしいわけではありません。大切なのは、エンジニアリングと事業価値との「距離感」の遠さに注目することです。

事業価値があり、さらにFCF、売上・利益、売上高や販管費などがあり、その先にプロダクト戦略やエンジニアリング戦略、そしてさらに先に我々が日々向き合うコードや具体的な課題があります。この距離感を認識せずにエンジニアと経営層が会話するから、すれ違いが発生してしまうのだろうと考えています。

では、事業価値はすべて、売上や利益など短期的な財務成果に繋がるのでしょうか？　そういうわけではありませんよね。

私は目先の利益だけでなく、組織が将来にわたって健全に成長し価値を高め続けていくために、非財務指標にも着目しています。この分野は世界的にまだ確立されていませんが、例えば最近では「ステークホルダー資本主義指標」というものが出てきて、以下の図のような内容が含まれています。EMが実践する取り組みの多くは、これらの非財務指標に近いと感じています。

まだ先の話かもしれませんが、これらの価値が市場からも評価されるようになれば、EMが向き合う課題や取り組みの意義を説明しやすくなるでしょう。短期的な財務成果だけを追求することの弊害も指摘される中、非財務指標の重要性は増しています。開発生産性やモチベーションの向上など、非財務指標として重要度が高いことに取り組む機会が多いEMこそ、この分野の議論を深め、自社なりの方針を確立していけるとよいなと思っています。

また当社では、「プロダクト戦略」と「エンジニアリング戦略」を分けて考えています。

プロダクト価値や利益だけを判断軸にすると、技術的負債の解消やリファクタリングといった施策が、優先度が低いと判断されがち。長期的にはプロダクト価値を向上できなくなっていきます。そうした事態を防ぐため「エンジニアリング戦略」と「プロダクト戦略」という2つの軸を設け、それぞれで選択と集中を行う方針をとっています。

そして、この2つの戦略の定義を昇華していくと、財務諸表のメタファーにたどり着きます。

プロダクト戦略は売上や利益に直結する、選択と集中の軸であり、これはPL（損益計算書）に相当します。一方エンジニアリング戦略は、有限なエンジニアリング資産をいかに最大化させるかという選択と集中の軸であり、これはBS（貸借対照表）に例えられ、先ほどの非財務指標にも繋がります。2つの戦略のバランスをあらかじめ考慮した上で、それぞれの戦略を策定しています。

ここからはよりエンジニアリングの領域の話をしていきます。

まずは「開発生産性」の構造を捉えていきます。当社では広木大地さんの「開発生産性の方程式」に則っています。

これを先ほどの財務指標と関連づけながら分解すると、以下のような構造で整理できます。

開発生産性を「価値」と「費用」に分け、価値の部分を「プロダクト価値」とそのアップサイド（価値向上の可能性）の拡大として、費用の部分を開発工数、人数、人件費として、QCD（Quality, Cost, Delivery）に似た形で整理しています。

さらに分解を進めると、Four KeysやDevOps Capabilitiesといった、より馴染み深いキーワードが出てきます。

開発人数、人件費、開発工数はQCD指標のような関連性を持っています。このバランスをとるために、図の右上の指標を用いて、開発品質と開発工数を可視化する。一方、右下のDevOps Capabilitiesは、開発組織全体の能力を底上げするための定性的な指標です。それぞれの指標を数値化し、状況を把握しながら選択と集中に関する判断を行っています。

重要なのは構造化すること自体というより、構造化を通じてボトルネックを可視化し、関係者間で認識を合わせることです。

それに、ここで示した構造化の方法はあくまで一例であり、当社での試行錯誤の結果です。自社の状況に合わせて要因を分解し、しっくりくる形に落とし込めるといいんじゃないかなと思います。

改めて「事業軸」をまとめます。事業価値を追求することは、もちろん重要です。同時に事業価値とエンジニアリング活動との距離感を理解し、コミュニケーションのプロトコルを使い分けることも大切。

ただし事業価値の構造をそのまま使うと、日々の課題解決に活用しづらい面もあります。そのため、先ほど示した開発生産性の分解のように、プロダクトや事業の文脈を踏まえつつ、中間的な構造化や言語化を試みることが重要だと思います。以上が事業軸の話です。

続いて技術軸の話です。こちらはより馴染みやすい内容かと思います。QCD、Four Keys、DevOps Capabilitiesといった指標を構造化・可視化した後、具体的にどう開発組織の運営に活用していくかについて説明します。

当社でも3～4年前にFourKeysなどを導入し、開発生産性の向上を目標に掲げていました。

当時は、技術的負債が蓄積したレガシーシステムが大きな課題でした。各エンジニアが負債解消、アーキテクチャの再設計、CI/CD改善など様々な手段で改善していきました。ただ、これらの改善を振り返った際に「何がどう改善されたのか」が定量的にも定性的にも不明確な状況になっていました。このままでは闇雲な改善になってしまう。

そこで、統計的なエビデンスが確立されつつあったFour Keysや、CTO協会が提供するDX Criteriaのアセスメントシートなどを活用し、体系的かつ定量的に状況を捉え、課題発見と解決を進める方針を採用しました。

3〜4年間取り組んだ結果として、開発生産性や開発者体験は定性・定量的に大幅に改善し、当時のDORAレポートにおけるElite基準のほぼ全てを満たす状態になりました。現在ではFour Keysそのものを主要な目標指標とはしていませんが、日々のヘルスチェックとして活用しています。

具体的にどのように取り組んでいるのかをもう少し深掘りします。

まず、定性分析です。Figmaを用いて、ボトルネック特定のためのワークショップを実施しています。DORAのDevOps Capabilitiesの各項目を色分けして並べ、それらに関連する課題感を、テックリードやエンジニアが付箋で記載していきます。するとこのように、課題の付箋がたくさん集まります。

この取り組みのメリットは、今ある課題をある程度まとめて可視化できること。このときはセキュリティ対策の甘さ、アーキテクチャ上の課題、デプロイプロセスの問題などが挙げられました。組織全体の状況を把握する上で非常に有効なワークショップだと感じていて、現在も半年～1年に1回など定期的に実施しています。

定量分析においては、CTO協会のアセスメントシートを、エンジニアリング組織全体で利用しました。このシートでは定性的な項目を一定の基準で定量評価するため、現状を数値として可視化できます。

ただ、実施には相当の労力がかかります。シートには様々なカテゴリがあるのですが、当社ではテクノロジーのカテゴリーに絞って実施しました。これも、現状分析にはとても有効でした。

Four Keysのレポーティングは、CI/CDパイプラインから直接BigQueryにデータを送信し、Looker Studio（旧 Google Data Portal）で可視化して自動集計しています。このレポートはそのままGoogleスライドに連携し、部会などで共有しています。

レポーティングを続けていくと、過去からの改善の推移を可視化することもできます。2020年から2025年までの5年間の推移が以下です。結果として大幅に改善しました。特にデプロイ頻度は右肩上がりに向上。現在ではエンジニア1人あたり平均して月に約20回本番デプロイを行っています。

このグラフを見ると興味深いことに、約5ヶ月周期でデプロイ頻度がピークアウトする傾向が見られます。これは現在も続いています。傾向を可視化することで、いつどんな改善施策をすべきか、前もって具体的に検討できるのも良いなと思っています。

QCDに関しては、見積もりと実績と比較してふりかえりを行い、見積もり精度を改善し続けています。見積もりと実績のデータをチームごとに集計して見積もり精度を数値化し、定期的に振り返りを行って改善点を探っています。

チームごとに見積もりの傾向が見えてくると、似た傾向を持つチームでうまくいった方法を試せるようになり、再現性向上につながっています。

信頼性に関してもFourKeysと同様に、データを集計してLooker Studioで可視化し、Googleスライドでレポートしています。インシデント対応や調査には、Datadogなどの専用ツールを使用しています。

プロダクトに関わるチームごとにSLI（Service Level Indicator）を1～3つ設定し、ユーザー体験に直結する信頼性指標をチーム自身が把握・管理できる状態を目指しています。ちなみに、エラーバジェットは運用していません。

データ収集は、DatadogからS3を経由し、BigQuery、dbt、BigQueryという流れで処理・可視化する形で運用しています。運用している指標は、主にバックエンドの可用性とレイテンシです。フロントエンド側は、ユーザー環境による影響が大きくエラーを同じ状況で再現できなかったりなど、コントロールが難しい側面があるため、基本的にはSLIの対象としていません。レポートでは、エンドポイントごとに各指標の月次推移をグラフなどで表示していて、集計・可視化は基本的に自動化されています。

信頼性を数値化できていなかった頃は、プロダクトチームが管轄する機能の信頼性が知らぬ間に悪化してしまうケースがありました。こうした状況は、各チームが責任を持ってSLIの数値を追いかけ、課題発見と改善に取り組めていれば、防ぎやすくなると考えています。悪化してから対応するのではなく、常に状況を可視化・把握して、対応の要否も含めてプロダクトチーム内でコントロールする。そのような運用をしています。

Four Keys自体は、あくまでパフォーマンスを測るための1つのツールです。導入にあたっては「何を解決したいのか」という仮説を明確にすることが重要です。試行錯誤する中で、「個々のエンジニアリング施策が直接的にFour Keysの改善に結びつくケースは稀だ」と気づきました。施策の効果は時間をかけて浸透し、徐々に現れることが多い。そのため、Four Keysは遅行指標として捉えるのが適切でしょう。

今日紹介したFour Keysや関連するプラクティスは、過去のものとなりつつある側面もあるかもしれません。書籍の出版から6年以上経過しますし、近年のAIの台頭によるソフトウェア開発の変化も非常に大きい。そのため、FourKeysの位置づけを理解した上で活用していくことが望ましいでしょう。

開発生産性改善における考え方の基礎は、『LeanとDevOpsの科学』にあると感じています。最近の書籍でも基本的に引用されているため、まず目を通すというのも大事だと思います。

ここからは組織軸の話です。

複数のEMがいる規模の組織で、EMが個々の経験や感覚に基づいてマネジメントを行うと、役割や責任範囲が曖昧になって重複や欠落が生じたり、注力すべき課題や優先順位の認識がズレたりしがちです。また、互いの活動が見えにくく連携が難しいことによって、マネジメントの基準もブレる。さらにメンバーや組織に対しては、EM間で方針が異なることで矛盾した指示を与えてしまい混乱や不信感を招くなど、組織の一体感を損なう可能性も出てきます。

これらの課題を防ぎ、EMチームとして一貫性を持ち、効果的に連携しながら組織全体のパフォーマンスを高めていくためには、「認識を合わせること」が重要です。この「認識合わせ」のために、当社で行っている取り組みを紹介します。

当社では、EMが担うマネジメントを「組織マネジメント」「ピープルマネジメント」「チームマネジメント」の3つに分解して以下のように図解し、EM間で認識を合わせています。

当社のEMは組織マネジメントとピープルマネジメントの比重が高いですが、場合によってはチームマネジメントにも関わります。各サイクルは特性や周期が異なるため、サイクル自体に課題を感じたら、さらに分解して問題箇所を特定して認識を合わせています。

EMの役割を明確にする上では、「EMの役割は、事業フェーズや状況によって変化する」という前提を捉えることが重要です。以下のように簡単に整理してみました。

例えば、スタートアップなど組織が小さいフェーズでは「①成果」の比重が高く、組織が大きくなるにつれて「③育成」や「④調整の重要性」が増す傾向があります。

EMの中で「今の状況で、誰にどういう役割が求められているのか」が明確になっていないまま協働していたり、その役割分担がメンバーに正しく伝わっていなかったりすると、組織全体が効率よく動けなくなっていきます。例えば、メンバーにとっての相談先が不明瞭になったり、意思決定が遅くなったり、責任の所在が曖昧になって連携がうまくいかなかったり。

そこで当社では、複数人いるEMの役割分担を明確に可視化し、現場のエンジニアも把握できるようにしました。その際につくった表がこちらです。

EMの4象限（ピープル、プロジェクト、プロダクト、テクノロジー）に「ストラテジーマネジメント」を追加した表に各EMの役割をまとめる。その上で、各EMが担う役割の優先順位（Primary/Secondary）も明示するようにしています。これにより、メンバーは誰に相談すればよいか分かりやすくなり、連携がスムーズになります。

少し別の角度から、EMの将来について最近考えていることを共有します。今後のエンジニアリング組織を考える上で、生成AIの影響は無視できません。この影響について、以下のように分解して考察しています。

まずはスキル軸からみていきましょう。生成AIにより、技術習得が容易になることで、EMには複数領域をまたがったより広範な知識が求められるようになる。それに伴い事業領域の知見の獲得も必須になる。その下の青い字、特化型のスキル軸としては、特定の深い技術領域をAIが代替することで、エンジニアがそうした領域に直接触れる機会が少なくなる可能性があります。その結果、深い技術領域に関する経験や知見の希少価値は上昇するかもしれません。こうしたスキル軸の変化と、一番上の生産性軸との関連を見ていくと、「事業価値における生産性の最大化」がより強く求められるようになるといえます。

チーム軸では、開発チームの少数精鋭化が進むことにより、多様な職能を持つメンバーで構成されるストリームアラインドチームのような形態が一般的になっていくかもしれません。

また、図表一番右の「ビジネス課題」に目を向けてみると、大規模で簡単な課題から解決されていくようになり、残された課題はより希少性が高く、難易度も上がっていくと考えられます。

つまり、AIによって技術的な敷居が下がる一方で、事業価値を創出するために求められる要件は、より高度化・複雑化していく。結果として、より多様かつ高度なスキルを持つ人材やチームが求められるようになるでしょう。

こうした変化を踏まえるとEMは、生成AI時代においても市場価値の高いエンジニアを育成するための方針やキャリアパスの設計などをしていく必要があるのだろうと考えています。

組織運営の面では、今もよく言われている「バッファを持たせること」の重要性は、今後も高いだろうと考えています。

学習時間を業務時間内に組み込むなど、学習文化を組織内に設計することも重要です。こうした方針を明確にし、メンバーに伝えることは、組織全体の生産性を最大化する上で、地味ながらも重要な取り組みです。

さらに、事業成長の源泉となるような組織文化を醸成していくことも、EMのより重要な役割となるでしょう。特にピープルマネジメントにおいては、表面的な事柄の相談や解決はAIに代替され、個々のメンバーの内面（モチベーション、キャリアへの考え、不安など）に向き合うことが多くなります。

メンバーが抱える不満やモチベーションの要因を分解していくと、以下の表の右上のように「ディレクション（方向性）」「ハンドリング（操作性）」「サポート（安全性）」といった要素が見えてきます。

それぞれの要素をさらに深掘りすると、キャリアへの不安や、心理的安全性の欠如といった具体的な問題に行き着くこともあります。問題を構造化して捉え、関係者と認識を合わせながら解決策を探っていくのが有効です。

「売上は全てを癒す」とよく言いますが、この引用元の文章には続きがあります。それは「事業成長は組織課題を隠す」ということ。

事業価値をドライに追求することはもちろん重要ですが、メンバーの心理面や組織文化などウェットな側面は、中長期的に組織の芯として残っていく部分です。DORAのDevOps Capabilitiesの中にも文化に関する項目が含まれているように、組織文化の重要性は統計的にも示唆されています。事業成長を追求するうえで、ウェットな面を切り離すことはできない。両方を大切にすることを心掛けています。

今回は組織課題について、様々な分解や構造化の方法を提示しました。これらをそのまま使うのではなく、自社の状況に合わせて分解・整理してみてください。その際、既存のビジネスフレームワークを使ってみると、うまく構造化できるかもしれません。

例えば、組織変革のフレームワークである「7S」を使うと、こんな感じ。

こうして必要な要素を抽出し、分解して示すことで、メンバーも課題を理解しやすくなり、一体感を持って取り組みやすくなるので、おすすめです。

参考までに、便利なビジネスフレームワークをまとめたチートシートを用意しておきます。

ここで紹介したのはあくまで一部ですから、様々な方法を試してみてください。

最後にAppendixとして参考書籍などを載せています。特に参考になった本とその抜粋をまとめたので、よかったら見てみてください。

https://speakerdeck.com/9ma3r/emconf2025?slide=47

以上で本発表を終わります。ありがとうございました。

執筆・編集：光松瞳