チーム開発 （2026年10月4日 更新） 6 min read

技術の話を経営層に伝える型——What / How much / So what で組み立てる

技術的な成果や課題を経営層に報告するとき、技術用語のままでは判断材料にならない。What / How much / So what の3点で組み立てる型と、数字・リスク・ビジョンの3つの軸、1枚資料の作り方をまとめる。

マネジメントテックリード組織設計

技術の成果や課題を経営層に報告するとき、自分は「What（何が変わったか）/ How much（どれだけ変わったか）/ So what（今後どうなるか）」の3点で話を組み立てている。

技術用語のまま話していた頃は、話が噛み合わないことが多かった。型を決めてからは、報告や投資の相談が通りやすくなった。この記事では、その型と使用例、資料の作り方をまとめる。

背景：技術の言葉のままでは判断材料にならない

自分は医療系の会社で、社内の業務システムを開発するチームのテックリードをしている。開発の状況を経営層に報告し、必要な投資を相談するのも役割の一部だ。

最初の頃は「コードが汚い」「テストカバレッジが低い」といった言葉でそのまま話していた。これは届かなかった。聞き手が技術に詳しいかどうかとは別の問題で、技術の言葉は人によって受け取り方が違う。同じ単語を使っていても解釈がずれたまま話が進み、噛み合わないことがあった。

そこでやり方を変えた。技術の話をするときは、必ず数字か事業への影響とセットにする。「こういう問題がある」で終わらせず、「この問題を放置するとこういうリスクがある。直すとこれだけ変わる」という構造で話す。

What / How much / So what

型は次の3点である。

| 項目 | 答える問い | 書くこと | |---|---|---| | What | 何が変わったか | 技術的な手段ではなく、結果として変わったこと | | How much | どれだけ変わったか | 費用・期間・頻度など、比べられる数字 | | So what | 今後どうなるか | その結果、会社として何ができるようになるか |

使用例：内製化の報告

外部ベンダーに委託していた開発を内製に切り替えたとき、その結果を報告する場面があった。エンジニアとして言いたくなるのは「NestJSでAPIを内製化した」だが、この報告では技術の話を一切しなかった。

| 項目 | 報告した内容 | |---|---| | What | 外部委託していた開発を社内でまかなえるようになった | | How much | 外部委託の固定費がなくなった。機能追加のリードタイムは、体感で3週間ほどかかっていたものが3日ほどになった | | So what | 今後の改修は自社でコントロールできる |

フレームワークの名前や設計の工夫は、聞かれたら答えればよい。先に出すのは、意思決定に使える3点だけにした。

伝わらないときに使う3つの軸

How much と So what が埋まらないときは、次の3つの軸のどれで語れるかを考える。

数字で語る

「開発速度が上がった」は伝わらない。「リリースサイクルが月1回から週1回になった」のように、前後を比べられる形に言い換えると伝わる。

定量化しにくいものは近似値を出す。経営判断に必要なのは精度より「オーダーがわかること」だと考えている。ただし近似値であることは隠さず、「体感では」「おおよそ」と添えるのがよい。

リスクで語る

「今はたまたま動いているが、放置するとこうなる」という形で話す。たとえば特定の人しか触れない部分があるなら、その人が不在になったときに何が止まるかを具体的に書く。最悪のシナリオが具体的であるほど、予防のための投資の意味が伝わりやすい。

ビジョンで語る

コストとリスクだけで話すと、守りの議論に偏る。「この基盤を整えると、来年この機能を外部に頼らず開発できる」のように、整えた先で何ができるようになるかも合わせて話す。

言い換えの対応表

| 技術の言葉 | 使う軸 | 言い換えの形 | |---|---|---| | 開発速度が上がった | 数字 | リリースサイクルが月1回から週1回になった | | コードが汚い、テストカバレッジが低い | リスク | 放置するとこういうリスクがある。直すとこれだけ変わる | | 基盤を整備したい | ビジョン | 整えると、来年この機能を外部に頼らず開発できる |

資料は1枚、基準は「5分で決めてもらえるか」

経営層向けの資料は、What・Why・いくら・いつまで が1枚で見えるようにしている。詳細は別添に回す。

# （件名：何を決めてほしいか）

## What（何をするか／何が変わったか）
-

## Why（なぜ今か。放置した場合のリスク）
-

## いくら（費用・工数。近似値ならそう明記する）
-

## いつまで（期限とマイルストーン）
-

※ 技術的な詳細は別添

作ったあとに「この資料を見た人が5分で意思決定できるか」を確認する。エンジニアとして作りたい資料と、意思決定者が必要とする資料は別物である。構成図や技術選定の比較は、自分にとっては本題でも、決める側にとっては別添で足りることが多い。

うまくいかなかった点

  • 型にたどり着くまでは、技術の言葉で説明しては噛み合わない、ということを繰り返していた。問題の指摘だけで終わる報告は、判断を求められた側も動きようがない
  • 定量化できないものは近似値に頼ることになる。精度には限界があるので、オーダーが伝われば十分と割り切っている
  • コストとリスクの話だけを続けると、守りの議論に偏る。ビジョンの軸を意識して足すようにしているのはそのためだ

まとめ

  • 報告は What / How much / So what の3点で組み立てる。技術的な手段は聞かれてから答える
  • 埋まらないときは、数字・リスク・ビジョンのどの軸で語れるかを考える
  • 定量化しにくいものは近似値でよい。ただし近似値だと明示する
  • 資料は1枚にまとめ、詳細は別添。「5分で決めてもらえるか」で確認する

技術を経営の言葉に置き換える作業は、最初は仕方なくやっていた。今はテックリードの仕事の中心のひとつだと考えている。コードを書く時間との両立については、プレイングマネージャーの記事に書いた。

関連記事:

関連記事

↑