経営とＩＴの関係の歴史的変遷

日本の大企業が本格的にコンピュータを導入し始めたのは１９６０年代中頃である。当時のコンピュータは性能が貧弱でで、プログラミングもオペレーションも技術知識が求められ煩雑な作業を必要とした。未だ海のものとも山のものともわからないことに熱心に取り組む連中は、一般社員からみれば変人・奇人にみえた頃である。

黎明期のコンピュータ

１９５５年に東京証券取引所と野村證券が導入したUNIVAC120が日本で最初の商用コンピュータである。その後、１９６０年代前半にかけて民間企業では大銀行や製造業の（超）大企業に導入されたが、一般の企業には高嶺の花であった。
　当時の主力機は輸入機であり、１９６０年代初頭になるとＩＢＭ機がそのほとんどを占め、「ＩＢＭ」がコンピュータの代名詞のようになっていた。コンピュータ室あるいはコンピュータ部門を「ＩＢＭ室」と呼ぶこともあった。国産メーカーは「君のところでもＩＢＭを作っているの？」と聞かれたとか。
参照：「汎用コンピュータの歴史 １９５０年代」、「同左　１９６０年代前半」

当時のコンピュータは、ガラス張りの室に鎮座し、白衣を着用していた操作者は神官のように見えた。さすがに白帽はつけていなかったが、スリッパに履き替えることはかなり後まで続いた。
　コンピュータは企業のステータスシンボルであり、１階の道に面したショーウインドウのような場所に置かれたり、見学者コーナーまで備えたりするところもあった（１９７５年に建設会社の間組のコンピュータが暴徒により襲撃された。それを機会に、コンピュータの存在場所を秘密にするようになった）。

１９６０年代中頃のコンピュータ

１９６０年代中頃になると、国産メーカーも本格的なコンピュータを開発するようになっていた。１９６４年にＩＢＭはその後の汎用コンピュータのベースとなるＩＢＭ３６０シリーズを発売したが。国産メーカーも１９６５年に、日本電気がＮＥＡＣ２２００シリーズ、富士通がＦＡＣＯＭ２３０シリーズ、日立がＨＩＴＡＣ８０００シリーズなどの対抗機を開発した。
参照：「汎用コンピュータの歴史 １９６０年代後半」

私が所属していた企業（以下「当社」という）では、ＦＡＣＯＭ２３０－２０を導入した。当時の典型的な中型コンピュータであり、以下の仕様等は私の「うろ覚え」であるが、平均的な構成であった。写真は松本市のものであるが、ほぼ同じような構成になっている。

ＦＡＣＯＭ２３０－２０
出典：松本市「松本市写真集 １９７０年その２」

［本体・周辺装置］

• 本体：ＦＡＣＯＭ２３０－２０
• メモリ：６４ｋキャラクタ（３２ｋＢ。ＭＢではない！）
• 外部記憶：磁気テープ装置４台
  （このレベルでは磁気ディスク装置はなく、磁気テープの一つにＯＳが入っていた）
• 入力装置：紙テープ読取装置１台
  （紙カード読取装置もあったのだが、カードにするには穿孔機が高く、導入当初は紙テープにすることが多かった）
• プリンタ：インパクト型ラインプリンタ１台（目読できる程度の速度）
• 操作卓：ゴルフボール型のタイプライタ

［ソフトウェア］

• ＯＳ：名称は忘れた
  マルチプログラミング機能なし（一度に一つのプログラムしか処理できない）
  仮想記憶機能なし（プログラムの大きさを考慮する必要あり）
• プログラミング言語：アセンブラ（すぐにＣＯＢＯＬが使えるようになった）
• 文字種：英数字、特殊文字、半角カナ

［設備］

• 床上式。床下に配線や冷却管などを敷設
• 空調設備：２０°Ｃに抑える必要があり、３台の空調機があり、図体ではこれが最大だった。

総費用は２００万円／月程度だったと記憶している。コンピュータと周辺機器のレンタル費用だけであったか、光熱費や消耗品なで含んでいたかはあいまいである。ちなみに、大学卒男子の初任給は２万円程度であった。

大変なプログラムの作成作業

ここでは単体テストの範囲に限定する。当時の環境では、単体プログラムのエラーをなくすだけでも大変な作業だった。

• フローチャートの作成
  コーディング以前に、１命令を１つの図形にまで落としたフローチャートを作成するのが通常だった。当時は未だコーディング作法が確立しておらず、ＧＯＴＯ命令を多用するロジックを組むのが通常であり、図化しないとロジックを組み立てるのが大変だったし、後日、プログラムを修正する場合でもフローチャートのほうがわかりやすかったからである。
• 多様な文書作成
  当時はデータベースの概念がなかったので、入出力のファイル仕様、１レコードの各項目を、何桁目から何桁でどの型であるかを個々のプログラムで記述する必要があった。しかも、当時はメモリや磁気テープの容量を少なくすること、入出力速度を上げるために、ファイルには必要最小限の項目だけをもつことが要求されたため、個々のファイルが異なったデザインになることが多かった。これも目視しやすいようにファイルデザイン用紙に記述するのが通常であった。
  当時は漢字やかなの文字種がなく、フォントも一つだけだった。そのため、出力帳票は見出しや項目名などを事前に印刷した用紙を用いる必要があり、アウトプットデザイン用紙で示すことが多かった。
  このように、ソースコード記述以前に多様な文書をそれぞれの用紙に記述する必要があった。これらの作業をプログラミング、これらの文書からソースコードに書き直す作業をコーディングといって区別することもあった。
• コーディング
  現在ならば、ソースプログラムをキーボードで入力し、「実行」を指示すれば直ちにコンパイルされ、エラーがあればディスプレイに表示され、その個所を直接修正して再実行できる。ところが、当時は紙テープあるいは紙カード（写真）に穿孔したものをコンピュータにかけたのである。
  穿孔機はタイプライタのようなものである。打ち損じた場合、カードならば誤りのカードを廃棄して打ち直しし、テープの場合はその部分に戻して無効コード（全穿孔）にして打ち直すという作業になる。このような作業なので、穿孔作業は専門の人（パンチャーといった）に依頼するのが適切である。それで、ソースコードはコーディング用紙（アセンブラ用、ＣＯＢＯＬ用など言語ごとに専用紙があった）に記述していた。文字通り「プログラムを書いて」いたのである（英字のＯと数字の０を区別するためにＯをＯあるいは０をφと書いたり、英字のＩを数字の１と混同しないために小文字のｉとすることが推奨された。今でも～ＴｉＯＮと書く老兵がいる？）。
• コンピュータ待ち
  当時のコンピュータは、マルチジョブ機能がなかった。売上計算をしている間や他の人がプロづグラムのコンパイルをしている間は、待っていなければならない。長い時間待ってコンパイルしたらエラーになり、行列の最後に並んで～などの繰り返しであるから、一つのプログラムが完成するには長時間かかったのである。
  エラーの修正も大変な作業である。カードであれば、カードに文字が印刷されていることが多いので、目視で対象カードを探して廃棄し正しく穿孔しなおしたカードと差し替えればよい。それでも探すのが大変などで、ＦＯＲＴＲＡＮなら命令文は７２桁目までに記入し、７３桁目以降８０桁目までに順番（カード番号）記入するようになっていた。テープの場合は、文字印刷がない場合が多く、穿孔をみて該当場所を探し、その部分を鋏と糊で修正するという面倒な作業であった（プログラマからカード要求の抗議があがった）。
  プログラム作成の生産性を向上するには、コンピュータを使わないデバッグ（机上デバッグ）が重要だとされた。

このようにコンピュータ導入当時では、プログラム開発（コーディングまわり）に多大な時間や労力がかかっており、システム構築費用の大部分を占めていた。このときの慣習が現在も根付いており、システム構築の工数や費用を算出するのに、ソースコードの行数をベースにしていることが多く、ソフトウェア産業の健全な発展を阻害していると指摘されている。

当時の対象業務＝基幹業務系システム

現在は「コンピュータ」が一般名称になっているが、１９６０年代では「電子計算機」（電算と略す）といわれていた。カッコよくＥＤＰＳ（Electronic Data Processing System）とも呼ばれた。文字通りデータ処理の電子化である。
　当時の日本は高度成長期であった。経済発展に伴い事務作業量が増大し、求人難や人件費が向上する。もはや手作業では限界にきており、コンピュータは大きな期待がもたれた。しかし、当時のコンピュータは高価である。しかも、プログラムを作成してシステムを構築するのには多くの費用がかかる。
　そのため、最初にコンピュータ利用の対象になったのは、
　・大量データであること（省力化効果が大）
　・定例的・定型的な業務（プログラムが繰り返し利用できる）
が優先された。具体的には給与計算、売上計算（請求書発行）、会計処理（財務諸表作成、固定資産管理）などである。
　このような業務データは、後に出現するＤＳＳやデータウェアハウスなどでの多様なデータ加工分析の基礎となるものであるから、基幹系業務システム（あるいは基幹系システム）と呼ばれている。

データの入力と処理

売上データなどの入力は、ごく初期では、現場（データ発生部署）で起票した手書き伝票をコンピュータ室に送り、紙テープに穿孔した。しかし、当時はすでに、紙テープに穿孔するとともに伝票形式で印刷できる装置が開発されており、現場での入力データ作成ができることになった。これは、原始データの責任明確化の観点からも望ましいことである。
　紙テープは、とりあえず磁気テープにコピーして使うのであるが、その作業も並行処理ができないのでコンピュータを占有してしまう。

データのチェックが大変だった。当時の中型機でのファイルはＳＡＭ（順編成ファイル、常にファイルの先頭から順にアクセスする）しか使えなかったので、得意先マスタや商品マスタなどのマスタファイルもＳＡＭファイルである。ＳＡＭファイル間の照合処理をするには、あらかじめ照合コードでソート（整列）しておく必要がある。およそ、次のような手順であった。

1. 各支店から送られてきた紙テープを磁気テープに変換する際に、１レコード内でできるチェック（桁位置や数字のチェックなど）を行う。
2. すべての紙テープからの変換が終了したら、それを１つの磁気テープ（本日売上ファイル）にまとめる。
3. 本日売上ファイルを品名コードでソートして、品名マスタと照合する。同様に、得意先マスタなど照合すべき項目ごとに本日売上ファイルをソートして照合する。
4. 当日売上ファイルには、新規追加データだけではなく、前日までの累積ファイルのデータの削除や更新のデータもある。その処理のために、本日売上ファイルを累積ファイルと同じキー項目でソートして、各処理を行うとともに、本日までの累積ファイルを作成する。
5. これらのステップにおいて、エラーになったレコードや削除・更新したレコードをファイルに記録しておき、送られてきた紙テープの区分に従って印刷し（プルーフリストという）を現場に返送する。現場は、それを確認し、修正データを次の紙テープ作成時に取り入れる。

遠隔地の現場にはプルーフリストをＦＡＸで送付するなどの工夫をするが、当月のデータがすべて確認され請求書発行ができるまでには多くの日数がかかってしまうこともあった。

ソート処理は照合や作表など多くの処理で多様される。コンピュータ利用実績を分析するとソート処理が群を抜いて多い。それで、ソートをいかに減らすか、高速化するかが大きな関心だった。システムエンジニアやプログラマがコンピュータ効率向上に腕を発揮できた時代であった。

• 磁気テープ装置の台数を増やすことにより、ソート時間を減らすことができる。初期導入からの増強では、ソート時間短縮のための磁気テープ装置追加が多かった。
• 一般にソートプログラムは、コンピュータメーカーからサービスプログラムとして無料提供されるが、あえて有料のプログラム（SYNCSORTが有名）を購入することもあった。
• 最初の照合時にマスタの項目（商品名など）を売上ファイルに取り込むことにより、その後の商品名を使うための照合処理をなくすことができる。しかし、それにより１レコードの長さが大きくなると、ファイルの保管容量が大になるし、アクセス時間が長くなる欠点がある。どの項目をどの処理で取り込むかがシステム設計での重点の一つであった。
• コード存在の有無だけを目的とした照合ならば、マスタファイルの主キーだけを取り出してメモリに保管することにおり、メモリ内でバイナリサーチをすればよい。主キーが多い場合には、頻度別に取り扱うようなプログラムを作ればよい。このような工夫により、処理時間を数十分の一にしたような例は多かった。

アウトプットの処理も大変だった。当時のプリンタは低速だったので、数部印刷するにはカーボン紙を挟んだ数枚セットになっている連続用紙を用いていた。それをはがして１枚ごとにするのにセパレータを用いるが、カーボンで手が汚れるといって女子は敬遠するし、男子は気が短いので高速にして連続用紙をジャムったり破いたりするトラブルが多かった。
　セパレートした連続用紙を１ページずつに切り離すのにカッターを操作するが、ここでもジャムったり破いたりするトラブルが発生する。さらに、送り先別に手作業で仕分けするのだが、得意先請求書に誤って他の得意先のページが入ると、単価などの秘密が漏えいするので始末書程度ではすまない場合もある。送り先が変わるたびに区切り用のページを印刷して、梱包の表紙にするなど、多様な工夫をしたものである。

このように当時のコンピュータは人手がかかった。コンピュータにより経理部や人事部が減員した人数よりも、コンピュータ関連の増員のほうが多かったという現象すらあった。

コンピュータ導入の指導原理

「コンピュータを導入したから儲かるのではない。業務の見直し、経営の革新によって儲かるのだ」ということは、当時もいわれていたことである。

• 省力化ではない増力化だ
  大量データ単純処理の無味乾燥な業務を省力化することにより、人間をもっと付加価値の高い業務につかせることができる。「コンピュータにできることはコンピュータに」という考え方である。そのため、省力化ではなく増力化であるべきだともいわれた。
  　これとは異なる考えもあった。一部の製造業では、設備の仕様や運転における最適化のためのＯＲや技術計算にコンピュータを使うほうが効果的であり、「人手でできることにコンピュータを使うな」といわれた。当時のコンピュータの特性を考慮した正論でもあった。しかし、コンピュータの価格が急激に低下するのに伴い、ほとんどの企業が基幹業務系システムを対象にするようになった。
• 業務の見直しをせよ
  事務処理の機械化だとはいえ、単に従来の手作業をコンピュータシステムに置換するのではない。手作業と機械化ではそれぞれ適した処理手順がある。機械化することにより不要になる手続きもあるし、標準化が必要になるものもあろう。コンピュータ導入を機会に、業務の抜本的な見直しを図るべきだとされた。 →参照：「手作業と情報システムの違い」
  　例えば、手作業時代では、全社統合したデータ把握や施策が行われていなかった（できなかった）ので、東京本社と大阪支店が異なる慣習で業務を行っていても、大きな問題にはならなかった。しかし、機械化にあたって、全社を統合した情報のメリットを追求するのであれば、業務の標準化が重要になる。また、コンピュータ部門の立場からすれば、東京本社用や大阪支店用など多様なプログラムを作成するのでは非効率である。
  　当時の小話「コンピュータで成功する秘訣」。社長は「コンピュータ導入をする。それに先立って、徹底的な業務見直しをせよ」と指示する。業務改善がかなり達成したら「やはりコンピュータは高いのでやめた」といえばよい。
• ＧＩＧＯ（Gabbage In, Gabbage Out）
  「コンピュータは期待したようには動作しない。命令した（プログラムした）通りに動くのだ」とは、プログラマへの注意であるが、データ作成者にはＧＩＧＯが力説された「間違ったデータを入れれば間違った結果しか出てこない」ということである。
  　しかし、人間は誤りをする。しかも、手作業では転記をするときに不審なデータに気付く機会があるが、いったんコンピュータに入ったデータの確認機会は少ない。それでデータ入力時に厳重なチェックをすることが重要である。これが、前述のデータ入力でのソートの多発につながるのである。
• 入力は１回、利用は多数回
  データ入力が厳しいことは、同じようなデータを何度も入力させるなということにつながる。例えば、販売システムでの売上データは、会計システムの売掛金ファイルになるので、会計システムで売掛金データを入力させないようにすべきである。また、それができるように、販売システム設計時に会計システムも考慮して売上ファイルを設計すべきである。
  　このように個々のシステムを個別に設計するのではなく、全体のシステムのサブシステムとしてとらえることが必要だとされ、１９６０年代後半にはＩＤＰ（Integrated Data Processing）といわれた。
  　ところで、ＩＤＰの考え方は米国よりも日本のほうが自然に取り入れていたようである。日本では、費用の関係から１台のコンピュータで多くの業務を処理していた。販売システムも会計システムも同じコンピュータ部門が構築し同じコンピュータで処理している環境ならば、あまり意識しなくてもファイルの互換利用をしやすい。それに対して米国では、新規のシステムを構築するだびに、その業務の専門家をスカウトして開発させた。すると、既存のシステムやコンピュータを意識せずに開発するほうが簡単などで、新規システムごとに新しいコンピュータを導入したのである。１９６０年代末期に米国のコンピュータ室を見学したことがあるが、広い室に多数のコンピュータが並んでおり、オペレータの作業を効率化するためにローラースケートを履かせたいと思っていると聞いたのには驚いた。米国では、このような状態だったので、ことさらにＩＤＰがいわれたのであろう。

急進的なコンピュータ部門

現在では、とかくコンピュータ部門が消極的で経営に関する提案をしないことが批判されている。ところが、１９６０年代のコンピュータ部門は、まさにチェンジング・エージェンシーだったのである。経営者にコンピュータ利用の効果を進言し（騙し）、利用部門に業務改革を説き（脅迫し）、コンピュータ利用を進めてきたのである。
参照：「ＩＴ部門の変遷　変革の尖兵としてのＩＴ部門」

• １９６１年　ガルブレイス（J.R.Galbraith）、「Management Information Systems and The Computer」によりＭＩＳを提唱（日本語訳は１９６７年出版）
• １９６４年　ダートマス大学、初の実用的ＴＳＳを開発
• １９６６年　ＩＢＭ、階層型データベースであるＩＭＳを発表
• １９６７年　日本生産性本部「ＭＩＳ視察団」派遣
• １９６７年　アコフ（R.F.Ackoff）、「Management Misinformation Systems」で、ＭＩＳ構築での「誤った仮説」を提示。
• １９７１年　ゴリー＆モートン（G.A.Gorry & M.S.Scott Morton）、「A Framework for Management Infirmation Systems」発表。広く読まれたＭＩＳの文献

ＭＩＳの概念

豊富な情報をタイミングよく経営者に提供することができれば、経営者は適切な管理統制ができ、正しい意思決定ができる。コンピュータをそのような目的に活用すべきだというのがＭＩＳ（Management Information System：経営情報システム）である。

１９６７年に日本生産性本部は米国にＭＩＳ視察団を派遣した。当時の各界のオピニオンリーダーが参加し、その報告書は日本のＭＩＳブームに火をつけた。
　多分にメーカーの戦略であろう。ＭＩＳは企業経営の革新であり、採算計算を度外視して、生き残りのためにコンピュータの導入や増強が必要なのだといわれた。当時、田原俊彦が「社長！　ＭＩＳをやりましょう！」と叫ぶＮＥＣ（だったと思う）のＣＭが注目された。

手作業の時代では、企業活動は、係→課→部→全社の各レベルで集約され経営者に報告されていたが、あまりにも時間がかかる。コンピュータを活用することにより、末端の活動を中間のレベルを飛び越えて直ちに経営者に伝えることができる。
　管理統制や意思決定をするには、判断の基礎になる多様な資料が必要になる。しかし、伝票等を多様な切り口で仕分けして集計するのは、手作業では膨大な作業量になる。それまでした得られる資料が本当に役立つかどうかは事前にはわからないし、資料を得るのに長期間かかれば、その情報が役にたたないこともある、そのような状態だったので、経営者は、資料作成の指示をためらい、経験、感、度胸で意思決定をしていたのである。
　それに対して、コンピュータは多様な切り口で検索加工するのに適している。コンピュータ化対象業務が広がってくると、企業の基本的なデータがコンピュータに蓄積されるようになった。そうなると、これらのデータを有効利用しようと考えるのは当然である。

ＭＩＳは中間管理者不要論へと発展した。コンピュータにより正確な情報が迅速に経営者に届くならば、それを報告するための部課長は不要になるという理由である。米国では実際に管理職解雇が起こったが、当時の日本では解雇を行う経営者は無能だとの伝統があった。それでも本社などスタッフ業務が主な部署では課制廃止が行われ、課長職をなくして、プレイイングマネージャとする動向が進んだ。
　しかし、多くの日本企業では、単に課長という名称を廃止しただけで、労務上の管理職としての立場、稟議制度での位置づけをそのままにしたので、実効が得られなかった。
　逆に、極端に中間管理者を排除した企業は深刻な副作用を生じた。少なくとも日本では、中間管理者は下の情報を上に報告し、上の命令を下に伝えるだけのピン機能だけではない。むしろ中間管理者が上下や横とのコミュニケーションをとりながら業務改善に取り組んできたのである。その人たちが去った後、イノベーション力が極度に低下したといわれる。
　中間管理者不要論は、ＢＰＲやグループウェアなど、いろいろな局面で話題になるが、それで成功する方法論は確立していないようである。

ＭＩＳの幻想

しかし、ＭＩＳを実現するには当時のコンピュータは貧弱であった。

• 前述のように、プログラムを書くのに時間がかかる。新しい資料を依頼しても、それが得られるには数日かかる。
• データベースは、初期の階層型データベースが発表されたばかりであり、多様な切り口で検索加工するのに適したリレーショナルデータベースが実用化するのは１９８０年代中頃である。
• ＴＳＳはミニコンでの科学術計算には使われていたが、社長室の端末からコンピュータを操作できるようになったのは１９７０年代末頃からである。出力は紙に限定される。
• 日本語文字が使えるようになったのは１９８０年代からで、当時は英数字と半角カナしか使えなかった。ましてグラフ表示はできない。

社長が出社すると、机の上にアウトプットされた資料が１メートル以上積み重ねられている。聞くと、社長が指示した資料を出力しただけだという。あまりにも膨大だし、内容は英数字と半角カナの羅列である。到底、読む気がしない。秘書に廃棄するよう指示するがコンピュータ部門の機嫌を損ねないように目立たないように廃棄させる必要がある。
　紙の氾濫は多くの部署でも起こっており、コンピュータは「紙屑製造機」だといわれた。裏面をメモ用紙にして再利用することが流行ったが、当時はセキュリティは深刻な問題にならなかったようである。それだけ、読みにくいアウトプットだったのだろうか？

１９６７年にアコフ（R.F.Ackoff）は論文「Management Misinformation Systems」でＭＩＳ設計における「５つの誤った仮説」を指摘した。

1. より多くの情報を与えよ。
2. 管理者は、自分の要求する情報が何かを知っている。
3. 管理者が欲している情報を提供すれば、意思決定が改善される。
4. より多くのコミュニケーションがよい結果につながる。
5. 管理者は情報システムの仕組みを知る必要はなく、使い方だけを知っていればよい。

このような理由によりＭＩＳはMiss（誤り）でありMyth（おとぎ話）であると評価されてしまった。

ＴＳＳ（Time Sharing System：時分割方式）とは、１台のコンピュータを複数の端末機から同時使用ができるようした仕組みである。１９６０年代に大学や研究所で普及したが、日本の一般企業で実用的に利用するようになったのは１９７０年代末頃からである。 →参照：「汎用コンピュータの歴史 ＴＳＳの実用化と普及」

ＴＳＳは、まずプログラミング作成に用いられた。紙テープや紙カードに穿孔して順番を待つことから、キーボードから打ち込みボタンを押すだけでコンパイルや実行ができるようになったので、プログラマは泣いて喜んだものである。ところが、すぐに結果が得られることから、デバッグを途中で切り上げるタイミングを逸する。そのため、徹夜で行うことが日課となり、プログラムの作成本数は革命的に向上したのであるが、残業も増えてしまった。しかも待ち時間がなくなり、かなり過酷な状況になった（もっとも好きでやっているのだから・・・）。

その後ＴＳＳは、端末を利用部門（経営者も含む）に設置して、利用者が直接にコンピュータを操作するようになった。エンドユーザ（情報部門以外の人）が、自主的に自らコンピュータを操作して、自分や自部門の業務に活用することをＥＵＣ（End-user Computing）という。

当時のＴＳＳをサポートするＯＳにはＣＬＩＳＴという機能（制御言語）をもっていた。ファイルをアサインする、プログラムを実行する、プログラムを作るといったコマンド群をファイルとして保持し実行するインタプリタである。バッチ的に処理することもできるし、ＣＬＩＳＴから操作者へ指示入力を求める機能もある。これを適切に作ることにより、あまりコンピュータに詳しくないエンドユーザに、必要な情報を入手できる仕組みをサポートすることができる。
参照：「ＪＣＬ／ＣＬＩＳＴの例」

汎用コンピュータ環境にくらべて、現在のオープンシステムやＷｅｂシステムは使いやすい環境になっているが、ぜひＣＬＩＳＴに相当する機能がほしい。スクリプト言語がそれに似ているが、ＣＬＩＳＴと比較すると機能も記述性も貧弱である。

ＤＳＳとは、エンドユーザがＴＳＳによりコンピュータを利用して意思決定の支援に活用することである。そのなかに、基幹業務系システムで蓄積したデータを、多様な切り口で検索加工する情報検索系システムがある。これは、データの有効活用に効果的であり、１９８０年代を通して普及した。そして、１９９０年代にはデータウェアハウス、２０００年代にはＢＩとして発展する。

ＤＳＳの概念

ＭＩＳは幻想だと評価されたが、コンピュータを意思決定の支援に活用する期待は高く、１９７０年代になると、ＤＳＳ（Decision support system；意思決定支援システム）が注目されるようになった。
　１９７１年にスコットモートン（M.S. Scott-Morton）は「Management Decision Systems: Computer-Based Supportfor Decision Making」を著したが、このＭＤＳがＤＳＳの原型である。
　ＤＳＳは米国では１９７０年代中頃から普及したが、日本で一般企業に普及したのは１９８０年代初頭からである。それは、ＤＳＳのインフラとしてのＴＳＳの普及が遅れたことと、１９７０年代末までは、汎用コンピュータで日本語が使えなかったからである。

ＤＳＳには二つの分野がある。モデル指向型ＤＳＳ（狭義のＤＳＳ）とデータ指向型ＤＳＳである。

モデル指向型ＤＳＳ

学者等の紹介では、ＯＲが構造的意思決定問題の最適解を求めるのに対して、ＤＳＳでは半構造的意思決定問題の満足解を人間とコンピュータのハイブリッドにより求めるものだという。

例えば、売上から利益までの損益計算書や原価計算の定義式、投資と生産量やコストとの関係、人材育成や広告の効果などの経験式（仮説）などをモデルとして組み込む。そして、「原料コストが５％増加したら～利益はどうなるか」「現在利益を維持するとしたら～どの製品をどれだけ増販する必要があるか」のようなWhat-If問題を机上実験する。問題の提起と結果の評価は人間が行い、複雑な計算はコンピュータにやらせる方法であり、現在でのExcelのGoolSeekingのような使い方である。
　米国では、コンサルタント会社が標準的なモデルを構築しクライアント企業の特徴、経営者のニーズに応じてカスタマイズするビジネスが流行した。そのモデルは比較的単純だったのに、かなり使われたようである。彼らは、解の値そのものを求めるよりも、全体的な波及影響を把握することを重視したので、厳密性よりも応答性、解のまわりの情報の豊富さを重視したのである。
　それに対して、日本の経営者は、興味をもったものの実務へ適用されなかった。実務適用を前提とした厳密解を求めるあまり、モデルが複雑になりすぎて、使いものにならないことが大きな原因だった。

データ指向型ＤＳＳ

販売システムや会計システムなどの基幹業務系システムで収集・蓄積したデータから、経営者の求めに応じて、多様な切り口で検索・集計して報告するシステムである。日本では、情報検索系システムあるいは情報系システムといっている。

銀行システムでは、預金や送金などのシステムを「勘定系」といい、データの分析など管理に用いるシステムを「情報系」といった。その「情報系」という名称が一般企業にも広まったようだ。しかし、「勘定系」は不適切なので「基幹系」としたらしい。いずれにせよ実務界での用語であり、学者はあまり使っていないようだ。

情報検索系システムはＭＩＳと同じような目的であるが、この時代（日本では１９８０年代初頭）にはＴＳＳが実用化されていた。経営者はディスプレイのメニューを指定するだけで情報が得られる。経営者自身が選択して入手できるようになったのである。
　このような提供方式を、個別帳票メニュー提供方式という。利用者はコンピュータ知識がなくても簡単に帳票が得られるので便利であるが、反面、メニューにある情報しか得られないし、コンピュータ部門の労力がかかる欠点がある。

このＤＳＳ端末（パソコン）を社長室などに設置したことによって、経営者のコンピュータへの関心が急速に高まった。役に立つ情報が容易に得られることから、コンピュータの効果を認識し「金食い虫だ」との叱責が少なくなった。また、「入っていない情報は出てこない」ことを実感した。経営に必要な分野が未だシステム化されていないとか、データの項目が不備で、適切な切り口での分析ができないなどを認識し、それらのシステム化を指示するようになった。
　端末を社長室などに設置したが、設置目的のＤＳＳ以外の利用が進んだ。当初は、社内情報に高い関心をもったが、そのうちに毎日同じようなデータを見るのに飽きてしまい、せいぜい確認のために見るだけになってしまった。ＤＳＳだけでは無味乾燥なので、当時流行っていた日経のＴＳＳサービスなども利用できるようにしておいたのだが、そのなかの株価情報や為替情報などのほうがアクセス回数が多くなったのである。当時は、社長にキーボードを打たせるのは気の毒だといって、画面を指でタッチすることも考えたのだが、関心のある情報ならば、独力でも取り出す能力を得るのである。

情報検索系システムの普及

社長や役員がＤＳＳで情報を入手し、気がかりのことがあると、担当部長や支店長を呼び出し、その原因や対策を聞く。部長や支店長は、藪から棒に聞かれるのは困るので、自分たちにもＤＳＳにアクセスさせろという。すると課長も～というように、要求が広くなっていく。
　当然ながら、担当部門が異なればほしい情報も異なる。経営者、管理者、一般社員では同じテーマでも集計レベルでのニーズが異なる。そのため、コンピュータ部門には多数のメニュー作成依頼が殺到する。これではコンピュータ部門は麻痺ししてしまう。それで、個別の帳票入手を対象にするのではなく、それらの元になる基幹業務系システムのデータを、エンドユーザが使いやすい形式に整理して公開し、使いやすい簡易言語を提供し、エンドユーザが自ら情報を取り出すようにするのがよい。このような方式を公開ファイル提供方式という。
　このような利用は、情報検索系システムとして、１９８０年代を通して普及した。ジェームス・マーチン（James Martin）は、著書「An Information Systems Manifesto」1984などで、「プログラマなしのシステム設計」「ユーザを運転席に」などと表現し、それに利用される簡易言語を第４世代言語でとし、ＥＵＣを支援する組織をＩＣ（Information Center）と呼んだ。

ＲＤＢとＳＱＬ

現在では、「エンドユーザが取り扱いやすいデータの持ち方」としてＲＤＢ（Relational Database：関係型データベース）、「簡易言語あるいは第４世代言語」としてＳＱＬがポピュラーである。
　それまでのデータベースはＮＤＢ（Network DB：網構造ＤＢ）が広く用いられていた。このデータベースは、項目間の結びつきを事前に設定する静的結合であり、基幹業務系システムのような定型処理に向いていた。ところが情報検索系システムでは、任意の切り口で分類・集計するので、実行時に結合する動的結合である必要がある。ＲＤＢは、１９７０年にコッド（E.F.Codd）が論文「A Relational Model of Data for Large Shared Data Banks」で最初に提唱した。その後、多様なＲＤＢ製品が出現したが、１９８３年にＩＢＭはＤＢ／２を発表、これが業界標準になった。当時のＲＤＢは、非常に処理速度が遅く、日本で実際に広く使われるようになったのは１９８０年代後半である。
　ＳＱＬは、ＲＤＢをアクセスする言語である。ＩＢＭがSEQUEL（Stored English Query Language）の名称で開発したものが、その後ＳＱＬとなり、１９８７年ＩＳＯで標準化されている。現在のＲＤＢ用言語はほとんどがＳＱＬをベースにしており、Accessも実際にはＳＱＬを生成している。

情報検索系システムの直接的効果

情報検索系システムによる基幹業務系システムの規模減少

さらに広い観点からの情報検索系システムの効果として、基幹業務系システムの規模減少、ＩＴ部門の負荷削減などがあげられる。

この頃、ＩＴ部門は負荷増大で硬直化していた。
　景気低迷への対策として、間接部門から直接部門への人事異動が行われた。ＩＴ部門も間接部門だとされ、業務増加に伴う増員は認められないどころか減員されることもあった。
　一方、対象業務は多くの分野に拡大し、それらの改善や拡張、業務環境の変化などのために保守改訂への要求が広まった。しかも、長期にわたるバッチ的修正が重なった結果、複雑になり、それを担当したベテランでないと修正ができない状況になっていた。

この状況を脱するには、エンドユーザが自分の要求を自分で解決できるようにするのが効果的である。要求の大半は新規帳票作成要求であり、そのほとんどは、すでに蓄積してあるデータを任意の切り口で検索加工することにより得られる。すなわち、情報検索系システムの普及が解決手段になる。
　しかも、このような利用が浸透していれば、新規に開発するシステムにおいて、多様な帳票作成要求を情報検索系システムにまわすことにより、ＩＴ部門が管理するシステムの規模を抜本的に少なくすることができる。開発業務だけでなく保守改訂業務の負荷削減に役立つ。
　さらにエンドユーザが表計算ソフトなどパソコンに熟達していれば、情報検索系システムでは汎用コンピュータからパソコンに必要なデータをダウンロードするだけでよく、その後の編集加工はエンドユーザに任せることができる。これは、情報検索系システム運営の負荷を低減するのに役立つ。
参照： 「情報検索系システムによる基幹業務系システムの簡素化」

情報検索系システムは、１９９０年代にはデータウェアハウス、２０００年代にはＢＩ(Business Intelligence）へと発展する。当初は、情報検索系システムは基幹業務系システムの補完的存在であった。それが次第に、情報検索系システムが重視され、それに信頼性のあるデータを提供するのが基幹業務系システムであるという認識すら生まれた。両社の位置づけが逆転してきたのである。

• １９７７年　米コンピュータ専門誌「DATAMATION」、ＯＡという用語
• １９７９年　オフィス・オートメーション学会（現日本情報経営学会）発足
• １９７９年　Personal Software社（当時）、VisiCalc発売（最初のApple用表計算ソフト
• １９８０年　各社が日本語ワープロ専用機を発売
  ＮＥＣ「文豪」、富士通「ＯＡＳＹＳ」、シャープ「書院」（１９８１年）
• １９８１年　ＩＢＭ、IBM PC発売（ビジネス用として注目）
• １９８２年　ＮＥＣ、PC-9801発売（国産機といわれるほど普及）
• １９８３年　Lotus社（当時）、表計算ソフトLotus 1-2-3発売（IBM PCなど多くのＰＣで稼働）
• １９８３年　ジャストシステム「JS-Word」
  １９８５年に「一太郎」とその変換ＦＥＰ「ATOK」
  

１９７０年代末頃になると、オフィス業務の生産性を向上させるために情報機器を活用すべきだという、ＯＡ（Office Automation）の概念が普及した。当初は、ファクシミリ、コピー機、ワープロが「ＯＡ三種の神器」と呼ばれた。ワープロ専用機は１９８０年代当初から普及が始まった。１９８０年代中頃にかけてピークになり、その後、一太郎などのパソコンソフトの発展によりパソコンに移行した。
参照：「ワープロの歴史」

１９８０年代になると、パソコンがビジネスでも活用されるようになり、オフィス業務でパソコンを活用することがＯＡであるとされた。
　そのキッカケとなったのがＩＢＭのＰＣ参入である。それまでにパソコンはかなり普及していたが、個人のホビー用とみられていた。当時コンピュータ業界での独裁者であったＩＢＭがビジネス用パソコンを発表したので、ＩＢＭ信奉者であるコンピュータ部門が一斉にパソコンに注目したともいえる。

ＯＡブーム

ＯＡは、利用部門にとって期待と不安をもって迎えられた。
　当時のパソコンには、先行的なものは除いて、ワープロソフトも表計算ソフトもなかった。それらが普及するのは１９８３年頃からである。
　１９８０年代初期にワープロ専用機が普及した。それまでのレポートはすべて手書きだった。活字印刷しようとすれば専門職のタイピストに依頼する必要があった。ワープロにより手軽に活字印刷できるようになったし、簡単なグラフも作れるようになったのは、体裁を愛好する利用部門にとって朗報であった。
　ワープロが必ずしも生産性を向上させたとはいえない。当初は「清書機」の認識が強く、手書したメモを見ながらワープロに入力することが多く見られた。キーボードに慣れずに部下に清書させる人もいた。しかし、次第に思考をまとめるため、文書を再利用するために有効な道具だとの認識に変わるようになる。また、自ら使うことにより、キーボード操作に慣れていった。
　１９８０年代後半になると、パソコンのワープロソフトが発展し、ワープロ専用機はパソコンに置き換えられていった。

パソコンの利用はビジネスマンンに必須であり、「パソコンができない管理者は去れ」とまでいわれた。当時、パソコンを使うにはＢＡＳＩＣ言語でプログラミングする必要があった。また、当時絶大なシェアを誇っていたＮＥＣのPC-9800では、ＢＡＳＩＣがＯＳのような枠割をもち、パソコン操作にもＢＡＳＩＣの知識が必要だった。それで、中高年の部課長が、慣れないキーボードでＢＡＳＩＣを作成するような光景が生じた。
　当然、ＩＴ部門などが講習会を開催するのだが、若い部下の前で醜態を見せたくないとして、内緒で巷のパソコンスクールに通うこともあった。

「ＯＡブーム」は社会的風潮になった。当時クリーニング店に「ＯＡクリーニング」という広告貼紙があった。パソコンを買って、預かり記録を入力しているだけなのだが、「ＯＡ」という言葉に魔力があったのだ。

ＢＡＳＩＣブームは表計算ソフトの普及とともに沈静化した。また、パソコンの普及により、ＴＳＳ端末がパソコンになった。汎用コンピュータのデータをパソコンのスプレッドシートに転送して、その後の処理は表計算ソフトで行うことができるようになった。これは、情報検索系システムの運用を格段に容易にした。
参照：「オフィスソフトの歴史」

当時は、大企業でもパソコンの設置率は５人～１０人に１台程度であった。パソコンは発熱量が高く、プリンタの騒音は大きかった。配線の都合もあった。それで、オフィスフロアの隅に「ＯＡコーナー」を設置して共同利用するのが通常であった（「１人に１台」の状況になるのは、１９９０年代のダウンサイジング以降である）。ＴＳＳの普及とともに、基幹系業務システムのデータ入力もパソコン画面から行うようになった。それでパソコン台数増加の要求が高まった。

１９８０年代になると、ポーター（Michael Eugene Porter）などにより、企業経営に競争戦略の概念が重視されるようになった。また、企業間ネットワークの普及により、メーカーが発注端末を小売店に設置して受注を増やすシステムが出現した。その初期の例として、アメリカン航空の座席予約システムがある。
　ワイズマン（Charles Wiseman）は、このような経営戦略に直接貢献するＩＴの活用を戦略的パースペクティブに基づくＳＩＳ（Strategic Information Systems：戦略的情報システム）と命名し、従来のＭＩＳやＤＳＳなど人間の活動を支援する利用である慣習的パースペクティブと区別した。
参照：「ＳＩＳ（戦略的情報システム）」
　ＳＩＳでは、「ＩＴは競争戦略の武器」だといわれ、ＩＴへの投資は、採算性を云々する状況ではなく、生き残りをかけた戦略的投資であるとされた（多分にメーカーの便乗的主張であろう）。

日本でも１９８５年の通信自由化により、企業間ネットワークが解禁になると、クロネコヤマトの宅急便システム、花王とライオンの発注端末競争など、ＳＩＳ的な利用が進んだ。
　しかし、これらのシステムは、当初から「ＳＩＳ」を意図したものではなく、業務合理化を追求した結果であり、「振り返ればＳＩＳ」だともいわれた。

情報システム部門の任務変化とＣＩＯ

従来の「お手伝い」利用の時代では、情報システム部門はある程度自明の情報システムを構築し運用することが任務であった。ところがＳＩＳにより、経営戦略に情報技術動向を取り込むことが重視されるようになった。情報システム部門は、企画部門と同様に、経営者に密着した戦略部門であるべきだとされた。従来のＤＰ部門からＩＴ部門への変貌が求められたのである。
　経営戦略とＩＴ戦略を統合するには、経営の観点からＩＴやＩＴ部門を統率する必要があり、経営陣がそれにあたるべきだとされ、ＣＩＯ（Chief Information Officer）の職制を設ける企業が続出した。
　また、情報システム部門をＩＴ業務に専心させるためには、従来のＤＰ業務を共存させるのは不適切であり、ＤＰ業務を切り離して情報子会社にしたり、アウトソーシングしたりするようになった。

この変化は、ＩＴが経営に不可欠な分野であり、ＩＴ部門を経営の中枢に位置づけることになるので、ＩＴ部門に大きな期待をもたせた。
　ところが、経営戦略云々が重視される反面、ＤＰ技術が軽視される傾向が進んだ。従来のＳＥやプログラマは昇進の道を閉ざされただけでなく、子会社やアウトソーシング先に移籍されることになったのである。優秀な人材が情報システム部門を敬遠する傾向を生じてしまった。
　また、戦略部門になったＩＴ部門は、システム開発やコンピュータ運用などの業務から遠ざかるのにつれて、情報技術能力の空洞化が起こり、ＩＴの素人集団になる傾向が進んだ。そのような部門が適切な戦略を提案することはできない。結局は予算管理部門、子会社・アウトソーシング先のコスト監視部門になってしまうことも多かったのである。
参照：「ＩＴ部門の変貌 ＤＰ部門からＩＴ部門へ」

さらに問題なのはＣＩＯである。ＣＩＯは、ＩＴガバナンスを確立して経営戦略とＩＴ戦略の統合を行うのが任務であるから、経営とＩＴの双方に高い経験・知識をもつことが求められる。ところが、一般に日本の経営者はＩＴを軽視してきた事情があり、日本のＣＩＯは、ＩＴに素人で他業務と兼任（ＣＩＯの比重が小さい）であり、戦略的ＩＴ活用の最高責任者というよりも、単なるＩＴ部門担当役員になっているのが大多数である。
参照：「ＣＩＯの現実」
　米国のＣＩＯがプロフェッショナルが大多数であることと大きな違いがある。米国企業と比較して日本企業ではＩＴの戦略的活用の割合が小さいことが指摘されているが、これがその主原因の一つである。
参照：「ＩＴ投資の適用分野での国際比較」

１９９３年に出版されたハマー（Michael Hammer）＆チャンピー（James A. Champy）著、野中郁次郎監訳「リエンジニアリング革命」は、ＢＰＲ（Business Process Reengineering）ブームを巻き起こした。
　日本企業が１９８０年代まで競争優位を確立してきた原動力の一つに、ＴＱＣなどボトムアップによる改善指向のカイゼン運動がある。米国企業がカイゼン運動を研究して、トップダウンによる改革運動へと発展させたのがＢＰＲだとされている。
　ハマーらは、ＢＰＲとは、カイゼンのような５％、１０％のような現状改善ではなく、数倍、数十倍といった抜本的な改革であるとしているが、ダペンポート（Thomas H. Davenport）のように「ホームランだけでなくヒットも必要だ」という論客もあり、それに日本的経営を見直そうという意見も混じり、百花繚乱の様相であった。

ＢＰＲは経営手法ではあるが、その実現にはＩＴが不可欠であるとされた。ＩＴによる経営革新という概念ではＳＩＳと同じようなものであるが、ＳＩＳが特定の業務へのＩＴ活用（特に企業間ネットワーク）を対象にしていたのに対して、ＢＰＲでは業務の流れ（ビジネスプロセス）の再構築（リエンジニアリング）を対象にし、従来の分業体制を改めるべきだと主張している。

１９９０年代中頃にＥＲＰパッケージが普及した。パッケージとは、「出来合いのソフトウェア」であり、ＥＲＰ（Enterprise Resource Planning）とは経営資源最適化であり、ＢＰＲと同じような意味である。ＥＲＰパッケージは、生産、販売、人事、会計など企業の全業務を統一した観点からパッケージにしたものであり、統合業務パッケージともいう。

ＥＲＰパッケージの特徴と普及

従来から財務会計や給与の年末調整など個別業務ではパッケージが使われていた。しかし、それでは他のシステムとのインタフェースが複雑になる。ＥＲＰパッケージは統一された思想で全社業務をカバーできる。それで「MakeからBuyへ」の傾向が強まった。

大企業では、既に基幹業務系システムは構築されていたが、全面的な改訂が求められる状況になっていた。しかし、基幹業務系システムが巨大になっており、費用や労力がかかるし、ＳＩＳにより本体のＩＴ部門の規模が縮小されているので、改訂に踏み切ることができない。ＥＲＰパッケージは、その状況を打破する救世主であるとして期待され、多くの大企業が導入した。

• 個々のシステムは長年のパッチあて的な改訂により複雑になっており、システム間の連携も不十分な状況になっていた。それを整理するだけでなく、経営環境の変化に即応するために、改訂が容易なシステムにする必要がある。
• 海外に事業所や関係企業をもつ企業では、各国の法律、慣習に合致したシステムを各国言語で利用する必要がある。それを統一したシステムで構築したい。
• ＢＰＲを行うことが必要だが、独力で全社的な構造を矛盾なく計画すること、それにＩＴ計画を適切に組み合わせることは難しい。ＥＲＰパッケージをひな型として利用するのが、実現への早道であろう。
• 当時ダウンサイジングが進んできたが、ＥＵＣ利用が主であり、基幹業務系システムを汎用コンピュータ環境からオープン環境へ再構築することが求められていた。ＥＲＰパッケージはオープン環境を前提としているので、オープン環境への移行に合わせてＥＲＰパッケージを導入するのが適切である。
• １９９０年代後半になると、西暦２０００年への対処が緊急課題となり、全面的な改訂が不可欠になった。

（注）西暦２０００年問題
慣習的に１９９９年を「９９」のように取り扱ってきた。２０００年は「００」になるが、それを１９００年と誤認して大きなトラブルを起こす危険性がある。１９９９年末や２０００年初頭には飛行機に乗るなとか銀行預金の確認が必要だなどといわれ、社会的問題になった（逆に大きな問題になったために、十分な対応が行われ、大きなトラブルは生じなかった）。
　単に年号を２桁を４桁にするだけであるが、大企業では、システム規模が巨大で複雑なため、数億円の費用と数年間の労力が必要になる。西暦２０００年問題のためだけでなく、これを機会にシステム全体の改訂をしよう、ＥＲＰパッケージを導入しようという機運が高まった。

初期のＥＲＰパッケージベンダは、かなり過激な売り込みをした。それを支援した論者も多い。

• ＥＲＰパッケージの作成には、公認会計士や経営コンサルタントなどの専門家が多数参加し、ＢＰＲ先進企業のベストプラクティスを取り入れているので、ＥＲＰパッケージを導入することがＢＰＲを実現する早道だ。
• グローバル標準にそったベストプラクティスであるから、これまでの日本固有の商取引や特定企業固有の業務にあわせてカスタマイズするのではなく、業務をＥＲＰパッケージに合わせて変更すべきであり、それがＢＰＲの実現に通じる。
• 業務をソフトウェアに合わせるのだから、利用部門の反発が予想される。それを抑えるには経営者のリーダーシップが必要だ。ユーザ主導のシステムから経営主導のシステムであるべきだ。

しかし、当時のＥＲＰパッケージは、期待にそえる状況ではなかった。ベストプラクティスかもしれないがコアコンピタンスではない。企業はコアコンピタンスの分野で競争優位になっているのであるから、その業務をＥＲＰパッケージに合わせたら、競争優位を失ってしまう。情報システムもその分野では多くの工夫をしており、ＥＲＰパッケージよりはるかに優れている。
　初期のＥＲＰパッケージは外国製で、日本の製造業が確立した製番管理などの機能がなかった。また、不適切な慣習だといわれても、自社システムの都合を顧客に押し付けるのは不適切だし、その慣習で自社が顧客満足を得ていることもある。

１９９０年代後半には国産のＥＲＰパッケージが続出し、日本固有の機能を積極的にサポートした。海外ベンダもそのような機能を取り入れるようになった。
　また、「ベストプラクティス」ではなく「優れた標準」といい直した。コアコンピタンスのシステムは自社独自の仕様で構築すべきである。それに傾注するためにも、会計処理や売上処理など一般の業務処理をＥＲＰパッケージを利用するのがよいというようになった。
　初期のＥＲＰパッケージ導入では、ベンダの能力不足が不満になった。ＥＲＰパッケージは統合業務パッケージのはずなのに、ベンダの経験不足により財務会計しか支援できない。「小さく生んで大きく育てる」といい、まず財務会計を対象にして導入し、販売や生産に広げるといいながら、広げることができなかったり、販売や生産のシステムを構築すると財務会計の改訂が必要になるなどの不手際も生じた。これらが満足できる状況になったのは２０００年代になってからである。

ＥＲＰパッケージがＩＴ部門に与えた影響

ＥＲＰパッケージの導入は、ＩＴ部門に深刻な影響を与えた。これまでにもＩＴ部門は多くのアイデンティティを失ってきたが、自社のシステムに関しては自分たちが最もよく知っているというアイデンティティがあった。
　ところがＥＲＰパッケージを導入すれば、ベンダ側の技術者と利用部門だけでシステム開発が可能になり、ＩＴ部門の参加は必然性がない。それどころか、ＩＴ部門はつまらぬ異議をいうので、ＩＴ部門を締め出したほうがよいというベンダすらいた。いずれにせよ、ＩＴ部門が他よりもシステムをよく理解しているとはいえなくなったのである。
参照：「ＩＴ部門の変遷　ＥＲＰパッケージとＩＴ部門」

１９８０年代末から１９９０年代前半にかけて、ＩＴ環境に大きな変化が起こった。ダウンサイジングである。当時「ネオダマ」という言葉が流行した。ネットワーク、オープン化、ダウンサイジング、マルチベンダ（あるいはマルチメディア）を短縮したものである。

ダウンサイジングとは、大型汎用機による集中処理から多数の小型機（パソコン等）をネットワークで接続した分散処理への移行動向のことである。
　１９８０年代初頭からビジネスにパソコンが使われるようになったが、パソコンの価格性能比は急激に向上した。その原動力はオープン化にある。汎用コンピュータはメーカー独自のアーキテクチャで設計されていた。ＩＢＭ機用のソフトウェアはＮＥＣ機に搭載できないとか、富士通機のＴＳＳ端末は富士通以外の機器では相性が悪いなど互換性が乏しかった。そのため、コンピュータの評価は、ハードウェアだけでなくソフトウェアや周辺機器などを総合した評価であった。ところがパソコンでは、アップルなどの例外を除けば、互換性が保証される（オープン化）ので、顧客へのアッピール要因は価格性能だけになる。そのため、激しい価格競争が行われ、１９８０年代末頃になると、多数のパソコンを接続した構成が価格性能比で大型汎用機を圧倒するようになった。
　国内出荷高では、パソコンは１９８８年から急上昇し、汎用コンピュータは１９９１年をピークに急下降、１９９２年にはパソコンが汎用コンピュータを抜いた。

ダウンサイジングとＩＴ部門

ダウンサイジングは、マスコミによるＩＴ部門バッシングへと発展した。ダウンサイジングによりコストが急激に下がるとか、ＩＴ部門に依頼して汎用コンピュータで構築すると数か月かかるシステムが、エンドユーザがオープン環境で一週間で稼働させたなど、ダウンサイジングを礼賛し、ＩＴ部門は、オープン環境では自分の知識経験がないために、汎用コンピュータにしがみついている保守反動派だと断罪したのである。

経営者は、ダウンサイジングの技術はわからなくてもコストダウンには敏感である。ＩＴ部門の意見よりもマスコミの論調のほうがわかりやすいし、ＩＴ部門の意見はいいわけのように聞こえる。本来、方向性を示すべきＣＩＯはＩＴの素人で、マスコミかＩＴ部門の代弁者で頼りにならない。
　米国ではトップダウンの決定が強く、解雇や採用がやりやすい。ＳＩＳ当時のＣＩＯはＩＴの素人でも務まっただろうが、このような状況では役に立たない。プロとしてのＣＩＯを採用し、ＩＴ部門を荒療治して、ダウンサイジングを強行したケースが多い。
　それに対して日本では経営者もＣＩＯも自分がダウンサイジングを決定するだけの能力がない。実際にはＩＴ部門に任せるしかない。コンピュータメーカーもダウンサイジングには及び腰である。そのため、日本ではパソコンやＬＡＮは行うが、汎用機も（台数を減らして）残すという中途半端なダウンサイジングになった。
　当時のオープン環境は、かなり信頼性の低い状況だった。米国と比較して、日本はエラーに厳しい。トラブルが起こると非難の矛先はＩＴ部門に向けられるので、ＩＴ部門はリスクを避けたがり、汎用コンピュータの撤廃には慎重論になる。このような事情を勘案すると、中途半端なダウンサイジングになったのは仕方なかったともいえる。

システム開発者に求められる知識の変化

「ＣＯＢＯＬプログラマ不要論」で代表されるように、汎用コンピュータ時代に重視された知識や経験が、オープン環境では不要になり、新しい知識が求められるようになった。
　ベテランは汎用コンピュータでのシステムの保守改訂に縛られている。それで、オープン系の業務は若い人たちにゆだねられた。また、そのほうが習得がはやいともいわれた。

これは正しい面もあった。しかし、基幹業務系システムでは、単にその処理ができるだけではなく、関連するシステムとのインタフェース、全体システムを通した基準の順守などが必要である。若い人たちは、ソフトウェア工学やシステム設計論を習得していないため、個人利用的な（その場しのぎの）ようなシステムを乱造する傾向がある。
参照：「ＩＴ部門の変遷 システム開発者に求められる知識の変化」

ベテランのノウハウを伝承する必要があるのだが、それが不十分なままに二分化が進む傾向があった。その反省として、２００年代中頃になると、団塊世代が定年になるとベテランのノウハウが消えてしまうという「２００７年問題」を防ぐことが重視された。

• １９８９年　グループウェアLotusNotes開発
• １９９４年　LotusNotes日本法人設立　１９９６年 LotusNotes4.0 で本格普及

汎用機を残したままのダウンサイジングは、期待したほどのコストダウンにはならず、その有効活用が求められた。それを救ったのが、ＬＡＮ環境での電子メールや電子掲示板などのグループウェアである。

電子掲示板や電子掲示板のような利用は、一部の企業では、かなり以前から行われていた。

• 汎用コンピュータのＴＳＳ機能にＳＥＮＤ命令により、特定の相手にメッセージを送ることができたし、ちょっとファイル操作を工夫すれば、電子掲示板のような利用ができた。
• ＯＡの利用で、日本ではＢＡＳＩＣや表計算ソフトの利用が多かったが、米国では電子メール的な利用が主流であった。
• 社外とのコミュニケーションでは、インターネットに先駆けてパソコン通信が行われていた。

しかし、ＴＳＳやＯＡでこのような利用をしていた日本企業は稀であったし、パソコン通信では通信回線費用を気にするため、本格的な社内利用にはならなかった。そこに、多様な機能をもち、自社用にカスタマイズできるグループウェアが出現したので、多くの企業がすれに飛びついた。極端な場合には、グループウェアの利用がダウンサイジングの目的になったほどである。１９９０年中頃は、LotusNotesがグループウェアの代名詞のようになっていた。

グループウェアの普及は、コンピュータ利用の本質的な変化だといえる。基幹業務系システムや情報検索系システムは、ファイルのレコードを加工して情報とする。すなわち、コンピュータの最大の役割は計算することであり、文字通り「コンピュータ＝計算機」だったのである（科学技術計算の分野では当然）。
　ところが、グループウェア的な利用では、ファイル単位でのデータの伝達や共有化が主になる。すなわち「コミュニケータ＝情報伝達機」としての利用へと拡大したのである。しかも、インターネット時代になると、むしろ、コミュニケータとしての利用のほうが大部分を占めるようになった。そろそろ「コンピュータ」という用語を廃止すべきでは？

グループウェアと企業文化

グループウェアは、企業の組織構成や、組織文化を変えるものだといわれた。
　グループウェアが普及すれば、組織の壁を越えて情報の共有化が進み、ダイナミックな協同作業が行われるし、報告や指示が迅速化される。すなわち、グループウェアは組織の創造性向上、組織の活性化へのインフラであると認識されるようになった。
　グループウェアは、経営者にも歓迎された。ＭＩＳ的な社内情報提供には積極的な利用をしなかった経営者も、グループウェアには多大な関心をもった。グループウェアにより、初めてＩＴの効果を実感したという経営者も多くいた。

自由闊達な意見交換ができる文化をもつ組織では、グループウェアは強力なインフラになる。そのような組織では、グループウェアが導入されると、すぐに「教えて教えます」コーナーを開設して、グループウェアの発展形態であるナレッジマネジメントの先取りをした。

それに対して、「沈黙は金」「ものいえば唇寒し」のような封鎖的な組織文化では、「他部門に電子メールを出すときは上司の承認を得ること」という規則を作ったり、教えてコーナーの掲示板にアドバイスすると「そんなヒマがあったら自分の仕事をしろ」といわれたりする。このような環境では、グループウェアの真価を発揮できない。それで、組織文化を変えることが重要であり、組織文化の改革のためにグループウェアを導入するのだともいわれた。
　マスコミでのグループウェア先進企業の経営者の談話として、「グループウェアにより、現場の動きがよくわかるようになった」「隠れた人材の発見に役立つ」などの効果が多く紹介された。一見、経営者の理解が高いように思われるが、これではグループウェアを監視の道具と認識しているようである。そのような状況で、フランクな発言が行われるだろうか？

個々の掲示板（会議室）のアクセス権の設定の複雑度、人事異動での対応の煩瑣度が組織文化のオープン性／クローズ性を測る尺度となると指摘した意見があった。オープン性が高い組織では、全員公開をする傾向があり、設定は簡単で人事異動でも変更する必要はない（当時は個人情報保護とか外部への機密漏洩はあまり重視されていなかった）。
　クローズ性の組織では、部門別の会議室を設定して、アクセスを部門内部に限定する。しかも、あの人には見せたいが、この人に見られるのは困る」として、複雑な設定になる。そのため、人事異動のたびに設定変更が大きな作業になる。

グループウェア関連トピックス

• ＩＴ部門の省力化
  グループウェアは「ＩＴ部門なしのコンピュータ利用」を実現させた。社員のＩＤ番号、掲示板の大雑把な割り当てなどを行うだけで、エンドユーザが自主的に電子メールを交換し、掲示板の設定や運用をしてくれる。しかも、エンドユーザにとって、グループウェアの利用がコンピュータ利用の大半を占めるようになった。
• トラブル発生リスク
  ＤＳＳやＯＡの時代と異なり、グループウェアはミッションクリティカルな機能であるとされ、信頼性の向上、回復時間の短縮が強く求められるようになった。ところが、当時のＬＡＮやパソコンの信頼性は低く、常にどこかでトラブルが発生する状態で、ＩＴ部門や利用部門のＩＴ担当者を悩ませていた。
• サーバＨＤＤのパンク
  当時のパソコン（サーバ）のＨＤＤ容量は小さい。バックアップ用記憶装置はさらに貧弱である。掲示板が多く作られ投稿が多くなるとグループウェアサーバのＨＤＤがパンクする。エンドユーザのパソコンには電子メールの残骸が残り、ソフトウェアのバージョンアップができない。「ディスクの整理整頓」を呼びかけても、利用部門は無頓着である。
• 予定表と社内民主主義
  グループウェアの機能に予定表がある。出張や来客などの日時を書き込んでおく。他人の予定表を見たり書き込むことができる。会議開催では上司が一方的に日時を設定して部下に押し付けることが多かったのが、この機能があると、少なくとも部下の状況を考慮しなければならなくなる。また、部下が上司の予定を見て、「○○日に顧客訪問に同行してください」と書き込んだとき、予定表が空白だと断る理由がなくなる。
  メンバーを人間ではなく、社用車や会議室にすれば、それらの予約に使える。先約優先の規程を作っておけば、上位者による割り込みを減らすことができる。
• グループウェアによる紙消費量の増加
  グループウェアの目的の一つにペーパーレスがあった。通知文書をオンラインで行うことにより、神の節約だけでなく、印刷・配布作業の削減、保管キャビネットなどの減少、検索・再利用の簡便化などが期待された（実際にこの効果は大きかった）。
  ところが、年配者はディスプレイで読む習慣がない。電子メールや掲示板の発言を印刷して読み、キャビネットに保管する。「ダウンサイジングによってＩＴ用紙の需要が増大した」という統計があったと記憶している。

インターネットが普及する以前は、ＩＴ利用は企業が主導権を握っていた。個人的なパソコン利用はしていても、それと企業でのＩＴ活用の間には大きなギャップがあり、新入社員の教育期間中に企業でのＩＴ活用の状況とインフラについて学習し、配属先で業務システムの利用方法を習得していたのである。社員にとって、社内ＩＴシステムが主であり、個人的利用は従の位置づけであった。

　その関係が、インターネットにより逆転したのである。入社以前に電子メールやＷｅｂページ閲覧などは十分に習得している。ワープロソフトや表計算ソフトにも習熟している。
　入社後も、ＩＴ利用の大半は、パソコンとしての利用やグループウェア的利用が大半であり、グループウェアはインターネットの社内版となり操作方法もほぼ同じである。
　基幹業務システムや情報検索系システム（データウェアハウス）も、ヒューマンインタフェースではＷｅｂブラウザあるいはその類似のものである。業務としての利用知識さえ習得すれば、事前に集述している操作方法や常識がそのまま通用する（注）。
　すなわち、入社以前から親しんでいた利用技術が主であり、社内の利用がローカル的に特殊化した従の位置づけになったのである。

（注）インターネットが普及する以前のダウンサイジング環境では、画面操作をファンクションキーで行うことが多かったが、そのキーの割り付けはアプリケーションあるいはプログラマの自由であった。Ｆ３キーが人事システムでは次画面への推移、販売システムではシステムの終了などとなっていると、人事部から販売部に異動になった人は誤操作をしてしまう。Ｗｅｂブラウザ基準になり、このようなトラブルがなくなったことは非常に喜ばしいことであった。

企業間ネットワークの容易化

ＳＩＳ、通信自由化以降、関係会社や主要取引先との企業間ネットワークは急速に進んでいた。しかし、その構築での打ち合わせでは、費用の配分について難航したものである。
　当時は通信回線が高かった。特に長距離通信費用は高かった。公衆電話回線の高かったが、大量データの安定通信のために専用線を使うと、その費用は取引コストを圧迫するものであった。そのため、通信費用の分担についてもめることが多かった。
　通信プロトコルも大きな問題だった。汎用コンピュータ間、汎用コンピュータとパソコン間ではメーカーが異なるとプロトコルが異なる。オープン化以降もUNIX、Windows、MacなどＯＳによりプロトコルが異なる。なかには「オンライン化には応じるが、それに使うコンピュータをそっちが負担してくれ」などといわれることもあった。
　それがインターネット以降では、それぞれがプロバイダまでの通信費用ですみ、プロトコルがＴＣＰ／ＩＰで統一され機器の制約がなくなったので、これらの交渉が非常に容易になった。
　さらには、一方的に受発注のＷｅｂサイトを構築し、「これを使って発注してほしい」というだけで済むようにもなった。

セキュリティ対策の深刻化

インターネット以前のセキュリティ対策とは、自然災害、機器の故障、人間の誤操作などが主であった。故意の犯罪への対策は、内部対策だけのこともあり、あまり重視していなかった。
　ところが、インターネット以降は、ウイルスや不正アクセスなど人間の悪意がセキュリティ対策の最大の対象になった。経営者のセキュリティへの関心（カネは出さずクチを出す）が高まった。ＩＴ部門の最大の任務が、システム構築や経営との連携よりもセキュリティ対策になった（これはオーバーであろう。ところがこのような結果を報告したアンケート調査が多いのも事実である）。

当初、苦労したのはエンドユーザの無関心（無責任）である。当時はフロッピーを介したウイルス感染が多かった。エンドユーザが得体の知れないフロッピーを会社のパソコンに持ち込み、ＬＡＮを通して広まったケースが大半であった。
　フロッピーを差し込んでパソコンに電源を入れただけで感染するウイルスもある。電源を入れるときにはフロッピーを抜けというのだが、当時は周辺機器を接続して周辺機器の電源を入れてからパソコン本体の電源を入れる手順だったので、混乱したことがある。

モバイルコンピューティングも新しい問題を招いた。当時はＶＰＮが普及していなかったので、ファイアウオールを通過する判断はパスワードだけである。ワンタイムパスワードもあったが、関係者全員に配布するにはコストがかかりすぎる。パスワードを頻繁に変更せよというのだが、面倒だ、忘れてしまうといって変更しない。システム側からアクセス回数、日数により強制的に変更を促すと、いったん変更した直後に元に戻すいう連中もいた。「悪習は直ちに普及する」例である。