ソフト開発監査の監査当日（１２）監査報告書の作成（後半）
監査の概要では監査の目的とその結果を先頭に明記する
この記事では、監査報告書の概要、是正要求、コメントの各々の欄の書き方について、注意点を紹介します。
先頭ページにある監査の概要には、監査の日時や場所等の今回の監査報告書の対象を特定できる情報を記載し、その後にサマリーとして監査の結果を書きます。監査の結果には、監査に合格したのか不合格だったのか何かの条件付で合格なのかを明記します。監査を受審した相手の組織の人にとっては監査の合否が真っ先に知りたい事なので、これを最初に明確に伝えます。
その上で、監査で見つかった問題点の中に改善を要求した改善要望事項が有る場合には、改善計画の作成と提出をお願いする文言を続けておきます。
良かった点は必ず１つは見つけて書いておく
サマリーの次には、監査を通して見つけた相手の組織の良かった点を具体的に書き出します。良い点がなかなか見当たらない場合もありますが、グータラ親父は必ず１つは何か良い点を見つけてあげて書き出すように努力してきました。
ソフト監査の目的の中で自社にとって最も大切なのは、監査先の組織のソフト開発力の改善です。そしてその作業は監査先の組織の担当者達がその気にならなければ、決して効果は出ません。自分達の問題点を指摘されるのは誰にとっても気が重い物です。監査報告書に問題点の指摘ばかりが並んでいては対策を考えようという気持ちも薄れてしまいます。人間は、自分の事を否定されると反発し肯定されると喜ぶというのは、どの国に行っても同じです。
そこで、監査報告書の冒頭ではまず監査で見出しが良い点を取り上げ、これを褒めると同時に相手に敬意を表しますそうする事でまずは監査報告を聞く相手の緊張を解き、その後に続く問題点の指摘について客観的に理解してもらえる雰囲気を作りだします。
是正要求事項は一覧形式で具体的に書く
２ページ目からは是正要求事項を表に書き出します。ソフトの開発能力の改善を目的とした監査ではこのページが一番大切です。監査先の組織に改善をしてもらいたい項目をできるだけ具体的に書き出して、相手の組織の中で効果的な対策を検討して貰う事を依頼します。
是正要求事項もその次のコメントも、監査先の組織で対策の検討が行われる時には、監査の場に居なかった人も参加されます。それらの人達に、何が問題点なのかを正しく理解してもらうためには、具体的で簡潔な説明が一番良いです。具体的に書けていないと問題点が誤解されてしまう事もあって、そうなってしまうと折角考えて貰った対策が、ピント外れな物になってしまいます。
是正要求事項では、まずその問題点をチェックリストのどの項目の確認で気づいたのかを伝えるために、チェックリスト番号を書きます。次に、どんな問題点があったのか、それはどんな資料を見て問題点と判断したのか、あるいは、ヒアリングのどんな回答内容から問題点と判断したのかを書きます。
問題点はなぜ不味いのかの説明を忘れずに
その次に、その問題点があるとどんな事が不味いのかの説明を加えます。ここまで説明して初めて、取り上げた問題点をなぜ問題点と考えているのかが伝わります。また、できれば対策の案や方向性について何等かの示唆ができるようならば、それも書いておきます。
何度も繰り返していますが、ソフト開発監査は指摘をする事が目的ではなくて、ソフト開発技量を高めて貰う事が目的です。ですので、相手の組織が実施できてさらには継続できるような対策案ができあがり、その対策案が実際に実行される事が一番大切です。
組織としての業務分担の垣根を越えてしまうような問題や、対策費用が高額で調達するのが難しそうおな問題等、プロジェクト単独では解決が難しそうな問題は、いくら対策を要求しても効果的な対策が実施される可能性が低いです。グータラ親父は、そのような項目については、問題点があってもあえて報告書に書かないという事も、よくありました。
コメントは相手の組織にとっての参考情報
是正要求事項の次はコメントの一覧表を作成します。コメントは、是正要求を依頼する程ではないけれども、相手先の組織で対策をすれば、ソフトウエア開発技量の改善に役だつのではないかと思われる問題点をお伝えします、というような項目です。
ですので、コメントに書いてある内容については、対策を検討して実施するのかどうかは、相手先の組織に委ねます。 ソフト開発監査としては、気が付いた項目なのでコメントとして残しておきますね、というレベルの物です。
ただし、コメントも場合によっては相手先の組織で対策の検討を実施されるかも知れませんので、書き方についての注意点は、是正要求事項と同じでです。問題点をできるだけ具体的にかつ簡素に書き出して、その問題点の何が問題なのかがうまく伝わるように注意します。
日本語と英語か現地語を併記して
各々のページの記述は、まずは日本語で書き出して内容を吟味した後に、英語なり現地語の翻訳を併記する方法で作成しました。監査報告書は、監査先に提出して問題点の対策の検討に使ってもらうのが第一目的なので、英語か現地語は必須です。同時に、社内に向けては相手先のソフト開発力がどんな状態だったのか、どんな点に弱みがあるので開発を進める上で注意しなければいけないか、を伝えるという側面もあります。ですので、日本語の併記も残しておきました。
監査報告書ができたらクロージング会議で内容を説明します
監査の最後はクロージング会議です。監査報告書を使って、監査で見つけた問題点を説明し、相手のエンジニアやリーダや管理職に問題点がある事を納得してもらい、対策を進めてもらいます。それでは、次の記事ではクロージング会議を行う上でのポイントについて紹介しましょう。