システム開発におけるユーザーニーズは絶対か？：システム部門Q＆A（16）（2/3 ページ）

[木暮 仁，＠IT]

ユーザー部門のセクショナリズム

　　　現象　　　

　中には「自分の」仕事をよく理解しており、適切なニーズを自部門内で取りまとめて要求することもあります。しかし、それは「自分の仕事」や「自部門内の合意」であり、その合理化が他部門への転嫁になることもあります。それなのに、ユーザー部門は自分の要求をすぐに実現することを望みます。ユーザー部門は「提案する部門」よりも「すぐやる部門」としての情報システム部門が好きなのです。

　情報システム部門が「販売部門としてはもっともであるが、この要求は、流通部門や生産部門にも影響するので、関係部門と相談して……」というと、ユーザー部門は「そんなことをしていたら時間がかかるだけだ。早急に実現してほしい」といいます。また「経営戦略に合致した全体的な最適化が必要だ」といえば、「われわれユーザー部門が経営戦略を実現しているのだ。情報システム部門はそれを支援するのが任務ではないか」と反発します。

　現行のシステムが、統合されていない縦割りシステムであることが批判されますが、ユーザーの言動がその原因になっていることが多いのです。このようなことは、製品や取引先のコード化では顕著になります。統合化した情報システム、保守改訂が容易な情報システムにするには、データ中心アプローチが適切だといわれますが、ユーザー部門のセクショナリズムはその実現を妨害しているのです。

　　　分析　　　

　ユーザー部門のセクショナリズムや情報システム部門との対立を解消するには、「経営者がリーダーシップを執って〜」や「情報システム部門を戦略部門にして〜」などが重要なのはいうまでもありません。しかし現実には、経営者や戦略部門の目が届かないところで、いろいろな問題があるのです。

• 上記のようなやり取りの多くは担当者レベルで行われます。それを防ぐために「必ず上位者の承認を」というようなルールを作ると、担当者レベルでヤミ取引をすることにもなります。
• ユーザーは自分の仕事は分かっていても、他人の仕事を理解していません。要求の全体の中での位置付けが不明確ですし、自分の要望が他人の要望と矛盾してしまうことがあります。ユーザー部門では、このような矛盾を調整する訓練はあまりされていません。また、それを解決するには、仕事の仕方や組織体制を抜本的に改革することも必要になりますが、ユーザーはそのような大きな変革には消極的になりがちです。
• ユーザー部門のセクショナリズムが強い状況で、情報システム部門をアウトソーシングするのは非常に危険です。その環境では、大規模なシステム化は経営情報統括部などが管理するにせよ、小さい要求はユーザー部門に任せるでしょうから、ユーザー部門が直接的にベンダと取引することになります。すると、金持ちの部門は小じゅうと的な情報システム部門がいないのでベンダを私兵のように使うことができるし、ベンダも良い顧客だとしてそれに従うことになります。当初は小さな要求だったのが、次第に成長してその部門の基幹的システムのようになります。そうなってから問題にしても、もう手遅れになってしまいます。

バカマジメが情報システムをダメにする

　　　現象　　　

　要求が多くなれば、情報システムの規模は増大します。規模が大きくなれば、開発費用も保守費用も指数的に増大します。それに対して、情報システムによる効果は、規模に対して対数的に増大するにすぎません。効果曲線と費用曲線の間が利益だから、その差が最大になる規模が最適規模だということになります。

　情報システムをこの最適規模で開発すれば良いのですが、なかなかそうはいきません。要求の中には「この機能がないと絶対に困る」という要求だけでなく、「あったら便利」とか「ついでだから頼んでおこう」というような、効果が比較的低いものもあります。ユーザーの中には、「せっかく情報システム部門が求めているのだから何か要求をしなければ」と、義務感から要求を「発見」してデッチ上げることもあるし、趣味的な要求まですることもあります。しかも、バカマジメなユーザーは、どうでもよいような要求を真剣に主張しがちです。

　このような要求は、どうせマトモには利用されないのですから、無視すればよいのですが、情報システム部門にもバカマジメな人がいると、「ユーザーの声は天の声である」と信じており、バカマジメなユーザーを情報化に熱心なシンパだとして共鳴し、その要求を無批判に受け入れて実現することが自分たちの任務だと主張します。その結果、情報システムの規模は最適規模より過剰な規模になります。極端な場合には、開発費用が利用効果よりも大きくなってしまう。費用対効果が悪くなるのは当然です。

　　　分析　　　

　過剰システムになる危険を防止するには、費用対効果でのアセスメントを強化することが重要だといわれており、「経営情報委員会」のような組織がチェックすることになっています。ところが、超バカマジメな人は、「システム化は絶対善であり、自分はその伝道師である。その恩恵に気付かない群集を改心させて正しい道に導くのだ」と信じ、いろいろな事例や論説を探し出しては熱心に説得します。委員会メンバーは、その熱心さに説得されてしまうでしょう。

　ユーザー部門に開発費用を持たせることにより、つまらぬ要求を防止できるかもしれません。しかし、委員会メンバーである上司は、あまり情報活用うんぬんの知識がありません。部下の主張を委員会で代弁することになります。特に、その部門が営業部門のように予算総額が大きく、情報化費用が相対的に小さい部門では、費用を付け替えられても大したことにはならないので、このようなことが起こりがちです。

　このように、バカマジメな人が不要にシステムを複雑にし、規模を大きくしてしまう元凶なのです。しかも、彼を阻止することは困難です。最も安全なのは、当初からバカマジメな人は絶対にプロジェクトメンバーに加えないことです。

ユーザーすら将来ニーズは分からない

　　　現象　　　

　業務環境は激変しています。現在のニーズは示すことができても、将来のニーズは分からない。それでシステム改訂が頻発するのです。

　情報システムのライフサイクルが短くなっているとはいえ、構築検討時点では、そのシステムを5年程度は使うと考えているでしょう。ユーザーは、現在のニーズは分かっているかもしれませんが、業務環境は激変しているので、5年後のニーズは分かるはずがありません。そもそも現行システムを構築した5年前に、当時のニーズに合致したシステムを作成したのですが、現在の状況を適切に把握できていなかったので、現行システムが役に立っていないのです。当時、将来の状況を予測したとしても、その予測はことごとく外れていたことが分かるだけでしょう。

　だからといって、ユーザーを非難するのは不適切です。環境が激変している状況では、経営者だって将来のことは分からないのです。ユーザー主導ではなく経営主導で構築することを標ぼうしているERPパッケージですら、構築数年後には大規模改訂から逃げられない状況になっているのです。

　「将来のニーズは分からない。そのニーズに気付いたときに即応できるシステムにしてくれ」というのが唯一正しいニーズでしょう。すなわち、保守改訂が容易にできるシステムが必要なのです。現在のニーズを金科玉条としてカミソリのようなシステムにしたら、保守改訂が困難になり、かえって不適切なシステムになってしまいます。

　　　分析　　　

　このように、あまりにもユーザーニーズを重視したシステムは不適切です。それよりも、保守改訂が容易にできるようなシステムにすることが大切なのです。

　保守改訂を容易にするためには、システム開発の段階から部品化を図るとかパッケージを利用するなど多くの方法論がありますが、最も単純なのは対象とするシステムの規模を小さくすることです。

　　データウェアハウスのように、販売システムや会計システムなどの基幹業務系システムで収集蓄積したデータをユーザーが任意の切り口で検索加工することを、情報検索系システムといいます。情報検索系システムが普及することにより、出力系の多くをそれに任せることができるので、基幹業務系システムの規模を小さく簡素化できます。また、過剰仕様の多くは出力帳票に関係しますが、それらを情報検索系システムにすることにより、開発規模を適正規模に抑えることができます。

　情報検索系システムでは、ユーザーに分かりやすく多様な用途に利用できるようにデータを整理しておくことが必要となります。情報検索系システムを前提として基幹業務系システムを設計すれば、自然と全業務を対象としたデータ中心へのアプローチになり、統合したシステムになります。

　このように、情報検索系システムの普及は効果が大きいのですが、その運用を誤ると多様な問題が生じる危険があります。それは「第9回：情報システム部門の生産性が上がらない理由」で示しましたが、これもユーザーが原因であることが多いのです。