外注は費用も意思疎通もコストが高い
最近はClaude Codeをはじめとした生成AIコーディングが浸透しつつあり、世の中的にも外注するよりも、自社内で開発したほうが当然安上がりという結論に至り、SESでは案件獲得が難しくなってきていると風の噂で聞く。
ふと前職のことを思い出してみると、まだそんな便利なものが出てくる前の話だったので、工数が足りなければしばしば外注に開発を依頼していた。私の所属していた部門は万年赤字であり、経営層からは猛省しろと言われ続けていたが、それでもなぜか予算だけはつく謎の体制だったので、上司も躊躇うことなく外注に踏み切っていた。
しかし、外注は法令による守りが強すぎることと、それがなかったとしても意思疎通のコストが大きいことがボトルネックだ。私もいくつかの案件で外注を扱ったが、これがまた骨の折れる話であった。技術的に怪しい部分があったし、取適法(下請法)も面倒で、これくらいなら自分でやったほうが楽だと感じた。
外注も金儲けをするというエゴがあるので言われたとおりに「はいそうですか」で動かない部分があるし、にも関わらず自分が期待しているほどの技術レベルにないこともある。お互い大人の態度で臨んではいるものの、それでも、それだからか、期待通りにはならない。ここでは私が悔しい思いをしたできごとをふたつほど挙げる。
ケース1
これまでお願いしていた外注先が履行不良を起こしてしまったので、社内でも別の会社を開拓しないとマズいという話になった。しばらくして上司がなかなか良さそうな開発会社を見つけてきたので、私が担当する案件でも採用することになったのだが、向こうからの提案としては何やら聞いたことのないJavaのライブラリとデータベースドライバを使うらしい。嫌な予感がした。
ライブラリはその会社独自の秘伝のタレ的なもので、強い癖はあったが外部依存するものではなかったのでよしとした。いっぽうデータベースドライバはこれまた別の個人が開発しているもので、Gitのコミットログを確認すると最終更新は3年前ときた。やめてくれと思うと同時にむしろどうやって見つけてくるんだこんなものと感心さえする。
さすがに気になったので先方にデータベースドライバをもっと一般的に使われているものに変えられないか？と打診をしてみた。すると「できなくはないですが、この納期には間に合いません」と事実上のお断りをされてしまった。どうせ今後自分が改修することはなさそうだし、ここで張り合っても仕方ないし、あまり言うと下請法が面倒なのでやめておいた。年下のガキに指示されるのも嫌かもしれないし。
ケース2
また別の会社を使ったときの話である。この会社は母体がそこそこ大きく、ちゃんとした要件定義書やシーケンス図、テスト仕様書を提出してきた。誰が見るんだこんなもの。検収しろと言われてもあまりにも膨大で人間が見て楽しいものでもないので斜め読みである。AIスロップが問題視される今の状況と似たか寄ったかである。この手の書類はモノとしてあることが大事なのだ。多分。
要件定義書の中にはデータベースのテーブル定義もあったのだが、私がTEXT型(可変長)だと考えていた部分がVARCHAR型(固定長)で定義されていた。ここはなんでVARCHARなんですか？と打ち合わせで聞くと、固定長でないとパフォーマンスがモゴモゴ…、最大文字数が決まっていないとアプリケーションレイヤとの整合性がモゴモゴ…と言う。このプロジェクトの規模とロジックでそんなわけがあるかい！
やんわりと「あとで改修が楽なのでTEXTで」とお願いすると、先方のプロジェクトリーダーが早口でなんやかんや捲し立てる。私の上司もその辺にしといたれ、みたいな顔をする。どうせ今後自分が改修することはなさそうだし、ここで張り合っても仕方ないし、あまり言うと下請法が面倒なのでやめておいた。年下のガキに指示されるのも嫌かもしれないし。
受託開発に厳しい世界に
ここにきて現れた生成AIコーディングはこれらの問題を同時に解決してくれる。ドメインエキスパートに要件を伝えさせて、ソフトウェアエンジニアが設計方針を指示すれば、よりよい方法で提案から実装までできてしまう。法律を盾に言い訳をすることもないし、追加改修のための爆弾を仕込むこともない。塵も積もればではあるが、生成AIコーディング費用は微々たるものである。
逆に受託開発側から見れば、これからは生成AIコーディングに勝る価値提供をしていかなければならない。ぱっと思いつく限りでは、AIに嫌悪感を抱いている会社に営業をかける、専門的なノウハウを提供する、人間の高度な洞察力による提案等々がある。やり方の工夫はすぐにはできるが能力の底上げは非常に難しい。そんなふうに誤魔化している間にも代替されていくようにも感じられる。