「レビューの技法」を体系整理　技法や観点を効果的に使い分ける

## はじめに

◆この記事は何？

レビューの技法について体系整理した記事です。

◆対象は？

- チーム開発をしたい方
- レビューに関わる方
- 「ソフトウェア品質技術者資格試験」の勉強をしている方

◆この記事のねらい
レビューの技法を知ることで、より効果的なレビューを選択できるようになること

## レビュー

レビューの技法は次のように大分類できます。

- レビューの技法の分類
    - レビュー方法
        - 重要度や目的によって方法を選択する
    - 技術的な観点
        - 仕様やコードに基づく観点
        - フォールトに基づく観点
    - リーディング技法
        - レビューアがどのように対象を読むか
        - 読み方の一貫性を高めることで、リーディング技法を用いない場合よりもレビューの効果を向上できる
- レビューの種類
    - 成果物を確認する（いわゆる「レビュー」）
    - マネジメントレビュー
        - 経営層や管理職がプロジェクトの状況把握や承認のために実施する
    - オーディット
        - 法令、国際規格、社内規則に従っているかどうかを調べる

## レビュー方法

重要度や目的によって、レビュー方法を使い分けます。
レビュー方法についてまとめます。

- インスペクション
    - 標準や仕様から外れた例外、文書化された標準からの逸脱や文書化された要求仕様から見た障害などを発見するレビュー方法の一つ
    - 進行役や読み上げ係のように参加者の役割が明確になっていること
    - 正式な記録があること
    - 最も公式なレビュー
- チームレビュー
    - チームにより実施されるレビュー
    - 一般的に行われているレビューはチームレビューであることが多い
    - 障害や不明点の抽出という目的の他に、チーム内の知識共有、プロジェクト構成員の教育などの副次的な効果が期待できる
- テクニカルレビュー
    - 技術専門家が参加するレビュー
    - レビューアの役割に特徴がある
    - 仕様書やソースコードなどの成果物の問題抽出を主な目的とする
- ウォークスルー
    - 作成者が主体となる
    - 仕様書やソースコード等の成果物に対し、作成者を含め複数人の関係者が参加して会議形式で行う
    - 作成者が対象となる成果物をプログラムの処理の純也業務シナリオの順等に説明し、参加者が成果物や説明内容に対して質問やコメントを述べる
- ラウンドロビンレビュー
    - レビュー参加者が、司会者とレビューアの役を持ち回りで務める方式のレビュー
    - 全員が司会とレビューアを両方の視点を持つことで、レビュー対象への理解を深めることができる
- パスアラウンド
    - レビュー対象となる開発成果物を複数のレビューアに配布、または回覧を行うことにより障害の指摘を行う
    - モダンコードレビューはパスアラウンドの一つ
    - モダンコードレビュー
        - 専用ツールなどの利用を前提としたコードレビューの総称
        - 変更に焦点を当てる
- ピアデスクチェック(ピアレビュー)
    - 成果物の作成者に、机上での障害の発見に長けたレビューアを1名加えて実施するレビュー
    - レビューアが1人だけなので、運用しやすく、安価なレビュー方法
    - 参考：[情報システム用語事典 ピアデスクチェック（ぴあですくちぇっく）](https://www.itmedia.co.jp/im/articles/1111/07/news194.html)
- アドホックレビュー
    - 目の前の問題を解決するために、近くの同僚に声をかけて知恵を借りるという程度の非公式なレビュー
- ペアプログラミング
    - 2名が1つのマシンを共有して共同でプログラミングを行う方法
    - XP（エクストリーム・プログラミング）の代表的なプラクティス
    - ドライバー
        - タイピングを行う人
    - ナビゲータ
        - その様子から指摘や助言をする人

参考：
[SPC研究会 特別コース：ソフトウェアの品質保証の基礎 グループB ： ＜レビュー技法について＞](https://www.juse.or.jp/sqip/workshop/report/attachs/2005/report1.pdf)

## 仕様やコードに基づいた技法

仕様やコードに基づいた技法の目的は、プログラムを実行しても発見しにくい仕様やコードの妥当性を確認することです。

例えば、ソースコードの可読性、再使用性なども確認の対象となります。

- 形式手法に基づくレビュー
    - 形式手法の考え方を用い、仕様上の矛盾を数学的な証明によって検出し、一貫性を確認する
    - 離散数学的記法で仕様を表現し、モデル検証ツールなどにより仕様の一貫性、正当性を確認する
    - 参考
        - [形式手法とは？](http://formal.mri.co.jp/outline/)
- ATAM
    - Arcitecture Trade-off Analysis method
    - アーキテクチャトレードオフ分析方法
    - レビュー対象はアーキテクチャ
    - シナリオを用いてアーキテクチャを評価する
    - アーキテクチャが品質要求を満たすことを評価するために、ユーティリティツリーと呼ばれるツリーを作成する
    - 事例
        - [アーキテクチャトレードオフ分析方法](https://www.jaspic.org/event/2017/SPIJapan/session1C/1C2_ID015.pdf)
- インターフェース分析
    - レビュー対象はインターフェース
    - インターフェースの切り口のつながり方を確認する
- モジュール展開
    - レビュー対象はモジュール
    - 分割されているモジュールを一つの図などに展開し、モジュール分けの妥当性、インターフェース設定の適切性を確認する
- アルゴリズム分析
    - レビュー対象はアルゴリズム
    - ソフトウェアで実現するアルゴリズムに着目し、そのアルゴリズムの正確性や効率性などを確認する
- 複雑度分析
    - レビュー対象はソースコード
    - 複雑度のメトリクスに着目し、ソフトウェアの開発、変更、保守を行う際の困難性を評価する
- パストレース
    - レビュー対象はソースコード
    - 処理の中のパスと条件によるそのパスの組み合わせとしてのロジックを確認する
    - ラン･スルーはパストレースの一つ
        - ランスルー
            - 要求仕様から入力データと期待出力を想定し、内部仕様やプログラムの正確性を確認する
- 制御フロー分析
    - レビュー対象はソースコード
    - 制御フロー（IF-THEN-ELSE）に着目する
    - データ処理と制御に切り分け、制御フローの正しさ、効率などをレビューする
- 静的解析
    - レビュー対象はソースコード
    - ソフトウェアを実行せずに解析する総称
- 7つの設計原理
    - 障害を作り込まないために考慮すべき、コード構造上の核心観点
    - 単純原理
        - シンプルにこだわる
    - 同型原理
        - 形にこだわる
        - 同じことは同じように扱う
        - 例：数値の単位を統一する
    - 対称原理
        - 形の対称性にこだわる
        - 例
            - 上があれば下がある
            - 右があれば左がある
        - 対になっているものを考える
            - 例：あるフラグが立っているときの処理があれば、フラグが立っていないときの処理がある
    - 階層原理
        - 階層にこだわる
        - 例
            - リソースを取得したら、同じ階層でリソースの解放を行う
    - 線形原理・透明原理
        - 処理の流れは直線であることにこだわる
        - 状態の数をむやみに増やさない
        - 見通しが良いことを「透明」という
    - 明証原理
        - ロジックの明証性にこだわる
        - 一見して正しい、と言えるコードを書く
    - 安全原理
        - 安全性にこだわる
        - ありえない条件をあえて考慮してコードを書く
        - ありえないと思いつつ、NULLチェックを行う
    - 参考：[プリンシプルオブプログラミング](

## フォールトに基づいた技法
フォールトに基づいた技法とは、システムダウンなどの故障(フォールト)に基づいて検出される障害の未然防止により信頼性を確保する技法です。

次のように整理できます。

- ソフトウェアFMEA
    - Failure Mode and Effects Analysis
    - 故障モード・影響解析
    - 故障モードに着目し、その原因調査・影響評価を行うことにより、システムの信頼性を定性的に解析する技法
    - 参考
        - [観点を用いたソフトウェアにおけるFMEAの効率的・効果的な実施方法とその効果](https://www.ipa.go.jp/archive/files/000057619.pdf)
- ソフトウェアFMECA
    - Failure Mode, Effects and Criticality Analysis
    - FMEAに加え、故障発生の確率及び故障による影響の重大さの格付けを考慮する技法
    - 参考
        - [ソフトウェア故障モード影響致命度解析 (SFMECA) JSTQB Advanced Levelテストマネージャ資格のキーワード解説！](https://zenn.dev/devopsinqa/articles/9f847a004ff75a)
- FTA
    - Fault Tree Analysis
    - フォールトの木解析
    - 製品がフォールトなどの定義された状態に至る、単独または組み合わせの要因を識別して構造化するための技法
    - 参考
        - [FTAとは何 - フォールトツリーを超簡単に説明！](https://www.edrawsoft.com/jp/fault-tree-analysis-introduction.html)
- EMEA
    - エラーモード故障解析
    - FMEAをヒューマンエラーに対して適用した技法
    - EMEAの事例
        - [医療事故防止のための二軸統合プロセス分析手法](https://www.jstage.jst.go.jp/article/safety/48/4/48_228/_pdf/-char/ja)
- STAMP
    - システムを構成する要素間の**相互作用**に着眼したアクシデントモデル
    - 事例
        - [STAMP/STPAとは何か基礎から学ぶSTAMP/STPA（1）](https://monoist.itmedia.co.jp/mn/articles/1803/09/news013.html)
- STPA
    - System-Theoretic Process Analysis
    - 相互作用のハザードの要因を分析する技法
    - 複数の要素が相互作用している複雑なシステムの分析に向いている

## リーディング技法

レビュー対象を読む技法です。
レビューの目的に合わせてリーディング技法を選択することで、短期間でより多くの障害を摘出しやすくします。

次のように整理できます。

- アドホックリーディング
    - 特定の手順に従わない読み方
    - レビューの成果はレビューアのスキルに大きく依存する
- チェックリストベースドリーディング（CBR）
    - チェックリストをあらかじめ作成しておき、チェックリストを利用して読む方法
- シナリオベースドリーディング（SBR）
    - 利用シナリオや品質シナリオに基づいて読み進める
- ディフェクトベースドリーディング（DBR）
    - 障害が混入しやすい箇所の情報を含むシナリオを用意する
    - レビューアは、そのシナリオにそって読む
- パースペクティブベースドリーディング（PBR）
    - 特定の視点を割り当てて読む方法
- ユーセージベースドリーディング（UBR）
    - ユースケースシナリオのような利用手順に照らし合わせながら読む方法


## おわりに

この記事では、レビューの方法について体系的に整理しました。

より適切なレビュー技法を選択できるようになれば幸いです。

## 参考

[ソフトウェア品質知識体系ガイド － SQuBOK Guide － 第3版](https://amzn.asia/d/4AxXGxu)