プロジェクト管理の実践的な手法として“出荷判定会議”があります。簡単に言いますと、ソフトウェア製品の出荷基準を設定し、それを満たしているかどうかを判定する会議です。基準が満たされているか否かが問われ、開発プロセスや手法について触れることはありません。

出荷判定会議の目的は、言葉通り、出荷基準を満たしているかどうかを判定することですが、出荷判定会議の真価は関係者をやる気にさせる、あるいは創意工夫にまい進させる副次効果にあります。出荷判定会議のキー・ポイントは「プロジェクト関係者が出荷判定基準を満たすことを約束して、その実現に向けて努力すること」にあります。その結果、開発現場に規律を持ち込む足がかりにすることができます。

出荷判定会議を行うに際して必要な事柄を整理すると以下の通りです。

１．出荷基準の設定

出荷判定会議に先立ち、関係者の間で出荷基準を決めておきます。

出荷基準は関係者が決める約束事です。関係者が納得できる基準にすることが大切です。関係者が十分に話し合って、ソフトウェア製品の利用者に満足してもらうために必要な項目を挙げます。例えば、次のような項目を基準に含めます。

１） 品質

ａ） テスト対象、テストの種類、テスト項目数（例：（テスト項目数／KLOC）≧０．２）、テスト実施状況
ｂ） 障害件数、障害検出率（（障害件数／テスト項目）×１００）
ｃ） モジュール/サブシステム別障害検出率、障害傾向分析
ｄ） 未解決障害件数
サブシステム毎に最近の障害検出率が０．１以下、つまり１０００項目のテストに対して１件以下の障害件数であれば品質はかなり良いと判断します。また、重症度が低いか高いかを判別し、高い障害については同類の潜在欠陥がありそうなモジュール/サブシステムを追跡します。
当然ですが、テスト網羅度も問題にします。例えば、テストを繰り返し行っているにもかかわらず、障害検出率が下がらないモジュール/サブシステムはテスト網羅度が低いことを疑います。

２） 負荷/性能

システム環境に合わせた負荷テストを行います。リアルタイムシステムであればトランザクションとレスポンスとの関係を実測し、使用に耐えるかどうかを確認します。

３） 限界

システム環境に合わせた限界テストを行います。

４） 販促資料

カタログ、販売店向け資料等の準備状況

５） 説明書

利用者説明書等の準備状況

上記の１）ａ）、ｂ）、ｄ）についてはそれぞれ判定基準値を定めます。また、２）、３）、４）、５）についてはすべての作業が完了し、成果物が揃っていることが必要です。基準値を満たし成果物が揃うまで合格としてはいけません。

２．会議メンバの選出

出荷判定会議のメンバの例は次の通りです。

会議議長 ： 事業責任者　≪出荷の最終判断を下す≫
幹事 ： 品質管理部門責任者
≪議長を補佐し、会議運営の実行責任を負う。開発統計データの集計と会議の準備≫
実施担当 ： 開発部門、営業部門の責任者　≪幹事の指示に従い、状況を報告書にまとめる≫

３．計測技術の浸透

出荷判定会議では、各部門の業務成果をデータとして集計し、データを分析し、評価データとして加工する必要があります。計測は見えない状況を視覚化するために必須の作業です。計測の詳細についてはプロジェクト管理考の「計測」を参照してください。

４．会議運営

出荷判定会議は複数回行うことを前提とします。判定基準となるデータが揃い始めたときを最初として、第一回目の判定会議を実施し、ソフトウェア製品の完成度を見極めます。回を重ねるに従い、問題点が絞られ、関係者が一丸となって問題解決に取り組む機会にもなります。各回の間隔はおよそ１Ｗを目処にします。

５．期待する効果

出荷判定会議の導入は出荷製品の出来栄えを見極めることで、出荷に至るプロセスの改善のヒントを与えてくれます。このことが、先に述べた関係者をやる気にさせる、創意工夫の引き金となります。

上記の出荷判定会議の結果を最終判定とすることができないプロジェクトがあることも記憶に留めておいてください。出荷判定会議の結論で合格となってもまだ本番が待っています。絶対にトラブルが許されないプロジェクトの場合、本番と同じ環境で一定期間、実際のデータで繰り返しテストを行う総合評価を実施しければ、危なくて使い物にならないケースがあると言うことです。 ■