お役立ちコラム

■技法の概要

アドホック(Ad hoc)とは、ラテン語で「その場限りの」「特定の目的のための」という意味です。レビュー技法としてのアドホックは、特に決まったルールや手順に従わず、レビューアが自分の経験や直感に基づいて自由に成果物をチェックする方法です。
最もシンプルで制約のないレビュー技法といえます。

■実施方法

基本的な進め方
・レビューアは作業成果物を最初から順番に読んでいく
・気になった点や問題だと感じた箇所があれば、その都度記録する
・特定のチェックリストやシナリオは使用しない
・レビューアの判断で自由に進める

■特徴とメリット

-メリット-
・準備が不要：チェックリストやシナリオを用意する必要がない
・柔軟性が高い：状況に応じて臨機応変に対応できる
・即座に実施可能：思い立ったらすぐに始められる
・直感的な問題発見：経験豊富なレビューアなら「何か変だ」という違和感から重大な問題を発見できることがある
-デメリット-
・レビューアのスキルに大きく依存：経験や能力によって成果が大きく変わる
・チェック漏れが発生しやすい：体系的なアプローチがないため、見落としが起こりやすい
・再現性が低い：同じ人が同じ成果物をレビューしても、毎回異なる結果になる可能性がある
・品質のばらつき：レビューアによって指摘の質や量が大きく変わる

■効果的な使い方

アドホックは以下のような場面で効果を発揮します。
・非形式的レビューの初期段階：より形式的なレビューの前に、まず大まかな問題がないか確認したい場合
・時間的制約が厳しい：詳細なチェックリストを用意する時間がない場合
・熟練者によるクイックチェック：経験豊富な専門家が短時間で全体を見渡す場合
・小規模な修正のレビュー：大がかりな準備が必要ないような軽微な変更のチェック

■実務での活用例

開発現場では、例えば以下のような場面でアドホックレビューが活用されます。
「ちょっとこのコード、見てもらえる？」と同僚に声をかけて、その場でさっと確認してもらう場合。特にチェック項目を指定せず、全体的におかしなところがないか見てもらいます。

■技法の概要

チェックリストベースは、事前に用意されたチェックリストに基づいて、体系的に成果物を評価する方法です。レビュー技法の中でも最も広く使われている実践的な技法の一つです。

■実施方法

基本的な進め方
レビュー開始前に、レビュー対象の種類に応じたチェックリストが配布される
レビューアはチェックリストの各項目を順番に確認していく
各項目について、成果物が基準を満たしているかチェックする
問題があれば、該当する項目と具体的な問題点を記録する

■特徴とメリット

-メリット-
・体系的なレビューが可能：重要なポイントを見落とさずにチェックできる
・レビューアのスキル差を補える：経験が浅い人でもチェックリストに従えば一定水準のレビューができる
・再現性が高い：同じチェックリストを使えば、誰がレビューしても似た結果が得られる
・効率的：何をチェックすべきか明確なため、時間を無駄にしない
・教育効果：チェックリストを通じて、何が重要かを学べる
-デメリット-
・チェックリスト作成の手間：適切なチェックリストを作成・維持するには労力が必要
・チェックリストにない問題を見逃す可能性：リストに記載されていない観点での欠陥を発見しにくい
・形式的になりがち：チェックリストをこなすことが目的化してしまう危険性
・定期的な更新が必要：技術の進化や新しい知見に合わせて更新しないと陳腐化する

■効果的な使い方

チェックリストベースは以下のような場面で特に効果的です。
・インスペクションやテクニカルレビュー：形式的なレビューで確実性を高めたい場合
・規格や標準への準拠確認：コーディング規約や設計標準への適合をチェックする場合
・定型的な成果物のレビュー：毎回似た内容をレビューする場合（テストケース、設計書など）
・チーム内でレビュー品質を統一したい：複数のレビューアによる評価のばらつきを減らしたい場合

■実務での活用例

コードレビューで、コーディング規約チェックリストを使用する場合。「命名規則は守られているか」「コメントは適切に記載されているか」「例外処理は実装されているか」などの項目を一つずつ確認していきます。

■技法の概要

シナリオとドライランは、あらかじめ用意されたシナリオ（一連の操作や処理の流れ）を使って、成果物を「頭の中で実行してみる」レビュー方法です。
ドライラン(Dry run)とは、「予行演習」「リハーサル」を意味する言葉で、実際にプログラムを動かさずに、机上で動作を追っていくことを指します。

■実施方法

基本的な進め方
・レビュー開始前に、シナリオ（使用手順や処理の流れ）が用意される
・レビューアはシナリオに従って、成果物を読み進める
・各ステップで「この操作をしたらどうなるか」「このデータが来たらどう処理されるか」を頭の中でシミュレーションする
・期待される結果と成果物の記述が一致しているか確認する
・矛盾や不整合、考慮漏れがないかチェックする

■特徴とメリット

-メリット-
・処理の流れ全体を確認できる：個別の機能だけでなく、一連の流れとしての整合性をチェックできる
・実際の使われ方に即したレビュー：ユーザーや他システムがどう使うかという観点でチェックできる
・複雑な相互作用を発見しやすい：複数の機能やモジュール間の連携における問題を見つけやすい
・データの流れを追跡できる：データがどう変換され、どう引き継がれるかを確認できる
・例外ケースの確認：正常系だけでなく異常系のシナリオでも動作を検証できる
-デメリット-
・シナリオ作成の負担：適切なシナリオを作成するには、対象システムへの深い理解が必要
・シナリオ外の問題を見逃す：用意したシナリオでカバーされない部分の問題を発見しにくい
・時間がかかる：シナリオに沿って丁寧に追っていくため、レビューに時間がかかる
・複雑なシステムでは困難：分岐が多いシステムでは、すべてのパターンをカバーするシナリオを用意するのが難しい

■効果的な使い方

シナリオとドライランは以下のような場面で効果を発揮します。
・要件定義書や仕様書のレビュー：ユーザーの操作フローが正しく定義されているか確認する場合
・設計書のレビュー：処理の流れやデータの受け渡しが適切に設計されているか確認する場合
・複数システム間の連携確認：システム間のインターフェースや連携処理を確認する場合
・異常系の考慮漏れチェック：エラー発生時の処理フローが適切に定義されているか確認する場合

■実務での活用例

バッチ処理の設計書レビューで、「日次の売上集計処理」というシナリオを使用する場合。売上データの抽出→集計→マスターとの突合→レポート生成→メール送信という一連の流れを、設計書を見ながら頭の中で追っていき、各ステップで必要な処理が漏れなく定義されているかを確認します。

■技法の概要

ロールベース(Role-based)は、レビューアがそれぞれ特定の役割（ロール）の立場になりきって、その視点から成果物を評価する方法です。
「もし自分がこの役割だったら、この成果物をどう見るか」という観点でレビューを行います。

■実施方法

基本的な進め方
・レビュー開始前に、各レビューアに特定の役割が割り当てられる
・各レビューアは自分に割り当てられた役割の視点から成果物を評価する
・その役割にとって重要なポイント、困る点、不明確な点などを指摘する
・異なる役割の視点からの指摘を持ち寄り、総合的に評価する

典型的な役割の例
・エンドユーザー：実際にシステムを使う人の視点
・初心者ユーザー：システムに不慣れな人の視点
・熟練ユーザー：効率的に使いたいヘビーユーザーの視点
・年配者・子供：特定の年齢層の視点
・保守担当者：システムを保守・運用する人の視点
・システム管理者：権限管理や設定を行う人の視点
・監査担当者：コンプライアンスやセキュリティをチェックする人の視点

■特徴とメリット

-メリット-
・多様な視点からの評価：一つの成果物を複数の角度から検証できる
・見落としの削減：ある役割では気づかない問題を、別の役割の視点なら発見できる
・ユーザビリティの向上：実際の利用者の視点で評価することで、使いやすさが向上する
・保守性の確保：保守担当者の視点を入れることで、メンテナンスしやすい設計になる
・役割を意識した設計：異なるステークホルダーのニーズを満たす設計を促進する
-デメリット-
・役割への理解が必要：割り当てられた役割について十分な理解がないと効果が薄い
・役割の演技が難しい：自分とは異なる立場になりきるのは、思ったより難しい
・調整の手間：複数の役割からの指摘が矛盾する場合、優先順位をつけて調整する必要がある
・時間がかかる：複数の役割でレビューするため、全体として時間がかかる

■効果的な使い方

ロールベースは以下のような場面で特に効果的です。
・ユーザーインターフェース設計のレビュー：異なるタイプのユーザーにとっての使いやすさを評価
・業務システムの要件定義レビュー：利用部門、管理部門、IT部門など異なる立場からの要件を確認
・運用設計書のレビュー：運用担当者、ヘルプデスク、システム管理者など異なる役割からの視点
・セキュリティ設計のレビュー：一般ユーザー、管理者、セキュリティ担当者など異なる権限レベルからの確認

■実務での活用例

社内システムの画面設計書をレビューする際、以下のような役割分担を行います。
Aさん（初心者ユーザー役）：「この画面、初めて使う人にも分かりやすいか」という視点でチェック
Bさん（ヘビーユーザー役）：「毎日何十回も操作する人にとって効率的か」という視点でチェック
Cさん（システム管理者役）：「ユーザー権限の管理や設定がしやすいか」という視点でチェック
それぞれが異なる問題点を発見し、バランスの取れた設計になります。

■技法の概要

パースペクティブベース(Perspective-based)は、ロールベースと似ていますが、単に役割の視点で見るだけでなく、その役割が実際に行う作業を疑似的に実施してみることで、成果物を深く評価する方法です。
「もし自分がこの役割だったら、この成果物を使って実際に作業できるか」を検証します。

■実施方法

基本的な進め方
・レビューアに特定のパースペクティブ（視点・役割）が割り当てられる
・レビューアはその役割で実際に行う作業を、成果物を使って疑似的に実行してみる
・作業を進める中で、情報の不足、矛盾、曖昧さなどを発見する
・実際に手を動かすことで、より深い理解と発見が得られる
典型的なパースペクティブと作業の例
・テスト担当者：仕様書からテストケースを作成してみる
・設計者：要件定義書から設計書を書き始めてみる
・開発者：設計書からコードを書き始めてみる
・運用担当者：運用手順書を見ながら運用計画を立ててみる
・エンドユーザー：マニュアルを見ながら操作手順を理解してみる

■特徴とメリット

-メリット-
・最も効果が高い技法の一つ：実際に作業することで、表面的には分からない深い問題を発見できる
・実践的な問題の発見：「この情報では実際の作業ができない」という実用上の問題を見つけられる
・曖昧さの検出：実際に手を動かすと、解釈が複数ありうる曖昧な記述が明確になる
・情報の過不足を確認：作業に必要な情報が揃っているか、余計な情報はないかが分かる
・後工程の問題を予防：次の工程で困難が生じそうな箇所を事前に特定できる
-デメリット-
・時間と労力が大きい：実際に作業を行うため、他の技法と比べて時間がかかる
・高いスキルが必要：その役割の作業を実際に行えるレベルのスキルが必要
・すべての作業を完遂する必要はない：全体を完成させる必要はなく、問題を発見することが目的

■効果的な使い方

パースペクティブベースは以下のような場面で特に効果的です。
・重要な成果物のレビュー：後工程への影響が大きい要件定義書や基本設計書など
・新しい技術・手法を使う場合：従来とは異なるアプローチを取る際、本当に実現可能か検証
・複雑なシステムのレビュー：多くの機能や連携が絡む複雑な設計の妥当性確認
・テスト可能性の確認：設計書からテストケースが適切に作成できるか確認

■実務での活用例

テスト担当者のパースペクティブでの例
システムの基本設計書をレビューする際、テスト担当者の立場で実際にテストケースを書き始めてみます。
「ユーザー登録機能」について：
正常系：メールアドレスとパスワードを入力して登録
異常系：既に登録済みのメールアドレスで登録しようとした場合は…
ここで気づきます。「あれ？既に登録済みの場合の処理が設計書に書いてない！」
このように、実際にテストケースを作ろうとすることで、設計書の記述不足を発見できます。
設計者のパースペクティブでの例
要件定義書から詳細設計を起こそうとした際、「この要件を実現するには、どのテーブルにどんなデータを持つ必要があるか」を考え始めると、要件の曖昧さや矛盾に気づくことがあります。

■技法選択のガイドライン

レビュー対象の成果物による選択
・要件定義書：シナリオとドライラン、パースペクティブベース（設計者視点）
・基本設計書：パースペクティブベース（テスト担当者視点）、チェックリストベース
・詳細設計書：チェックリストベース、パースペクティブベース（開発者視点）
・プログラムコード：チェックリストベース、アドホック
・UI設計：ロールベース（複数のユーザータイプ）
・テストケース：チェックリストベース、シナリオとドライラン

■レビューの形式度による選択

・非形式的レビュー：アドホック、チェックリストベース（簡易版）
・ウォークスルー：シナリオとドライラン、ロールベース
・テクニカルレビュー：チェックリストベース、パースペクティブベース
・インスペクション：チェックリストベース、パースペクティブベース

■プロジェクトの状況による選択

・時間が限られている：アドホック、チェックリストベース
・品質要求が高い：パースペクティブベース、チェックリストベース＋他技法の組み合わせ
・レビューアの経験が浅い：チェックリストベース、ロールベース（明確なガイド付き）
・新技術・新分野：パースペクティブベース、シナリオとドライラン