共同レビューとは？きょうどうれびゅー
共同レビューとは、発注する側と開発する側の双方が同じ場に出て、要件定義書や設計書の内容を一緒に確認し、認識の食い違いや漏れをその場で洗い出す作業。工程の区切りごとに行い、合意した内容を記録して次の工程へ進んでよいかの判断材料にする。共通フレーム（開発作業の内容と用語をそろえた共通の物差し）でも、開発の各工程で実施する作業として位置づけられている。
最終更新：2026-10-10
この語が出る過去問を解く →背景
システム開発の手戻りの多くは、プログラムの誤りではなく「頼んだものと違う」という認識のずれから起きる。ずれは工程が進むほど直す費用が跳ね上がり、稼働の直前に見つかると作り直しになる。そこで成果物ができた区切りごとに、発注側と開発側が同じ文書を突き合わせて確認し、合意した内容を残す。担当者が一人で読んで承認する形にしないのは、双方が同席することそのものに意味があるからである。
具体例
業務システムの要件定義では、利用部門の担当者と開発会社の技術者が同席し、画面の項目や帳票の様式を1枚ずつ確認する。「この欄は空欄のままでも登録できるのか」といった細部をその場で決め、議事録に残して要件定義書へ反映する。近年はMicrosoft Teamsの画面共有で遠隔から行うことも多い。
試験での引っ掛け
共同レビューは発注側と開発側の双方が参加することが要件で、開発側だけで行う内部の確認は含まない。またレビューは欠陥を見つけて記録する場であって、その場で直したり担当者の責任を問う場ではない。動かして確かめるテストと違い、文書を読んで確かめる作業である点も区別される。
関連用語
出た過去問
問題文で直接問われたものと、解説の中で触れられたものが含まれます。
出典：平成21年度 秋期 ITパスポート試験 問29（IPA）解説で登場
現行システムの使用を開始してから10年が経過し、その間に業務内容も変化してきた。そこで、全面的に現行システムを開発し直すことになった。開発者が、システム要求の分…
正解：システム要件は、システム利用部門と共同でレビューを行う。
要点：要件は利用部門と共同レビューし合意して確定する
要件定義では、実際に業務を担う利用部門の要求を正しく反映できているかが成否を分ける。そのため開発者が一方的に決めるのではなく、まとめた要件を利用部門と一緒にレビューし、認識の食い違いを早い段階で解消して合意を得る進め方が適切である。現行の操作手順をそのまま踏襲すると、変化した業務に合わないシステムになりかねない。
出典：平成26年度 秋期 ITパスポート試験 問35（IPA）
システムの開発を外部のベンダに委託する際に、納期及び品質を取り決めることにしている。調達に関する活動a～dのうち、取り決めた納期と品質を実現するために不可欠な活…
正解：a, b, c
要点：納期と品質の確保は合意文書・共同レビュー・受入れテスト
納期と品質を守らせるには、まず取り決めを文書として合意し（c）、開発中は共同レビューで進捗と問題を把握し（b）、完成物は受入れテストで要求を満たすか確認する（a）という一連の活動が必要である。支払の実行は契約履行の事務であり、納期・品質の実現を直接担保する活動ではない。
出典：平成31年度 春期 ITパスポート試験 問51（IPA）
システムの利用者と開発者の間で、システムの設計書の記載内容が利用者の要求を満たしていることを確認するために実施するものはどれか。
正解：共同レビュー
要点：共同レビューは利用者と開発者で要求との一致を確認
共同レビューは、利用者側と開発側が同席して成果物を突き合わせ、要求が正しく反映されているかを確認する場である。設計書の段階で認識のずれを見つけられれば、後の工程での手戻りを大きく減らせる。テストは作られた動くものを検証する活動、会議体は進行状況を管理する場であり、いずれも設計内容の妥当性確認そのものではない。
出典・参考
公式シラバスの4 開発技術 ＞ 25. システム開発技術 ＞ (1) システム開発のプロセスに掲載されている用語です。
解説は資格暗記が独自に作成しています。過去問の出典は各問題に記載のとおりです。