
情報システム部門の生産性が
上がらない理由
――システム部門Q&A 第9回
木暮 仁
2004/6/5
| システムを利用しても生産性が上がらない理由 |
- - PR -
■1.情報システム部門の“過保護症”
情報検索系システムの普及に当たり、ユーザーには簡易ツールの習得やデータファイルの理解が困難だとの理由で(それを説明するための努力が大変だとの理由もありますが)、個別帳票メニュー提供形式を採用しがちです。個別帳票メニューは一見便利なのですが、ユーザーの多様なニーズに応じて多くのメニューを作成するために、情報システム部門の労力は増大してしまいます。
そこで「公開ファイル提供方式にしよう」ということになりますが、今度は多ファイル症候群、ラージファイル症候群になる危険があります。多ファイル症候群とは、○○帳票出力用ファイルのような「帳票直前ファイル」群を提供することです。「ユーザーが適切なファイルを特定するのが困難だ」とか、「ジョイン(RDBの結合)処理の概念が難しい」との深情(?)により、結局、多様なニーズに合わせて多くのファイルを作ることになるので、情報システム部門の労力は増大したままです。
あるいは少数のファイルで何でもできるようにと、非常に多数の項目で各コード項目の名称も加えたファイルを提供することで陥るラージファイル症候群があります。そのため大容量になり、レスポンスは悪化します。このようなファイル提供では、ファイル群の維持管理も困難になります。
■2.ユーザーの“過度体裁愛好症”
情報システム部門が「過保護症」ならば、ユーザー側にも「過度体裁愛好症」があります。
例えば、支店別府県別売上集計を得たいとき、図1のような小計・中計・大計のベタ打ちの表を作成するのであれば、汎用的なツールを簡単に入手できます。ツールではこの作業が10分でできるとし、手作業では1週間かかるとすれば、生産性はかなり向上します。
|
|
ところがユーザーはこれでは満足しません。図2のように、すぐけい線を引きたがります。また、大計・中計・小計のようにデザインしたくなります。そうなるともはや汎用ツールは使えません。さらに数表だけではつまらないので、グラフにしたがります。それも表計算ソフトの標準グラフではあまりにも平凡ですので、図3のような「作品」に仕上げます。
![]() |
| 図3 集計表を「作品」に |
当初から図3にするのならば大したことはありませんが、そこに至るまでに、いろいろな努力をするのですね。決して図3で満足したのではなく、努力している間に1週間が過ぎたので、仕方なく打ち切ったのです。すなわち、パソコンを利用してもユーザーの生産性は向上しないのです。
ここで注意するべきことは、図1から図3までのプロセスにおいて、体裁はよくなったでしょうが、特に情報が追加されたのではないということです。本来の業務は名古屋支店の業績を改善することですから、11分後には上司に報告して対策を練る必要があったのに、図1→図3の作業が必要だとは思えません。すなわちサボっていたのです。ヒマなときは喫茶店でサボる人もいるでしょうが、その場合はサボっていることを自分も周囲も知っています。忙しいときにそんなことはしません。それなのに、図3にしようとパソコンに向かっていると、自分も周囲も真剣に仕事をしているような錯覚をしてしまいます。
しかも、この現象は周囲に伝染します。A君が図3のような帳票にしているのに、Bさんは図1を部長に見せるわけにはいきません。“超図2”にしようと頑張ります。この結果、「全社員のコピーライター化」という現象が出現し、組織的なサボタージュが堂々と行われることになります。しかも、ユーザーが表計算ソフトの知識があれば図1や図2を自分で作れますが、知識のない人に過度体裁愛好症と過度依存症が併発すると、このような2次加工までも情報システム部門や周囲の人に依頼するようになります。
| では、どうするか? |
上記のような状況を回避するために、情報検索系システムの運営で留意するべき事項を列挙します。
■1.ユーザーに最小限の知識を強制する
図4のように、ユーザーの便宜性を追求すれば、情報システム部門の負荷が増大するし、情報システム部門の負荷を減少させるには、ユーザーの知識向上の労力が増大します。両者の合計が最小になるのが最適な方法ですが、現実にはユーザーの過度依存症と情報システム部門の過剰保護症のために、かなりユーザー便宜性側に偏っているケースが多く見られます。
![]() |
| 図4 ユーザーと情報システム部門の負荷の関係 |
車の運転には免許が必要なように、情報検索系システムの利用でも、最小限の知識が要求されます。それにより全体費用が急激に低下することを認識させる必要があります。
個別帳票メニュー提供方式は便利ですが、それですべてをカバーさせることはできません。むしろ、公開ファイル提供方式をベースにして、個別帳票メニュー提供方式はよく用いるもの、あるいは加工が複雑になるものなどに限定するべきです。ユーザーが個別帳票メニュー提供方式に慣れてしまうと、後で公開ファイル提供方式に切り替えるのが困難になります。
なお、個別帳票メニュー提供方式でのメニュー作成を情報システム部門にさせると、情報システム部門は過剰保護症により、それに無節操に応えようとするので、それを業務統合部門の支援グループにさせるのが適切であることは、前回の「システム部門縮小化に打ち勝つ!」で示しました。
■2.オンライン・ユーザー辞書を整備する
最小限必要知識を引き下げる工夫をする必要があります。それには使いやすい簡易ツールの導入は効果があるのは当然ですが、それにも増して、データやファイルの解説書(ユーザー辞書)を作るのが効果的です。すなわち、用語(項目名)の統一をして、その意味を明確にすること、ファイルでは上記の売上数量や売上金額のような疑問に対する説明を記述した辞書を作り、それを簡易ツールと連動したヘルプ機能として組み込むようにします。
また、先に行った処理をプロトタイプとして登録しておき、それを必要に応じてカスタマイズできるような機能も必要です。そのプロトタイプもユーザー辞書に組み込んでおきます。このようにすれば、公開ファイル提供方式での利用に必要な知識を大幅に減少させることができます。逆にいえば、ユーザー辞書を組み込みやすい簡易ツールを採用することが重要です。
■3.利用現場での指導が必要
過度体裁愛好症を予防するのはかなり困難です。現場での上司や情報化リーダーが適切に指導・注意するしかありません。情報化リーダーの人選が重要です。パソコン坊やを任命すると、業務の遂行よりもパソコン技術(帳票体裁の改善)に興味を持ち、その技術を広めようと努力します。過度体裁愛好症のウイルスをまき散らす危険があります。
■4.利用部門に自覚させる
そもそも情報検索系システムは、ユーザーのニーズに起因するのですから、ユーザーがそれなりの努力をするのが当然です。それが、どういうわけか情報システム部門が情報検索系システム普及の責任者にされてしまいます。それが問題の起源なのです。
ところが以前は、ユーザーは情報が必要になると、情報システム部門へ「おーい木暮、○○を出してくれ」と電話をすればそれでOKでした。すなわちユーザーは音声応答・AI(人工知能)付きのコンピュータを持っていたのですから、情報検索系システムのような不便な代物には関心がありません。それで情報システム部門は、ユーザーに頼み込むことになります。それを説得するために過剰サービスをすることになり、それが過度依存症を招く原因になります。
ダウンサイジング環境での総費用TCOが大きいことが指摘されていますが、そこでも過度体裁愛好症による組織的サボタージュは認識されていません。これを加えたらTCOは非常に大きくなりましょう。このような見えないコストを利用部門に自覚させる必要があります。
| |
2/2
|
第10回へ |
| INDEX | |
| 情報システム部門の生産性が上がらない理由 | |
| Page1 | |
| 個別帳票メニュー提供方式と公開ファイル提供方式 | |
| なぜユーザーは情報検索系システムを使わないのか | |
| Page2 | |
| システムを利用しても生産性が上がらない理由 | |
| では、どうするか? | |
|
この記事に対するご意見をお寄せください |
managemail@atmarkit.co.jp |
|
|
||||||||
■要約
ユーザーが情報検索系システムを利用しないのは、必要なときに情報を得られなかったり、データやファイルが分からないといった理由が挙げられる。またシステムが業務部門に定着していても、それでシステム部門・ユーザー部門双方の生産性が上がるわけではない。システム部門はユーザーに対する過保護の念から、多数のファイルを用意して、その開発・管理に忙殺されることもあるし、ユーザー側は「どうせなら見栄えのいい書類を作ろう」と、無益な作業に没頭することもある。 こうした事態を防ぐため、(1)ユーザー側に最低限のIT教育を施す、(2)オンライン・ユーザー辞書を整備する、(3)書類作成作業に没頭しないよう、利用現場で指導を徹底する、(4)利用部門に「情報系システムは誰のためのものか」という自覚をうながす、といった取り組みが必要になる。 |
||||||||
|
|
||||||||
| ▲記事の先頭<Page1>に戻る |
|
システム部門Q&A バックナンバー
- 第1回 IT書籍やコンサルタントが“使えない”理由
- 第2回 なぜ情報化投資は初期計画より増えるのか?
- 第3回 社内から必要とされるITスタッフを育成するには
- 第4回 IT投資効果の算出法は本当に役に立つのか?
- 第5回 コンサルタントを賢く活用する秘策
- 第6回 ERPのカスタマイズを最小限に抑えるには
- 第7回 バランスト・スコアカードで業績が上がるか?
- 第8回 システム部門縮小化に打ち勝つ!
- 第9回 情報システム部門の生産性が上がらない理由
- 第10回 情報システム部門を戦略部門化できるか?
- 第11回 セキュリティ対策、社内の協力を仰ぐには?
- 第12回 RFPの作成方法が分からない!
- 第13回 ここまでやればRFP作成工数は削減できる
- 第14回 データウェアハウス中心アプローチで問題解決しよう
- 第15回 パートナーベンダの見直しは慎重に!
- 第16回 システム開発におけるユーザーニーズは絶対か?
- 第17回 健全なEUC推進に適した組織とは?
- 第18回 素人IT部長に望むこと
- 第19回 素人IT部長に望むこと(2)
- 第20回 会計原価を損得計算に使うな!
- 第21回 会計原価を損得計算に使うな!(2)
- 第22回 情報共有化の障壁を突き崩せ!
- 第23回 なぜ、ITコンサルタントに依頼が来ないのか?
- 第24回 企業合併でシステムが止まらない方法教えます!
- 第25回 素人CIOとの上手な付き合い方とは?
- 第26回 ユーザー企業のIT部員育成はどうすればよいのか?
- 第27回 社内用語・概念を整理する「ユーザー辞書」は役立つ
- 第28回 いろいろある基準をどう考えて、どう使うか?
- 第29回 中小企業がERPパッケージを成功させるには?
- 第30回 オープン化とERP導入は今年中に終わらせよう!
- 第31回 部門のエゴによるデータ公開反対運動を回避せよ
- 第32回 新技術ラッシュをいかに乗り切るか?
- 第33回 文系学生はIT関連科目で何を学べばよいのか?
- 第34回 日本版SOX法はIT部門にとって脅威か機会か?
- 第35回 行政のセキュリティ投資はどうするべきか?
- 第36回 オープンシステム移行による弊害を断罪する
- 第37回 IT部門が頼りなくなった原因はなんだ?
- 第38回 ユーザーが満足する提案ができません
- 第39回 経営者が可視化を理解できないのはどうして?
- 最終回 どうしたら、しこりなくローテーションができるのか?
| 「システム部門Q&A」バックナンバー |
|
ホワイトペーパー(TechTargetジャパン)
|
|





