http://www.projectcartoon.com/cartoon/586
より、この絵の解説を試みたい。
顧客はその分野のプロフェッショナルなので、
プロなら問題の把握や解決策の提案も
信頼できるかと思いきや、そうでないことが
多いという皮肉。顧客は問題発見や要求定義の
プロではないのだ。
コンサルはその手腕(思考法、分析法)で
相手も気付いていないような問題の掘り起こしや
発見に努めなければならない。
■ 営業(コンサル)の表現、約束
問題に対して一定の解決案を示せているものの
顧客に媚びるあまり誇大であったり、無駄な表現で
周囲を混乱させてしまう。
「大舟に乗ったつもりで」といった感じだ。
■ アナリストのデザイン
アナリストは凝ったものを作りたがる性癖がある。
問題を解決できそうではあるが、
しばしば現実離れしたものを考案してしまう。
アナリストは趣味に走らず、顧客や自分たちの
実力をわきまえて実現可能な提案をすることに
努めなければならない。
■ プロジェクトリーダの理解
プロジェクトリーダは、問題解決の総指揮者。
顧客や営業、アナリストの意見をまとめて
プロジェクトの方向性を決定する。
実現可能でバランスの取れた解決策を
提案できるが、顧客、営業、アナリストの意見を
調整するうちに重要なものを削ぎ落としてしまうことがある(この場合ブラブラできない)。
リーダは必ず問題の本質を押さえて最低限の
要件だけでも満たせるよう努めなければならない。
■ プログラマの実装
アナリストやリーダの示した目標を実現するには
技術が未熟であったり、そもそも人手不足であったり
することがあり、手の届く範囲で頑張った結果、
何か形のあるものにはなっているが顧客の問題を
全く解決できない。最悪の場合、プログラマは
「何だか分からないけど顧客の所に持っていけば
運用でなんとかなるんだろう」ぐらいの意識。
■ ベータ版テスターの受難
ある程度は要件を満たしているのだが、ベータテストの
段階ではちょっと長さが足りなくて、首吊り紐みたいになって
しまっている。もしこれを使用したらひどい目に
合うことは分かっているのだが・・・
■ プロジェクトの書類
成果物が要件を満たせなかったため、ドキュメント
を作成する時間がないという現象。
ドキュメントがあったとしても、実際の成果物の
影くらいしか表現できていない。
■ 顧客への請求金額
プロジェクトリーダは現実的な予算を組み、
営業は安く見積もったり、
アナリストの提案は高価すぎたり、
そもそも問題の理解が不十分なために
度重なる仕様変更で請求額は乱高下。
■リリース時期
リリースが遅れた結果、シーズンを逃してしまい
誰も寄りつかない始末。
■広告
広告だけはクール。
■ 実際の運用
全てがちぐはぐであったため、システムを
適切に設置することができない。できあがった
ものを顧客のところに設置しようと、2本目の縄を
垂らそうとしたとたん、「いや、そうではない」
というクレームが付いて、そこまで止まり。
■ 得られたサポート
使い物にならないので、サポートは
途中でスッパリ打ち切られる。
■障害対策
バックアップ系を用意してある。
ただし実運用に耐えるかは未評価。
■実際の性能
ちょっと蝶のようなものが上に乗ったくらいの負荷で
破損してしまう。
■オープンソースの場合
だいたいみんなが望むものは、一通り無料で
揃ってる。だが、それは顧客にとって必要な
ものかどうかは別の問題。
■パッチの適用後
セキュリティパッチをあてたら、色々と制限が加わって
結局のところ手も足も出ない。
■ 顧客が本当に必要だったもの
顧客の説明は「木からぶらさがるもので、
縄で吊るして、乗ることができて
地面から離れていてぶらぶらできて、
頭をくぐらせられるだけのスペースがあって、
ブランコに似ているけど、でもブランコではなくて」
というようなものだったようだ。
そして、顧客自身も説明するときに重要な点を
見落としているため本当に必要であったものは
誰にとっても思いもよらないものであったり、
見積もりより遥かに工数が少なくて済むもので
あったりする。
■diggの影響
そんな公共事業が掲示板などで話題になると・・・