AI導入で生産性が上がらない会社は、どこで詰まっているのか

こんにちは、大平です。

AIコーディング支援を導入したのに、個人の「便利になった」という声ほど、組織全体のリリース速度が変わらない。 最近は、こうした相談を受けることがあります。

このとき、「使い方の研修が足りない」と判断して利用率だけを上げても、生産性が改善するとは限りません。 実装の下流にあるレビュー、仕様決定、テスト、承認、デプロイが詰まっていれば、コードを作る速度が上がるほど待ち行列が長くなることもあるからです。

DORA 2025レポートは、AIをチームの問題を直す道具というより、組織がすでに持つ能力や弱点を増幅するものと整理しています。 AIを入れても速くならない現場の共通点も、ツールの性能だけでは説明できません。

AI導入の投資対効果を判断するには、個人の生成量ではなく、顧客に変更が届くまでの流れでどこが何時間止まったかを測る必要があります。

生産性を三つの層に分ける

「生産性」という一語に、個人の作業量、チームのデリバリ、事業成果をまとめると診断を誤ります。

SPACEフレームワークの原著は、開発者の生産性を単一の指標では捉えられないとして、満足度とウェルビーイング、成果、活動、コミュニケーションと協働、効率と流れの五つの次元を示しています。 コミット数やプルリクエスト数は、このうち「活動」の一部にすぎません。

僕はAI導入の意思決定では、数字を次の三層に分けて見るのが扱いやすいと考えています。

• 個人の作業：調査、実装、テスト作成、レビュー準備などに使った時間
• チームの流れ：着手可能になった変更が、レビューや承認を通って本番へ届くまでの時間
• 成果と安全性：利用率や売上などの事業成果と、障害や計画外修正を増やしていないか

AIが個人の実装を短くしたとしても、残りの二層が同じ方向へ動くとは限りません。 逆に、実装時間がほとんど変わらなくても、調査の共有やレビュー準備が改善し、チーム全体の待ち時間が短くなる場合もあります。

したがって、AIの利用率、生成行数、提案の採用率だけで「生産性が上がった」と報告するのは早計です。 これらは利用状況を知る補助指標にはなりますが、顧客へ価値を届けた量や速さを直接示す数字ではありません。

DORAの五指標は結果を示す

ソフトウェアデリバリの結果を継続的に見るには、DORAの指標が基準になります。 ただし、現在も通称としてFour Keysと呼ばれることがあるものの、2024年にデプロイ手戻り率が加わり、現行定義は五指標です。

DORAの現行ガイドと指標の変遷をまとめた公式ページに沿うと、五指標は次のように整理できます。

前三つはスループット、後ろ二つは不安定性を見る指標です。 速さだけを評価すると、レビューやテストを省いて数字を作る動機が生まれるため、スループットと不安定性は対で見ます。

なお、DORA 2025レポートでは、Elite、High、Medium、Lowという旧来のランク分けが廃止されています。 他社の古い水準表へ当てはめるのではなく、自社の同じサービスを同じ定義で継続比較してください。 現行定義と変更点は、公開済みの2026年版DORA／Four Keys解説でも詳しく整理しています。

DORAの五指標は、「デリバリ結果がどうなったか」を示す結果指標です。 レビュー待ちなのか、仕様回答待ちなのかといった原因までは教えてくれません。 ボトルネックを特定するには、結果指標の内側を区間に分けて測る必要があります。

最初に計測単位と境界を決める

計測ツールを選ぶ前に、何を一件と数え、どこからどこまでを測るかを決めます。 この定義が途中で変わると、施策の前後比較ができません。

まず対象を、ひとつのプロダクト、サービス、リポジトリなど、デプロイの流れがほぼ共通する範囲に絞ります。 Webサービスとモバイルアプリのように、リリース条件が異なるものを同じ母集団に入れると、数字の変化がAI導入によるものか、配布経路の違いによるものか分からなくなります。

次に、DORAの変更リードタイムと、企画を含む社内のリードタイムを分けます。 DORAの起点はコミットですが、仕様決定の詰まりを見たいなら、それより前の「着手可能になった時刻」も必要です。 社内では、次の二本を別名で持つと混同を避けられます。

• 変更のリードタイム：最初のコミットから本番デプロイ完了まで
• エンドツーエンド時間：チケットが着手可能になってから本番デプロイ完了まで

最後に、本番デプロイの定義を揃えます。 ステージング反映を本番として数えない、同じ変更の再実行をデプロイ回数へ重複計上しないなど、集計規則を短い文書に残します。

区間ごとにどの時刻を取るか

最初から大がかりなダッシュボードは要りません。 対象サービスの変更を数十件選び、チケット管理、Gitホスティング、CI/CD、インシデント管理に残る時刻を一つの表へ並べれば、最初の診断はできます。

最低限、次のイベントを取得します。

• 着手可能：仕様と受け入れ条件がそろい、開発者が作業を始められる状態になった時刻
• 開発開始：チケットを進行中へ移した時刻
• レビュー可能：ドラフトを外し、人へレビューを依頼した時刻
• 最初の人間レビュー：Botのコメントを除き、最初に承認または修正指摘が付いた時刻
• 仕様ブロック開始と解除：仕様判断が必要だと記録した時刻と、採用する回答が確定した時刻
• 承認とマージ：必要な承認がそろった時刻と、変更をマージした時刻
• 本番デプロイ完了：対象コミットが本番環境へ反映された時刻
• 失敗と復旧：デプロイ起因の即時対応が始まった時刻と、サービスを復旧した時刻

仕様の質問がチャットだけに流れると、開始と終了を機械的に取りにくくなります。 チケットに「仕様待ち」「法務承認待ち」「リリース承認待ち」などの停止理由を付け、解除時刻まで残す運用にすると、待ち時間を原因別に集計できます。

データをつなぐキーも必要です。 チケットIDをプルリクエストへ、コミットSHAをデプロイ記録へ、問題を起こしたデプロイをインシデントへ紐づけます。 すべてを自動化できなくても、対象を一つに絞って週次で補記すれば傾向は見えます。

待ち時間を診断する七つの数字

イベント時刻がそろえば、AI導入の前後で次の数字を比較します。

• 実装時間：開発開始からレビュー可能になるまで
• レビュー待ち時間：レビュー可能になってから最初の人間レビューまで
• 仕様回答待ち時間：仕様ブロック開始から解除まで
• 承認待ち時間：承認依頼から必要な承認がそろうまで
• デプロイ待ち時間：マージから本番デプロイ完了まで
• ブロック比率：エンドツーエンド時間のうち、停止理由が付いていた時間の割合
• 仕掛かり件数：完了していない変更の件数を、同じ時刻にスナップショットした値

それぞれについて、件数、中央値、p90を並べます。 中央値は典型的な変更を、p90は長く滞留した変更を把握するために使い、母数が少ない期間は件数も必ず併記します。 平均値だけでは、一件の長期停止に引っ張られたのか、全体が遅いのかを切り分けにくいためです。

変更失敗率やデプロイ手戻り率のような割合は、率だけでなく分子と分母も出します。 たとえば「変更失敗率20％」だけでは、五件中一件なのか、百件中二十件なのかが分かりません。

さらに、全変更の待ち時間を原因別に合計します。 中央値が長くても該当件数が一件だけなら、組織全体の最優先課題とは限りません。 「レビュー待ちで合計何時間失ったか」「仕様回答待ちで合計何時間失ったか」を並べると、予算をどこへ配るか判断しやすくなります。

二時間の実装が四日目に届く仮例

ここで、実際の顧客事例ではない仮の変更を置きます。 AIコーディング支援を使い、月曜の午前中に二時間で修正できたとします。

この仮例では、実装時間は二時間ですが、レビュー待ちは二十三時間、仕様回答待ちは四十七時間弱、マージ後のデプロイ待ちは四時間です。 着手から顧客へ届くまでは約八十時間なので、実装をさらに短くしても全体への寄与は小さくなります。

次に投資すべき場所は、AIモデルの追加契約とは限りません。 レビュー開始を早める当番設計、仕様判断者と期限の明確化、低リスク変更の承認委譲、デプロイの自動化などが候補になります。 どれを選ぶかは、実測した最長区間と総待ち時間で決めます。

症状から詰まりを切り分ける

一つの数字だけで原因を決めず、結果指標と診断指標を組み合わせます。

品質側が悪化したときは、「AI生成コードだから悪い」と即断せず、変更の大きさ、テスト範囲、レビュー条件、失敗の記録方法が前後で同じかを確認します。 そのうえで検証能力が不足しているなら、AI開発を支えるテスト基盤を先に整えます。 生成費用だけを下げ、後工程の確認や保守へ負担を移すと、安く作った分が運用費へ回る構造になりかねません。

数字に出ない摩擦も残ります。 レビューへの自信、割り込みの多さ、AIが生成した変更を説明できる感覚は、短い定点アンケートや振り返りで補います。 これはSPACEが活動量だけでなく、満足度、協働、効率を同時に見る理由とも重なります。

よくある五つの誤診断

第一の誤診断は、AIの利用率が低いから速くならないと考えることです。 利用率が低い事実は研修や権限設定の問題を示すことがありますが、リリースが遅い原因まで特定しません。 利用率を上げる施策と、待ち時間を減らす施策は分けて評価します。

第二の誤診断は、レビューが遅いからレビュアーを増員することです。 原因が巨大なプルリクエスト、担当者の偏り、仕様の未確定にあるなら、人数を増やしても同じ場所で止まります。 変更規模と停止理由を見てから、増員、当番制、小口化のどれが必要かを決めます。

第三の誤診断は、プルリクエスト数や生成行数の増加を生産性向上とみなすことです。 件数を評価へ結びつけると、変更を不自然に分割したり、不要なコードを増やしたりする動機が生まれます。 活動量は診断の補助にとどめ、個人評価には使いません。

第四の誤診断は、旧Four Keysのランクで他社や他チームと競わせることです。 現行のDORAは旧ランクを使っておらず、サービスの性質や規制、リリース経路が違えば妥当な頻度も変わります。 比較対象は、定義を固定した同一サービスの過去です。

第五の誤診断は、計測基盤を完成させてから改善を始めることです。 完全な自動集計を待たず、一つのサービスを手作業で標本調査すれば、長い待ち時間の候補は見つけられます。 自動化への投資は、その数字を継続して意思決定に使うと確認してからでも遅くありません。

打ち手を選ぶ順序

改善はカレンダーを三分割するのではなく、観測した制約に沿って進めます。

まず、事業上の優先度が高く、変更の流れを追えるサービスを一つ選びます。 AI導入の目的も、「開発者の利用率を上げる」ではなく、「顧客要望を本番へ届ける時間を短くし、変更失敗率を増やさない」のように、結果と安全性を対にして置きます。

次に、定義を固定して基準値を取ります。 DORA五指標に加え、実装、レビュー、仕様回答、承認、デプロイの各区間について、件数、中央値、p90、総待ち時間を記録します。 導入前の記録が残っていない場合は、取得できる履歴を使いつつ、比較できない範囲を明記します。

そのうえで、総待ち時間が最も大きい区間を一つ選びます。 レビュー待ちなら担当の自動割り当てや当番制、仕様待ちなら決定者と回答期限、承認待ちなら低リスク変更の権限委譲、デプロイ待ちなら手動工程の自動化を検討します。 品質指標が悪化している場合は、速度施策を追加する前にテスト、段階的リリース、ロールバック手順へ投資します。

施策後も、同じ定義と母集団で数字を取り直します。 対象区間の中央値が下がっても、p90や変更失敗率が悪化していれば、一部の変更へ負担を移しただけかもしれません。 待ち時間が縮み、品質側も悪化していないと確認できたら、次に大きい制約へ進みます。

誰がどの判断を持つか

計測を現場任せにすると、数字は取れても組織横断の詰まりを変えられません。 一方で、経営が個人のコミット数まで管理すると、指標が評価のために最適化されます。

経営層は、改善対象のサービス、事業成果、安全性の下限、投資枠を決めます。 CTOやVPoEは、レビュー担当の偏り、部門をまたぐ承認、リリース方針など、チームだけでは動かせない制約を引き取ります。 開発チームは、イベントの定義、変更の小口化、レビュー方法、失敗の記録を運用します。

この分担があると、「AIをもっと使ってください」という依頼を、誰がどの待ち時間を減らすのかという判断へ変えられます。

速くなった場所ではなく、待っている場所を見る

• DORA五指標は結果指標：デリバリの速さと不安定性は見えるが、レビューや仕様決定の詰まりまでは分からない
• 区間の時刻は診断指標：実装、レビュー、仕様回答、承認、デプロイを分け、件数、中央値、p90、総待ち時間で比べる
• 改善対象は一度に一つ：最も大きい待ち時間へ手を入れ、同じ品質指標を添えて前後を確認する
• 活動量は個人評価に使わない：生成行数やプルリクエスト数では、顧客へ届いた価値を測れない

AI導入で生産性が上がらないとき、追加すべきものがAIツールとは限りません。 二時間で終えた実装が四日目まで止まるなら、次の投資先は、その間にある意思決定と待ち行列です。