品質基準を作る手順 -プロジェクト計画書を作るコツ-
お疲れ様です、ゆーろー@常駐しないPMOです。
わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。
品質基準が不明確だと、品質保証が曖昧なままプロジェクトが進行してしまいプロジェクトの目的を実現できなくなります。
このような品質基準で進めているプロジェクトは赤信号です。
・成果物の品質基準を設定されていない。
・各工程で計画された品質基準に則ってレビューされていない。
・上流工程の成果物（要件定義書、基本設計書）が5W1Hで表現されていない。
十分な注意が必要です...
こんにちは、プロコンサルの平山 理です。
私が参加しているiPMでは、PM初心者のスキルアップやDX時代に適応したいPMのリスキリングのサポートとして、iPM TRAININGを運営しています。
このコースの一つとして、『プロジェクト計画書の作り方』を講座として提供しています。
計画書を作る中で、品質基準を決めていきます。
受講されている人の多くは、品質基準を他のプロジェクト計画書の記載されている内容をコピペして利用していました。
そのため、担当するプロジェクトの特性や特異性を盛り込んだ品質基準として不十分であることから、クライアントと品質について、協議・議論に多くの時間を費やしたとのことでした。
無駄な工数や時間を減らしてもらうために、『品質基準を作る』とは、"なんぞや”を理解して、品質基準を作っていく手順をマスターすることをおススメしました。
今回のコラムは大手コンサルファームでも使っている、プロジェクトのスケジュールを決めていく方法をWHAT・WHY・HOWの順番で解説します。
WHAT：品質基準を作るとは何か？
品質基準を作るとは、クライアントニーズを満たすために、開発工程・受入工程で作成される成果物の品質数値基準を考えることです。
その時、高すぎる品質目標を設定しないことが重要です。
これは、成果物の品質の良さとそれを実現するために必要となるコストが関係してきます。
最初、品質はコストに応じて高まっていきますが、ある程度品質が高まったところで、いくらコストをかけても品質が上がらなくなります。
このことから、現実としての基準を設定しなければなりません。
ここで言うニーズとは、システムの品質であり、システム機能のリッチさ、所謂、高機能を備えると言うことではありません。
もっとユーザが使いやすいように作れば売り上げが増える。
そのような事は品質のリクエストではなく、ビジネス的な要望となります。
クライアントと協議する場合は、システムの品質と高機能を使い分けるように注意してください。
WHY：なぜ品質基準を作るのか？
なぜ品質基準を作るのでしょうか？
PMは、クライアントから良いシステムを作って欲しい、そのような曖昧な要望を受けることが多く、期待に応えなければなりません。
しかし、何を持って良いシステムであるか？
実は、PMもクライアントの判断が付いていません。
そのため、成果物の予算や良し悪しを判断する基準をクライアントと明確にしておく必要があります。
HOW：品質基準を考える
スケジュールを決めていくには、2つのACTIONを踏んでください。
ACTION1：開発工程での品質基準の作成
開発工程の品質基準を作成するには、組織のプロセス資源、前提条件、制約条件、作業範囲記述書をもとに考えていきます。
ここでは、一般的な開発工程における品質基準を解説します。
⚫︎ システムのレスポンスタイムの品質基準
レスポンスタイムは主に画面入力やバッチ処理の時間を設定します。
類似システムや一般的な基準をもとにして最も遅い処理時間を上限とし、クライアントと調整します。
⚫︎ 開発工程の品質基準
設計工程 設計工程では、レビューを中心とした机上検証による品質の確認が行われます。
そのためレビューにおける品質基準を設定します。
例えば、レビュー指摘事項による修正は100%完了していること、このような基準になるでしょう。
また、設計工程における合格基準で注意したいのが開発視点だけでの基準が設定されがちです。
必ずクライアント視点も考慮して品質基準を考えましょう。
テスト工程 テスト仕様書をもとにしたシステム環境での検証による品質の確認が行われます。
そのため、テスト消化や不具合の修正における品質基準を設定します。
例えば、テスト消化率は100%完了、不具合修正率は100%完了していること、このような基準になるでしょう。
ACTION2：受入テストでの品質基準の作成
受入テスト工程の品質基準を作成するには、組織のプロセス資源、前提条件、制約条件、作業範囲記述書をもとに考えていきます。
受入テスト工程では、クライアントの要件通りにシステムが動作するかを、確認するユーザテストの品質基準を考えていきます。
ここでは、一般的な受入テスト工程における品質基準を解説します。
ユーザテストは、要件定義書に記載されている要望が、システムを利用した時に、要望通りに動作して業務が正確に行えるかを確認するテストです。
そのためテスト消化や不具合の修正、要望の達成度合いにおける品質基準を設定します。
例えば、テスト消化率は100%完了、不具合修正率は100%完了、要望達成率は100%達成していることが、基準になるでしょう。
👀 クライアント目線での品質基準
クライアント目線での品質基準の作り方は、こちらのコラムが参考になります↓
このような2つのACTIONを踏んでプロジェクトのスケジュールを決めていって下さい。
【事例：某PJの品質基準】
*プロジェクト計画書からの抜粋
まとめ
今回は、プロジェクト計画を立てる中で、品質基準を考えていく手順を解説しました。
品質基準はクライアントのガイドライン、SIerの標準指標...etc
プロジェクトでは良く目にするものです。
また、品質基準は品質マネジメントに深く関わりがあり、テストで検出されたバグ数の集計やバグのデータをもとに品質の良し悪しを把握していく側面を持っています。
しかし、これはシステムの良し悪しだけの判断でであり、クライアントの業務が新しいシステムを使うことで、プロジェクトの目的を達成したかを、判断する基準ではありません。
品質基準は、システムの側面と業務運用の側面を判断できなければなりません。
▶︎ システムの側面を持った品質基準
(1)設計工程 レビューを中心とした机上検証による品質の良し悪しを判断する基準を作る。
(2)テスト工程 テスト仕様書をもとにしたシステム環境での検証による品質の良し悪しを判断する基準を作る。
▶︎ 業務運用の側面を持った品質基準
(1)受入テスト工程 クライアントの要件通りにシステムが動作するかの品質の良し悪しを判断する基準を作る。
PMは、これらをプロジェクト計画の段階で実効的な品質基準を作るようにしてください。
★★★ 45秒で分かるiPM navi ★★
無料メンバーの登録（こちら）
iPM naviの活用方法（こちら）
★★★ ぜひ、お立ち寄りください ★★
最後まで読んでいただき有難う御座いました。
お忙しい中、読んで頂き有難うございます。サポートは、今後のPM育成を充実させる活動と他のクリエイターへ還元していきたい考えています🙇♂️