ソフトウェアの開発には時間がかかる。技術の進歩はあるし、ビジネス環境の変化のスピードも早いから以前に比べたら短期間にシステムを作れるようになったけど、それでも一朝一夕でソフトウェアは作れない。
例えば、完成するまでに(最初の見込みでは)12ヶ月の作業期間が必要なソフトウェアがあるとする。費用は普通に考えると完成して引き渡されたタイミングで支払われる。しかし、開発が終了するまでの12ヶ月に一度も支払いが行われないと、開発を請け負った会社は少し困ってしまう。なぜなら作業者には月々の給料を払わなければならないからだ。
そこで、適当な作業の区切りで何回かに分けて支払いをしてもらうようにする。そうすれば、資金繰りの問題は解消される。ここまでは特に問題はないのだけれども、中間支払いのことを「分割納品」とか「中間納品」と呼ぶと、悪夢が始まる。
建築の場合
じつは建築とソフトウェアの構築の違いを知りたいと考えて、家を建ててみた。建売りではなく注文建築で、要件定義から基本設計、詳細設計、構築と進むウォーターフォール型のプロセスである。実際にプロジェクトに着手してから、約1年半の工期の間には、中間支払いをする必要があった。設計段階から施工中まで何回かの支払いをして、最終段階で残金と仕様変更などの精算をした。支払額は最初から、全体金額をどのような割合で、どのポイントで分割払いするかが決めてあって、それに従っていった。
この話は私の個人的な体験だけれども、合理的だと思う。ソフトウェア開発でも同じようにすればいいと思っている。
分割納品(中間納品)の問題の個人的考察
ソフトウェアの開発で中間支払いをする際に、ついうっかり分割納品(中間納品)をすることにしてしまうと、いろいろな問題が発生する。そもそも、ウォーターフォール型の開発プロセスを取っていたとしても、本来は開発途中で「納品できる完成したもの」は無いはずだ。具体的にいくつかのパターンについて考察してみる。
設計工程の切れ目
何らかの設計工程(外部設計・基本設計、内部設計・詳細設計と呼び方はいろいろある)が完了した際には設計ドキュメント(設計書)が作られているので、一見するとこの作成した設計ドキュメントを分割納品(中間納品)できるような気がする。しかし、実際にはソフトウェアの設計行為は、プログラミングが完了するまで行われる。これは以前にも書いたとおりだが、
設計は指針であって、指図ではない
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
なのである。
納品という呼び方をしてしまうと、自然と「完成品」を求められてしまう。しかし実際には、ドキュメントが完成するのは、稼動するソフトウェアが完成したときと一緒である。
ちなみに、経済産業省「情報システム信頼性向上のための取引慣行・契約に関する研究会」最終報告などを見ると外部設計完了時点では納品行為を想定、それ以降では分割した形は想定していないようである。また、外部設計完了時点の納品物(設計書)については、
- 要件定義書及び第○条所定の外部設計検討会での決定事項との不一致又は論理的誤りがある場合を瑕疵とする
- 瑕疵がユーザの指示や提供した資料等に起因する場合にはベンダは担保責任を負わない
- ベンダが資料等又はユーザの指示が不適当であることを知って指摘しない場合には担保責任を免れない
となっている。
まとめ
- 中間納品はやめておこう
- どうしても中間納品するなら、外部設計の終了タイミングか、何らかのテスト工程が終わったタイミングで