システム開発の難しさ その２
 顧客が説明した 要件 |
 プロジェクト リーダーの理解 |
 アナリストの設計 |
 プログラマの コード |
 営業の表現、約束 |
 プロジェクトの 書類 |
 実際の運用 |
 顧客への請求金額 |
 得られたサポート |
 顧客が本当に 必要だったもの |
アナリストの設計
アナリストがプロジェクトリーダーの構想を分析した結果、このままではブランコが動かないことに気づきました。
そのため、ブランコがなんとか揺れることができるように改良されています。
しかし、支えの棒が脆弱ですぐに崩壊しそうです。
プロジェクトリーダーの意図はとりあえず反映してみたものの、そもそも当初の見通しが間違っているため、顧客の要求と両立させるために不自然で歪んだシステムが設計されてしまいました。
妥当性を検証し、上流工程に差し戻してやり直しを要求することは立場として難しいのでしょうか。
あるいは、アナリストとして腕の見せ所と張り切った結果でしょうか。
無意味に新技術を導入したがる設計者が多いのも問題なのかもしれません。
プログラマのコード
木の幹にブランコが繋がれている状態です。
第三者の目にはかなり異様な光景に映りますが、「木と板を２本の紐でつなぐように」としか説明されなかった薄給のプログラマが形だけ作ってみたものです。
一昔前なら「ステップ数でこれだけの進捗がありました」と報告するような職場での仕事ぶりでしょうか。もしくは、どの幹に結んでも結局は折れるので、仕様を満たそうとするとこうするしかない、という現場の苦悩でしょうか。
これはブランコの設置なので、見た目はまだ分かりやすいですが、プログラマの労働の成果であるプログラムの構造や動作を第三者が手早く評価したり欠陥を見抜くのは容易ではありません。
設計者の意図は正しくプログラマに伝わっておらず、まともに動かないシステムが生まれゆく状況を示しています。
木とブランコが「とりあえず繋がっている」ので、顧客にはとりあえず「間違ってはいない」という説明はできます。
プログラマが顧客の要求を知る術もないため、ここでも成果物の妥当性を検証する機会はないようです。
見かけ上の成果は増えていき、進捗遅れもなく開発が順調に進んでるように見えますが、後々捨てられるプログラムが大半を占めるのです。
営業の表現、約束
立派な肘掛け椅子を搭載した無駄に豪華なブランコです。
第三者の目にはかなり異様な光景に映りますが、売り込みに熱心な営業担当者はそんなことは気にしません。
まさに絵に描いた餅です。
システムの本質を満たしていない上に、過剰な機能の搭載を売り込んでしまう営業。製品はまだできていないので、何とでも言えるのです。
また、顧客の要望が枯れた技術を水平展開して代用して実現できる可能性に仮に気づいていても、絶対に営業側から顧客に言い出すことはありません。
顧客側から「もっと安く代替できるのでは？」と指摘されても「でもこちらのソファの方がお尻が痛くないですよね。」と誘導していくのです。
なるべく高価で大量に機能を盛り込んだ豪華なプランを、さもお得であるかのように見せかけて契約を取るのが彼らの仕事だからです。
この手法は顧客が技術的なことを理解できない場合はなおさら有効です。
ところで、営業担当者たちは実際の開発現場とどんな交流があるのでしょうか。
現実には交流はほとんどありません。
というより、営業担当者本人が技術的なことを全く理解できてない場合も多く、マネジメントの知識すらないこともあります。
そのため、「こんな凄いことがたったこれだけの工数でできてしまうんです！」「仕様変更(追加)ですか？任せてください！簡単なことですよ！！」となんの根拠もなく豪語してしまうのです。
競合他社がいる場合、出来ないことを知っていても、開発側に丸投げすることすらあります。
とりあえず、案件を取りさえすれば自分の手柄になるのだから、後のことは知ったことはないのです。
当然、開発現場には「これと同じものをロープ２本と板１枚の【予算】で作れ」と要求します。
阿鼻叫喚の始まりです。
もちろん営業側は満足した顔でさっさと定時で帰ってしまうのです。
システム開発の難しさ その２ 関連ページ
PR
