SIerのAI活用｜開発生産性を測る5指標

はじめに

「AIでコーディング時間が半分になりました」

開発部門の報告会で、この数字は目を引く。ところがPMは素直に喜べない。レビュー待ちは長くなり、仕様の確認も増え、結合テストでは手戻りが出ている。実装者の作業は速くなった。それでも、案件全体の納期はほとんど変わっていない。

SIerのAI活用で起きやすいのが、この局所最適である。ツールの利用回数や生成コード量は数えやすい。個人へのアンケートも取りやすい。だが、顧客が買っているのはプロンプトの回数ではない。合意した仕様を、求める品質と納期で届ける力だ。

IPAが整理した活用場面は、要件定義、議事録、プログラム開発、レビュー、テストまで広い。コード生成だけ測っても、開発全体への効果は分からない。要件から本番まで、同じ物差しで流れを見る必要がある。

SIerのAI活用で「削減時間」だけを追うと失敗する

生成AIの効果を「一作業にかかった分数」で測ること自体は悪くない。PoCの初期には、変化をつかみやすい指標だ。ただし、それを案件全体の生産性と呼ぶと話がずれる。

たとえば、AIが基本設計書の初稿を2時間から30分に縮めたとする。差は90分だ。ところが、要件との対応が曖昧でレビューが2回増えれば、PM、設計者、顧客担当者の時間を消費する。浮いた90分より、確認と修正に使った時間の方が長いかもしれない。

NTTデータの2025年の報告にも示唆がある。設計情報の復元では品質を評価できた一方、生産性向上は十分に検証できていない例が紹介されている。テスト項目の生成でも、長大な表をそのまま渡すと構造を正確に扱えない課題があったという。生成できたかと、工程が改善したかは分けて見なければならない。

測定前に、次の三つを固定する。

• 対象工程：要件定義、設計、実装、テストのどこか
• 比較対象：過去の類似案件、またはAIを使わない同種タスク
• 品質条件：レビュー合格、テスト合格、顧客受け入れなど

開発生産性を測る5つの指標

SIerのAI活用では、速さと品質を対にして測る。実務上は、要件、実装、レビュー、テスト、本番の五地点に一つずつ指標を置くと追いやすい。

1. 要件合意時間

要件定義で測るのは、文書の作成時間ではない。未決論点が登録されてから、顧客または業務責任者が判断するまでの時間である。

生成AIは議事録の整理や選択肢の列挙を速められる。だが、「誰が決めるか」が空欄なら合意は進まない。論点ごとに、決定者、期限、選択肢、影響範囲を記録する。平均値より中央値を見ると、一部の長期滞留に引っ張られにくい。

要件定義のヒアリングで確認したい7つの質問も、論点を早く見つけるために使える。質問数ではなく、未決事項が何日残ったかを測るのがポイントだ。

2. 変更リードタイム

実装工程では、AIがコードを書いていた時間だけでなく、着手からマージまでを測る。調査、実装、CI、レビュー待ち、修正をすべて含める。

AIコーディングで実装が速くなっても、大きな差分を一度に出せばレビューは重くなる。変更を小さく分け、同じ規模の変更同士で中央値を比べる。機能追加と障害修正を混ぜない。緊急対応も別集計にする。

NTTデータが示すAI駆動開発は、成果物を早く提示し、人の判断と改善のサイクルを速める点を重視している。ここで測るべきは、生成速度ではなく、そのサイクルが一周する時間である。

3. レビュー指摘の再発率

レビュー工数だけを減らす目標には注意がいる。確認を薄くすれば、数字だけは簡単に下がるからだ。代わりに、同種の指摘が観測期間中に再び出た割合を見る。

指摘を「命名」「認可」「例外処理」「性能」「仕様不一致」のように分類する。観測期間を4週間、判定単位を同一チームに固定する。そのうえで「過去に一度以上出た分類の指摘数」を全指摘数で割る。AIへ渡す開発ルールを直した後、同じ分類が減ったかを追えば、チームが学習資産を積めているか分かる。

レビューコメントをAIへ無条件に学習させるのは危ない。承認したルールだけを共有資産にする。

4. テスト初回合格率

AIでテストケースを増やすと、実行数は伸びる。けれど、似たケースを大量生成しただけでは品質は上がらない。初回実行で受け入れ条件を満たした割合を測る。

正常系、境界値、権限、異常系を分け、各群の母数を残す。テストを途中で削除した場合も記録する。分母が動くと、合格率は簡単に良く見えてしまう。

SIer向けRFPで提案を比較する7項目で触れた通り、成功指標と受け入れ条件は別物だ。業務成果が出たかとは別に、納品物が合格したかを測る。その線引きがあると、AIが生成したテストの責任範囲も明確になる。

5. 本番流出欠陥率

最後に、本番へ出た欠陥を変更件数で割る。AIを使った変更と使わなかった変更に印を付け、重大度も分ける。単純な件数だけでは、小さな表示崩れと情報漏えいにつながる不備が同じ一件になってしまう。

観測期間は案件に合わせる。リリース直後に利用が集中するサービスなら14日、月次処理なら少なくとも一周期を見る。障害件数が少ない小規模案件では、一件で率が大きく動く。率と実数を併記する。

この指標は、品質を後払いして速度を作っていないかを見る安全弁だ。NTTデータが公表した改善例には、別々の案件で、工期を5割短縮した例と約3倍の生産性を実現した例がある。ただし同社も、案件の複雑さやモデルで結果が変わり、一律には保証できないと説明している。自社の案件でも同じ慎重さが要る。

2週間で計測方法を動作確認する

最初から全案件へ共通目標を置く必要はない。小さな変更を6〜10件選び、2週間で計測漏れや定義のずれを見つける。この期間は効果判定ではなく、計測方法の動作確認とする。AIありとAIなしを同数にできなければ、直近の類似変更を仮の比較対象にする。

記録表は一枚にする。

AI利用率を成果指標から外すと会話が変わる。「もっと使って」ではなく、「要件合意が遅いのはなぜか」「同じ認可ミスが再発するのはなぜか」と聞ける。AIは目的ではなく、詰まりを解く選択肢になる。

効果判定は、計測方法を直した後に行う。少なくとも3スプリントまたは30件の変更を蓄積し、案件特性、担当者、仕様変更などAI以外の差も記録する。本番流出欠陥は14日や月次一周期など、先に決めた観測窓が閉じてから比較する。

一方、AI利用料、検索基盤、ルール整備、教育、レビュー時間は原価に含める。無料試用中の料金をゼロとして扱わない。本番展開後の費用で試算する。削減時間だけ足して、導入と確認の時間を引かない計算は避けたい。

案件横断で比較するときの3つの注意点

一つ目は、案件の難易度をそろえることだ。画面一枚の改修と、外部決済を含む変更は比べられない。影響ファイル数、外部連携数、非機能要件、担当者の経験などで層を分ける。

二つ目は、速さと品質を同じ表に載せることだ。変更リードタイムが20%縮んでも、本番流出欠陥が増えたなら成功とは言いにくい。テスト初回合格率と本番品質が維持されて初めて、速度改善として扱う。

三つ目は、平均値だけで経営判断しないことだ。一つの巨大案件が全体を歪める。中央値、母数、最大・最小を併記する。どの工程で効き、どの工程では効かなかったかも残す。

IPAのDX動向2026調査では、国内企業のAI導入は広がる一方、期待どおり以上の効果は限定的で、用途は業務効率化・迅速化が中心と報告されている。1,799社を対象にした調査だ。SIerが次へ進むには、「使った人数」から「顧客価値と品質を保って流れが速くなったか」へ物差しを変える必要がある。

SIerのAI活用は仕様と検証記録をつないで進める

五つの指標は、別々のダッシュボードに置くだけでは弱い。要件ID、変更、レビュー指摘、テスト結果、障害を一本につなぐ。どの要件で時間がかかり、どの変更で指摘が再発し、どの欠陥が本番へ出たかを追えるようにする。

ここで仕様書が効く。納品のために作る文書ではなく、AIと人が判断を共有する台帳として扱う。目的、受け入れ条件、例外、禁止事項、決定理由が構造化されていれば、AIの出力もレビュー結果も同じ基準で比べやすい。要件や受け入れ条件をAIが読める形で整理する際は、Kakusillのプロダクトページも参考にできる。

SIerのAI活用を始めるなら、ツールの全社契約より先に、一つの工程と一つの案件を選ぶ。そして五つの指標のうち、今取れるデータを確認する。取れない指標があれば、計測点を開発フローへ足す。2週間後に計測方法を直し、十分な件数がそろってから速さ、品質、原価を比べる。

Atsumellは、業務と要件の整理、AIが読める仕様の設計、開発フローへのAI組み込み、評価指標の設計まで支援している。「生成AIを何人が使ったか」から一歩進み、案件全体で効果を説明できる状態を一緒に作りたい。