プロジェクト計画書の作成（４）各工程の品質計画についてまとめ

プロジェクト計画書（４）

続いては、品質計画について記述していきます。品質管理に関しては、ここで全体を詳細に述べることはしません。

（ボリューム的には品質のところだけで本が1冊書けるくらいの内容があります）

大型プロジェクトでは、品質管理チームを用意する必要があります。

つまるところ品質は、お客様の満足度で評価されるということをよく理解しておきましょう。

品質担当にアサインされた場合は、ぜひ一度品質管理に関して本を一冊読んで理解することをお勧めします。

【お勧めの書籍】

独立行政法人情報処理推進機構(IPA) ソフトウェア・エンジニアリング・センター(SEC)

以下2点（現在はＰＤＦ版のダウンロードのみ公開されているようです）

SEC BOOKS： 定量的品質予測のススメ

SEC BOOKS：続 定量的品質予測のススメ

３．品質計画

全体計画としては、以下の内容を記述します。

• 各工程の品質計画
• レビュー計画
• テスト計画

3-1.品質計画

品質に関しては各工程のクライテリアにも関係するため、まずは各工程の品質要素の洗い出しと品質水準をどのレベルとするか内部で検討しましょう。

品質とコストはトレードオフの関係となるため、品質を上げるためには、十分なコスト（品質チェック工数）をかける必要があります。

ここで重要なことは、品質の目標値や品質管理の方法についての合意を得るということです。

お客様としては当然高品質（要求機能がきちんと実現され、バグがない状態）を要求してきます。

ただしバグを限りなく0に近づけるには相当な工数がかかるということを理解してもらう必要があります。

予算は有限であり、期間・要員も限られた中で最大限の成果を目指す必要があるため、効率的なレビューやテスト方法が求められます。

PAF法（prevention-appraisal-failure approach）では、品質コストは、予防コスト（P)、評価コスト（A)、内部/外部失敗コスト（F)に分類されます。

不良率が高い場合は、当然品質が高いとは評価されませんが、同様にいくら不良率が低くてもコストをかけすぎている場合は、品質が良いとは評価されません。

そのため不良率とコストのバランスが非常に重要となります。少ないコストでいかに品質をあげるかが求められます。

もちろんお客様の業種や業務内容によって、どこまでコストをかけて品質を高める必要があるのかは異なります。

特に、官公庁のシステム、保険や金融系システムなど、セキュリティが重要となるシステムでは、巨額のコストをかけて、品質を高めるための施策をしていると思います。

ただし、ある程度の大規模ベンダーであっても総合的に高レベルのセキュリティを担保するようなシステムを構築するのはとても難しいということを理解しておく必要があります。

その点、Salesforceでは、毎年巨額の費用をかけて、セキュリティ対策を実施しているため、日本のベンダーに依頼して構築したWEBシステムよりもはるかに高いセキュリティを持つシステムとなっています。各評価機関からの審査結果を見れば一目瞭然ですね。

そのため、近年では官公庁や金融機関も積極的にSalesforceのサービス基盤を利用したシステム構築を始めています。

同じクラウドサービスでもamazonのAWSを使って構築する場合には、専門的な知識を有した人が基盤設計をして構築する必要がありますが、Salesforceでは基盤部分は設計する必要はなく、アプリケーションの構築に専念できるメリットがあります。

【定量評価】

品質要素に関しては、作成したシステムの場合、一般的にバグ密度を用いますが、上流工程の場合には、設計書のレビュー指摘密度を用いて定量的に評価します。

レビュー指摘密度は、レビュー指摘件数を設計書のページで割って算出します。（設計書1ページあたりのレビュー指摘件数）

評価に当たっては、あらかじめ似たような過去のプロジェクトでの実績に基づき、密度の基準値を定義しておく必要があります。基準値と比較することで設計に対する品質をチェックすることができます

【定性評価】

設計書のレビューにあたり、レビュー指摘の分類毎に集計することで、どういう指摘が多いのか傾向を把握して改善策へつなげることができます。

例えば、誤記が多い場合であれば、ドキュメントの校正に力をいれたり、「合目的性」「正確性」に関する指摘が多い場合は、ユーザ要求を正しく理解できていない、システム機能要件の定義が曖昧などの原因となり、要件のヒアリングが足りていない状況だと判断できます。

品質要素、水準の定義にあたっては、経済産業省の「ソフトウェアメトリクス高度化プロジェクト」から提供されている各種ガイドを参考にするとよいでしょう。

・定量的マネジメントのための公開データ利用ガイド
・システム及びソフトウェア品質の見える化、確保及び向上のためのガイド

3-2.レビュー計画

続いて各工程で作成する成果物についてのレビュー計画を立てていきます。

基本的には、業務領域や成果物単位で、それぞれ作成者・業務担当者が異なるため、これらの単位でレビューを実施していくことになります。

例えば、財務・会計の業務領域であれば、要件定義や開発も財務・会計の知識や簿記等の資格を持っている担当者がアサインされることが多いと思います。

お客様側に関しても、部門/部署単位で担当業務が異なることがほとんどです。お客様は通常業務と並行しての作業となるため、極力必要な会議体だけ出席していただくように計画していきましょう。

画像はクリックすると拡大表示されます。

上記のテンプレートはこちらから提供しています。

3-3.テスト計画

品質管理の最後はテスト計画となります。

テスト計画に関しても実際に計画書を作成する段階では、多くのことを検討する必要がありますが、プロジェクト計画書では、その概要だけを記載しておきましょう。

ただし、テスト対象（どこまでやるのか）、実施方法（どのような手法で実施するかなど）は曖昧にせず明確に定義しましょう。お客様と認識が異なり、追加のテスト要望が出てくるとテストの工数やスケジュールに大きな影響があります

【テスト計画の記載内容】

以下の内容について、工程ベースにマトリクス表を作成して、環境や検証機能、実施者などを纏めて記載するとよいでしょう。

３．品質計画まとめ

以上でプロジェクト計画における品質計画に関する説明が終了となります。

計画段階のためあまり詳しく記載していませんが、プロジェクトではQCD（品質、コスト、納期）が非常に重要な観点となりますので、品質管理に関しては、しっかり学習しておきましょう。

続きは、次の記事へ

関連記事