主張・講演＞ 情報システム部門の戦略部門化とアウトソーシング
ここでは，ユーザ企業での情報システム部門，しかもデータ処理を主任務としている情報システム部門での部員育成が困難な状況になっていることを示します。
部員の育成には，情報技術の動向がどのように変化していくか，企業や情報システム部門がどのようなスキルを必要としているかといった前提が必要ですが，その前提が時代とともに大きく変化してきました。
昔は，技術進歩も今から振り返ればゆっくりしていました。さらに重要なことは，ＩＢＭによる独占支配が安定しており，ＩＢＭは過去の技術との継続性を重視していました。それで，ＩＢＭの提供する技術を習得していれば，着実にレベルを向上させることができました。
そのような状況でしたので，情報システム部門での部員育成のフレームワークは明確でした。習得すべき技術も，ＯＳ（ＪＣＬ）とＣＯＢＯＬの知識があれば，かなりのことができました。データベースやネットワークの技術も，ＯＳやＣＯＢＯＬという幹の枝という位置づけでとらえることができました。システム構築の方法論も，長い汎用コンピュータ時代に確立していました。このように比較的少ないツールを用いて，それを駆使して複雑なシステムを構築することができました。いうなれば外科医的な能力が求められたといえましょう。
このような環境では，実務経験が実力向上に一致します。それで，情報システム部門に配属されると数年間はプログラマとして下流工程の情報技術を習得し，その後，上流工程を担当するＳＥ（システムエンジニア）になり，そのうちに情報システム部門の管理者になるというスキル段階が確立していました。
ユーザ企業内の情報化も，継続的な技術発展を前提とすることができたので，長期的な情報化計画を策定することができました。また，情報化の推進段階でしたので，景気の浮沈による影響はあったものの，情報化業務は安定して成長していました。情報システム部員には，安定した将来が約束されていたのです。
１９８０年代中頃になると，ＳＩＳ（Strategic Information System：戦略的情報システム）が概念が普及しました。情報は第４の経営資源であり，情報技術の活用が競争優位を確立することが認識されるようになりました。
このような状況になると，情報システム部門の任務は，プログラムを書くとかコンピュータの運用をするというようなデータ処理の任務ではなく，情報技術動向を認識して経営戦略に結びつける任務が重視されるようになりました。
それで，情報システム部門を戦略部門として位置づけるようになり，情報システム部員もその任務に必要なスキルが求められるようになりました。従来のようなプログラマや与えられた仕様でシステムを構築するＳＥではなく，経営の観点から情報システムのありかたを考えたり，情報技術を用いて経営革新を図ったりできる能力が求められるようになったのです。
このような能力は，情報システム部門内でＯＳやＣＯＢＯＬだけを習得していたのでは得られません。むしろ，企業の中心となる部門の知識や企業全体を見通す立場にある企画部門の体験などが必要になったのです。このような変化により，以前のスキル体系は崩壊したのです。
このような傾向は，情報技術を軽視するという副作用を生じました。「プログラマあがりをＳＥにするな」，「ＳＥあがりを情報システム部長にするな」となり，「ＩＴガバナンスを情報システム部門から取り上げろ」というようなことにもなったのです。それで「情報システム部門にいるのは出世の妨げ」となり，これまでのエリートコースから転落してしまいました。
そうなると，情報技術者としての育成計画は部員にとって魅力を失います。ここで不幸だったのは，それに替わるべきスキルパスが見出せず，それが現在にまで尾を引いていることです。
１９８０年代末頃から，従来の汎用コンピュータによる集中処理からＣＳＳ（クライアント・サーバシステム）による分散処理へと，情報処理のパラダイムが大きく変化しました。これまでの環境をレガシーシステム，新しい環境をオープンシステムといいます。
レガシーシステムからオープンシステムへの移行に伴い，ＩＢＭ独占体制が崩壊し，これまでの情報技術習得体系も崩壊しました。当時はマイクロソフトの覇権も確立していない戦国時代であり，どこが将来的に発展するのかが不明確でした。それで，自社にどれを導入するのか，何を重点に習得すればよいのかわからなくなってしまったのです。
その後，勝利したマイクロソフトは，ＩＢＭのような過去技術との連続性などは無視していましたし，マニュアル通りに動作するのかの保証もない政策をとり続けてきました。技術習得をする側から見れば，信用できる教科書はなく，実際にやってみて体験的に習得するしか手段がなくなったのです。臨床医学だけが医学になってしまったのです。
そうなると，これまでの育成体系は役に立ちません。情報システム部門に長くいても，オープン環境での経験はありません。しかも，ベテランが現存するレガシーシステムの保守に従事している間に，それができない若者がオープンシステムの開発に従事しました。その結果，在籍期間と実能力の関係が逆転してしまったのです。「ＣＯＢＯＬ技術者はいらない」状況になったのです。
臨床医学的習得では，ベンダＳＥに比べて情報システム部員は経験できる環境が限定されます。それで，以前にまして現実のシステム開発をベンダに頼るようになり，それがさらに部員の経験習得機会を少なくしています。
大規模な基幹業務系システムでは，まず仕様を明確にして，その仕様を正確に実現することが開発者の任務でした。それには外科医的な能力が重要でした。また仕様を満足するシステムが出来上がればプロジェクトが完了しました。
ところがオープン環境では，小規模な部門システムやグループウェアが広く利用されます。それらの構築では，自らプログラムを書くのではなく，市販している多様なソフトウェアとハードウェアをうまく組み合わせることになります。仕様も明確ではなく「情報の共有化を進めたい」というような抽象的な要求ですし，これで完了という状態にはなりません。それで，外科医ではなく内科医（しかも漢方医），大学病院ではなく家庭医としての能力が求められるようになりました。このような育成計画はかなり難しいものになります。
| レガシー環境 | オープン環境 | |
|---|---|---|
| 典型例 | 給与計算 | グループウェア |
| 環境の特徴 | 病理学 原理・原則が通用。体系的学習で能力向上 |
臨床学 かなり暗黙知の世界。実際の体験が重要 |
| システムへの要求 | 最初段階で明確化 | かなりあいまい（「情報の共有化」など） |
| 開発者能力 | 外科医能力 ＯＳやＣＯＢＯＬなどの少数のツールを駆使 して高度なシステムを構築する | 内科医（漢方医）能力 環境に合致した市販のハード・ソフトを 選択して組み合わせる |
| システムの完了 |
仕様を満足したシステムができれば一応完了。 その成果も比較的明確 |
所期の目標があいまいなので実現したか どうか不明。継続的発展 |
| 開発者の位置 | 大学病院 プロジェクト期間だけ利用者と接触すればよい |
開業医（家庭医） 日常的に利用部門と接触する必要。 利用部門自身が行う（ＥＵＣ）ことも |
| 育成体系 | 作成しやすい 形式知で教育可能 |
作成が難しい 個人の体験が重要 |
リストラがタブーどころか経営者の能力とみなされる時代になると，ユーザ企業では情報システム部門の業務はコア・コンピタンスではないので，その業務をアウトソーシングするとともに，情報システム部員も転籍するようになりました。
企業が社員の将来を保証しなくなったのですから，社員が自分で将来を切り開くしかありません。企業がどのような育成計画を策定しても，それが部員個人の計画に合致しなければ，受け入れられないのは当然です。
ベンダのＳＥに負けない情報技術能力が高く，しかも情報分野で成長したいと計画している部員は，むしろそれがチャンスでしょう。そのような部員にとって，外部で通用する技術，しかも高く売れる技術が習得できる機会を切望します。その機会を自社で提供できるとは限りませんし，情報システム部門として必要とするスキルと合致するとも限りません。
情報技術知識が低いか情報分野に興味を持たない部員は，このまま情報システム部門にいて転籍させられるのを待つよりも，機会を見つけて他部門に移るほうが安全でしょう。そのとき，情報システム部門が示す育成計画にのって短期的にせよこの部門での評価を上げるか，むしろそれを無視することにより他部門へ放出されるように仕向けたこうが有利かを考えるでしょう。あるいは，利用部門のキーマン的存在になろうとして，その分野に異常な関心を持つかもしれません。
このように，部員育成計画は従来とは質の異なる問題に直面しているのです。しかも，その解決には身分保証が前提となりますので，不可能といってもよいでしょう。強引に従わせるとすれば，「この育成計画に積極的にのらなければ解雇する」というしかありませんが，裁判でそれが正当な解雇理由として認められるかどうか疑問です。
しかも，現在の情報システム部門は他部門と比較して社内的地位が低いのです。情報システム部門で不適格者との烙印を押された部員を他部門が受け入れるでしょうか？ 育成どころか士気低下を食い止めるほうが問題になる危険すらあるのです。
下のグラフは，ＬＳ研（富士通の先進ユーザ企業団体）が２００３年に行ったアンケート調査です。ユーザ企業が過去３年間に部員に求めてきたスキルと将来３年間に必要となるスキルを示しています。なお，ベンダ企業での結果もこれと大差ありません。
図のＡグループは，これまでも重視されてきたが，将来はさらに重視されるスキルです。特に「情報技術コンサルティング」は重要度が急速に高まるとされています。
Ｂグループは，従来はかなり重視されていたが，将来はそれほど重視されなくなるスキルで，Ｃグループは，過去も将来も比較的重視されないスキルです。いわゆる古典的な情報技術の多くがＢやＣになっていることに注意してください。
この回答企業は先進企業ですので，ＢやＣのスキルは既に十分に持っているから将来は低いのであり，一般企業では「過去３年間」と同様なスキルが要求されるのかもしれません。また，この種のアンケートでは将来の変化を過剰に意識したり「あるべき姿」の理想を追いすぎるので，将来３年後も同様な状況なのかもしれません。
しかし，いずれにせよＡグループのスキルへの要求は高まるでしょう。ところが，これら（セキュリティを除いて）はシステム開発や運用を主任務としてきた従来型の情報システム部門では，経験する機会が少ない分野です。それをどのようにして育成計画に組み込ませるのかが，これからの課題であるといえましょう。
国は以前から情報技術者の育成が重要であると認識して，そのガイドラインを示してきました。その中心になってきたのが国家資格である情報処理技術者試験制度です。その制度も次第にベンダ寄りになってきました。
２００２年にはＩＴＳＳ（ＩＴスキル標準）というフレームワークが公表されました。これがこれからの情報技術者のスキルを評価する共通のものさしになると思われますが，これもユーザ企業の情報システム部員は不利な環境になっています。
情報処理技術者試験は１９６９年に通商産業省（現：経済産業省）による国家試験として開始されました。１９８４に「情報処理の促進に関する法律」に基づき指定試験機関として日本情報処理開発協会情報処理技術者試験センターが設立され，その後２００４年、情報処理推進機構（ＩＰＡ）の情報処理技術者試験センター（ＪＩＴＥＣ）へ移管されました。
当初の１９６９年から１９９４年までの体系は，下左図のようにシンプルなものでした。その後１９９４年に改訂があり，さらに２００１年から現在の体系になりましたが，それは下右図のように複雑なものになっています。当初は単線的であったキャリアパスが，情報技術の発展により専門分野が細分化され，複数のキャリアパスになりました。また，個々のパスが長くなりました。
ここでも未だベンダ企業での情報技術者とユーザ企業の情報システム部員とは同じキャリアパスになっています。一般的にユーザ企業では，特に情報システム部門の規模が小さい場合には，狭い分野に特化してその専門家になることは困難ですから，ベンダ企業にくらべて不利な立場にあります。
ところが，ユーザ企業で昇進するには，システム監査技術者やＩＴコーディネータが求められます（どういうわけか，上級シスアドとＣＩＯとの間に線がないのです）。そして，この両者とも個々の専門技術よりも全般的な情報技術の理解が必要なのに，それを評価するものが存在しないのです。このことも，情報システム部員を不利にしています。実際，ユーザ企業／ベンダ企業にあまり違いがないと思われるシステム監査技術者でも，ベンダ企業の合格者の比率が高いのです。
情報技術者のキャリアパスの複線化に伴い，それらに求められるスキルを整理、体系化したのが「ＩＴスキル標準」です。各種の情報関連サービスの対象職種に分類し，それぞれをさらに複数の専門分野に細分化して、個人の能力や実績に基づいて７段階のレベルを規定しています。マーケティングやセールスなど，情報技術者試験では対象にしていない関連分野にまで広げています。
ＩＴＳＳ策定の目的は，ＩＴ業界がＩＴスキル標準を取り入れることで，効果的に人材育成を推進し，人材不足を解消するとともに，情報技術者個人がキャリアパスを確立できるようにすることにあります。
ＩＰＡのＷｅｂページ（http://www.ipa.go.jp/jinzai/itss/itskill/index.html）より
ＩＴＳＳはベンダ企業を対象にしているはずですが，おそらくユーザ企業の情報システム部員のスキル基準としても利用されるでしょうし，ユーザ企業からベンダ企業に転職するときには，これのどれに相当するかが大きな要素になるでしょう。また，独立することもありましょう。そのとき，情報システム部門での経験は不利になることが懸念されます。
マーケティングやセールスは，あくまでも情報関連製品やサービスのそれであり，自動車販売のマーケティングや新聞のセールスではありません。当然，そのような経験も役立つでしょうが，それには情報システム部門よりも販売部門の経験のほうが役立つでしょう。情報システム部門はこれらの購入側であり，その経験が役立つこともありましょうが，かなり間接的なものでしょう。
顧客がコンサルタントを選択する場合，最も重視するのは（奇妙なことですが）コンサルタントの知識能力よりも自社業界の経験です。多様な業界を経験できるベンダに対して，ユーザ企業では限界があります。また，たまたま同じ業界であったとしても，情報システム部門にいたよりも企画，販売，生産などの部門のほうが買われる傾向があります。情報分野のコンサルティングの場合でも，外部の顧客から見れば，製造業でのＣＩＯよりも有名な情報関連企業の管理職出身のほうが知識経験が高いと思われがちです。
ＩＴアークテクトになるには，個人の能力以外に研究できる環境や機会が不可欠ですが，通常のユーザ企業ではそれに恵まれていないでしょう。また，最近はプロジェクトマネジメントが注目されていますが，そのレベルは従事したことのあるプロジェクトの規模が大きな指標になります。一般企業，特に中堅以下の企業に所属していたのでは，これで高いレベルになることは不可能です。
すなわち，ユーザ企業の情報システム部門に所属して，レベル７に到達するのはかなり困難であるといえましょう。
このように，情報技術者としての資格や標準スキルを得るためにはユーザ企業の情報システム部門はあまり有利だとはいえません。もし，それを期待するのであれば，早期に転職するほうが有利かもしれません（「しれません」というのは，ベンダ企業も多様であり，必ずしも有利だとはいえないからです）。
しかし，企業にとって重要な情報技術は，このような技術だけではありません。むしろ複雑な課題をどのように整理して認識するのか，関係者の多様な価値観をどう統合するのか，状況が変化するプロジェクトをどうマネジメントするのかという周辺の知識経験が求められます。これは，情報システム部門だけでなく，社内のあらゆる部門で必要とするものです。
このような人材は社内で育成することが求められます。情報システム部門は，その業務を通してこのような知識経験を得るのに適した部門です。情報システム部門を人材育成部門，人材供給部門として位置づけることができます。
ダウンサイジングやＥＵＣの発展に伴い，利用部門でも情報技術を持つ人の必要性が高まっていますし，情報システム部門を戦略部門化／アウトソーシングするならば，なおさら必要性が高まります。従来よりもローテーションしやすい環境になったといえましょう。
すなわち，これからの情報システム部員の育成では，情報システム部門にクローズするのではなく，他部門も含めた全社的な観点でのキャリアパスとして考えることが必要なのです。