開発生産性を経営に説明する方法：CTO／VPoEのための「翻訳」の技術

こんにちは、大平です。

技術顧問として開発組織に関わっていると、CTOやVPoEの方から「経営会議で開発の状況をうまく説明できない」という相談を受けることがあります。 デプロイ頻度もリードタイムも測っている。 ダッシュボードも整備した。 それでも経営会議に数字を持っていくと、「で、結局うちの開発は順調なの？」と聞き返されてしまう。 数字はあるのに、説明が成立していない状態です。

これは説明する側の能力の問題ではなく、翻訳の工程が抜けているだけだと考えています。 この記事では、開発生産性の指標を経営の意思決定につなげる「翻訳」の方法を、会議に出す資料の型まで含めて書きます。 対象は、開発の数字を経営会議に載せる立場のCTO、VPoE、開発部長と、その報告を受ける側の経営者の方です。

なぜ伝わらないのか：言語が違う

経営会議の言語は、突き詰めるとお金、時間、リスクの3つです。 その投資はいくらで、いつ効果が出て、何が起きたら困るのか。 議題が営業でもマーケティングでも採用でも、意思決定はこの3軸に載せて行われます。

一方、開発生産性の指標は、そのままでは「デプロイ頻度が週3回」「変更のリードタイムが中央値2日」という形をしています。 これは開発チームの内部言語であって、経営の3軸のどれにも直接は載っていません。 翻訳を挟まずに指標を投影するのは、日本語の会議に英語の資料を持ち込むのと同じです。 聞き手の理解力の問題ではなく、翻訳の工程が抜けています。

もう1つ、先に押さえるべきなのは説明の目的です。 経営への説明は「開発が頑張っていることを分かってもらう」ためではありません。 次の投資判断（予算、人員、技術投資、外部委託）を正しくしてもらうためです。 この目的から逆算すると、出すべき数字と出し方が決まります。 逆に、目的が「理解してもらうこと」で止まっていると、資料は指標の網羅に向かい、会議は数字の説明会になります。

なお、指標そのものの現行定義（DORAの指標が5つになったこと、現在のQuick Checkでは年次調査のクラスタ区分ではなく0〜10のスコアを使うこと）は2026年版の解説に、指標選びの全体像は開発生産性の総論にまとめています。 この記事は「測れている前提で、どう話すか」を扱います。

原則1：指標を事業の言葉に言い換えてから出す

DORAの5指標は、経営の言葉に言い換えられます。

たとえば「変更のリードタイムが14日から4日になりました」は、「コードとして確定した変更を本番へ届ける待ち時間を10日短縮し、仮説検証や緊急対応へ移れる時点を前倒ししやすくなりました」と言い換えられます。 同じ事実でも、後者は経営の3軸のうち、時間とリスクに載っています。 ただし、コミット前の企画や実装にかかった時間は含まれないため、「意思決定から顧客提供までが10日短くなった」と測定範囲を広げてはいけません。

金額への換算は、効果的ですが慎重にやるべきです。 障害対応や再作業に費やした工数へ人件費を掛ける換算は、投資規模を話す土台になります。 一方、レビュー待ちの経過時間をそのまま人件費へ掛けることはできません。 待っている間に別の仕事をしている可能性があり、実際に失われた工数とは限らないからです。 換算の前提を明示し、一点の金額ではなく下限と上限を示す方が、議論に耐える資料になります。

原則2：「ベースライン → 投資 → 差分」の構造で話す

改善報告の最小構造はこの3点セットです。 着手前の数字（ベースライン）、実施した投資、その後の差分。 このうちベースラインが最も重要です。

「AIを導入して開発が速くなりました」という報告は、導入前の数字がなければ検証のしようがない印象論です。 Gitやデプロイの履歴から遡って復元できる指標もありますが、当時の待ち状態や開発者の体感は後から同じ条件で取れません。 着手前に定義を固定して数週間の記録を取れば、同じ報告が投資判断の材料になります。 これから技術投資の説明をする立場なら、投資の承認を取りに行く前に、まずベースラインの記録を始めてください。

投資を要望する場面では、この構造を未来向きに使います。 「この投資で、この数字を、ここからここまで動かします」と伝えます。 あわせて「結果は次の定例で確認します」と約束し、目標と確認日をセットにします。 予測が外れることはありますが、構造があれば「なぜ外れたか」を検証でき、次の要望の精度が上がります。 構造がなければ、外れたことにすら気づかれず、開発投資は「効果のよく分からない出費」として扱われ続けます。

原則3：アウトプットとアウトカムを分けて示す

開発が速く安全になったこと（DORAの指標が示すもの）と、事業成果が出たこと（売上や利用率）は、別の話です。 ここを混ぜて「開発生産性が上がったので事業も伸びます」と語ると、事業が伸びなかったときに、開発生産性の数字ごと信用を失います。

誠実な切り分けはこうです。 「デリバリの能力が改善し、仮説を試せる回数は増えた」と説明します。 一方で、何を作るかはプロダクトと事業の議題であり、別の指標で評価します。 開発の責任範囲を明確にすることは、責任逃れではなく、経営が正しい場所に次の問いを立てるための整理です。 結果的に、開発への信頼を守ることにもつながります。

経営会議に出す「1枚」の型

実務でおすすめしているのは、毎回同じフォーマットの1枚を定点で出し続けることです。

• 上段：スループット3つ（デプロイ頻度、変更のリードタイム、失敗デプロイの復旧時間）と不安定性2つ（変更失敗率、デプロイ手戻り率）の直近数か月の推移。それぞれに改善、横ばい、悪化の矢印を付ける
• 中段：今期のトピックを1つだけ。最大のボトルネックと、打っている手
• 下段：次の投資の要望と、それで動かすつもりの数字

運用のコツは3つあります。 一つ目は悪い数字を隠さないことです。 数字の信用は資産で、一度「良いときだけ出す資料」だと思われると、良い数字まで割り引いて受け取られます。 悪化は、原因の仮説と打ち手をセットにして出すほうが、むしろ信頼されます。

二つ目は数字の定義を途中で変えないことです。 定義を変えると推移が読めなくなります。 どうしても変える場合は、変更点と理由を資料に注記します。

三つ目はダッシュボードのスクリーンショットを貼らないことです。 計測ツールの画面は情報量が多すぎて、経営の3軸に載りません。 ツールは裏側の集計に使い、会議に出すのは翻訳済みの1枚だけにします。

やってはいけない説明

• 行数、コミット数、PR数を成果として出す。 作業量の診断には使えても、顧客価値やデリバリ能力を直接測る数字ではありません。 AIコーディング支援の普及後は生成量を増やしやすくなり、生産性の代理指標としての信頼性はさらに下がっています
• 古い閾値で「うちはElite相当」と自己評価する。 過去のDORA年次レポートに登場した区分は、その年の回答をクラスタ分析した結果です。 業界ベンチマークは参考情報にとどめ、同じ定義で測った自社の推移を主な比較対象にします
• 根拠を説明できない倍率を出す。 「生産性が2倍になりました」と言っても、何の2倍なのかを答えられない主張は、資料全体の信用を損ないます
• 良い指標だけを選んで出す。スループットだけ見せて不安定性を伏せる報告は、悪化が表面化したときに「知っていて伏せた」ことになります

逆方向の翻訳も、この仕事のうち

翻訳は開発から経営への一方向ではありません。 経営からの問いを、制約の言葉に訳し戻すのも同じ仕事です。

「人を増やせば速くなるのか」と聞かれたら、ボトルネックの位置で答えが変わることを説明します。 実装能力が制約なら増員が効く可能性はありますが、立ち上がりまでの時間と教育負荷も見込む必要があります。 レビューや意思決定の待ちが制約なら、実装担当だけを増やすと仕掛かりが増え、かえって遅くなることがあります。 どこで詰まっているかの診断はAI導入で生産性が上がらない会社の分析で詳しく書きましたが、この診断結果こそ、経営の問いへの答えとして持っていくべき情報です。

「なぜ機能追加を止めて基盤にお金を使うのか」と聞かれたら、技術的負債を数字の言葉で説明します。 負債を放置すると、変更のリードタイムが伸びる可能性があります。 そこで市場への反応速度を維持する投資という形で、事業の言葉に翻訳できます。 「リファクタリングさせてください」では通らない要望が、「反応速度の悪化を止める投資です」なら議論の土俵に載ります。

報告を受ける経営者のためのチェックリスト

ここまでは説明する側の話でしたが、報告を受ける側にも確認の型があると、会議の質が変わります。 開発の報告を受けたとき、次の5つを聞いてみてください。

1. その数字の定義は何か：起点と終点を即答できない数字は、まだ管理に使える状態ではありません
2. 比較対象はいつの自社か：他社比較だけで良否を決めず、同じ条件で測った自社の推移を確認します
3. 悪化している指標はどれか：すべて良い場合も、対象範囲や集計条件が限定されていないかを確認します
4. ボトルネックと次の投資は何か：現状報告で終わる資料より、投資の要望まで載っている資料の方が意思決定に使えます
5. AI投資の効果を導入前の何と比べたか：ベースラインがなければ、効果の大きさを判断できません

これらに淀みなく答えられる開発責任者なら、数字の運用は信頼できます。 答えられない場合は、責める材料ではなく、計測体制への投資が先だというサインとして扱ってください。

まとめ

• 経営の言語はお金、時間、リスク。指標はこの3軸に言い換えてから出す
• ベースライン → 投資 → 差分の構造で話す。着手前の数字が説明の土台になり、待ち状態や当時の体感など後から同じ条件で取れない情報もある
• アウトプットとアウトカムを分ける。切り分けの明確さが、開発への信頼を守る
• 毎回同じ1枚を出し続ける。 定義を変えず、悪い数字も原因と打ち手をセットにして出す
• 翻訳は双方向。経営の問いを制約の言葉に訳し戻すところまでが仕事

開発生産性の計測は、ツールを入れれば終わる仕事ではなく、経営との共通言語を作る仕事です。 共通言語ができると、開発への投資判断が速くなり、それ自体が開発組織の競争力になります。