『クライアント視点を無視したテスト仕様でトラブル』手戻りさせないためのPMの対策！
PMであればユーザテスト仕様書のINPUT情報はなんであるかを理解していなければトラブルが起こります。
と疑問を抱えているPM初心者・未経験者の悩みを解決できる記事になっています。
■今回のテーマ
プロジェクト計画における『品質基準の作成』の検討の中で、『ユーザテスト仕様を間違った』ことにより、『プロジェクトが停滞した』という問題が起こりました。
この問題を取り上げ、現役PMOが検証して教訓をお伝えしていきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。
参考：このような方にもお役に立つ記事となっています
✅ユーザテスト仕様書のINPUT情報を知りたい方
✅CTO、プロジェクト責任者の方
1,000以上のプロジェクトに携わった現役PMOがトラブルプロジェクトを検証した結果をご覧ください。
目次
prologue
【プロジェクト概要】
株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。
プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。
目的を達成させるためには、個々の目標の設定が必要です。
品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。
コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。
開発期間を6ヶ月としました。
【プロジェクトの登場人物】
▷山田
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
また、同社はプロマネ初心者の佐藤をフォローアップするために、The manager's（PMOコミュニティー）の『※iPMO』を利用。
また、同社はプロマネ初心者の佐藤をフォローアップするために、The manager's（PMOコミュニティー）の『※iPMO』を利用。
▷PMアドバイザー
The manager's Barに所属。プロマネ初心者の佐藤のマネジメントアドバイザー。
【プロジェクト状況】
現在のプロジェクトは、ユーザテスト（受入）工程である。
当該工程は、ITベンダであるABC社が代行して実施していおり、テストは順調に進んでいるとプロマネ初心者の佐藤は認識をしていた。
しかし、クライアントから『貴社が実施しているテストは、総合テストの内容に近いものである。業務がスムーズに実行される保証にならない。クライアント視点によるテストを実施して欲しい』との要望があった。
現在、所要期間の50%を消化しており再テストを行うには作業工数を増やし、リリースを延期しなくてはならない旨を伝えたが、却下された。
プロマネの佐藤は、状況の把握をしているが、具体的な問題が分からず打つ手もなかった。
そこで、PMOの私へサポートを求めてきた。
（以降のSTEP1-STEP4はPMOが実施した）
STEP1：問題の設定
今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『スコープマネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『ユーザテスト範囲を間違え手戻りによる工数超過』、このように問題を設定した。
STEP2：原因の究明
この問題は、品質目標である要望達成率100%を逸脱、スケジュール目標であるリリース日を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)テストの所要期間の間違え
(2)テスト仕様作成におけるスキル不足
(3)テスト仕様作成におけるインプット情報の間違え
そして、仮説に対して調査を行い検証した。
【仮説の検証】
(仮説1)テストの所要期間の間違え
▷有識者が算出した所要期間も計画と同じであったか？
➡︎YES
(仮説2)テスト仕様作成におけるスキル不足
▷メンバーはユーザーテストの仕様を作成する上で十分なスキルがあったか？
➡︎YES
(仮説3)テスト仕様作成におけるインプット情報の間違え
▷クライアントの業務が整理されているユースケースを使ってテスト仕様を作成していたか？
➡︎NO
【特定された原因】
問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は、ユーザーテストに必要なインプット情報が分からない、メンバーへクライアント業務を思いつくだけ考えて、テスト仕様を作成するように支持していたことが分かった。
STEP3：解決策
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】
解決策A：
全業務に対してユースケースを元にテスト仕様を見直してからプロジェクトを再開する。
解決策B：
クリティカルな範囲に対してユースケースを元にテスト仕様を見直し、再度テストを実施する。
解決策C：
クリティカルな範囲に対してユースケースを元にテスト仕様を見直し、スケジュールを延期して、再度テストを実施する。
調査の結果から、ユーザーテストに必要なインプット情報が分からない、メンバーへクライアント業務を思いつくだけ考えて、テスト仕様を作成するように支持していたことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。
【採用した解決策と採用の根拠】
山田の意向は、クリティカル範囲を対象にテストの見直しと再実施することに問題はないが、リリースの延期はできないとの要望があり、『解決策B』を採用した。
【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、ITベンダにテスト仕様の再検討と作成による工数が30%超過した。
今回の問題における原因は、テスト仕様作成におけるインプット情報の間違えということである。
今後、このような事態を避けるために、以下を教訓とした。
【プロジェクトを終えての教訓】
STEP4：リスク管理表の作成
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。
最後まで、読んで頂き有難うございました。
今後の貴方のプロジェクト活動の参考になれば幸いです。
