レビューで指摘したらちょっと空気がピリついちゃって……。要件定義ってレビューも難しいですね。
そうですね。レビューは内容だけでなく伝え方も大事です。対立ではなく、合意形成の場として捉えると進めやすくなりますよ。
はじめに
要件定義レビューは、プロジェクトの成功可否を左右する重要な工程です。しかし、内容の精度を高める一方で、レビューの場がギスギスしてしまうことも少なくありません。本記事では、現場で実践できる“嫌われない”要件定義レビューの進め方を、具体的なチェックポイントとともに紹介します。
なぜレビューで空気が悪くなるのか？
目的のすれ違い
レビューを受ける側と指摘する側で目的意識がずれていると、レビューの意図がうまく伝わらず、「なんでこんなこと言われるの？」という不信感が生まれることがあります。
たとえば、レビュアーは仕様の正当性を見ているが、対象者は文法の修正程度を想定していると、指摘が重く感じられます。レビュー開始前に「今回は〇〇の観点で見ています」と共有することが大切です。
指摘の仕方が攻撃的に聞こえる
本人に悪気がなくても、言葉の選び方によっては相手に批判的な印象を与えてしまいます。
例：「このままだと使い物になりません」よりも、「この部分、ユーザー視点だと混乱するかもしれません。こういう表現に変えてみてはどうでしょう？」など、建設的かつ提案型の表現を使うのがベターです。
レビューが形式化している
チェックリストだけを機械的になぞっていくようなレビューでは、本来の目的である「共通理解の形成」や「業務要件の適合確認」が形骸化します。
「この機能、現場のオペレーションで実際に回せそうですか？」といった実用面の視点を取り入れ、形式に流されないレビューを心がけましょう。
嫌われないレビューの基本スタンス
改善提案型で話す
実践例：「この仕様の説明、図を追加して処理の流れを示すとさらに分かりやすくなりそうです」
立場を上下で見ない
- 初心者相手でも、対等な立場として話すことで信頼関係が築ける
- 「この表現ちょっと気になったんだけど、こういう考え方もありそうですよね」と、協働するスタンスを意識する
- 教育的アプローチを意識しつつ、指導ではなく“共に考える”姿勢が重要
レビューの目的を冒頭で共有する
- 「今日は仕様の抜け漏れがないかを重点的に見ましょう」と目的を明確にする
- 目的によって見るべき観点（仕様の妥当性、表現の統一、業務要件との整合性など）が異なるため、事前共有することで指摘のズレを防げる
- レビュー観点の例：「今回のレビューはユーザー視点での使いやすさを重視して見たいと思います」
精度を上げるための実践チェックポイント
内容面
- 要件に曖昧な表現（例：”適切に”、”迅速に”、”十分に”など）が含まれていないか確認。可能であれば定量的な表現に置き換える
（例：「3営業日以内に」など）。 - 機能要件（何ができるか）と非機能要件（どのようにあるべきか）が明確に分類され、ドキュメント内で章立てやラベルで区別されているかを確認。
- 業務フロー図や画面仕様書との整合性が取れているかを確認。
要件に記載された処理の順序や画面項目が、業務フローやUI仕様と一致しているか、さらに操作の前提条件や画面遷移条件に齟齬がないかを見直す。
表現面
- 各要件の文が「誰が（主語）」「何を（目的語）」「どうする（述語）」で構成されているかを確認。
- 箇条書きの記号（例：ハイフン・中黒など）や文末表現（「〜すること」など）が統一されているかを確認。
- 図表と本文が参照番号（例：「図1」「表2」など）で明確に連携されており、該当箇所での説明が省略されていないかを確認。
合意形成面
- レビュー実施前に、レビュー観点（例えば「用語統一」「機能網羅性」など）を明文化して関係者間で合意しているか。
- 指摘が業務的な論点（業務要件や運用観点）に基づいているか、または単なる書き方や個人のスタイルの指摘かを分けて整理されているか。
- 指摘をする際に「○○のようにしてはどうでしょうか？」という代替案や理由が添えられているか。これにより単なる否定的コメントに終始せず、改善の方向性が共有される。
| 観点 | チェック項目例 |
|---|---|
| 内容面 | 曖昧な表現がないか、機能・非機能の分類が明確か、業務フローとの整合性があるか |
| 表現面 | 主語・述語の対応、箇条書きの統一、図表との連携が取れているか |
| 合意形成面 | レビュー観点の合意があるか、指摘が業務的かどうか、代替案があるか |
レビュー後のフォローも大切
- 指摘内容のトーンを再確認
- 相手にとって受け入れやすい言い回しだったか、口調にトゲがなかったかを自省する。可能であれば、指摘の背景や意図を補足するコメントを後で追加しておくと誤解が減る。
- 感謝を伝える文化を持つ
- 「レビューありがとうございました」だけでなく、「具体的な指摘が役立ちました」「気づけなかった点を教えてくれて助かりました」といった具体的なお礼を伝えると、チームの雰囲気が向上する。
- 議事メモを共有する
- レビューで出た指摘や対応方針を記録した議事メモを作成し、関係者に共有することで、認識の齟齬を防ぎ、修正の抜け漏れを防止できる。NotionやConfluenceなどのツールを活用すると効率的。
要件定義レビューは「チェック」ではなく「合意形成」の場。
精度を高めることは大前提として、参加者の納得感や関係性を損なわない工夫が、最終的なプロジェクト品質を高めるカギとなります。ぜひこの記事で紹介したポイントを取り入れ、現場で嫌われないスマートなレビューを実践してみてください。
💡 「レビュー＝指摘大会」になっていませんか？
「言った・言わない」で揉める、雰囲気がギスギスする…
そんな要件定義レビューには、やり方の“コツ”が欠けているのかもしれません。
この記事では、現場で信頼を失わずにレビューを進める工夫と、実務に活かせるチェックポイントを紹介しました。
さらに深く学びたい方は、Schooのレビュー実践講座もあわせて活用してみてください。
7000本以上の動画講座が見放題！今すぐ“学び直し”を始めよう
社会人のリスキリングを支援する学習プラットフォーム【Schoo】。
AI・プログラミング・業務改善など、今の時代に必要なスキルを月額で学べます。
基礎から実践まで、レベル別に分かれているので初心者でも安心。
まずは無料登録で、あなたに合った講座を探してみませんか？
