◇システム共同化の現状と課題◇

当論説は、金融財政事情4月21日号への寄稿文に加筆したものです。

近年、急増しているIT共同化に関して、地銀などの共同化事例を想定しながら、銀行経営者が共同化において注意すべき事項を説明しています。特定プロジェクトを前提とはしておりませんが、多くの失敗事例から共通して得られる教訓を列挙しております。金財の記事をご覧になった方々から、全く同感だという感想を数多く頂きました。しかしながら、その方々の中でも、本当に共同化の失敗原因を理解している方は、少ないのが実状であります。このままでは、まだまだ同じ過ちを繰り返す恐れがあります。


共同化の目的と現状

銀行業界では、基幹システムの共同化やアウトソーシング化の事例が増えている。共同化のために、オープン系技術を採用した新規開発を行うことも多い。しかし、新聞報道などに見られるように、新規開発は必ずしも順調には進んでいないようである。

プロジェクト不調の原因として、オープン系技術の未成熟さやベンダーの開発能力低下が指摘されている。また、メガバンクで発生したシステム障害の前例を考慮して慎重を期したとの理由をあげる銀行もある。

多くの金融共同化プロジェクトを垣間見てきた筆者の経験からすれば、共同化の成否は偏にプロジェクト管理或いはその前提の計画段階におけるガバナンスにあると言える。昨今の信金共同や地銀共同に関して、聞き及ぶ情報をプロジェクト・リスクの視点から評価すれば、開始段階から異常なまでに高いリスクが予測できる。技術的問題以前に、ユーザー銀行の戦略的判断とベンダーの営業的判断に無理があり、技術者は被害者とも言える。

稼動を大幅に延期した経営トップが、経営に与える影響は軽微だと説明することもあるが、とすれば大規模投資の目的自体が疑問視される。新システムに期待した機能実現が遅れるばかりでなく、無用な投資が発生する。上場銀行であれば格付けに影響し、株主から批判されることもあろう。ベンダー側では、技術者の責任問題ばかりでなく、大きな営業損失も発生する。ITベンダーによっては、顧客のITガバナンスを評価して、顧客を逆選別することもある。売上よりも利益率を重視すれば、当然の対応である。

 

ITガバナンスの考え方

ITガバナンスといってもその範囲・定義に確立したものはない。単純化すれば、IT関連の戦略、ユーザー業務との連携、システムインフラ、開発対象業務、プロジェクト計画、品質要求水準などに関する判断基準と意思決定の仕組みと言えるだろう。

共同化の多くは、自行ITに対する経営の不満と不安から決定されている。コストが高い、要員を確保・維持できない、新規対応が遅すぎるなどの不満である。一方、ますます増大が予想される開発案件に対応できるかという不安も強い。勘定系オンラインは、どの銀行も同じ機能なので、戦略的ではないとする考えがある。その結果、ITへの不満と不安の解決策として共同化が最適解に見えるようである。勘定系オンラインに差別化要素がなかったのは規制下にあったからである。収益の大半を供給する業務が戦略的でないとすれば、銀行としての存続理由は何であろうか。情報系は戦略を支援するが、戦略そのものではないと考えられる。商品やプロセシング能力を具現化するITこそが差別化要素であり、それを共同化することは、営業戦略やサービス戦略も共通化する必要がある。

勘定系の機能は同じとの前提に立てば、業務範囲の決定や業務設計を外部に全面委任するという選択肢が出てくる。システムは、その企業の業務手順そのものであり、組織文化でもある。購入してスイッチを入れれば作動する機械とは異なることに留意すべきであろう。

オープン系技術による基幹システム

オープン系技術を採用すれば、開発費用は数分の一、開発期間も数分の一という売り文句が散見される。対象業務によっては、そのような場合もあるが、複雑な取引管理や大量の処理を必要とされる業務においては、オープン系にも制約はある。危険なことは、現在のITが抱える問題の原因が汎用機技術にあり、その対極のオープン系技術を採用すれば、ITに対する不満と不安が解決できると短絡化することである。わかり易い論法かもしれないが、銀行システムはそれほど単純ではない。ある取引が、システム内部で複数の別取引を派生し、それぞれが整合性をもって終了して始めて取引が完了する。処理中に何らかの異常があれば、関連する処理を全て凍結或いは取り消して再処理する。異常の原因を特定し、再発防止を行なうための検証機能も銀行オンラインに不可欠な機能である。オープン系には、こうした複雑な取引管理や大量のバッチ処理、異常時の検証方法などにまだ制約が多い。汎用機とオープン系は二者択一の技術ではなく、それぞれに適した使い方がある。

念のために申し添えれば、オープン系だと開発費用が数分の一になることは、常識的にありえない。端末機を除くホスト導入費用の70%以上は開発費である。サーバーがUnixといえども、昨今ではメインフレーム機と価格面で大差ない。開発費に占める業務分析、設計、プログラム開発、テストのコスト構成は、各々25%、25%、30%、20%と考えてよいだろう。オープン系だから効率的になると言えるのは、設計の一部とコーデイングである。テストは、むしろ負荷増かもしれない。30%以上の開発効率を期待できる根拠は発見できない。保守段階での労力増を考えるとTCOとしては、メインフレームの方が優位ということも考えられる。ライフ全体を考えて、適用業務と運用手順を設計し、業務適性に応じた開発技法とテクニカル・インフラを選定すべきである。

パッケージ・ソリューションの限界

銀行オンライン新規開発の費用と時間を節約するツールとして、パッケージは古くて新しい問題を抱えている。

第一に、誰が業務設計するのかという問題である。銀行経営者は、ベンダーの製品であるから全てはベンダーが実施し、それを自行用に若干の仕様変更をすれば済む筈と考える。ところが銀行業務を本業としないベンダーが業務設計することには相当の無理がある。ベンダーによっては、元銀行員の技術者によって経験と実績を誇示するが、全ての銀行業務に精通していることはありえない。

第二に仕様変更から発生する問題である。画面や帳票を多少変更する程度であればまだしも、コード体系やファイル体系を変えるとなれば大幅な変更となる。窓口端末が違えば、業務手順そのものを変える必要がある。元のプログラムの30%以上を変更するのであれば、新規開発した方が早くて(低コストと同義)安全なことは、技術者の常識である。

第三にパッケージの実績である。基盤ソフトやミドルウエアと違って、業務パッケージはカストマイズされることが多い。製品名は同じでも、ユーザーによって内容は全く異なる。設計書を参照モデルとして利用できるメリットはあるが、ベンダー労力としては、都度開発と大差ない。パッケージを採用しても費用が大幅に下がる保証はないのである。

パッケージを利用するのであれば、仕様変更を行なうべきでない。組織権限体制を含めた業務手順をパッケージに合わせるべきである。その手順書を顧客に提示できない場合は、製品が未完成であることを意味する。未完成製品をもって、戦略的判断を行なう危険性は経営陣が責任を負うべきである。

40年以上前に三井銀行が我が国で始めて稼動させた普通預金オンラインは、アセンブラーで数千ステップだった。それが、会計処理ルールに大きな変更がないにも関わらず、今日では、信金でも10万ステップを超えている。大手銀行に至っては、複雑なバッチ連携を加えると百万ステップを越えているそうである。他アプリケーションとの連動処理が増えたこともあるが、事務規定の複雑化とチェックアンドバランスのロジック追加が規模拡大の原因である。銀行の勘定系処理を単純に会計処理ととらえると大きな過ちを犯すことになる。まさしく、各銀行の歴史・経験・学習の集積なのである。システムは企業文化そのものだという理由である。

プロジェクト体制とコンサルタント

数十人月程度の小規模開発ならば、桶狭間方式でまず着手してしまう方法も採りうる。しかし、数百人月以上となれば、開発規模に応じてリスクは急激に高まり、一人当り開発生産性も級数的に劣化する。プロジェクトの目標、全体構成、開発手順、役割分担、管理方法、品質水準などを事前に定めて、参加者全員が共有化する必要がある。ベンダーの数が増えれば、その必要性はますます高まる。

設計段階で機能や品質を明確に定めておかなくてはならない。後工程での変更が殆どないほどまで、変数を減らしていく作業が重要である。誰が、どのような基準で判断して決定するかという問題と同義である。ユーザー銀行がこの責務を放棄すれば、そのプロジェクトの結果は悲惨なことになる。丸投げの危険性はここにある。

最近は、SI(システム・インテグレーション)ベンダーに、プロジェクト管理を含めて全面的に開発委託を行なうことが一般的である。その場合でも、業務設計の仕様確定はユーザーが行なうべきである。ベンダーにそのような業務知識を期待することが無理なことは前述した。

コンストラクション・マネジメントとして、設計やプロジェクト管理をコンサルタントに委託し、開発作業はSIベンダーに依頼する事例も増えつつある。有効なケースもあるが、コンサルタントと開発ベンダーそしてユーザー間の役割と責任分担が曖昧になることが多い。また、日本では、就業慣行から特定分野に特化熟達した人材が少なく、米国のように専門知識を持ったコンサルタントは数少ないことに留意すべきである。

本来、コンサルタントは実作業を行なわず、クライアントに助言することを役割としている。その方が、客観的で中立的な助言が可能だとの考えである。しかし、クライアントに望まれて開発作業も行なうことが増えている。その場合は、期待する役割と成果物については、事前に明確化しておくべきである。安直・曖昧な期待のみで、プロジェクトに参画させると混乱を引き起こすことが多い。プロジェクト参加全社の明確な役割分担と良好な協業体制が不可欠である。

プロジェクト管理(PM

昨今、PMの重要性が経営層から注目されている。裏返すと、これまで余り重視されていなかったことになる。本稿ではPMそのものに触れないが、プロジェクト不調の場合の対応策について若干コメントしてみる。

従来のプロジェクトは、付与の業務要件をシステムに実装するために、予算と時間を管理してきた。即ち作業の進捗管理を行なえば、大半は済んだといえる。ところがマルチユーザー(共同だけでなく、合併時も同様)、マルチ・ベンダーとなると、PMは著しく困難となる。進捗が不調になると、プロジェクト・マネジャーの責任が問われ、交代が行なわれることが多い。マネジャーの資質や技能に起因する場合もあるが、多くはプロジェクト計画自体や体制の不備に起因する。マネジャーの更迭で解決することは稀有である。

設計から開発への移行段階で問題が発生することも多い。これは、要件確定が出来ていないか不適切なことによる。業務ニーズを提示すべき利用部門の能力不足(業務知識や整理の手法)か、それを業務設計書に展開するエンジニアの技能不足が原因である。この問題が広い範囲で見られる場合は、システム化の目標設定や設計技法に致命的欠陥があることが多い。中断して、計画を再作成することが無難であろう。

開発局面において問題が頻発する場合もある。多くの場合は、要件仕様の変更による手戻りが原因である。安易な要件定義が主因であるが、基盤に使用予定の技術や製品の機能不足に起因することもある。打開策として、開発要員の大幅増強が行われることが多い。管理不能なまでの多人数を投入して、とりあえず稼動させるのである。結果は、システムの整合性を傷つけ、後日の保守、安定稼動、他システムとの連携などに多くの問題を残し、システムの寿命を縮めることになる。

金融庁の検査マニュアルでもシステム監査の有用性が唱えられている。経験的にいえば、開発段階に入ってから監査をしても、問題点を追加発見するのみでプロジェクトの建て直しにはならない。欠陥の多くは、計画段階、設計段階で内包されている。開発段階となっては手遅れのことが多い。外部チェックはプロジェクト初期段階に行ない、品質要件と作業手順を明確化、徹底させておくべきである。

ベンダー・マネジメント

マルチ・ベンダー方式をベンダー間の牽制手段や値引き圧力として使うことは推奨できない。前向きな協業体制ができないからである。特にソフト開発は、技術者の技能と経験を購入することであり、技術者の意欲を削ぐ施策は回避すべきである。ユーザー銀行が目指すビジョンに満ちた新システムを各ベンダーが得意技能を持ち寄って共同構築することが、技術者を意欲付け、その技能を活用できる。

ベンダーによって、作業方法や使用ツールなどが異なるので、その一元管理には難しいものがある。プロジェクト管理やベンダー管理に熟達した経験者が、ユーザー側責任者をサポートするためのプロジェクト管理支援チームを組成することも有効であろう。このチームはあくまでも、ユーザー側責任者の為に活動する。決して開発作業を委託したり、特定ベンダーとの提携先を選定してはならない。

昨今のIT不況とオフショア開発の増加という環境変化を受けて、ユーザー銀行のベンダー・コストに対する圧力は厳しさを増している。金融向け料金の適正化という面からすれば好ましい動きであるが、単純な人月単価の引き下げであれば、その反動は顧客側に戻ってくることに注意すべきであろう。ベンダーとの関係は、戦略的パートナーであるべきだ。ベンダーも、売上が立てば良いという姿勢を改め、パートナーとして顧客に対するビジネス・ソリューションを提案・実装しなくてはならない。コスト削減という顧客のビジネス・ニーズに対して、単純にオープン系・パッケージ・共同化を組み合わせて提案するのでは、論理に飛躍がありすぎる。

共同化成功のポイント

通常のプロジェクトと共同化プロジェクトの違いは、業務要件設計の難しさと意思決定構造の複雑さにある。共同化の目的と範囲を明確にし、プロジェクト推進の手順、判断項目と基準、作業項目抽出と役割分担を明確にすることが第一である。意思決定の仕組みを事前に決めておくことも不可欠である。つまり、社内プロジェクトより数段詳細なプロジェクト計画を作成し、参加全社が合意、共有化する必要がある。曖昧な期待は、単に無秩序を生むだけである。各社は自社のプロジェクト参加メンバーに出来る限りの権限委譲を行なう。持ち帰り判断が必要な場合は、経営トップみずから参画して早急に結論を出すべきである。ボトムアップの検討を各社毎に行なっていては、プロジェクト運営は不可能である。共同化を単なるコスト節減策ととらえて、経営者から丸投げされても担当者は対応できない。

新勘定系オンラインに対するビジネス・ニーズ

共同化する場合に、特定行のシステムに片寄せすることが最も安全でコストも安いことは自明である。現時点で、新システム開発を促すほどの経営環境変化はない。しかし、新規開発する事例が続いている。既存システムに技術的な寿命が迫っているのだろう。共同化で年間ITコストを20〜30%節約できても、新システムの開発・移行コストを回収するには数年を要するだろう。

現在の不良債権問題と景気低迷という問題が解決すれば、金融ビジネスの変革は大きく進展する筈である。業界は垂直構造から水平構造化して分業化、専門化するだろう。新商品も高度で多様なものが続出する。顧客へのデリバリー・チャネルが多様化すれば、価格設定の方法や提供サービスも変革される。恐らく、メガバンクといえども単独で総合金融化のIT対応は困難になる。

業界共通のビジネス・プロトコル(番号体系や各種書式など)が標準化され、他の金融機関やベンダーのソフトやシステムを取捨選択して利用するようになる可能性が高い。その時の技術的インフラは、オープン系技術程度の変革ではすまない。IT能力の高い銀行と、低い銀行の戦略的選択肢と経営格差は明確に二極化することになる。

共同化そのものを否定する理由はない。それが、現行ITに対する不満と不安からの逃避ではなく、経営力強化のビジョンに根ざしたものであり、時間軸との整合性に配慮されている必要がある。また、共同化やアウトソーシングを戦略的に活用する為には、高度なITガバナンスを持つことが不可欠というジレンマを解決する必要もある。


→ 調査レポート Backnumber