「論点が違う。」
レビューでその一言を言われた瞬間、「またか……」と思ったことを今でも覚えています。
何時間もかけて資料を作ったのに、レビューは5分で終了。
返ってくるコメントは、いつも似たような内容でした。
- 論点が違う
- 整理不足
- それは要件ではなく解決策だよね
- 根拠が弱い
- 詰めが甘い
当時は本気で「自分はコンサルに向いていないのではないか」と悩みました。
しかし現在は、新規事業・DX領域のコンサルタントとして要件定義を担当し、大きく困ることは少なくなりました。
もちろん、今でも完璧ではありません。
それでも、以前のように何度も差し戻されることはほとんどなくなりました。
この記事では、私が実際に受けたレビューコメントと、そこからどのように改善したのかを実体験ベースで紹介します。
要件定義に苦手意識があるコンサル1〜3年目の方の参考になれば幸いです。
要件定義が苦手だった頃の私
私はコンサルタントになってから、要件定義がとても苦手でした。
レビューでは毎回のように、
- 論点が違う
- 整理不足
- 要件と解決策が混同している
と指摘されていました。
当時の私は、「顧客の要望を整理すれば要件定義になる」と思っていました。
例えば、お客様から
「Excelで毎月集計していて大変です。」
と言われると、
- BIツールを導入する
- Excelを自動化する
という内容を資料へ書いていました。
しかし、これは要件ではなく解決策です。
レビューでは必ず、
「なぜExcelが大変なの？」
「本当に解決したい課題は何？」
と聞かれました。
私は「どうやって解決するか」を考えていましたが、本来整理すべきなのは「何を実現したいか」だったのです。
レビューで実際によく言われたこと
| レビューコメント | 当時の自分の解釈 | 今なら分かる本当の意味 |
|---|---|---|
| 論点が違う | 資料の書き方が悪いと思っていた | 何を議論すべきか整理できていなかった |
| 整理不足 | 情報量が足りないと思っていた | 情報ではなく構造化が不足していた |
| 要件と解決策が混同している | 改善案を書けば良いと思っていた | 「何を実現したいか」の整理が先だった |
| 根拠が弱い | もっと調査が必要だと思っていた | 要件の背景を説明できていなかった |
一番の原因は「論点整理」ができていなかったこと
今振り返ると、一番の原因は論点整理でした。
当時はヒアリング内容をそのまま並べるだけで、「今回のプロジェクトで本当に決めるべきこと」を整理できていませんでした。
要件定義で重要なのは、情報量ではありません。
- 何が課題なのか
- 何を実現したいのか
- 今回どこまでを対象にするのか
この3つを整理することです。
この整理ができていないと、どれだけ見た目がきれいな資料でもレビューでは評価されません。
私は「論点が違う」と言われるたびに資料を修正していましたが、本当に直すべきだったのは資料ではなく、自分の考え方でした。
改善前と改善後を比較するとこう変わった
| 改善前 | 改善後 |
|---|---|
| ヒアリング内容をそのまま資料へ書く | 論点を整理してから資料を書く |
| 解決策を書いてしまう | まず要件を整理する |
| 完璧な資料を目指す | 80点でレビューへ出す |
| レビュー後は修正だけ | レビュー内容をチェックリストへ追加する |
| 本を読むだけで満足する | 場数と振り返りを繰り返す |
要件定義が改善できた5つの方法
① 最初に「論点」を一文で言える状態にする
今では資料を作る前に、自分へ必ず質問しています。
「このプロジェクトで一番解決したいことは何か？」
この問いに一文で答えられなければ、私は資料を作り始めません。
論点が曖昧なまま資料を作ると、高い確率で「論点が違う」とレビューされるからです。
② 要件と解決策を意識的に分ける
私が最も改善できたポイントです。
| 要件 | 解決策 |
|---|---|
| 月次集計に10時間かかる | BIツールを導入する |
| 入力ミスを減らしたい | 入力チェック機能を追加する |
| 進捗をリアルタイムで把握したい | ダッシュボードを作成する |
「何を実現したいか」と「どう実現するか」は別物です。
この違いを意識するだけで、レビューでの指摘は大きく減りました。
③ レビューコメントを「資産」にする
私が一番変わったきっかけは、レビューの受け方でした。
以前はレビューが終わると、指摘された箇所を修正して終わりでした。
しかし、それでは同じ指摘を繰り返します。
そこで始めたのが、レビューコメントを自分専用の「改善ノート」に残すことでした。
毎回、次の3つだけを書き出します。
| 振り返ること | 記録する内容 |
|---|---|
| 何を指摘されたか | レビューコメントをそのまま残す |
| なぜ指摘されたか | 自分の考え方や思い込みを書く |
| 次回どうするか | チェックリストへ追加する |
この積み重ねが、自分だけの「要件定義の教科書」になりました。
④ 場数を踏むことから逃げない
「おすすめの本はありますか？」と聞かれることがあります。
もちろん書籍や研修も役立ちます。
しかし、私が最も成長できたのは、本ではありませんでした。
実案件でレビューを受け続けた経験です。
レビューは正直、気持ちの良いものではありません。
何時間もかけて作った資料が、数分で真っ赤になることもあります。
それでも、その経験が一番成長につながりました。
場数を踏むことを避けず、1件ごとに振り返ることが、遠回りに見えて一番の近道だったと感じています。
⑤ 完璧を目指さず、80点でレビューに出す
若手の頃は、「100点の資料を作ってからレビューを受けよう」と考えていました。
しかし、その考え方は非効率でした。
方向性が違っていれば、どれだけ作り込んでもやり直しになるからです。
今は80点程度でレビューへ出し、方向性が合っていることを確認してからブラッシュアップしています。
レビューは評価される場ではなく、一緒に品質を高める場だと考えるようになってから、心理的な負担も減りました。
私が今でも使っているレビュー前チェックシート
現在でも、レビュー前には必ず次のチェックをしています。
| チェック項目 | 確認 |
|---|---|
| 論点を一文で説明できる | □ |
| 要件と解決策を混同していない | □ |
| 今回の対象範囲（スコープ）が明確 | □ |
| 抜け漏れがないか確認した | □ |
| 顧客目線で違和感がない | □ |
| レビューで聞かれそうな質問を想定した | □ |
レビューで大きな手戻りが減ったのは、このチェックシートを作ってからです。
ぜひ、自分なりのチェック項目を追加しながら育ててみてください。
結局、一番効果があったのは何だったのか
この記事では5つの改善方法を紹介しました。
もし、一つだけ選ぶなら、私なら「レビュー後の振り返り」です。
本も読みました。
フレームワークも学びました。
AIにも相談しました。
それでも、一番成長できたのは、「なぜ指摘されたのか」を毎回言語化したことでした。
要件定義は才能ではありません。
レビューを受け、振り返り、考え方を修正し、次に活かす。
この積み重ねこそが、要件定義を改善する一番の近道だと私は実感しています。
今、「論点が違う」と言われて落ち込んでいる方も、焦る必要はありません。
私も同じ経験をしました。
だからこそ、この記事が少しでも前に進むきっかけになれば嬉しいです。
よくある質問（FAQ）
Q. 要件定義が苦手なのはコンサルに向いていないからですか？
いいえ。私自身も苦手でしたが、レビューの振り返りを続けることで改善できました。要件定義は経験と改善の積み重ねで伸ばせるスキルです。
Q. 一番効果があった改善方法は何ですか？
レビュー後の振り返りです。指摘内容を記録し、自分専用のチェックリストへ落とし込むことで、同じ失敗を繰り返さなくなりました。
Q. 要件定義は本だけで上達できますか？
知識は身につきますが、実務力を高めるには実案件でレビューを受ける経験が欠かせません。場数と振り返りの組み合わせが最も効果的でした。
関連記事
この記事のまとめ
私が要件定義で成長できた理由は、特別な才能があったからではありません。
レビューで受けた厳しい指摘を受け止め、振り返り、次に活かすことを繰り返したからです。
もし今、レビューで「論点が違う」「整理不足」と言われて悩んでいるなら、まずはレビューコメントを自分の資産として残すことから始めてみてください。
きっと数か月後には、自分でも驚くほど成長を実感できるはずです。
コンサルパパからのメッセージ
このブログでは、コンサルタントとして働きながら、育児・資産形成・キャリアについて実体験をもとに発信しています。
「仕事も家庭も、お金も、少しずつ良くしたい。」
そんな方に向けて、実践的なノウハウを今後も発信していきます。