ソフト開発監査の監査当日（１１）監査報告書の作成（前半）
Warning: Undefined array key "file" in /home/qakobe/qa-kobe.com/public_html/wp-includes/media.php on line 1734
監査報告書は相手が効果的な対策を見出せるような報告を目指す
ここまでの記事ではソフト開発監査の進め方について、オープニング会議からチェックリストを使った実際の確認作業まで、監査を進める時の注意点を紹介してきました。監査チェックリストによるソフト開発力の確認が終わったら、次は監査で発見した問題点を監査先に伝えるための、監査報告書の作成です。 この記事では、監査報告書の作成についての注意点を紹介します。
ソフト開発監査の目的は、①開発委託先の選定 ②委託中の組織のソフト開発力の改善 ③不具合修正版ソフトの品質確認 のどれかです。 ①の場合には、監査をした組織が開発委託先として選定されるかどうかは未定なのですが、②と③の場合は既にソフト開発委託先として選定されています。その様な組織には、できるだけ品質の高いソフトを開発する能力を持ってもらいたいですね。
ですので監査報告書では、監査先の組織のソフト品質上の問題点を説明して、その改善策を検討してもらえるような記述にする事が大切です。ソフト開発監査をする事自体が目的では無いので、監査先組織の実務担当の人達が実際に実施できて効果のありそうな対策が見いだせる助けになるような報告とするのがベストです。
そのような観点で監査結果の報告を行うために、グータラ親父が注意していた点について紹介していきます。
まずはソフト開発監査で見つけた問題点の洗い出しと整理
チェックリストによる確認の作業が終わったら、まずは見つけた問題点を再確認して整理していきます。 チェックリストによる確認の作業中に気付いた問題点は、議事録やメモ書きとして残してあるので、それらもう一度見直しながら整理する作業です。
グータラ親父は、チェックリストを使った確認の作業の中で問題点に気付いた時には、設計書や作業手順書やテスト仕様書などの具体的な資料を見せてもらい、場合によってはホワイトボードで相手の設計者の人と内容について議論をして、それらの問題点を具体的に確認していました。そして、その時に見せてもらった資料やホワイトボードの板書はデジカメで撮影して参考資料として残しています。同時に、印刷して持参したチェックリストに問題点や気付いた事を、赤ボールペンで手書きしてメモ書きとして残しています。
これらの参考資料とメモ書きをもう一度眺めて、問題点について ①何が問題なのか ②それはどの資料を見て問題だとと判断したのか ③その問題点があると何が悪いのか ④どうすればその問題を解決できるのか を整理していきます。
問題点について監査先の担当者にも理解して貰いその対策を検討して貰うためには、特に②と③が大切です。監査先が海外の組織の場合には、特に②と③を注意深く準備しないと、こちらの考えている事が正しく伝えられません。この辺は、異文化の人と接する機会の少ない日本人の苦手とするところですので、特に注意が必要です。
一通りの整理が終わったら、次は問題点を是正要求事項とコメントと対象外の３つに分類します。是正要求事項は監査先の組織に対して対策を検討して実施して貰う項目です。コメントは対策の検討までは必要ないけれど気付いたので伝えておきますという項目です。対象外は監査報告書にも記載しない項目です。
監査報告書はテンプレートを使い日本語と英語を併記して書く
問題点の整理が終わったら、その内容を元に監査報告書を作成していく作業に取り掛かります。ソフト開発監査は、グータラ親父が勝手に作った方法なので報告書のフォーマットも特に決まってはいません。でも、問題点の整理と報告書の作成に使える時間は1時間から1時間半程度なので、報告書のテンプレートを用意しておかないと時間的にかなり苦しくなります。 ですので、グータラ親父はこのようなテンプレートを使っていました。
報告書は ①監査概要 ②是正要求事項 ③コメント の３部構成で作ってあります。この報告書は、クロージング会議で相手先の組織に報告したあと、そのま相手先に提供しますので、日本語と英語を併記しています。英語の部分は、優秀な翻訳者の人が付いてくれている場合には現地語で書いている事もあります。最近はオンラインの翻訳ツールの性能が高くなってきたので、まず日本語で書いてそれを英語や現地語に変換する事で、報告書の作成が随分楽になりました。
是正要求とコメントはあまり数が多くならないように配慮
②是正要求事項 と③コメント がソフト開発監査の主要な報告内容になりますが、そこに記載する件数はあまり多くならない様にしています。
ソフト開発監査に限らないですが、問題点の指摘があまりにも多量にあると、その対策を実施させられる方は気持ちが滅入ってしまいやる気が失せます。ソフト開発監査は実施する事が目的ではなく、相手先の組織にソフト開発力を高めてもらう事が目的なので相手のやる気が失せるようでは困ります。
ですので、相手の組織にとって効果が出せそうな問題点を数点、多くても６～７件までを取り上げてそれを是正要求事項としてそれ以外はコメントとします。 コメントも 多くて6～7件までとしてそれ以外は対象外として除外します。
そんなので良いの？ という心配される方もおられるかもしれませんが、そもそも是正要求事項やコメントが多量に見つかるような組織なら、その他にも多くの問題点が潜在しているはずなので、今回の監査だけでは不安です。まずは今回重要と思われる是正要求事項について対策を実施してもらい、改めて再監査を計画するほうが良いでしょう。
まあ、ソフトの最終テストで思いのほかバグがたくさん見つかったら、リリースを延期してバグ修正版ソフトを作りなおしてもう一度テストを実施する、というのと同じ考えかたですね。
概要と是正要求とコメントを作る時の注意点は次の記事で
次の記事で概要と是正要求とコメントを実際に書き出す時のポイントについてもう少し詳しく紹介していきましょう。