ITプロジェクトの実態とは！

参照元のサイトのコメントによると、この漫画はいろんなところで引用されているらしい。
ManagementNextという記述の24ページが元ネタではないかともいわれているし、ソフトウエア工学（有沢誠著）の２５ページにのっていた ロンドン大学ニュースレター５３号（1973年3月搭載）の図ともいわれている。
こんな絵もあるらしい。（コメントが微妙に違うのがおもろい）
まぁどちらにしても、古くからある漫画らしい。詳しくは引用元のBlogのコメントやらトラックバックを見て欲しい。

英語版はこちら

著作権上問題があるかもしれないけど、まぁ引用ということで。。。問題があったら教えてください。消します。

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

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

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

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

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

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

「得られたサポート」
これがちょっと意味がよくわからない。
僕なら、「実装された運用」の絵に対して、紐の先に結び目くらいつけてあげると思うのだが。。。

「プロジェクトの書類」
問題外

「顧客への請求金額」
問題外

思うこと
顧客は本当に必要なものはいわない。それを引っ張り出すのはアナリストの仕事。
アナリストの能力がプロジェクトに大きな影響を与える。
でも、実際問題、世の中で、アナリシスをすっ飛ばしたプロジェクトってごまんとあるんだと思う。そうゆうプロジェクトはこけるべくしてこけるんだなぁという再認識。

営業はそれが仕事なんだからしょうがないかなぁ。。。

別にこの漫画はコミュニケーションがどうのとかいう漫画じゃないと思う。