「たくさん指摘されて、自分には向いていない気がした」
「指摘どおりに直したのに、次のレビューでも似たことを言われた」
新人SEにとって、設計書やプログラムのレビューは緊張する場面です。赤字やコメントが多いと、自分そのものを否定されたように感じることもあります。
しかし、レビューの目的は、作成者を評価したり責めたりすることではありません。成果物の問題を本番や後工程へ持ち越す前に見つけ、チームとして品質を高めることです。
私も銀行システムの開発・保守に25年以上携わり、作る側と確認する側の両方を経験してきました。レビューで本当に差がつくのは、指摘の少なさだけではありません。指摘の理由を理解し、次の成果物へ反映できるかどうかです。
この記事では、新人SEが身につけたいレビュー対応を、次の3つに分けて解説します。
- レビューを正しく受ける
- 指摘を次の仕事へ活かす
- 提出前にセルフチェックする
レビューは「成果物をよくする共同作業」
レビューでは、作成者とレビュー担当者が対立する必要はありません。二人とも目指すものは、仕様どおりで、安全に使える成果物です。
新人の成果物に指摘が多いのは、珍しいことではありません。まだ知らない業務知識、プロジェクト固有のルール、設計の観点があるためです。レビューを通して、教科書だけでは分からない現場の判断軸を学べます。
| レビュー前 | レビュー中 | レビュー後 |
|---|---|---|
| 目的・対象・懸念点を整理 | 指摘の意図と影響を確認 | 修正・横展開・再発防止 |
| セルフチェックを実施 | 事実と認識をそろえる | 対応結果を記録・共有 |
この流れを意識すると、レビューは「答え合わせの時間」から「品質と仕事の進め方を学ぶ時間」へ変わります。
1．レビューの受け方：まず意図を理解する
指摘を受けたとき、すぐに言い訳したり、反対に何も考えず「分かりました」と答えたりすると、重要な学びを逃します。最初に確認したいのは、指摘によって何を防ぎ、何をよくしたいのかです。
レビュー前に3点を伝える
レビューを依頼するときは、成果物だけを渡さず、次の三つを添えます。
- 成果物の目的と対象範囲
- 参照した仕様書や前提条件
- 迷った点、重点的に見てほしい点
「会員情報変更機能の基本設計書です。入力チェックとエラー時の画面遷移を追加しました。既存機能との整合性に自信がないため、重点的に確認をお願いします」
レビュー担当者が背景を把握でき、重要な箇所へ時間を使いやすくなります。
指摘は最後まで聞き、認識を確認する
指摘の途中で反論したくなることもありますが、まず最後まで聞きます。そのうえで、自分の理解を短く言い換えて確認します。
「入力チェックが足りないというより、異常時に後続処理を実行しないことが設計書から読み取れない点が問題、という理解で合っていますか」
修正箇所だけでなく、指摘の理由と影響を理解できれば、似た箇所にも応用できます。
説明が必要なときは根拠を示す
レビュー担当者と意見が異なる場合もあります。そのときは、感覚で反論するのではなく、仕様書、プロジェクトルール、過去の決定などの根拠を示します。
「自分が正しいと証明する」ことが目的ではありません。前提をそろえ、成果物としてどちらが適切かを一緒に判断します。根拠を確認した結果、自分の認識が違っていたら、素直に修正すれば問題ありません。
2．指摘の活かし方：その場の修正で終わらせない
レビュー指摘を該当箇所だけ直して終えると、次の成果物で同じ指摘を受けやすくなります。指摘を成長につなげるには、「なぜ起きたか」「他にもないか」「次からどう防ぐか」まで考えます。
指摘を種類ごとに分ける
指摘を次のように分類すると、自分の弱点や再発防止策が見えやすくなります。
- 仕様理解：要件や業務ルールの理解不足
- 検討漏れ：異常系、境界値、影響範囲の不足
- 整合性：他資料、画面、処理との不一致
- 表現：曖昧な記述、主語や条件の不足
- ルール：命名、書式、プロジェクト標準の不遵守
誤字なら修正で終えてもよい場合がありますが、仕様理解や検討漏れは、同じ考え方で作成した別の箇所にも存在する可能性があります。
同じ原因の箇所を横展開して確認する
一つの画面で入力上限の記載漏れを指摘されたら、同じ設計書内の他の入力項目も確認します。プログラムで例外処理の不足を指摘されたら、同じパターンの処理を検索します。
指摘された箇所だけを直す「点の対応」ではなく、同じ原因がある範囲を確認する「面の対応」を意識すると、品質が大きく上がります。
自分専用のチェックリストへ追加する
繰り返したくない指摘は、次回のセルフチェック項目へ変えます。
指摘：異常時の処理が記載されていなかった 原因：正常時の流れだけで設計を終えた 次回の確認：各処理について正常・異常・境界条件を確認する 横展開：同じ設計書の全処理を確認済み
指摘一覧をためることが目的ではありません。次の作業前に見返せる短いチェック項目へ変えることが大切です。
3．セルフチェック：レビュー前に基本的な問題を減らす
セルフチェックを行うと、レビュー担当者は誤字や形式ではなく、仕様や設計方針など重要な内容へ時間を使えます。指摘をゼロにするためではなく、レビューの質を高めるために行います。
作成直後ではなく少し時間を空ける
作成直後は、頭の中の前提を文章に補って読んでしまい、抜けに気づきにくくなります。可能なら別の作業を挟み、少し時間を空けてから読み直します。
時間がない場合でも、画面表示を変える、PDFにする、声に出して読むなど、見え方を変えるとミスを発見しやすくなります。
観点を分けて複数回確認する
一度にすべてを確認しようとすると、注意が散ります。次のように観点を分けます。
- 内容：要件や仕様を満たしているか
- 整合性：関連資料や前後の記述と一致するか
- 例外：異常系、境界値、権限、データなしを考慮したか
- 表現：第三者が同じ意味で読めるか
- 形式：命名、版数、日付、書式がルールどおりか
参照元と突き合わせる
成果物だけを読み返すと、文章として自然でも、要件が抜けていることに気づけません。要件一覧、仕様書、チケット、依頼メールなどの参照元と、一項目ずつ突き合わせます。
「自分が書いた内容は正しいか」に加え、「書くべき内容がすべてあるか」を確認することが重要です。
レビュー対応で避けたい3つの行動
1．指摘数だけで一喜一憂する
指摘数は、成果物の量、レビュー担当者、確認範囲によって変わります。数だけでなく、重大度、原因、同じ指摘の再発状況を見ましょう。
2．理由を理解せず言われたとおり直す
表面だけ直すと、別の箇所で同じ問題が残ります。分からない場合は、「この指摘で防ぎたい問題は何ですか」と確認しましょう。
3．すべての指摘を無条件に受け入れる
レビュー担当者も前提を誤解することがあります。根拠がある場合は丁寧に説明し、認識を合わせます。ただし、勝ち負けの議論にせず、成果物にとって適切な結論を選びます。
提出前のセルフチェックリスト
- 成果物の目的と対象範囲が明確になっている
- 要件・仕様・依頼事項を一つずつ反映した
- 正常系だけでなく異常系と境界値を確認した
- 関連資料との用語、値、処理の整合性を確認した
- 曖昧な表現や主語のない文章を見直した
- 過去に受けた同種の指摘を確認した
- 版数、日付、ファイル名、変更履歴を確認した
- 迷った点をレビュー担当者へ伝えられる
まとめ：レビュー指摘は次の品質へ変える
レビューは、間違いを指摘されるだけの場ではありません。自分では気づけなかった観点を知り、次の成果物の品質を高める機会です。
- 指摘された箇所だけでなく、理由と影響を理解する
- 同じ原因がないか横展開し、チェックリストへ追加する
- 提出前は観点を分け、参照元と突き合わせて確認する
まずは次のレビューで、指摘を受けたときに「どの問題を防ぐための指摘か」を一つ確認してみてください。その積み重ねが、自分の判断軸になります。
コメント