情報化白書（1996）によると、全産業の約１／３の企業がダウンサイジングを推進中であり、さらに約１／３が検討中であるという１）。このように、最近の情報システムは、メインフレームコンピュータ（以下、メインフレームという）を中心としたシステムから、クライアントサーバシステム（以下、ＣＳＳという）を中心とするシステムへと移行している。
ＣＳＳの普及は、単にコストダウンに効果があるだけでなく、情報システムのありかたに大きな影響を及ぼす。情報システム部門とユーザ部門（利用部門）の関係にも影響する。そのために、ＣＳＳの運営は経営的観点からも重要な関心事である。
ＣＳＳは、基幹系システムでのデータ入力や帳票出力、グループウェア、データウェアハウスでのデータマートなど多様な用途に利用される。そして、その中心になるのが、アプリケーションやデータを保管しているサーバである。
本稿では、サーバの設置形態を「用途サーバ」、「場所サーバ」、「部門サーバ」の三つに分類し、それぞれの設置形態について長所・短所を比較検討する。
ここでは対象とするサーバを次のように限定する。ＣＳＳにおけるサーバには、通信サーバやプリントサーバなど多くの用途があるが、ここではデータを共有することを用途にしたサーバに限定する。
また、その用途でのサーバにも、グループウェアでの電子メールや電子掲示板などのサーバがあるが、ここでは販売システムや経理システムなどの基幹系システムで収集したデータの利用を用途としたものに限定する。
この用途では、基幹系システムのメインフレームすらサーバということもあるが、ここではそのような大型のものは含まず、通常のＰＣ（パーソナルコンピュータ）あるいはＷＳ（ワークステーション）を用いたサーバを対象にする。
各事業所ごとに各用途別にサーバを設置するのでは、あまりにもコストがかかるだけでなく、データの管理も面倒になる。ここでは次の三つの観点でグループ化をした。
サーバは多様な用途に利用される。基幹系システム用サーバとか、データマート用サーバというように、用途別にサーバを持つことが考えられる。そのような設置形態ををここでは「用途サーバ」形態という。
また一般的に、サーバはＬＡＮに応じて設置されるので、本社や支店など事業所別あるいは各フロア別に設置されることが多い。このような基準で設置する方式を、ここでは「場所サーバ」形態と呼ぶ。
場合によっては、本社販売部は本社経理部よりも支店の販売課情報を共有するほうが重要なこともある。このような場合には、本社販売部や支店販売課などの販売部門全体として、一つのサーバを共有するほうが適切である。このように、場所を超えて業務部門ごとに設置する形態を「部門サーバ」形態と呼ぶ。
ＰＣを基幹系システムの端末として、データの入力をしたり、定型あるいは非定型の帳票出力をすることは以前から行われてきた。
データ入力において、データチェックを効果的に行うには、サーバに商品マスタや得意先マスタなどのマスタ類を置き、入力データをそれらと照合させるのが便利である。
また、入力データは、バックアップも兼ねて、当月分程度はサーバにも蓄積しておくのが通常である。サーバの容量が十分ならば、先月および前年同月のデータも保管できる。オペレーショナルな帳票出力では、発行伝票の確認、当月の売上状況、先月・昨年同月との比較などのニーズが大部分である。
すなわち、オペレーショナルな目的としては、サーバには各種マスタ類と、自部門で入力した当月のディテールデータ、前月、前年同月などのサマリデータを置くことが望ましい。
基幹系システムで収集蓄積したデータを、ユーザが任意の切り口で検索加工する処理形態を情報系システムという。最近話題になっているデータウェアハウスは、情報系システムの発展形態であるといえる。データウェアハウスは、全社的なデータの保管庫としての（狭義の）データウェアハウスと、ユーザの操作性を重視したデータマートに区分されるが、データマートはサーバに置かれるのが通常である。
日本企業では、ラインとスタッフが未分離であり、第一線のセールスが販売計画も立案することがある。計画立案とまではいわないまでも、担当得意先の分析などは日常的に行うことが多い。そのために、自部門が取引している商品や得意先について、時系列のデータを持ち、それを多様な角度で分析できることが要求される。このとき、直近のデータはディテールデータで持つこともあるが、長期的なものまでそうするのはデータ量が膨大になるので、たとえば月別集計のようなサマリ化をしたものになる。
すなわち、サーバにはＯＬＡＰ（Online Analytical Processing ）用のデータとして、マスタ類、直近のディテールデータ、長期時系列のサマリデータを置く必要がある。
ワークフローシステムの対象分野は多様であるが、ここでは購買処理とリース機器のクレーム処理を例にする。
購買伝票の起票処理には、購入品目や仕入先などのマスタ類が必要であり、承認処理には予算実績などのデータが必要になる。クレーム処理では、顧客の取引記録、機器構成、修理記録などのデータや、機器の保守マニュアルや保守技術者のスケジュールなどが必要になる。このように、ワークフローシステムは、従来の基幹系システムと共通するデータが多い。
ＣＳＳを導入する目的の一つは、各部門でのローカルな利用を活発にすることにある。たとえば売上管理では、セールス担当者別の売上成績などを支店内でのシステムで算出したり、商品や得意先を支店独自の観点から区分をして分類集計することなどがある。これらのためにも、基幹系システムでのマスタ類や売上データなどを、サーバに持つことが必要になる。
このように、各用途で必要とするデータは互いによく似ている。そのため、サーバを用途別に設置したのでは、データの重複が多く無駄が発生する。単一用途でのユーザ数が大きいとか、単一の用途にしか利用しない部門など、特殊な事情がない限りは、用途サーバ形態は不適切である。
それで、以降は場所サーバと部門サーバについて考察する。
サーバのありかたに最も影響を与えるのは、サーバに置かれているデータを誰と誰が共有するかである。それは当然、業務形態や企業文化によって異なる。
各事業所が独自の商品や市場を取り扱っており、他の事業所の日常的な動きを重視しなくてもよい業務形態であれば、情報を共有する範囲を事業所内に限定することができる。このときは場所サーバが適切である。
それに対して、各支店が同一の商品を取り扱っており、各支店の販売状況を本社や他の支店が常に把握しておく必要のある業務形態では、全社の販売部門がデータを共有する必要がある。このような場合には、販売部門全体で一つの部門サーバを使うのが適している。
本社と支店の関係が、本社が支店の動向を逐一把握したり指示したりしている環境では、支店の販売課は本社の販売部、経理課は経理部というように、部門別に本社と支店が結びついている。その場合には、支店の各部門は自支店の他部門との横の連絡は少ないので、サーバに置いた他業務のデータを相互に関連させる必要性は少ない。しかも、支店の計画や評価を本社が行うのであれば、支店にはそのためのデータを置く必要性も少ない。
このような業務集中型の環境では、おそらく支店のデータもメインフレームに集中している。そのデータを各事業所の場所サーバに返送するよりも、部門別に分けて部門サーバに入れるほうが簡単である。すなわち、業務が集中型のときは、場所サーバ形態よりも部門サーバ形態のほうが適切である。
それに対して、支店の独立性が高いときは、各支店で計画立案や業績評価をするので、自支店の販売や経理など多部門のデータを組み合わせた情報が重要になる。このような状況のときに部門サーバ形態にすると、他部門データを得るのが困難であり、場所サーバ形態が適している。各事業所が個別の顧客や商品を取り扱っている場合でも同様である。
すなわち、サーバの設置形態は、原則として業務形態や企業文化と一致させることが望ましい（図１）。
┌─────┬─────┬─────┐ │サーバ形態│場所サーバ│部門サーバ｜ ├─────┼─────┼─────┤ │業務形態 │ 分散 │ 集中 ｜ ├─────┼─────┼─────┤ │対象市場 │ 独立 │ 同一 ｜ ├─────┼─────┼─────┤ │本社統制 │ 弱い │ 強い ｜ ├─────┼─────┼─────┤ │支店独立性│ 強い │ 弱い ｜ └─────┴─────┴─────┘ 図１ 業務形態・企業文化とサーバ設置形態
現在では、ＬＡＮにくらべて事業所間の通信回線の伝送速度やコストが劣るなどのために、部門サーバよりも場所サーバの形態をとるのが一般的である。また、場所サーバでは、ユーザの近くにサーバが置かれるので、ユーザが心理的に近親感を持つ。これは、ユーザが主体的にコンピュータを活用するのに効果的である。
ところが、この形態ではサーバのコストがかかることや、サーバの要員が必要になるなどの問題点がある。
たとえば、東京支店には販売課や経理課など多くの部門があるとする。各課に個別のサーバを設置するのはコストがかかるので、多くの課で一つのサーバを共有することになる。すると、販売課のための売上データや経理のための売掛金データなど、多様なデータを一つのサーバで持つことになる。各課に固有なアプリケーションも一つのサーバで持つことになる。そのために、サーバに大きなディスク容量が必要になる
東京支店でも大阪支店でも同じような業務を行っている場合には、各サーバで同じデータを重複して持つことになる。たとえば、全支店が同一商品を取り扱っているときには、商品マスタが各サーバで重複する。他支店と同一得意先に取引をすることがあれば、得意先マスタや売上データも重複する部分が増大する。さらに、全社的なデータも各支店で必要とするならば、重複の度合いは非常に大きくなる。
場所サーバでの最大の問題点は、サーバを運営管理する要員が増大することである。ＣＳＳ環境は、メインフレーム環境に比べて、未だ安定性に欠けるし利用形態も複雑である。サーバのデータのバックアップやリカバリ、ハードウェアやソフトウェアでのトラブル対処など、かなり作業が面倒であり、しかも技術的経験を必要とする業務がある。
これらは、情報システム部門が遠隔管理するには限界があり、現地で管理する必要がある。ところが、ユーザ部門でサーバを管理できる人を育成するのは困難である。情報システム部門から人材を転出させるにしても、まだそのような業務をできる人が少ない。その状況で人材を転出するのでは、戦力が分散してしまう危険もある。
これらの要員業務は間接業務である。場所サーバ形態では、人件費、しかも間接業務の人件費が増加する危険がある２）。これはホワイトカラーの生産性を向上して、直間比率を改善しようとする動向に反する。
部門サーバの形態にすれば、たとえば販売部門のデータは各支店のサーバに分散せずに、一つの販売部門サーバに集中して持つことになるので、データの重複を防ぐことができる。また、サーバの設置場所は本社の統括部門あるいは情報システム部門になるので、サーバ管理のための要員も比較的少数になる。
しかし、この形態にも問題点がある。
部門サーバ形態での最大の問題点は、事業所間の通信回線が伝送速度も遅いし、コストも高いことである。従来のメインフレームと端末での利用であれば、データが文字データだけなので転送データ量もたいしたことはない。しかし、事業所間でＬＡＮ環境と同様なシステム利用をするには、プログラムやレプリケーションなどユーザが直接意識していない情報も流れるし、マルチメディアデータの利用があるので、非常に大きな伝送速度が必要になる。
部門サーバ形態では、各部門別の縦割り業務になりやすい。戦略的あるいは全社的な業務改革では、販売業務と経理業務を連携するようなデータの活用が必要になるが、この形態ではそれが困難である。
本来、ＣＳＳは、同じ販売課でも東京支店と札幌支店ではニーズが違うので、それぞれのニーズに合致するシステムにしようという目的があった。ところが、サーバを集中管理にすると、データの持ち方やアクセスの方法までも一律的にしてしまう傾向がある。
また、サーバがユーザの近くになく、情報システム部門に設置されていると、ユーザにコンピュータ利用で自主性を持たせることができにくい。そのために、ＣＳＳが設置されても、依然として情報システム部門依存の体質が継続しがちである。
サーバを取り巻く環境は激変している。その変化は、サーバの設置形態に影響を及ぼすものであるが、現時点では極端にどちらに有利になるかは判断できない。
・ ＰＣや通信回線の価格低下
ＰＣやＷＳの価格性能比は急速に向上している。それにより、サーバの台数やディスク容量の増大が費用的に問題にならなくなれば場所サーバに有利になる。逆に、通信回線の伝送量あたりの費用も低下しており、これは部門サーバに有利である。
・ 遠隔管理ツールの発展
回線管理やデータやソフトウェアの管理を行うツール、サーバ間のデータ同期のためのレプリケーション技術、分散データベース技術などが急速に発展している。これにより、現場でのサーバ管理者の仕事が低減するとはいえる。しかし現実には、サーバ管理者の仕事には、ユーザ教育や部門での情報化を推進する仕事がある。このような仕事に比べれば、遠隔管理ツールがカバーできる分野は比較的重要ではない分野だともいえる。
・ アウトソーシング
ＣＳＳ管理をアウトソーシングする動向もある。それにより、場所サーバでの管理要員が不要になるかもしれない。しかし、情報化推進などの業務は自社の人間があたるべきである。むしろ、メインフレーム業務をアウトソーシングして、情報システム部門から大量にユーザ部門に配転すべきだともいえる。
・ 利用形態の変化
データウェアハウス、ワークフローシステム、イントラネットなどの発展が期待されている。これらは、サーバの資源を多く利用するので、場所サーバ形態が有利といえる。しかし、全社的システムとの融合を重視すると部門サーバのほうが適切ともいえる。
以上の考察のように、場所サーバ形態も部門サーバ形態も長所短所がある。一般的には、業務形態や企業文化に合致した設置形態をとるのがよい。また、全サーバをどちらかに統一するのは、むしろ稀であり、ケースバイケースで混合形態をとるのが現実的である。
海老澤（1994）は、ある時点で一方の長所が他方の短所を打ち負かしたにせよ、やがてその長所が短所になるので、集中か分散かという短絡的な二者択一的論議は、不毛であり、問題提起そのものに本元的な危険があるとしている３）。
サーバの設置形態についても同じことがいえる。当初は場所サーバ形態が適切だとして設置したのが、経営環境や技術動向の変化により、部門サーバ形態にしたほうがよいというようなことは予想される。一方に決めておいて、後日急に他方に切り替えるのは、多くの困難を伴う。
・ ハードウェアの観点
場所サーバ形態を部門サーバ形態に変更するには、事業所間回線の増強や１台のサーバの能力増強などのハードウェア的な変更が必要になる。しかし、これは次の二つに比べれば、比較的容易に解決できる。
・ データ体系の観点
設置形態の変化により、サーバが持つデータの内容が大きく変化する。場所サーバ形態では当該支店のデータを個別に持っているが、部門サーバ形態にしたときには、支店データを個別に持つのは非効率的なので、全社データにまとめることになる。このとき、各支店でマスタにローカルな項目をつけていたり、ローカルなデータを持っていると、それらの取り扱いの調整が大変な作業になる。
逆に、場所データ形態に変更するときにも、単に全社データを支店別に分割するだけではすまない場合が多い。たとえば、東京支店管轄の得意先に大阪支店から出荷したとき、東京支店のサーバに大阪支店出荷データを持たせるかどうかなどの問題が発生する。
・ 組織や人の観点
部門サーバ形態では、サーバの管理運営は情報システム部門や本社の業務統括部門が担当するが、場所サーバ形態に変更すると、ユーザ部門が担当をすることになる。
これはユーザ部門の間接業務の増大になる。前述のように、サーバの管理運用は面倒であり知識経験を要するので、そのような人材をユーザ部門で育成し確保するのは大変である。ユーザ部門がその重要性を認識しないと、受け入れられない。
部門サーバ形態を長期間続けていると、情報システム部門への依存が強くなってくる。場所サーバ形態にするには、ユーザ部門が情報システムに責任を持つことや自主的に利用することが重要になるが、ユーザ部門の認識を変えることは、かなり困難であり、特に業務形態や企業文化とからんでくると、非常に難しくなる。
設置形態を変更するには、サーバに持つデータを変更しなければならない。データの変更は、設置形態変更のような本質的なことではなく、サーバの追加や利用部門の場所配置変更などの日常的な変化でも必要になる。
データ変更を容易にするためには、データの再編成を簡単にできるようにしておくことが必要である。それには、データを正規化しておくのが適切である。ところが、サーバでのデータは、操作性をよくするために、正規化を追求するには限界がある。
むしろ、サーバにデータを提供するメインフレームやデータウェアハウスでのデータを正規化しておくことが効果がある４）。このように、サーバの管理では、単にサーバだけを考えるのではなく、メインフレームなども含めたデータ管理が必要なのである。
一般論として、ＣＳＳの利用ではユーザの参画が重要である。しかも、ユーザニーズを提出するというレベルの参画ではなく、自分でサーバ運用管理をするレベルの参画であることが望ましい。しかし、すべて現場に任せるのでは、ややもすると現場ニーズだけが優先して、経営方針と合わないような状態になる危険もある。
それを避けるためには、統括部門（営業本部や本社経理部など、業務を統合する部門）に、情報活用支援組織（ＩＣ：Information Center）を設置することが重要になる５）。その位置づけを図２に示す。
たとえば営業本部は、本社の販売各部や支店の販売課などに対して、販売方針を示し、販売方法を指示し、結果の評価をする。情報システムは業務の仕方と合致していることが重要である。業務と情報技術を結びつけるのは、統合部門が適している。
┌──┐ ┌─┐ │ 情├────────┤エ│ │ 報│ ┌──┐│ン│ │ シ├────┤現場││ド│ │部ス│┌──┐│部門├┤ユ│ │門テ││統括├┤ＩＣ││| │ │Ｉム├┤部門│└──┘│ザ│ │Ｃ ││ＩＣ├────┤ │ └──┘└──┘ └─┘ 図２ ３つのＩＣ
ＥＵＣの普及には、情報システム部門にＩＣをおき、ユーザ部門にキーマンとかリーダという現場ＩＣを置くのが通常であり、その成熟期では統合部門ＩＣが必要であるが、サーバの運用管理においては、統合部門ＩＣが重要な位置づけになる。
統合部門ＩＣの任務は、その配下の部門に対して、業務の遂行に情報システムを活用することを推進し支援することである。部門サーバ形態にするときは、統括部門ＩＣがその運営管理をする。場所サーバ形態にするときは、データウェアハウスからデータベースへのデータのダウンロードや多次元データベースへの変換、情報系システムでのアプリケーション開発などを行う。
サーバの設置形態の変化には、組織的な対応が必要である。部門サーバ形態から場所サーバ形態に移行するには、現場での情報システムに関する責任の自覚が必要である。その説得と指導は、情報システム部門が行うよりも、業務を統括している統括部門が行うほうが受け入れられやすい。
また、場所サーバ形態から部門サーバ形態に移行する場合には、情報システムが実務から離れてしまう危険がある。この場合でも情報システム部門が受けるよりも統括部門ＩＣが受けるほうがその危険が少ない。このような理由により、統括部門ＩＣを設置することにより、サーバの設置形態の変更を比較的円滑にすることができる。
ダウンサイジングはかなり普及してきた。その中心になるのはサーバである。また、最近はデータウェアハウスが重視されているが、そこでもサーバはデータマートとして重要である。このようにサーバには多様な用途があるが、サーバにどのような用途でどのようなデータを持たせるかの検討が重要である。
サーバの用途や持つべきデータを検討するには、サーバの設置形態を考える必要がある。本稿では、部門サーバ形態と場所サーバ形態の得失を比較した。しかし、一般論として一方がより有利であるという論拠は見いだせない。当然なことであるが、自社の業務形態や企業文化により、選択することが必要である。しかし、経営環境は変化する。現在の業務形態や企業文化で設置形態を固定することは危険である。将来に設置形態が変化することを認識して、柔軟な対応をしておくことが必要である。
なお、ここでは設置形態について二極的な比較をしたが、データの転送や機器の管理の面から考えると、実際には複合的な形態になることが多い。また、検討が複雑になるのを避けるために、電子メールや電子掲示板などのグループウェアでのサーバについては対象外としたが、これはサーバの用途として大きな分野である。これらを含めて、さらに個々の事例について調査研究することが必要である。