システム管理者入門(6)

「統括部門IC」の提案


『Network Clipping』誌連載「システム管理者入門」の第6回です。 1997.9.pp56-59

 最近よく指摘される事項に「C/Sシステム環境における運用管理費用の増大」がある。それを回避するにはイントラネットが適切だとされ、ブラウザ志向が進んでいる。これは見ようによっては集中化である。コンピュータの分散/集中論は、歴史的にもスパイラル的に繰り返されているようだ。
 しかしここでは、分散・集中論には深入りせず、情報系システムにおける運用体制を検討したい。その結論は「統括部門ICの設置」である。

1 統括部門ICの設置

 IC(Information Center)とは、EUC支援グループのことである。EUCを円滑に運営するためには、情報システム部門内だけではなく、ユーザ部門にもICを置くことが重要であることはよくいわれている。営業本部や本社経理部のように全社の業務を統括している部門を統括部門というが、そこにもICを置くべきであると筆者は主張する。
 統括部門は、その関係する部門に対して業務を統括するが、統括部門ICは、業務への情報技術活用を指導し支援する。具体的には、個別処理メニューの作成と提供やデータマートへのデータの提供を任務とする。すなわち、情報システム部門が全社的な情報インフラの整備を担当するのに対して、統括部門ICは、業務に即した情報提供を任務とするのである(図1)。


2 個別処理メニュー提供方式

 情報系システムでの環境提供方式に、「1を押したら○○集計表、2なら××分析表」のように個別処理のメニューを画面表示して提供する方式がある。この方式はユーザにとって便利である。便利であるがために、多くのメニュー作成依頼が殺到する。特にC/Sシステム環境では、個々の現場のニーズに合わせることが目的であるから、ますますメニューが多様化してしまう。その結果、情報システム部門はその作成のために多忙になりバックログが増加し、ユーザはいつになっても対応してもらえない。これでは双方の不満が高まる。
 これを避けるために、これまでは個々の帳票ではなく、その基になる公開ファイルを提供し、簡易言語によりユーザが任意に検索加工するほうがよいとされてきた。ところが一般ユーザにとっては、「公開ファイル+簡易言語提供方式」はなかなか使いにくいのも事実である。個別処理メニューには問題があるものの、その便利さを考えると否定することはできない。
 そもそも個別処理メニューの作成を情報システム部門が行うことが不適切なのである。一般的に情報システム部門はユーザの要求をはねつけることが苦手である。あまり効果がないメニューだとは思っても、ユーザにその必要性を強調されれば、結局は作ってしまうことになる。
 ところが、統括部門ICがそれを受けるとなると事情が変わる。統括部門ICは情報活用を業務改善の手段として指導している。その観点に合致したものについては要求がなくても作成して、その利用を強制するであろうし、合致しない要求については、拒否するどころかそのような発想をすることに文句がいえる立場にある。個別処理メニューは統括部門ICが作成するほうがよいのである。


3 データマートの運営

 ここでは、全社的なデータの保管庫をデータウェアハウスといい、各部門のサーバに設置した目的別のデータ保管庫をデータマートと呼ぶことにする。部門のサーバは比較的容量が小さいので、ユーザの多様なニーズのすべてを満足させるデータを常駐させることはできない。さらにユーザニーズは時間と共に変化する。そのために、データウェアハウスからデータマートへの転送が頻繁に発生する。しかも、データマートのデータは、ユーザの目的に合わせて操作が容易でなければならない。それには、多次元データベースなどの形式にして提供する必要がある。
 これを情報システム部門が引き受けると、どうしてもユーザはそれに頼ってしまう。どのような用途にも使え、しかも操作しやすいようにすることを要求する。するとサーバの容量が足りなくなるが、それを増強するのが情報システム部門の任務だと思われてしまう。
 さらにユーザが「画面偏愛症」だったりすると、多次元データベースの画一的な画面ではなく、個別の画面やグラフ化を要求することになり、個別処理メニュー提供を強いられることになる。それを避けるためには、データマートに何を置くべきかを考え、必要なデータを加工転送する業務を統括部門ICが行うべきなのである。
 それには、統括部門ICの作業を容易にすることが必要になる。データウェアハウスのデータ体系をわかりやすくすることが必要であり、データを正規化し、加工しやすくするのが適切である。そしてデータを部品化して蓄えることが重要なのである。
 この作業は情報システム部門が行うべきである。すなわち、データウェアハウスに部品としてのデータを構築するまでが情報システム部門の任務であり、データウェアハウスからデータマートへ加工転送するのは統括部門ICの任務とするのがよい。


4 場所サーバと部門サーバ

 通常のC/Sシステム環境では、サーバはLANの構成に従って、事業所や階を単位に設置される。このようなサーバの設置形態を「場所サーバ」と呼ぶことにする。それに対して、全社の販売部門が共通のサーバを持ち、全社の経理部門が別の共通サーバを持つというように、部門別にサーバを設置する形態を「部門サーバ」と呼ぶ(図2)。

 現在では一般的に場所サーバが多いが、これには問題が多い。
 グループウェアについていえば、本社の販売部が情報の共有や伝達を行いたい相手は、本社の経理部や人事部よりも、むしろ支店の販売課であろう。データマートでも、東京支店で販売課や経理課など支店全体での目的別データを持つよりも、本社、東京支店、大阪支店などの販売部門で目的別データを持つほうが、共通したデータも多いであろうし、使うツールも共通したものが多いであろう。サーバを基幹系システムのデータエントリに使うこともあるが、おそらくその場合のマスタ類は、データマートと同様に、部門で共通したものが多く、場所での共通性は少ないであろう。
 それに、場所サーバではサーバ数が増えて、遠隔地に点在することになる。とかくサーバの管理は面倒であり、専任に近い者を必要とする。それが「C/Sシステム環境では管理コストが増大する」ことにつながっているのである。
 部門サーバの欠点は、事業所間ネットワークの回線費用がかかることである。しかし、将来は通信費用の低下が期待できる。また、インターネットの利用により、そのコストはかなり下げられよう。すなわち、将来的には回線コストは相対的に非常に安くなるのである。
 部門サーバにするなら、その設置場所はどこでもよい。統括部門ICに余裕があるならば、統括部門に設置すればよいし、データの転送やバックアップ、ソフトのバージョンアップなどの作業を重視するなら情報システム部門に置けばよい。一般的に統括部門と情報システム部門の距離は近いであろうし、同一ビル内の場合も多いであろうから、その違いはたいしたことではなかろう。
 部門サーバをすべて情報システム部門に置くのであれば、どうしてバラバラにする必要があろうか。データファイルは別途管理するにしても、ハードの筐体はまとめても支障はない。すると、いつの間にか集中化したことにもなる。


5 統括部門ICとローテーション

 情報システム部門とユーザ部門によるローテーションが重要なことは今更いうまでもない。しかし現実には、技術のベテランが営業の第一線に行ってもすぐに役立つとは思えないし、せっかくの技術知識が生かされるとも思えない。その逆も同様である。

      

 そこで図3のように、情報システム部門とユーザ部門の間に統括部門ICを置き、それをクッションにするのがよい。情報システム部門から統括部門ICに移ることにより、そこでユーザ部門の運営方針を理解すると共に、個別処理メニュー作成やデータマート運営に高度の情報技術を適用することができる。そして、ユーザ部門から統括部門ICに移ることにより、より現場ニーズに即したサービスを提供すると共に、情報技術を習得したり、情報システム部門の文化を吸収することができる。
 このような制度にすることによって、ローテーションによる戦力低下を防ぐことができるだけでなく、あまり増員することなく、統括部門ICを設置することができるのである。しかも、統括部門ICでの滞留時間を比較的短くすることにより、第4回で述べたパワーユーザの反乱を防ぐこともできる。


6 統括部門ICとBPR

 「今までの情報システム部門は、システムを作成することを主任務とするDP部門であった。これからは、経営戦略と情報技術を統合するIT部門になるべきだ」といわれる。筆者は、このような任務こそ統括部門ICの任務であると思う。 第2回で述べたように、日本の経営者にとって、重要案件の相談相手は情報システム部門ではなく統括部門なのである。統括部門こそ、経営者が積極的に参画している部門である。
 情報技術の調査研究は、その発展が急速なので、統括部門ICが行うよりもむしろ情報システム部門が行うほうが適切である。しかし、実際に面倒なのは、調査研究そのものではなく、関係者間でのコンセンサスを得ることなのである。そこで、情報システム部門と統括部門ICとのローテーションを活発にすることにより、情報システム部門と統括部門、さらには経営者とのコンセンサス作りが円滑になる。
 情報システム部門のアウトソーシングにおいて、最も重要であるにもかかわらずあまり話題になっていないのが、ユーザ部門の情報システム部門依頼体質である。アウトソーシングする場合、ユーザニーズを満たすには目に見えた費用が必要になる。そして、その予算獲得の説得が必要になる。費用対効果が明確になると、効果実現の責任が重くなる。ところがユーザ部門はそれに慣れていないので、アウトソーシング後にトラブルが発生する。そこで、図3にあるように統括部門ICの体制があれば、ユーザ部門は少なくとも情報システムの実務利用面については、情報システム部門に頼る必要がなくなる。これが大きな効果を生むのである。
 このように、統括部門ICは、これからの情報システムの活用には重要な組織である。したがって、この育成がシステム管理者の任務だといえよう。

      

○ おわりに

6回にわたって連載させていただきました。かなり偏見と独断に満ちた主張かと思います。しかし、筆者は、情報システム部門がしっかりと自己主張することが、企業での健全な情報システムの発展に貢献するのだと信じています。システム管理者各位のご活躍を期待して、今回で連載を終了させていただきます。ありがとうございました。


 目次へ  第1回へ  第2回へ  第3回へ  第4回へ  第5回へ  第6回