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