RIETI海外レポートシリーズ 国際金融情報スーパーハイウェイの建設現場から

第五回「投資銀行におけるオフショアリングとアウトソーシングの黎明期(3)」

松本 秀之
コンサルティングフェロー

多種多様なシステムが複雑に絡み合うスパゲッティ型情報システム構造、数多くの複写紙伝票を用いた非効率な事務処理プロセス、これらがもたらすコスト高。投資銀行の事務処理部門が、この状況から脱却する為には、新しい情報システム戦略の計画立案、そして実行が必要です。パソコン環境を活用したユーザー部門によるエンドユーザーコンピューティングと、UNIX環境を活用したIT部門によるシステム開発。情報システムの安定性を高める為には、前者から後者へのシフトが必要です。そこでITプロジェクトを成功へ導く為に、ハイブリッドマネージャーの育成に取り組むケースが現れはじめます。

事務処理部門の格闘

投資銀行の事務処理部門は資金にかかわる決済だけでなく証券にかかわる決済も行う必要がある為、投資銀行のバックオフィスシステムは商業銀行のバックオフィスシステムと比較すると、より複雑なシステム構造になっています(注1)。通常、投資銀行のバックオフィスシステムは、金融取引約定データを作成する第1階層、ポジション管理と資金証券決済を行う第2階層、そしてコーポレートアクションや経理処理、定期報告書作成を行う第3階層から成り立っています(注2)。そして日本で投資銀行ビジネスを行う際、事務部門は金融商品取引法およびその関連規則で定められた数多くの法定帳簿を作成することが必要となります(注3)

さて、1990年から1994年頃まで、投資銀行の事務処理部門の大部分に旧態依然としたペーパーベースの事務処理プロセスが存在し、その中に革新的な情報システムを用いたデジタルベースの事務処理プロセスが局地的に点在している状態になっていました。この事務処理部門の情報システムは、オンライン型やビューロー型といった外部連結型システムと社内開発型システムとが複雑に絡み合い、スパゲッティ型と揶揄されるような情報システム構造になっていました。

大量に発生する金融取引データの処理を行う事務処理現場には、たとえばフロントオフィスが金融取引の内容を記載する注文伝票、事務処理部門が資金証券決済の指示を行う受渡計算書、現物証券の出入れの指示を行う入出庫指示書、現金証拠金の出入や利金配当金の処理を行う経理伝票などの、多種多様の伝票が存在しました。

これらの伝票は、通常、数枚重ねの複写紙。1枚目はオリジナルとして法定帳簿など重要書類の保管を担当する部署が管理し、2枚目は作成部署がオリジナルの複写として保存。3枚目はデータ入力部門に、4枚目は突合作業を担当する部署に、そして5枚目は経理部門に送られるといった、複雑な事務フローが確立されていました。前述の事務処理部門におけるスパゲッティ型情報システム構造の影響を受け、理想とは掛け離れた非効率な事務処理フローが出来上がり、多種多様な情報システムにデータ入力を行う部署と、多種多様な情報システムから出力されるデータの突合作業を行う部署に、多くの人的資源が吸収されることがありました。

事務処理部門の机の周りには何箱ものダンボール。その中に手書きのメモや出力データを印刷した大量の紙が無造作に置かれ、必要なときに再度確認するという光景も珍しくありませんでした。そして、「このような人海戦術的作業からどうにかして脱却したい」という声が、事務処理の現場から高まります。

エンドユーザーコンピューティングの拡大

その解決策の1つとしてパソコンを用いたエンドユーザーコンピューティングという手法が拡大します。1980年代、MS-DOS環境はIBM・東芝・日本電気などの各メーカーによってフォーマットが微妙に異っていた為、別々のフォーマットを変換する互換機なるものが存在しました。1990年、Windows3.0が発表されます。そして1992年、後継バージョンであるWindows3.1が市場に爆発的に広まることで、パソコンの環境はほぼ標準化されます。このWindows環境は、一般ユーザーでも容易にプログラムを作成できるような環境であり、起動ファイルや表計算ソフト、あるいはデーターベースソフトなどに、ユーザー自らがプログラムを書き込むことができます。このユーザーによるプログラム作成という手法を活用して、事務処理自動化の試みが活発に行われました。これがエンドユーザーコンピューティング(EUC)です。

このEUCでは、少数の有能なユーザー兼プログラマーが、ソフトウェアプログラミングから、日常業務における事務処理、データのバックアップ、そしてシステムのバージョンアップに至るまで、広範囲の作業を担当することになります。EUCは劇的な事務処理コスト削減をもたらすことがありましたが、同時にEUCはリスクも孕んでいました。そのリスクには大きく以下の3つがありました。

第1に、EUCはプログラミング能力と事務処理能力の両面で優れている稀少なスタープレーヤー的スタッフが、推進する事になります。その結果、会社組織の内部にはスタープレーヤー過剰依存という図式が生まれます。万が一、このスタープレーヤーが何らかの理由で会社から去ってしまった場合、EUCで作り上げた事務処理プロセスが一時的に滞る可能性があります。

第2に、スタープレーヤーであったとしても、彼らの元来の職務は事務処理である為に、そのスタッフは自分の守備範囲だけをEUC化します。そこで、事務処理プロセスと情報システム構造という、2つの観点からの戦略的なデザインが行われない場合、EUCによって単発的・局地的な自動化だけがもたらされることになります。その結果、スタープレーヤーのいる特定の部署のみ自動化され、その他の部署は手作業のままというような、斑模様のシステム構造となる場合があります。

第3に、投資銀行の事務処理部門の情報システムには必ず中核となるメインフレームシステムが存在します。単発的・局地的に事務処理を自動化したEUCは、メインフレームシステムとの間で、必ずデータのアップロード・ダウンロードというやり取りが必要になります。仮にEUCを操作するプロセスでデータ処理のミスがあった場合、メインフレームシステムに多大な影響を及ぼす事になります。その結果、EUCを用いた事務処理担当者の小さな操作ミスが、組織全体に大きな影響を及ぼすという、それまで経験した事の無い問題に直面することになりました。

ITプロジェクトマネジメントの特徴

他方、1990年代初頭から、オペレーティングシステムSolarisを搭載したサン・マイクロシステムズ社のUNIXサーバーが、爆発的にマーケットシェアを獲得。これに伴いパソコン環境を活用したEUCとは別に、UNIX環境を用いたプロフェッショナルなコンピュータープログラマーによる情報システム開発が、活発に行われるようになりました。

しかし、ユーザー自らプログラミングを行うEUCと比較すると、UNIX環境でのシステム開発は、ユーザー要件を把握する段階で問題がありました。UNIX環境で新しいシステムを開発する際には、当然、ユーザーはシステム開発部門のプログラマーに対して、要件定義を行わなければなりません。事務処理を経験したことのないシステム開発部門のプログラマーが、紙による説明書を基に、事務処理部門のユーザーが欲しているシステムの内容を、正確に理解することは容易なことではありません。

要件定義が適切に行われずユーザーの要望が正確に伝わらなかった場合、開発されたシステムがユーザーの期待外れになる場合があります。また、予定されていたスケジュール通りに、ITプロジェクトが終了しないこともあります。その結果、システム開発コストが当初の計画よりオーバーすることがあります。そこで、システム開発の現場では、ITプロジェクトを進める上で、計画、分析、設計、開発、試験、実施といった幾つかの段階に分けて、それぞれの時点でユーザー側からの確認が行われるウォーターフォール型のITプロジェクトマネジメントメソッドなどの管理手法が導入されます。

ITプロジェクトを行う際に、前述のユーザー要望から乖離した情報システム開発、スケジュールの遅延、そして予算オーバーといったことが、何故、起こるのか。この事に対して、ユニバーシティ・カレッジ・ロンドン(UCL)のピーター・モーリス博士は、道路や橋を建設するといったIT以外のプロジェクトとITプロジェクトとを比較した研究を通して、以下のような興味深い指摘を行っています(注4)

(1) ITの戦略的デザインには多種多様なアイデアがあることから、組織内の意思統一を行う事は困難である。

(2) ITプロジェクトの初期段階である要件定義フェーズにおいて、ユーザー側がIT導入後のビジネスモデルを明確に定義付けしないまま、ITプロジェクトは開始される傾向性がある。

(3) ITプロジェクトを推進する側は主に技術者タイプのスタッフである為、ユーザー側が想定するIT導入後のビジネスモデルを完全に理解することは困難である。

(4) ITプロジェクトの計画段階にIT導入後に将来影響を受けるユーザーを、全て特定する事は困難である。

(5) その結果、ITプロジェクトの計画段階でIT導入後に必要となるキャパシティを正確に算出するのは困難である。

(6) IT関連のハードウエアおよびソフトウエアの市場における価格変動が激しい。

(7) ITの技術革新は日進月歩であり、ITプロジェクトが始まった時点の技術と比較して、そのプロジェクトが終了する時点では、かなり異なった新しい技術が市場に出回っている場合がある。

(8) 市場でメジャーに成り得なかった技術に依存するITを推進してしまった場合、IT導入後に市場でメジャーとなった別の技術に乗り換える必要が出てくる。

(9) このような不確定要素が多く存在する為に、ITプロジェクトの計画段階でITプロジェクトの費用対効果分析を正確に行うことは困難である。

以上のことからピーター・モーリス博士は、「ITプロジェクトを行っている過程で要件定義が継続的に変化し続ける傾向性がある」と指摘しています。このモーリス博士の指摘と同様の現象が、投資銀行の事務処理部門にかかわるシステム開発の現場で頻繁に起きていました。

プロトタイプの活用とハイブリッドマネージャーの育成

スパゲッティ型情報システム構造とペーパーベースの非効率な事務処理プロセスがもたらすコスト高、単発的・局地的に行われるユーザー部門によるEUC、そしてユーザー部門とシステム開発部門との容易ならざる協同作業であるUNIX環境におけるシステム開発。このような問題を抱える事務処理部門の状況を打開する為に、「プロトタイプとしてのEUC活用」という概念に着目したケースがあります。

前出のモーリス博士も指摘しているように、既存のシステムを新しいシステムに置き換えを行うITプロジェクトには、成功例が多いことは広く知られていました。これはシステム開発部門が、既存システムの分析を通してユーザー要望の基礎部分を理解し、また新しく付け加えるべき機能を確認する作業を通してユーザーの要件定義の全体像を把握することができる、ということが成功要因でした。そこで、既存システムが無い新規システム開発の場合は、IT開発に着手する以前に、まずプロトタイプという小型模型の開発を行い、それを活用してシステム開発部門とユーザー部門との間で要件定義を確認する手法が、有効であると考えられています。

そこで、投資銀行のシステム開発の現場では、パソコン環境におけるEUCをUNIX環境におけるシステム開発のプロトタイプと捉え、EUCを行ってきた事務処理部門のスタッフを、システム開発部門と事務処理部門との間でITプロジェクトをコーディネートするマネージャーとして、育成することに取り組むケースが現れはじめます。このカテゴリーの人材を、オックスフォード大学のマイケル・アール博士などは「ハイブリッドマネージャー」と定義付けています(注5)

そこで次回は、ハイブリッドマネージャーについて更に分析を加えると共に、投資銀行が取り組んだグローバル情報システムマネジメントの課題について、ご報告を致します。

2008年1月16日
写真

2008年1月16日掲載

この著者の記事