「人類がソフトウェアの工数を正確に見積もるのは、もはや不可能である」

はじめに

まずこの話をするのにあたって「正しい見積り」という伝承を語らねばならない。

次の章は、筆者が観測してきた100社ほどの開発関連会社におけるトレンドを雑に集約したものなので、当然ながら観測者バイアスがかかっている。

したがって、ITエンジニアのみなさんご自身の体験とはだいぶ違う事もあるかもしれない。その点はご了承願いたい。

ところで、カンブリア爆発のように、ある事柄がきっかけて急激に世界が変わっていくことは産業界にもよくある。
たとえば蒸気機関の登場が産業革命を引き起こしたように。

また、システム開発にも古代と現代を区切るほどのエポックメイキングな出来事が一つあると思っている。

それは「GitHubの台頭」。

本論では、この古代のことを「前GitHub時代」と呼ぶことにする。

※厳密に言えばGitHub以外にも様々なソースコード共有サイトやリポジトリシステムは存在した。が、それらをコミュニティとパッケージャー運用システムまで内包した「文化を構築」できたのは唯一GitHubだけだと考えている。

前GitHub時代のシステム開発

類例をあげればきりがないし、たんなる老害トークになるので、現代と比較されうるポイントだけ簡単に述べる。

前GitHub時代のシステム開発では、「ライブラリ」と呼ばれるものは基本的に自社製のライブラリを指していた。

各ソフトウェア会社は自社製のライブラリを保有しているのが普通であり、エンジニアはその自社製のライブラリに精通している事が重要なスキルだった。お金のある企業はプロプライエタリなライブラリを、提供している会社から購入することもあった。

そうでなければ、ボタン一つ表示するのにも、自社でゼロからコーディングする必要があったのだ。

そして、プログラミング手法における責務範囲や命名規則、ドキュメントのフォーマットや粒度まで各社十人十色だった。

同じ言語を扱うプログラマーという仕事は、他社に行けばまるで違う仕事としか思えないほど、業務プロセスも、コーディングスタイルも、ライブラリも、何もかもが、各社特有の文化圏で独自進化したガラパゴス状態だったのだ。

GitHubの台頭

GitHubがこの世に及ぼした影響を述べ始めれば、おそらく一冊の本が書けるだろう。

なので今回は本題に関わる、限定的で、かつ決定的な影響だけを論じる。

GitHubというソースコードの文化的集約点の誕生により、集合知によるエンジニアリング技術の全体的向上をもたらし、実装ノウハウが、世界中で会社間を超えて交換・共有されるようになった。

つまり、車輪の再発明が行われなくなり、多彩で便利なライブラリが増え、それらを管理するパッケージマネージャが各処理系において提供され、実装方法やアーキテクチャはより良いものが模倣され、かつ淘汰されるようになった。

その結果、ITエンジニアは自身の解像度における問題にリソースを集中できるようになったわけだ。

システム開発の変質

GitHubがもたらした様々な影響は、実装手法だけではなく、ITエンジニアの雇用やプロジェクトマネジメントそのものにも大きなインパクトを与えた。

その最たるものが、ITエンジニアの仕事の質の変化である。

前GitHub時代のような決まりきった演繹的な実装作業よりも、帰納的あるいは探索的な「工数の予測が難しい」タスクのウェイトが、相対的に大きくなっていった。

正確に言うと、個人によって必要工数の差が激しいタスクが、プロジェクトの大半を占めるようになった。

つまり、工数の予測が難しいということは、いわゆる
「不確実性コーンの幅」
が爆発的に広がってしまうという現象をもたらしたのだ。

すなわち、何時間作業をすればこの機能ができる、という予測がどんどん難しくなっていったのが現代である。

「正確な見積り」という聖杯を求めて

では、「プロジェクト工学」的アプローチによってこの広がってしまったコーンを狭め、正確な見積りにより近づく事はできないだろうか？

もちろん、可能である。

たとえば個々のスキルを標準的な手段を元に常に計測し、進捗を定量的に計測することでプロジェクトへの影響を予測できる（かもしれない）

はたまた他で作ったことがあるプロジェクトとメンバーのスキルを参考にして工数を推測することができる（かもしれない）

事前に詳細な設計を行い、緻密な作業見積りを積み上げることで正確な工数を予測することができる（かもしれない）

そう。時間とお金をかければ、工数をそれなりに正確に見積ることは不可能ではない。

だが、その「がんばって予測した正確な見積り」は何を生み出すのか？

「正確な見積り」がどんな利益を生む？

多大な計測コストをかけて見積りを正確にすることに意味はあるんだろうか？

もちろんある、なぜなら正確な見積りこそが、SIerにとっては
「受託開発の価格を正しく決定する唯一の手段」
になるからだ。

事前の見積より、工数が1/10になったり10倍になったりするような危険があったら、とてもじゃないがビジネスとして成立しないのだ。

つまり受託開発というSIerのビジネスモデルが成立するには
「工数の見積りが正確である」
ということが必要不可欠になっている。

無論、SIerだけの立場で言えば、不確実性コーンが安全圏内に収まる係数まで工数を倍掛けした値段を見積りとして出して、発注者に請求すれば良い。

だが、それは発注者にすべてのリスクを押し付ける取引は、はたしてフェアなんだろうか？

「正当な対価を要求する」のは、サステナブルなビジネスを続けるために必要なのは明白だ。

正確な見積にはコストがかかる。
見積もれなければSIerは、高いリスクを負ってしまう。
そのリスクを解消するための見積りコストはすべて発注者が支払う。

これが
「多くのシステム開発、すなわちウォーターフォール開発の現状」
なのだ。

ウォーターフォールに利点はあるのか？

もちろんある。

たとえば、「作ったことのあるもの」「価値の検証が不要なもの」については、正確な見積が可能だろう。
これらは、ウォーターフォールの方が良いし、実際早く完成するだろう。

しかし「事業会社にとってのソフトウェアの価値」という観点で見ると、事前に価値がわかっているシステムというのは、それが完成した時点で（むしろ作る前の段階で）コモディティ化しているとも言える。

もちろん、人のビジネスをコピーして数十倍の資本で叩き潰すというスタイルは手堅いビジネスだ。

そういうった現場においてはコモデティ化したプロダクトを投入するのは、ビジネス観点においては問題はなにもない。

ITエンジニアとして、そんな仕事が面白いかは別の話だが。

新規事業を行う人々にとってのソフトウェアの価値とは

散々ウォータフォール型システム開発の利点と欠点を論ったところで、現代の潮流を読んでみよう。

現代において、新規事業を行おうとしてるスタートアップ、メガベンチャー、大手企業のすべての新規事業部門は「新しいこと」をやりたがっている。

つまり、それらは、すべからく
「事前に価値のわからないソフトウェア」
を必要としているのだ。

しかしながら　　　　　　　　　　　　　　　
「価値がわからないソフトウェアを正確に見積もろうとすればするほど見積りコストが指数級数的に増える」
　　　　　　　　　　　　　　　↓
「SI受託開発方式では受発注者双方の見積りコストが膨大になる。それを怠ると、双方にとってギャンブルになる」
　　　　　　　　　　　　　　　
言い方を変えれば
「事前に価値のわからないソフトウェア」
というものは、SIerにとってみると
「自身のビジネスモデルを否定しうる存在」
になってしまっているのだ。

大手SIerに代表される、現代日本の（大多数の）受託開発ソフトウェア産業構造においては、そもそも価値のわからないソフトウェアを製造したいという要求に答えるのは難しい。

まとめ

GitHubがもたらしたプログラミング産業革命というべき単純作業の駆逐が、ウォーターフォール開発における大前提となる正しい見積りを、現実的に不可能なまでにコストを増大させてしまった。

そして
「簡単に見積もれるようなソフトウェアにはそもそもビジネス価値がない」

すなわち

「人類がソフトウェアの工数を正確に見積もるのは、もはや不可能である」

我々は、そういう世界に生きている。

おわりに

もはや工数を正確に見積もれなくなった人類に、救いの手は差し伸べられるのだろうか？

次回「絶望の先にあるもの」

Be Agile!