ソフト開発監査の監査当日（２）オープニング会議
オープニング会議で監査の進め方と時間配分をまず再確認
何事も始めが肝心ですがソフト開発監査では世間一般には無い監査を行う事になるので、監査を受ける相手に対する最初の説明は特に大切になってきます。監査を受ける側の相手の会社のリーダや担当者にしてみれば、ソフト開発監査ってどんな事が聞かれて、監査の結果として自分達の仕事にどんな影響があるのだろう？ と心配な点もあると思います。
監査を 3現主義で進めるために開発やテストの実務の現場に入り込んでいくには、リーダや担当者の協力が必要不可欠ですので、最初の時点で彼らの持つ心配点や疑問点を解決しておく事で監査がスムーズに進むようになります。 ですので、オープニング会議では監査の目的や進め方について、丁寧に説明しておくのが良いです。
そのためオープニング会議には、今回の監査で対応してくれる人には全員出席してもらえるように要請しておきます。もちろん、監査が進むに従って最初に予定されていなかったエンジニアを監査の場に来てもらう事もありますが、少なくともリーダクラスの人は全員、オープニング会議に出て貰うようにします。
まずは監査の目的をしっかりと説明
会議の冒頭では、今回のソフト開発監査の目的を説明します。ソフト開発監査の目的はソフト開発についての、①力量の把握 ②力量の改善 ③不具合対策版ソフトの品質確認 の３つに大きく分かれます。今回の監査がどれを目的にしているのかをまず紹介します。
次に、監査の進め方について、監査計画書の日程表を元にざっと紹介します。最初に相手先の会社による開発プロセスやソフト品質保証の活動についての紹介を受け、その後監査チェックリストに従った確認を行い、最後にクロージング会議で監査の結果を報告する、という監査当日の日程を紹介します。
クロージング会議についても説明を忘れずに
クロージング会議では、監査の報告書を元に監査結果を報告するのですが、報告書の内容に異議がある場合にはその会議で申し立ててくれれば、内容を修正するという事も、最初に伝えておいくのが良いです。
監査の報告書には監査の指摘事項が含まれていて、指摘事項は是正要求事項とコメントの２種類がある事も、この機会に伝えておきます。是正要求事項は１ヶ月先を目処に是正計画を提出してもらい、その２か月後には是正計画の実施状況を確認するフォローアップが有る事も、オープニング会議で説明しておきます。コメントについては、是正計画の提出は必要無いので、今後の相手先会社のソフト開発能力の改善に役だててもらえば良いと伝える事にしています。
以上のような事を、オープニング会議でざっと紹介した後に、実際の監査作業に移ります。
まずは相手先による開発プロセスの紹介を受けて全体を把握する
オープニング会議が終わるといよいよ実際の監査に入ります。まず最初は、相手先の会社によるソフト開発の組織や開発プロセスについての紹介を受けます。相手の会社のソフト開発の概要については、事前に入手した資料を元に予習をしてきてはいますが、改めて相手の会社から具体的な内容も含めた説明をしてもらいます。
製品群や組織や開発拠点や開発プロセスについて、相手の説明を聞きながら、以下のような点に注意して、場合によっては具体的な社内資料等も見せて貰いながら、相手のソフト開発プロセスを理解していきます。
- ソフト開発とその支援を行っている組織と事務所の所在
- テストを行う部門がソフト開発部門と独立して存在するかどうか
- ソフトエンジニアとテストエンジニアの人数はどの程度か
- ソフトの品質保証を行う体制はどうなっているか、ソフトウエア品質保証部門があるのか
- ソフトのリリースの判定者（責任者）は誰になっているか
- ソフトの技術を改善する組織は有るか（アーキテクトチームやシニアエンジニアチーム）
- ソフト開発プロセスを改善する組織はあるか（CMMIで言うところのSEPG）
- ソフトの品質を管理するチームが手法があるか（CMMIで言う所のSQA)
- ソフトの品質を評価するメトリクス（評価指標）を持っているか
判りにくい所は３現主義で現物や現実を確認しながら
相手の担当者による説明を聞いているだけでは、なかなか具体的なイメージが湧きません、その様な時には、説明してもらった内容について１歩踏み込んで具体的な事例を見せてもらうと、判り易くなります。例えばテスト部門がソフト開発部門とは独立して存在するという説明があった時には、「テスト部門にはどんなタイミングや方法でテストの依頼が発行されるのか？」、とか、「テスト部門でのテストの結果はどうやって開発部門にフィードバックされるのか？」、というような少し具体的な活動を質問すると、実態が見えてきます。
具体的な状況まで入り込んで話を聞いていくと、この段階で組織やプロセスに関する問題点が見えて来る事も良くあります。どの会社でも、完璧なソフト開発プロセスなんて出来ていないので、不十分な点は必ずあります。問題点が見えてきた時には、具体的な資料をできるだけ見せてもらい、その資料を元にどこに問題点があるのか、その問題が引き起こすリスクは何なのかを相手に説明し、問題点がある事を相手にも理解してもらいます。
その上で、その場では問題点として手元の資料に記録するに留めます。その内容を是正要求事項とするかコメントとするか特に記録の残さないのかは、最後の報告書の作成時点で判断します。これは、この後の監査チェックリストを使った確認作業でも同じです。是正要求事項とするかコメントとするかは、監査の最後に全体を見返りながら決めていきます。
相手先による紹介が終わればいよよいよ監査チェックリストを使った監査
相手先の会社による紹介が終われば、いよいよソフト監査チェックリストを使った監査の本番です。監査の当日に、ソフト監査チェックリストのどの項目について確認をするのかは、ソフト監査実務・事前準備その３：チェックリストの事前記入の段階で決めてあるので、その順番に沿って確認していきます。
とはいえ、監査当日までの準備で決めておいた項目にあまり拘る必要はありません。監査当日に相手の会社から説明を聞き、またソフト監査チェックリストによる確認を進めるに従って、ここはもう少し詳しく聞きたいとか、ここは省略してもいいやとか思いつけば、実際に確認する項目を変更しても問題ありません。
おおまかに、１項目の確認には10分から15分程度掛かるので、時間の進み具合を見ながら監査チェックリストの項目を取捨選択しながら確認をしていくので良いです。また、日程表に計画していた終了時刻が来たら、チェックリストの項目が残っていてもそこで確認作業を終わっても構いません。ソフト監査チェックリストはあくまでも監査の目的を達成するためのツールです。ツールなので標準的な使い方は一応は決めてありますが、その使い方に従わないといけないという事は、全く無いのです。
チェックリストはプロセス、要求仕様、テスト、設計・実装の４部構成
グータラ親父の使っていたソフト監査チェックリストは、確認する内容によって ①開発プロセス ②要求仕様 ③テスト ④設計・実装 の4種類の EXCEL の sheet に分けてあります。実際の監査チェックリストは ソフト監査実務・チェックリストその１：開発プロセス（要件管理）以降の記事に添付してありそこで各々の項目についての説明をしていますので、興味のある方はそちらもご覧下さい。
この記事では、監査チェックリストを使った確認作業の進め方について、少し具体的に紹介していきます。監査チェックリストは EXCEL 表で、横方向に ID番号、タイトル、概要、具体的な確認項目、回答、備考 の欄が作ってあります。そして縦方向には、１行毎に１つの確認項目が書いてあり、上から順に見ていくと監査が進むような構成になっています。
監査チェクリストは ソフト監査実務・事前準備その３：チェックリストの事前記入 の段階で相手先の会社にも渡して、回答欄を記入してもらってあります。監査当日はこのチェックリストをプロジェクタで投射して、今どの項目についての確認をしているのか、出席者全員が判るようにして確認を進めると、確認作業がスムーズに進みます。
チェックリストは各項目の主旨を出席者に説明しながら確認を進める
また、ソフト監査チェックリストは予め渡してあるとはいえ、出席者が全員その内容を読んでいるとも限らないですし例え読んでいても内容を忘れている事も多いです。ですので、確認作業では項目毎に目的と具体的な確認項目の説明をまず行い、その後に相手先会社のソフト開発のルール（プロセス）の説明を受け、そのルールに従った実施状況を実際のアウトプット（確証）を見せてもらいながら作業の実施状況を確認する、という順番で進めていきます。
大切なのは、相手先会社のソフトエンジニアやテストエンジニア、あるいはマネージャが業務で実際に使っているシステムやワークシートや設計書等の作業の記録を見せてもら事です。作業記録の現物を見せてもらい、作業の流れにそって現実を説明してもらう事で初めて、実務の進め方や管理の仕方に問題があればその問題点が見えてきます。
問題点が見つかればなぜ問題なのかを内容とリスクで説明して理解を得る
問題点が見えてきた時には、その問題点の内容とリスクについて相手に説明し、問題点について相手にも理解してもらいます。その上で、その場では問題点として手元の資料に記録するに留めます。その内容を是正要求事項とするかコメントとするか特に記録の残さないのかは、最後の報告書の作成時点で判断します。これは、最初の相手先による開発プロセスの紹介の時と同じです。
それでは、ここからはグータラ親父が使っていた ①開発プロセス ②要求仕様 ③テスト ④設計・実装 の４つのチェックリストについて、もう少し詳しく監査のでの注意点を紹介していきます。ですがその前に、まずは相手からの開発組織やプロセスの紹介がありますので、この紹介を聞く時の注意点について次の記事で紹介します。