プロジェクト監査

プロジェクト監査とはプロジェクトの推進側とは異なる立場の第三者が、プロジェクトに対して様々な観点から問題がないかを確認し、プロジェクトの目標達成に向けてプロジェクトのマネジメントおよび、プロジェクトの推進・運営を適正化する取り組みです。

プロジェクト監査により点検、評価する観点について一例をあげます。

1. プロジェクト計画の妥当性
2. プロジェクトマネジメントの適正性（事実を可視化し、真実を捉え対処できているか）
3. プロジェクトの人的リソースのアサインの適正性
4. プロジェクトリスクの可視化、報告から意思決定までのコントロールの適正性
5. 上流、開発、テストの各段階での成果物、品質評価の適正性
6. 移行から本稼働、運用保守の計画、運営、実行判断の適正性

など、プロジェクトのマネジメントやプロジェクトの運営がプロジェクト目的の達成に向けてQCDを守りながら適切に推進されていることを、第三者の視点から点検、評価、提言（是正）する取り組みになります。

プロジェクトの計画段階、開発工程の進行中、本稼働前後に監査を行うことで問題点を早期発見し、大トラブルを未然に防ぐこと、そしてプロジェクトの目的を達成するようにプロジェクトの推進を適正化することがプロジェクト監査の役割であり、目的となります。
一方、プロジェクト監査は企業の中に閉じた取り組みに留まらず、大規模プロジェクトでは投資家をはじめとするステークホルダーに対して、投資に見合う目的達成に向けて適切にマネジメントされていることを説明、情報開示する役割を担うこともあります。

一例としてあげた観点について、どのような確認を行うか更に例示します。
　

1. プロジェクト計画の妥当性
   過去実績などに照らして計画に無理はないか、また、多少の無理を承知で実行する場合にはリスク対策やコンティンジェンシープランが施策化され、プロジェクト関係者で合意が取れているかを確認します。
2. プロジェクトマネジメントの適正性（事実を可視化し、真実を捉え対処できているか）
   計画に対して進捗が適切に可視化され、課題や問題があれば曖昧にすることなく対策や対応方針を決定し、実行完了まで適切にコントロールされているかを確認します。また、関連当事者（ステークホルダー、協力会社、プロジェクトメンバなど）とのコミュニケーションが適切に実行され、課題や問題が顕在化する取り組みがなされていることは重要な確認点となります。
3. 人的リソースのアサインの適正性
   対象プロジェクトの規模、新技術、開発ツール/技法、パッケージ/製品など、プロジェクトマネージャーから主要メンバー（チームリーダクラス）、協力会社まで含め経験や実績があり、適切にそのノウハウや経験値が活用できていることを確認します。
   経験がない場合にはプロトタイプによる検証・評価を行ったり、外部の経験者からのサポートを受けたりするなど、対策が適切に実施されているかも確認する必要があります。要件定義や設計、テスト仕様の策定、業務運用設計などにおいては、その確からしさを評価できずギャップを内在したままに本稼働させて大トラブルになるケースもあり、対象業務に関する経験や知見なども確認しておく必要があります。
4. プロジェクトリスクの可視化、報告から意思決定までのコントロールの適正性
   プロジェクトの企画・計画段階からリスク棚卸、リスク対策の検討を行うことが求められますが、対策が適切に施策化されプロジェクトにおいても施策がコントロールされていることを確認します。対策・施策でリスクが十分に回避、抑止できない場合にはコンティンジェンシープラン（代替回避策やExitプランなど）をプロジェクト関係者で合意し、それが適切に監視・評価されていることを確認します。
5. 上流、開発、テストの各段階での成果物、品質評価の適正性
   成果物のドキュメント作成標準（記載レベルや記載内容）、作成ボリューム、更には品質評価指標などを計画段階から設定し、進捗管理できているかを確認します。成果物の作成レベルや品質問題がある場合には、その対策が確実に検討され対策化されていることも確認しなければなりません。これらの作成標準や生産性、品質基準などはIPA（独立行政法人情報処理推進機構）やSAAJ（特定非営利活動法人　日本システム監査人協会）など第三者機関が蓄積、公開している情報がありますので参考にするとよいでしょう。
6. 移行から本稼働、運用保守の計画、運営、実行判断の適正性
   本稼働判定が総合テスト、UAT（ユーザ受入テスト）を通じて、確実に実施されプロジェクト関係者の合意に基づいて本稼働されるか、或いは本稼働されたかを確認します。プロジェクト特性（要件定義、設計段階からの運用上の対応事項、総合テストやUATで判明した運用上の考慮点など）が運用保守体制、プロセスに反映できているか、また本稼働初期のリスク体制が適切に確保できているかなども確認する必要があります。

　プロジェクト監査は、プロジェクト推進におけるリスクを検知した際に実施することが通例になりますが、原則的にはプロジェクトの企画・計画段階からコントロールして行く方が、問題が顕在化してからの対応よりも圧倒的にその対策にかかる時間と投下資源は少なく済む、という考え方があります。
　大規模プロジェクトやハイリスクで難易度の高いプロジェクトは、プロジェクト監査の対象になることが多いですが、ITガバナンスの観点では必ずしも第三者監査人がプロジェクト監査であります、というやり方が全てではありません。
　大切なことは、全てのプロジェクトについてリスクや難易度をプロジェクト計画段階から点検、評価し、そのリスクに対してどの観点で何をいつ評価するかを決定（計画）し、点検・評価する（されている）ことを全社でコントロールすることです。
　先ず、プロジェクト開始前のリスク点検を規模や難易度、実績有無などで評価し、リスク対策をそのリスクの大きさのレベルに応じた組織階層（チームリーダ、部署責任者、部門役員、経営会議など）でコントロールします。そして定点監視ポイントを予め設定し、先ずはプロジェクトマネージャーによる自己点検からスタートし、これを監査の階層や監査者が点検、評価し改善や是正を行うプロセスを繰り返し、リスクが極小化或いは解消されるまで実施することが求められます。こうした取り組みを通じて、企業内に監査チームを育成して行くことも可能となります。
　こうした能力を組織内に導入することはとても時間と労力のかかることではありますが、組織、企業、更には企業グループのITを強化して行く有効な手段ですので、ITガバナンスの検討時に考えておくと良いでしょう。