2007年5月 – 東京 – 2007年問題と言えば「団塊の世代」退職に伴ってノウハウを持った方が職場からいなくなってしまうという意味で使われます。が、ここでは理工系職場の世界が如何にすごいことになっているのか、大学生のデータで示そうと思います。 このコラムをお読みになる方がいかなる年代に属するのかわかりませんので、退屈かもしれませんがまずは基本的な内容から整理していきます。最初に次の図をご覧ください。 18歳人口と高校卒業年別の大学入学志願者数・入学者数・入試倍率 [出所] 文部科学省「学校基本調査」 大学の「みかけの入試倍率」は、年代別に見ると5倍から9倍に至るまで大きく変化しています。入試倍率が上がる理由は4つあります。すなわち、1)複数受験する人が増えた、2)受験人口が増大した、3)入学定員が減少した、4)受験先の人気が高まった、です。 図を見ますと、複数受験が可能であった時期とそうではない時期とでは大きく入試倍率が異なります。例えば中曽根政権下で共通一次試験を改革し併願可能とした1987年がそれです。ただし、複数受験が可能というのは、見かけの入試倍率を押し上げますが本質的な入試倍率を上げることにはなりません。入学辞退者が続出するからです。また入試科目の数などは、確かに受験生にとっては大変かもしれませんが、本質的な難しさとは何ら関係がありません。 そこで、「みかけの入試倍率」ではなく、本当の入試難易度を測るために「潜在入試倍率」というものを定義してみます。潜在入試倍率とは、18歳人口を大学入学者数で割った数値のことで、仮に18歳になった人すべてが大学入学を希望したとすれば大学の入試倍率がいくらになるのかを示すものです。 こうしてみますと、1991年以降どんどん入試が簡単になってきたことがわかります。1990年の約4倍から最近は2倍あたりまで低下するという超楽勝ぶり。そう考えると最初のベビーブーム世代は入試倍率6倍ですから苦労してますね。そして入試倍率と反比例する形で大学生の質が低下したと理解すれば、同じ大学を出てはいても「昔の京大工学部化学科はこんなではなかった」、と仰る退職間際のオジサンの優秀さも理解できるというものです。なお、最初から大学入試に参加しないという意味でのこの間の普通科高校進学率も大学入試に影響を与えてはおりますが、その種の問題は図で示した1970年以降に関する限り軽微です(図が煩雑になるため数字は省略しました)。 ではなぜ1991年以降の入試が全体的に簡単になってきたのか。それは、2)受験人口と、3)入学定員の、両方が関係しています。先に受験人口から見ますと、18歳人口が減少に転じたのは1993年からであり、今では2割方大学入試の競争相手がいなくなった状況にあります。これは大きい。 大学入学定員については次の図をご覧ください。 学部別の大学入学者数 [出所] 文部科学省「学校基本調査」 趨勢的に大学入学定員は増えていますが、特に1985年を境にして各段に増員されたことがわかります。なんと実に2倍です。これら2つの要因が大学入試がやさしくなった理由であり、大学生、ひいては大学卒業生の質低下をもたらしたと考えれば間違ってないと思います。もちろん、教員の質が低下したとか、学習指導要領がいけないとか世間ではいろいろと言われておりますけれども、やはり人口要因は無視できない。いわゆる「分数が出来ない大学生」問題の最大の容疑者はこれでしょう。 さて、今度は学部別に見ていきましょう。 グラフの中で理工系と定義したのは、理学部、工学部、理工学部の合計です。また経済系とは、経済学部、商学部、経営学部の合計です。図が示すのは1997年あたりを境にして、理工系、経済系ともに入学定員が緩やかな減少傾向にあることです。それはなぜかと言えば、特に土木系や農業系のような不人気学科が、「環境…」など接頭辞を付けた洗練された名称に看板替えしたからです。経済系も同じで「経営…」とか「国際…」などが流行しています。 こうした看板替えの流行自体は本題とは関係ありません。ここでは、経済系と理工系の入学定員はほぼ同じであること、そしてどちらにも分類できない学部がどんどん増えたおかげで大学入学定員は1980年代初の2倍近くまで増えたことを覚えておいてください。 次に学部別の大学入試志願者数を見ることにします。 学部別の大学入学志願者数 [出所] 文部科学省「学校基本調査」 1986年を境にして一気に理工系離れが進んだことが明らかです。「でも1991年以降は経済系人気も落ちて最近は理工系離れも元に戻ってるじゃないか」と思われた方、早とちりです。次の図を見てください。 定員割れ学校数の推移(私立大学) [出所] 日本私立学校振興・共済事業団「私立大学・短期大学等入学志願動向」 なんと今や私立大学の4割が定員割れする時代。大学入試自体の容易化が進行したおかげで、1990年代の後半になると「誰でも入学できる」とは言わないにしても全学部で入試倍率の低下傾向がみられるというのが真相。 もちろん上位校は別であろうけれども、母集団全体で見れば学生のクオリティに関わらず難易度の高い学部が消えつつあるというのが実態に近いのです(なおこの何年か医薬系に人気が集まる「医学部シフト」要因があるが、統計上は医薬系ブームも昨年度から沈静化傾向にある模様)。 次の図のように入試倍率に換算してみますと理工系離れはさらに露骨になります。 学部別の大学入試倍率 [出所] 文部科学省「学校基本調査」 1990年代前半の経済系人気がさらによくわかります。逆に言えば、人気の受験漫画”ドラゴン桜”で「東大を目指すならば理Ⅰを狙えば簡単だ」と言っているのは本当だったのです(先日最終回になり主人公の教え子のひとりは東大理Ⅰに見事合格)。 私は1986年に大学を卒業したので当時の状況はよく覚えています。経済系がサークルで遊びまくっている一方で(本当かどうかはともかくとしてそう言われていた)、理工系は授業と実験に勤しまなければならない(これはかなり真実)。会社訪問(私が出た学科の場合は今ほどではないが売り手市場で当時は4年生の春に就活をやりました)で日立の研究所(山奥)に勤める先輩(人工知能を研究中)を訪ねれば「お前ここで年に何人自殺してるか知ってるか」と驚かされ、NECでは「ここで難しいソフトウェアやマイクロプロセッサ作ったって(＝当時NECはVシリーズという名前の米Intel社製互換CPUを独自開発し売っていた)グループ企業の中では評価されないんだ」と愚痴を聞き、「メーカーは男ばかりだから彼女いるなら離すなよ」と妙なアドバイスをされ(府中や三田ばかりでなく日立市でも同じ話になった)、富士通は「電機労連系＝給料低い」しDRAMばかりで(異端な人は相手にされない雰囲気)面白くなさそうで(課長昇進試験のことは当時から有名だった)皆敬遠しているから最初から行かず、日本IBMに行けば「Think」のロゴ(当時のキャッチコピー)入りクリアフォルダをもらえて嬉しかったが六本木も箱崎も所詮営業の会社だとわかってがっかり「行くなら博士とってから大和の基礎研だよね」と学生どうし話し合い(私の学科から就職する人は修士か博士をとって研究職が普通であって学士で卒業するのは少数派)、リコーの中央研究所は「将来なくなってしまうかも」と思って敬遠し(あの放射状の机は当時からあって中央研究所は結局今でも存在している)、ソニーにも多少心が動いたが(一緒にスキーに行ったら開発中のビデオカメラもちろん未発売品をゲレンデに持ってきた先輩がいたほど自由な雰囲気)でも「危ない」と思った。変わったところではヤマハ(昔はパソコンも作っていたしMIDIは当時よりも古い)は就職した先輩も会社も素晴らしかったが浜松は遠すぎ、警察庁(知られざる東大情報科学科卒業生の有力就職先で映画「踊る大捜査線 THE MOVIE 2 レインボーブリッジを封鎖せよ！」に登場する監視モニターシステムC.A.R.A.S.のモデルか)に行った先輩がまぶしく見えたが「所詮は技官」と思い．．．といった状況。これだけ正直者のリクルーター(ネットが普及する以前の理工系の人は一般に正直で小心者だった)が教えてくれれば相当な覚悟がない限りどんなに勧誘されようがメーカーには行きたくなくなる。それで「自分には大学院よりも異分野で経験積んだ方が向いていそうだ」と考えたのが就職活動を始めたきっかけだったと思い直し(私の場合はリクルートG8ビルでのアルバイト＝リクルート社員の方ならわかると思うが館内放送があってバンザイする奴です、が原体験となって学科では珍しい就活マニアになった)、「君、いい加減にして大学院に入りなさい」と言う先生の反対(今では大学院に行った方が良かったのかもと思い直して感謝してますが当時どれほど反対されたか何人の先生から反対されたかご想像ください！)を押し切って銀行や商社を会社訪問してみれば(商社と生保をそれぞれ2社訪問してみたが私が優秀でないせいか拘束されなかった)、体育会系と国家公務員受験者を優遇する雰囲気ありありで嫌だったが(その翌年リクルーターとして真相を知ることになる)、世間知らずなので拘束にあって面倒になりそのまま就職を決めてしまった(このあたりが文系の皆さんと違うところ)。そうしたら文科系の友人から「お前よくあんなきついところにしたな」と言われて(当時は同じようにひどい言われ方をした証券会社が別にあった)、「しまった」と思いシュンとなったものの(もう遅い)、「日立にするくらいならいいや」と自分を納得させた(その頃の私は就活は押さえとし最終的に大学院進学と天秤にかけるという甘い作戦を考えていたから多少不満な先で内定してもあきらめがついた)。それで大学4年生の夏休みに入り大学院の入試勉強も面倒になり、内定先の銀行で時々集まりがあって供される食事が「学生控室の冷蔵庫にある赤札堂(弥生門から徒歩10分)で買った安物ワインプラスチックカップ入りとは大きな違いだなあ」と学士卒業&就職に決めてしまう。．．．回想すればこんな感じでした。当時はバブルに向かって駆け上がろうという時期であり、「マル金、マル貧(ビ)」が流行語になっているくらい拝金志向が強く、「三高」(＝高身長高学歴高収入)と言って女性にもてるかどうかも(これから就職する20代としては重要な要素)収入次第と思われていました。いきおい、理工系卒メーカー入社と言えば同情されていた。逆に理工系で東京電力(彼が手配してくれたおかげでこれだけたくさん会社訪問できたし電中研の話も聞けた)や東京ガス(それで浜松町ものぞいてみました)を選んだ人は自信に満ち溢れて見えました。 もちろん20年後の今から振り返れば、当時は青臭い考え方をしたものだと思うし、多くの予想ははずれています。が、これだけの逆風下で1990年代前半以降に理工系を選んだ方は大したものだと証言できるでしょう。いずれにしても優秀な学生は理工系から経済系に流れた。それも奔流となって。それは銀行が理系大量採用を開始し、共通一次試験が国立大学併願可能に変更された1988年から起きた。一見すれば18歳人口減と大学入学定員増によって隠蔽されてはいるけれど現在もそのトレンドは続いている。 さて、最後の図「大学院修士課程の入学者数」をご覧ください。 大学院修士課程の入学者数 [出所] 文部科学省「学校基本調査」 国の大学院生倍増化計画を受けて、先に見た大学の比ではない変化が大学院に起きた。今や1980年代前半の実に4倍の人員が大学院に流れこみ、院生の質が大幅に劣化しているという事実。逆に言えばかっての修士や博士のクオリティは素晴らしいものだったのかも。 俗にマネーロンダリングにかけて「学歴ロンダリング」という言葉があって、東大に入るのは難しくても東大の大学院に入るのは簡単だから、最終学歴をカッコよくしたければ大学院を目指しなさいという意味で使います。企業の人事部がそんな計略に引っ掛かるはずがなく、まるでワインのビンテージ物のように「君学士を取った大学はどちら？」「学士取得年はいつ？」と聞いては修士や博士をふるいにかけている。そんな現実は報道されないで、やれ「博士課程出身者を企業は評価すべきだ」などという馬鹿な意見が横行しているわけです。 まとめましょう。 国内の同じ大学から定期採用している企業の場合、学生全般の質低下が進んだために若年層の質が近年大きく低下したと考えられる。 この傾向は理工系、そして大学院から定期採用する企業の場合、より強く影響が現われていると思われる。 経済系を中心に採用し、配置転換等で採用人員の目標シフトを誘導できた企業は、上記変化の悪影響を一応回避できている可能性がある。 このコラムは日本の技術系の現在および将来像というテーマでしたが、様々な推論を引き出すことが可能であると思います。例えば「加熱する中学受験って意味あるの」のような推論ですが本題からはずれるのでやめておきます。 以下はもう少し踏み込んだ本筋の仮説です。 […]

2004年5月 – 東京 – 平均的なITエンジニアは世間的な意味での「プロ」ではないという話題です。身に覚えがあると思いますが、難しいシステムプロジェクトはやはりうまくいかないし、大手か中小かを問わずシステムインテグレーターが高度なシステムを納品することはなく、「他社製アプリXと他社製データベースYを簡易言語を使って組み合わせます」となってしまう。 情報化投資に支えられてITサービス業の売上高は1995年以降増加傾向、2002年11月1日現在で実施した調査結果では従業者数は56万9823人(2001年比+0.8%)*1。 経済産業省ITスキル標準(ITSS)による分類方式に照らせば、30才以下のITエンジニアの半数以上が”初心者”に該当する。日本のITエンジニアのうち、コンピュータ・サイエンスやソフトウェア工学に関する教育を受けた人は半数以下(48.6%)である*2。 2004年秋、米マサチューセッツ工科大学(MIT)の電気工学／コンピュータ学科(Department of Electrical Engineering and Computer Science:EECS)に入学する学部生は200名を下回る。昨年の入学者数は約240名、3年前には385名だった*3。 IT業界では、本当に有能な人材はまさに宝石のようなものです。 *1 出所: 経済産業省、”特定サービス産業実態調査実態調査”。 *2 出所: “ITエンジニアのスキル実態”, 日経ITプロフェッショナル 2003年10月号、日経BP社, “第3回ITスキル調査”。この調査は、日本ではエンジニア育成は大学よりも産業界のOJT(on the job training)が中心となって行われている現状や、ITSSの評価方法(経験年数重視)を割り引いて見なければなりません。とはいえ、海外のITエンジニア、あるいは日本でもIT分野以外の技術者の大半が当該分野に関する専門教育を受けていることを考えれば、日本のITエンジニアの現状は際だっています。 *3 出所: CNET Japan, 「コンピュータ科学に背を向ける学生たち」(翻訳記事)。その理由を同記事は、「VoIPやEコマースなどと言われて、コンピュータ科学が、宇宙の歴史を紐解くことより魅力的な学問だと思う人は少ない」、と要約しています。なお日本ではIT教育が出遅れており、情報工学関連の講座数がそもそも少ないためか、ここまで劇的な変化は見られません。ただ、最近の東京大学の進学振り分け(大学2年次に行われる学科選択試験)の動向を見ますと、近年凋落が著しいバイオ系ほどではないにしても、先行きは米国と似たようなものではないでしょうか。

2001年5月31日 – 東京 – システム開発は、予算が大きいほど、スケジュールが長いほど、投入される人員が多いほど難航します。システムの技術的難易度とは関係なく、金融機関において一定規模以上の開発プロジェクトが当初計画通りに終わる確率は50%に到底達しません。終わりのないプロジェクト、通称「死の行進」(death march project)も稀ではありません。各種の統計によれば、この傾向は技術面の先進国(例えば米国)であるか否かに関わらず存在します。もちろん、部分的にはプロジェクト管理やソフトウェア工学の知識により説明可能です。しかし、個別企業の利害が絡む話題、IT業界の影の側面に関する情報が乏しいために、真相を理解するのは容易ではありません。本来お金と時間をかければ良い物が出来上がりそうなのに、皆様も疑問に思われないでしょうか。 大抵の方は、開発資金は発注元である顧客が出す以上、システム開発は顧客主導で進むと理解されておられるのではないでしょうか。図示するならば次のようになるでしょう。なお、図の横軸が知識集約的か労働集約的かを示す軸線、縦軸が顧客との距離感を示しています。ここで言うシステムインテグレーターとは、総合電機メーカーから大手メインフレーマ、外資系コンピュータ会社、独立系、総研系、さらにコンサルティング会社の受託開発部門に到るまでを含めた、ソフトウェア開発会社全般を指しています。図の中には普通、顧客の目からは隠されている下請け構造も示しました。下請け会社としては文字通りの中小ソフトウェア会社のほかに、大手メインフレーマの系列ソフトウェア会社や特約代理店、再受注先に回った大手システムインテグレータ、中国やインドなど海外の開発受託会社を含みます。下請け発注の中には業務委託契約や請負契約ばかりでなく人材派遣会社の利用も含まれます。 理想的な開発形態 残念ながら、現実はこの図とは大きく異なっており、必ずしも顧客主導でことが進むわけではありませんし、お金を出せば相応の対価が得られるわけでもありません。第一に、顧客側のIT部門はいわゆるITのスペシャリストではありません。技術に立ち入った経営判断が下せないことも多いのです。第二に、技術志向のソフトウェアベンダーが不足しています。専門家の絶対数が足りないのです。第三に、システムインテグレーターにとっては過酷な売上高競争があります。他産業対比で見れば成長率の高いIT業界ですが、その実態は建設業界に似たゼネコン、1次発注、2次発注、…と続く連鎖の集合体です。 他に日本の特殊性としては、旧電電ファミリー系企業を対象として政府主導で産業振興した「国策コンピュータ」時代のなごりで、IT産業全般に競争政策が欠けている点を指摘できるでしょう。個々人の能力が鍵を握るソフトウェア開発の特性上、本来であれば活力を失った企業は淘汰され、代わりに技術力のある企業が台頭する新陳代謝が強く働きそうです。しかし日本では、官公需、通信ほかの社会インフラ系需要、企業グループ内の需要といった、排他的で安定的な需要構造が存在するため、技術の優劣による企業の淘汰は働きにくいのが実情です。おかげで大手コンピュータ会社の経営は安定しましたが、その引き換えとして、Intelも、Microsoftも、Oracleも、Sunも、Dellも、Ciscoも、SAPも、そしてその後に続く世代交代を担う新興企業群も生まれませんでした。 米国に例えるならば20年前、もし政府がIBMとAT&Tを強力に保護する政策を行っていたらどうなっていたかを想像してみてください。それが現在の日本です。保護されたマーケットの中で自社製品の販売にこだわっている間に、国外からより優れた製品群が上陸、顧客も次第に離れていったのです。今日、UNIXサーバー、CPUなどのコンピュータの中核部品、OSやデータベースなど基本的なソフトウェア製品、開発ツールのほとんどにおいて日本国内勢は単なる販売代理店の役目にまで後退しています。 日本の大学におけるコンピュータ教育に努力余地があるのも問題です。その上、社会に出てから専門的能力を向上させようにもメインフレーム時代の守旧色が強すぎてインセンティブには欠ける市場環境ですから、ソフトウェア業界おしなべて人材のレベルは高くありません。このため、日本国内でのシステム開発は一般にハイリスクです。 ここまでを頭に入れた上で、典型的な3つの開発形態を見ていきましょう。最初にとりあげるのは「一括開発委託」方式です。 一括開発委託型の開発形態 この「一括開発委託」方式は、金融機関の勘定系システム開発を想像するとわかりやすいでしょう。「第X次オンラインシステム開発」といった名前のプロジェクトが大銀行で始まると、コンピュータ各社は1000億円級の受注を巡って争奪戦を展開、下請け、孫請け、その下まで大騒ぎになります。証券系などある市場系システムも古くはこのようなゼネコン丸投げで開発されました。コンピュータ会社にとってこの種のプロジェクトの旨味の大きさはやや想像を絶しています。 まず、自社だけではなく系列会社からその先まで潤いますし、自社製品があればプロジェクトの中で抱き合わせ販売が可能です。構築したシステムを他の金融機関にも売り捌けば2度おいしいプランにもなります。開発がたとえ難航したとしても、人月単価を基本に金額請求できる業界慣行がありますから、後々顧客に請求する余地はあります。むしろ難航した方が人月単価が膨らんで好都合であるケースさえあるのです。結果、安値受注をしてでも獲得競争に励みますし、利幅の大きな案件の付随案件ともなれば官公需入札で有名になった「1円入札」も起こるのです。事情を理解している発注側もまた、コンピュータ会社の行動を読んで商談を有利にまとめようとします。これは価格競争や縁故ビジネスであって、技術競争ではありません。 さて、特定業者への丸投げで開発するためには、発注者である顧客自身か受注者であるシステムインテグレーターの側に業務と技術に関するノウハウがすべて揃っているとの前提が必要です。ダム建設や道路工事と同じで予め予見できない問題はない、要求仕様、詳細仕様、と順に設計書が出来上がるとしなければ計画も見積もりもできません。ところが、1980年代以降、金融業務のディレギュレーションが進み、金融ハイテクに属する分野や、BIS規制対応のような外部要因が入ってくると、顧客側としても発注仕様を書くのに困る状況が生まれました。一括発注しようにも機能しそうもないので第三者が介入する余地が生じ、コンサルタント会社に仕様決定を任せるケースが出てきました。次の図です。 コンサルタント会社の利用 「コンサルタント会社利用」方式は一時期ブーム化しましたが、本質的な問題解決にはなりませんでした。顧客側にはコンサルタント会社の不得意なテーマまで任せる使い方の問題が、コンサルタント会社側には出来ないことまで高価な報酬を提示して受注するモラルの問題がありました。コンサルタントを使ってもシステム開発に纏わる問題点は先の一括委託委託方式から一向に変化しませんから、ただでさえ巨大なプロジェクトがさらに巨大化して苦しむケースも多かったのです。不運なケースでは、漠然とした仕様を元にしてプロジェクトを開始してしまい、開発が遅れるたびに人員を逐次増やしていった結果、気がつけばプロジェクト管理に追われてプログラムを書くよりもドキュメントを書く人員の方が多かったというケースも珍しくありません。これではたとえ問題を解決できる人材がプロジェクト内にいても、組織が重厚すぎてもはや力を発揮できません。 それでは、成功した金融機関のシステムを買ってきて時間と予算を節約してはどうでしょうか。顧客内部のユーザー部門が中心となって、いくら大会社であっても能力的に疑わしいシステムベンダーよりも、定評のあるパッケージベンダーの製品を選び、最低限の仕様を確保しようと主張したわけです。これは自社内に膨大な雇用を抱えて、系列企業まで食べさせていかねばならない重厚長大なシステムインテグレーターにとっては好ましい傾向ではありません。しかし、人的リソースに限界のある独立系のシステムインテグレーターにとっては歓迎できる方向でした。そこで一部のシステムインテグレーターは、「内部で開発できない物は仕入れよう」との発想へ転換、ゼネコンであるとともに商社機能も果たすようになりました。特注品ではなく汎用品をベースにするBPR系パッケージの発想と同じで、パッケージを買い、不足する部分はシステムインテグレーターが改造しようと言うわけです。この戦略は、他国の市場に販路を拡大しようとする海外ベンダーの戦略にも合致しました。最初は顧客側の希望で始まった「外部パッケージ導入」方式は、すぐにシステムベンダー側からの提案営業に姿を変えていきます。 外部パッケージの導入 「外部パッケージ導入」方式が広まるとともに、システムインテグレーター各社間の力関係も変化していきます。PCやLANの普及も後押しになり、ハードウェアもソフトウェアも特定企業の製品で固めるのが事実上無理になったのです。口先では「オープン系システム」を標榜しながら自社製品で固めるようなシステムインテグレーターには開発を任せたくないと考える顧客も増えて、旧勢力の力が強い勘定系システム開発を除けば独立系システムインテグレーターの勢力が随分と増しました。 ところが「外部パッケージ導入」方式にも問題があります。カスタマイズや日本語化の問題は常について回りますが、特にパッケージ購入が国外から行われた場合、開発元の制御は当然ながら容易ではありません。何よりも当惑させられるのは、開発元が事業から撤退したり、買収・被買収の形で突然に保守打切りを通告してくるケースです。開発元にしてみれば日本の顧客の割合はごく一部ですから「正常な経営上の意思決定」なのですが、日本サイドから見れば大手の金融機関であっても大事にしてくれないわけで当惑してしまいます。そこで間に立ったシステムインテグレーターに開発引継ぎを依頼するわけですが、仲介者にノウハウがないことがわかればもう大変です。不幸なケースでは、英語の意味が読み取れない、あるいはセールストークと仕様説明との区別がつかなかったなどの理由でパッケージが機能を果たしていないことが判明、表向きはパッケージ導入として宣伝されていながら、実際は委託発注方式で日本国内のシステムベンダーが開発したり、あるいは発注側の顧客自身が開発したケースさえあります。 以上、いろいろな開発形態を並べてみましたが、システムの発注側と受注側とは本質的に利益相反するものであり、しかも利益至上主義とモラルのなさではIT業界も金融業界も似たり寄ったりということです。顧客側に判断能力と主導権のないシステム開発プロジェクトは非常に危険です。投資もシステム発注も自己責任原則、相手のモラルに期待して業者丸投げを行うならば結果は目に見えています。また最近、「アウトソーシングビジネス」の名のもとに複数の大手メインフレーマが地方金融機関に対して攻勢をかけておりますが、これも本来の意味でのアウトソーシングと言うよりも、リストラクチャリング下にある金融機関を対象とした中世的なエンクロージャーに似てきています。遠くない将来に反省期を迎えることでしょう。

2001年5月31日 – 東京 – 現在、日本国外のパッケージソフトウェアベンダーにはひと頃の勢いはありません。日本国内のシステムインテグレーターが海外製品に対し販売協力する(業界用語で「担ぐ」と言います)ことも稀になり、海外ベンダーの日本現地法人の経営基盤は全般に不安定、経営者も頻繁に変わります。その表面的な理由は、日本国内の需要が低迷するとともに、海外ベンダーの製品競争力自体も足踏みを続けていることです。 ある意味では、金融テクノロジーの成熟化に伴って、日本国内のベンダーにキャッチアップされてしまったとも言えるでしょう。しかしより本質的には、(1)市場に関する分析の不足、(2)コラム: 「金融機関のシステム開発」で述べた顧客からの信頼性喪失、(3)さらに現地法人のマネジメント、に問題がありそうです。 特に市場分析の問題としては、ほぼ唯一の英字業界誌であるRisk誌が好例です。特殊な専門分野で成功するには、主要な市場参加者、有力な学界関係者、規制当局の動向をフォローアップする努力が不可欠です。しかし、英字メディアから東京市場の有力金融機関、理論家、主要ソフトウェアベンダーの動きを読み取ることは困難です。Risk誌では先ごろも “Japan Risk” と題した特集がありましたが、著名な金融機関からの情報は少なく、日本の動向を伝えると言うよりもむしろ在日企業による全面広告の様相でした。いくら日本特集を組んでもRisk誌の主要な読者はあくまで非日本語圏におりますから、雑誌編集者に読者からのフィードバックを期待しても難しいでしょう。雑誌が広告料を支払ったスポンサー企業を持ち上げるのもまた自然なことです。それでは英字誌の情報の正確性に疑問を持ったとして、日本語情報を求めようとしても、Institutional Investorsを読んで理解可能な日本人と、金融財政事情を読んで理解できる米国人の比率を考えてみれば難易度は明らかです。おかげで安易に市場参入、当然ながら営業不振、高額の東京のオフィスは売上がなければ維持できませんから短期間に撤退、という事例が相次いでいます。 この英語=日本語間の情報フローの非対称性の問題は、日本語メディアと英字メディアの双方を解すことができる我々にとっても決して良いことではありません。端的な例は、英字誌やカンファレンスの広告媒体や資料としての価値が大幅に減じたことです。長年各種の海外セミナーやカンファレンスに参加して参りましたが、1980年代～1990年代中頃であればウォール街からの技術吸収としての参加意義が十分にありました。しかし商業銀行の信用リスク管理のように日本国内の方がむしろ研究事例が豊富な話題では、日本における1～2年前の話題が海外セミナーのテーマになっていたりすることも多く、時々うんざりさせられます。今では海外セミナーに参加する最大の目的は「次に東京市場に入ってくる可能性のあるシステムベンダーはどこか」といった業界動向調査となっています。経費節減の影響が大とはいえ、邦銀からの参加者もほとんどいなくなりました。 目先は不振が目立つと言っても、仮に日本の金融システム市場が1990年代前半並みに回復するような目算が立てば、日本国内のシステム会社の買収などの形で海外資本による本格参入があるかもしれません。これはSUNGARDグループによるInfinity買収のような手堅い市場参入策ですが、必要資金が大きく適当な候補もなくて過去には例がありません。その時々のスポット的な話題を狙って商品を販売する程度であれば単独の日本現地法人を作る方が簡単ですが、この方法は経営を任せうる人材の調達難が相変わらずネックです。この業界でいくら大手と言っても売上高数億円から数十億円の小企業、しかも専門性が高いので経営の難易度も高いわけです。直接レジュメから判断するにせよエグゼクティブサーチを頼むにせよ成功例は多くありません。当面は相変わらず日本のシステムインテグレーターを出先販売機関とし、大幅な販売マージンを落とす形での散発的な日本市場参入が続きそうです。なお、仮に我々自身が海外進出するとしても、直面する問題はおそらく同じです。

2001年5月31日 – 東京 – 金融機関のシステム開発に限らず、最近のシステムプロジェクト案件が難しくなっている背景には、エンジニア全般の人材の質の問題と、システムインテグレーターの会社としてのモラルの問題があります。雑誌の関連記事では、日経コンピュータ 2001年2月12日号 「IT業界のモラルハザード」をご覧になれば状況の一端を知ることができるでしょう。 メインフレームシステム上での大規模開発が主流であった当時は、企画設計に十分な時間を割き、上流工程を担当するコンサルタントやSE(System Engineer)から下流工程を担当するプログラマーからテスターまで、水が流れるように逐次作業を進める開発手法が一般的でした。これがウォーターフォール型開発方式です。新人は大抵下流工程から入り、鍛え上げられて上流工程に移動するというキャリアパスを踏み、相応の教育訓練が行われました。システム開発も何年もかかるのんびりとしたもので、技術の移り変わりも今ほど急速ではありませんでした。開発言語はCOBOL(コボルと読みます)、高度なアルゴリズムを書けない代わりに分業に向いていました。システムインテグレーターの役割とは人員を大量にプールし、育成し、チームで開発することだったのです。顧客への価格提示を人月単位で行う商慣習もこの時生まれました。突出したプログラミング能力があるからといって出世できない代わりに、規格化された大量の労働力が存在した時代です。 状況が一変したのは1980年代末頃から普及したUNIX系のシステム開発が広まって以降です。開発方法論が固まっていない新しいシステム環境では、それまで大量育成された人材の多くが役に立ちません。当然ですが、メインフレーム時代のような経験年数に応じた職階制度が徐々に崩壊、転職は日常茶飯事、UNIXやネットワークに詳しい若手の発言力も増しました。金融業界と同じく肩書きが次第にインフレ化、「プログラマー」、の上が「SE」で、その上が「コンサルタント」になりました。新人でもすぐに「コンサルタント」です。ウォーターフォール型の開発方式が崩壊したことも影響がありました。当時、ウォーターフォール型に代わる開発方式として、プロトタイプを短期間に何度も作成し見直した結果をフィードバックしつつ最終成果物へと向かうスパイラル型開発方式が注目されていました。ウォーターフォール型の開発過程をひとつの開発プロジェクトの中で何度も繰り返すわけです。本来的な意味でスパイラル型が普及していればよかったのですが、日本経済の長期低迷とインターネットブームに重なったのが不運でした。顧客からの開発単価引下げと納期短縮要請を達成するために、企画設計段階とテスト段階から手を抜いた上にソフトウェア部品の組み合わせと外注で納品してしまう、要するに単なる工程省略になってしまいました。表面的にはやさしくなった開発言語の助けもあって、中途半端なシステムが量産されてしまいます。 今やこうしてシステムインテグレーターの役割は、短期化した開発への人材の逐次投入、ほとんど人材派遣業に近い存在になっています。新聞などでよく報じられるように、大手コンピューター会社に加えて、人材派遣会社までが大量採用した人材を短期間で訓練し、開発現場に投入しています。当然ですが本人の適性や教育は二の次であり、大手から中小に到るまでエンジニアが粗製濫造される構造がみられるのです。本来、スパイラル型開発方式が最も力を発揮するのは少人数のよく訓練された専門家チームのはずですが、IT業界にそんな専門家を育てる余裕はありません。コンピュータサイエンスの教育訓練などなくとも、下請け会社ばかりでなく大手でも講習会に行かせれば即「戦力」です。ここ数年ブームであったインターネット関連の強い労働需要も問題です。他産業であれば「未熟練労働者」とみなされる人材であっても、多少社会経験があれば「コンサルタント」の肩書き、そうでなければ「SE」や「エンジニア」の名刺を持たせさえすれば、書類の上では人月単価で計算され顧客に請求書を発行可能な状況が常態化しています。今では、表に立つシステムインテグレーターの看板はほとんどあてにならなくなっています。プロジェクトが混迷した場合でも人事や業務命令は個々のエンジニアとの直接契約ではなく会社間の契約を介して行われますから、人材派遣会社よりも厄介なのかもしれません。特にネットワークやサーバーなど基盤系の担当者に問題があれば、プロジェクト全体が立ち往生してしまいます。 現在、システムインテグレーターへの開発委託を含むプロジェクトに参加する際は、(1)そもそもその会社の正社員か(外資系大手コンピュータ会社に発注したつもりが某宗教団体に仕事が流れた事件に代表されるような2次発注先や3次発注先でないか)、(2)本人に辞めそうな素振りはないか(一般に労働条件の悪い業界なので本人のモラルとともに心の健康に注意が必要)、(3)最後に当人のスキル(研修で濫造された人月単価の単なる埋め合わせ要員ではないか)、をよく吟味してかかる必要があります。