AI駆動開発で、受託開発の見積りはどう変わるか

「AIを使っているので安くできます」は、それ単体では見積りの根拠になりません。 どの工程がどれだけ速くなり、どの工程は変わらないのか。そこを分解できて初めて、価格の話ができます。

速くなる工程と、変わらない工程

受託開発の工程を粗く分けると、要件定義・設計・実装・テスト・移行・定着支援になります。 このうちAI駆動開発で明確に速くなるのは実装とテスト、そしてドキュメント作成です。 逆に、ほとんど変わらないのが要件定義と定着支援——つまり人と向き合う工程です。

• 速くなる：実装、テストコード、ドキュメント、リファクタリング、調査・検証
• やや速くなる：設計（叩き台の生成は速いが、意思決定は人）
• 変わらない：要件定義、合意形成、業務設計、定着支援

ここを混ぜて「全体が半分になります」と言ってしまうと、要件定義や定着支援の工数が足りなくなり、 結局「安かったが使われないシステム」ができあがります。

人月から離れるほど、設計の責任が重くなる

実装が速くなると、相対的に設計の巧拙が結果を大きく左右するようになります。 作り直しのコストが下がるぶん、方向を間違えたときの損失は小さくなりますが、 「作れてしまう」からこそ、作らない判断が効きにくくなる。

速く作れることの価値は、速く捨てられることとセットで初めて成立します。

私たちが見積り時に必ず確認するのは、標準機能や既製品で組み切れる範囲がどこまでかという点です。 作らずに済むものを作らない判断は、AIを使っても代替できません。

品質を落とさずに価格を下げる

低コストは、品質を落とすことでは実現しません。大規模・高難易度の基幹系で培った設計基準を保ったまま、 実装・テスト・ドキュメントの生産性でコストを下げる。安さの理由を、品質以外に持つということです。

具体的には、テストコードとドキュメントを「余裕があれば書くもの」から「必ず伴うもの」に変えられます。 これまでコスト都合で削られてきた部分が標準装備になる、というのがAI駆動開発の実務的な効き方です。