━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ IT Pro Executive Radar　by　日経情報ストラテジー　 　　 2004/02/10 ……………………………………………………………………………………………… 〜　IT経営に関するニュースやトレンドを毎週お届けします　〜 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 目┃次┃　今号の内容 ━┛━┛━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ くたばれ「ユーザニーズ」 　システム開発にあたっては，ユーザニーズを重視することが必要だといわれている。 ところが・・・。 ●ユーザニーズの大部分は存在するのではない。発明されるのだ。 　（マジメバカをチームに入れるな） 　システム開発プロジェクトでは，対象業務担当部門のメンバーがユーザニーズを取 りまとめる任務で参画するが，彼（彼女）の性格により，開発プロジェクトは大きな 影響を受ける。 　ユーザニーズのなかには，「ぜひ必要」なニーズもあれば「あったらいいな」程度 のニーズもある。ズボラ人間は適当に手を抜き，まわりから強くいわれるニーズしか 取り上げないので，「ぜひ必要」なニーズに限定される。ところがマジメ人間は，ニ ーズを多く提出することをプロジェクトチームや所属部門への忠誠だと思っているの で，「あったらいいな」どころか「どうでもよい」ニーズまで発明（発見ではない！） する。しかも，しょせんはバカなのだから，発明したニーズが実用になるはずがない。 　情報システム部門にとっては「ユーザの声は神の声」である。情報システム部門に もマジメバカが多く，発明ニーズの実現が天命であると考える。ときにはリコウ人間 がいてバカげた要求だと指摘することもあろうが，マジメユーザは忠誠心から，なぜ それが必要かという理由まで発明して聖戦を挑む。この時点でプロジェクトの失敗は 保証される。さらに，最近はスパイラル型の開発が多いが，これにマジメバカが参加 すると無限ループに陥り，失敗は確実なものとなる。 　そもそも現存のシステムが巨大・複雑になったのは，マジメバカ人間をチームに入 れたからである。ＥＲＰパッケージの最大の利点は，このようなマジメバカ人間を締 め出すことができることにある。 ＜蛇足的説明＞ 　横軸に要求事項，縦軸に金額をとる。効用のグラフは，横軸に要求事項を重要度で 並べて，それが実現したときの効果を縦軸にとれば，対数的に増大するパレート曲線 になる。それに対して，費用のグラフは，横軸にシステムの規模，縦軸に開発工数を とれば，ベームの法則に従い指数的に増大する曲線になる。やや強引であるが，要求 事項の数とシステムの規模は変換できるし，保守も含めたシステムの総費用は開発工 数と比例するので，この二つのグラフを一つの座標に描くことができる。 　そのシステムによる利益は効果−費用であるから，それが最大になるのは二つの曲 線の差が最大になる点であり，その横軸が開発するべきシステムの最適規模（実現す るべき要求事項）である。ところが「どうでもよい」要求をするために規模は最適規 模を超えてしまうので，利益は少なくなり，さらに「発明ニーズ」が多いと要求規模 は２つのグラフの交点も越えてしまい，費用対効果がマイナスになってしまう。 ＜／蛇足的説明＞ ●ユーザニーズはユーザにもわからない 　マジメバカを排斥しても問題が残る。システム開発には時間がかかるし，システム はある程度の期間利用することが前提である。将来を見越したニーズを確定できるだ ろうか？　現行システムを計画した時点で現在の状況が的確に予測されていたならば， このシステムを開発する必要すらないはずだ。当時に予想したことがことごとく外れ たのだから，これからも同様であろう。そもそも，現在の状況を的確に予測できた人 は，自社から逃げ出しているであろう。それは経営者でも同様だから，経営者が積極 的に参加したところで効果はない。かえって将来に禍根を招く機能を要求するのがオ チである。 　すなわち，適切な「ユーザニーズは存在しない」のである。強いて言えば「将来の ことはわからない。それが発生したときに即応するシステムにしてくれ」というのが 唯一の適切なニーズである。 　変化に即応するには，現状のユーザニーズにがんじがらめになったカミソリのよう なシステムでは困る。適当にズボラなナタのようなシステムにしておくほうがよいの である（これについては，情報検索系システムが有効なのであるが，別の機会にゆづ る）。