スタートページ＞ （主張・講演、 Ｗｅｂ教材） 歴史＞ 経営とＩＴ
大企業におけるＩＴ部門の任務、社内的位置づけ、ＩＴ部員の意識などに関して、コンピュータの導入当初からインターネットの普及にいたる歴史的変貌の推移を振り返る。かなり主観的な内容である。
１９７９年にノーラン（Richard L. Nolan）は、ＩＴ資源管理に関する発展段階説（Stages of Growth Theory）を発表した。当時はＥＵＣが普及しかけた頃で、ＳＩＳもインターネットも存在しなかったし、一企業内の発展を対象としており、年代的発展を示したものではないが、ＩＴ部門を取り巻く組織任務の変遷を適切に説明している。
参照：「ノーランの発展段階説」
ＩＴ部門の任務は、経営におけるＩＴの位置づけの変化と情報技術の発展（ネットワーク）により変化する。コンピュータ利用の大衆化が進むとともに、ＩＴ部門のもつアイデンティティが喪失する。それらの時点において、適切な対応をしたＩＴ部門は重要な部門になるし、そうでないＩＴ部門は社内的地位が低下する。残念なことに後者のケースが多い。
日本の大企業が本格的にコンピュータを導入しはじめたのは、１９６０年代中頃である。１９６４年にＩＢＭ３６０が発表され、国産機メーカーがそれへの追従を開始した頃である。
当時は、「コンピュータ」よりも「電子計算機」のほうが一般的な名称であった。それで、ＩＴ部門は「電算室」と呼ばれることが多かった。一般にコンピュータ導入は、経営陣の一人がリーダーになり、いくつかの部門から若い人を集めてプロジェクトを編成するが、それがそのままＩＴ部門になることが多い。また、当初は「部」にするには規模が小さく、経営陣直属のスタッフ的性格が強いことから「室」としたのである。
当時のコンピュータ（中型機）の機能を列挙する。
このような環境のため、プログラミングやコンピュータ運用には、かなり面倒で、しかも技術習得が求められた。海のものとも山のものともつかぬコンピュータを相手に、なんやら難しい面倒なことをやっている連中は、通常の社員には特殊な部落の変人にみえたかもしれない。
プログラム作成の生産性は非常に低く、極度な長時間労働であった。他のジョブを処理している間はコンパイルすらできない。長時間待ったコンパイル結果にはバグがある。バグの修正には紙カードならば該当カードの差し替え、紙テープなら該当箇所をハサミとノリで修正して、また自分の番を待つという状況である。１日に数回しかテストできない。それで他のジョブが多い日中を避けて夜間にテストをすることになる。それが嵩じると、コンピュータ室に寝具を持ち込み泊まることが日常化する。
かなり劣悪な労働環境で不満も多かったが、楽しみもあった。バグがでると修正しようという本能のため、スケジュール的には翌日にまわせはよいことまで徹夜で行うようなこともあった。
長時間拘束のわりには作業密度が小さく、余裕の時間があった。コンピュータで遊ぶこともあり、好奇心で新しいロジックを開発して、翌日仲間に吹聴するようなこともあった。しかも当時は高度経済発展期でサービス残業のような締め付けはなかった。現在からみれば、全体におおらかな時代だったともいえよう。
コンピュータ室は温度調整が効いており、冷暖房が不備な自宅よりも快適であった。空調設備にビール等を隠しておくなど、夜食対策もできた（就業規則違反だが時効だし公知のことでもある）。
当時のＩＴ部門は、実作業としてはプログラム作成やコンピュータ運用が主であったが、それ以上の使命感をもっていた。
経営者に進言し（騙し）、業務担当部門を説得（脅迫）してコンピュータ化推進を行うことが任務だった。しかも、単にコンピュータ化するのではなく、それを機会に、業務の流れや組織体制を抜本的に変革することが、本当の使命であると認識していた。
近年では、ＩＴ部門は提案をしない、御用聞き部門になっていると批判されることが多いが、当時は、自らを変革の尖兵（チェンジエージェンシー）だと位置づけていたのである。また、ＩＴ部門を経営戦略とＩＴ戦略を結びつける戦略部門になるべきだといわれるが、当時の「室」はそのような位置づけだったのである。
私が所属していた企業では「合理化推進室」という名称だった。当時の国鉄（現ＪＲ）では、経営立て直しのため大規模な人員整理が行われ労組と激しく対立し社会問題にもなっていた。その人員整理が「合理化運動」と呼ばれていたので、名刺を出すのに「首切りの係」と思われないかとちゅうちょしたものである。
ＩＴ部門が積極的だった背景には、当時のＩＴ部員が、自分の業務に自信と誇りを持っていたことがあげられる。
一般社員からみればＩＴは特殊分野であり、ＩＴ部員が独占的な知識をもっていた。単純なプログラムが書ける程度ですら、存在意義があったのである。
コンピュータは高価で機能が貧弱であり、プログラム作成の生産性が低いことから、対象業務は給与計算、売上計算、財務会計など、大量データで処理ロジックが簡単な分野に限定されていた。小さいリスクはあるものの、提案が成功する確率は非常に高かったのである（というよりも、そのような「おいしい」分野をつまみ食いしたのだともいえる）。
また、プログラミングのテクニックにより、コンピュータの性能を最大限に引き出すことが、処理時間の短縮やコンピュータ費用の節減に直結した。個人的な技術力を高めることが、業務改善、会社の利益に直結していた。
コンピュータ導入から５～１０年経つと、当初想定していた多くの分野がシステム化された。それに伴い、ＩＴ部門は部員数が増大し「部」としての組織も整った。
システム開発、コンピュータ運用といったＤＰ（Data Processing：データ処理）業務に集中するようになり、それと裏腹に、往年のような誇りと自信を持った改革の尖兵的な性格は低下していった。
この頃になると、ＩＴ部員数は数十人になっていた。自社社員以外に、コンピュータメーカーからＳＥ（System Enginner）と称される技術者が数人常駐していたし、オペレータ（磁気テープやプリンタ用紙のセット、出力帳票の発送などのコンピュータ運用業務）は外注要員を用いていた。システム開発の繁閑に応じて多数の外注オペレータがＩＴ部員と一緒に作業していた（当時は請負と派遣の区別があいまいだった）。これら社外要員の数は、自社ＩＴ部員数に匹敵あるいはそれより多数であった。他の部と比較して大規模な組織に成長したのである。
システム化対象が広範囲になり、各システムの改良・拡大が行われるようになると、販売グループ、経理グループのように、担当を分化する必要がでてくる。また、システム開発以外に、ＩＴの高度専門技術、企画管理などのＩＴ業務が必要になり、それぞれの業務が専門化してきた。
参照：「情報システム部門の伝統的組織」
業務分析やプログラミングなど個々の業務が日常化してくると、以前のような改革のプロモータだというような性格はスローダウンしてきた。
そのような理由により、「電算室」は「情報システム部」となり、経営者直属ではなく、販売部や経理部や人事部のような普通の部になった。ＩＴの知識経験の高い人が情報システム部長になり、その上にＩＴ担当役員を置くのが通常だった。このＩＴ担当役員は後述の、ＣＩＯというよりは、情報システム部長の上司として稟議決済や相談に応じる程度の位置づけで、通常は他の部（経理部が多かった）も担当していた。
システム化が進むに伴い、対象業務のうち、単純にシステム化でき、その効果の高い業務（おいしい分野）は先輩たちが食い散らかしていた。残った分野は実現性や採算性が比較的低い分野である。
また、従来のシステム化は、給与計算とか売上計算など「点の業務」のシステム化であった。システム化の効果を上げるためには、それら点のまわりの業務もシステム化する必要があるし、給与や売上のアウトプットが財務会計のインプットとなるようにシステム間の連携が必要である。
利用部門のニーズに合致したシステムにすることが重要だとされ、「ユーザ主導」であるべきだといわれるようになった。
そもそも「ユーザ主導」とは、コンピュータメーカーの提案を鵜呑みにしてシステム化を行うのではなく、ユーザ企業が自社の戦略に基づいて行うべきだという、ごく当然の認識であった。
それが、ＩＴ部門と利用部門の間の関係にしたのはＩＴ部門の策略であった。コンピュータ導入当時、利用部門はシステム化に傍観者的態度だった。利用部門の積極的参画を促すために、システム化は利用部門のためであり、役に立つシステムにするには、利用部門が主導的に取り組むことが必要なのだといったのである。
それがいつの間にか、利用部門のニーズを実現することがＩＴ部門の任務だということになり、さらには、ＩＴ部門は利用部門のいうことだけを聞いていればよいということになった。これはＩＴ部門の責任回避でもある。
システム化の対象業務拡大の経過においてＩＴ関連費用が急激に増大した。
とかく利用部門は、処理の効率化による省力化の実現よりも、操作性のよさや出力帳票の体裁を重視する。業務の標準化よりも各人の業務に合致したシステムを望む。このような主張が強くなると、システムは必要以上に複雑化し巨大化する。
その結果、経営者に「カネ食い虫」だと思われるようになった。
１９７０年代中頃になると、経営環境は第１次オイルショックに続くマイナス成長、失業者の増大など深刻な不況の時代に入った。コンピュータ導入頃の変革志向のＩＴ関係役員は去り、管理志向の役員になっている。ＩＴ投資における費用対効果の検討が厳しくなった。
従来のような点のシステム化段階では費用対効果は明らかだったが、対象が複雑になると、ＩＴ部門ではその評価ができない。しかも、以前のＩＴ部員は、対象業務部門出身者が主流であったが、この頃になると、ＩＴ部門プロパーの比率が増大しているし、業務環境が変化しているので、現状の業務知識に乏しい。ＩＴ部門が不要だと思っても、利用部門から必須だといわれれば、それに反発するだけの能力がない。
ＩＴ部門は「ユーザ主導」と「カネ食い虫」の板挟みになった。
コンピュータの機能や性能は急速に発展し、１９７０年代中頃から後半になると、コンピュータ導入頃に重視された職人芸は不要になってきた。プログラミングだけに限定しても、多くの変化があった。
これらの変化は、技術をカネで解決するものであり、プログラミングを工業製品とみなすことである。これによる効果は高いが、プログラマを好奇心の高い職人から規則を遵守する工員にしてしまった。プログラマの能力への期待が低下したし、プログラミング作業を外注するのが一般的になってきたこともあり、プログラマの地位は下がった。
それに対して、ＳＥ（System Engineer：システム設計者）の地位が向上する。「ＳＥにプログラマの知識は不要だ」「プログラマあがりをＳＥにするな」などという主張が出てきた。そのＳＥがシステム工学や開発方法論を習得していればよいのだが、高度なプログラミング能力をもつＩＴ部員以外にそのような知識をもつ者は少ない。結果として、素人ＳＥが出現したのである。
それでは、適切なシステム化の提案をすること、プロジェクトを管理することは難しい。これがＩＴ部門の評価を下げた一因になった。
汎用コンピュータの基本的な概念はＩＢＭ３６０およびその後継機がベースになっているが、具体的な実装では、各メーカーが固有のアーキテクチャ（仕様）を用いていた。そのため、あるメーカーのソフトウェアは他メーカーのハードウェアには搭載できないとか、周辺機器は同一コンピューターのものでないと接続ができない状態だった。
そもそも初期の頃は、ソフトウェアはハードウェアのオマケであった。１９７１年にＩＢＭは、米国の独禁法への対応でハードウェアとソフトウェアを分離して販売するアンバンドリング方式に切り替えた。国産メーカーはかなり遅れたが１９７７年から実施した。
ハード・ソフトの分離は、コンピュータメーカーにとっては大問題であったが、ユーザ企業のＩＴ部門にとっては、たいした問題にはならなかった。
初期にはコンピュータメーカーを乗り換えることもあったが、この頃になると、全体のシステム規模が巨大になっており、その変換作業は膨大なものになる。メーカーが変われば、それまで仲間としてきたメーカーＳＥや開発外注要員も変わるので、新規の関係を築く間はかなりのトラブルが予想される。このような理由により、多くのＩＴ部門はメーカーにより抱え込まれてしまったのである。
このような状態では、ハードウェアもソフトウェアも単一メーカーで統一されているのだから、ソフトウェアの互換も気にならないし、価格構成が変わっても全体の金額が不利にならない限り関係のないことである。実際、アンバウンドリングによりメーカーを変えた例は稀だったと記憶している。
抱え込みは癒着につながる。部外者にはそう見られており、それがＩＴ費用の増大につながっているとの指摘もあった。
ところが、ＩＴ部門とメーカーの関係は、むしろ運命共同体のような関係だった。他メーカーを用いている同業他社とのＩＴ活用での優劣は、コンピュータメーカーの評価でもあった。メーカーから来ているＳＥは、自社よりも客先の利益を優先するような人が多かったし、メーカーも（現在と比較すれば）ユーザ志向が高かった。
また、当時のＩＴ部門は、同業他社ＩＴ部門との交流が盛んで、価格やサービスの内容は筒抜けだった。自社が不利のようだったら、メーカーに厳しく抗議したものである。
一般にＩＴ部門は他社との交流が盛んである。コンピュータメーカーによるユーザ会、同業ＩＴ部門の研究会が定期的に開催されていた。これがＩＴ部門のあるべき姿を討論したり、ＩＴ活用動向を調査したり有力な情報源だった。当時は、ＳＩＳ以前であり、経営戦略に触れずにＩＴの話をすることができ、技術と商売は別だという認識があったこと、社内ではこのような話題をする相手がいなかったことがその理由である。
１９７０年代末頃になると、ＴＳＳ（Time Sharing System）の実用化、汎用コンピュータでのの実現により、ＤＳＳ（Decision support system；意思決定支援システム）、特に、基幹業務系システムで収集蓄積したデータを、エンドユーザがＴＳＳにより、多様な切り口で検索加工するデータ指向型ＤＳＳが広まり、情報検索系システムと呼ばれるようになった。
また、オフィス業務の生産性向上に情報機器を利用すべきだとのＯＡ（Office Automation）の概念が広まり、パソコンがビジネスで利用されるようになった。
このように、エンドユーザが自主的に自らコンピュータを利用することをＥＵＣ（End-user Computing）という。
ＥＵＣ、特に情報検索系システムの普及は、ＩＴ部門と利用部門との関係を変化させた。適切な対応に成功したＩＴ部門は、新しいＩＴ部門の存在意義を高めた。
業務を取り巻く環境が変化するとともに多様な情報が必要になる。情報検索系システムによる対処は、利用部門が必要なときに必要な情報が容易に得られることになるので、利用部門にとって好ましい利用形態である。
販売部門や流通部門などのフロント業務部門では、現在の状況がタイミングよく把握でき、日常管理業務の質が向上する。企画計画担当部門では、問題発見、仮説検証などがスピーディに行えることから、計画立案のための強力な武器になる。
参照：
「情報検索系システムの日常業務への適用」、
「情報検索系システムの計画業務への適用」
この頃、ＩＴ部門は負荷増大で硬直化していた。対象業務は拡大し、保守改訂業務が多く、しかも、長期にわたるバッチ的修正で複雑化し、ベテランでないと修正ができない状況になっていた。利用部門からの要求を減らすためにも情報検索系システムの普及が期待された。
しかも、このような利用が浸透していれば、新規に開発するシステムにおいて、多様な帳票作成要求を情報検索系システムにまわすことにより、ＩＴ部門が管理するシステムの規模を抜本的に少なくすることができる。開発業務だけでなく保守改訂業務の負荷削減に役立つ。
参照：「情報検索系システムによる基幹業務系システムの合理化」
パソコンの利用部門への普及は、一時は「ＢＡＳＩＣ必要論」などの混乱を生じたが、オフィス業務の生産性向上に役立った。エンドユーザが表計算ソフトなどパソコンに熟達していれば、情報検索系システムでは汎用コンピュータからパソコンに必要なデータをダウンロードするだけでよく、その後の編集加工はエンドユーザに任せることができる。これは、情報検索系システム運営の負荷を低減するのに役立つ。
経営者に必要な情報を提供することはＩＴの主要な目的であるが、これまでは紙に出力した帳票であり、しかも日本語が使えなかった。数字とカナが羅列した帳票を山のように提出したのでは、経営者は見る気もしない。「紙屑製造機」どともいわれた。
それがＴＳＳにより、経営者は簡単な操作でほしいときにほしい情報だけを入手できるようになった。これは好評であり、ＩＴを経営者に身近なものにした。
ＩＴの費用を基幹業務系による省力化だけでカバーするのは困難である。情報検索系システムの活用こそ、業務改善に役立ち、場合によっては数億円のコストダウンにつながることもある。「カネ食い虫」だといわれたＩＴ費用をカバーするのに適した利用であり、ＩＴの価値を高めるのだといえよう。
ＥＵＣの普及のためには、ＩＴ部門の推進グループがインフラの整備や教育などを行う。これにより、利用部門の上位者と接触する機会が増え、ＩＴ部門の理解を高めることができる。
また、利用部門に「ＥＵＣ推進担当者」を設置する必要がある。それまでにも個人的な協力者はいたが、恒久的な組織としてオーソライズできた。しかも、ＩＴ部門はその担当者を統括する機能を得たので、担当者の選出、育成、指導などに発言できるようになった。
さらに発展すると、営業本部や本社経理部など業務統括部門に、ＥＵＣ推進担当組織を設置して、それが各利用部門の統括を行うようになる。それにより、ネットワークの整備や公開ファイルの整備などはＩＴ部門が行うが、具体的な業務に関するユーザサポートをその組織に移管できる。統括部門は業務の方針や実現方法に関する権限を持っている。とかくＩＴ部門は利用部門の要望に逆らえない体質があるが、統括部門を通すことにより、経営戦略に合致しない要求を却下することができる。
経営者は統合部門によく出かける。ＩＴ部門は統合部門のＥＵＣ推進グループと密接な関係があるので、それを介して、経営者と接触する機会が増大する。このような状況を作り出したＩＴ部門は、後述するＳＩＳの波にうまく乗ることができたのである。
自慢話で申し訳ないが、私は１９７８年に公開ファイル提供方式でＩＣを開設した。これは米国大企業と比較しても早期である（その多くは１９８０年頃であった）。
当然、ＥＵＣやＩＣという言葉すら知らなかったし、ＤＳＳの高邁な理論の実践でもない。当時の経営環境により、営業活動の強化が重要課題であり、コンピュータ部門にも人材供出の圧力が強くなった。人材不足にもかかわらずコンピュータへの要求は多い。それで「自分のことは自分でせよ－Do It Yourself」しかも「ひもじい者に魚を与えても一時の安らぎに過ぎない、魚の捕え方を教えれば一生の安定になる」などと勝手な理由を考えて、利用部門に押し付けただけである。
情報検索系システムの普及がもたらした効果に合併システムの早期構築がある。当然、合併システムの開発を急がなければならない。双方のコンピュータ部門が協議しているのと並行して、前述の業務統括部門のチームが他方の同等部門と協議をすすめ、コンピュータ部門に「本管まではコンピュータ部門、蛇口工事はＩＣ」（公開ファイル群を提供してくれれば、それを用いた資料のうち外部提出用以外のものはほとんど情報検索系システムで対応してやる）といってくれたのである。その結果、開発すべきシステムの規模が小さくなり。計画期間内で合併システムを実現できた。
効果の高いＥＵＣであるが、その運用を誤ると、大きな副作用を生じる危険性をはらんでいる。多くのＩＴ部門が、程度の差はあれ、深刻な影響を受けた。そのなかには、ＩＴ部門の価値にまで関するものもある。
情報検索系システムの提供方式には、個別メニュー提供方式と公開ファイル提供方式の二つがある（参照：「公開ファイル提供方式と個別メニュー提供方式」）。
情報検索系システム導入当初は、エンドユーザの人数も少ないし、エンドユーザ用のツールも未整備なので、個別メニュー提供方式をとるのが通常だった。
ところがエンドユーザが多数になり、個々のエンドユーザによりニーズが異なる状況になると、メニューを作成するＩＴ部門の負荷は急増してしまう。また、エンドユーザからすれば、メニュー以外の
欲しい情報が得られない、ＩＴ部門に頼んでもいつになってもメニューを作ってくれないという不満になる。
それを回避するために公開ファイル提供方式にするのだが、それを活用するには知識が必要になる。エンドユーザは知識習得に消極的なだけでなく「コンピュータ技術の習得はわれわれの任務ではない。情報提供はＩＴ部門の任務だ」というし、個別メニュー提供方式から公開ファイル提供方式に移行するのはサービスの低下だという。
さらにＩＴ部門内で「エンドユーザにファイルのジョインなどを教えるのは難しい」として、ジョイン後のすべての項目を展開したフラットファイルで提供したり、「複雑なＩＦ命令は使えない」として、個別帳票別のファイルにしたりする。このような過剰サービスにより、公開ファイル提供方式のメリットは限定的になる。
これには当時の技術的未熟がある。情報検索系システムではデータはＲＤＢ（Relational Database：関係型データベース）をＳＱＬでアクセスするのが適切である。ところがＲＤＢはあまりにも処理時間がかかるし、ＳＱＬはまだ国際標準にはなっておらず、ＩＢＭがその前身であるSEQUELを開発し各社が追従していたような状態で機能も不十分であった。実用的に利用でき普及したのは１９８７年前後である。
それまでは、データは基幹情報系システムと同様にＳＡＭファイルやＶＳＡＭファイルであり、それをいわゆる簡易言語でアクセスしていたのだから、エンドユーザに公開ファイル提供方式を押し付けるのは無理があったともいえる。
私の体験
実用的だった言語はEasytrieveだった。当時、ベンダのアシスト社はシステム監査用の言語としていたが、私はこれをエンドユーザ用言語として普及した。
ここで重要なことに気付いた。エンドユーザが困難とするのは言語文法の習得ではない。Easytrieveでも通常のプログラミングに必要な知識は半日で十分だった。エンドユーザは、どのようなファイルがあるのか、項目名は何か、その項目の定義は何かというような、提供するデータの内容がわからないのである。それで講習会に出席しても実務で使えないのである。
それを解決するために、「ユーザ辞書」を用意した。項目名の検索と内容説明、その項目名をもつファイルの検索、そのファイルを主入力よする処理のスケルトンのプログラム表示などをオンラインで使うことができる。
木暮 仁「連載 システム部門Ｑ＆Ａ 社内用語・概念を整理する「ユーザー辞書」は役立つ」
このような工夫により、初期の段階で公開ファイル提供方式を普及することができた（後日、アシスト社はEasytrieveをエンドユーザ言語だと広告していた。この事例が影響したのかも）。
すなわち、利用部門の要求回避によるＩＴ部門の負荷低減を目的したはずの情報検索系システムが、かえってＩＴ部門の負荷を増加させ、エンドユーザが要求への不満を大きくする結果になってしまう。
エンドユーザはきれいな体裁が好きである。情報検索系システムで得たデータを、パソコンのファイルに再入力して、罫線を引く、グラフにする、多色立体グラフにするというように、長時間かけて体裁を整える。その間にＩＴ活用による生産性向上のメリットは低減される。
本来は情報を得て実務に反映するのが目的なのに、一種のサボタージュである。それなのに、本人も周囲も真剣に仕事をしているように錯覚する。
しかも、その報告を受ける上司が、問題の指摘よりも帳票の美しさを褒める。それで、全社員が体裁向上に努める。その結果として、ＯＡは報告書美化が主目的になり、生産性はかえって低下する現象すら生じる。
参照：「ユーザの過度体裁愛好症」
この習性が顕著だったのがワープロである。ワープロ専用機は１９８０年代中頃に急速な普及をした。その講習会で、ワープロによる論理組み立ての容易化や再利用について関心をもつことは稀であり、エンドユーザが最も関心をもったのは罫線であった。
さらに１９９０年代に起こったワープロ専用機からパソコンへの移行では、既存文書の変換が必要になるが、このときも最大の問題は罫線の非互換である。それができないのでワープロ撤去に反対した。電子メールの導入でも、本文に罫線が使えないので、Word文書を添付ファイルを用い、バージョンアップとの関係で受取側が読めないという苦情も発生した。
パソコン利用が進む間に、ＩＴ部門よりもはるかにパソコン知識をもつスーパーユーザが出現した。
それ自体は好ましいのだが、ややもするとＩＴ部門に反抗する。しかも、そのようなユーザは業務にも有能であるため、エンドユーザや経営者への影響力が大きい。
標準化の必要性や全社システムとの整合性などは、ＩＴに素人な経営者には重視されない。むしろスーパーユーザの意見のほうが説得性がある。それで「ＩＴ部門は、業務のことを考えないコンピュータバカだ」と烙印をおされてしまう。
一般のエンドユーザではなおさらである。彼らはスーパーユーザを信頼し、ＩＴ部門を無視するようになる。
そもそもスーパーユーザは、ＩＴ部門が多大な協力により育成したのだ。それが立派に育ったのは喜ばしいことである。味方でいる場合は、上述のＥＵＣの効果をあげるプロモータとして信頼のおけるパートナーになるのだが、いったん敵に回すと恐ろしい存在になる。「飼い犬に手を噛まれ」ないようにする政策が求められた。
１９８０年代の後半から１９９０年代前半にかけて、ＳＩＳ（Strategic Information Systems：戦略的情報システム）、ＢＰＲ（Business Process Reengineering）の波が押し寄せた。これは、ＩＴ部門に根本的な変貌を求めるものであった。
参照：「ＳＩＳによるＩＴ部門の変化」
ＳＩＳにより、従来のシステム開発やコンピュータ運用といったデータ処理の業務（ＤＰ業務）よりも、経営戦略へのＩＴ動向の反映、経営戦略に密着したＩＴ戦略の策定の業務（ＩＴ業務）のほうが重要だと認識されるようになった。
ＩＴ部門は、ＣＩＯの指揮のもとで経営陣に直結した経営中枢での戦略部門であるべきだとされた。ＩＴ業務に専心させるには、ＤＰ業務を分離して情報子会社化あるいはアウトソーシングすべきだとされた。
これまでにＩＴは大きな成果をあげてきた。基幹業務系システムにより利用部門の単調業務から解放された。情報検索系システムにより多様な情報を容易に得られるようになった。パソコンの設置により日常業務の生産性が向上した。
このようなＩＴを運用管理しているＩＴ部門は、利用部門から重宝される存在になっていた。
重宝される反面、ＩＴ部門の社内的地位は次第に低下してきた。「ユーザ主導」といわれるように、利用部門とＩＴ部門の関係は「お客様と下請け業者」の関係になっていたのである。そこでは、「お客様の満足」が最大の目的であり、常に利用部門のニーズを探る「御用聞きＩＴ部門」と、それを無批判に実現する「すぐやるＩＴ部門」が高い評価を得ていた。
例えば、販売部門からのシステム化の要望に対して、ＩＴ部門が、流通部門や生産部門に与える影響が大きいので、それらの部門を加えて総合的に検討しようと提案する。販売部門としては、システム化実現が遅れるし、自分の要望とは異なるシステムになることを嫌う。
ＩＴ関連誌がＩＴ部門評価のアンケート調査結果を掲載することがある。それらによると、利用部門のＩＴ部門への評価は比較的高い。ところがその理由は、要望を実現してくれることであり、業務の抜本的改革を伴う提案をするからではない。
そのような状況になったのは、ＩＴ部門管理者が往年の使命感を失い、部員がＩＴ部門プロパーが多数になり他部門業務を知らなくなったことも原因であるが、ＩＴ部門が対象業務のシステム化に自信を失ったことが大きく影響している。
既に「おいしい」分野はなくなっている。しかも、ＩＴ活用が高度になり、システム化が組織体制や仕事の仕方を抜本的に変更する状況になってきた。しかも、対象が社外も含む広範囲になり関係者が多様になった。そのため、効果や実現への信念がぐらついてきた。そのため、自分から提案ができず消極的になり「ユーザ主導」が進んだのである。
当時、ＩＴ部門では自虐的に「２２２の法則」がいわれていた。「システム開発では、計画した２倍の費用、２倍の工期がかかり、１／２の機能しか実現できない」というのだ。その原因は要件定義の不備や変更、業務関係者間の不合意など、ＩＴ以外のことが多い。 →参照：「２２２の法則」
自信喪失が決定的になったのがＳＩＳである。経営戦略、競争戦略などが対象になると、何を提案すればよいのか、その実現可能性はどうかがわからない。そもそもＩＴ部員には経営者を経験していないし、一般に経営者は（経理部や営業部とは異なり）ＩＴ部門にはめったに顔を出さないのだから、経営者が何を思っているのか正確にはわからないのは当然だともいえる。
しかも、わからないのはＩＴ部門だけでなく、経営者も利用部門も同様である。分からない人たちの不明確なニーズや空想的な要望ではシステムは作れないのは当然である。それなのに、ＩＴ部門だけが責められるのは不条理だといえる。
しかも、ＩＴ部門はうまくいってあたりまえ、トラブルがあれば（その原因のいかんにかかわらず）叱られるので、リスクを回避しようとする本能が染みついている。そのため、経営者や利用部門がある程度マトモな要求をしても、消極的な態度にでる傾向がある。
ＳＩＳの概念の普及とともに、ＩＴ部門を戦略部門化すること、そのためにはシステム開発やコンピュータ運用などのＤＰ業務を情報子会社にしたりアウトソーシングすることが必要だとされた。
参照：「ＩＴ部門の戦略部門化とアウトソーシング」
これまで他部門のサービス部門であり下請業者的な社内地位にあったＩＴ部門にとって、企画部と肩を並べる経営中枢の戦略部門になること、日常的に面倒なＤＰ業務をアウトソーシングしてそれから解放されることは、非常に喜ばしいことである。ＩＴ部門はＳＩＳの重要性を提唱する側になった。
ＩＴの活用が業務革新に必要だとの理由により、ＣＩＯを委員長とし、各部門の部長クラスを委員とする「経営情報委員会」（名称は多様）が設立され、ＩＴ部門はその事務局になった。
これにより、ＩＴ部門はその活動を従来以上に各部門に認識させ、各部門への働きかけができるようになった。
この波に適切に対応できたＩＴ部門は、企業が経営的に成功しただけでなく、部長や部員に昇進の機会が多くなった。実際、ＩＴ部門を主な出身部門とする役員が続出するようになったのはこの頃からである。
しかし、大多数のＩＴ部門（当時のＩＴ部員）にとって、期待とは大きく異なる状況になってしまった。
経営情報委員会は、見方を変えれば、ＩＴの基本方針、予算編成、ＩＴ化優先順位の策定など、本来ならばＩＴ部門の最重要権限を放棄したことになる（「経営経理委員会」や「経営人事委員会」などをもつ会社は稀であろう）。しかも、ＣＩＯの大多数が他部門出身者でありＩＴの素人なので、ＩＴ部門の意見よりも利用部門の意見を重視する傾向がある。ＩＴ部門はオブザーバー、記録係のような役割になるｋとが多い。
また、経営的観点を重視するあまり、技術的な知識・経験が軽視されるようになった。それどころか、「ＩＴ部長をＣＩＯにするな」「（戦略・企画を担当する）ＩＴ部員は利用部門から選べ」となり、ＩＴ技術者はＤＰ業務専門職だとされて、情報子会社への移籍、アウトソーシング先への出向などが行われ、本体企業での昇進機会を奪われた。
このような状況に際し、ＩＴ部員はＩＴ技術習得に熱意を持たなくなり、他部門への異動を希望するようになった。野心のある人材は、ＩＴ部門を避けるようになった。
この背景には経営者のＩＴへの認識の低さがある。タテマエではＩＴが重要だといっているが、ホンネでは軽視している。そもそも、ＩＴ部門の戦略部門化をいうのは、戦略部門である経営陣や企画部門にＩＴがわかる人材を育成・配置してこなかった証である。
また、そのような人材がいないので、適切なＣＩＯを任命できなかった。現在ですら日本のＣＩＯの大多数は、ＩＴの素人であり、他の業務との兼任（ＣＩＯの割合は低い）である。
参照：「ＣＩＯの現実」
素人ＣＩＯの下で、利用部門からの素人ＩＴ部員、技術を放棄した旧ＩＴ部門出身者からなる部門が適切な「ＩＴ戦略」を実現できるはずがない。旧ＩＴ部門出身者は、うまくいって当たり前、エラーがあれば（他部門が原因でも）がれば叱られるというリスク回避の体質になっており、本質的にハイリスク・ハイリターンの経営戦略には適していない。利用部門出身者はＩＴ固有のリスクを知らない。
その結果、リスクを無視したＩＴ化になりそうだが、素人ＣＩＯは「ＩＴ費用を下げる」ことを重視する傾向があるので、致命的失敗を避けることができる（なかには無茶なＥＲＰパーッケージの導入やダウンサイジングを行い、多額の損失を出した例もあるが）。
多くの新ＩＴ部門は、ＩＴ予算の管理、情報子会社やアウトソーシング先の価格設定の監視などが主任務になり、戦略設定などには成果をあげていないことが多い。
情報子会社やアウトソーシングにすることは以前から行われていた。しかし、以前は、銀行など副業が禁止されていたため、ＩＴ技術者を大量採用するため、新規事業を立ち上げるためなど、なんらかの目的が明確であった。それに対して、この場合には、「ＩＴ業務に専心させるため」であり、情報子会社設立そのものには積極的な目的がないのが特徴である。
●外販志向の子会社
独立の性格が強く、技術力にも優れた子会社は、親会社やその関連企業以外の第三者へのサービスを拡大し、ユーザー系情報システム業として独立し、親会社よりも高い業績を生んでいることもある。
外部志向の場合、進出市場を明確にすること、その市場におけるコア・コンピタンスをもつことが必要である。成功した子会社はそれができていた。
ところが、「ＩＴ業界の成長率が高いから」とか「長年、自社システムを構築した経験があるから」など単純な理由で決定したケースが多いのである。これでは、成功の保証はない。親会社やその関連企業のサービスが一巡すると、第三者へ進出して成功するだけの競争力を持たないため苦労することが多くあった。
当時、日本経済が低成長時代にあったのに、情報サービス業界は高い成長率を示していた。ところがその統計にはウラがある。製造業のＩＴ部門の費用は製造業にカウントされる。それが情報子会社として分離すると、その費用は情報子会社の売上になり情報サービス業にカウントされる。情報サービス業のうち、いわゆるユーザ系を除外すると、その成長率はたいして高くなかったことを記憶している。
なお、情報子会社は親会社だけでなく関連会社のＩＴ化に積極的であった。その関連会社には中小規模のものが多く、ＩＴ部門は弱体で、システム構築や運用を外部に頼っていた。それを取り込んだのだから、アウトソーシングではなくインソーシングというのが適切であろう。
●内需志向の子会社
多くの子会社は、親離れ・子離れが進まず、主として親会社やその関連企業のサービスを行ってきた。この場合、親会社ＩＴ部門と子会社の関係は千差万別である。
ＩＴ部門が親会社のＩＴ基本方針を定め、利用部門の要求を査定してビジネスとしてのシステム仕様を定める。子会社はそれ以降のシステム構築や運用を担当し、それを低費用で円滑にするためのハードウェアやソフトウェアの選定や各種標準化などを行うというのが理想的であるが、そうならない場合も多い。
親会社に「子会社＝下請」の意識が強く、ＩＴ部門がＩＴガバナンス能力が低い場合は深刻な状態になる。利用部門は情報子会社に依頼というより命令のような態度で要求する。子会社は、ＩＴ化の予算や優先順位はＩＴ部門の所轄だから、ＩＴ部門を通してくれという。ＩＴ部門は、システム化の工数や納期、他のシステムとの整合性などがわからないので、子会社に取りまとめを指示する。子会社に能力があり、本体のＩＴ化を真剣に考えている場合はしかるべき案を作成できるが、これでは子会社が戦略部門になってしまい、ＩＴ部門の存在意義がなくなってしまう。そうでない場合は、子会社は各利用部門からの要求とＩＴ部門からの予算枠の締め付けに悩み、声が大きい利用部門を優先することになる。しかも、その利用部門の代弁者となってＩＴ化の正当性を説明させられるようなことにもなる。
子会社にとって心配なのは、内需志向／外販志向が親会社の思惑により変わることである。分離当初は内需志向だとして、プロパー採用ができないどころか、親会社スリム化の受け皿にさせられる（優秀な人材が送り込まれるはずがない）こともあった。親会社に不要な分野の研究もできないし、していない。
それが、親会社の収益低迷やＣＩＯの異動により、突然に外販志向になることが強制される。子会社に競争力がない。解散してリストラ対象になるか、身売りされる羽目になる。
そもそもＩＴ部門（ＤＰ業務）を子会社化するのは、経営者がその分野が親会社のコア・コンピタンスと思っていないからである。他の部門に比べてＩＴ部門の子会社化が顕著だったことは、経営者が（タテマエはともかくホンネでは）ＩＴ部門などは不要だということを態度で示したことになる。そのような部門が社内的地位が低いのは、むしろ当然だといえよう。
１９８０年代末になると汎用コンピュータによる集中処理から、多数のパソコンをネットワーク接続した分散処理へと移行するダウンサイジングが始まった。
参照：「汎用コンピュータ（メインフレーム）の歴史」
１９９０年代初に、ＩＴ関連の雑誌や論者は、動機は不明だが、ダウンサイジングを礼賛するとともにＩＴ部門をバッシングした。
「ダウンサイジングにより大幅なコストダウンが実現し、利用に適したシステムを容易に構築することができる。それなのに、ＩＴ部門は汎用コンピュータに固執している保守反動派である。ＩＴ部門は悔い改めるか去れ」という論調である。これが、ＳＩＳからのＩＴ部門変貌必要論あるいはＩＴ技術者不要論と結びついた。
この頃になると、経営者もＩＴに関心をもち、ＩＴ関連の雑誌を読むようになっていた。経営者はダウンサイジングの内容はわからなくてもコストダウンはわかる。ＩＴ部門はコンピュータメーカーと結託してＩＴ予算を浪費していた不逞の輩だったのかと疑った。ＩＴ部門は信頼を失ったのである。
オープン系礼賛、ＩＴ部門バッシングの例として「ＩＴ部門がレガシー環境で３人月かかったシステムを、エンドユーザがオープン系で１週間で構築した」というような記事が氾濫した。エンドユーザが短期間で開発できるのは、エンドユーザは自分だけ、そのシステムだけを考えればよく、他のシステムとの整合性や入力チェックなどの周辺環境、標準化や文書管理などの改訂への考慮をしないからだというのは明らかである。それらをあえて言及していないことに作為を感じる。
さらに後日、担当者が異動になり、ブラックボックスのシステムが残されてしまったことなどは話題にもならない。Ｊ－ＳＯＸ法への対処で、このようなシステムが大きな問題になっても、マスコミは当時に自分が礼賛したことを思い出そうともしない。
前述したようにＩＴ部門はリスク回避の文化に染まっており、それがダウンサイジングに慎重な態度をとったのだといえるが、ＩＴ部門の状況分析は正しいこともあった。
ダウンサイジング以降のシステムをオープンシステムといい、汎用コンピュータ時代のシステムをレガシーシステムという。「オープン」とは、メーカー独自のアーキテクチャではなく、Windowsのようなデファクトスタンダードに対応した、すなわち、メーカー間でオープンだという意味であるが、なんとなく「ＩＴ部門の閉鎖的な環境ではなく、開かれたシステム」であるように思われるし、 レガシーとは「伝統的な」ではなく「古臭い」という意味で使われた。なかにはフランス革命とアンシャンレジームの挿絵を用いた雑誌記事もあった。
１９９４年にガートナー社は、パソコン１台を購入・運用する総費用（ＴＣＯ）の調査を発表した。それによれば、パソコンのハードウェアとソフトウェアの費用は総費用の２０％程度であり、利用部門の人件費が５０％近くになる。そして、総費用は集中処理よりも高額になると指摘した。まさしく「人身御供」コストである。
これらはその後正しいことが判明されたが、当時は説得すればするほど保守反動派の陰謀だと思われた。ところが経営者には、ＩＴ部門を無視したダウンサイジングを強行するほどの能力はない。ＩＴ部門もコストダウンに努力していることを示さなければならない。それで、中途半端なダウンサイジングになった。
汎用コンピュータ時代では、グローバルな観点ではＩＢＭ、自社ローカルな観点では丸抱えされているコンピュータメーカーの動向を把握していれば、それなりの信頼できるＩＴ活用の方向付けができた。
ところが、当時のオープン環境では群雄割拠の戦国時代である。パソコンでは既にマイクロソフトが独占的地位を得ていたが、それでもWindows95以前である。ＬＡＮのＯＳやサーバＯＳ、各種ミドルウェアでは、どれが将来優勢になるかわからない。
ＳＩＳ以降、ＩＴ部員はＩＴの技術習得の動機を失ったし、高度なＩＴ技術者は子会社へ移っている。ＣＩＯはＩＴの素人である。
このような環境において、ＩＴ部門は、戦略部門になったのに、その基本的な機能であるＩＴインフラに関する戦略を示すことができなくなった。時間が解決するので静観する態度にでた。すなわち、及び腰でダウンサイジングに対応したのである（結果として、これは正しい選択だったといえる。もたもたしている間にインターネットが普及し、社内ＬＡＮでもその技術を使うようになったのだから）。
（幸いなことに？）このＩＴ部門の無能は、経営者や利用部門に知られることはなかった。彼らは、アプリケーションには関心をもつが、ＯＳやミドルウェアについては関心も知識もない。ＩＴ部門が、方向付けができないことに悩んでいることすら気づかないのである。
米国では、この時代にＩＴ素人ＣＩＯが追放され、プロとしてのＣＩＯが出現する機会になったのだが、日本ではその機会がないまま、現在までＩＴ素人ＣＩＯが存続することになった。
汎用コンピュータ時代のシステム開発は、極端にいえば、ＪＣＬ（ジョブ制御言語）とＣＯＢＯＬを知っていれば、ほとんどのシステムが構築できた。当然、ネットワークやデータベースの知識は必要であったが、コンピュータメーカーにより、インタフェース仕様が標準化されており、ＪＣＬやＣＯＢＯＬの拡張機能として実現されていた。すなわち、システム開発者には、標準化された数少ない道具を用いて高度なシステムを作る能力、いうなれば外科医的な能力が求められていたのである。
それに対して、オープン環境でのシステム開発者に求められるのは内科医的能力である。マルチベンダで多種多様なツールがあり、それを適切に組み合わせる知識が必要である。プログラミングはオブジェクト指向言語が主流になり、多様なコンポーネントをカスタマイズして組み合わせる技術が必要になる。数多い薬の特徴をよく理解して、症状にマッチした調合をする能力が求められるのである。
開発環境が大きく変化した。データの入出力インタフェースはＧＵＩ環境で行うが、その部分のシステム開発もＧＵＩでデザインしながら構築する。データベースの設計もＧＵＩ環境で画面操作で行う。「マウス開発環境」になったのである。
ファイル編成が大きく変化した。汎用コンピュータでは通常のファイルではＳＡＭファイルとＶＳＡＭファイルが使われていたが、それはプログラム言語やアプリケーションから独立していた。ＣＯＢＯＬで記述したプログラムで作成したデータファイルをＰＬ／Ｉのプログラムでアクセスできるのは当然だった。データベースはＮＤＢやＲＤＢなど方式による非互換はあったが、同一方式間ではかなりの互換性があった。それに対して、オープン環境ではファイル編成方式がWordやExcelなどアプリケーションごとに違う。ＣやＪａｖａなど手続き型言語間でも互換性に乏しい。
このような変化は、新しい概念の習得が必要になるが。いわゆるＣＯＢＯＬプログラマにとって、従来の知識が、かえって習得の妨げになることもある。特に、中高年にとって難しいものである。それで「ＣＯＢＯＬプログラマを入れるな」という風潮が生じた。
当時は汎用コンピュータが残っていたし、そのシステムの保守改訂作業も多かったので、ＣＯＢＯＬプログラマとしては、あえてオープンシステムに従事しなくても、十分な仕事があったのである、
このような理由により、オープンシステムは主に若い人たちが担当し、既存の汎用システムは年配者が担当するといった二分化が進んでいった。
当初のうちは、考慮すべき他のシステムや標準化規程もなかったので、オープンシステムの生産性は高く、オープン環境の優位性（逆にレガシー環境の劣等性）が喧伝された。ところが、対象業務の拡大、既存システムの保守改訂が行われる段階になると、他システムとの連携の悪さ、保守頻度の増大、保守資料の欠落などが大きな問題となった。
ベテランは長年かけてシステム開発方法論、ソフトウェア工学などを習得し、全社的な観点、システムのライフサイクル全体を通した観点で対象システムを把握することを身に着けていた。学問的に学習しなくても、世間的常識から、それに合致したルールを作ってきたのである（それすら身に着けなかったＣＯＢＯＬプログラマは、従前から不要の存在だったのだ）。
それが、担当の二分化により伝承されなかったのが大きな原因だとされた。団塊世代が定年になるとベテランのノウハウが消えてしまうという「２００７年問題」を防ぐことが重視された。
当時「ネオダマ」という言葉が流行った。ネットワーク、オープン化、ダウンサイジング、マルチベンダ（マルチメディア）である。ここでは、マルチベンダ化がＩＴ部門へ与えた影響を取り上げる。
汎用コンピュータ時代では、汎用コンピュータメーカーのプロトコルでネットワークもパソコンも統一されていた（シングルベンダだった）。ところが、ダウンサイジング環境では、多様な技術が組み合わされる。そのすべてに汎用コンピュータメーカーが最善のサービスを提供するのは不可能である。ハードウェア、ソフトウェア、ネットワークなどそれぞれの分野で、最も適したベンダを起用するのが適切である。不可避的マルチベンダ化である。
さらに、これまでシングルベンダに癒着していたが、例えば同じ機能のパソコンでも、あえて複数ベンダを競争させてコストダウンを図るべきだという、積極的マルチベンダ化も行われるようになった（「混一色よりも清一色のほうがよい」というＩＴ部門の反論は癒着正当論だとして却下される）。
この風潮は、ＩＴ部門と汎用コンピュータメーカーの関係を疎遠にさせた。これまで独占的に密接な関係にあった汎用コンピュータメーカーは、多数のベンダの一つに過ぎなくなり、しかも、積極的マルチベンダ化により、優先度が低くなってしまったのである。
さらに、「サービス有料化」も進み、メーカーからの常駐ＳＥもいなくなってしまった。ＩＴ部門は親密な相談相手を失ったのである。
逆に、新しいベンダが積極的にアプローチするようになった。彼らはＩＴ部門よりも経営者に直接アプローチする。そのとき、従来の方式が不合理であったことを吹き込むことが多い。経営者はベンダの能力評価よりもＩＴ部門への不信感を募らせる。
マルチベンダ環境では、納期の遅れや故障などのトラブルが発生したとき、ＩＴ部門が問題を分析して担当するベンダを特定するなど、高いマネジメント能力を求められる。ところが、アウトソーシングや子会社化により、そのような技術力は低下している。従来よりも解決に時間がかかるようになった。
その対策として、システムインテグレータに一括発注することになる。ところが、当時は汎用コンピュータメーカー以外のシステムインテグレータが未熟で、自分たちが経験したハード・ソフトに限定するため、適切な組み合わせができないとか、上流工程に集中して下流工程はベンダ任せにするなど、不適切なことも多くあった。
さらに、個々のシステムで異なるシステムインテグレータを起用したため、全体としての標準化が崩されてしまうことがあった。
ダウンサイジングは、ＥＵＣ環境の発展形態だともいえる。
ＴＳＳによる情報検索系システムは、利用部門に設置された部門サーバに、その部門に必要なデータを使いやすい形式で保管することができるし、基幹情報系システム以外にローカルで収集したデータと組み合わせて、より充実した情報に加工できる。
パソコンで作成したアプリケーションやデータをサーバで共有することにより、利用範囲が大きく広がる。グループウェアの導入は、オフィス業務を一変させたともいえる。
このような変化により「ＥＵＣ推進担当者」の任務はさらに重要になった。ＬＡＮなどインフラのトラブルへの対処、サーバに保管されたデータのバックアップなど、ＩＴ部門が汎用コンピュータの運用で行っていた業務を（規模は小さいが）、利用部門でも行うようになったのである。
そのため、担当者に利用部門の人をあてることが困難になり、ＩＴ部門から利用部門に要員を転出させる（人身御供！）ことが多く見られた。
その転出者の取り扱いにより、光と影のケースがある。
光のケースは、転出者をヒーローにすることである。単なるＩＴ運用者としてではなく、（コンピュータ導入当初のＩＴ部門がすであったように）業務改革のプロモータとして位置付ける。部長や支店長の補佐として、その業務の本質を理解させ、その改革へのＩＴ活用を考えるように仕向ける。ＩＴ部門は、彼の意見を尊重し、かなり無理をしてもその実現に協力する。ヒーローにすれば、周囲の協力が得られやすいし、その成果も高まる。若手社員は彼のようになることを期待して、進んで協力するようになる。
影のケースは、便利屋にされてしまうことである。基幹業務系システムでのデータ入力、情報検索系システムでの出力依頼など本来は他の者が行う仕事まで押し付けられる。そしてすべてのトラブルに責任を押し付けられる。利用部門の会議なども、任務が違うからといって出席させてもらえない。そのため、利用部門の仕事も覚えられないし、ＩＴ部門の協力もえられないまま、ＩＴの動向にもついていけなくなる。利用部門の人たちは、このような便利屋になりたくないので、ＩＴを避けるようになる。
ある企業では、むしろ積極的に人身御供を差し出した。そのとき、ヒーローになるであろう優秀な部員を選出した。転出先の部長にヒーローになるような取扱いを協議し、彼の行動はＩＴ部門が全力で支援することを約束した。彼は、その部門で大きな功績をあげた。それが評価されて本社の業務統括部門へ引き抜かれ、後に役員になった。
このような計画的異動を継続的に行った結果、役員や中枢部門にかなりの人材ができた。それが、戦略部門としてのＩＴ部門の活動を円滑にしているだけでなく、ＩＴ部門の社内的地位の向上につながっている。
基幹業務系システムは汎用コンピュータを維持するなど、中途半端なダウンサイジングの状況で、ヒットしたのが電子メールや電子掲示板（会議室）などを主な機能とするグループウェアであった。
これは経営者や利用部門のコンピュータ観を一変させたといってよい。「これで初めてコンピュータが役に立つことがわかった」といった経営者や、「グループウェアを導入することが目的でダウンサイジングするのだ」といった論者もいたほどである。
グループウェアがＩＴ費用論議をある程度緩めたし、この普及が社内でのインターネット利用を円滑にしたといえよう。
グループウェアは、ほとんどが利用部門だけで運営できる。ＩＴ部門はソフトウェアを選定してインストールしたこと、電子メールや電子掲示板のディスク容量の上限設定とその管理をする程度であり、手離れのよいシステムである。それが、実際のＩＴ利用の大部分を占めるようになったのだから、ＩＴ部門としては、うれしいような淋しいような複雑な思いであった。
ＩＴ部門はグループウェアの導入提案に不安があった。経営者は投資の費用対効果を重視する。ところが、グループウェアの効果を説明するのは困難である。
「情報の共有化」では、「誰と誰が何の情報を共有化するのか」を具体的に示して、グループウェアがある場合とない場合の効果を示すのは困難である。「ペーパーレス」では、紙の購入費用なら１円程度だが、配布・保管・検索・再利用などを考えれば数百円になろう。どの値を用いるかはかなり主観的である。
それを誤魔化すために（？）、パソコンやＬＡＮは既に存在することにして、グループウェアのソフトウェア費用だけを計上するなど対策を練った。
ところが、グループウェアを仮インストールして実演すると、そのような費用対効果を問題にする人は少なかったのである。経営者は自分が是としたことには、寛容であることがわかる。
その結果に自信をもち、今度は「グループウェアの普及のために」として、１人１台のパソコン配置を提案するようになる。
１９９０年代中頃から大企業ではＥＲＰパッケージ導入が進んだ。 →参照：「ＥＲＰパッケージ」
システム開発や運用などのＤＰ（データ処理）業務をアウトソーシングして、経営戦略部門化したＩＴ部門にとっては、ＥＲＰパッケージの導入によりシステム全体が標準化され「見える」状況になる。コストダウンになることも期待できる。
さらに、ＥＲＰパッケージの導入にあたっては、経営者や利用部門の積極的な参画が重視されるが、ＩＴ部門はその統括部門として中心的な立場になる。ＢＰＲ推進部門として本来の任務が行われるようになる。ややもすると単なるＩＴ管理部門になりがちであったＩＴ部門にとって、存在意義を高めることになる。部門的な観点からも期待された。
しかし、ＤＰ業務を主業務としているＩＴ部門にとっては、ＥＲＰパッケージは脅威になった。
それまでに、ＩＴ部門は多くのアイデンティティを失ってきたが、「自社システムのことは自分たちが最もよく知っている」という自負があり、周囲もそれを認めていた。
ところが、ＥＲＰパッケージでは、出来合いのプログラムを自社の状況に合わせてパラメータを指定（カスタマイズ）すれば、システムが出来上がる。そのパラメ－タ設定は、ＩＴではなく業務に関することだから、ＩＴ部門が参画しなくても、利用部門とベンダ技術者だけで行える。すなわち、ＩＴ部門にとって基幹業務系システムまでブラックボックスになってしまったのである。しかも、出来上がったシステムは、ＥＲＰパッケージのバージョンアップでの継続性を保証するために、ベンダに依頼しなければ改訂も拡張もできない。ＩＴ部門は、システムの開発や保守について、利用部門とベンダとの電話交換手になってしまった。
当時のＥＲＰパッケージに慎重なＩＴ部門はかなりあった。例えば、次のような懸念があり、それを考慮すべきだと指摘したのだが、真剣に受け止められなかった。
それに対してベンダは、ＥＲＰパッケージの優位性を主張するために、既存システムの欠点をあげつらった。そして、ＢＰＲの実現のために、自社独自の業務の仕方を欧米の成功企業のノウハウを取り入れ国際標準となっているＥＲＰパッケージに合わせることが重要だと経営者に売り込んだ。ときには、保守反動派であるＩＴ部門を、検討グループから締め出すべきだと主張することさえあった。既存システムの事情を知らない経営者は、ベンダの意見を鵜呑みにして、ＩＴ部門への不信を募らせた。
ＩＴ部門の懸念は無視され、導入検討では軽視されたのにもかからわず、開発が始まると利用部門は退き、ＩＴ部門が開発責任部門になる。パラメータ間の矛盾、パッケージ自体の不備、サーバＯＳやミドルウェアとの不適合、運用負荷への対応、他システムとのインタフェースの不適合など、多様なトラブルが発生する。
ＥＲＰパッケージによるシステムを安定稼働するために、費用や納期がかかってしまい、当初期待した機能を削除した例も多かった。
この開発での難航が本質的な問題を招くこともあった。あまりにも苦労したため、そのシステムを稼働することだけが関心事になってしまい、肝心のＢＰＲを実現すること、業務改革を行うことが忘れ去られてしまう。「ＥＲＰパッケージは稼働した。ＢＰＲはこれからだ」といった企業が多かったのである。そして、不条理なことだが、その責任はＩＴ部門にあるとされた。
実際にＥＲＰパッケージによるシステム開発が難航した例が多かった。昼間の講演会で、ＥＲＰパッケージ導入について発表し利点を列挙した先行企業の人が、夜の酒席では、ＥＲＰパッケージによる開発での苦労を愚痴り、二度とＥＲＰパッケージにはかかわりたくないといったとか。
１９９０年代中頃からのインターネットの爆発的な普及は、２０００年頃にはＩＴ革命といわれるほど、広範囲に急激な変化を与えた。企業でのＩＴ活用も大変化が生じた。
しかし、１９９０年代の間は、社外ネットワークの発展、社内ＬＡＮの環境変化といったＳＩＳやダウンサイジングの延長であった。ＩＴ部門にとっては、これまでの変化が加速されたが、質的な大変化はあまりなかった。しかし、その兆候に早く気づき対応したＩＴ部門と、変化に乗り遅れたＩＴ部門とでは、その後の環境変化で大きな差が生じるのである。
インターネット技術－特にＩＴＰ／ＩＰとＷｅｂブラウザ－を社内ＬＡＮに適用した形態をイントラネット、関係会社や主要取引先との企業間ネットワークに適用したものをエクストラネットという。
参照：「イントラネットとエクストラネット」
イントラネットはダウンサイジング環境の標準化に効果があった。それまで多様なＬＡＮやサーバのＯＳやミドルウェアが存在し、アプリケーションによりファンクションキーの機能が異なっていた。
それが、ヒューマンインタフェースに関する部分は、Ｗｅｂブラウザに類似したものになった。利用者はＷｅｂブラウザの操作に習熟している。そのため、新アプリケーションの導入では、業務に関する事項の説明だけでよく、操作方法の説明は不要になった。
多くの市販アプリケーションがＬＡＮ対応（Ｗｅｂサーバ対応）になった。バージョンアップがあっても、サーバのソフトを更新するだけでよく、従来のようなクライアントソフトの変更が不要になった。
エクストラネットはさらに容易になった。従来は、専用回線の費用分担、通信プロトコルの確認、通信端末の統一など、多くの協議事項があったが、インターネット利用により大部分が不要になった。さらには、一方が独断でＷｅｂサイトを構築してアクセスしてもらうだけですむようになった。
このように、イントラネット・エクストラネットは、ＩＴ部門をシステム構築や運用での付随的な作業から解放するのに大いに役立ち、急速にそれらに移行した。
インターネットの普及により、利用者と社内システムの関係が変わった。それまでは、一般の人たちは、パソコンのワープロや表計算機能は使っていたが、本格的なＩＴ利用は会社が設定した環境ではじめて接したのである。
ところが、インターネット利用は社会常識になった。会社でも利用の大部分はグループウェアであり、電子メールや電子掲示板などインターネットのローカル版である（しかも、グループウェアをインターネットで代行する動向も出てきた）。基幹業務システムや情報検索系システムもヒューマンインタフェースはＷｅｂブラウザに似ている。
利用者にとっては、インターネットこそがグローバルなＩＴなのであり、社内システムは限定されたローカルなＩＴの位置づけになったのである。
インターネットがＩＴ部門に与えた大きな影響の一つがウイルスや不正アクセスなどの脅威である。セキュリティ対策がＩＴ部門の主要任務になった。
インターネットが普及する以前からウイルスの脅威はあったが、当初はフロッピーなどの媒体によるものであった。それがＬＡＮを介して伝染するようになり、インターネットからの感染が多くなるのにつれて深刻な問題になってきた。
当時は、セキュリティへの関心が低く、ＩＴ部門に専門的知識がなかった。経営者は利益に直結しない投資に冷淡だった。エンドユーザは規制されることに反発した。
本格的なセキュリティ対策が講じられるようになったのは、インターネットが普及してから数年後である。
一部の企業を除き、自社のＷｅｂサイト開設は、会社案内などの広報から始まった。しかも、プロバイダにＷｅｂページ作成を依頼し、プロバイダのサーバを利用するのが通常だった。そのため、広報部門や営業部門などコンテンツに関係する部門とプロバイダとの直接交渉で行われ、ＩＴ部門が参加するとしても中心的な役割にはならなかった。
ところが次第に適用業務が拡大してくる。最初に組み込まれたのはグループウェア機能であり、関係会社や取引先などを含む電子メールや電子掲示板であった。社内のグループウェアにそれらから直接に入るのには抵抗があったし、第三者がアクセスする一般のインターネットでは困るからである（セキュリティ対策が不十分なＶＰＮ、ＳＮＳのような形態）。
それが進むと、受発注業務にまで適用しようとの動きになる。これは基幹業務系システムであり、その機能設計にはＩＴ部門が主体になるべきである。ところが、ＩＴ部門不在のままかなりの段階まで検討が進んでしまい、実装して運用する段階になって、既存システムとの連携がうまくいかないことが露呈してトラブルが発生するケースも生じた。特に取引先との折衝が進んでいた場合には、大きな問題に発展した。
ＩＴ部門が参加した場合でも、Ｗｅｂシステム開発は、汎用コンピュータやダウンサイジング環境でのシステム開発とは、方法論も実装方法もかなり異なる。ＩＴ部門にはその経験がない。参加しても、既存システムとのデータ授受についての意見をいう程度で、存在感が薄い状況になる。
セキュリティ対策やＷｅｂシステムの出現は、当初は深刻な問題ではなかった。しかし、この時点で積極的に対応したＩＴ部門は、その後のインターネットが普及した段階で、重要な戦略的な部門になる。
それに対して、イントラネットやエクストラネットにより作業負荷が低減したことに満足していただけのＩＴ部門は、時代の流れについていけず、存在意義すら問われることになる。
１９９０年代末から２０００年前半にかけて、電子商取引の発展、サプライチェーンマネジメントなど、インターネットをインフラとした経営環境が大きく発展する。ＩＴ経営ともいわれるように、ＩＴなしには経営戦略を考えることはできなくなった。
日本企業は米国企業と比較して、全投資に占めるＩＴ投資の割合が低いだけでなく、ＩＴ投資での戦略的投資の割合が低い、すなわち、日本企業ではＩＴの戦略的活用が遅れていると指摘されている。その原因の一つに、ＣＩＯがＣＩＯとしての任務を果たしていないことがあげられる。
また、ＩＴ部門への批判では「提案をしない」ことがあげられている。これはＩＴ部門の責任でもあるが、経営者がＩＴ活用に関して自ら取り組んでいないともいえる。
もはやＩＴはＩＴ部門の所轄ではなく、経営陣や企画部門などが中心となって取り組むべき対象になった。企画部門が担当するゼネラルスタッフ機能のうち、ＩＴが占める割合が大きいので、それをＩＴ部門として独立させたのだというような認識が必要になってきた。
また、ＩＴ部門のＤＰ機能が必要だとの再認識も出てきた。企業環境は激変する。それに即応あるいは先取りするためには、システム構築や改訂を迅速に行う必要があり、システムの内製化が求められる。ところが、情報子会社化やアウトソーシングにより、ＩＴ能力は空洞化している。本体の復帰が必要だという動きが出てきた。
ＩＴ部門のアウトソーシングは米国から輸入された思想だが、日本では米国を超えた極端なＩＴ部門縮小が行われた。日本企業でのＩＴ部員数は米国企業の数分の一であるという。日本では社外要員が多いこと、利用部門にもＩＴ関係者がいることなどを勘案しても少ない。
そもそもアウトソーシングや情報子会社化したのは、経営者がその業務を自社のコア・コンピタンスではないと軽視していたからであり、軽視の度合いが日本のほうが大だったのだ。
その当時ですら、空洞化は指摘されていた。それがこの時代になって回帰の動きがでてきたのは、時代の変化というより、経営者の誤認識が責められるべきだと思う。
２０００年代後半には、クラウドコンピューティングの動向が進んできた。ハードウェア、ソフトウェア、データなどすべての情報資源はプロバイダ側にあり、利用企業にはクライアントしかないという環境である。情報システムは自社で所有するのではなく、プロバイダが提供するサービスを取捨選択して利用すればよいのだという考え方である。
参照：「ＳａａＳ／クラウドコンピューティング」
すべての情報資産を所有しない時代にあって、ＩＴ部門は何を任務とするのであろうか？ ますます戦略部門として重要視されるだろうか？ 経営者やゼネラルスタッフでないＩＴ部員は存在価値があるのだろうか？ あるいは、この動きは単なるブームであり、コアコンピタンスとなる分野のシステムは自社構築するのが当然だといわれるようになるのだろうか？
現在では現実的な答えはないが、これがＩＴ部門の存亡に関する大きな転換期であることは確かであろう。