システム開発プロジェクトでは通常、事前に「何を作るか」を検討する。この作業を一般に「規模見積もり（Sizing）」と呼び、その結果が成果物スコープとなる。規模の単位はファンクションポイント（FP）やステップ数（LOC：Line of Code）、ユースケースポイントなどだ。しかし最近、この「規模見積もり」が消えてしまうのではないかと、危機感を募らせている。

　なぜこんなことを思うようになったのか。それは、クラウドサービスを使った開発や、アジャイル開発が広がりを見せているからだ。これらはスピード重視の開発だけに、作りながら実装すべき機能を詰めていくことが多い。つまり、何を作るかという規模見積もりに相当する作業を、工程の中に組み込んでいるとも言える。

　「それならそれでいいではないか」と思う人がいるかもしれない。実際あるベテランのプロジェクトマネジャーは「何を作るかを考えるのが上流工程の役割。要求があいまいな中で事前に成果物のスコープを決めるなど困難だ」と話す。動くシステムをユーザーに見せながら必要な機能を詰めていく方が、よほど現実的だという主張である。

　確かにそうかもしれない。結果的にその方が速く開発できることも多い。ただし、この考え方は一方で大きな危険性をはらんでいると思う。

作ってみなければ分からない怖さ

　誤解しないでほしいのは、記者は決して「プロジェクトの中で機能を詰めていくこと」を否定しているわけではない。問題視するのは「規模見積もりを全くせずにプロジェクトに突入する危険性」である。過去の多くの取材を通じて、成果物スコープをほとんど見積もらずにプロジェクトを進めると、大きく二つの問題が発生する恐れがあると考えている。

　一つは、プロジェクトがコントロール不能に陥る問題だ。規模見積もりの結果である成果物スコープは、工数の算出につながり、それが期間やコストの見積もりのインプットとなる。つまり成果物スコープがないと、プロジェクトの計画値のほぼすべてが根拠の乏しいものになってしまう。計画値がブレれば、プロジェクトのコントロールは困難を極める。

　実際、日経SYSTEMSでは現在、「失敗プロジェクト徹底調査」を実施中だ。途中結果でも、見積もりの不備によるプロジェクトの失敗が、回答者の声で多く寄せられた。

　もう一つの問題は、規模見積もりが実質的に消えることで、準委任契約が広がる可能性があることだ。以前はプロジェクトの上流工程のみに準委任契約が適用され、後工程は請負契約となることが多かった。それが最近は“作っては見直す”というアジャイル開発において、全工程を準委任契約で進めるケースが少なくないようだ。

　準委任契約は、ユーザー企業にプロジェクトのリスクが付くことを意味する。極端に言えば、ベンダーがユーザーに対して「作ってみなければいくらかかるか分からない」と突き付けているようなものだ。ベンダーにとっては事前に規模見積もりをしないだけに、何を作るのかが不透明で、準委任契約をせざるを得ない事情がある。かかった分へのコストが保障される契約なので、ベンダー側が生産性向上施策を積極的に取りづらく、業界発展の妨げにもなりかねない。