テックエイド
Udemy共通クーポン:TA2605LEARN02 詳細を見る
プロジェクトマネジメント

PMが設計レビューに参加するときの非技術観点|要件整合・影響範囲・顧客合意の確認ポイント

#PM #設計レビュー #受託開発 #品質管理 #成果物管理
PMが設計レビューに参加するときの非技術観点|要件整合・影響範囲・顧客合意の確認ポイント

「設計レビューに参加しているんですが、技術的な話についていけなくて……」

PMが設計レビューに呼ばれたとき、技術詳細に入れないことに引け目を感じることがあります。でも、PMがレビューで見るべきことは、エンジニアが見るものとは違います。

設計書の技術的な正確さはエンジニアが確認します。PMが確認するのは「このプロジェクトの要件と合っているか」「顧客との合意が反映されているか」「このまま進んで大丈夫か」という観点です。この記事では、PMが設計レビューで使える5つの非技術観点をまとめます。


PMは技術レビューを代替しなくてよい

前提として確認しておきたいのは、PMが設計書の技術的な正確さを判断する必要はないということです。

「このAPIの設計が正しいか」「このデータ構造が効率的か」はエンジニアが判断することです。PMが無理に技術的コメントをつけようとすると、的外れな指摘になり、かえって混乱を招きます。

PMのレビューは「プロジェクト管理の観点で問題がないか」の確認です。技術的な深さではなく、プロジェクト全体との整合性を見ます。


非技術観点1:要件との整合

最初に確認するのは「要件定義の内容と合っているか」です。

設計書に書かれている機能・処理・画面が、要件定義書で合意した内容と一致しているかを確認します。要件定義書がない場合や古い場合は、議事録や合意メールを確認します。

「要件には〇〇と書いてあるが、設計書では△△になっている」という差異があれば、意図的な変更かミスかを確認します。変更であれば顧客合意が必要かどうかの判断が必要です。


非技術観点2:影響範囲

新しい設計が既存の機能や他のシステムに影響を与えないかを確認します。

「この変更は〇〇機能にも影響しますか?」「既存データに影響はありますか?」という問いかけで確認できます。エンジニアが影響範囲を把握している場合は説明してもらい、漏れがないかを確認します。

影響範囲が広い場合は、テスト計画に反映されているかも確認します。


非技術観点3:未決事項

設計書の中に「TBD(検討中)」「後日確認」などの記載がないかを確認します。

設計が完成していない部分があると、後工程でその穴が表面化します。特に顧客確認が必要な箇所が未決のまま実装フェーズに入ると、後から仕様変更になります。

「この部分のTBDはいつ解決される予定ですか?」「誰が確認する作業ですか?」という形で未決事項を拾います。


非技術観点4:顧客合意

設計書に書かれている仕様が、顧客との合意内容と一致しているかを確認します。

特に確認が必要なのは、「顧客が自分で操作する部分(管理画面・入力フォームなど)」と「顧客の業務フローに関わる部分」です。技術的には正しくても、顧客の業務実態と合わない設計になっている場合があります。

「この操作フローを顧客に確認しましたか?」「顧客の業務フローと合っていますか?」という確認を行います。


非技術観点5:テスト観点

設計書を見たとき、「どうやってこれをテストするか」がイメージできるかを確認します。

PMが技術テストの詳細を考える必要はありませんが、「この動作が想定通りかどうかを確認する方法がある」ということは確認できます。

「この機能の受入テストはどこで確認しますか?」「顧客確認のシナリオはどう作りますか?」という問いかけで、テスト観点が抜けていないかを確認します。


レビュー後の記録

レビューで出たコメント・確認事項・未決事項は記録しておきます。「口頭で言った」だけで終わると、後で反映されたかの確認ができません。

記録する最低限の内容は次の3点です。

  • 指摘した内容
  • 担当者と対応期限
  • 次のレビューを行うかどうか

設計レビューを「見た」で終わらせず、「確認して記録した」にしておくことが、手戻りを防ぐことにつながります。


まとめ

PMが設計レビューで確認するのは、技術的な正確さではなく、要件整合・影響範囲・未決事項・顧客合意・テスト観点の5点です。

「技術的なことが分からないから参加しても意味がない」は誤解です。PMの視点でしか気づけない観点があります。技術的なコメントは無理にしなくてよいので、この5点を持って参加してください。

設計レビュー前チェックリスト

レビューに参加する前に以下を確認しておくと、会議中の発言がしやすくなります。

  • レビュー対象の設計書と関連する要件定義・仕様書を事前に読んでいるか
  • 前回レビューからの変更点(変更履歴)を確認しているか
  • 今回の設計が関係する顧客合意事項を把握しているか
  • 未解決の懸念事項・保留事項を事前に把握しているか
  • レビュー後の記録担当(議事録・コメント反映)を確認しているか

「準備なし→その場で考える」より「事前に5点確認→会議で確認する」にするだけで、レビューの質が変わります。

受託開発PM実務の設計レビュー・品質管理を学びたい方は、品質管理・炎上予防系の講座受託開発PM向けの課題別パックをご覧ください。

関連する記事