ウォーターフォールだって成功する。ただしそれには前提条件があるはず

東京証券取引所の新株式売買システムの刷新という大規模な開発プロジェクトの背景と、成功要因を、東証の担当者自身が説明したプレゼンテーションを記事にした「客が本気にならないといいシステムができない。東証arrowhead成功の鍵とは ～ Innovation Sprint 2011」は公開から3日後の現在、過去1週間でもっとも読まれた記事の第1位になっており、たくさんの反響をいただきました。

記事で取り上げたarrowheadの開発は巨大なウォーターフォール型のプロジェクトであり、その成功の鍵として主に挙げられていたのは次のようなことでした。

• 関係者全員での危機意識の共有
• 発注者責任の明確化
• 上流工程完璧主義

しかしこの成功の鍵には、語られなかったけれども理解しなくてはならない背景があったと僕には思えます。おそらく当事者にとっては当たり前すぎて語られなかったことです。

語られなかったけれど、あったはずの成功の背景

1つは、開発対象となったarrowheadでは要求仕様が比較的安定していたのではないか、ということ。

株式売買システムの要件の中心をなすであろう株式売買ルールや外部との通信プロトコル、ユーザーインターフェイスなどは、おそらく歴史的経緯もあってそれなりに安定したもので、時間の経過とともにころころ変わったりするものではないだろうと想像されます。こうした背景が、今回のウォーターフォールの成功の大きな要因だった「上流工程完璧主義」を支えていたのでしょう。

もしも時間とともにビジネス環境が変わり、それとともに要求仕様も変わっていくものだとしたら、上流工程を完璧にしたとしても、要求仕様が変化したら意味がなくなってしまいますからね。

もう1つは、株式売買システムは東証の本業そのものであり、だからこそ本気になって取り組まざるを得ない環境であっただろうこと。このプロジェクトが失敗すれば東証の地盤沈下になるだろうという危機感を関係者全員が共有できたのには、こうした背景があったためだと思います。

といったことを、このセッションのモデレータをされていた奈良先端科学技術大学院大学 助教 森崎修司氏と、ちょうどセッション直後に話し合っていました。

森崎氏は、先週ブログにこんなエントリ「使おうとしているプラクティスや技法の前提は明らかになってますか？」を書いています。

同様にしてプロセス、技法、プラクティスが、なぜ効果を発揮したか、その前提は何かを明らかにすると、事例を伝える際に非常に説得力を増す。

arrowheadプロジェクトはウォーターフォールで行われましたが、それがなぜ成功したかという前提を考えるとき、ここにあげたような「要求仕様が変化しにくい」「顧客が本気で取り組む環境が揃っていた」からではないでしょうか。逆に言えば、巨大なウォーターフォールでもこうした前提があれば成功させることができる、という事例だったわけです。

そしてこうした前提が揃わないときは、例えば「要求仕様が変化しやすい、あるいは最初に決めることが難しい」場合には、ウォーターフォールよりもアジャイル開発手法が向いているでしょう。しかし、「顧客が本気で取り組んでくれない」のは、開発手法や技術では解決できません。そして、これによってプロジェクトが失敗したり、納期が延びたりする、という課題を抱えている開発関係者は多いのでしょうね……