AI 時代、請負開発は限界に来ているのではないだろうか
はい、どうもこんにちは佐藤です！
AI のおかげで、開発の工数は大きく減りました。コードを書く時間だけで見れば、体感でもかなり速くなっていますよね。
となると、気になることがあります。今まで「どれだけ開発を圧縮できるか」の差分で儲けていた請負開発は、この先どうなるのでしょう？
受託の現場を見てきた私の意見では……。
請負開発は、限界に来ています！
これからは要件定義と同じように、開発フェーズも高単価の準委任契約で、アジャイルのスプリントのように進めないとリスクが高い。そう思っています。
その理由を書いていきますね！
AI で原価が下がる、は幻想だった
AI で開発できるんだから、原価は下がりまくりじゃん。
そう考えるのが自然ですよね。でも、現実は違います。
AI で早く開発できることは、発注側も知っているのです。
すると何が起きるか。
- これも必須機能
- あれも必須機能
- ついでにこれも
と、機能がどんどん詰め込まれていきます。浮いたはずの工数は、追加の機能で埋められてしまうのです。
受託側は「それがないと運用が回らない」と言われたら、対応せざるを得ません。特に、発注側の力が強い案件では断るのが難しく、回避策も取りづらくなります。
さらに最近は、若い PM・PL が増えてきました。顧客の担当者のほうが年上、という場面も多いですよね。年齢差があると、ビジネスライクに「それはできません」と拒否するのは難しいものです。
「明日までに必須です」と言われた現場
実際に、こんなやり取りがありました。
顧客「この機能を明日までに追加してください。必須です」
PL「いや、設計書に書いていないですし、それができるような作りにしていないですし、そんな短期間では無理です」
顧客「やってもらわないと業務回らないので（笑）」
……結果どうなったか。
現場のエンジニアが高稼働で、付け焼き刃の対応をすることになりました。
PL の言っていることは正論です。設計書に書いていない。そういう作りにしていない。期間も足りない。それでも、「業務が回らない」の一言で押し切られてしまうのです。
設計書は、もう契約書として効いていない
もともと設計書には、こういうことを起こさないための契約書としての側面がありました。
- 設計書に書かれていないことは、やってはいけない
- 設計書に書いてあることは、やらねばならない
これが請負の前提ですよね。完成させる範囲が決まっているから、完成に責任を持てる。範囲の外の要望は、追加の見積もりで受ける。
では、今の開発ではどうでしょうか？
ウォーターフォールの請負のはずが、気がついたら「伴走します」と言って、やんちゃアジャイルになっている。そんな案件、心当たりがありませんか？
受注側も、どうせそうなるのだからと、変更しやすいようなふんわりとした設計書を書くようになります。範囲が曖昧なら、なんでも詰め込める。そしてその負担を背負うのは、いつも現場です。
実際、契約の範囲を決めきれない要件定義フェーズは、準委任契約でやっている会社も多いでしょう。範囲が決まらないなら、完成責任の請負は成り立たない。開発フェーズも、もう同じ状態になっているのです。
コードは速くなっても、テストと影響調査は速くならない
AI でコードは早く書けるようになりました。
では、テストやレビュー、影響調査はどうでしょう？
詰め込まれた機能の分だけ、テストは増えます。既存の機能に影響していないかの調査も必要です。ここは、コードを書く速さほどは縮んでいません。
結果、現場は 36 協定ギリギリの労働にならざるを得ないのです。
健康やライフステージを犠牲にしてまで、やるのはおかしい。そう思いませんか？
残業の上限が現場を守る砦だという話は、月45時間の残業上限は、エンジニアと発注側の両方を守る砦だ で書きました。今回は、そもそも砦に頼らなくて済む契約の形を考えます。
開発フェーズも、高単価の準委任にする
開発フェーズでも、仕様はどんどん追加されて、対応せざるを得ない状態になります。
だったら、最初から準委任契約で、要件の整理、優先度の整理、実装、検証までやった方が良い。
ここで大事なのは「高単価」の部分です。
要件の整理が入るのだから、高単価の人材が入らないと太刀打ちできません。顧客の「必須です」を受け止めて、本当に必須なのか、今やるべきなのかを一緒に整理できる人が必要なのです。
普通の人月なら、開発だけを切り出して、あまり単価の高くないチームに投げることができていました。
以前 AI 時代にエンジニアが本気を出さないわけ で、「人月は時間を売る契約だから、効率化が報われない」と書きました。今回の準委任は、それとは別物です。
- これまでの人月: 決まった開発作業を、時間で売る
- 今回の準委任: 要件の整理から検証までを、判断できる人材ごと売る
売っているのは、作業の時間ではなく整理と判断なのです。
スプリントレビューで、OK の実績を積み重ねる
とはいえ、準委任にしただけでは足りません。範囲のない契約は、それはそれで好き放題やられてしまいますよね。
そこでスプリントです。
- スプリントごとに優先度を決める
- スプリントレビューを行う
- 受託会社のリソースの上限と、出した成果に対して OK をもらう
この OK の実績を積み重ねていかないと、好き放題やられてしまいます。
ポイントは、リソースの上限を毎回はっきりさせることです。「このスプリントで使える人と時間はこれだけです。その中で何を優先しますか？」と顧客に選んでもらう。新しい「必須です」が来たら、何かを後ろに回して入れる。
設計書が契約書として効かなくなった代わりに、スプリントレビューの OK が、範囲を区切る役目を果たすわけです。
まとめ
というわけで、AI 時代に請負開発はもう限界だよね！って話でした！
あ。正確には、範囲が決まらないなら、範囲を区切る仕組みごと契約を変えよう って感じですねっ。
AI で浮いた工数は、放っておけば機能の詰め込みで消えます。そのしわ寄せは、いつも現場のエンジニアの健康とライフステージに来ます。要件の整理ができる人材を高単価の準委任で入れて、スプリントごとに上限と成果を確かめ合う。それが、受託側が現場を守りながら AI の恩恵を受けるための形だと思います。
ぜひみなさんも、次の案件の契約形態を見直してみてください！