- [レビューのシナリオの作成とレビューのしかた](#レビューのシナリオの作成とレビューのしかた)
  - [はじめに](#はじめに)
  - [レビューのシナリオの作成のしかた](#レビューのシナリオの作成のしかた)
    - [検出すべき問題種別の選定](#検出すべき問題種別の選定)
    - [システムの目的、特徴、価値を明らかにするには](#システムの目的、特徴、価値を明らかにするには)
    - [シナリオの作成](#シナリオの作成)
    - [シナリオの順番決め](#シナリオの順番決め)
    - [ソースコードの品質属性](#ソースコードの品質属性)
  - [レビューをする](#レビューをする)
    - [レビューできる量、時間](#レビューできる量、時間)
    - [レビューで見つけた欠陥を記録する](#レビューで見つけた欠陥を記録する)
  - [このあとは](#このあとは)
  - [参考文献](#参考文献)


<a id="orgb2942e1"></a>

# レビューのシナリオの作成とレビューのしかた

2016-12-12 ごろ作成


<a id="orgb9b5bc3"></a>

## はじめに

レビューは大変です。なぜ大変かというと、それはたぶん、何をチェックすべきなのかを毎回考えないといけないからだと思います。

何をチェックすべきなのか、「どこ」を「どのように」調べるのかを具体的に記述した文を、「レビューのシナリオ」と言うことにします。
『なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版』 (以下、森崎修司(2015)) に、レビューのシナリオを作成する方法が書かれていました。
この文書ではその方法を紹介したいと思います。加えて、他の本からの引用もまじえつつ、レビューのしかたについても提案したいと思います。

森崎修司(2015) では、主にウォータフォールモデルにおける設計レビューのしかたについて解説しています。
ウォータフォールモデルでは、前の工程で発生した欠陥は後の工程の工数に多大な影響をおよぼします。
そのため森崎修司(2015) では「レビューの目的は(後工程での)修正工数を減らすこと」を強調しています。

そして、レビューをすることについて重要な点として次の点を挙げています。

-   問題を指摘すると、修正工数の低減につながるかどうか
-   修正工数を低減させるために、指摘すべき問題をすべて洗い出しているか


<a id="org4c1a1fb"></a>

## レビューのシナリオの作成のしかた


<a id="orga63f9ae"></a>

### 検出すべき問題種別の選定

まず 1〜2時間をかけて、検出すべき問題種別の選定をするそうです。

「問題種別」という用語については、森崎修司(2015)では未定義のまま使われています。
推察しますと、おそらく「問題の種類」とか、個別の問題をいくつか束ねて一般化をしたもの、というような感じだと思います。

問題種別は、次の4つから得られるそうです。

1.  以前の類似タスクにおけるレビューでの指摘内容
2.  以前のテストで見つかった不具合 (つまり以前のレビューで見逃されたもの)
3.  見落として大きな手戻りが発生しそうなもの
4.  システムの本来の目的や最も大事な機能について考え、システムの価値を明らかにする。その価値を阻害する問題種別

上の 4. についての詳細は次のとおりです。

レビューの対象が「現状困っている事象を解決する」もの(つまり欠陥修正など)でしたら、その事象を解決できるかどうかを問題種別にします。

レビューの対象が新機能だったり、新システムの場合はこうなります。
まず、その新機能がビジネスや業務へサービスする内容を列挙します。その中から価値となるものを見つけます。
言い換えると、顧客からの要求に隠れているような、本当に重要なシステムの価値を割り出します。
その価値を阻害するものを問題種別とします。

上の 1. から 4. のアプローチによって考えた問題種別を5〜10個を目安に絞り込みます。


<a id="orgcac5942"></a>

### システムの目的、特徴、価値を明らかにするには

前節の 4. についての補足です。森崎修司(2015)に載っていた、「アカウント認証システムの特徴と価値」の例です。
そのアカウント認証システムの目的は、「グループ会社向けアカウント認証をサービスする」です。

その特徴は次のとおりです。

-   多くの社内システムの認証に使われる
-   社員が増えたりして認証回数が増えることがある
-   利用状況の把握ができていない
-   時間帯によってはスループットが低下することがある

つまり、そのシステムの価値はこうなります。

-   アカウント認証を正しく行うことができる
-   スループットが安定する
-   サーバ増強の判断が適切にできる


<a id="orged1e2b2"></a>

### シナリオの作成

問題種別を作ったら、指針となるシナリオを作成します。
ここで言うシナリオとは、選定した問題種別を検出するために、「どこ」を「どのように」調べるのかを具体的に記述した文のことです。

例: 機能間で入出力の不整合がないか調べるため、インターフェース定義をチェックする。入出力の項目の名前と型が一致することを確認する。

レビューのシナリオを作成する人(レビューのモデレータ)とは別に、単にシナリオにそってレビューをする人(レビューア)を設ける場合があります。
ですので、実際にレビューをする人(レビューア)の知識に依存しないように、具体的に「どこ」を「どのように」調べるのか記述するようにします。

前の節の「アカウント認証システムの特徴と価値」の例から導かれるシナリオは次のとおりです。

-   ネットワーク機器の性能が対象ドキュメントに明記されているかチェックする。明記されている場合、機器の仕様と付き合わせて誤りがないか調べる。
-   ネットワーク構成図から、認証システムのあるネットワークの最大帯域が、認証を受け取るネットワークの帯域と同じかそれよりも小さいかチェックする。
    -   その際、認証システムの最大帯域は、今後の拡張があることを前提に置く。


<a id="org263af26"></a>

### シナリオの順番決め

シナリオが出揃ったら、どのシナリオが重要か優先順位を決めます。指針となる点は次のとおりです。

-   修正工数やリスクの低減効果が大きいシナリオを優先する
-   次に優先すべきなのは、漏れに関するシナリオ
-   その次は、曖昧さに関するシナリオ


<a id="orgf0fc458"></a>

### ソースコードの品質属性

「ピアレビュー 高品質ソフトウェ開発のために」(以下、 Wiegers (2004)) の p.106 では、 製品の品質属性として次の7点が挙げられています。
レビューのシナリオとして適切なものが思いつかなかったときに参考になるかもしれません。

-   保守性 maintainability: 別保プログラマにとってコードがどれほど理解しやすく変更しやすいか。よく構造化され、十分コメントがついているか。
-   堅牢性 robustoness: 予想外の稼働条件の下で製品がどう応答するか。不正な入力または入力がない場合に備えて、デフォルトが指定されているか。
-   信頼性 reliability: fault tolerant 対障害性があるか。効果的な例外処理とエラー回復の仕組みを有しているか。
-   効率性 efficiency: プログラムがメモリ容量またはプロセッサをどれくらい使うか。アルゴリズムは最適化され、不必要な演算は回避されているか。
-   再利用性 reusability: コンポーネントは他のアプリケーションに再利用できるか。プログラムはよく分割され、モジュール化された設計で凝集度は強く、結合度は緩くなっているか。
-   完全性 integrity: ソフトウェアやデータが、許可されていないアクセス、情報損失、変更、ウィルス感染から守られているか。
-   拡張性 scalability: システムはより多くのユーザー、サーバー、データ、その他のコンポーネントに、許容できる性能とコストで適応できるか。


<a id="org9fa67dd"></a>

## レビューをする

レビューアはシナリオをもとにレビューをします。レビューは次の点に注意して行います。

-   レビューの目的を見失わないように、シナリオにそって問題検出する。
-   問題検出が目的で、修正はしない。
-   まず一つの観点だけで通読する。複数の観点で一度にまとめてチェックしない。
-   複数のシナリオをチェックするとき、各シナリオで時間配分のムラが起きないようにする。

ただ注意したいのは、森崎修司(2015)の主題は、何十ページもある自然言語で書かれた設計文書のレビューのしかたについてです。
Agile 開発を採用していて、レビューの対象がコードであったりする場合は、多少やりかたを調整できる余地がありそうな気がします。
でもブラウザからテストをするときは、漫然と UI を操作するのではなく、シナリオを立ててそれに従って問題検出をするほうがチェック漏れが少なくなりそうな気がします。


<a id="org7fdde0f"></a>

### レビューできる量、時間

『Code Complete 第2版』の 21.3 節では次のようなことが書かれています。

-   1時間でレビューするのは、1時間に100行ほど
-   レビューミーティングで解決策を話し合ってはならない。参加者はエラーの検出に全力を挙げること。
    -   誰かがエラーと考えるような紛らわしいものならば、設計、コード、ドキュメントを明確にする必要がある。
-   レビューミーティングは、一日1回2時間以内
-   解決策は3時間目以降に話し合うのでもよい。

Wiegers (2004) では次のようなことが書かれています。

-   1時間で調べられる平均コード行数 (インスペクション速度 LOC/時間) は、150~200 ほど。  (p.87)
-   要求仕様、設計書、プロジェクト計画のようなテキスト文書では、1時間あたり3〜4ページ


<a id="org7daeb0d"></a>

### レビューで見つけた欠陥を記録する

他のレビューで指摘を再利用できるように、見つけた欠陥を記録します。
Wiegers (2004) では 7.3.3 節「欠陥と課題を記録する」のところで、次のような記録のしかたを推奨しています。

発生源:

-   どの工程で欠陥が発生したかを記録します。
-   Wiegers (2004) ではウォータフォールモデルをもとに話を進めていますから、発生源として要求、設計、実装、テストから選択するようになっています。
-   欠陥がどの工程で多く作り込まれたのかわかれば、特にその工程の後のレビューを厚くするように改善することができます。

種類:

-   各項目がどんな種類の課題や欠陥であるかを記録します。
-   Wiegers (2004) では種類として次のような分類が紹介されています。
    -   欠陥
        -   上流の成果物からの欠落 、 作業漏れ
        -   ロジックの間違い、計算式の間違い、要求の不正語などの誤り
        -   過剰または不要な要素
        -   使い勝手や性能に悪影響を及ぼす因子
    -   課題
        -   疑問
        -   基準違反の様式 (コーディングスタイルなど) への提案
        -   明確化する必要のある場所。曖昧さの残っている箇所。

重要度:

-   欠陥の相対的な重要度を記録します。
-   大きい欠陥とは、下流工程への影響が大きく、手戻りや顧客の問題で無駄な時間が発生するような欠陥のことです。

これは個人的な考えですが、上のように詳細に形式に則って欠陥を記述するのは煩雑な気がします。
上のように一定の形式にあてはめて欠陥を記述する目的は、あとでレビューの結果を統計的に分析しやすくすることだと思います。
そこまでする予定がまだないなら、自由文形式で欠陥についてのコメントを詳しく書くだけでもいいのかなという気はします。


<a id="org593c6e2"></a>

## このあとは

Wiegers (2004) には、レビュー結果(インスペクションデータ)を分析する方法が書かれていました。
これについてはあとで別の文書にまとめたいと思います。


<a id="org60d95f0"></a>

## 参考文献

-   森崎修司(2015)『なぜ重大な問題を見逃すのか？間違いだらけの設計レビュー改訂版』日経BP
-   Steve McConnell (2005)『CODE COMPLETE 第2版』日経BP、 21.3 節
-   Karl E. Wiegers (2004)『ピアレビュー 高品質ソフトウェ開発のために』大久保雅一 監訳、日経BPソフトプレス