顧客は要件を伝えられない
開発を担当するSEは、「顧客は設計に必要なインプットをくれるものだ」と思っている。
でないと、「どんなソフトウェアを作っていいか分からない」と思いこんでいるケースがとても多い。
でも実際には、はじめから設計に必要なインプットを準備している顧客なんてありえない。
新しいソフトウェアを作るためのインプットなんて、出てこないと思ったほうが良い。
＃逆に言えば、新しいソフトウェアの開発で、それがすぐに出てくる顧客は怪しい。
＃どこかのモノマネだったり、盗んだものだったりする。
＃参考にするのはいいですが、新たに開発するソフトウェアは、やはりオリジナリティが大事です。
なので、顧客から「どのようなソフトウェアを作りたいのか？」というところを引き出し、
練って、現実の仕様のインプットを作成するところからソフトウェア開発は始まるものです。
これを「要件定義」と呼びます。
私たちは、要件定義を行うために、RDRAというフレームワークを使用しています。
RDRAでは、このような要求モデルを採用しています。
要望：思いつきレベルのもの（～を～したい という表現になる）
要求：検討対象として合意されているもの、既に共通認識として認識されているもの（～できること という表現になる）
要件：要求のうち今回の開発で実施すると決めた重要なもの。
要望から要件が出てきてはじめて、システム設計の入り口まで来たという感じでしょうか。
プロジェクト失敗の理由に、「要件定義が甘かった」という反省がよくあります。
実は簡単で、ここで失敗しているだけの話です。顧客の「～したい」という「要望」を
そのまま設計のインプットにするから、顧客との認識にギャップが産まれる。
システムの「要件」は、顧客から伝えられるものではなくて、「要望」から引き出して定義するもの。
そういう認識がないと、上流工程のエンジニアは務まらない。
顧客は、要件をSEに伝えられないんです。大事なのは、SEがそのことを認識すること。
でないと、「顧客の言うとおりに作ったのに、顧客満足が得られないソフトウェア」ができてしまいます。