対象試験と出題頻度
ピアレビューは、基本情報技術者（FE）・応用情報技術者（AP）の午前で出題される開発技術分野のテーマです。
「インスペクション」「ウォークスルー」「デザインレビュー」など他のレビュー技法との区別が問われる定番論点で、ソフトウェア品質管理を学ぶ上での基礎となります。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「ピアレビューって普通のレビューと何が違うの？インスペクションとどう使い分けるの？」と混乱しがちです。
ピアレビュー（Peer Review）とは、一言で言うと
「同じ職場の同僚同士で、成果物の欠陥を早期に発見するために行うレビュー」
のことです。
「ピア（peer）」は英語で「同僚・対等な仲間」を意味します。
イメージとしては、「同僚同士で書いた作文を読み合う勉強会」です。
先生（上司）に提出する前に、隣の席のクラスメイト（同僚）と原稿を交換して、誤字や論理の飛躍を指摘し合う。あの感覚に近いものです。
上下関係のない対等な立場で、気軽に指摘できる雰囲気が特徴になります。
📊 ピアレビューの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Peer Review（ピア＝同僚） |
| 分類 | ソフトウェアレビュー技法 |
| 主な参加者 | 作成者と同等の立場の同僚（管理職は含まない） |
| 主な目的 | 欠陥の早期発見、品質向上、知識共有 |
| 対象成果物 | 設計書、仕様書、ソースコードなど |
解説
ソフトウェア開発では、バグや仕様の欠陥が後工程で発覚するほど修正コストが跳ね上がります。
テスト段階で見つかる欠陥より、設計段階で潰せる欠陥のほうが圧倒的に安上がりです。
そこで、開発工程の早い段階で成果物を「人の目」でチェックする活動が重要になります。
これがソフトウェアレビューであり、その代表的な実施形態の一つがピアレビューです。
なぜ「同僚」で行うのか
ピアレビューが「同じ立場の同僚」で行うことにこだわる理由は、心理的安全性とコスト効率にあります。
| 同僚で行う理由 | 具体的な効果 |
|---|---|
| 心理的安全性 | 上司がいないと作成者が萎縮せず、率直な議論が成立する |
| 業務知識の近さ | 同じプロジェクトに属する仲間なら、文脈の説明を省けて指摘が早い |
| 知識共有 | レビューを通じて、若手が先輩の書き方を学び、チーム全体のスキルが平準化する |
| 低コスト | 管理職の工数を使わないため、頻繁に実施できる |
図解：レビュー時期と欠陥修正コストの関係
欠陥は発見が遅れるほど修正コストが跳ね上がります。だからこそ、上流工程でピアレビューを回す価値があります。
📊 欠陥の発見工程と修正コストの関係
要件定義
×1
基準
設計
×5
少し増
実装
×10
中程度
テスト
×20
高コスト
運用後
×100
致命的
💡 ポイント：後工程に進むほど修正コストは指数的に増加する。だからこそ、上流工程でピアレビューを回し、欠陥を早期に潰すことに価値がある。
※ コスト倍率はBoehmらの古典的な研究に基づく目安
他のレビュー技法との比較
試験で最も問われるのが、他のレビュー技法との違いです。
広義のピアレビューには下記の技法が含まれますが、狭義の「ピアレビュー」は同僚同士の自由なレビューを指します。
| 技法 | 主催者 | 特徴 | 公式度 |
|---|---|---|---|
| インスペクション | モデレータ（第三者） | 役割分担を明確にし、チェックリストに沿って欠陥を検出する最も公式な技法 | ★★★ |
| ウォークスルー | 作成者本人 | 作成者がレビューを進行し、成果物を順に説明していく | ★★ |
| パスアラウンド | 作成者 | 成果物をメール等で複数の同僚に回覧し、コメントをもらう | ★ |
| ピアデスクチェック | 作成者 | 作成者と同僚1名の2人だけで実施する最小規模のレビュー | ★ |
| デザインレビュー （参考） |
管理職含む | 次工程に進むための関門（審査・承認）として実施。ピアレビューとは目的が異なる | ★★★ |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 ピアレビューの核心を3行で
・「ピア＝同僚」、同じ立場の仲間で成果物を検証するレビュー手法
・管理職は参加させず、対等な立場で欠陥の早期発見と知識共有を狙う
・次工程へ進むための審査・承認（デザインレビュー）とは目的が異なる
試験ではこう出る！
ピアレビューは、AP午前で繰り返し出題されている定番テーマです。出題パターンは「説明文を選ばせる単独問題」と「他のレビュー技法と混ぜた識別問題」の2系統に絞られます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H27秋 午前 問47 |
ピアレビューの説明として適切なものを選ぶ問題。 | ・正解：「同じ職場内の様々なスキルや知識をもつレビューアによって成果物を検証する」 ・ひっかけ：デザインレビュー、共同レビューの説明 |
| FE H29春 午前 問47 |
インスペクションを選ばせる問題（裏でピアレビューと比較）。 | ・モデレータの存在＝インスペクション ・選択肢にピアレビュー的記述が混入 |
📝 IPA試験での頻出ひっかけパターン
ひっかけ1：「管理職が参加する」
ピアは「対等な仲間」のため、管理職が入った時点で誤り。「早期に欠陥を取り除くために管理職の参加が必要」という選択肢は不正解。
ひっかけ2：「次工程に進むための審査・承認」
これはデザインレビューの説明。ピアレビューはあくまで欠陥の早期発見と品質向上が目的で、ゲート判定の役割は持たない。
ひっかけ3：「発注元と検証する」
これは共同レビューの説明。発注者を巻き込む形式はピアの「同僚」の定義から外れる。
頻出キーワードは「同僚」「同じ職場」「対等」「欠陥の早期発見」。逆に「管理職」「承認」「発注元」が出てきたら別技法と判断してOKです。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発に利用されるピアレビューの説明として、最も適切なものはどれでしょうか？
- A. 同じ職場内の様々なスキルや知識をもつ同僚（レビューア）によって、成果物を検証する。
- B. 成果物の内容を審査して、次の開発工程に進むための関門（審査・承認）として実施する。
- C. モデレータと呼ばれる第三者が進行役となり、役割分担を明確にして欠陥を検出する最も公式なレビュー技法である。
正解と解説を見る
正解：A
解説：
ピアレビューは「ピア（peer）＝同僚」が示す通り、同じ職場の対等な立場のレビューアが集まって成果物を検証する手法です。AP H27秋 午前問47の正解選択肢と同一の表現が使われています。
選択肢Bはデザインレビューの説明です。次工程への移行可否を判定するゲートとして実施されるもので、欠陥発見と知識共有を主目的とするピアレビューとは役割が異なります。選択肢Cはインスペクションの説明です。モデレータが存在し、役割分担とチェックリストに基づいて進める最も公式なレビュー技法であり、同僚同士の自由な議論を中心とするピアレビューとは厳密性が異なります。
よくある質問（FAQ）
Q. ピアレビューと「コードレビュー」は同じものですか？
重なる部分はありますが、同じではありません。コードレビューは「ソースコードを対象にした」レビューを指す言葉で、対象成果物に着目した呼び方です。一方ピアレビューは「同僚同士で行う」という実施形態に着目した呼び方で、設計書や仕様書も対象になります。GitHubのプルリクエストで同僚にレビューを依頼する一般的な行為は、コードレビューであり、かつピアレビューでもある、という関係です。
Q. IPAの資料では「広義のピアレビュー」という言葉が出てきます。何が違うのですか？
IPAの「高信頼化ソフトウェアのための開発手法ガイドブック」では、広義のピアレビューにインスペクション・ウォークスルー・チームレビューなどを含めて整理しています。つまり「同僚同士で行うレビュー全般」を広義、「フォーマル度合いを落とした自由なレビュー」を狭義と捉える二段構えです。試験で問われるのは狭義の意味なので、まずは「同僚で行う・管理職は入らない」を押さえれば十分です。
Q. ピアレビューを効果的に運営するコツはありますか？
実務で意識すべきポイントは3つあります。1つ目は「人ではなくコードを批判する」というルールを共有すること。2つ目は事前にチェック観点（命名規則・例外処理・性能など）を簡易リスト化しておき、論点を絞ること。3つ目は1回あたり60〜90分以内に区切ること。長時間のレビューは集中力が落ち、後半の指摘精度が下がるためです。GitHubやGitLabのレビュー機能と組み合わせると、指摘の履歴が残って改善活動につなげやすくなります。
Q. ペアプログラミングはピアレビューの一種ですか？
広い意味では関連しますが、別物として整理するのが一般的です。ペアプログラミングは2人が1台のPCでリアルタイムに開発する手法で、書きながら同時にレビューが進む点が特徴です。一方ピアレビューは「成果物が一旦完成してから」レビューする後追いの活動を指します。アジャイル開発ではペアプロをピアレビューの代替として位置づけるチームもありますが、IPA試験では別概念として区別しておくと安全です。
