はじめに

受託開発の場合，まず顧客の要望があって開発がスタートします。その要望に応えられるシステムを作成するというのがプロジェクトの最終的なミッションです。

ここでは，受託開発というフィールドの中で，どのような開発プロセスが考えられ，実際に採用されてきたかについて簡単に紹介します。

ウォーターフォール型開発モデル

システムの開発工程を各フェーズに分割し，それを順番に実行していこうという開発モデルを「ウォーターフォール型」と呼びます。ウォーターフォール，つまり滝のように流れ落ちるように作業を進めていくことからこの名前がつきました。

基本は，各フェーズをきちんと順序立てて進めていく，ということです。一般に，システムの開発工程は次のようになっています。

ウォーターフォール型の開発では，各フェーズで成果物を残し，それを元にして次の工程を進めていくことになります。基本的には，前の工程が終わるまで次の工程に進んではいけません。各フェーズをきちんとやっていれば，その次のフェーズであれこれ迷う必要がなくなるので非常に効率のよい開発スタイルと言えます。

欠点としては，最終的なシステムができあがるまで顧客がシステムを実際に見ることができないということが挙げられます。せっかく完成したのに顧客が思っていたものと違うものができあがってしまった……。この場合，作業に後戻りが発生するため非常に手間がかかってしまいます。どれほど各フェーズをきちんと進めていても，このリスクをなくすことはできません。

スパイラル型開発モデル

そうしたウォーターフォール型の開発の欠点を克服しようとして考えられたのが，「⁠スパイラル型」の開発モデルです。

スパイラル型の開発では，まずプロトタイプと呼ばれるシステムを作成します。プロトタイプの目的は，顧客に実際のシステムを見せることで，要求や仕様に問題がないかのレビューを行うことです。レビューのフィードバックを元に，再びシステムを開発し直します。それを何度も繰り返すことでシステムの完成度を上げていきます。何度も繰り返す1回1回は，ウォーターフォール型の開発そのものです。

たとえプロトタイプといえども，最終的に必要とされる機能をすべて備えている必要があります。そうしないと完全なレビューが行えず，プロトタイプを作成する意味がなくなってしまいます。したがってコストが非常にかかる手法であるため，実際に採用されるケースは少ないようです。

実際の運用

受託開発の現場では，ウォーターフォール型の開発モデルが採用されてきました。その理由として，開発工程が順々に分かれているので計画が立てやすく，分業しやすいということがあります。

大規模なプロジェクトでは，プロジェクトに参画するメンバーを1つの会社で揃えるというのは実際問題として困難な場合が多かったのです。そういう事情に，「⁠設計する人」と「実装する人」が異なっていても問題ないウォーターフォール型の開発モデルは非常にマッチしました。要求分析から設計までを行う会社と，実装だけを行う会社が協力してシステムを開発するということが一般化したのです。

この分業制はさらに発展し，今日ではオフショア開発と呼ばれる形態も取られるようになっています。たとえば，日本にある企業が要求分析，設計を担当し，実装を外国（中国，インドなど）にある企業に委託するような形態です。外国の企業に発注した方が人件費が安く済むため，トータルでコストを抑えることができると期待されています。

ドキュメントとコミュニケーションの大切さ

分業するからには，それぞれのフェーズの担当者の間で認識を合わせないと失敗します。まずはドキュメントをきちんと書くことです。設計書，仕様書がきちんと書かれていない限り，認識を合わせることは不可能です。お互いの理解を助けるためにも，ドキュメントはしっかり書かれる必要があります。もちろん，必要以上に体裁にこだわる必要はありませんが。

そうしてドキュメントを作成したとしても，設計者の思った通りのシステムが実装されてくるとは限りません。常にコミュニケーションを行い，認識のズレが生じていないか確認しておく必要があります。オフショア開発の場合，コミュニケーションはさらに重要な要素となります。そのためのコストが想像以上にかかることも多いので，本当にオフショア開発が効果的なのかどうかは慎重に判断する必要があるでしょう。

細かいイテレーションへ

分業が進むと，どこかで手戻りが発生した場合のコストが大きくなってしまいます。もうすでに実装が開始されていたり，実装が完了しているシステムに対して仕様の変更など予定外のことが発生した場合，作業をやり直すコストは非常に高くつきます。ウォーターフォール型の開発の最大の問題は，最初からシステムを完成させることをゴールに据えて大きな単位で作業が進んでいくことなのです。

そのため，もっと小さな単位でイテレーション（反復）を行うことが考えられるようになってきています。たとえば1機能，1画面の単位で短期間でシステムを開発し，顧客のレビューを通しながら徐々にシステム全体の軌道修正を行っていくといった方式です。それを継続して行い，機能を少しずつ加えていくことによって，完成したシステムが顧客の思っていたものと違っていた，といった失敗を防ぐことができます。

小さな成功を積み重ねていけば，大きな成功により近づくことができるのです。

まとめ

必要なドキュメントを書くこと，コミュニケーションをしっかりとること。そして小さな単位でイテレーションをまわし，それを積み重ねていくこと。こうした方式を，「⁠アジャイルソフトウェア開発手法」と呼ぶこともあります。興味を持たれた方は，「⁠アジャイル」で検索してみてください。いろいろな工夫が開発ブロセスに対して行われようとしているのがわかると思います。