ここ数回にわたって，ベンダーおよびベンダーSE，情報システム部門，CIO（最高情報責任者）といった企業のIT導入に関わる人々を，ユーザーの視点で取り上げ，そのあり方を検討してきた。今回はユーザーの視点でユーザー自身を取り上げてみよう。つまりユーザーの自己反省である。IT導入を成功させるためには，それも避けて通れまい。

　ユーザーと一口に言っても，ベンダーやコンサルタントから見たときは，ユーザー企業を意味する。しかし，ユーザー企業の中で情シス部門，CIO，あるいは経営陣から見ると，業務部門がユーザーとなる。今回は，後者のユーザー部門（ユーザー）を対象とする。

“あてがい扶持意識”が災いをもたらす

　ユーザーについて最も問題と感ずる点は，ある部門にITを導入するとき，発案するのはほとんどの場合，当該部門のユーザーではなく，情シス部門だということである。筆者の経験から見ても，ユーザーが自ら手を挙げたケースはごく稀（まれ）である。実に情けないことである。だから，IT導入については最初からユーザーは受身になり，最後まであてがい扶持の意識を払拭（ふっしょく）できないのである。この意識が，あらゆるところで災いすることになる。

　あてがい扶持の悲哀を，トコトン痛感した経験談を挙げよう。ここでは，A君のB事業所での経験としておく。B事業所は量産工場と言われていたが，非量産品が20％くらいを占めていた。A君は，非量産部門に属していた。事業所のコンピュータ管理は，当然量産システムを前提に敷かれていた。あるとき部長会議から戻った部長が，A君に「おい，我が部門にもいよいよコンピュータが導入されることになりそうだ。すぐ情シス部門へ行って相談しろ」と指示した。

　喜んだA君は早速，情シス部門へ飛んでいった。そして，情シス部門から指示されたとおり，コンピュータ導入の投資伺いに使用するための膨大な資料を時間と手間をかけて作成し，提出した。

　それから2カ月ほど経ったろうか，A君は投資伺いが認可されたという噂を聞いた。当事者である自分には認可されたという連絡がないのを不審に思いつつ，A君は情シス部門へ確認に出向いた。そこでA君は愕然とした。情シス部門の回答は「何の話か？」と言わんばかりのものだったからだ。

　A君の質問を受けた情シス部門は，「えっ！」と答えて，一呼吸おいてから「あっ，あれは量産システムの古くなったハードをリプレースしたかったが，量産管理ではもう効果が出ないので，非量産管理に導入するという口実で伺いを出したのさ」と答えた。A君は机を叩いて激怒したが，負け犬の遠吠えでしかなかった。

　その2，3年後に，A君たちは自部門に情シス部門の力を全く借りず，独力でコンピュータを導入することに成功する。それはさておき，ユーザーが自らIT導入のトリガーを引かないということは，ユーザーを取り巻くいろいろな問題の元凶になる。

　システム導入はユーザー主導で行くべきだ，というのは教科書の上での話で，実際は，発案のほとんどが情シス部門であり，ユーザーにとって他人事である。しかも，ユーザーはルーティーン・ワークに追われて，システム導入どころではない。場合によっては，何故俺の部門を導入部署に選んだのだと恨むケースまで出てくる。IT導入プロジェクトには，ユーザー部門からエース級の人材を出さなければならないのに，余剰人材を供出する始末だ。結局，A君が悲哀を感じたように，すべてが情シス部門のペースで進んでしまう。無力化したユーザーは，IT導入プロジェクトに非協力的な態度を取り，あげく天に向かって唾を吐くような結果を招くことになる。

要件定義に真剣さが足りず，全体最適の視点も持たない

　システム仕様の決定にも問題がある。要件定義は本来，ユーザー主導で行われなければならない。少なくとも，情シス部門がユーザーの意見や要望を十分聞き出して要件定義に反映しなければならない。しかし，要件定義に対するユーザーの対応が曖昧で，後になってから，「言ったはず」「言われていない」「現実と乖離（かいり）がある」「状況が変化した」などなど，いろいろな理由で仕様の変更や追加を出してくるケースが多い。

　確かに稼働してみなければ気がつかない部分があるだろう。情シス部門は，要件定義に際して，ユーザーに賢くなることをしばしば求めている。だが，筆者が見るところ，賢くないのではなく，真剣さが足りないのである。

　あるいは，的が外れているとも言える。例えばユーザーは，投資予算には全く無関心で（実際は，投資額を自部門で償却しなければならないのに），ローカルな要求に固執したり，趣味的要求を出したりする。自部門のことしか考えられないから，全体最適の視点を持てず，的を外すのである。

　システム構築，要件定義の際にユーザーの要望を十分聞き入れるべきことは，常識として語られている。ユーザーの方も，情シス部門が要望を聞き入れてくれなかったことを，システムが軌道に乗らない理由とする場合が多い。しかし，ユーザーの要望を聞き入れたことが却って災いとなることがある。何でもユーザーの意見を聞き入れればいいというものでもない。何故なら，ユーザーは部分最適を優先しかねないし，機能を増やしすぎた結果としてシステムが重くなりかねない。一方，ユーザーの側も本質とは無関係な些細な要求にこだわるべきでない。

　さてシステムが稼働を開始したとき，所期の効果を出すためにシステムを軌道に乗せるのはユーザーの責任である。そのとき最も重要なことは，何が何でもシステムを軌道に乗せるのだという気概と執念である。しかし，システムの生まれを他人事だと思っていると，最後まで淡白でいられることになる。これでは，システムが軌道に乗るはずがない。

　以上，筆者がユーザー出身であり，ユーザーの自己反省なので，厳しい指摘になったかも知れない。「そんなことは極端な例で，問題点を強調しすぎている」と言われるかも知れない。もちろん，あなたのところがこれに該当しなければ，別に腹を立てることはない。幸いなことだったと思えばよい。もし該当するなら，改善しよう。

　IT導入は，ユーザーが自己発案しなければならない。あるいは，情シス部門が導入を希望するユーザー部門を募集して，申告制にすべきである。経営方針からトップダウンで導入する場合も，その背景を周知徹底した上で，基本的にはユーザー部門から申告させるべきである。そうすれば，ユーザーは自分のこととして，導入に真剣になるだろう。的を外すこともなく，システムを軌道に乗せるために不退転の執念を持って臨むだろう。一方，ユーザー要求は節度を重んずるべきである。

　最後にひとこと付け加えさせていただく。ユーザーからの自己発案や申告がなければ，敢えてITを導入する必要はない。