インスペクションとは？他のレビューとの違いや実施手順を解説
COLUMN
最終更新日：2023年06月05日 ／ 投稿日：2023年04月26日
ソフトウェア開発におけるレビューは、品質向上のために重要です。客観的にコードを評価されることで、エンジニアは欠陥を発見でき、自身の技術力を向上できます。
レビューには簡単に行われる非公式的なものと、厳密にルールを決めて行われる公式的なものがあります。中でも、インスペクションは特に公式的なレビューです。
この記事ではインスペクションの目的や、他のレビューと違う点、インスペクションを実施するときの手順について解説します。
1.ソフトウェアレビューにおけるインスペクションとは
インスペクションとは、プロジェクトメンバー以外の第三者が事前に定められた評価基準に沿って、仕様書やソースコードに問題点がないか検証する会議のことです。
インスペクションはソフトウェアレビューの1つであり、他のレビューに比べて公式的なレビュー方法とされています。
インスペクションは、欠陥を漏らさずにチェックし、次回以降の開発計画につなげることを目的に行われます。
1か月トライアル無料：詳細はこちら
1-1.ソフトウェアレビューの主な種類
システム開発でのミスを防ぐためのソフトウェアレビューには、さまざまな種類があります。成果物に対して行われるレビューを3種類紹介します。
・アドホックレビュー
アドホックレビューは、手の空いた同僚などの身近な人物にチェックをお願いするレビュー方法です。非形式的なレビューで、仕様書に記載のない点についても確認してもらえます。気軽に実施できますが、タスク化が難しく、優秀な技術者に依頼が集中しやすいというデメリットがあります。また、即席のレビューであり細かなルールが決まっていないため、レビューの精度は担保されません。
・ウォークスルー
ウォークスルーとは、作成者が数人の評価者に成果物の説明をしてコメントを求めるレビュー技法です。ウォークスルーは、定義された手順はなく、記録もとりません。作成者が司会者となって進めていくため、作成者の説明内容によっては、欠陥が見過ごされる可能性があります。
・チームレビュー
チームレビューとは、開発チームメンバーで行う公式的な方法です。インスペクションほど厳格な決まりごとはなく、手順や役割、チェックリストはチームごとに決める必要があります。記録はとりますが、その後のデータ分析などは行わず、開発メンバーの中で課題や解決策などの擦り合わせを目的に行われます。
2.インスペクションの特徴と他のレビューとの違い
インスペクションは、他のソフトウェアレビューと比べて厳密に定められたルールに従って行われるのが特徴です。インスペクションの特徴と、他のソフトウェアレビューの違いについて解説します。
2-1.コードの作成者が運営に絡む役につけない
インスペクションを行うときは、レビューの対象となる成果物の作成者を運営に絡む役につけてはいけないというルールがあります。
運営に絡む役につけないのは、感情的になって客観的な立場を維持できなくなるのを防ぐことが目的です。作成者自身が成果物の説明をすると、不安な部分は情報をぼかしたり、飛ばしたり、資料にない補足説明をしたりする可能性があります。また、成果物に対しての欠陥や課題を指摘されたときに、感情的になってしまう人もいるでしょう。
くわえて、コードの作成者が運営に絡む役職につけないルールには、作成者が他の作業で気を取られて説明を聞き落とすことを防ぐ目的もあります。自分の成果物の説明を第三者から聞くと、コードの作成者は解釈の違いによる欠陥などを発見しやすくなります。コードの作成者が説明や指摘の内容に集中するためには、役職につけないルールが必要です。
2-2.レビュー参加者の役割が明確に定められている
レビューの1つであるウォークスルーでは、状況に応じて各自が役割をこなすのに対して、インスペクションでは、参加者の役割が明確に定められているのが特徴です。基本的に参加メンバーは兼任を行わず、以下の役割に分かれます。
・レビューイ
レビューの対象となるコードの作成者で、運営側の役職にはつけません。
・レビュアー（インスペクター）
コードのレビューを担当する運営側のメンバーです。開発の関係者だけでなく、ユーザーや開発と直接関係しない第三者が加わり、客観的な視点を提供することが望ましいとされます。
・プレゼンター
コードについての説明を担当する運営側のメンバーです。
・モデレーター
インスペクションレビューのマネジメントを担当する運営側のメンバーです。参加メンバーの選定・計画書やチェックリストの作成・日程調整などはモデレーターの役割です。
・レコーダー（記録係）
レビューで指摘された内容を記録する、運営側のメンバーです。他のメンバーが議論に集中できることを目的とします。
2-3.欠陥の収集・分析まで行う
インスペクションを行うときには、検証を行って終了するのではなく、指摘された問題点や課題に向けての解決方法などを記録として残し、欠陥の収集や分析まで行います。欠陥の分析によって次回以降の開発では余計な工程を省くことができ、開発チームの負担軽減が可能です。
3.インスペクションを実施する場合の流れ
インスペクションは他のレビューより厳密なルールに従うことで、客観的にコードの欠陥を洗い出し、問題を改善して次回以降の開発につなげることが目的です。
インスペクションを成功させるためには、以下のような定められた手順を守り、インスペクションを行うことが必要です。
3-1.インスペクションの計画を立てて参加メンバーを決める
インスペクションを行うタイミングや評価対象、収集データの共有・分析方法などを決めた上で、参加メンバーを選定して役割を決めましょう。すべて決まり次第、計画書を作成し、参加者に共有できるように準備します。
役割を決めるときには、レビューイを運営に絡む役につけられない点・役割の兼任ができない点に注意しましょう。
3-2.参加メンバーへの概要説明を行う
インスペクションを実施する前に、作成した計画書をもとに、参加者全員へ概要説明を行います。インスペクションを円滑に進めるには、レビューを実施する目的や狙い、役割分担などを参加メンバーに事前に理解してもらうことが重要です。
また、概要説明を受けられなかったメンバーのために、計画書はレビュー関係者がいつでも閲覧できる場所に保管しておきましょう。
3-3.各個人がコードのインスペクションを行う
概要説明の終了後、計画書に記載された手順に従って、成果物のインスペクションを個人で実施します。レビュアーに選ばれた人はチェックリストに記載のある項目を検証し、不具合があれば記載します。
インスペクションの際には、技術的に高い知見を持ったレビュアーと、他のレビュアーを区別し、チェック内容を割り振りすることが重要です。技術力の高いレビュアーは、自身でも重要なソフトウェア開発の上流工程に携わっているケースが多く、個人のインスペクションが負担になる可能性があります。技術的な知識が必要ない項目は他の人に割り振り、技術的な知識が必要な項目のみチェックしてもらうといった工夫により、インスペクションを効率的に進められます。
3-4.インスペクション会議を開く
個人のインスペクションが終了したら、計画書のスケジュール通りにインスペクション会議を開きます。インスペクション会議では、必ずしもレビューをチェックリストの順番に進めていく必要はありません。レビュアーが特に疑わしいと感じた部分から指摘を始め、問題点を明らかにしていく方法もあります。
インスペクション会議で決まった項目や判定結果は、レコーダーがすべて記録し、不具合表を更新します。インスペクション会議での指摘項目がない場合、エビデンスとして事前に実施した個々のチェックリストを集めて、会議の記録として残すようにしましょう。
3-5.コードの修正とフォローアップ・原因分析を行う
レビューイは、インスペクション会議で記録された内容を参考に、コードを修正します。修正完了後は、リストに記載されている修正の必要な部分が改善できているか確認するフォローアップ作業から、修正が必要になった原因分析まで行います。
多くの問題が発見された場合、レビューイが修正作業を強く負担に感じ、モチベーションが下がってしまわないよう注意しましょう。コードの品質を大きく改善したレビューイには、別のインスペクションで運営側として参加するときにより少ない作業を割り振るなどの工夫をするのがおすすめです。
まとめ
インスペクションとは公式的なソフトウェアレビューであり、欠陥を漏らさずにチェックし、次回以降の開発計画につなげることを目的としています。レビュー方法や手順が明確に決まっている、レビューイが運営側の役職につけない、欠陥の収集・分析まで行うといった点が特徴です。
インスペクションを実施する場合、まず計画と参加メンバーを決め、概要説明を行った上でレビュアーがコードをインスペクションします。その後インスペクション会議を開き、指摘された欠陥をレビューイが修正します。
手順に沿ってインスペクションを行うことで次回以降の開発では余計な工程を省け、開発チームの負担軽減が可能です。
