それは「本当に欲しいアプリケーションは誰にも分からない」からである。
システムは通常、要件定義、外部設計・・・といったプロセスを経て作成される。
そのときに、先に「設計」をおこなうわけだが、ここで厄介なのが「ソフトウェアは見えない」事である。
さらにBPRまで含むと、もうどうしようもない。
改革後のビジネスプロセスはまだ誰も未体験なのだから。
つまり、どんなに会議室にあつまって、可能な限り業務に精通したものが知恵を絞って山ほど資料を作成しても、おそらく「それは欲しいアプリケーション」と必ずしもイコールではない。
そういった「本当に欲しいものとの差」は「要件の不確定さ」としてあわられる。
もちろん、予めシステム開発には、見積もりがあって要件定義があって、設計が有る。
「ECが欲しいのか、経理システムが欲しいのかわかりませんが、作ってみました」と
言うわけにはいかない。
なので、「作ってみなとわからないなあ」と開き直るわけにもいかない。
上記の会議室では無論可能な限りその「新しいビジネスモデル下での欲しいアプリケーション像を探り近づける。
しかし、実際の設計の完成度は添付のような上がり方をしていく。
最初?までの個社などと関係なく、いわゆる「常識」で設計できる部分までが一番早い。この段階では「要件の不確定さ」は顧客と開発者の間でも最小である。
?を超えると、「今回の顧客の要望要求を得て設計する」ことになる。ここで設計側と顧客側とで「要件の不確定さ」が発生し始める
?に達すると今度は新しいビジネスモデル特有の部分に入り始める。この段階では顧客の中同士でも「要件の不確定さ」が現れ始めて、ロスが大きくなる。
?の段階では「使ってみないと分からない」「決定者の好みによる」部分となってきてもはや、顧客の１個人の中でも「要件の不確定さ」が現れ始める。
このグラフにあるように、最終的には、?の段階を超えると「作ってみないとわからない」段階に達する。
?の段階を超えると、設計にいくら時間と費用を掛けても大した成果が得られなくなりしかもその成果はリスクの高い成果となる。
なので、その分は事前設計コストを抑えて変わりに、実装とその後に再度要件を取り込むリソースを用意すべきである。
このときにアジャイルは「分からないので、作ってみて直しましょう」を前提にしていることが素晴らしいのである。
つまり、「要件の不確定さ」を前提としているプロセスであることが素晴らしいのである。
しかし、何処からが?段階で何処からが?段階かはあまり論じられていない。
そのことがアジャイルを考える上での不満点でもある。
私は常々この部分をうまく組み合わせればウォータフォールとアジャイルは結婚できると考えている。
で、宣伝チックになるが、「http://www.opentone.co.jp/cgi-bin/wiki3_6_2/wiki.cgi?page=FrontPage」での開発プロセス検討と相成った次第である。
