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

0

システムイニシアティブ研究会

２０１１年８月例会

システムイニシアティブ研究会

２０１１年８月例会

2011年8月24日

東京海上日動火災保険株式会社

内部監査部

田中幸一

情報システム内部監査からみた

「ユーザー主体のシステム開発」

1

Contents

はじめに１

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

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

おわりに４

2

■企業の情報システムは「事業に熟知したユーザーが主体」となって作らなければ望ましいものは出来ない。

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

■システムイニシアティブはユーザーがシステム開発の主権を取り戻そうという意味、かつてはユーザー主体で開発をしていた原点に戻ろうという呼び掛け。

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

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

3

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

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

１９６１年８月に東京海上では、コンピュータを活用して経営管理の高度化を図るべく

「事務機械化９原則」を策定した。この「事務機械化９原則」は東京海上日動の

情報システム開発の指針としてその精神が受け継がれている。

はじめに

4

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

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

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

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

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

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

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

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

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

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

はじめに

5

１

こうしたＤＮＡを受け継ぎ、東京海上（２００４年からは東京海上日動）では

過去から「当社（ユーザー）主体のシステム開発」を実施してきた。

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

はじめに

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

6

はじめに１（３）情報システム内部監査の視点

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

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

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

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

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

7

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

アプリオーナー制度

サービスの提供・サービス時間・応答時間

オーナー（サービス部）

オーナー（サービス部）

ユーザー（営業・損害・事務・会計

・・・）

ユーザー（営業・損害・事務・会計

・・・）

システムの提供

システム化ニーズ業務への適用

サプライヤー（ＩＴ企画部門）

品質管理部門支援部門

開発部門

運用部門

ユーザーニーズの収集ユーザビリティの向上

最適なソリューションの提案

開発・運用委託

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

8

２（１）

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

アプリオーナー

業務要件を充足するシステム要件の作成

最終テストＳＴＯＴ

ＰＴ IＴ

ビジネスモデルの実現に向けて進捗管理・変更管理（人・物・金・時間）

進捗管理・変更管理システムの完成度検証

要求された通りにできているか

業務要件の定義

サプライヤー

製品・範囲・内容をＣＨＫ

欲しかったものが作られているか

製品をＣＨＫ

システム・環境最終ＣＨＫ

こういうものを作って欲しい

(システムズ)

開発部隊（内製・協力会社）

環境開発

システムの作成こういうふうに

作って欲しい

基本計画SP

要件定義SA

設計UＣ～SS

製造PS～PT

テストIT～ST

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

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

9

２（１）

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

ＩＴ化構想立案～基本計画の策定

（ＳＰ）

ＩＴ化構想立案～基本計画の策定

（ＳＰ）

開発工程

開発工程

要件確定（要件定義）＆テストケース設計

（ＳＡ/ＵC）

要件確定（要件定義）＆テストケース設計

（ＳＡ/ＵC）

ＰＧＭ設計・作成・テスト

（ＳＳ/ＰＳ/ＰＧ/ＰＴ/

ＩＴ）

ＰＧＭ設計・作成・テスト

（ＳＳ/ＰＳ/ＰＧ/ＰＴ/

ＩＴ）

機能確認・運用確認テスト（ＳＴ/ＯＴ）

機能確認・運用確認テスト（ＳＴ/ＯＴ）

システム稼働後の評価

システム稼働後の評価

▲プロジェクト計画レビュー

▲ＳＡ完了レビュー

▲ＵＣ完了レビュー

▲テスト計画

レビュー▲サービスイン承認

レビューレビュ｜

レビュ｜

▲運用要件設計レビュー ▲移管評価レビュー



10

２（１）

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



アプリオーナー ◆システム化の目的と期待効果の明確化◆ＩＴ投資の最適化◆システム化ニーズのまとめ◆開発の優先順位付け

◆システム開発への参画◆予定通りの要件確定、システムテストへの参画、ステム開発工程終了の承認◆ユーザーへのシステム提供と活用促進（利用者への教育、マニュアル作成等）

サプライヤー ◆アプリケーションシステムの企画立案◆高品質・低コストのシステム構築／運用◆最適なシステムソリューションの提案（全体最適の実現）◆ユーザビリティの向上／標準化

◆納期を遵守したシステム構築／運用◆オーナーの依頼に基づく構築／運用の実施◆予算費消状況、開発状況等のディスクローズ◆ユーザーへのサービス提供

役割・責任

11

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

１．プロセスチェックの強化を通じたＰＤＣＡサイクルの有効性の検証をする。

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

２．リスクベース・アプローチを一層強化する。

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

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

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


12

２（２）

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

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

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

２．リスクを軽減するアクションプランサービスを提供しているＡ社については、情報セキュリティ関連の外部監査を完了しているが、以下の取組みを追加して実施することにより、リスク軽減を図る。

①Ａ社のシステムセンターについての設備やセキュリティー面での実地確認②Ａ社と「データセンターの管理・情報管理に関する指針」等に対しての当社の基準に基づく契約の締結

③当社の正当な理由による実地監査の保証の確保

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


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

13

２（２）

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

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

議報告」が１０年Ｘ月に実施されている。

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

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

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


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

14

２（３）

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

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


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

保険検査マニュアル

15

２（３）



当社の対応

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

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

16

２（３）

「会計システムを含む情報システムの開発および変更計画が適切に策定される仕組みとなっているか」を冒頭で確認している。その中では、

①情報システム計画は、戦略計画と整合しているか。②会計システムと関連する情報システムとの間での機能分担等の調整は適切に行われているか。

③アウトプットの信頼性および適時性を含め、情報システムを利用する者の満足度をどのように把握しているか。

④経営から付託を受けた全社横断的な委員会を設置・審議する等して、システム開発の優先順位を適切に設定しているか。

⑤情報システム計画は、取締役会での決議または報告および監査役（会）または監査委員会への報告がなされているか。

を求めている。



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

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

17

２（４）

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

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


サンプルで２５件の

プロジェクトを任意抽出

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

18

２（４）

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

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


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

ＰＡ１００ 2011/7/26

ＰＡ１０００２ 2010/5/15

ＰＡ１０００３ 2010/5/15

ＰＢ２００３４ 2011/7/26

サンプルで２５件の

プロジェクトを任意抽出

19

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

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

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

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

20


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

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

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

進行中のプロジェクトに対してユーザー主体のシステム開発が整斉と行われ有効なシステムがコスト・納期・品質を守るのみならず、

所期の開発効果を発揮するシステムを開発ができるかを確認するシステム監査

21

３

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

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

⑤情報システムの外部委託に関するリスク

④情報システムのセキュリティに関するリスク

③情報システムの運用に関するリスク

情報システムのリスク


②情報システムの開発に関するリスク

①情報システムの統制環境（経営者の情報システムに対する関与態勢等）

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


22

３

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

⑤情報システムの外部委託に関するリスク

④情報システムのセキュリティに関するリスク

③情報システムの運用に関するリスク



②情報システムの開発に関するリスク

①情報システムの統制環境（経営者の情報システムに対する関与態勢等）

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

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



23

３

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

システム開発の「コスト」に関するリスクシステム開発の「コスト」に関するリスク

システム開発の「品質」に関するリスクシステム開発の「品質」に関するリスク

システム開発の「納期」に関するリスクシステム開発の「納期」に関するリスク

システム開発のリスク

システム開発のリスク

1990年代の前半の、米国

企業でのＩＴプロジェクトの成功率は１６．７％（注）

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

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



24

２

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

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

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

①システム開発の統合マネジメント（プロジェクトの全体管理）

ＰＭＢＯＫの管理項目

ＰＭＢＯＫの管理項目

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

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

⑧調達マネジメント（プロジェクトに関する調達管理）

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

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

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

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

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


25

３


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


①システム開発の全体計画スケジュール（プロジェクトのマスタープラン等）

・システム開発のマスタースケジュール

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

・システム開発のプロジェクト体制図

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

・外部委託会社からの報告要領がわかる資料

④システム開発の統合マネジメント(プロジェクト全体の管理）上の現時点での課題（開発主体（アプリオーナー）等の認識）

・プロジェクト推進に関わる各種会議体一覧表

内部監査の着眼点主要な監査資料等

26

３




①システムの基本要件定義の完了状況（システム化の範囲の明確化状況）、その成果物の文書化状況とアプリオーナーの承認状況

・システム構成の全体がわかる資料

②各サブシステムの重要な制約事項の明確化状況（アプリオーナーの承認状況）

・機能の中で「重要な制約事項」（実施しない機能を含む）を明示した資料

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

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

・他社システム等との機能比較表等

⑤スコープマネジメント上の現時点での課題


27

３




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

・スケジュール実績対比表（ＷＢＳ作業予定実績対比表等）

②進捗管理における計量方法（ステップ数、プログラム数、要件変更項目数、テスト項目数等）と定義・活用の状況

・各開発工程（要件定義局面、システム設計局面等）での進捗管理要領を定義した資料

③アプリオーナー側での準備状況を把握・報告するスキームの整備・運用状況

・スケジュール実績対比表

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


28

３


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

・開発費、運用費の算出根拠がわかる資料

②システム移行コストや、研修導入コスト等直接開発コスト以外のコストの見積もり状況

・間接費用（研修導入コスト）の算出根拠がわかる資料

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

・ＮＰＶ計画上の効果発現のための具体的なアクションプラン

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




29

３




①各サブシステムの品質管理に関する評価基準の設定状況

②各開発フェーズでのシステム開発レビューの管理・運営状況

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

・運用レビュー資料

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

・外部委託会社が実施する品質管理基準を示す資料等･自社情報システム部門が実施する品質管理基準を示す資料等

・公式のシステム開発レビュー資料


30

３




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

・開発体制図

②システムの工程毎の要員計画表（積上表）の整備状況

・開発要員積み上げ図

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

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


31

３


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

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

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

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


・各会議体議事録



32

３




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

・外部委託契約書

②外部委託会社の決定に至るまでのＲＦＰの提示、先方提示の「提案書」内容の比較検討状況

・外部委託会社からの提案書・上記提案を比較した資料

③システム開発に伴う各種物理資源（テスト用コンピュータ等）の調達スケジュール等の管理状況

④調達マネジメント上の現時点での課題

（注）ＲＦＰ（Request For Proposal）:情報システム開発にあたりシステム開発の概要を複数の開発外部委託会社に正式に伝え、開発費用等の見積もりや開発体制等についての先方の提案情報を入手する手続きの資料


33

３




①各サブシステムのシステム開発に伴うリスクの認識・明示の状況

・システム開発リスク管理表等

②システム運用上のリスクの認識・明示状況・システム運用リスク管理表等

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

ｂ．情報の網羅性を保証する仕組み・情報の網羅性を保証する仕組みの資料

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

ｄ.情報の正確性をモニタリング等によって確認する仕組み等

④当該システムのサーバ群の「財務諸表に関連するサーバ」としての管理状況（プログラム変更管理、特権IDの管理サーバ運用、サーババッチ管理、バックアップ運用等）

・当該システムを運用するサーバの管理状況を示す資料

⑤コンティンジェンシー・プランの基本的な考え方ならびにプランの作成予定

・「コンティンジェンシー・プランの基本的な考え方」を示す資料

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


34

３


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

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

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

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

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


35

３


①今回の開発に際しては、「フィージビリティスタディー」によって、大部分のＳＡ（基本要件定義）が実施されていることを、「プロセスフロー」等の基本要件記述書類で確認をした。またその中での残存課題や重要な制約事項も明確になっているので、ＸＸ年ＸＸ月末に予定されているＳＡレビューで基本要件の確定をし、その後の要件変更についてはルールを定め厳重に管理することが求められる。

②フィージビリティスタディーで、作成した事務・システムフロー等に関して、営業部門、業務部門のウォークスルーは監査時点では、まだ実施ができていないとのことであるが、例外処理を含めて現行の事務処理との親和性があるかを、ＳＡレビューの前に確認しておく必要がある。

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

フィージビリティスタディー：大規模なシステム開発を計画する時に、そのシステム開発の実現可能性を、当該プロジェクトの基本要件、ハードウェア基本形態、開発・運用コスト概要、開発体制等について、コンサルファームやシステム開発の専門企業に外部委託をして、検討すること。




36

３




①フィージビリティスタディーの際に、基本要件の検討項目タスクを詳細にブレークダウンして、外部委託会社（以下：Ａ社）が日次単位の「スケジュール実績対比表」を作成し、詳細に管理していることを確認した。ＵＩ工程以降の実開発工程における進捗管理についても、基本的には同様な進捗管理をしていくことで良いが、以下の留意点について検討をして、ＳＡ工程終了までに、ＰＭＯで「進捗管理の具体的方法」について決定し、プロジェクトメンバーに徹底をすることが必要である。

ＵＩ工程は、アプリオーナー部門、情報システム部門が実際に作業に関与することもあって、進捗は体感でも把握ができるが、ＳＳ（システム設計）～ＳＴ（Ａ社によるシステムテスト）の期間については、期間が１０ヵ月と長い中で、アプリオーナー部門・情報システム部門は殆ど作業に関与しないフェーズになるので、的確な数値に基づく進捗報告がないと状況が全く把握できない。従って、進捗管理における計量方法（ステップ数、プログラム数、要件変更項目数、テスト項目数等）を明確に定義して、Ａ社等から報告をもらうことが重要である。

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


37

３




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

②Ａ社と「請負契約」を一括して締結することについては、以下の観点から妥当であると考える。

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

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


38

３




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

ａ．Ａ社内の品質管理部門による監査のタイミングならびに実施内容を確認し、情報システム部門の開発品質管理部での評価を実施することが必要である。

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


39

３




①開発工程毎の要員計画については、以下の課題がありＳＡ工程終了までには検討が必要である。

ａ．アプリオーナー部門の工数・第Ⅱ期のフィージビリティスタディーとの重なりの中で、ＸＸ年Ｘ月～Ｘ月やＸＸ年Ｘ月～Ｘ月にはオーナー工数として３人月と大きくなるが、この工数を確保することが必要になる。・第Ⅱ期フィージビリティの要員をネームドで確保することが必要と思料する。新機能が多いこと、ならびに非常に重要な機能部分の検討なので、当該実務に精通した要員の確保が重要と考える。

ｂ．情報システム部門の工数・Ⅰ期ならびにⅡ期の重なりの中で、ＸＸ年Ｘ月～ＸＸ年Ｘ月は、４人月～４．７人月の工数が予定されている。これに対してネームドで要員を確保しておく必要がある。また本要員計画が「ＸＸ年度システム開発計画」上でオーソライズされていることが重要である。

ｃ．Ａ社の工数・Ａ社のフィージビリティスタディーのリーダーは第Ⅰ期のプロジェクトマネージャーとは異なる要員をアサインしてもらう必要がある。第Ⅰ期と同様に、第Ⅱ期のフィージビリティスタディーのリーダーがそのまま第Ⅱ期のプロジェクトマネージャーになることが望ましく、第Ⅰ期と第Ⅱ期の重なりを考えると、異なる要員であることが必須である。


40

３




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


41

３




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

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


42

３


①ＳＡ工程完了後に、ＰＭＯメンバー、プロジェクトマネージャーで「リスク整理」を行い、「事前のリスク軽減策の策定、コンティンジェンシープランやバックアッププラン」の作成に繋げることが望まれる。

②当システムで使用する「ユーザＩＤ」ならびにパスワードに関しても、フィージビリティスタディーで十分に検討していることが窺われた。今後のＵＩ工程の中で、「パスワード変更サイクル」や「お客様ユーザＩＤの登録方法」の検討課題を早期に決定することを期待したい。

③データの網羅性をシステム的に保証するため、件数確認に加えて重要な金額確認は、各システムのインターフェース時に自動的に必ず実施すべきである。（件数と金額の合計チェック：データヘッダーにセットし、後続システムでカウントチェックをする等。）

④ＢＣＰ（Business Continuity Plan 業務継続計画）については、「新システム業務設計書（ＢＣＰ検討）」によって精緻に検討がされ、多摩・千葉両システムセンターに二重化して構築し、有事のみならずシステム障害時におけるＢＣＰ体制を実施することを確認した。新システムは、当社計上システム等各サブシステムが有機的に連結されているので、当該システムの停止リスクを分析し、ＵＩ時には「コンティンジェンシープラン」や「バックアッププラン」を作成し、ＢＣＰとして文書化しておくことが必要である。




43

３

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

■システム開発の予防的内部監査の経験筆者は、この情報システム監査を（08年度～10年度で）、「東京海上日動の

情報システム開発」に対して１３例（開発外部委託費百億台のシステム１件、十億台のシステム７件、１億～９億のシステム５件）経験をしてきた。この経験から、本システム監査の実施上の留意点を以下掲げることとする。

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


44

３

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

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

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

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



45

３

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

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

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

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



46

３

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

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

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

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



47

３


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

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



48

３


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

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



49

３


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

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



50

３


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

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

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



51

３


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

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



52

３


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



53

３


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



54

３


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

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



55

３


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

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



56

３


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

①ユーザーＩＤとパスワード②入力データの正確性を保証する上位者等による「承認」の仕組み③システムの正確性を保証する「プルーフリスト」の出力と定期的な

モニタリング体制の整備状況（予定）④データの網羅性をシステム的に保証するため、件数確認に加えて重

要な金額確認は、各システムのインターフェース時に自動的に必ず実施すべきである。（件数と金額の合計チェック：データヘッダーにセットし、後続システムでカウントチェックをする等。）



57

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

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

３

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


58

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

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

３

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


59

４おわりに

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

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

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

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

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

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

60

ご清聴ありがとうございました。

本日の講演が、

「ユーザー主体のシステム開発」の推進

に少しでもご参考になればと

思っております。

本資料・本講演は講演者自身の見解であり、

講演者の所属する組織の意見を代表するものではありません。

Documents

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