はじめに
設計書、手順書、ソースコードをレビューするときに、次のような状態になることがあります。
- 何を見ればよいか分からない
- 作成者の意図が伝わらず、指摘が表面的になる
- レビュー会議をしたのに、あとから認識違いが見つかる
- 若手メンバーに設計の考え方を共有したい
こうした場面で使いやすいレビュー手法のひとつが、 ウォークスルーレビュー（Walkthrough Review） です。
この記事では、ウォークスルーレビューの意味、進め方、他のレビューとの違い、SES現場での使いどころを整理します。
この記事でわかること
- ウォークスルーレビューとは何か
- インスペクション、ピアレビュー、ラウンドロビンとの違い
- 設計書レビューでの進め方
- レビュー時に使える観点と記録テンプレート
- ウォークスルーで気をつけたい落とし穴
先に結論
ウォークスルーレビューは、 作成者が中心となって成果物を説明し、参加者が質問や指摘をしながら内容を確認するレビュー手法 です。
| 観点 | 内容 |
|---|---|
| 主体 | 作成者 |
| 目的 | 内容説明、認識合わせ、改善点の発見、知識共有 |
| 向いている成果物 | 設計書、手順書、ソースコード、構成図、テスト観点 |
| 向いている場面 | 意図を共有したい、若手に考え方を伝えたい、設計の前提をそろえたい |
| 注意点 | 作成者の説明に引っ張られすぎると、細かい欠陥を見逃しやすい |
一言でいうと、ウォークスルーレビューは 「作成者が説明しながら、参加者全員で成果物を確認・改善していくレビュー」 です。
前提
- 対象読者: レビュー手法を整理したい人、設計書レビューに参加する人、SES現場でレビューの進め方を知りたい人
- 扱う範囲: ウォークスルーレビューの基本、流れ、実務での使い方
- 扱わない範囲: 特定企業のレビュー規定、厳密な品質管理プロセス、監査向けの正式なレビュー手順
- 仕様確認日: 2026-08-05
この記事では、SESを「外部の開発・インフラ現場に参画し、設計書や手順書、コードなどの成果物を作る働き方」として扱います。実際の現場にレビュー規定がある場合は、そのルールを優先してください。
用語の短い説明
| 用語 | 短い説明 |
|---|---|
| 成果物 | 設計書、手順書、ソースコード、構成図、テスト仕様書など、レビュー対象になるもの |
| 作成者 | 成果物を作った人。ウォークスルーでは説明役になる |
| レビュアー | 内容を確認し、質問や指摘を出す人 |
| モデレーター | レビューの進行役。インスペクションでは特に重要になる |
| 欠陥 | 誤り、抜け、矛盾、仕様不一致など、修正すべき問題 |
| SPOF | Single Point of Failureの略。そこが止まると全体が止まる単一障害点 |
ウォークスルーレビューの特徴
ウォークスルーレビューでは、作成者が成果物を順番に説明します。
例えば、設計書を作った人が次のように説明します。
このネットワーク構成は、AZ障害を考慮して冗長化しています。
ここでALBを配置し、ECSへルーティングしています。
DBはprivate subnetに置き、外部から直接接続できない前提です。
参加者は、その説明を聞きながら質問します。
- この構成でSPOFは残っていないか
- セキュリティグループの考え方は説明できるか
- 障害時の切り替えはどこで確認するか
- 運用手順書に必要な手順が落ちていないか
- 実装担当者が同じ認識で作業できるか
ポイントは、単に誤字や表記ゆれを探すだけではないことです。 作成者の意図、設計の前提、参加者の理解をそろえる ことも大事な目的です。
ウォークスルーレビューの流れ
基本の流れは次のとおりです。
会議では、最初に「今日は何を見るのか」を決めておくと進めやすいです。
| 手順 | やること | 具体例 |
|---|---|---|
| 1 | レビュー対象を決める | 基本設計書のネットワーク構成だけを見る |
| 2 | 作成者が前提を説明する | 可用性、セキュリティ、運用制約を説明する |
| 3 | 参加者が質問する | 「この通信経路はどこで許可しているか」 |
| 4 | 指摘を記録する | 指摘、理由、対応方針、担当、期限を残す |
| 5 | 修正後に確認する | 修正内容だけ再レビューする |
レビュー範囲が広すぎると、説明だけで時間が終わります。1回のウォークスルーでは、「全体構成」「認証」「運用手順」など、見る範囲を絞るのがおすすめです。
設計書レビューで見る観点
SES現場で設計書をレビューするなら、次のような観点が使いやすいです。
| 観点 | 確認すること | 質問例 |
|---|---|---|
| 目的 | 何を満たす設計か | この設計で一番守りたい要件は何か |
| 前提 | 何を前提にしているか | 利用者数、運用時間、障害許容はどこに書いたか |
| 構成 | コンポーネントの役割が明確か | ALB、ECS、DBの責務は分かれているか |
| 通信 | 通信経路が説明できるか | 外部からDBへ直接入れない構成か |
| セキュリティ | 権限や公開範囲が強すぎないか | セキュリティグループは最小限か |
| 障害 | 障害時の動きが説明できるか | AZ障害、アプリ障害、DB障害でどう気づくか |
| 運用 | 監視、ログ、バックアップがあるか | 誰が何を見て、どう復旧するか |
| 実装 | 実装者が迷わない粒度か | パラメータ、命名、環境差分は書かれているか |
作成者が説明しながら、参加者がこの表を横に置いて質問すると、指摘が出しやすくなります。
レビュー記録テンプレート
ウォークスルーレビューでは、指摘をその場で流さず、必ず記録します。
次のようなMarkdownテンプレートにしておくと、あとから修正状況を追いやすいです。
## レビュー概要
- レビュー対象: 基本設計書 ネットワーク構成
- 作成者: 山田
- 参加者: 佐藤、鈴木、田中
- 日時: 2026-08-05 10:00-11:00
## 今日見る範囲
<!-- 範囲を絞ると、説明が広がりすぎるのを防げる -->
- VPC、サブネット、ALB、ECS、RDSの配置
- 外部公開範囲とセキュリティグループ
- 障害時の切り替え方針
## 指摘一覧
| No | 指摘内容 | 理由 | 対応方針 | 担当 | 期限 |
| ---: | --- | --- | --- | --- | --- |
| 1 | private subnetの外向き通信経路が不明 | パッチ取得や外部API接続の可否が判断できない | NAT Gateway要否を設計書に追記する | 山田 | 8/6 |
| 2 | ALB障害時の確認手順がない | 障害時に一次切り分けが遅れる | 監視項目と確認コマンドを運用手順書へ追加する | 佐藤 | 8/7 |
## 次回確認
<!-- 再レビュー対象を明確にして、全体を最初から見直さないようにする -->
- No.1、No.2の修正差分だけ確認する
ウォークスルーレビューは会話で理解を深めやすい一方、記録が弱いと「言った・言わない」になりやすいです。指摘内容だけでなく、理由と対応方針まで残すと修正しやすくなります。
他のレビュー手法との違い
レビュー手法は似た言葉が多いので、主体と目的で整理すると分かりやすいです。
| レビュー手法 | 主体 | 主な目的 | 向いている場面 |
|---|---|---|---|
| ウォークスルー | 作成者 | 内容説明、認識合わせ、改善点の発見 | 設計意図を共有したいとき |
| インスペクション | モデレーター | 欠陥を体系的に発見する | 品質基準を厳格に確認したいとき |
| ピアレビュー | 同僚 | 気軽な相互レビュー | コードや小さな設計変更を早く確認したいとき |
| ラウンドロビン | 複数人 | 順番に確認・指摘する | 参加者全員から意見を出したいとき |
ウォークスルーは、厳格さよりも 理解の共有 に強い手法です。
一方、欠陥を漏れなく洗い出したい場合は、チェックリストや役割分担を決めたインスペクションの方が向くこともあります。
メリット
ウォークスルーレビューには、次のメリットがあります。
| メリット | 説明 |
|---|---|
| 認識のズレを早く見つけられる | 作成者の意図を聞きながら確認できる |
| レビュー参加者が内容を理解しやすい | 背景や判断理由も共有される |
| 若手への教育に使いやすい | なぜその設計にしたかを説明できる |
| 暗黙知を共有しやすい | 手順書や設計書に書ききれていない前提を拾える |
| 修正方針まで決めやすい | 質問と回答をその場で整理できる |
特に、初めて触るシステムや、引き継ぎ前の設計書では効果が出やすいです。
デメリットと対策
便利な一方で、ウォークスルーレビューには注意点もあります。
| デメリット | 起きやすいこと | 対策 |
|---|---|---|
| 説明が長くなる | 作成者の説明だけで時間が終わる | 事前共有し、当日は重要箇所だけ説明する |
| 細かい欠陥を見逃す | 説明に納得してしまい、確認が浅くなる | チェックリストを使う |
| 作成者に遠慮する | 指摘が出にくい | 目的を「責める」ではなく「成果物を良くする」にそろえる |
| 議事録が弱くなる | 修正内容が曖昧になる | 指摘、理由、対応方針、担当、期限を記録する |
ウォークスルーは、作成者の説明力に依存しやすいレビューです。そのため、参加者側も受け身にならず、観点を持って質問することが大切です。
SES現場での使い方
SES現場では、参画直後にシステム全体の背景が分からないことがあります。
このとき、ウォークスルーレビューは次のような場面で使いやすいです。
- 基本設計書の内容をチームでそろえる
- 詳細設計書の具体値をレビューする
- 手順書の抜け漏れを確認する
- 若手メンバーへ設計判断を共有する
- 引き継ぎ前に成果物の意図を説明する
例えば、ネットワーク設計書であれば、作成者が次のように説明します。
この構成では、ALBだけをpublic subnetに置いています。
アプリケーションとDBはprivate subnetに置き、外部から直接入れない前提です。
障害時はALBのヘルスチェックとアプリログを見て切り分けます。
レビュアーは、説明を聞きながら次のように確認します。
- ALBからアプリへの通信だけ許可しているか
- DBへ直接入れる経路が残っていないか
- AZ障害時に片系で動く前提か
- ログと監視で障害に気づけるか
- 運用手順書に切り分け手順があるか
作成者が「なぜそうしたか」を説明し、参加者が「それで現場が運用できるか」を確認する。これがウォークスルーレビューの実務的な使い方です。
進めるときのチェックリスト
実際にウォークスルーレビューを行う前に、次の項目を確認しておくと進めやすいです。
- レビュー対象と範囲を決めた
- 成果物を事前共有した
- 作成者が説明する順番を決めた
- 参加者が見る観点を持っている
- 指摘を記録する場所を用意した
- 指摘の担当と期限を決める
- 修正後にどこまで再確認するか決める
レビュー会議は、集まること自体が目的ではありません。 修正すべきことが明確になり、次の作業に進める状態 を目指します。
関連記事
- AWSインフラ工程を5ステップで整理する 要件定義・設計・実装・検証
- AIへの依頼をMarkdownで構造化するだけで、出力の事故はかなり減らせる
- AI時代のエンジニア生存戦略 使い倒す人と淘汰される人
まとめ
- ウォークスルーレビューは、作成者が説明しながら成果物を確認するレビュー手法
- 欠陥発見だけでなく、設計意図の共有や認識合わせにも向いている
- 説明が長くなりやすいため、範囲、観点、記録方法を先に決める
- SES現場では、設計書、手順書、引き継ぎ、若手教育で使いやすい
おわりに
ウォークスルーレビューは、成果物の正しさだけでなく、チーム内の理解をそろえるためにも役立ちます。レビュー前に「何を見るか」と「何を記録するか」を決めておくと、会議の時間をかなり使いやすくできます。
Wealthy Designでは、Webシステム開発、クラウド活用、AIを使った業務改善に取り組んでいます。
会社の取り組みは、会社サイトにまとめています。
