ソフト開発監査の監査当日（１３）クロージング会議とフォローアップ
ソフト監査の当日の作業はクロージング会議で終わる
ここまでの記事で、ソフト開発監査のオープニング、チェックリストを使った詳細確認、監査報告書作成についてと監査当日の作業を紹介してきました。最後はいよいよ、監査報告書を使ったクロージング会議です。
クロージング会議は、監査の結果を監査先の組織に伝えるのが目的ですので、ソフトウエア開発監査に対応して下さった人のうち、リーダクラスの人は原則として全員出席して貰います。 また、できれば監査対象組織の部門のトップの方にも同席して貰うのが良いで。
クロージングの会議では会議の冒頭でまず、今回のソフトウエア開発監査に対応してくれた事に対する謝意を述べます。監査のために、監査対象の組織の人達は本来の開発や管理の業務の手を止めて、監査のために時間を使ってくれていますので、その事に対する謝辞を真っ先に伝えておきます。
クロージング会議は監査で見つけた問題点の認識合わせの場
クロージング会議では監査結果をまとめた報告書の内容を説明しますが、その内容は会議の段階ではまだ原稿であり、報告書の記載の内容に間違いがあれば会議の場で指摘してもらえばその場で修正する。という事も伝えておきます。クロージング会議は一報的な報告書の説明の場ではなく、報告書の内容について双方の認識を合わせる場だからです。
是正要求事項については対策を実施してもらう
なお、ソフト開発監査で気づいた問題点は、是正要求事項とコメントの２種類の分類して報告するので、是正要求事項については監査対象組織で対策を考えて、対策の計画書を提出してもらう、という事もクロージング会議の最初で再度伝えておきます。
これらのクロージング会議の進め方についての説明をした後は、作成した監査報告書のページを前から順に、監査概要のサマリーや良い点、是正要求事項、コメント について、順次説明していきます。
報告書の説明が終わったら、報告書に書かれているで問題無いか、当方から指摘している問題点について、異論はないかを再度確認して、出席者が合意できている事を確認します。 そして確認がとれた報告書の電子ファイルを、何らかの方法で監査対象組織の責任者の方に渡して、是正要求事項に対する対策の検討をお願いします。
ここまでくれば、ソフト開発監査の現地での作業は終了です。 クロージング会議の終了を宣言して、当日の作業を終えます。
現地での監査を終えたらフォローアップです
現地へ出向いての監査の確認作業を終えると、ソフト開発監査の作業の量としては８割近くは終了しています。ただし、監査の目的から考えると、現地に出向いての監査作業は折り返し地点に相当します。
現地での確認作業で判った事は、監査先の組織にソフト開発能力に関する問題点が何件くらい存在していて、その具体的な内容がどんな物なのか、という事です。これらの問題点を元に、監査先組織のソフト開発能力の良否を判断したり、改善対策を実施してソフト開発能力を改善したりしりする事が、ソフト開発監査の目的ですので、ここからの作業も大切です。
とはいえ、監査先の組織のソフト開発能力の善し悪しの判断は割と少ない作業で完了できます。絶対的な採点をする訳ではなく、発注しても問題無いかどうかの見極めをするだけなので、これまでの他社のソフト開発監査の結果と照らし合わせて、大きく劣っていなければ大丈夫と判断しても良いでしょう。
ソフト開発能力の良し悪しは変動幅が大きいので正確に測れない
そんな簡単な判断で良いのか？ と心配される方もおられるでしょうが、実際のところソフト開発能力を正確に測定する方法も無いので、どんな方法で判断しても大して違いはでません。 なにしろ、ソフト開発の全ての作業は人の頭の中で行われる思考の産物です、そして人の思考の能力は、例え同じ人であってもその時の環境や感情や情緒によって大きく変動します。
昨日徹夜した次の日はいつもの半分程度の思考力しか無いですよね。それほど振れ幅の大きな人間の思考能力の総和が組織のソフト開発能力になるなので、そもそも正確に測れる物ではありません。また例え測れたとしても１時間もすればその結果が変わって行きます。という事なので、大雑把な判断しかしようが無いのです。
ソフト開発能力の改善はしっかりと対応する
もう一つのソフト開発能力の改善は、もう少ししっかりと対応をする事ができます。こちらは、まずは監査先の組織から提出される対策計画書の確認から始まります。監査当日のクロージング会議では、是正要求事項に対して対策の内容を検討して、対策計画書を提出する様に依頼してあります。
この対策計画書が送らてきたら、その内容を注意深く読んで指摘していた問題点を監査対象の組織がちゃんと理解してくれているか、その問題点について効果のある対策を計画してくれているかを確認します。
監査の時には、監査に対応してくれた開発やテスト部門のリーダや設計者と議論もして、問題点についての認識は合っているはずです。でも、実際に対策案を検討する段階になって、別の人に引き継がれている場合もよく有ります。その様な場合には、時にはこちらの指摘した問題点を誤認してしまい、ポイントの外れて対策案を提案してくる場合もあります。ですので、まずは対策計画書を注意深く確認する事が大切です。
ここで誤認があれば、改めてメールや電話会議で、問題点について相手に説明し直して、問題点についての認識を合わせた上で、対策を再度考えて貰います。
対策案は続ける事が可能で効果が出せそうか
誤認が無ければ、次は対策案が効果を出せそうかどうか、という観点で内容を確認します。その時に注意するのが、実行できそうかと続けられそうかの２つの点です。言い方を変えると、ソフト開発監査を早く終わらせたくて理想論に近いような対策が書かれていないか？ という見方ですね。
いくら良い計画書を貰っても、実行が難しかったり続けるための負担が大き過ぎたりしては、結局その対策は実施されなくなって、ソフト開発能力の改善という目的は達席できません。努力すれば続けられて、ソフト開発能力の改善に本当に結びつくような対策になっている事が大切です。
提出された対策計画書を上記のような観点で確認すると、やはり何か所か修正してもらった方が良い点が見えてきます。そういう時には、計画書に書かれている内容をベースに、メールや電話会議で対策内容の検討を行って、改訂して貰う作業が続きます。グータラ親父の経験では、２～３回メールや電話による改訂を行って対策計画として仕上がる事が多かったです。
対策書ができたら最後は対策を実施した事の確認
対策計画が出来上がれば、最後は監査先の組織がその対策内容を実施してくれてた事の確認です。対策計画が出来上がってから３か月程度が過ぎた時点で、対策内容の実施状況を何等かの資料（確証）を元に確認して、無事に実施されている事が確認できれば、これでソフト開発監査の一連の作業が完了です。
ソフトウエア開発監査のイメージは掴めましたか？
ここまでの記事で、グータラ親父のやってきてソフト開発監査について、事前の準備と監査当日の作業、監査後のフォローアップについて紹介してきました。ソフト開発監査がどの様なものかイメージは掴めましたでしょうか。
この次の記事からは、ソフト開発監査でグータラ親父が使っていたチェックリストの中味を見ながら、もう少しだけ詳しく紹介しようと思います。