『品質基準を丸投げ』PMなら絶対やってはいけないこと！

PMは、プロジェクトの特色・特異性に合わせて品質基準を用意しなければなりません。品質基準の策定方法がわからないからメンバーの裁量に任せるのは危険です。

noteマガジン➡︎問題解決のロジカルツールを読んでください

▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷◁▷

このような疑問を抱えているPM初心者・未経験者の悩みを解決できる記事になっています。

今回のテーマ
プロジェクト計画における『品質マネジメント』の検討の中で、『品質基準の策定を行わなかった』ことにより、『プロジェクトが停滞した』という問題が起こりました。
この問題を取り上げていきます。
※プロジェクト検証の結果をお伝えするにあたり、架空の企業である「株式会社XYZ」での出来事として紹介します。

参考：このような方にもお役に立つ記事となっています
✅品質基準を策定するのに苦戦している人
✅CTO、プロジェクト責任者の人

👍この記事の信頼性
1,000以上のプロジェクトに携わった現役PMO林 雄一郎が、実際に起こったトラブルプロジェクトを解決した実話です。
この記事は、そのときの検証結果となります。
➡︎林 雄一郎のプロフィール

prologue

【プロジェクト概要】
株式会社XYZは、市場シェアの拡大と業務コストの削減のために、新規プロジェクトを立ち上げることになりました。
プロジェクトの目的として、売上の10%増加と業務コストの20%削減を掲げています。目的を達成させるためには、個々の目標の設定が必要です。
品質目標は、レスポンスタイム、受け入れ合格に数値目標を設定しました。コスト目標は、開発費用を1800万円以内として、スケジュール目標は、リリース日を10月1日、主要なマイルストーンをユーザーテストによる品質判断としています。
また、プロジェクトの開始は、4月1日。開発期間を6ヶ月としました。

【プロジェクトの登場人物】
▷山田
株式会社XYZの事業部長であり、プロジェクトオーナー。
▷木村
株式会社XYZの社内調整役。
クライアント窓口であり、ITベンダーとコミュニケーションを取る。
▷佐藤
このプロジェクトの開発を担当する株式会社ABCのプロジェクトマネージャーであり、今回初めてプロジェクトマネージメントを行うプロマネ初心者。
また、同社はプロマネ初心者の佐藤をフォローアップするために、The manager's（PMOコミュニティー）の『PMOリモート』を利用。

▷PMO（YUICHIRO HAYASHI）
The manager's Barに所属。
プロマネ初心者の佐藤のPMアドバイザーでありリモートで支援。

【プロジェクト状況】
現在のプロジェクトは、基本設計工程である。
当該工程が所要期間の50%を消化した時点で、要件定義の品質が低いため、設計チームより基本設計が行えないと指摘があり、要件定義を再度実施する必要があった。
そこで、プロマネ初心者の佐藤は『リリース日の延期』を依頼した。
クライアント窓口の木村の解答は『要件定義の品質基準が不明確な中で、要件定義のやり直しとリリース日の変更は認められない。当初の計画通り進めて欲しい』と要望された。
プロマネの佐藤は、状況の把握をしているが、具体的な問題が分からず打つ手もなかった。
そこで、PMOのわたしはへサポートを求めてきた。
わたしは、お客さま先に常駐しないPMOであるため、PMOリモートで今回のトラブルを解決した。

PMOリモートは、PMが、好きな時に、好きな場所で、プロジェクト経験豊富なPMOのビデオ通話、メールでオンラインサポートする新しい形のPMOサービスです。
フル常住型のPMOサービスと比べても、遜色の無いサービスをリーズナブル料金なので、大幅にコストが削減でき、プロジェクトを成功に導きます。
また、PMOリモートをご利用いただくことで、プロマネ初心者の方は、『マネジメント力』と『経験力』を身に付けることができます。
>>PMOリモートの詳細なサービスを確認する

プロジェクトを検証しました

検証は、STEP1-STEP4の順番で行いました。

STEP1
今回の問題は、プロジェクトで起きた事象を、様々なプロジェクト情報を元に考えたところ、『品質マネジメントエリア』で起こっている問題として取り扱うことにした。
そして、『品質基準が不明確で基本設計に進めない』、このように問題を設定した。

STEP2：原因の究明
この問題は、品質目標である要望達成率100%を逸脱している。
そこでPMOの私は、原因の仮説を立て検証を行った。
【原因の仮説】
(1)要件定義の所要期間が間違っている
(2)要件定義を行うスキルが不足している
(3)最低限の要件定義における品質基準が設定されていない

そして、仮説に対して調査を行い検証した。
【仮説の検証】
(仮説1)要件定義の所要期間が間違っている
▷有識者が算出した所要期間と同じであったか？
➡︎YES

(仮説2)要件定義を行うスキルが不足している
▷メンバーは要件定義を実施する上で十分なスキルがあったか？
➡︎YES

(仮説3)最低限の要件定義における品質基準が設定されていない
▷最低限の要件定義における品質基準である5W1Hで表現されているか？
➡︎NO

問題の根本的な原因は、『仮説3』と判明した。
また、プロマネ初心者の佐藤は、品質基準を担当者の裁量に任せていたことが分かった。
更に、5W1Hで表現されていない要件が多数見つかった。

STEP3：解決策
この問題を放置することは、デスマーチプロジェクトの危険があるため、PMOの私は解決策を３つ考え、プロジェクトオーナーの山田と協議した。
【解決策の候補】
解決策A：
要件定義工程における品質基準を作成してから、再度要件定義をやり直す。

解決策B：
5W1Hで表現されていない部分に対して、要件定義をやり直す。

解決策C：
5W1Hで表現されていない部分に対して、要件定義をやり直す。その上でスケジュールを延期する。

調査の結果から、5W1Hで表現されていない要件が多数見つかったことが分かっている。
その状況をプロジェクトオーナーの山田へ説明し、山田の意向を踏まえ解決策を決定した。

【採用した解決策と採用の根拠】
山田の意向は、5W1Hで表現されていない部分をやり直すことに問題はないが、リリースの延期はできないとの要望があり『解決策B』を採用した。

【解決策の実行に伴うダメージ】
また、今回の解決策を実施したことで、ITベンダーに再要件定義の設計、レビューに対する工数が30%超過した。
また、お客さまに再要件定義レビューに対する工数が30%超過した。
今回の原因は、最低限の要件定義における品質基準が設定されていなかったということである。
今後、このような事態を避けるために、以下を教訓とした。

【教訓】
(1)プロジェクト計画で成果物に対する品質基準を設定する。
(2)要件定義工程で計画された品質基準に従いレビュー実施し、特に5W1Hで表現されていることを確認する。

STEP4：リスク管理表の作成
最後に、今回プロジェクトで起こった問題を課題問題整理表に記述し、今後のプロジェクトの教訓として役立てるためにリスク管理表に記述した。
このリスク管理表は、ITベンダーのプロジェクト情報として保管され、他チームへの情報共有として利用することになった。

🔎PMOのよもやま話

今回のテーマですが、要件定義の品質が悪いことから基本設計に入れずトラブルになったケースです。
要件定義における品質基準を策定するのは、ベテランPMでも頭を痛めるのではないでしょうか？
要件定義は、要求仕様（書）をもとにお客さまからのインタビュー（アンケート含む）によって情報を引き出す作業です。
これは、お客さまの発信する情報と受け取るITベンダーのニュアンスが少しでも違うと、最終的に大きな乖離が出てお客さまが想像しなかったシステムが出来上がることもあります。
そのため、要件定義は開発工程の中でも一番難しい作業と考えられています。
また、ニュアンスの違いで最終形が変わってしまうことから、完璧な品質基準を作るのが困難であると考えています。
しかし、完璧でなくとも『ニュアンスの違い』が早い段階で分かれば、リスクもある程度軽減されます。
そのため、『要件定義工程における最低限の品質基準』を『5W1H』で一つ一つの要求が要件として表現されているのかを基準にすることをお薦めします。
そのためには、ユースケース図に可能な限り5W1Hを表現することが大事です（どちらかと言うと、業務フローに業務要件とシステム要件を盛り込んだイメージ）。
要件定義工程の品質基準は、非常に難しいと思いますが最低限5W1Hを盛り込んで表現したいものです。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
★今回の感想や同じような思い出があればコメントしてください。
★他にもリスクをお知りになりたい人はコメントしてください。
明日からのPMOとしての活力になります！
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

最後まで読んでいただいて有り難うございました。

👍いっしょに解決しましょう

あなたがプロジェクトでこんな風に思ったら、お手伝いさせてください。💦自分では、解決できそうもないなぁ〜
💦プロジェクトを進めるうえで、この判断って正しいのかなぁ〜
💦今は順調だけど、どんなリスクが待っているのか、凄く不安だ！
💦PMを目指すにはどんなスキルを身に付ければ良いんだろ〜
こんな時は、『PMOリモート』を使って、いっしょに考えて解決しましょう！
PMOリモートは、coconalaでもご依頼いただけます。

ITプロジェクトをオンラインで支援します オープンお試し価格1,000円（10名まで） | IT・システムの相談 | ココナラ