勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

ソフトウェア開発の分解能

ソフトウェアの開発には時間がかかる。技術の進歩はあるし、ビジネス環境の変化のスピードも早いから以前に比べたら短期間にシステムを作れるようになったけど、それでも一朝一夕でソフトウェアは作れない。

例えば、完成するまでに(最初の見込みでは)12ヶ月の作業期間が必要なソフトウェアがあるとする。費用は普通に考えると完成して引き渡されたタイミングで支払われる。しかし、開発が終了するまでの12ヶ月に一度も支払いが行われないと、開発を請け負った会社は少し困ってしまう。なぜなら作業者には月々の給料を払わなければならないからだ。

そこで、適当な作業の区切りで何回かに分けて支払いをしてもらうようにする。そうすれば、資金繰りの問題は解消される。ここまでは特に問題はないのだけれども、中間支払いのことを「分割納品」とか「中間納品」と呼ぶと、悪夢が始まる。

建築の場合

じつは建築とソフトウェアの構築の違いを知りたいと考えて、家を建ててみた。建売りではなく注文建築で、要件定義から基本設計、詳細設計、構築と進むウォーターフォール型のプロセスである。実際にプロジェクトに着手してから、約1年半の工期の間には、中間支払いをする必要があった。設計段階から施工中まで何回かの支払いをして、最終段階で残金と仕様変更などの精算をした。支払額は最初から、全体金額をどのような割合で、どのポイントで分割払いするかが決めてあって、それに従っていった。

この話は私の個人的な体験だけれども、合理的だと思う。ソフトウェア開発でも同じようにすればいいと思っている。

分割納品(中間納品)の問題の個人的考察

ソフトウェアの開発で中間支払いをする際に、ついうっかり分割納品(中間納品)をすることにしてしまうと、いろいろな問題が発生する。そもそも、ウォーターフォール型の開発プロセスを取っていたとしても、本来は開発途中で「納品できる完成したもの」は無いはずだ。具体的にいくつかのパターンについて考察してみる。

設計工程の切れ目

何らかの設計工程(外部設計・基本設計、内部設計・詳細設計と呼び方はいろいろある)が完了した際には設計ドキュメント(設計書)が作られているので、一見するとこの作成した設計ドキュメントを分割納品(中間納品)できるような気がする。しかし、実際にはソフトウェアの設計行為は、プログラミングが完了するまで行われる。これは以前にも書いたとおりだが、

設計は指針であって、指図ではない
アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

なのである。

納品という呼び方をしてしまうと、自然と「完成品」を求められてしまう。しかし実際には、ドキュメントが完成するのは、稼動するソフトウェアが完成したときと一緒である。

ちなみに、経済産業省「情報システム信頼性向上のための取引慣行・契約に関する研究会」最終報告などを見ると外部設計完了時点では納品行為を想定、それ以降では分割した形は想定していないようである。また、外部設計完了時点の納品物(設計書)については、

  • 要件定義書及び第○条所定の外部設計検討会での決定事項との不一致又は論理的誤りがある場合を瑕疵とする
  • 瑕疵がユーザの指示や提供した資料等に起因する場合にはベンダは担保責任を負わない
  • ベンダが資料等又はユーザの指示が不適当であることを知って指摘しない場合には担保責任を免れない

となっている。

プログラミング工程の切れ目(テスト前)

ウォーターフォール開発プロセスを採用しているとして、最初のテスト(単体テスト)前のソフトウェアを納品するのは可能だろうか。例えるなら「組立てはまだだが、製品のパーツはすべて揃ったので金を払って欲しい」ということになるが、実際には結合(組立てし)て、テストして(動かして)みないとパーツが揃っているのかも確認できないので、分割納品(中間納品)にはそぐわない。

テスト工程の切れ目

それでは、何らかのテストが完了した段階での分割納品(中間納品)は可能なのだろうか。実はこのパターンは問題が無い。○○テスト(単体テスト結合テストシステムテストなど・・・呼び名はそれぞれ)が完了したソフトウェアは、「一定の動作は確認した試作品」であるので、それを納品することは特に問題が無い。そもそも完全なテストを行うことは不可能なので、最終納品物であっても実際には「一定の品質チェックを行った製作品」なのである。

まとめ

  • 中間納品はやめておこう
  • どうしても中間納品するなら、外部設計の終了タイミングか、何らかのテスト工程が終わったタイミングで