失敗しないシステム開発のためのプロジェクト監査

プロジェクト進行中に監査を行うことで問題点を早期発見でき、大トラブルを防ぐことができる。システム開発成功に役立つプロジェクト監査のポイントを具体的かつ平易に解説する。
序 章 トラブル事例・プロジェクト監査の必要性
第 1 章 プロジェクト監査とは
第 2 章 プロジェクト監査実施プロセスーー監査受託〜監査報告まで
第 3 章 企画・計画のプロジェクト監査
第 4 章 開発の監査 (1) --外部設計
第 5 章 開発の監査 (2) --実装設計〜結合テスト
第 6 章 開発の監査 (3) 総合テスト
第 7 章 サービス開始準備、効果検証
第 8 章 プロジェクトマネジメントの監査

システム開発の大きなトラブルは、終わってから振り返ると早い段階に兆候が出ていたことが少なくありません。『失敗しないシステム開発のためのプロジェクト監査』 (認定 NPO 法人日本システム監査人協会 監修、プロジェクト監査研究会 著、同文舘出版、2020 年 7 月刊) は、完了後の事後検証ではなく進行中のプロジェクトに監査を入れ、問題点を早期に発見して大トラブルを防ぐという考え方を、工程ごとの監査ポイントとして具体的かつ平易に解説する A5 判の実務書です。副題には「プロジェクトマネジメント監査のガイドライン」を掲げています。

序章と第 1〜8 章の構成、監査の受託から効果検証まで工程順に

序章でトラブル事例とプロジェクト監査の必要性を確認し、第 1 章でプロジェクト監査とは何かを定義したうえで、第 2 章は監査受託から監査報告までの実施プロセスを示します。第 3 章以降は開発の流れに沿って進み、第 3 章が企画 / 計画、第 4 章が外部設計、第 5 章が実装設計から結合テスト、第 6 章が総合テストの監査です。第 7 章はサービス開始準備と効果検証、第 8 章はプロジェクトマネジメントそのものの監査を扱います。監査人の動き方を先に押さえ、そのあと工程別の観点へ入る順序なので、監査を受ける側が何を見られるのかを知る目的でも読み進めやすい配置です。

進行中のプロジェクトを第三者が点検する難しさと価値

監査というと決算や内部統制の事後確認を思い浮かべますが、システム開発のプロジェクト監査は、動いている途中の案件に独立した目を入れる点が特徴です。難しいのは、当事者の進捗報告には楽観が混ざりやすく、遅れや品質問題が数値に表れるのは工程がかなり進んでからだという点にあります。要件定義 や外部設計の段階で決め切れていない事項は、実装や結合テストの段階で手戻りとして表面化し、その時点では修正の費用が大きく膨らんでいます。工程ごとに「この段階で確認されているべきこと」を第三者が点検する仕組みは、この時間差を埋めるためのものであり、本書の章立てが企画 / 計画から総合テストまで工程に分かれているのは、その考え方と対応しています。第 8 章が プロジェクトマネジメント の監査を独立した章として置いているのも、個々の成果物だけでなく進め方の仕組みに欠陥がないかを見る必要がある、という整理と読めます。

工程順の開発を前提にした読み方と、監査人以外の読者

章立てが外部設計、実装設計から結合テスト、総合テストと工程を順に追う形なので、工程が段階的に進む開発を念頭に置いた読み方が自然です。反復型の開発に当てる場合は、各章の観点を自分たちの反復単位に読み替える作業が読者側に残ります。監修が日本システム監査人協会であることから、監査を実施する側の読者を軸にした本と考えられますが、序章から第 2 章までの流れは、監査を受ける立場のプロジェクトマネージャーや PMO、開発を委託する発注側の情報システム部門にとっても、進捗報告を受け取るときの確認項目として機能します。章の区切りが工程名で置かれているため、設計やテストの段階区分についての基礎知識があるほうが読みやすい本です。

元が取れる読者と、開発技法そのものを学びたい人の違い

大きな開発で手戻りやスケジュールの崩れを経験し、次の案件では途中で止められる仕組みを持ちたい組織にとって、工程別の監査ポイントを手元に持てることが本書の直接的なペイオフです。監査人として案件に入る人は受託から報告までの進め方を、発注側は各工程で何を確認すべきかを、それぞれ自分の立場から使えます。一方、本書は監査の観点を整理する本であり、設計手法やテスト技法そのものを解説する本ではないため、開発スキル自体を伸ばしたい人には設計やテストの専門書が合います。監査を見る側の本である点を踏まえて手に取れば、進行中の案件に第三者の目を持ち込むための実務的な足場になります。