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

ITプロジェクトの実態とは!に、非常に興味深い漫画が出ていた。自分なりに解釈を入れてみようと思う。


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

英語版はこちら

著作権上問題があるかもしれないけど、まぁ引用ということで。。。問題があったら教えてください。消します。
「顧客が本当に必要だった物」と「顧客が説明した要件」
顧客が本当に必要なものは、顧客は自分では説明できない。
結局、本当に必要なものって身の回りでは結構少ない。あると便利だから。とかデザイン(見た目)がいいからとかそんな理由で身の回りのものはそろえられていくのだと思う。
んで、買うときは、どうせ買うんだから安くて良いのが欲しいと思うわけである。
実際問題、ここで「顧客が本当に必要だった物」が一発で手に入ったとしても顧客は喜ばないわけである。いつも顧客はプラスアルファの何かを欲しているのだから。
「顧客が説明した要件」と「営業の表現、約束」
営業としてはできるだけ、顧客からお金をふんだくらなくてはならない。よくも悪くもそれが仕事である。ということは、ファンシーでハッピーなことをいうわけである。
顧客の説明した要件に枝葉をつけて、こんなんつけたら幸せでしょってな感じでオプションを追加していくわけである。
途中で、ゴムタイヤのブランコで十分だということが気が付いたとしてもそれは口には出さない。手が汚れるから、おしりが痛くなるからソファーの方がいいでしょ。ってな具合になるわけである。
「アナリストのデザイン」
アナリストは顧客に近い立場にいる。アナリストは顧客が何を要求しているのかを考える。しかし、アナリストが「顧客が本当に必要だったもの」を見つけ出すのは難しい。第一、顧客は本当に必要な物は欲しがっていないからである。そこで、何をやりたいのかを悪戦苦闘してあの絵ができてくる。興味深いのは機能としてはちゃんと実現されているところである。
「プロジェクトリーダーの理解」について
「アナリストのデザイン」ではあきらかに不自然な構造を、自然な構造に修正してある。これは現実的な解である。
しかしこのことにより、機能が満たされなくなっている。修正する際には機能は削減されてはいけない。もし削減される場合はちゃんとアナリストやら顧客やらと相談するべきである。
「プログラマのコード」
プログラマはできるだけ、楽に実装をしたい。プロジェクトリーダーはその道筋をちゃんと示す義務があると思う。プロジェクトリーダーがその道筋をちゃんと示さない場合は、プログラマは最短経路を進もうとする。ブランコというモジュールがあって、そのモジュールが木にくくりつけられている。という事実からあの絵が出来上がる。
「実装された運用」
プログラマのコードから使える部分だけを取り出して、顧客が実際に運用している絵があのかたちなのだと思われる。
プログラマが一生懸命働いても、ぜんぜん使われないわけである。
「得られたサポート」
これがちょっと意味がよくわからない。
僕なら、「実装された運用」の絵に対して、紐の先に結び目くらいつけてあげると思うのだが。。。
「プロジェクトの書類」
問題外
「顧客への請求金額」
問題外
思うこと
顧客は本当に必要なものはいわない。それを引っ張り出すのはアナリストの仕事。
アナリストの能力がプロジェクトに大きな影響を与える。
でも、実際問題、世の中で、アナリシスをすっ飛ばしたプロジェクトってごまんとあるんだと思う。そうゆうプロジェクトはこけるべくしてこけるんだなぁという再認識。
営業はそれが仕事なんだからしょうがないかなぁ。。。
別にこの漫画はコミュニケーションがどうのとかいう漫画じゃないと思う。

「ITプロジェクトの実態とは!」への18件のフィードバック

  1. うーん。おらの環境のせいなのかもしれない。
    あんまりトラックバックってされないから、ちゃんと動いているか、実は自信が無いんだよな。
    Webで検索するとMTにはトラックバック時の文字化けの問題ってあるらしいし。。

  2. 「プロジェクトリーダーの理解」についての解説に異論があります。
    ブランコの縄が左右別々の枝に繋がっていて、振り子が出来ない状態である。
    この事からプロジェクトリーダーは顧客の目的すらも理解してないという構図だと思う。

  3. 「得られたサポート」の解釈ですが、
    客:こんなブランコは使い物にならない。
    S:そうですね。
    客:役に立たない、邪魔なだけだ。
    S:仰るとおりです。
    客:なんとかしろ(怒
    S:邪魔でしたら、外しましょう。
    S:ブランコを付けないのでしたら木も必要ないでしょう。
    S:ついでにサービスで切っておきましたから。
    客:唖然・・・

  4. IT関係のイメージを説明しても、専門家がいろいろにキャッチするのがわかりました。顧客もわからないことをどう表現したらいいのか、はたして可能なのか不可能なのかもわからない状態ですので
    うやむやに丸め込まれる可能性があるのですね。

  5. 通りすがりの者です。
    面白いですねこれ♪
    プロジェクトリーダーが実現不可能な設計で進行してしまったため、アナリストが無理矢理な修正案を提示しているともとれますねー。
    「得られたサポート」は、製作側がこうしたくなる場面も度々ありますね。変に気を回して便利ボタン追加>顧客からさらに余計な機能追加要望>障害>なんとかしろ>元に戻させてくれ!
    みたいな。

  6. 「プロジェクトリーダーの理解」
    ここでいうプロジェクトリーダーとはエンジニアとは限らず、「納期までにいけるからやろう!」と言う人のこと。
    リーダーが要件やコストを安く見積もることが多い、ということ。
    「アナリストのデザイン」
    「顧客が説明した要件」と、「プロジェクトリーダーの理解」の折衷案だが、どうしても何かが変になる。
    「プログラマのコード」
    枝の強度が足りないから幹へ、ぶら下がること自体が危険だから地面につけよう、と変に気を回してしまった状態。
    「実装された運用」
    運用される時点でやっと顧客が本当に必要だったものが見えてくる。
    「プロジェクトの書類」
    木の大きさやロープといった肝心の部分がない様子。
    「得られたサポート」
    木から再構築していく様、そして途中で打ち切られる様子。
    こんな感じでは?

  7. [情報]企業・組織論のまとめ

    激動の21世紀、この高度資本主義の時代を生き抜くには、企業の動向を常に見極める眼が必要とされるでしょう。IT企業を中心に、企業・組織・就職・労働などの話…

  8. 「得られたサポート」は、開発中の開発陣へのサポートなのか、完成後のユーザーへのサポートなのかで解釈が異なりますね。

  9. ITプロジェクトの実態が良くわかるブランコ

    結構古いネタなのですが、普遍的なものだと思うのでご紹介します。 IT系のプロジェクトをやっていると、恐ろしいことに「なんでこうなったんだろう」と終盤にきて…

コメントを残す