金融機関のシステム開発

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業界も金融業界も似たり寄ったりということです。顧客側に判断能力と主導権のないシステム開発プロジェクトは非常に危険です。投資もシステム発注も自己責任原則、相手のモラルに期待して業者丸投げを行うならば結果は目に見えています。また最近、「アウトソーシングビジネス」の名のもとに複数の大手メインフレーマが地方金融機関に対して攻勢をかけておりますが、これも本来の意味でのアウトソーシングと言うよりも、リストラクチャリング下にある金融機関を対象とした中世的なエンクロージャーに似てきています。遠くない将来に反省期を迎えることでしょう。