[引用] ＩＴプロジェクトの実態

　　　
http://www.cagylogic.com/archives/2004/03/04021256.php
　　　ピアノのレッスンも、こんな感じですよね・・・。


（クリックすると拡大します）


[以下上記サイトより引用]
■「顧客が本当に必要だった物」と「顧客が説明した要件」
顧客が本当に必要なものは、顧客は自分では説明できない。
結局、本当に必要なものって身の回りでは結構少ない。あると便利だから。とかデザイン（見た目）がいいからとかそんな理由で身の回りのものはそろえられていくのだと思う。
んで、買うときは、どうせ買うんだから安くて良いのが欲しいと思うわけである。
実際問題、ここで「顧客が本当に必要だった物」が一発で手に入ったとしても顧客は喜ばないわけである。いつも顧客はプラスアルファの何かを欲しているのだから。

■「顧客が説明した要件」と「営業の表現、約束」
営業としてはできるだけ、顧客からお金をふんだくらなくてはならない。よくも悪くもそれが仕事である。ということは、ファンシーでハッピーなことをいうわけである。
顧客の説明した要件に枝葉をつけて、こんなんつけたら幸せでしょってな感じでオプションを追加していくわけである。
途中で、ゴムタイヤのブランコで十分だということが気が付いたとしてもそれは口には出さない。手が汚れるから、おしりが痛くなるからソファーの方がいいでしょ。ってな具合になるわけである。

■「アナリストのデザイン」
アナリストは顧客に近い立場にいる。アナリストは顧客が何を要求しているのかを考える。しかし、アナリストが「顧客が本当に必要だったもの」を見つけ出すのは難しい。第一、顧客は本当に必要な物は欲しがっていないからである。そこで、何をやりたいのかを悪戦苦闘してあの絵ができてくる。興味深いのは機能としてはちゃんと実現されているところである。

■「プロジェクトリーダーの理解」について
「アナリストのデザイン」ではあきらかに不自然な構造を、自然な構造に修正してある。これは現実的な解である。
しかしこのことにより、機能が満たされなくなっている。修正する際には機能は削減されてはいけない。もし削減される場合はちゃんとアナリストやら顧客やらと相談するべきである。

■「プログラマのコード」
プログラマはできるだけ、楽に実装をしたい。プロジェクトリーダーはその道筋をちゃんと示す義務があると思う。プロジェクトリーダーがその道筋をちゃんと示さない場合は、プログラマは最短経路を進もうとする。ブランコというモジュールがあって、そのモジュールが木にくくりつけられている。という事実からあの絵が出来上がる。

■「実装された運用」
プログラマのコードから使える部分だけを取り出して、顧客が実際に運用している絵があのかたちなのだと思われる。
プログラマが一生懸命働いても、ぜんぜん使われないわけである。

[引用終わり]