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)最後に当人のスキル(研修で濫造された人月単価の単なる埋め合わせ要員ではないか)、をよく吟味してかかる必要があります。