ソフトウェア開発、システム開発の手法として最も代表的なものはウォーターフォールモデル型の開発手法です。
以下にもまとめました。
ウォーターフォールモデル(局面化開発手法)において各工程は、要件定義、外部設計(基本設計)、内部設計(詳細設計)、システム開発、単体テスト、統合テスト、納品、保守の順番で作業は進みます。
一番最初のフェーズは要件定義と呼ばれる局面ですが、実はここはとても難しい局面なんです。
要件定義局面の難しさを風刺する「顧客が本当に必要だったもの」という面白いイラスト集があります。
一番の大元は「オレゴン大学の実験」と呼ばれるものです。
これを現代風に分かりやすく書き換えたものが、下記の絵です。
How Projects Really Work (version 1.5)
要件定義の重要性、難しさ、システム開発が失敗する理由を理解する上でわかりやすいので引用して解説してみます。
画像はすべて
からの引用です。
ほとんど説明なく理解できるはずです。
目次
顧客が説明した要件
ちょっと変わった面白いブランコを作って欲しい。
例えば、3人が同時に乗って遊べるような。
プロジェクトリーダーの理解
分かりました。
ブランコを作るんですね。
木にブランコをくくり付けます。
(おいおい。これ動かないぞ！)
アナリストのデザイン
動かないブランコをちゃんとデザインし直しました。
木を真ん中で切れば動きますよ。
その木は両方の細い木で支えます。
すごいでしょ。
(おいおい。これ乗って遊べないぞ！)
プログラマのコード
分かりました。
木にロープをくくりつけて、板とつなげばいいんですね。
コードを書きました。
(おいおい。乗れないぞ。)
ベータテスターが受け取ったもの
木にロープ。。。？
(おいおい。自殺しろってか？)
営業の表現、約束
これはとても素晴らしい優雅な遊び道具です。
なんとソファーのように乗り心地がよいブランコなんです。
(おいおい。安定してないぞ。)
プロジェクトのドキュメント (仕様書)
ドキュメントは作っていません。
(おいおい。困った。どこが問題なんだ？)
実装された運用
運用はロープ1本を使ってください。
(おいおい。なんだこれ？)
顧客への請求金額
これは木製ジェットコースターなので、とても高いです。
(おいおい。払えないぞ。)
得られたサポート
サポートはほんのわずかです。
(おいおい。わからないことだらけだ。)
マーケティングで宣伝された物
次世代電話機スマートフォン iPhoneのようなブランコです。
名前はなんと iSwing 。
(スティーブ・ジョブズもびっくり。)
顧客が本当に必要だった物
顧客が本当に必要だったもの。
木にタイヤをくくり付けて、何人かが同時に乗って遊びたかっただけ。
一連の画像のオチ。
おいおい。。
まとめ
一連の風刺画は誇張はあるものの、伝言ゲームの難しさを語っています。
一番のポイントは、顧客がちゃんと要件を説明できていない事でしょうか？
「複数人で遊びたいブランコが欲しい」っていう要件が、伝言ゲームで独り歩きしてしまったって事かな。
多くのITプロジェクトの失敗は、システムの不具合よりもコミュニケーションの齟齬。
要件定義は難しい。
だって、顧客だって本当に必要なものが分かっていないんだから。。
↓下記の訴訟も要件定義がうまくいかなかったことが原因か。
コメント