Unmute Systems Blog

どうやって工数の根拠を説明するか

受託開発ならクライアントへ、プロダクト開発なら役員へ、開発工数を説明しなければならないことがある。

AI-coding になった場合、彼らからは明らかに「いままでより工数が圧縮できる」という期待を向けられる。受託開発であれば100万円の案件が30万円になる、プロダクト開発であればリードタイムが1ヶ月から1週間になる、といった肌感だろうか？

Tech team の立場からは、このとき単にサブシステムや機能の量から積み上げただけの工数見積もりでは期待に答えられないし、そもそも正確ではない。

足場から考えてみる

分解すると、ざっくり以下のようになる

タスク複雑度
- 確実性の高い部分の実装量
- 不確実性
  - 技術的不確実性(=偶発的な複雑さ)
  - ドメイン不確実性(=本質的な複雑さ)
必須の工程
- 検証、統合
リソース
- 開発者の人数 * 単価
- 技術的ケイパビリティ(習得・人材採用リードタイムの有無)

従来の総開発費はこう定義できる:

総開発費 = 開発者単価 \cdot 人数 \cdot 時間的工数

時間的工数はこんな感じでモデル化できそう:

時間的工数 = 不確実性解消 + \frac{実装量}{人数 \cdot スキル} + \frac{検証や統合の量}{人数 \cdot スキル \cdot 自動化}

代入すると、

\begin{aligned} 総開発費 &= 開発者単価 \cdot 人数 \cdot \left(不確実性解消 + \frac{実装量}{人数 \cdot スキル} + \frac{検証や統合の量}{人数 \cdot スキル \cdot 自動化}\right) \\ &= 開発者単価 \cdot 人数 \cdot 不確実性解消 + \frac{開発者単価 \cdot 実装量}{スキル} + \frac{検証や統合の量}{スキル \cdot 自動化} \end{aligned}

従来の IT コンサルなら、ざっとこんな読み方をしただろう

第1項( $開発者単価 \cdot 人数 \cdot 不確実性解消$ $開発者単価 \cdot 人数 \cdot 不確実性解消$ ):
- “人月の神話”で論じられているのはここで、開発者を増やしても不確実性解消には寄与しないと解釈できる。
- しかし、後述の第2項のほうが支配的だという想定もあり、見積もりにくい不確実性解消のコストは従来、曖昧にされていた。だから要件定義までの上流工程が厚かったり、実装フェイズのバッファが多かったりした。
第2項( $\frac{開発者単価 \cdot 実装量}{スキル}$ $\frac{開発者単価 \cdot 実装量}{スキル}$ ):
- ここがプロジェクトの支配的要因になると考えられている。実装は線形に進捗するものと想定しており、規模に対して人と時間をあてると予測しやすい形で完了できる。
第3項( $\frac{検証や統合の量}{スキル \cdot 自動化}$ $\frac{検証や統合の量}{スキル \cdot 自動化}$ ):
- 第2項に内包されるか、CI/CDの自動化度が高いチームでは無視できる項として扱われてきた。実装速度と検証速度が釣り合っていれば、これは支配項にならない。

しかし AI 時代での読み方では支配的要素が大きく変わる

第1項( $開発者単価 \cdot 人数 \cdot 不確実性解消$ $開発者単価 \cdot 人数 \cdot 不確実性解消$ ):
- 要件定義不足だったりアジャイル的にゴールを探る形のプロジェクト、つまりドメイン不確実性が高い領域は AI 導入で解決しづらい。
第2項( $\frac{開発者単価 \cdot 実装量}{スキル}$ $\frac{開発者単価 \cdot 実装量}{スキル}$ ):
- AIにより実装量は極小に、個人のスキルは極大にでき、第2項自体をコストにしなくてよくなってくる
第3項( $\frac{検証や統合の量}{スキル \cdot 自動化}$ $\frac{検証や統合の量}{スキル \cdot 自動化}$ ):
- 新たな支配項になる。複数の研究でAI によってレビュー、デバッグのコストが増大したと示されている。さらなる自動化あるいは人的投資で分母を増やさなければ、工数は従来より増えるかもしれない

極度に単純化すればこうなる:

\begin{aligned} 総開発費 &= 開発者単価 \cdot 人数 \cdot 議論の時間 + \text{わずかなAIオペレーション} + 検証や統合への投資 \end{aligned}

つまり、AI時代で何が削減されるの？新しい付加価値はあるの？

削減できないこと

要件定義フェイズ、ドメインに関する議論
検証・統合工程。むしろコストが増える

ここをAI Slopにしてはいけない。AIはこの時間の圧縮に使うのではなく、議論や理解の精度を上げるため、検証・統合の自動化のために使うべきだ。

削減できること

モジュールを多く作るための開発者の数
固有技術のエキスパートの採用コスト
実装フェイズの工数

コスト削減以外の新しい価値

不確実性の除去、特に本質的複雑さと言われるドメイン(ビジネス価値に直結する概念モデル)の確立に集中しやすい。
決まった要件に対しての開発リードタイムが速く、方針の変更に柔軟である

従来は、実装からリリースまでのリードタイムを考慮しながら経営戦略も並走していたため、ドメインのモデリングをある程度で妥協するか、ロードマップ策定時点でビジネスに対する潜在的遅延が生じていた可能性がある。

ケーススタディ

例) 製造業の社内稟議の電子化

クライアント「以前、他社見積もりで600万円だったのですが、AI を使って200万円でお願いできますか」

と、言われたらを想定してみる。提案資料ではこうしてみよう。単純化するために、日数＝単価とする。

	従来型開発	AI駆動開発
要件定義	3週間	4週間(↑増やす)
実装	10週間	3週間
検証・統合	3週間	3週間(増えないよう、事前投資)
合計	16週間 / 600万円	10週間 / 375万円

実装は大幅に短縮できるが、要件定義は縮まらないことを説明する。むしろ、業務改善に本質的に関わっていくことで別の価値を説明しつつ金額を下げすぎない方向に持っていきたい。

また、検証・統合はプロジェクト横断でワークフローを作り工数が増えないようにしなければクライアントの期待通りの予算削減はできず、トータルの納期も単価も増える可能性すらあることに注意。

どのような説明ができるようになるか

受託開発の場合

おそらく開発会社というよりは業務改善コンサルに看板を寄せていったほうがよい

まずは、ひとつの開発フェーズのなかで、存在する不確実性、そうでない実装量、検証統合コストの合意を取る
AI 導入で削減できる部分は実装フェイズの期間・人数に限定される
ドメイン設計の質がクライアントやプロダクトの競争優位に直結することを説明し、議論の時間とイテレーションサイクルの回数を従来の開発プロセスより多く取れることを付加価値として訴求する。上の議論の通り600万円を200万円にすることは本質的にできないため、600万円の中身をより競争優位につながる活動に組み替えられるという提案になる。

プロダクト開発の場合

VPoE, CTO レベルに以下のような提言が必要かもしれない。

人

複雑さの規模に対して線形で外注で開発エンジニアの数を増やしてはいけない
複雑さへの対処には、ドメイン設計のスペシャリスト、FDE(フォワードデプロイドエンジニア)などを優先的にアサイン
一方で、予測可能な実装量に対しては AI オペレーターとしての低コストなエンジニアを集める

時間

機能の量をもとにしたボトムアップでの工数見積もりはもはや意味が無い
ドメインを熟議する期間のウィンドウを決めるなど、モデリングがどれくらいかかるのかを基準に計画する

運用

現代的な開発ツール、CI/CD文脈からすると、スプリント計画のような儀式的なスクラム手法は形骸化していることが多い。ドメインエキスパートが、意思決定者の直下でビジネス戦略を考慮して自律的にリリースまで行う体制を作り、本質的な高速イテレーションをすること

結論

AI では思ったより安くならない。一方で予算配分が大きく変わる。クライアントや役員が期待する AI のメリットとはギャップがある。

ポジティブな面ではドメイン設計により時間を割くことができる。また方針変更のコストが下がった
ネガティブな面で検証・統合の時間が増えるリスクがある。チームのレビュースキルや自動化への投資を行う必要がある

AIで開発工数の何が圧縮されるか