第5回SIA研究会（例会）プレゼン資料

システムイニシアティブ研究会
２０１１年８月例会

情報システム内部監査からみた
「ユーザー主体のシステム開発」

2011年8月24日
東京海上日動火災保険株式会社
内部監査部
田中幸一
0

Contents
１はじめに

２アプリケーションオーナー（アプリオーナー）制度

３情報システムの予防的内部監査

４おわりに

1

１はじめに

（１）システムイニシアティブ研究会の設立趣旨

■企業の情報システムは「事業に熟知したユーザーが主体」と
なって作らなければ望ましいものは出来ない。
■システムイニシアティブはユーザーがシステム開発の主権を取り戻そうと
いう意味、かつてはユーザー主体で開発をしていた原点に戻ろうという呼
び掛け。

■ユーザーがしっかりしなければベンダーも強くならない。ユーザーがイニ
シアティブを取ろう！！

「ユーザー主体のシステム開発」を「情報システム内部監査」
の視点からみてみよう。

2

１はじめに

（２）東京海上日動のシステム部門のＤＮＡ

＜東京海上の事務機械化９原則（１９６１年）＞

１９６１年８月に東京海上では、
コンピュータを活用して経営管理の高度化を図るべく
「事務機械化９原則」を策定した。
この「事務機械化９原則」は東京海上日動の
情報システム開発の指針としてその精神が受け継がれている。

3

１はじめに


「事務機械化９原則」
①当社の事務機械化は経営管理の高度化に資することを主たる目的とする。

②長期の機械化計画に基づいて総合的に実施する。

③機械化の効果は、短期的な採算をみるにとどまらず長期的採算をも十分考慮する。

④機械化に適する業務はすべて機械化する。

⑤機械の購入には、実験費ないし研究開発費的支出を認める。

⑥部門ごとに機械化担当のスタッフを組織上明確にする。

⑦機械化の効果を高めるために、事務組織および手続きを根本的に改める。

⑧機械の処理能力を増強する。

⑨機械化に関連した人事管理を充実する。
4

１はじめに


こうしたＤＮＡを受け継ぎ、東京海上（２００４年からは東京海上日動）
では
過去から「当社（ユーザー）主体のシステム開発」を実施してきた。

例えば「アプリケーションオーナー（アプリオーナー）制度」
当社では２００２年度から「アプリケーションオーナー」を明確にして
システム開発を実施する取組みを実施しており、定着をしている。

5

１はじめに

（３）情報システム内部監査の視点

こうしたシステム開発の実態を監査する「情報システム監査」では、「弊社の情報シ
ステムに関して、経営者・管理者が主体的にシステム開発・運営のＰＤＣＡを回して
いるか」を監査することが重要である。

■アプリオーナー制度による「情報システム開発」の実施状況の内部監査

＝＝＞ユーザー主体のシステム開発が遍く実施されているかのシステム監査

■情報システムのプロジェクト開発の世界標準である「ＰＭＢＯＫ」を着眼点と
した内部監査

＝＝＞進行中のプロジェクトに対してユーザー主体のシステム開発が整斉と行わ
れ有効なシステムがコスト・納期・品質を守り開発ができるかを確認するシス
テム監査
6

2 アプリケーションオーナー（アプリオーナー）制度

（１）アプリオーナー制度とレビュー制度

アプリオーナー制度

オーナー
オーナー
（サービス部）
（サービス部）
システムの提供
開発・運用委託
システム化ニーズ
最適なソリューションの提案
業務への適用

ユーザーニーズの収集
ユーザビリティの向上開発部門
ユーザー
ユーザー
（営業・損害・事務・会計
（営業・損害・事務・会計品質管理運用部門
・・・）
・・・）支援部門部門

サービスの提供
サプライヤー
・サービス時間
（ＩＴ企画部門）
・応答時間

7

２アプリケーションオーナー制度


アプリオーナー制度、レビュー承認制度

アプリオーナー
ビジネスモデルの実現に向けて欲しかったものが
進捗管理・変更管理（人・物・金・時間）作られているか

業務要件の定義
製品・範囲・内容をＣＨＫ

こういうものを
作って開発部隊（内製・協力会社）最
欲しい終
こういうふうに環境開発テ
作ってシステムの作成スト
欲しいＳＴ
ＯＴ

業務要件を充足するＰＴ IＴ
要求された通りにできているか
システム要件の作成
製品をＣＨＫ
進捗管理・変更管理
サプライヤー (システムズ) システム・環境最終ＣＨＫ
システムの完成度検証
基本計画設計テスト
SP UＣ～SS IT～ST

要件定義製造 8
SA PS～PT



アプリオーナー制度、レビュー承認制度

ＰＧＭ
ＰＧＭ
開
開設計・
設計・システ
システ
発
発ＩＴ化構想立
ＩＴ化構想立要件確定
要件確定作成
作成機能確認・運用
機能確認・運用ム稼
ム稼
工
工案～基本
案～基本（要件定義）＆テ
（要件定義）＆テ・テス
・テス確認テスト
確認テスト働後
働後
程
程計画の策定
計画の策定ストケース設計
ストケース設計ト
ト（ＳＴ/ＯＴ）
（ＳＴ/ＯＴ）の評
の評
（ＳＰ）
（ＳＰ）（ＳＡ/ＵC）
（ＳＡ/ＵC）（ＳＳ/
（ＳＳ/ 価
価
ＰＳ/Ｐ
ＰＳ/Ｐ
Ｇ/ＰＴ/
Ｇ/ＰＴ/
ＩＴ）
ＩＴ）

▲プロジェクト ▲ＳＡ完了 ▲テスト計画 ▲サービスイン承認
計画レビュー
レ
レレビューレビューレビュー
ビ
ビ ▲ＵＣ完了
ュ
ュレビュー
｜
｜
▲運用要件設計レビュー ▲移管評価レビュー
9



アプリオーナー制度（アプリオーナーの役割と責任）

役割・責任

アプリオーナー ◆システム化の目的と期待効果の明確化 ◆システム開発への参画
◆ＩＴ投資の最適化 ◆予定通りの要件確定、システムテストへ
◆システム化ニーズのまとめの参画、ステム開発工程終了の承認
◆開発の優先順位付け ◆ユーザーへのシステム提供と活用促進
（利用者への教育、マニュアル作成等）

サプライヤー ◆アプリケーションシステムの企画立案 ◆納期を遵守したシステム構築／運用
◆高品質・低コストのシステム構築／運用 ◆オーナーの依頼に基づく構築／運用の
◆最適なシステムソリューションの提案（全実施
体最適の実現） ◆予算費消状況、開発状況
◆ユーザビリティの向上／標準化等のディスクローズ
◆ユーザーへのサービス提供

10


（２）２０１１年度の内部監査部の取組方針

１．プロセスチェックの強化を通じたＰＤＣＡサイクルの有効性の検証をする。
経営目標の達成に向けての観点から、内部管理態勢の適切性や有効性の検証を引き続き徹
底する。そのために、不備の指摘に留まらず、組織目標達成に向けての取組みや、課題・
リスクに対するコントロールに関するプロセスチェックを行い、問題の原因となったプロ
セスを追求する。プロセスチェックを通じて、組織体におけるＰＤＣＡサイクルが有効に
機能しているかを検証する。

２．リスクベース・アプローチを一層強化する。
限られた監査資源（要員・時間・費用など）を有効に配分するために、引き続き内部監査
の有効性を高めつつ効率性の追求に努める。その一方で重要なリスクにフォーカスした内
部監査を実施する。

３．経営及び部店に対する明確でメリハリのあるメッセージの発信と指摘に努め、
改善が進むまでフォローアップしていく。

４．新たな問題発見（潜在的な課題発見）に努めると共に、これまで大きくとりあ
げられなかった課題についても、今日的観点で見直して課題の改善に繋げる。

11



着眼点：ユーザーが重要なリスクを認識してシステム開発・運用を実施しているか

着眼点：外部委託管理態勢（クラウドコンピューティングサービス利用におけるリスク対策）
・クラウドを活用するシステム開発が注目されているが、当社においても○○システムでクラウド型シス
テムを活用している。一方でクラウドの利用については、一般的には技術及び効率面で非常に魅力的
であるものの、情報セキュリティ面等でのリスクも存在する。

【確認した事実】（要約で記述している）

１．当部の認識している課題・リスク
クラウドの利用においては、情報漏洩リスクへの対策としてのセキュリティ管理が極めて
重要であると認識している。

２．リスクを軽減するアクションプラン
サービスを提供しているＡ社については、情報セキュリティ関連の外部監査を完了してい
るが、以下の取組みを追加して実施することにより、リスク軽減を図る。
①Ａ社のシステムセンターについての設備やセキュリティー面での実地確認
②Ａ社と「データセンターの管理・情報管理に関する指針」等に対しての当社の基準
に基づく契約の締結
③当社の正当な理由による実地監査の保証の確保
12



着眼点：ユーザーが重要なリスクを認識してシステム開発・運用を実施しているか

【確認した事実】（要約で記述している）

３．ＰＤＣＡサイクルとその実効性
（１）Ａ社のシステムセンターの実地確認結果を確認した。
（２）Ａ社との契約書を確認した。必要な条項が盛り込まれている。
（３）上記の内容を含め、クラウドを利用する事に関するリスク対応等について「経営会
議報告」が１０年Ｘ月に実施されている。

【評価・指摘事項】（要約で記述している）

クラウド利用については、サービスを提供しているＡ社のセキュリティーレベルの現地確
認をし、Ａ社との契約書締結等においてもセキュリティー確保のための各種対策が実施さ
れている。またこれら事項に関して「経営会議」に報告されていることを確認した。適切
な統制がされており、特段の指摘事項はない。

13


（３）保険検査マニュアル等とシステム監査

■２０１１年２月発出の金融庁の「保険検査マニュアル」では、
「経営陣及び管理者による情報システム管理態勢、外部委託管理態勢の
強化」が新たに規定されている。

保険検査マニュアル

「経営陣によるシステムリスク等管理態勢の整備・確立状況：取締役は
システムリスク等の管理を軽視することが、戦略目標の達成に重大な影
響を与えることを十分に認識し、システムリスク等の管理を重視してい
るか・・。」

14



当社の対応

「毎年、システムリスク管理の実施計画（アクションプラン）を策定し、これを担当役員に
諮った上で、取締役委員会であるリスク管理委員会に報告している。また当アクションプラ
ンの実施においては、実施計画をＩＴ部門内でタスク化し、毎月進捗状況をモニタリングし
ておりその実施状況を担当役員に報告し、半期毎にリスク管理委員会に報告している。

システム開発に関しては、全社的な見地からＩＴの持つ可能性を最大限に活かした業務運
営について検討し、必要な施策の推進を図るとともに、ＩＴ投資計画全般についての総合的
調整を行うため、経営会議の付託を受けて「情報化委員会」を設置し、年４回程度論議を行っ
ている。この中で経営戦略との整合性確認や優先順位付け等の議論を経て、年次システム開
発計画にまとめ毎年「経営会議」に付議し、「取締役会」で決議している。また今後の成長
戦略を支えるインフラとして、商品とそれを支える事務・システムおよび代理店システムの
抜本改定およびそれに基づく業務プロセスの改革を行うため、抜本改革を推進している。そ
の進捗状況や重要事項の論議のため、経営会議の付託を受けて「ビジネスプロセス改革委員
会」を設置し、毎月開催をしている。

15



Ｊ－ＳＯＸ「全社的な内部統制（ＩＴへの対応）

「会計システムを含む情報システムの開発および変更計画が適切に策定される仕
組みとなっているか」を冒頭で確認している。その中では、
①情報システム計画は、戦略計画と整合しているか。
②会計システムと関連する情報システムとの間での機能分担等の調整は適切
に行われているか。
③アウトプットの信頼性および適時性を含め、情報システムを利用する者の
満足度をどのように把握しているか。
④経営から付託を受けた全社横断的な委員会を設置・審議する等して、シス
テム開発の優先順位を適切に設定しているか。
⑤情報システム計画は、取締役会での決議または報告および監査役（会）ま
たは監査委員会への報告がなされているか。
を求めている。

真に「ユーザー主体のシステム開発が実施される態勢」が構築されていな
いと、このＪ－ＳＯＸ上の規定に応えることはできない。

16


（４）ユーザー主体のシステム開発が遍く実施されているかのシステム監査

①上からの確認：「情報システム開発計画」＝＝＞「レビュー承認一覧表」

サンプルで２５件の
プロジェクトを任意抽出

「プロジェクト計画レビュー資料、ＳＡ完了レビュー資料、ＵＣ完了レビュー資料、テスト計画レ
ビュー資料、サービスイン承認レビュー資料」等に関して「アプリオーナー」が適正にレビューをし、ア
プリオーナーならびにＩＴ部門の責任者が承認をしているかを確認する。

17


（４）ユーザー主体のシステム開発が遍く実施されているかのシステム監査

①下からの確認：「プログラムディレクトリー」＝＝＞「プログラム一覧表」

ＰＡ１００ 2011/7/26
ＰＡ１０００２ 2010/5/15
ＰＡ１０００３ 2010/5/15 サンプルで２５件の
ＰＢ２００３４ 2011/7/26 プロジェクトを任意抽出

「プロジェクト計画レビュー資料、ＳＡ完了レビュー資料、ＵＣ完了レビュー資料、テスト計画レ
ビュー資料、サービスイン承認レビュー資料」等に関して「アプリオーナー」が適正にレビューをし、ア
プリオーナーならびにＩＴ部門の責任者が承認をしているかを確認する。

18

３情報システム開発の予防的内部監査
（１）情報システム開発の予防的内部監査とは

■情報システムの安定稼動は金融機関の信頼の前提
今日の金融機関等には、新しい情報技術を積極的に活用して情報戦略を展開し、信
頼できる金融サービスを提供することが求められている。こうした中にあって、情
報システムの安定稼動は金融機関の信頼の前提であり、情報システムリスクが金融
機関等の経営戦略の達成と業務活動に大きな影響を与えることは論をまたない。

■金融商品取引法：「Ｊ－ＳＯＸ」による内部統制の評価
こうした中で、金融商品取引法によって、経営者が、財務報告に係る内部統制の整
備及び運用状況の有効性について評価・報告することを義務付けられた。この所謂
「Ｊ－ＳＯＸ」の有効性の評価に関わる内部監査において、ＩＴ全般統制のリスク
評価について統制目標等が「ＲＣＭ（Risk Control Matrix）」という形で具体的
なテンプレートとして明示されたことは、内部監査の品質の向上に大きな貢献をし
てきた。
しかしながら、「Ｊ－ＳＯＸ」上のテンプレートは、情報システムの信頼性や安全
性を監査の目的とする「セキュリティ型のシステム監査」には十分に対応ができる
が、情報システムの有効性及び効率性を監査の目的とする「戦略支援型のシステム
監査」には、対応が難しい。
19

（１）情報システム開発の予防的内部監査とは

■新規の情報システム開発のリスク
金融機関等では、経営戦略の策定と実行に向けて年間で数十億の新たな情報システ
ム開発を実施している。こうした「新規の情報システム開発」には、「コスト」
「品質」「納期」といったリスクの他に「所期の情報システム開発効果を発揮でき
ないリスク」も潜在的に抱えているが、こうしたリスクは非常に大きく、場合によっ
ては会社経営を根底から揺るがすリスクに繋がることもある。

■ 「ＰＭＢＯＫ」による「システム開発の予防的内部監査」
しかしながら、こうした「情報システム開発」のリスクを標準的なフレームワーク
で内部監査をするテンプレートが殆どなかった。
そこで筆者は、東京海上日動火災で開発をされた各種の「新規の情報システム開発」
にプロジェクト開発の世界標準である「ＰＭＢＯＫ（Project Management Body Of
Knowledge）」を適用し、「情報システム開発の予防的内部監査」として一定の成
果を挙げてきた。本項では、その実施状況を報告する。

進行中のプロジェクトに対してユーザー主体のシステム開発が
整斉と行われ有効なシステムがコスト・納期・品質を守るのみならず、
所期の開発効果を発揮するシステムを開発ができるか
を確認するシステム監査
20

（２）情報システム開発のリスクとプロジェクトマネジメント

金融機関等では、経営戦略の達成に向けて情報システムを新規に開発し活
用をしており、金融機関等のビジネスは情報システムなくしては成り立た
なくなっている。その意味で情報システムリスクは、事業活動に伴って生
じるビジネスリスクの中でも大きな位置づけを占めるリスクになっている。

情情 ①情報システムの統制環境
報報（経営者の情報システムに対する関与態勢等）
シシ
スス ②情報システムの開発に関するリスク
テテ
ムム ③情報システムの運用に関するリスク
のの
リリ ④情報システムのセキュリティに関するリスク
スス
クク ⑤情報システムの外部委託に関するリスク

⑥情報システムのコンティンジェンシーに関わるリスク 21


情情 ①情報システムの統制環境
報報（経営者の情報システムに対する関与態勢等）
シシ
スス ②情報システムの開発に関するリスク
テテ
ムム ③情報システムの運用に関するリスク
のの
リリ ④情報システムのセキュリティに関するリスク
スス
クク ⑤情報システムの外部委託に関するリスク

⑥情報システムのコンティンジェンシーに関わるリスク

Ｊ－ＳＯＸのテンプレートが提供されており、標準的な監査スキームが確立

Ｊ－ＳＯＸのテンプレートは開発手順の遵守性の確認が主眼 22


Ｊ－ＳＯＸのテンプレートは開発手順の遵守性の確認が主眼

シシ
スス
テテシステム開発の「コスト」に関するリスク
システム開発の「コスト」に関するリスク
ムム 1990年代の前半の、米国
開開
発発企業でのＩＴプロジェクトの
ののシステム開発の「品質」に関するリスク
システム開発の「品質」に関するリスク成功率は１６．７％（注）
リリ
スス
ククシステム開発の「納期」に関するリスク
システム開発の「納期」に関するリスク

ＰＭＢＯＫを活用したシステム開発の予防的内部監査

（注）Kathy Schｗalbe著、ＰＭＩ日本支部訳「ＩＴ業界のためのプロジェクトマネジメント教科書」
23

２情報システム開発の予防的内部監査
（３）ＰＭＢＯＫを活用しての予防的内部監査

ＰＭＢＯＫ（ＰｒｏｊｅｃｔＭａｎａｇｅｍｅｎｔＢｏｄｙＯｆＫｎｏｗｌｅｄｇｅ）

①システム開発の統合マネジメント（プロジェクトの全体管理）
ＰＰ ②スコープマネジメント（プロジェクトの範囲・対象の管理）
ＭＭ
ＢＢ ③タイムマネジメント（プロジェクトの進捗管理）
ＯＯ ④コストマネジメント（プロジェクトのコスト管理）
ＫＫ
のの ⑤品質マネジメント（プロジェクトの品質管理）
管管
理理 ⑥人的資源マネジメント（プロジェクトの要員管理）
項項 ⑦コミュニケーションマネジメント（意思疎通の状況）
目目
⑧調達マネジメント（プロジェクトに関する調達管理）

⑨リスクマネジメント（プロジェクトのリスク管理）

上記に各種アレンジして「内部監査の着眼点」を設定 24

（４）ＰＭＢＯＫを活用しての予防的内部監査の着眼点


内部監査の着眼点主要な監査資料等
①システム開発の全体計画スケジュール（プロジェクト・システム開発のマスタースケジュー
のマスタープラン等）ル

②システム開発に伴う全体管理（システム開発のプロ・システム開発のプロジェクト体制図
ジェクト・マネジメント・オフィス（ＰＭＯ）機能等）

③各サブシステム単位の進捗状況・課題管理状況を把・外部委託会社からの報告要領がわ
握・報告する「標準的なスキーム」（外部委託会社からかる資料
の報告要領並びにその報告を管理するスキーム等）

④システム開発の統合マネジメント(プロジェクト全体の・プロジェクト推進に関わる各種会議
管理）上の現時点での課題（開発主体（アプリオー体一覧表
ナー）等の認識）
25


②スコープマネジメント（プロジェクトの範囲・対象の管理）


①システムの基本要件定義の完了状況（システム化の・システム構成の全体がわかる資料
範囲の明確化状況）、その成果物の文書化状況とアプ
リオーナーの承認状況

②各サブシステムの重要な制約事項の明確化状況（ア・機能の中で「重要な制約事項」（実施
プリオーナーの承認状況）しない機能を含む）を明示した資料

③要件変更・仕様変更のスキームとその運用状況・基本要件の変更のスキーム（変更管
理手続き等）がわかる資料

④その他のスコープマネジメント（システムの機能範囲）・他社システム等との機能比較表等
上の確認事項（例：同種他社システムとの比較、パッ
ケージシステムとの比較等）
⑤スコープマネジメント上の現時点での課題
26


③タイムマネジメント（プロジェクトの進捗管理）


①システム開発に関わる全ての活動の可視化状況、週・スケジュール実績対比表
次単位の「スケジュール実績対比表」の整備・運用状況（ＷＢＳ作業予定実績対比表等）

②進捗管理における計量方法（ステップ数、プログラム・各開発工程（要件定義局面、システ
数、要件変更項目数、テスト項目数等）と定義・活用のム設計局面等）での進捗管理要領を
定義した資料
状況
③アプリオーナー側での準備状況を把握・報告するス・スケジュール実績対比表
キームの整備・運用状況

④タイムマネジメント上の現時点での課題

27


④コストマネジメント（プロジェクトのコスト管理）


①基本要件定義終了時の、システム費用（ベンダー等・開発費、運用費の算出根拠がわか
開発会社への開発委託費用、システム運用ハードウェる資料
ア費用）の再見積もり状況

②システム移行コストや、研修導入コスト等直接開発コ・間接費用（研修導入コスト）の算出根
スト以外のコストの見積もり状況拠がわかる資料

③ＮＰＶ上での費用対効果計画での効果発揮に向けた・ＮＰＶ計画上の効果発現のための具
具体的な「アクションプラン」体的なアクションプラン

④コストマネジメント上の現時点での課題（注）ＮＰＶ：Net present value（正味
現在価値）

28


⑤品質マネジメント（プロジェクトの品質管理）


①各サブシステムの品質管理に関する評価基準の設・外部委託会社が実施する品質管理
定状況基準を示す資料等
･自社情報システム部門が実施する品
質管理基準を示す資料等
②各開発フェーズでのシステム開発レビューの管理・運
営状況・公式のシステム開発レビュー資料

③運用品質を確保するための「運用レビュー」の実施状・運用レビュー資料
況あるいは計画

④品質マネジメント上の現時点での課題

29


⑥人的資源マネジメント（プロジェクトの要員管理）


①サブシステム毎の開発体制図（アプリオーナー部門、・開発体制図
情報システム部門、外部委託会社（含む二次受会社））

②システムの工程毎の要員計画表（積上表）の整備状・開発要員積み上げ図
況

③要員に関する課題（アプリオーナー、情報システム部
門、外部委託会社の要員不足等）に対する解決スキー
ムの準備状況

④人的資源マネジメント上の現時点での課題

30


⑦コミュニケーションマネジメント（意思疎通の状況）


①システム開発に関する情報（進捗、課題、要件変更・各会議体議事録
等）の共有の仕組（会議体、標準管理資料等）の定義・
運用状況

②同会議での質疑内容等の議事録等の記録状況なら
びに「課題管理表」等での情報共有状況

③外部委託会社との定例打合せ等での管理責任者か
ら正確な情報があがるスキームの整備・運用状況

④コミュニケーションマネジメント上の現時点での課題

31




①外部委託会社等との「外部委託契約書」等の契約状・外部委託契約書
況

②外部委託会社の決定に至るまでのＲＦＰの提示、先・外部委託会社からの提案書
方提示の「提案書」内容の比較検討状況・上記提案を比較した資料

③ システム開発に伴う各種物理資源（テスト用コン（注）ＲＦＰ（Request For Proposal）:
ピュータ等）の調達スケジュール等の管理状況情報システム開発にあたりシステム開
発の概要を複数の開発外部委託会社
に正式に伝え、開発費用等の見積も
りや開発体制等についての先方の提
④調達マネジメント上の現時点での課題案情報を入手する手続きの資料

32




①各サブシステムのシステム開発に伴うリスクの認識・・システム開発リスク管理表等
明示の状況
②システム運用上のリスクの認識・明示状況・システム運用リスク管理表等

③Ｊ－ＳＯＸ対応上のリスク管理状況
ａ．ユーザＩＤ・パスワードの管理・ユーザＩＤ・パスワードの管理内容

ｂ．情報の網羅性を保証する仕組み・情報の網羅性を保証する仕組みの資料
ｃ．情報入力の権限者による承認の仕組み・権限者による承認の仕組みを示す資料

ｄ.情報の正確性をモニタリング等によって確認する仕組み等
④ 当該システムのサーバ群の「財務諸表に関連する・当該システムを運用するサーバの管
サーバ」としての管理状況（プログラム変更管理、特権理状況を示す資料
IDの管理サーバ運用、サーババッチ管理、バックアップ
運用等）
⑤コンティンジェンシー・プランの基本的な考え方ならび・「コンティンジェンシー・プランの基本
にプランの作成予定的な考え方」を示す資料

⑥リスクマネジメント上の現時点での課題 33

（５）着眼点を活用しての具体的な予防的監査の例

内部監査による具体的な指摘事項備考

①現段階で策定しているシステム開発のマスタースケジュールについては、ＸＸ
年ＸＸ月の経営会議報告に比べ、「２ヵ月遅れのＸＸ年ＸＸ月のサービスイン」とし
ている。ここで策定した「マスタースケジュール」は関係者が共有し、今後は当該
スケジュールを厳守すべく、プロジェクトマネジメントの徹底を期待したい。なお、
改定した「マスタースケジュール」については、ＳＡ（基本要件定義）レビュー終了
後等の機会を捉え、担当役員への報告をすることが必要である。

②プロジェクト開発のＰＭＯ（プロジェクト・マネジメント・オフィス）については、基
本的にＰＭＯメンバーを実開発主体のメンバーと分けて、ＰＭＯの役割の発揮の
実効性を確保しており評価できるが、今後のＰＭＯの役割発揮に向け、下記のよ
うな活動をすることが必要である。

ＰＭＯメンバーは、①各サブシステムのスイーパーの役割（発生した課題の解消等に向
けての調整等の活動）と、②ＰＭＯの主要共通機能の企画推進のリーダーの役割を担っ
ていく必要がある。システム開発が佳境になってくると①の役割に専念することが多くな
り、②の役割の発揮が実施できなくなるおそれがあるので、ＳＡ（基本要件定義）の期間
内に「システム開発の標準化」「進捗管理に関る各種ルール」、「品質管理に関る各種
ルール」等を策定し、プロジェクトメンバーに周知・徹底をしておく必要がある。

34




①今回の開発に際しては、「フィージビリティスタディー」によって、大部分のＳＡフィージビリティスタディー：
大規模なシステム開発を計
（基本要件定義）が実施されていることを、「プロセスフロー」等の基本要件記述画する時に、そのシステム開
書類で確認をした。またその中での残存課題や重要な制約事項も明確になって発の実現可能性を、当該プ
ロジェクトの基本要件、ハー
いるので、ＸＸ年ＸＸ月末に予定されているＳＡレビューで基本要件の確定をし、ドウェア基本形態、開発・運
その後の要件変更についてはルールを定め厳重に管理することが求められる。用コスト概要、開発体制等に
ついて、コンサルファームや
システム開発の専門企業に
外部委託をして、検討するこ
と。
②フィージビリティスタディーで、作成した事務・システムフロー等に関して、営業
部門、業務部門のウォークスルーは監査時点では、まだ実施ができていないと
のことであるが、例外処理を含めて現行の事務処理との親和性があるかを、ＳＡ
レビューの前に確認しておく必要がある。

③新システムは、他社システムを凌駕した機能設計がされていると判断される。
しかしながら今後他社は「お客様・代理店さんとの「情報の共有化」」について新
しいシステム構築をしてくることが考えられる。新システムにおいても、第Ⅱ期の
フィージビリティスタディーの一環で「情報の共有化の仕組み」の要否を検討する
ことが必要と考える。

35



①フィージビリティスタディーの際に、基本要件の検討項目タスクを詳細にブレー
クダウンして、外部委託会社（以下：Ａ社）が日次単位の「スケジュール実績対比
表」を作成し、詳細に管理していることを確認した。ＵＩ工程以降の実開発工程に
おける進捗管理についても、基本的には同様な進捗管理をしていくことで良い
が、以下の留意点について検討をして、ＳＡ工程終了までに、ＰＭＯで「進捗管理
の具体的方法」について決定し、プロジェクトメンバーに徹底をすることが必要で
ある。
ＵＩ工程は、アプリオーナー部門、情報システム部門が実際に作業に関与することもあって、進捗
は体感でも把握ができるが、ＳＳ（システム設計）～ＳＴ（Ａ社によるシステムテスト）の期間につい
ては、期間が１０ヵ月と長い中で、アプリオーナー部門・情報システム部門は殆ど作業に関与しな
いフェーズになるので、的確な数値に基づく進捗報告がないと状況が全く把握できない。従って、
進捗管理における計量方法（ステップ数、プログラム数、要件変更項目数、テスト項目数等）を明
確に定義して、Ａ社等から報告をもらうことが重要である。

②ＳＳ以降の工程の進捗報告に関して、プロジェクト責任者（部長クラス）が参加
し、プロジェクト全体の進捗・課題管理を行う月次報告会議には、少なくともＡ社
の「品質管理部門」が精査をしてコメントした進捗管理資料を活用することによっ
て、進捗管理の正確性・実効性を確保することも有効である。検討を願いたい。

36



①フィージビリティ完了時点で、以下のように必要になる費用（システム開発費
用・運用費用）に関して詳細に積算を行うことによって、費用を明確にしている。
この金額が、ＸＸ年ＸＸ月の経営会議に報告されていることを確認した。

②Ａ社と「請負契約」を一括して締結することについては、以下の観点から妥当
であると考える。
・既述のとおり、フィージビリティスタディーで、基本要件定義をほぼ済ませて開発範囲は明
確になっておりＡ社からも正確に費用見積もりが提示され（費用の上振（うわぶれ）リスク（コ
ストが増加するリスク）は少ないと思料する。従って、Ａ社が見積もった費用の範囲で（万が
一二次受け会社の開発品質が芳しくなく、予定工数以上の工数がかかったとしても、Ａ社の
責任で費用吸収をする）開発の外部委託をする「一括請負契約」は妥当である。

・詳細要件定義以降の局面でコスト増加がありうるのは、「要件追加」の時になるが、当該コ
スト増加要因は、ＰＭＯ等による「コスト管理」で吸収可能である。（なお、コスト増加につな
がる「要件変更」に関しては、予備費ＸＸ万円を予算化しているが、この費消に関しては厳格
な管理が求められる。）

37




①開発したシステムの品質管理に関しては、Ａ社にて主に開発を行う部分につ
いては、Ａ社の品質管理基準と、情報システム部門における標準的なバグ密度
資料などをもとに比較・検討を行い、基準を設定し管理を行っていく方向性を確
認した。品質管理の方向性は、前記で妥当であるが、ＳＡ工程終了までに下記
の検討が必要である。
ａ．Ａ社内の品質管理部門による監査のタイミングならびに実施内容を確認し、
情報システム部門の開発品質管理部での評価を実施することが必要である。

ｂ．月次報告会議には、Ａ社の「品質管理部門」が精査をしてコメントした品質
管理資料を活用することによって、品質管理の正確性・実効性を確保すること
が必要である。

38



①開発工程毎の要員計画については、以下の課題がありＳＡ工程終了までには
検討が必要である。
ａ．アプリオーナー部門の工数
・第Ⅱ期のフィージビリティスタディーとの重なりの中で、ＸＸ年Ｘ月～Ｘ月やＸＸ
年Ｘ月～Ｘ月にはオーナー工数として３人月と大きくなるが、この工数を確保す
ることが必要になる。
・第Ⅱ期フィージビリティの要員をネームドで確保することが必要と思料する。
新機能が多いこと、ならびに非常に重要な機能部分の検討なので、当該実務
に精通した要員の確保が重要と考える。
ｂ．情報システム部門の工数
・Ⅰ期ならびにⅡ期の重なりの中で、ＸＸ年Ｘ月～ＸＸ年Ｘ月は、４人月～４．７
人月の工数が予定されている。これに対してネームドで要員を確保しておく必
要がある。また本要員計画が「ＸＸ年度システム開発計画」上でオーソライズさ
れていることが重要である。
ｃ．Ａ社の工数
・Ａ社のフィージビリティスタディーのリーダーは第Ⅰ期のプロジェクトマネー
ジャーとは異なる要員をアサインしてもらう必要がある。第Ⅰ期と同様に、第Ⅱ
期のフィージビリティスタディーのリーダーがそのまま第Ⅱ期のプロジェクトマ
ネージャーになることが望ましく、第Ⅰ期と第Ⅱ期の重なりを考えると、異なる 39
要員であることが必須である。




フィージビリティスタディー時の議事録（Ａ社との定例、アプリオーナー部内の定
例）を確認したが、的確な内容で報告され情報共有がされていることが窺えた。
今後のプロジェクト推進においても、フィージビリティスタディー同様にプロジェク
トメンバー間の良好なコミュニケーションを期待したい。

40



①ＸＸ年ＸＸ月に「Ａ社」ならびに「Ｂ社」の２社に対して、「①システム開発の具体
的内容・体制及び費用、②システムを稼動させる上で必要なハードウェア・ソフト
ウェア構成と費用、③利用開始後の運用体制等」に関して、詳細な内容のＲＦＰ
を出し、先方２社の提案を評価して「Ａ社」を開発パートナーとして選定をしてお
り、問題のない手続きを踏んでいる。

②特にＲＦＰ時に、オンラインレスポンスやセキュリティ要件、ＢＣＰ等の「非機能
要件」を詳細に記述し提案を求めていることは評価できる。

41




①ＳＡ工程完了後に、ＰＭＯメンバー、プロジェクトマネージャーで「リスク整理」を
行い、「事前のリスク軽減策の策定、コンティンジェンシープランやバックアッププ
ラン」の作成に繋げることが望まれる。
②当システムで使用する「ユーザＩＤ」ならびにパスワードに関しても、フィージビ
リティスタディーで十分に検討していることが窺われた。今後のＵＩ工程の中で、
「パスワード変更サイクル」や「お客様ユーザＩＤの登録方法」の検討課題を早期
に決定することを期待したい。
③データの網羅性をシステム的に保証するため、件数確認に加えて重要な金額
確認は、各システムのインターフェース時に自動的に必ず実施すべきである。
（件数と金額の合計チェック：データヘッダーにセットし、後続システムでカウント
チェックをする等。）
④ＢＣＰ（Business Continuity Plan 業務継続計画）については、「新システム業
務設計書（ＢＣＰ検討）」によって精緻に検討がされ、多摩・千葉両システムセン
ターに二重化して構築し、有事のみならずシステム障害時におけるＢＣＰ体制を
実施することを確認した。新システムは、当社計上システム等各サブシステムが
有機的に連結されているので、当該システムの停止リスクを分析し、ＵＩ時には
「コンティンジェンシープラン」や「バックアッププラン」を作成し、ＢＣＰとして文書
化しておくことが必要である。
42

（６）ＰＭＢＯＫを活用した情報システム開発監査の留意点

■前記の例
前記の事例のシステム開発は、基本要件定義直前の段階で実施した「比較的プ
ロジェクトマネジメント体制がしっかりした事例」であるが、それでもＰＭＢ
ＯＫの網羅的なマネジメント項目に照らすと前記記述のような指摘事項等が発
見される。

■システム開発の予防的内部監査の経験
筆者は、この情報システム監査を（08年度～10年度で）、「東京海上日動の
情報システム開発」に対して１３例（開発外部委託費百億台のシステム１件、
十億台のシステム７件、１億～９億のシステム５件）経験をしてきた。
この経験から、本システム監査の実施上の留意点を以下掲げることとする。
43


対象とする情報システム開発の規模

■本監査の対象は、外部委託費が１億～百億円台の大規模システム開発
の予防的内部監査に適している。

■数千万単位のシステム開発でも適用が可能であるが、そうしたシステ
ム開発の「リスク」はそれ程大きくなく、予防的システム監査を実施
する効果も大きくない。
（但し、「チェックリスト」を活用した簡易監査は有効である。）

■それに対して外部委託費が１億～百億円台の大規模システム開発は、
プロジェクトマネジメントの優劣によって、リスクの顕在化の程度は
非常に大きく、従ってこのような予防的システム監査実施の効果も大
きいと考える。

44


対象とする情報システム開発の時期

■予防的監査であるので、システム開発工程の中でも「基本要件定義」
終了時に、内部監査を実施することが、最も適切である。

■それ以前では、基本要件も決定しておらず、監査対象システムの骨格
が定まっていないので、この監査の実施によって指摘できる要改善点
が明確にならない可能性が高い。

■一方でシステム開発のシステムテスト実施の工程であると、既に「プ
ログラムの作成」は終了しており、指摘事項は「結果に関する指摘」
になり、「要改善対応」も時間的にも実施できない状況になっている
ことが多い。

45


「ＰＭＢＯＫ」適用監査上の留意点

■前述の事例は、当社保険システムの所謂「勘定系の基幹システム」で
はなく、部門システムの再構築をアプリオーナー主導で、外部委託会
社を活用して実施した事例である。

■情報システム部門のシステム開発要員が超大規模システムの開発と重
なって逼迫している中で、アプリオーナー主導で実施せざるを得ない
プロジェクトであったが、当該アプリオーナー部門には大規模システ
ム開発の経験者がおらず、それ故に「プロジェクトマネジメント」の
遂行にはアプリオーナー部門にも不安があった。

■こうしたアプリオーナー主導のシステム開発は情報システム部門要員
を多く抱えていない会社では一般的であり、この「予防的システム監
査」の手法は有効であると考える。その際に留意すべき「内部監査」
のポイントを次項から解説する。
46



■大規模システム開発では、「ＰＭＯ（プロジェクト・マネジ
メント・オフィス）」の役割が決定的に重要であり、その活
動状況を実際の議事録等で詳細に確認をする必要がある。

■ＰＭＯの機能に慣れないユーザー主導のシステム開発では、
外部委託会社のＰＭＯに多くを依存することになるが、その
機能発揮状況を十分に確認し、場合によっては、「ＰＭＯ」
の要員強化まで求めることがある。

47



■大規模システム開発の場合、「フィージビリティスタディー」
によって、システムの実現性の可否を判定することが望まし
い。「フィージビリティスタディー」はコンサルファームや
大手システム開発会社に外部委託することになるのでコスト
は掛かるが、その結果を「基本要件定義」に繋げることがで
きるので、余計なコストの発生にはならない。

■従って、当該「フィージビリティスタディー」の実施状況を
「フィージビリティスタディー結果報告書」等で十分に監査
をする必要がある。
48



■基本要件の検討項目タスクを詳細にブレークダウンした日次
単位の「スケジュール実績対比表」を作成し、詳細に管理し
ていることの確認が重要である。

■システム開発工程の進捗報告においては、プロジェクト責任
者（部長クラス）が参加し、プロジェクト全体の進捗・課題
管理を行う月次報告会議には、少なくとも外部委託会社の
「品質管理部門」が精査をしてコメントした進捗管理資料を
活用することによって、進捗管理の正確性・実効性を確保す
ることも有効である。この項目の実施状況の確認も重要であ
る。
49



■フィージビリティ完了時点で、必要になる費用（システム開発費用・運
用費用）に関して詳細に積算を行ない、その費用が経営会議等で経営層
に報告されているかを確認することが必要である。

■この時点での費用見積もりは、「プロジェクト予算化」の見積もりであ
り、実際に必要になる費用に対して「－１０％～＋２５％」の誤差が出
るという（注）。近時の厳しい経営環境では、予算化の際に安全目の
「プロジェクト予算」を稟議するのは困難なので、開発主体は実際に掛
かるより少なめの予算を立案し稟議する傾向もある。従ってこの「見積
もり費用」立案時に、「システム要件策定の不確定要素」を勘案した
「予備費」をシステム開発費用・システム運用費用それぞれの１０％分
確保して、当該費用の費消には、「ＰＭＯ」や「部長クラスが参加する
ステアリング・コミッティ」の承認が必要とされる仕組みが確立されて
いるかを確認することが必要である。
50

（注）「ＩＴ業界のためのプロジェクトマネジメント教科書」の第７章「コストマネジメント」の「コスト見積もりの種類」から引用



■開発するシステムの品質管理に関しては、外部委託会社で主
に開発を行う部分については、当該社の品質管理基準に準拠
して管理を行っていることを確認する必要がある。

■また、「部長クラスが参加するステアリング・コミッティ」
で、外部委託会社の「品質管理部門」が精査をした「品質管
理報告書」が提出されていることが重要であり、この内容も
確認する必要がある。

51



■開発工程毎の要員計画については、システム開発に従事する
システム部門の要員や外部委託会社の要員の他、詳細要件定
義やシステムテスト（ユーザー受け入れテスト）に従事する
アプリオーナー部門の要員が極めて重要である。月毎の「必
要な要員積み上げ表」によって、当該要員がネームドで確保
されているかを確認する必要がある。

52



■各会議体の議事録を詳細に確認し、的確な内容で報告され情
報共有がされていることを精査することが必要である。会議
体の議事録が作成されていないケースや議事録が項目程度で
十分な内容でない場合には、当該プロジェクトはうまく進捗
しない危惧があり、注意が必要である。

53



■当該システム開発の外部委託契約書が適切に締結されている
ことは勿論である。

■加えて、「①システム開発の具体的内容・体制及び費用、②
システムを稼動させる上で必要なハードウェア・ソフトウェ
ア構成と費用、③利用開始後の運用体制、④レスポンスやセ
キュリティ等の非機能要件」に関して、詳細な内容のＲＦＰ
を複数社に出して、当該社の提案を評価した経緯を確認する
ことが重要である。

54



■各サブシステムのシステム開発に伴うリスクならびにシステ
ム運用に伴うリスクに関して、「リスク確認書」に記載され、
当該リスクが管理されていることを確認することが必要であ
る。こうした管理の成果が、「事前のリスク軽減策の策定、
コンティンジェンシープランやバックアッププランの作成」
に繋げられていく。

■当該システムが長期間に亘って使用できない障害発生時のＢ
ＣＰ（Business Continuity Plan：業務継続計画）の確認も
必要になる。

55



■財務諸表に影響のある業務システムを構築する場合に「Ｊ－ＳＯＸ」上
の以下の主要ポイントが設計されていることを確認することが非常に重
要になる。システムが完成してからこうした仕組みを構築したり改善す
るには追加のコストと開発期間が必要になるので、「あの時に言っても
らっていたら・・・」と被監査部門からの不信感に繋がる危惧がある。

①ユーザーＩＤとパスワード
②入力データの正確性を保証する上位者等による「承認」の仕組み
③システムの正確性を保証する「プルーフリスト」の出力と定期的な
モニタリング体制の整備状況（予定）
④データの網羅性をシステム的に保証するため、件数確認に加えて重
要な金額確認は、各システムのインターフェース時に自動的に必ず
実施すべきである。（件数と金額の合計チェック：データヘッダー
にセットし、後続システムでカウントチェックをする等。）
56

（７）予防的内部監査の効果と今後の課題

■新規システム開発は、「事業経営に影響を与える不確定要因」である
「潜在リスク」を数多く抱え、開発に従事をしているメンバーも「不確
定要因」を明確に意識していないことがある。この「予防的システム監
査」は、そうしたリスクを「見える化」し、経営層を含めた関係者で共
有ができ、リスク軽減の対策を採ることができる。

■そうしたことで、当社ではこの「予防的システム監査」を受けた被監査
部門の口コミもあって、「予防的システム監査」を受けたいという要望
が数多く上がっている。「予防的システム監査」での指摘事項（要改善
事項）への対応は、被監査部門が主体的に遂行していかなければならな
い課題であり、ある意味で「仕事が増える」状況にはなるが、要改善事
項に対応することによって、「リスク」を軽減していくことは重要な業
務であり、被監査部門では寧ろ歓迎すべき事項と捉えてくれている。

57

（７）予防的内部監査の効果と今後の課題

■システム開発はユーザー主導で進めるべきであるが、ベンダーがＰＭＯ
を中心にＰＭＢＯＫ等のマネジメントツールを活用して「ユーザー」サ
イドと良好なコミュニケーションを取ってシステム開発を進めることが
必須条件であり、その内容を「予防的システム監査」では、詳細に確認
し「被監査部門のみならず経営に提言」できる。

■今後は、この「予防的システム監査」を引き続き実施することによって、
この内部監査手法を「改善提案機能」から「保証機能」にできるだけ近
づけて「戦略支援型のシステム監査」の手法として確立していきたい。

58

４おわりに

ユーザー主体のシステム開発に向けての内部監査の今後の課題

①現在のアプリオーナー制度からアプリオーナーがユーザ（代理店、営業
損害第一線）の声を的確に吸い上げてシステム計画をする仕組み作り

②開発したシステムの活用推進のための仕組み作り

③開発したシステムの投資効果を事後に評価・判定していく仕組みの定着

④上記①②③のＰＤＣＡの検証と提言（内部監査）

⑤システム開発の予防的内部監査の一層の深化

59

ご清聴ありがとうございました。
本日の講演が、
「ユーザー主体のシステム開発」の推進
に少しでもご参考になればと
思っております。

本資料・本講演は講演者自身の見解であり、
講演者の所属する組織の意見を代表するものではありません。

60

第5回SIA研究会（例会）プレゼン資料

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 第5回SIA研究会（例会）プレゼン資料

Semelhante a 第5回SIA研究会（例会）プレゼン資料 (20)

Mais de Tae Yoshida

Mais de Tae Yoshida (12)

第5回SIA研究会（例会）プレゼン資料