AI 2026.07.29

AI未導入の保守開発プロジェクトにおいて仕様駆動開発（SDD）を導入して原価25％減らした話

1. はじめに

私のチームでは、お客様（発注元）の要望をすでに稼働しているシステムに落とし込む開発をしています。
いわゆる、「保守改善」「派生開発」と呼ばれる仕事になります。
開発プロセスはアジャイルで、毎スプリント一定の品質／生産性を満たしています。

こうした状況のなかで、自社からも発注元からも「AIで開発を効率化し、原価を下げたい。」という声が上がるようになりました。
単にAIツールを導入して各工程の作業を速くするだけでは劇的な改善は見込めないと考え、
開発プロセスそのものを仕様駆動開発（SDD）ベースに組み替え、実際のプロジェクトで試してみました。
その結果、品質と生産性の水準を維持したまま、　メンバー数を20％／原価を25％減らす　ことができました。

本記事では、そのために何を変えたのか、原価削減以外に得られたもの、AI導入のメリット／デメリットについて、現場で使っている仕組みを交えながら書いていきます。

2. 今までの開発プロセス（AIなし）

AI前提で構築し直したプロセスを説明する前に、今まで行っていた開発プロセスの整理、および課題を以下に整理します。

大まかに図解すると、以下の通りです。

今までの開発プロセスでは、1要件（PBI）ごとにV字モデルに沿って全て人の手で作業を行っています。
SEが要件定義／基本設計を行い、PGは詳細設計／実装／単体試験を実施しています。
基本設計から単体試験まで各フェーズの出口にレビューがあり、上流はPL、下流はTECリードが成果物を確認していました。
※要件定義は、発注元への説明を持ってレビューとしています。（発注元への説明時にはPLも同席。）

本プロセスでは、　レビュー依頼がPL／TECリードに集中する　ことが課題になっていました。
そのため、以下の問題が発生していました。

レビュアーが回らなくなると途端に進捗管理が複雑になり、作業の入れ替え・差し戻しが増える
そもそもPLの本当の仕事はレビューではないが、それに多くの時間を使ってしまい、全体計画やリスク課題管理等に時間を使えない
TECリードによるレビューは、作業量的にプログラムの書き方のチェックしかできず、要件誤りまで指摘できていない

その結果、案件を回せる規模は　レビュアーが回せる量　で頭打ちになり、案件規模を増やすには人数（特にPL）を比例して増やすしかありませんでした。
さらに、PLには管理業務に加えてレビューも求められるため、プレイングマネージャー（レビューも実施する）でなければプロジェクトが回らない、という人材面の制約もありました。

3. 仕様駆動開発（AIあり）

旧プロセスから、以下の変更を行い新しいプロセス（仕様駆動開発）に変えました。

AIによる一部作業実施
フェーズとしての詳細設計の廃止
役割としてのPG撤廃

※ここでいう仕様駆動開発は、基本設計書とAI用ルールを仕様として実装・テストを進める進め方です。

要件定義／基本設計の実施については、今までのプロセスと変更はありません。ただし、設計書のレビューについてはAIが実施します。

詳細設計のフェーズは廃止しました。元々、詳細設計は実装力の低いメンバーが誤った箇所／内容で実装しないかを実装前に確認するために実施していました。AIは実装力が高いため、わざわざ詳細設計を実施する必要がなくなりました。（必要あれば、AIに詳細設計を書かせることも可能です。）

AIの実装をSEがレビューする運用にしています。ただし、今までTECリードが行っていたアーキテクト的なレビューではなく、要件を満たす実装になっているかの確認を行っています。そのため、実装レビューを行う上で高度なプログラム知識が不要になり、TECリードの役割もなくなりました。（アーキ的な疑問点が出てきても、AIに確認すれば解答ももらえます。）

単体試験は、テストケース作成とテスト実施にフェーズを分けました。テストケース作成はAIによって実施し、そのテストケースを元に人がテストを実施します。テストを実施するなかで、不足点等の洗い出しも併せて行っていきます。（レビューとテスト実施を同時に行います。）

4. チーム体制の変化と開発原価

仕様駆動開発に開発プロセスを変更することで、チーム体制そのものにも変化が発生します。

契約上10人月の案件の場合、平均的なメンバー構成（原価は一例）は以下の通りでした。

PLがレビューをする必要がなくなったため、メンバー数換算でいうと0.5人に減少しています。

SEは逆に増えています。AIによる実装／テストケース作成の実施およびそのレビューを行っているためです。

PGはなくなり、テスターに置き換わっています。テスターの数は、PGに比べてテスト実施だけなので減っています。

新しい役割として、「AI調整」が生まれています。AIによる実装や設計書レビュー等が一定のルールを元に行われるようにSKILLファイルやrulesファイルを修正する役割です。

仕様駆動開発にすることで、

　メンバー数：20％減

　原価：25％減

を達成できています。

5. メリット／デメリット

仕様駆動開発におけるメリットについては、原価削減に加えて、次のようなものも得られました。
しかし、デメリットも存在しています。

デメリットの2、3について、もう少し補足します。

デメリット2　判断作業の増加による心理的コスト増加

AIによる成果物の正誤判断を、各SEが自身で行う必要があります。今までは、最終的な正誤判断をPLが担っていましたが、今後はその責任が各SE個人のみに移ります。人によっては、その心理的な重さを負担に感じる恐れがあります。経験が伴わない状態でAIが出力した知識／技術を納品する、今までの働き方にない負担なるのではないかと。
⇨だからこそ、PLの空いた工数の使い方が重要になります。今までの採点型レビューではなく、SEの不安点を一緒に考える並走型相談を実施していきます。並走型相談を通し、各SEがPLと同じ判断軸を持てるようになるのではないかとも考えています。

デメリット③　判断作業の増加による心理的コスト増加

受託開発の現場では、これまでおおよそ次のような階段が想定されることが多かったと思います。（年数は目安）
　　PG（3〜5年）⇨ SE（5〜8年）⇨ PL（5〜8年）⇨ PM ⇨ 管理職
ですが、PGの作業がAIに置き換わっているため、新人はテスターから仕事を始めていくことになります。「とりあえずプログラム書いて」といった仕事がなくなるため、SEの土台となる知識を、PGとしての実務を通して学ぶことができない恐れがあります。
　⇨ただし、これについてはデメリットだけではなく、早期にSE／PLへの道が開けるという大きなメリットもあると考えています。組織として、どう若手を育成していくかが重要になりそうです。（AI導入で浮いた工数・原価を、どこまで／どのように育成に割くか。）

デメリットとしてあげていますが、上手く対応することでメリットに反転する可能性もあると考えています。

6. さいごに

保守改善・派生開発をアジャイルで回す現場で、開発プロセスを仕様駆動開発（SDD）ベースに組み替えました。
品質と生産性の水準を維持したまま、メンバー数20％・原価25％の削減を達成できたのが、今回の一番の成果です。
もともと粒度の細かい基本設計書——ウォーターフォール型の設計書に近い形式——を作成していたこともあり、SDD への移行自体は比較的スムーズでした。

ただし、現状は基本設計書を仕様の中心に据えており、SPEC ファイルを前提とした SDD の理想形とはまだ距離があります。
要件定義からの AI 作成や SKILL／rules の整備、若手のキャリアパスなど、「5. メリット／デメリット」で触れた課題への対応もこれからです。

それでも、レビュー集中という構造的なボトルネックを外し、プロセスごと変えた効果ははっきり出ました。
利益面の改善はもちろんですが、個人的に大きかったのは　SE増加による発注元への直接貢献です。
原価削減だけでなく、お客様（発注元）と直接向き合えるメンバーを増やせた点も大きいと感じています。

新規案件の受注拡大にとどまらず、　金銭面　だけでなく　人が生み出す価値　として、メンバー一人ひとりがお客様に直接貢献できる——そう思っています。