クライアント目線の品質基準を作る手順

お疲れ様です、ゆーろー@常駐しないPMOです。

わたしがプロコンサルとして参加しているiPM naviのコラムをご紹介します。

---

プロジェクトは、一般的に要件定義・基本設計の最終的な品質保証をITパートナーが主体となり総合テストで行います。

このテストを通じて、システム要件とシステム不具合（バグ）が解消していればシステム視点として品質が合格となります。

そして、最終工程のユーザーテストで、開発されたシステムを試運転し正確な業務運用ができていると判断されたときに、全ての品質条件がクリアーされたことになります。

この品質保証の判断には、ITパートナーとクライアントに大きなギャップが生じます。

それは、システム視点とクライアント視点という品質目線が違うからです。

そのためにも、ITパートナーは総合テストでも『クライアント視点』のテストを盛り込み実行することで、クライアントは安心できて、無用な誤解も避けられるのです。

👍 このコラムは

むずかしさ　：★☆☆☆☆（PM初心者向け）

ボリューム　：★★★☆☆(5分-8分で読める)

気付き学び　：★★★★★(顧客目線の品質基準の重要性)

お役立ち　　：★★★★★(顧客目線の品質基準の作り方)

仕事の実用性：★★★★☆（今すぐ使える）

---

こんにちは、プロコンサルのMASAです。

iPM PREMIUMで運営しているオンラインサロンでは、プロコンサルが企業さまのPMへ個別のレクチャーやプロジェクトの後方支援を行なっています。

その活動を通じて、プロジェクトを成功に導くために活用した大手コンサルファームならではの特別なノウハウやメソッドをコラムにしています。

今回のコラムは、SIerに勤務する38歳のPMの方からのご相談となります。

PMからのご相談

■相談者
SIerに勤務する38歳のPM

■相談内容
わたしはSIerに勤める38歳です。
この度、システムエンジニア職からPM職に転身しました。

今回のプロジェクトで初めPMになった未経験者です。

①現在、プロジェクトは総合テストの中盤です。 総合テストはシステム要件をもとにして作成された要件定義書・基本設計書の品質を実機で確認することが目的であるため、システム視点でテストを実施しています。

②わたしは、クライアント主体で実施するユーザーテストへスムーズに引き継げるように、総合テストの中間報告をしました。

③中間報告前にチームで進捗状況・品質状態を確認したところ、スケジュール通りに進行しており、不具合に対しても品質管理プロセスに従い修正していました。

④しかし、クライアントは「わたしたちは技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい。」とご指摘を受けました。

⑤わたしは、総合テストの位置付けと目的を説明しましたが、お客さまは納得してくれません。

⑥クライアントに、納得してもらえる方法はないでしょうか？


■相談のポイント
①相談者は、総合テストの中間報告でシステム視点での品質について説明した。

②クライアントは、業務視点での品質を気にしている。

③相談者は、業務視点（クライアント視点）での品質基準がわからない。


あなたが、PMであればどのように対処しますか？

こんな時は、こうしてみれば良いですよ！

このように前提条件を整理しました。

・相談者は、クライアントへ総合テストの位置付け

・目的について強引な説得をしない。

・ITパートナーは、業務視点での品質基準を検討する工数を捻出できる。

・クライアントは、業務視点の品質基準が納得できるものであれば受け入れる。


総合テストは、ITパートナーが主体となり実施するテストです。

そのため、どうしても『システム目線』になっています。
*特に、PMがエンジニアリング・キャリアが長いと、この傾向は強いです。

クライアントは、システム品質の保証と業務運用の保証を求めるものです。

しかし、クライアントは、システムありきの業務運用ではなく『業務運用ありきのシステム』と意識するものです。

そのためには、総合テストの中で『クリティカルな業務要件』に対して正確に業務運用ができるかのテストを実施しなければなりません。

まずは、このことを認識して、この問題をアプローチしていきましょう！
*このアプローチはDX時代に適応したリスキリングしているPMの方にも実用的に使えます。


アプローチ1
要件定義書・基本設計書からクリティカルな業務要件を洗い出す。

※下図のクリティカル条件を参考のこと。

アプローチ2
洗い出した業務要件をもとにクライアントと総合テストで実施する業務範囲を決める。

アプローチ3
テスト範囲を明確にするためにユースケースを作成する。

アプローチ4
ユースケースをもとに、テスト仕様書を作成する。

アプローチ5
クライアントへユースケースとテスト仕様書を説明し実施可否を判断してもらう。

【　注意　】
ユーザーテストで実施する予定のテストが含まれている場合は、総合テストもしくは、ユーザーテストのどちらで実施するかを調整する。

※同じテストを2つのテスト工程で実施することは、プロジェクト工数を圧迫するため。

まとめ

プロジェクトでは、品質基準を作ります。

元々、エンジニアから仕事をスタートした人にとっては、技術的な知見を活かせるので、容易に品質基準を策定できるという誤解があります。

確かに、品質基準は技術的な観点が必要ですが、クライアントの観点での品質基準を考えるスキルを持っていなければなりません。

クライアントは、システムありきの業務運用ではなく『業務運用ありきのシステム』と意識しています。

そのため、エンジニアリング視点で、『品質は、大丈夫！大丈夫！』と伝えても、意味がないのです。

ポイントは、テスト開始前までに、このようなことを実施しておくことです❗️

・クリティカルな業務要件を整理する。

・総合テストで実施すべき業務範囲を確定する。

・テスト範囲を明確にするために、ユースケースを作成する。

・クライアントへユースケースとテスト仕様書を説明し理解を得る。

これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。

---

★★★　45秒で分かるiPM navi　★★

無料メンバーの登録（こちら）

iPM naviの活用方法（こちら）

★★★　ぜひ、お立ち寄りください　★★

最後まで読んでいただき有難う御座いました。