システム開発のプロジェクトで、顧客レビューが予定どおり返ってこない。
そんなとき、PMとしてまず考えるのは、
- 顧客が忙しいのかな
- 少し期限を延ばそう
- こちらから催促しよう
- 次の工程に影響しないようにスケジュールを調整しよう
といった対応ではないでしょうか。
もちろん、レビューの遅延そのものもプロジェクト上の問題です。
しかし、PMとして本当に警戒したいのは、レビューが遅れることそのものではありません。
より怖いのは、
顧客が十分にレビューできていない状態のまま、プロジェクトだけが先に進んでしまうこと
です。
上流工程で顧客と認識を合わせることができなければ、後になって、
「こんなつもりではなかった」
「この業務では使えない」
「この画面では必要な操作ができない」
といった問題が発覚する可能性があります。
そして、それが受入試験や総合試験の段階で発覚すると、単純な修正では済まなくなることがあります。
この記事では、システム開発プロジェクトにおける顧客レビューの遅延・品質低下をPMがどのように捉え、どのように先回りして管理するかについて整理します。
「顧客レビューが遅い」だけなら、本当に問題なのか？
まず、ここは分けて考える必要があります。
顧客レビューが予定より数日遅れたとしても、顧客が十分な時間をかけて内容を確認し、必要な指摘を返してくれているのであれば、必ずしも重大な問題とは限りません。
むしろ、
「予定より少し遅れたが、内容をしっかり確認してもらえた」
のであれば、PMとして調整すれば済む場合もあります。
一方で危険なのは、
レビューの遅延と同時に、レビューそのものの品質が低下しているケース
です。
例えば、
- 以前よりレビューの返信が遅くなった
- 指摘件数が急に減った
- 指摘内容が以前より薄くなった
- 「特に問題ありません」という回答が増えた
- 顧客から質問がほとんど出なくなった
といった状況です。
これだけを見ると、「設計の品質が上がった」と考えることもできます。
しかし、実際には、
顧客が十分な時間を取れず、細かく確認できていない
という可能性もあります。
ここを見落とすと、上流工程では「順調」と見えていたプロジェクトが、後工程で一気に問題化することがあります。
顧客レビューで見逃してはいけない3つの兆候
兆候① レビューの返信が遅くなっている
最初に確認したいのが、レビューの返却スピードです。
例えば、これまで5営業日程度で返ってきていたレビューが、最近は7営業日、10営業日と遅くなっている。
単純に考えれば、
「顧客が忙しいから遅れている」
という話です。
しかし、PMとしてはもう一歩踏み込んで考えます。
「なぜ忙しいのか？」
ということです。
顧客側で、
- 他案件のレビューが集中している
- 複数のプロジェクトを掛け持ちしている
- 通常業務が繁忙期に入っている
- 社内調整が増えている
- レビューできる担当者が限られている
といった状況が発生していないでしょうか。
特に注意したいのが、複数案件のレビュー時期が重なっているケースです。
自分たちのプロジェクトだけを見ていると、
「今週は設計書5冊なので、それほど多くない」
と思ってしまうかもしれません。
しかし、顧客側から見ると、
- 案件Aの基本設計レビュー
- 案件Bの要件確認
- 案件Cのテスト仕様レビュー
- 通常業務
が同じ週に集中しているかもしれません。
つまり、PMが見るべきなのは自分たちの案件のレビュー量だけではありません。
顧客側から見た全体の負荷を見る必要があります。
兆候② レビューの指摘件数が減っている
これは特に注意したいポイントです。
普通なら、
指摘件数が減った
↓
設計品質が向上した
と考えます。
もちろん、本当に品質が上がって指摘が減った可能性もあります。
しかし、
顧客が忙しい
↓
レビュー時間が取れない
↓
十分に確認できない
↓
指摘する余裕がない
↓
指摘件数が減る
という可能性もあります。
つまり、
「指摘が少ない＝問題が少ない」
とは限りません。
ここはPMとして非常に注意したいところです。
特に、
- レビュー返却が遅くなっている
- 顧客側の繁忙期と重なっている
- レビュー対象が増えている
- それなのに指摘件数だけ減っている
という複数の兆候が同時に出ている場合は、単純に「品質が上がった」と判断しない方が安全です。
兆候③ 指摘内容が薄くなっている
指摘件数だけではなく、指摘の中身も確認します。
例えば以前は、
といった具体的な指摘が出ていたのに、最近は、
「確認してください」
「要検討」
「問題ないか確認」
といった抽象的なコメントばかりになっている。
これは一つの警戒材料になります。
もちろん、指摘内容が薄くなる理由は顧客の忙しさだけではありません。
しかし、
レビュー遅延＋指摘件数減少＋指摘内容の希薄化
が同時に発生しているのであれば、顧客が十分なレビュー時間を確保できていない可能性を疑ってみる価値があります。
なぜ顧客レビューの品質低下が危険なのか
顧客レビューの目的を、
「設計書を承認してもらうこと」
だけだと考えてしまうと、本質を見失います。
システム開発の目的は、設計書を完成させることでも、テストを完了させることでもありません。
最終的には、
顧客の業務を適切に支援できるシステムを作ること
が目的です。
そのためには、システムを作る側だけでは分からない業務上の判断を、顧客側に確認してもらう必要があります。
特に上流工程では、
- 実際の業務フロー
- 現場での例外処理
- 部門ごとの運用
- システムを利用する担当者の考え方
- 現行業務で暗黙的に行われていること
など、顧客側にしか分からない情報があります。
ここを十分に確認しないまま設計を進めてしまうと、後工程で初めて問題が発覚します。
例えば受入試験の段階になって、
「この画面では実際の業務ができません」
「このケースも考慮してほしいです」
「想定していた操作と違います」
となった場合です。
この段階では、すでに多くの設計・製造・テストが終わっている可能性があります。
結果として、
追加開発、設計変更、テストやり直し、スケジュール変更
などにつながることがあります。
だからこそ、PMとしては上流工程で顧客にしっかり確認してもらうこと自体を、プロジェクトの重要なリスク対策として捉える必要があります。
PMは「レビュー量」ではなく「顧客側のレビュー負荷」を見る
では、顧客レビューの負荷をどう管理すればよいのでしょうか。
一つの方法は、顧客側のレビュー負荷をプロジェクト全体で見える化することです。
例えば、複数の案件が同じ顧客担当者に関係している場合、それぞれの案件について、
- いつレビューが発生するのか
- どのフェーズなのか
- どの程度の設計書を提示するのか
- どの程度の難易度なのか
- いつまでに回答が必要なのか
を週単位で並べてみます。
すると、
「この案件だけを見ると問題ないが、顧客側では同じ週に複数案件のレビューが集中している」
という状況が見えてきます。
これは、プロジェクト単位でスケジュールを管理しているだけでは見つけにくいリスクです。
「レビュー負荷」を相対的に考える
レビュー対象を単純に「設計書○冊」と数えるだけでは、実際の負荷を捉えきれないことがあります。
例えば、同じ10冊でも、
- 既存機能の軽微な改修
- 新規機能の設計
- 複数システムにまたがる設計
- 業務判断が多く必要な設計
では、顧客側のレビュー負荷は異なります。
そこで、レビュー負荷を考える際には、例えば、
- 新規か改修か
- 設計書の量
- 機能の難易度
- 顧客側で必要となる業務判断の量
- 関係部署との調整の有無
などを考慮し、相対的な負荷として捉える方法があります。
例えば、
改修機能を基準として、新規機能はより高い負荷として扱う
といった考え方です。
ここで重要なのは、負荷を「正確に数値化すること」ではありません。
どの時期にレビュー負荷の山が来るのかを事前に把握することです。
実際の負荷が予測より軽かったのであれば、それは問題ありません。
むしろ危険なのは、
「この週はかなり忙しくなると分かっていたのに、レビュー計画をそのまま進めてしまった」
というケースです。
レビュー負荷は「顧客に伝えて終わり」ではない
レビュー負荷のピークが予測できたら、顧客と共有します。
ただし、ここで、
「この週は忙しいと思いますが、予定どおりレビューしてください」
と伝えるだけでは不十分です。
顧客からすれば、
「忙しいのは分かっているけど、どうすればいいの？」
となってしまいます。
大切なのは、顧客側の負荷を認識したうえで、プロジェクト側から支援できることを考えることです。
例えば、
「この時期は複数案件のレビューが重なるため、負荷が高くなると認識しています。このままだと後工程への影響も懸念しています。こちらでレビュー対象を分割する、説明会を設定するなど、支援できることがあれば対応しますので、遠慮なく相談してください。」
という伝え方です。
ポイントは、
「ちゃんとレビューしてください」と顧客を責めないこと。
そして、
「プロジェクトを成功させるために、一緒に問題を解決したい」という姿勢を示すこと。
顧客との関係を良好に保ちながら、必要なレビューを確実に実施してもらうことが重要です。
レビュー期限そのものを調整するという考え方
顧客側の繁忙期が事前に分かっているのであれば、レビュー期限を一律に設定する必要もありません。
例えば通常は5営業日でレビューしてもらっている場合でも、顧客側の繁忙期と重なるのであれば、事前にレビュー期間を長めに設定することもできます。
重要なのは、
顧客が現実的にレビューできる計画になっているか
です。
「5営業日で返してください」というこちら側の都合だけでスケジュールを作るのではなく、
- 顧客側の繁忙期
- 他案件のレビュー
- レビュー対象の量
- 必要な業務確認
- 関係部署との調整
などを考慮して、実現可能なレビュー計画を作る。
これもPMの重要な仕事だと考えています。
顧客レビューでPMが確認したいチェックポイント
最後に、顧客レビューを計画するときに確認したいポイントを整理します。
| 確認項目 | 確認するポイント |
|---|---|
| レビュー時期 | 顧客側の繁忙期と重なっていないか |
| 並行案件 | 他案件のレビューと重複していないか |
| レビュー対象量 | 短期間に大量の設計書を提示していないか |
| 新規・改修 | 新規機能など負荷の高い設計が集中していないか |
| 難易度 | 業務判断や関係者調整が多い設計になっていないか |
| 顧客体制 | 実際にレビューできる担当者が確保されているか |
| レビュー期間 | 顧客が現実的に対応できる期限になっているか |
| 返信状況 | 以前よりレビューの返却が遅くなっていないか |
| 指摘件数 | 急激に指摘が減っていないか |
| 指摘内容 | 指摘が抽象的・形式的になっていないか |
| 業務観点 | 実際の業務で利用できるか確認できているか |
| 後工程への影響 | 未確認事項が後工程に持ち越されていないか |
このように、「レビューが終わったか」だけを見るのではなく、「十分なレビューができる状態だったか」まで確認することが重要です。
まとめ：PMが管理すべきなのは「レビューの期限」だけではない
顧客レビューが遅れたとき、
「顧客が忙しいから仕方ない」
で終わらせてしまうと、後になって問題が大きくなる可能性があります。
一方で、
レビューが遅れている
↓
顧客の負荷が高いのではないか
↓
レビュー品質も低下していないか
↓
指摘件数・指摘内容に変化はないか
↓
後工程に認識齟齬を持ち越していないか
という視点を持てば、問題が大きくなる前に対応できる可能性があります。
そして、最も重要なのは、顧客にレビューしてもらうこと自体を目的にしないことです。
システム開発の目的は、設計書を承認してもらうことでも、テストを完了させることでもありません。
顧客の業務を支援できるシステムを作ること。
そのために、顧客にしか判断できない業務上の観点を、できるだけ上流工程で確認してもらう。
「お願いしたことを顧客にやってもらう」というだけではなく、プロジェクトの成功に必要なことを顧客と一緒に担保する。
これが、顧客レビューを管理するうえでPMが持っておきたい基本的な考え方だと思います。
プロジェクトのリスクを「何となく」ではなく、観点から確認したい方へ
システム開発では、顧客レビュー以外にも、
- 要件定義での認識齟齬
- 基本設計での仕様漏れ
- 詳細設計での考慮漏れ
- 製造・単体試験での品質問題
- 結合試験でのシステム間連携問題
- 総合試験での業務シナリオ不足
- 移行・切替時の準備不足
- ベンダー・体制・進捗などの管理上の問題
など、工程ごとに異なるリスクがあります。
「何か問題が起きてから考える」のではなく、プロジェクトの各フェーズで、あらかじめ何を確認しておくべきかを整理しておくと、リスクの見落としを減らしやすくなります。
私自身、プロジェクトを確認するときに使えるよう、システム開発の各工程で確認したいリスク観点を一覧として整理しています。
プロジェクトのリスク洗い出しや工程レビューのチェック項目を増やしたい方はこちらをご覧ください。
※この記事では、特定のプロジェクトや顧客の事例をそのまま紹介するのではなく、システム開発プロジェクトで一般的に起こり得る状況として整理しています。
