システム開発のレビューとは？種類と進め方、効果を出す5つのコツ

システム開発のレビューとは、成果物を作った本人以外の目で確認し、欠陥や認識のずれを工程の早い段階で見つけて直す活動です。本記事では、システム開発のレビューの目的と効果、要件定義・設計・コード・テスト結果の4種類の違い、STEP1〜4の進め方、効果を出す5つのコツ、形骸化を防ぐ方法を整理します。開発リーダーやPM、品質向上を支援するITコンサルタントが、レビューの観点と進め方を決めて運用できる状態になることを目指します。

システム開発のレビューとは何か

システム開発のレビューとは、要件定義書・設計書・ソースコード・テスト結果といった成果物を、作成者以外の関係者が確認して、誤りや抜け、認識のずれを見つける活動です。

開発工程の全体像はシステム開発の工程の基本で整理しています。レビューは、その各工程の出口に置かれる確認の場であり、次の工程に進んでよいかを判断する関所の役割を持ちます。作った本人は思い込みで読み飛ばしがちなので、別の視点で読むこと自体に価値があります。

レビューの目的と効果

レビューの目的は、欠陥の早期発見、認識の統一、品質基準の共有の3つです。

• 欠陥の早期発見：設計書の矛盾や要件の抜けを、プログラムを書く前に見つけられます。
• 認識の統一：発注側と開発側、あるいは担当者同士で、同じ成果物を見ながら解釈の違いを揃えられます。
• 品質基準の共有：「どこまで書けば合格か」という水準がチームに伝わり、成果物の書き方が揃っていきます。

効果として最も分かりやすいのは、手戻りの小ささです。要件の誤りが設計書の段階で見つかれば修正は文書の書き換えで済みますが、テスト段階で見つかると設計・実装・テストをやり直すことになります。

品質を守るためにレビューが必要な理由

レビューが必要な理由は、テストだけでは設計や要件の誤りを見つけられないためです。

テストは「設計書どおりに動くか」を確かめる作業なので、設計書そのものが間違っていても、設計書どおりに動けば合格になってしまいます。要件の取り違えや考慮漏れは、成果物を人が読んで初めて見つかるものが多く、テストの前に置く確認としてレビューが欠かせません。工程全体の流れの中での位置づけはVモデルの考え方とあわせて見ると整理しやすくなります。

レビューの種類4つ

システム開発のレビューは、見る成果物によって要件定義・設計・コード・テスト結果の4種類に分かれ、種類ごとに目的と見る観点が異なります。

IPA（独立行政法人情報処理推進機構）の「信頼性向上に向けたシステム開発共通リファレンス」でも、システム要件、方式設計、詳細設計、コードなど、工程ごとに独立したレビューのタスクが定義されています（2026年10月参照）。4種類の違いを表にまとめます。

要件定義のレビュー

要件定義のレビューは、作るものが業務上の目的に合っているかを、実装に入る前に確かめるレビューです。

見る観点は、必要な機能の抜け、項目同士の矛盾、「迅速に」「柔軟に」といった測れない表現、機能ごとの優先度の4つです。たとえば「検索結果を素早く表示する」という要件は、何秒以内かが決まっていなければ、開発側と利用側で合格の基準が一致しません。具体的な書き方は要件定義書の記載例が参考になります。

設計のレビュー

設計のレビューは、要件定義書の内容が設計書のどこで実現されているかをたどり、実現方法の妥当性を確かめるレビューです。

基本設計では画面・帳票・データの流れと外部システムとの連携を、詳細設計ではデータベースの項目定義や処理の分岐を確認します。要件の1項目ごとに対応する設計箇所があるかを照合し、対応のない要件があれば漏れとして指摘します。あわせて、性能・セキュリティ・障害時の動きといった非機能要件が設計に反映されているかも見ます。

コードのレビュー

コードのレビューは、設計どおりに実装されていて、後から読んで直しやすいコードになっているかを確かめるレビューです。

観点は、設計書との一致、変数名や関数の分かりやすさ、入力値の誤りやエラー時の処理、権限や個人情報の扱いといったセキュリティです。動作が正しいかどうかはテストが確かめるので、コードのレビューでは「読めるか」「後任者が直せるか」に重心を置きます。

テスト結果のレビュー

テスト結果のレビューは、テストで確認すべきことが足りているか、見つかった不具合の傾向に偏りがないかを確かめるレビューです。

合格件数だけを見ず、要件や設計の項目に対してテスト項目が抜けなく割り当てられているか、不具合が特定の機能に集中していないかを確認します。不具合が集中する機能は、設計やコードに構造的な問題を抱えている場合があります。テスト工程の全体像はシステム開発のテスト工程で解説しています。

レビューの進め方 STEP1〜STEP4

レビューは、STEP1で対象と観点を決め、STEP2で事前に資料を読んで指摘を集め、STEP3で会議にて整理し、STEP4で修正を確認して記録する4段階で進めます。

各STEPの入力と出力を決めておくと、誰がいつ何をするかが明確になり、会議が読み合わせだけで終わることを防げます。

STEP1 対象と観点を決める

STEP1では、レビューする成果物の範囲と、見る観点を会議の前に決めて参加者へ共有します。

1. 入力：成果物の最新版、前の工程のレビュー結果、観点のチェックリスト
2. やること：レビュー範囲を1回あたり読み切れる量に区切り、観点を3〜7項目に絞る
3. やること：レビューで参照する上流の成果物（要件定義書など）が、レビュー済みかを確認する
4. 出力：レビュー対象の一覧、観点リスト、参加者と日程

IPAの共通リファレンスは、レビューで参照する他の成果物のレビュー完了率を、100%であることが望ましいとしています。要件定義書が未確認のまま設計書をレビューすると、前提そのものが間違っている可能性が残るためです。

STEP2 事前に資料を読んで指摘を集める

STEP2では、会議の前に各レビュアーが個別に成果物を読み、指摘を所定の様式に書き出します。

1. 入力：STEP1の対象一覧と観点リスト、成果物
2. やること：観点に沿って読み、指摘を「場所・内容・重要度」の3点で記録する
3. 出力：レビュアーごとの指摘一覧

読む時間の目安として、IPAの資料はHumphreyの品質ガイドライン（2000年）を紹介しています。要求のレビューは1ページあたり0.5時間以上、高レベル設計のレビューは書式の整った設計文書で1ページあたり0.2時間以上、コードのレビューは1行あたり約20秒以上（1時間に200行前後）とされています。古い資料に基づく参考値であり、そのまま基準にする必要はありませんが、「1ページを数分で済ませる」では足りないことを示す目安になります。

STEP3 会議で指摘を整理する

STEP3の会議では、集めた指摘を1件ずつ確認し、修正する・しない・保留のいずれかを決めることに時間を使います。

1. 入力：レビュアーごとの指摘一覧
2. やること：重複する指摘をまとめ、指摘の意図が分からないものは起票者に確認する
3. やること：各指摘について、修正の担当者と期限を決める
4. 出力：判断済みの指摘一覧（修正する／しない／保留と、担当者・期限）

会議では解決策の議論に深入りしないことが大切です。修正方法の検討は担当者に任せ、会議では「直すべきかどうか」の判断を優先すると、時間内に終わりやすくなります。

STEP4 修正を確認して記録する

STEP4では、指摘が実際に直されたことを確認し、レビューの結果と次回に生かす情報を記録して終わります。

1. 入力：判断済みの指摘一覧、修正後の成果物
2. やること：修正済みかを指摘ごとに確認する（起票者または進行役が実施）
3. やること：指摘の件数、種類、読んだ時間を記録する
4. 出力：レビュー完了の記録、次の工程へ進んでよいかの判断

修正の確認を省くと、指摘が出たこと自体で安心してしまい、直されないまま次の工程に進みます。確認の担当者を会議の場で決めておくと、抜けを防げます。

効果を出す5つのコツ

レビューで効果を出すコツは、観点の事前共有、対象量と時間の限定、成果物への指摘、重要度の明示、記録の活用の5つです。

1. 観点を事前に共有する：観点が決まっていないと、レビュアーごとに見る場所が異なり、同じ種類の指摘ばかりが集まります。チェックリストをSTEP1で配ると、見落としが減ります。
2. 1回の対象量と時間を絞る：長時間のレビューは集中が続かず、後半の指摘の質が落ちます。1回あたり1〜2時間で読み切れる量に区切るのが現実的です。
3. 人ではなく成果物に対して指摘する：「あなたの書き方が悪い」ではなく「この記述だと2通りに読める」と書くと、作成者が受け止めやすくなります。
4. 指摘に重要度をつける：「修正必須」「推奨」「質問」の3段階に分けると、修正の優先順位が決まり、細かい表記の指摘で本質的な指摘が埋もれることを防げます。
5. 記録して次のレビューに生かす：指摘の種類を集計すると、「要件の曖昧さが多い」といったチーム固有の傾向が見え、観点リストの改善に使えます。

5つのコツのうち、まず取り組みやすいのは1つ目の観点の共有です。次のレビューからチェックリストを数項目でも用意するだけで、指摘の質が変わるかを確かめられます。

よくある失敗と防ぎ方

レビューが形骸化する主な原因は、観点の不在と時間不足であり、どちらも事前の段取りで防げます。

とくに時間不足は、計画にレビューの工数が含まれていないことが根本の原因になります。進捗が遅れたときにレビューが真っ先に削られる状態を避けるため、レビューを独立した作業として工程表に載せておくことが有効です。開発全体のリスクの見方はシステム開発のリスクと管理の進め方で整理しています。

まとめ｜レビューを品質の仕組みにする

システム開発のレビューは、要件定義・設計・コード・テスト結果の4種類を、STEP1〜4の手順で進めることで、品質を守る仕組みとして機能します。

観点を事前に決め、事前に読み、会議では判断に集中し、修正を確認して記録する。この流れを毎回同じ形で回すことが、レビューを個人の頑張りではなくチームの仕組みにする近道です。まずは次のレビューから、観点リストと指摘の重要度の2つを取り入れてみてください。工程全体の進め方はシステム開発の工程と進め方の基本もあわせてご覧ください。

ITコンサルタントとして開発プロジェクトに関わる場合も、上流の成果物を評価できる力は強みになります。単価の目安でも、上流工程（戦略策定・要件定義）は下流（運用・保守）より高い傾向があり、IT戦略領域で月150〜200万円という水準がある一方、運用・保守寄りの案件では下限が50〜60万円台まで下がる例があるとされています（編集部が整理した2026年時点の相場の目安）。

出典・参考情報

1. IPA（独立行政法人情報処理推進機構）「信頼性向上に向けたシステム開発共通リファレンス」（2026-10-13参照）

本記事の内容は2026年10月時点の情報に基づきます。個別のプロジェクトへの適用は、契約や体制に応じて専門家にご確認ください。