金融機関のシステム環境の変化とリスク管理の課題
２０１０年１０月
プロモントリー・フィナンシャル・ジャパン
江見 明弘

本日の説明内容
１．金融機関システムを巡る最近の環境変化（１）システム技術の進化（２）システム外部委託の進展
2. システムリスク管理上の留意事項（１）経営陣の役割（２）リスクベース・アプローチ
3. IT人材の育成
2

１．金融機関システムを巡る最近の環境変化
システム技術の進化

人的資源・コスト面の制約

金融機関システム
品質面

外部委託先依存度の高まり
リスク管理面

高い要求レベル顧客

監督当局
3

（１）システム技術の進化①オープン系システム技術の進化▼オープン系システムの採用拡大（出所：日本銀行金融高度化セミナー「システムリスク管理の現状と課題」（２００７．３））
4

▼オープン系システムのリスク認識と対策
リスク認識

対策

ハードウェア－ メインフレームに比べ，機器単体では故障しやすい。

・ 機器の冗長化による可用性向上。

ソフトウェア－ 多種多様なソフトが組み合わさってシステムを構成しており，相性問題が起こりやすい。
－ ＯＳの障害局所化機能，高付加制御機能等が弱い。
－ ウィルスに感染する。
－ 仕様が公開されているため，ソフトの脆弱性を突いた外部攻撃を受けやすい。

・ 入念な事前テストの実施（ｅｘ．パラレルラン・テスト）。
・ メインフレーム系ＯＳ比劣後している機能を強化するためのミドルウェアの導入。
・ ウィルス対策の実施。
・ ソフトの脆弱性対策の実施（ｅｘ．ＷＥＢアプリの脆弱性対策）。

要素技術・ベンダー－ 要素技術が分散しているため，様々なスキル・ノウハウが必要。
－ ベンダーが複数に跨るため，障害時対応が難しい。

・サーバの集中管理。
・基盤を一元管理する部署の設置と強化。
・バグ・セキュリティホールの情報収集，パッチ適用の一元管理。
・取り纏めベンダーの指定。
5

②インターネットバンキングの普及と犯罪手口の高度化

インターネットバンキングサービスを提供する金融機関の割合－ ＦＩＳＣ「金融機関のシステム化アンケート」（２００９．３）
・ 事象者向け・・・・・８２．４％
・ 個人向け ・・・・・８８．４％

個人インターネットバンキングの利用状況（１／２）（出所：楽天リサーチ「インターネットバンキングに関する調査」（２００９．１０））6



個人インターネットバンキングの利用状況（１／２）（出所：楽天リサーチ「インターネットバンキングに関する調査」（２００９．１０））7 インターネットバンキングを利用した犯罪状況▼ 日本での偽造キャッシュカードとインターネットバンキングによる被害発生状況
時期

偽造キャッシュカード

15年度

16年度

17年度

18年度

19年度

20年度

件数

（件）

106

468

913

638

703

398

被害額

（百万円）

331

1,063

980

576

435

267

平均被害額

（万円）

312

227

107

90

61

67

件数

（件）

149102

233

127

（百万円）

0105

129

191

131

インターネットバンキング 被害額

平均被害額
（万円）
0
214
127
81
103
（注１） 各犯罪類型による被害発生の取りまとめ期間は以下のとおりであり、平成21年4月15日までに金融庁及び財務局に報告されたものを集計している。
■偽造キャッシュカード犯罪：平成12年4月から平成21年3月■インターネットバンキング犯罪：平成17年2月から平成21年3月（出所）金融庁「偽造キャッシュカード等による被害発生等の状況について」をもとに、FISCにて作成▼ （参考）英国でのインターネットバンキングによる被害発生状況（出所：ＡＰＡＣＳ：銀行共同支払決済機構）

8 インターネットバンキングを利用した犯罪手口の高度化（１／２）▼ トロイの木馬（出所：ＲＳＡ）
9 インターネットバンキングを利用した犯罪手口の高度化（２／２）▼ Man-in-the-Browser (MITB)攻撃（出所：ＲＳＡ）
10

インターネットバンキングにおけるシステムリスク管理の守備範囲？

２要素認証

Ｆ／Ｗ

ＳＳＬ通信

ＯＴＰ

ＩＤＳ／ＩＰＳ11

③システムの仮想化技術の進化とクラウドコンピューティング

システム仮想化「一つの物理的サーバを、複数の論理的サーバに分割し、各々でシステムを稼動させることができるようにすること」（メリット）
・ サーバ台数の削減
・ 保守・運用負担の軽減
・ サーバの稼働率アップ

クラウドコンピューティング「クラウド・コンピューティングとは、貯蔵／共有化された電算処理資源（ネットワーク、サーバ、ストレージ、サービス）を、ネットワークを介し必要に応じて利用可能とするモデル」（米国国立標準技術研究所の定義）（特性）・ オンデマンド／セルフサービス－ ベンダーの人手を介することなく、自動化された形態でサービス利用が可能
・ ネットワークを介した利用－ どこからでもサービス利用が可能
・ リソースの集中貯蔵－ リソースの保管場所、保管形態を知ることなく、サービス利用が可能
・ 迅速なリソース確保／開放－ 利用サービス資源の迅速なスケールアウト／インが可能
・ 計測可能なサービス
12－ サービス利用の課金の透明性確保が可能▼ クラウドコンピューティングのタイプ（出所：FB&T)

13 クラウドコンピューティングのメリット

クラウドコンピューティングの利用により、システム資源の安定性確保や規模拡張に頭を悩ませることなく（コスト負担を含め）、本来のコア業務に専念できる。
・ コスト削減－ システムの規模拡大に伴うコスト負担－ 不稼動資源に対するコスト負担
・ 迅速性－ システム資源のスピーディーな提供－ システム開発のスピードアップ

14 クラウドコンピューティングのリスク－ 殆どのリスクは、従来システムと共通ないしその延長線上のもの。
・ 情報セキュリティのリスク－ サービス提供者のリスク対策が不十分なため、情報漏洩が発生するリスク
・ システム復旧のリスク－ サービス提供者のリスク対策が不十分なため、障害時や災害発生時のシステム復旧が遅延するリスク
・ データ取得・復旧のリスク－ データの所在が不明確であることに伴う、当局要請時やシステム障害時等におけるデータ取得・復旧の遅延リスク
・ リーガルリスク－ システム・データが海外に所在することに伴い、外国の法規制を受けることになるリスク

サービス提供者のリスク対策の明確化・可視化（ＳＬＡの締結、立入調査権の確保、外部監査結果の入手など）
15

（２）システム外部委託の進展

システム技術の高度化・多様化

外部委託先依存度の高まり
システム関連コストの圧縮要請

16

▼ 外部委託の進展がＩＴ統制に与える影響

委託形態の変化・個別委託から共同委託へ
・委託から利用へ委託元としての管理意識の低下
・委託先との接触機会の減尐
・ｎ分の１であるとの意識
・利用者（障害発生時は被害者）意識

プロパー要員のシステムスキル低下
・スキル育成環境・機会の減尐

ＩＴ統制の弱体化
17▼ 地域銀行における勘定系システム共同化の進展（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））
18

▼ 主要な勘定系システム共同化（２００９/12月時点）
ベンダー
利用（予定）先数 システム基盤 実現方式(注） AP提供者
BeSTA
NTTデータ９（６）ﾒｲﾝﾌﾚｰﾑ
④
ベンダー
MEJAR
NTTデータ０（３）ﾒｲﾝﾌﾚｰﾑ④
ベンダー
じゅうだん会
日本IBM
６（１）ﾒｲﾝﾌﾚｰﾑ①or③
銀行
CHANCE PROJECT 日本IBM
４（２）ﾒｲﾝﾌﾚｰﾑ③
銀行
TSUBASAﾌﾟﾛｼﾞｪｸﾄ 日本IBM
０（５）
n.a.
n.a.
ベンダー
Bank Vision
日本ユニシス２（６）Windows②
ベンダー
NEXT BASE
日立
５（４）ﾒｲﾝﾌﾚｰﾑ④
ベンダー
STELLA CUBE
NTTデータ０（８）ﾒｲﾝﾌﾚｰﾑ④
ベンダー
STAR－ACE
NTTデータ６（０）ﾒｲﾝﾌﾚｰﾑ④
ベンダー
PROBANK
富士通
４（０）ﾒｲﾝﾌﾚｰﾑ①or②
ベンダー
NEXT SCOPE
日立３（０）ﾒｲﾝﾌﾚｰﾑ②
ベンダー（注）①センターが別々、②同一センター内でホストコンピュータが別々、③ホストコンピュータを論理分割、④業務APロジックで分割（マルチバンク方式）

19▼ 勘定系システム共同化の周辺業務取り込み状況（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））⇒ 今後、勘定系ｼｽﾃﾑから周辺系ｼｽﾃﾑへと共同化範囲が拡がる見通し20▼ システム共同化のメリット・デメリット（メリット）
・ システム経費の削減
・ 自行システム要員の圧縮
・ 機能強化、サービスの充実

・ システムの信頼性・可用性・機密性の向上
・ システムの業務継続機能の向上（デメリット）・ システム仕様の柔軟性の低下
・ 開発スピードの低下
・ システムスキル・ノウハウの低下
・ 委託先管理の実効性低下
・ 次期システム検討の遅れ
21

▼システム共同化先のシステム経費の削減、自行システム要員の圧縮▽ システム共同化に伴うシステム経費の削減効果
010

20

3040

▽システム共同化に伴う自行システム要員の圧縮（単位：％）（単位：％）
5060

050％以上削減

250％以上圧縮

30～50％削減

430～50％圧縮
53

5～30％削減15

ほぼ同等（±5％）18

増加（5％以上）不明

5

10 15 20 25 30 35 40

3335
22

5～30％圧縮5

ほぼ同等（±5％）増加（5％以上） 09
不明55＞＜集計対象金融機関数：※ 勘定系システム以外も含む、年間総システム経費比較

555＞＜集計対象金融機関数：※ 勘定系システム以外も含む、自行システム要員数の比較（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））
22▼ システム共同化先の機能強化、サービスの充実▽ システム共同化に伴い、機能・サービスが強化・充実された点（複数回答）（単位：％）
0

10 20 30 40 50 60 70 80 90 100

64

365日連続稼働

58

チャネル拡充58

オフサイトバックアップシステム

53

24時間連続稼働
36

商品ラインナップの拡充
23

データウェアハウス
15

CRM※

その他

4

特になし

453＞
＜集計対象金融機関数：※Customer Relationship Managementの略。詳細な顧客情報データベースを基に、企業が顧客との関係性をマネジメントする方法（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））23▼システム共同化先のシステム可用性の向上▽ システム共同化に伴う顧客影響障害の発生件数の変化
01020（単位：％）40503040減尐
35

不変
増加

不明

1115
＜集計対象金融機関数：▽システム共同化に伴う障害発生後の復旧時間の変化

55 ＞※ システム共同化直後の初期障害を除く

01020（単位：％）405030

44

短縮
33

不変
長期化

13

不明

1155＞
＜集計対象金融機関数：（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））24▼システム共同化先におけるシステム仕様の柔軟性の低下▽ 自行独自のカスタマイズ（プログラム変更）の自由度
010

2030（単位：％）40 50 6053

費用負担すれば原則自由▽ 共同システムの独自カスタマイズ率
021

１～３割

他共同化先の同意が必要

19

３～５割

その他

62

＜集計対象金融機関数：53＞

2030

40

5060

（単位：％）
70 80

68

１割未満

他共同化先の同意は不要であるが、抑制的に運用されている原則不可（他共同化先から共通仕様として受入れられる必要）

10

19
11

５割以上

0不明

2
＜集計対象金融機関数： 53 ＞

※ 自行独自仕様のプログラムステップ数／全プログラムステップ数（または、自行独自仕様の機能数／全機能数）（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））25

▼システム共同化先における開発スピードの変化▽ システム共同化に伴う開発案件提案から稼働開始までのスピード感の変化
0

10

20

3040

（単位：％）
50 60▽ リーダー行の有無と開発スピードの変化との関係

遅くなった

33%
66％

遅くなった

57

変わらず

速くなった

変わらず

27%

速くなった

40%

26
26%

178%

＜集計対象金融機関数：53＞

リーダー行有り
リーダー行無し＜集計対象金融機関数：15＞ ＜集計対象金融機関数：38＞（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））26

▼システム共同化先におけるシステムスキル・ノウハウの変化▽ システム共同化に伴う自行職員のスキル変化
共同化先
01020

委託先管理スキル※30

40506070

システムプロジェクト管理スキル

24

36

45

システム品質管理スキル

2951

要件定義スキル24

64

システム資源・性能管理スキル
システム設計スキル

70（単位：％）
80 90 10016

うち、リーダー行
0

10

20

30

6

40

50

60

70

（単位：％）
80

80

90

100

20

01867

33

02067

33

067

33

01345

38

758

35

1767

17向上

不変

低下

向上

不変

低下

＜集計対象金融機関数：55、※は54＞

33

67

0

＜集計対象金融機関数：6、※は5＞（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））27

▼システム共同化先における委託先管理実施状況▽ 共同化先が実施している委託先管理手段（複数回答）（単位：％）
020

406080▽ 共同化先が実施している品質管理手法（複数回答）（単位：％）
0100

20406080

100

定期的に委託先が実施した外部・内部監査結果を入手

81

ユーザー受入テストの実施

91

定期的に立入検査して検証

80

設計書の検証（レビュー）89

委託先が実施するテスト結果のユーザー検証87

定期的に委託先の自主点検結果を入手

70

定期的に外部監査を依頼
その他

59
4

特に検証していない 0

委託先からの品質管理レポートの入手
その他

75
8

特に実施していない（委託先に一任） 0＜集計対象金融機関数：54＞＜集計対象金融機関数：53＞（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））28

▼システム共同化先における次期システム検討の遅れ▽ 共同化先における次期システムの検討状況と、現行システムの更改時期の想定有無

次期システムの検討を開始
している
44%

次期システムの検討を開始
していない

52%

現行システムの更改時期を想定していない48%

現行システムの更改時期を想定している

56%＜集計対象金融機関数：55＞＜集計対象金融機関数：31＞（出所：日本銀行「金融機関におけるシステム共同化の現状と課題」（２００９．６））
29

２．システムリスク管理上の留意事項（１）経営陣の役割


外部委託への依存度が高まったとしても、経営陣の役割は基本的に変わらない。
経営陣は、システムを経営に直結する問題として捉え、システムリスク管理を重視する必要。
⇒ 一度、システムリスクが顕現化すると、経営に重大な影響。

事例１： みずほ銀行の大規模システム障害（２００２年）－ 旧３行システムの暫定統合時の障害。十分なシステム品質の見極めができな
いままシステム統合に踏み切ったことが原因であるが、背景にはシステム統合の難しさに対する経営陣の認識の甘さ。
事例２： 三菱UFJ証券の大規模情報漏洩（２００９年）－ 元職員の内部犯行が直接の原因であるが、背景には脆弱な情報セキュリティ管理態勢に対する経営陣の認識の甘さ。
30

 経営陣の役割⇒ 外部委託の進展という実態を踏まえたうえで、以下の戦略・方針策定を自ら率先して推進する必要。
・ システム戦略方針の策定
・ システムリスク管理態勢の整備・確立
・ システムリスク管理方針の策定
・ システムリスク管理プロセスの策定
・ 危機管理体制の整備方針の策定
・ 人材育成方針の策定
31

（２）リスクベース・アプローチ
限られた資源のなかで、実効的かつ効率的なシステムリスク管理を行うため、残存リスクの大きさに応じたリスクベース・アプ
ローチを徹底する必要。
①システムの品質管理
 留意しておくべきこと・ 金融機関システムの品質に対する要求水準は高い－ 顧客、監督当局、マスメディア
・ 原因と結果の非対称性－ 大規模システム障害を引き起こすのに大きな原因は必要ない。
・ 品質とコストのバランス確保－ 品質に完璧を期すほど、コストは加速度的に増加。
32

 金融庁監督指針の記述「中小・地域金融機関向けの総合的な監督指針」（Ⅱ－３－６－１－２ システム統合リスクの「リスク特性」とリスク軽減策）
・ システム統合リスクのリスク量は、事象（イベント）の発生確率と発生した場合の影響度（インパクト）の積で認識すべきものであり、銀行は、業容等を勘案した上で、徹底したリスク軽減策が求められることに留意する必要がある
・ 加えて、リスク軽減策に見合うコンティンジェンシープランを整備し、各種リスク事象が複合的に顕在化（障害が同時発生）しても、顧客に大きな影響を及ぼすことを回避できるような態勢を整備する「主要行等向けの総合的な監督指針」（Ⅲ－３－８－１－１システム統合リスク）
・ 主要行等の業容等からすれば、以下のような徹底したリスク軽減策が求められることに留意する必要がある
・ 発生する確率は低い事象でも、発生した時にはその影響が極めて大きいため、コンティンジェンシープランを発動しても制御し切れず、結果として顧客や決済システム等に大きな影響・障害を与えるリスク事象があることを重視し、そのようなシステム及び業務・事務を網羅的に洗い出して、徹底したテスト・リハーサル等により、これらの発生を確実に防止することが基本となる
33

 実効的かつ効率的な品質管理を行うためのポイント
・ システム・開発プロジェクトの重要性（リスクの大きさ）に応じたリスクベースな品質管理の徹底。
－ 例えば、 開発プロジェクトにおいて徹底した品質向上を要するケースとそうでないケースの切り分け。
品質向上のためのメニューシステム・開発
プロジェクトの重要性（委託先成果物検証）
・設計書検証・ソースコード・インスペクション・テスト項目検証
・テスト結果検証，等（テスト結果分析）
・障害発生傾向分析
・メトリックス分析
・すり抜け分析・障害収束分析，等（品質向上テスト実施）
・障害分析を踏まえた追加テスト
・連続日回しテスト
・ピーク日事務量テスト
・過負荷テスト・いじわるテスト
・端末集中打鍵テスト
・顧客との接続テスト
・障害時運用テスト
・無影響確認テスト，等実施の範囲・
深度・網羅性34

②外部委託先管理 留意しておくべきこと・ 業務の外部委託は、金融機関が当該業務に係る顧客への責任を免れるための理由にはならない。
・ 金融機関は当該業務に関して適切なリスク管理が外部委託先によって行われていることを、適切なモニタリングを通じて確保する必要がある。
・ 外部委託先による適切なリスク管理レベルは、当該委託業務の重要度に応じて定まるのであって、契約形態（委託か利用か、国内か海外か、等）により左右されるものではない。
・ 外部委託先のリスク管理が適切かどうかは、金融機関が自身のリスク管理基準に従い当該業務を行った場合と、同等レベルかどうかを判断基準とすべきである。

・ 外部委託先に対するモニタリング手法は、契約形態によっては制約を受けることもあり、適切にモニタリングできる範囲において柔軟であってよいと考えられる

35

 金融庁監督指針の記述「主要行等向けの総合的な監督指針」（Ⅲ－３－３－４－１ 外部委託・意義）
・ 銀行が外部委託を行う場合には、顧客を保護するとともに、外部委託に伴う様々なリスクを適切に管理するなど業務の健全かつ適切な運営を確保することが求められる
・ 外部委託には・・・形式上、外部委託契約が結ばれていなくともその実態において外部委託と同視しうる場合や当該外部委託された業務等が海外で行われる場合も含む（Ⅲ－３－３－４－２ 外部委託・主な着眼点）
・ 委託契約によっても当該銀行と顧客との間の権利義務関係に変更がなく、顧客に対しては、当該銀行自身が業務を行ったのと同等の権利が確保されていること

36 実効的かつ効率的な外部委託先管理を行うためのポイント
・ 委託業務の重要度に応じた求めるべきリスク管理レベルの明確化と、契約形態に応じた適切なモニタリング手法の選定。
－ 契約の制約から適切なモニタリングが出来ない場合は、委託先の変更も考慮する必要。

委託先モニタリング手法
求めるべきリスク管理レベル（金融機関のリスク管理規定に基づき、委託業務の重要度に応じて決定）・定例報告
・定例打合せ・ＳＬＡの取極め・ＣＳＡの実施
・委託先側監査結果の入手
・立入り監査の実施

37

３．ＩＴ人材の育成


外部委託が進展する中で、システム部門に求められる役割とは、・ システム戦略の経営陣への提案
・ ベンダー提案の評価
・ システム開発プロジェクト管理（委託元として）・ 委託先管理

金融機関IT要員に求められるスキルとは、⇒ 「ユーザー部門とITベンダーの橋渡し」⇒ 但し、単なる「つなぎ屋」ではなく、付加価値を付けることが必要。
①システム戦略の策定・提案スキル
経営戦略とユーザーの業務ニーズを踏まえたシステム戦略を策定・提案できるスキル。
②システム企画スキル
IT技術を評価し、製品の特性や能力を生かして実現可能なシステムを企画できるスキル。
ITベンダーの提案を正しく評価できるスキル。
③プロジェクトマネジメントスキル
システム開発プロジェクトのプロジェクトマネージャーとして、全体を統括し、委託先管理、プロジェクト管理を実行できるスキル。
38

▼ IT人材育成のステップ

必要スキルの明確化

現有スキルとのギャップ分析

スキル育成計画

スキル育成策の実施

 併せて、魅力的なキャリアパスと正当な評価軸を整備し、IT要員のやる気を引出すことが重要。
39

▼スキル育成策― スキル育成計画に沿って、中長期的に地道に取り組む他ない。

研修-- 外部セミナーへの参加
 資格取得-- ITコンサルタント、ITアーキテクト、プロジェクトマネージャー
 委託先への派遣-- システム開発、プロジェクト管理等の実務経験-- ジョブローテーションへの組込み 中途採用-- 外部人材の活用
40

ご清聴有難うございました。

41