世の中は比較的

こんにちは。naekです。
今日は、仕事中に話題になった、「顧客が本当に必要だったもの」についてです。

この絵は、ITビジネスにおけるシステム開発の迷走ぶりを風刺した絵で、顧客の？な要望から始まって、それを各担当に回していった結果、途中経過でだんだん最終形がずれてきて、最終的にできたものは「何それ？」っていうシステムが出来上がるという絵です。




絵の流れとしては、下記の通りです。
※ちなみに、コメントについては、私のこれまでの社会人経験から感じたコメントです。

1. 顧客が説明した要件
   
   理想に任せて好き放題の希望を言います（私はお客さんだから当然だと思ってますが）
2. プロジェクトリーダーの理解
   
   ブランコにはなぜか意味もなくありえない3段仕様が付帯しているためその部分をうまく（？）解釈して安定したブランコになります
3. アナリストのデザイン
   
   プロジェクトリーダの設計だとブランコとして機能しないから、椅子のところの幹を切って乗れるようにしましょう
4. プログラマのコード
   
   木から2本ロープが出ていて、板をつければいいという仕様どおりにできました！
5. 営業の表現、約束
   
   受注を取りたいがために顧客にはいいところを強調して説明します。しかも、技術的には深い知識を持った人は少ないので、できるかできないかわからないがとにかく顧客の喜びそうなオプションを付けてくれます
   
6. プロジェクトの書類
   
   なんかとりあえず、プロジェクトは進んでいるけども、締め切りがあるのでつい急いでしまい、文書セットができてないことが多いです。コスト削減のために、あえて作らないっていう選択をしている会社さんもあります
7. 実装された運用
   
   ズレズレな仕様で進めきているので、効率悪く、GoLiveにも間に合わずとりあいそうもないけど、一応気にロープ付けたしとりあえずはこれで完成！！
8. 顧客への請求金額
   
   結果がどうあれ、作業工数としては発生しているので、請求も発生します。見積もりも途中の仕様変更などで追加追加となり、膨大となりました
9. 得られたサポート
   
   できあがったものの、満足に使える状態にない。じゃぁ直してくださいとお願いすると追加料金が発生することになり、これ以上お金はかけられないとなれば、宙ぶらりんの状態で、このシステムを使うこともなく、そして使わないからサポートもなく...
10. 顧客が本当に必要だったもの
    
    結果、よーく考えたら、タイヤで十分やったね

結果、そんなバカな！？と思うんですが、業界ではこれが結構あるあるです。




幸い、私が働いてきた会社では、あまりそういうことがなかったんですが（たぶん社内での作り込み開発だったから？）、システムを外注すると上のようなプロジェクトの混沌とした状態を整理してくれる人がいないと、大変なことになります。

ただ、過去にITコンサルタントとお仕事していたことがあったんですが、とてもリーダーシップのある方でしたので、海外の支社の社員も一緒に参加するような大きなプロジェクトでもうまくまとめ、上の絵の顧客の過剰な要望に対しても、「それでは実現不可能です」とか「不要な機能はつけるべきではない」というのをハッキリとコンサルされておられました（スバラシイ！！）。

本来コンサルというのは、そうあるべき！！とは思いますが、通常はそんなことはまれで、グダグダのプロジェクトも巷にはたくさん転がっているのが現状です。

私にとっては、コンサルの役割の重要性がとても感じられる絵でした。


参考ページ：顧客が本当に必要だったもの
　　　　　　ニコニコ大百科（仮）顧客が本当に必要だったもの



本日も、読んでいただきありがとうございました。

ブログランキングに参加しています。
もしよろしければ応援よろしくお願いします。
にほんブログ村