ＩＴ業務の外部委託と委託者ガバナンス　　　　　　2011.02.01

　ＩＴ関連業務を外部に委託する場合でも、顧客に金融サービスを提供する際の債務履行責任は金融機関にあり、そのサービスの一部である情報システムの適切な開発・運用に関しても管理注意義務がある。また、委託業務に関する財務面からの内部統制も求められる。委託企業にとって、外部企業における開発運用作業や情報システムに対して内部統制を行うことは決して容易くはない。外部委託における発注側のＩＴガバナンスに関して考えてみる。

　情報システムの開発、保守、運用の外部委託が当然の時代となった。中には、ＩＴに係わる全業務を外部専門業者に依存する金融機関もある。委託者にとっては、受託者が高度な技術と広範な経験を有していることから、自社で行うよりも低コスト、高品質であると安心できることは大きな利点である。しかしながら、ＩＴに係わる委託費用は膨大であり、財務面に関する株主等のステークホルダーに対する説明責任と適切な運用を確保・確認することがＪ－ＳＯＸや銀行法等の業法によって求められる。また、受託者が提供する情報システムを利用しながら、顧客に金融サービスを提供する責任を負う立場からすれば、受託者の情報システム（或いは提供サービス、製品）が、自社の提供する金融サービスに必要十分な品質と機能を有しているかを検証、確認することも求められる。情報システムを外部委託している場合でも、その業務内容をブラックボックス化して、自らの債務履行責任を受託者に移転させることはできない。発注者としてのＩＴガバナンスの確立が必要ということである。

　わが国特有のＩＴ取引慣行であるが、発注者は業務要件を受託者に提示し、受託者が提出する成果物を検証するだけで、実際の開発作業は請負契約で受託者に全面依存することが多い。提示する業務要件も、抽象的かつ部分的であることがある。発注者の技術的経験やノウハウが不足することもあり、受託者が技術的仕様に展開できるほど整理された業務要件となっていないことが多い。このことが、業務仕様における両者の認識不一致や受託者における請負プロジェクト採算割れとなることになる。両者の間での問題に止まる場合は、まだ幸いである。業務上の論理エラーをはらんだまま実サービスを開始してしまい、顧客に実損を与えてしまう事態もある。この場合は、一義的に発注者（当該サービス提供者）が顧客に賠償を行い、二義的に発注者と受託者の間で瑕疵担保責任を巡る協議が行われることになる。ただ、金融機関のように多数の顧客に社会インフラとしての金融関連サービスを行う事業者においては、事前の防止に最大限の注意を払う義務があるとされている。業法上での健全な業務運営に違反するとみなされれば、行政処分の対象となることもありえる。例えば、ファイル管理の仕組設計に根本的問題を抱えている為に、似た障害を繰返す金融関連企業がある。プログラムのアルゴリズムの問題であり、請負契約であることを考えれば、この不具合の責任は開発した受託企業にある。しかしながら、顧客も行政もガバナンスの観点から、発注者の債務不履行を責めることになる。例外的な条件が重なった場合にのみ、当該アルゴリズムの不具合が表面化する場合は、テストや検証で事前に発見することは極めて難しい。システム設計や開発されたプログラムの妥当性確認作業において発見すべきミスであり、発注者としては受託者が実効性ある品質管理を適切に実施しているか、監督・管理する必要がある。それがガバナンスである。そもそも、当該技術と経験をもった人材が不足するので外注したのであり、発注者としてはどうすれば良いのか途方にくれることとなるだろう。

　金融庁の検査マニュアルでは、経営陣による統制対象としてＩＴ企画開発体制と管理体制の整備を要求している。担当部署による内部管理の対象としてシステム・ライフ全般に渡るＩＴプロセス管理項目が列挙されているが、外部委託管理に関しても多くのチェック項目を列挙している。しかし、具体的な管理項目や作業項目は明示されていない。これらに関しては金融情報システムセンターの「金融機関等のシステム監査指針」が詳しい。ただし、情報漏洩防止等を意識した指針であるため、開発作業の管理に関しては文書手続き面での整備に主眼が置かれている。その点で、経済産業省の「情報システムの信頼性向上のための取引慣行・契約に関する研究会」報告書が詳しい。

　要件定義において、ユーザー（発注者、委託者）がベンダー（受託者）に提示すべき要件仕様を表す資料として、機能情報関連図、業務流れ図、業務処理定義書、システム機能階層図、概念ＥＲ図、データ項目定義書、システム間関連図、システム間インタフェース定義書、画面・帳票一覧、画面・帳票レイアウトなどが必要だとしている。これらを自社単独で作成できる金融機関は限られる。多くはＩＴベンダーの協力を得て作成することとなろう。しかし、その作業は請負契約ではなく、委託契約となる。最終成果物が事前に具体的に特定できないので、請負契約の対象とならないからである。よって最終成果物である要件定義書一式に関する権利と責任は発注者にある。当該作業中に、協力したベンダー技術者に重大な過失があり、要件定義に大きな瑕疵があったとしても、賠償請求における過失証明は発注者が行わなければならない。それを懸念して全ての作業と打ち合せ内容を記録保存すれば、時間、費用の無駄ばかりでなく、共同作業そのものが阻害される。経験者がいれば、リスクの存在する作業項目を予知特定し、予防策を事前に手当てできるのだが、実質丸投げでは危険極まりない。ＩＴベンダーにおいても世代交代が進み、対象業務の変化や技術革新の激しい今日では、お互いの信頼関係だけでは、問題は解決しない。

　既に全面的な外部依存をしてしまい、こうした技能を持つ社員を失った金融機関は、発注者としてどうすべきか。第一に、要件定義チームを編成できる体制を組成することである。要件定義には、業務知識とその整理記述技法のスキルが必要である。対象となる業務分野は千差万別なので、プロジェクト毎に必要な業務知識保有者を召集することになるが、要件の整理技法および記述手法には汎用性があるので、そのスキルを持つ人々を中心に業務要件定義専門のチームを育成すべきだろう。彼らは業務フローやデータ・ダイヤグラムを読めるので、開発プロジェクトの各局面におけるレビューに参加することで、業務面から見たプログラムとシステムの妥当性を確認することもできる。重要なことは、業務要件定義の段階で、受け入れテストにおいて検証すべき項目も整理し、開発ベンダーに提示しておくことである。これによって、受託者である開発ベンダーは、システム設計、プログラム設計、コーディング等各作業の適切な検証方法を確立しながら、効率的に作業を推進することができる。品質向上だけでなく、開発のスピードアップ、コスト削減にも大きく貢献できるだろう。

　公認会計士協会では、財務諸表の基礎となる取引の承認、実行、計算、集計、記録等の業務を外部委託している会社の財務諸表監査において、当該会社の監査人が業務を受託している会社の当該業務に係わる内部統制のリスクを評価するための実務上の指針を公開している。いわゆる監査基準１８号報告書である。

　監査人は、委託業務の内部統制に関して整備状況報告と整備及び運用状況報告を行うこととされている。前者は、一定時点において受託会社の内部統制が適切に記載され、適切に設計されており、実際に業務に適用されているか否かについて、受託会社の監査人が意見表明する報告書である。後者は、前者に加えて、特定した一定期間の運用状況の有効性について受託会社監査人が意見を表明するものである。委託者である金融機関としては、受託者であるベンダーの監査人から内部統制評価報告書を受け取り、自社の監査人に提示して、自社の内部統制全般の評価を受けることになる。ただし、財務諸表の基礎となる取引の会計処理には、承認、実行、計算、集計、記録というプロセスがあり、その内の集計と記録のみを外部委託しており、承認、実行と会計報告責任を委託者が有している場合は、委託者監査人が、受託者の内部統制体制を理解し、評価する必要がないことがある。要は内部統制の実効性を担保できるか否かによって、委託者内部統制において受託者内部統制の評価を参照すべきかが決定されることになる。委託者である金融機関の担当者は自社監査人に対して、少なくとも以下の情報を正確に伝えることが求められる。

　すなわち、業務委託契約の内容、与える指示や求める報告の程度、受託会社の業務提供能力や財務安定性、ユーザーマニュアルや業処理マニュアル等による委託業務の内容、受託会社の全般統制および業務処理統制、同様の委託を行っている他社業務との同一性や他の会社数、保有している監査可能なデータ等である。他にも、可能であればとの前提付きであるが、受託会社の内部統制報告書や当該業務の内部監査報告書、受託会社が監督官庁に提出する当該業務関連報告書など。一見して複雑多様な報告資料が必要と見えるが、金融機関としては従来から当然のこととして管理しているものばかりである。

　しかし、Ｊ－ＳＯＸ対応として財務面の内部統制ではなく、ＩＴガバナンスとして考えると話は変わってくる。ＩＴガバナンスの評価手法としてはＣＯＢＩＴが代表的なものである。図にあるように４領域、３４のプロセスに関して、０～５までの６段階で評価する。一般的に外部依存が強くなるに従って、計画と組織の領域、及び、モニタリングと評価の領域の成熟度が下がる。このことは、ＩＴの戦略的活用と資源の有効活用が劣化していることを意味する。更に悪化して、開発とインプリメントの領域まで劣化すると、大規模なシステム変更や更改が大きく制限されるようになる。最悪のケースで供給とサポートの領域まで劣化すると利用部門や顧客の離反が始まることになる。

　この事態を防止するにはどうすれば良いだろうか。全面的に外部委託に依存するとしても、企画戦略機能を残せば問題ないとする考えもあるが、それで成功した事例を筆者は知らない。実経験のないスタッフが机上でたてるＩＴ戦略に実現可能性はないからである。また、主要業務を外部委託した場合には、ベンダー交替の機会は、ほぼ永遠になくなる。その為、取引ベンダー以外からの情報入手機会は激減する。戦略立案に必要な情報入手が、極端に制限されてしまうのである。こうして、まずは戦略立案機能から劣化が始まる。

　これへの対策は、自社要員に実戦機会を提供しつつ、情報収集体制を強化することに尽きるだろう。人的資源に制約のある金融機関においては、対象業務と対象技術分野を選択集中せざるをえない。例えば、預金・決済系と汎用機技術は放棄して、資産運用系とデータベース技術、ネットワーク技術に集中するなどである。その選択には、経営戦略と技術戦略の重点分野が明確になっていることが前提である。そして、当該業務と技術分野におけるＩＴガバナンスを、ＣＯＢＩＴ４領域のバランスをとりながら強化すべきである。こうして蓄積した経験、ノウハウ、情報は、外部委託している業務分野におけるＩＴガバナンス強化にも有効に活用できる。

　外部委託をＩＴ展開の中心に据えた場合のガバナンスは、実作業をアウトソーシングしながらも、その作業の適切な体制と運用を確認し、必要な是正処置を講じることができる仕組（人材、規定、組織）により確立できる。決して形式的な会議や報告書で代替できるものではない。

NS