ソフト開発監査の事前準備（１）監査計画の説明
ソフト開発監査の実務について具体的に紹介します
これまでの記事でソフト開発監査の概要について紹介してきましたので、ここからはソフト開発監査の具体的な進め方について紹介していきます。ソフト開発監査という方法がそもそもグータラ親父が勝手にそう呼んでいるだけの独自手法なので、これが正解という物はありません。グータラ親父はこうやっていましたという紹介なので、役に立ちそうなところがあれば、皆さんがソフト開発委託先を監査する時の参考にして貰えば良いと思います。
ソフト開発監査ではまず監査について相手に説明します
ソフト開発監査は大まかには、①当日までの事前準備、②当日の現地での監査作業、③監査結果の活用（フォローアップ） の３段階に分かれます。順番に紹介していきますが、まずは①当日までの事前準備について紹介します。
ソフト開発監査の進め方は ソフト開発監査概要・方法その１ の記事でも紹介しましたように、ISO9001 の監査の手順を手本にしています。ですので、事前準備・現地での監査・監査後のフォローアップ の順に作業を進めて行きます。この記事では監査当日までに行う事前準備の内容について紹介していきます。ISO9001 の監査に慣れておられる方は、この記事は読み飛ばして次の 実務・当日の確認ポイン の記事に進んでもらっても良いと思います。
ソフト開発監査の説明と先方の了解の取り付け
ソフト開発監査というのは、グータラ親父がエイヤッと作り上げたような物なので、世間一般にはソフト開発監査という活動はありません。なのでまずは相手の会社に対してソフト開発監査というのはこんな目的でこんな事をやりますよと説明して、監査を受ける事を相手の会社に了承してもらう事から始まります。
この辺りは、ISO9001や CMMI の様に、世間一般で広く知られている手法に比べるとひと手間増える部分です。まあ、「 大雑把に言ってISO9001 の監査のソフトウエア開発版なので宜しく！」 とお願いすると大抵の会社は監査を受ける事を了解してくれます。とはいえ、何日程度の監査なのかとか、どんな事を確認されて合否の基準は何なのかとか、監査の結果不合格となったらどうなるのかとか、相手の会社の方がいろいろと疑問を持たれる事も多いです。
ソフト監査概要・目的その１ の記事でも紹介しましたように、ソフト開発監査の目的は委託先の選定、委託先の開発力改善、不具合修正版の品質確認 の３つに大きく分かれます。ですので、その時のソフト開発監査の目的に沿って監査の概要を説明すると相手の会社にも理解して頂きやすくなります。
また、資料無しにソフト開発監査を説明しても相手の会社の方も理解し難いので、次で紹介するような監査計画書の雛形を提示しながらソフト開発監査を説明する事も、説を進める上で有効です。
ソフト開発監査の計画書の提示
ソフト開発監査を相手の会社に説明して理解してもらい、相手の会社の社内で監査を受審する準備を進めて貰うためにも、まずはソフト開発監査の監査計画書を作成して、これを元に具体的な監査の進め方を説明するのが良いです。また、監査計画書を書くことで、監査の事前準備の内容も具体化されてきます。
では、ソフト開発監査の監査計画書にはどんな事を書いて、監査の事前準備としてどんな事をやっておくのが良いでしょうか。グータラ親父がこれまで使っていた監査計画書の雛形を例にしながら、紹介していきましょう。
（クリックするとpdf が開きます）
開発監査の概要
まずはソフト監査の概要として、監査の目的や監査の方法、監査の対象プロジェクト、計画日などを最初に書きます。また監査員が何人なのか、監査後のフォローアップがあるのかどうか、なども概要の部分で簡単に触れておきます。 概要の部分は箇条書きで書き出すと相手も判り易いです。
次に監査の日程表を載せます。日程表には、監査の時間割りと、各々の時間帯でどんな確認をどんな方法で行うのか、また監査を受ける側はどんな人が対応する事を想定しているのか、などを書き出していきます。この日程表は、監査当日には監査時間の管理にも使います。
最後に、監査までの事前準備として相手先に事前の提出を願いする資料や、監査当日に準備しておいて貰いたい資料や機材等を書いておきます。ここで相手の会社に要求する資料に沿って、監査を行う側（自社の事ですね）も事前の準備を進めていきます。
監査当日の大まかな作業の流れを日程表で説明する
監査を受ける側の会社にとって、監査当日にどんな事を確認されるのかが一番知りたい内容ですので、この部分を監査当日の日程表を使って判り易く伝えます。
ソフト開発監査は ISO9001 の監査の手順を参考にしていますので、監査当日の作業の流れも ISO9001 を踏襲しています。具体的には、最初にオープニング会議を行い、次に監査を受ける会社による自社の紹介を行い、その次に監査チェックリストを使った監査を実施して、最後に監査結果の報告を含むクロージング会議を行う、という順番です。
この大まかな監査の流れは、監査計画書では日程表に書き出してあります。監査チェックリストを使った監査の実施の部分は、監査計画書の例では No.3 , No4, No.5 にあたり、ここはソフト開発監査の目的に応じて内容や時間の割り付けが変わります。しかし、オープイング会議や相手の会社による自社紹介やクロージング会議は、だいたいどの監査でも実施する定型項目です。
監査日程は国内ならば基本は１日
ソフト開発監査は、国内の会社を監査する場合は基本的に１日で 9時-17時で実施する事が多いです。色々と盛りだくさんの事を確認しようとすれば、2日とか3日とかの監査を組み立てる事も可能ですが、グータラ親父は監査に使うチェックリストの項目を絞り込んで1日で終わる事を目指しています。
ソフト開発監査はあくまでも手段なので、本来の目的を達成できる範囲でできるだけコストパフォーマンスを良く実施する事が求められます。そう考えると、グータラ親父の経験では１日で監査を終える程度の監査が一番適切でした。
開発委託先の選定が目的ならば、１日監査すればだいたい相手の会社のソフト開発に関する技量が判ります。２日以上の時間を掛けても、１日の監査での判断が変わる事はあまり有りません。既に開発を委託している会社の技量改善が目的の場合も、何日もかけて多数の改善点を見つけて一気に改善に取り組んでもらうよりは、１日の監査で見つけた改善点を着実に対策してもらい、その改善が終わったらまた再度監査を実施するほうが改善の継続性の面で効果的です。不具合修正版の品質の確認が目的の監査なら、１日の監査でOKが出せないようなら、その不具合修正の開発・テストのやり直しを命じたほうが良いです。
ただし、開発委託先の技量改善を目的とした監査で、開発技術やテスト技術の具体的な内容まで踏み込んだ技術改善の指導までを行う場合には、あと１日や２日の日程を追加する場合もあります。 ただし、この追加の日程はソフト開発監査というよりは、設計やテスト技術の指導という側面が強くなります。
海外の会社を監査する場合は2.5日～3日
国内の会社を監査する場合は１日で済みますが、監査の対象が海外の会社の場合、2.5日から3日掛かりました。監査の内容は国内の会社の場合と同じなのですが、言葉と文化の壁を乗り越えるのには、やはり２～３倍の手間暇が掛かるのが実態です。
グータラ親父が一番困ったのは、ソフトの技術用語が相手の国の言葉で何と言えば良いのかとか、日本のソフトの開発やテストの現場で使われている考え方は相手の組織内での開発手法ではどれに相当するのか、というような技術文書の翻訳の基本にあたる部分です。ここが判っていないとうまく考えが伝えられません。
グータラ親父は外国語は苦手なほうなので、監査に通訳の人に同席してもらう事もありました。でも残念ながら通訳の方がおられても、その人がソフト技術に精通した方でないと技術用語の翻訳は難しいです。例えばテスト技術の議論で同値分析という言葉を使う場面では、この技術用語が正しく相手の国の言葉に翻訳されないと、こちらが伝えたい事が相手には伝わりません。そして同値分析という技術を知っている人でないと、正しい翻訳ができません。
ソフトの技術用語に精通した通訳の方の協力が得られるといいう嬉しい状況はなかなか無いので、ソフト監査の現場ではこの技術用語の壁によくぶち当たります。ではそいういう時にはどうするかというと、例えば同値分析であれば、その考え方を簡単な絵に描いてこの考え方の事だよと説明すると相手もソフト技術者なので、ああこれの事かと納得してくれる事が多いです。
外国語がイマイチでも最後は計算機言語があるさ。。。
グータラ親父は外国語力がイマイチなので、よくこんな場面に出くわしました。そのために、国内なら１日で済む作業が海外で2.5日から3日掛かったという次第です。このあたりは、監査をする人の語学力に依存するので、グータラ親父の経験はあまり参考にしないほうが良いと思います。
ただ、語学力が無いと海外のソフトウエア開発監査は実施できないのかというと、それほど心配する事はありません。ソフト開発監査の場合は、少々語学力が無くても計算機言語を知っていればなんとかなるという面があり、グータラ親父もいろいろと助かりました。
伝えたい内容をうまく説明できない場合には、最終的にはホワイトボードに C 言語で疑似コードを書いて、これの事を議論したいのです！ と言えば直ぐに伝わりました。自然言語の英語とか中国語とかは分からなくても、伝えたい内容がソフトの技術領域であれば、世界共通の計算機言語を使って伝えるという最終手段があります。