カスタムシステム開発プロセスの問題点
情報システムの開発環境はこの10年で大きく進歩しました。
開発用のマシンはとても高性能になり、再利用可能なライブラリやフレームワークがインターネット上に無数に存在し、仮想サーバ技術やクラウドを利用すればハードウェアが無くてもすぐにシステムを構築することができます。開発者一人当たりの効率はおそらく2倍以上に上がっているでしょう。開発言語や開発手法も進歩しています。にも関わらず、クライアントが思い描くシステムを決められた期間やコストの中で作ることができないのは、カスタムシステム開発の問題が開発効率よりも開発プロセスの中にあるためです。
クライアントは開発メンバーか？
既存の開発プロセスでは、クライアントに仕様の確認やテストへの参加といった協力を強く要求します。さまざまな書籍等で紹介されている失敗事例でも頻繁に指摘されているとおり、失敗する原因の多くは、クライアントがよく分からないままOKを出した仕様に基づいて開発してしまうことです。その結果、終盤になって要求と違うと言われて大幅な巻き戻しをせざるを得なくなったり、逆にあれもこれも必要だとクライアントに言われるままに開発しようとしてエンドレスに陥ったりしてしまうことになります。
この問題は既に広く認識されていて、多くのプロジェクトマネジメントの教科書では、クライアントにも開発メンバーの一員であるという意識を持ってもらい、責任を共有することが大事であると説いています。確かに、何億円ものコストを投じる大規模システム開発の場合には、クライアント側からも専任のメン バーを出してもらい、開発に参加してもらうのが理想的だと思います。しかしより一般的な、数百万円単位のカスタムシステム開発の場合に、クライアントにも開発に参加してくださいというのは現実的でしょうか？
カスタムシステム開発では、クライアントはエンドユーザ本人の場合がほとんどです。そのため、クライアントは業務の内容についてはエキスパートですが、UML で書かれた設計書を読みたいとは思わないでしょう。また、本来の業務に忙しいため、細かい仕様についていちいち質問されても答える時間すら十分にないことがあります。このような状況の中で進められるカスタムシステム開発を成功させる1番目のポイントは、大規模システム開発の場合とは反対に、クライアントにできる限り負荷をかけずに要求を汲み取る技術だと考えています。
完成形をなるべく早くイメージすること
既存の開発プロセスのもう一つの問題点は、完成形がどうなるのかを早く知りたいという、クライアントにとって当たり前の要求を重視していないことです。 ウォーターフォール方式では、実際にクライアントがシステムの完成形をイメージできるのは最後のテストのフェーズになってからです。スパイラル方式やアジャイル方式では早い段階で動作可能なシステムを開発しますが、部分的に動くシステムを建て増ししていく方式なので、完成形がなかなか（場合によってはいつまで経っても）見えてきません。その結果、クライアントのシステム開発に対する熱意が薄れてしまったり、開発者への信頼が損なわれていきます。
この問題を解決するには、完成形を具体的にイメージできるプロトタイプシステムをできる限り早く製作する技術が必要です。さらに、クライアントに提示されるプロトタイプシステムは、どの機能が欠けていて最終的にどうなるかという完成形との差分を明確にして、具体的な完成形のイメージをつかめるものである必要があります。