Top / レビュー

レビュー

目次 †

レビュー †

• システム開発は複数人で作業を分担し、並行して進められる。このとき担当者だけで作業を進めると、思い込み・ミスなどで間違った結果や成果物を出してしまうことがある。これを防ぐために各工程の終了時に担当者や関係者が集まって内容のチェックを行うためにレビューを行う。
  • つまり、レビューは欠陥除去の方法といえる。
• 静的テストの技法の一種。
• すべてのソフトウェア作業成果物はレビュー可能である。
• 動的テストの実行前に行うと大きな効果がある。
• 要求仕様の漏れなどの機能や処理の抜けを動的テストよりも簡単に見つけられる。
• メモリリークのようなバグはレビューによって見つけにくい。
  • 動的テストを行った方が効率がよい。
• レビューには開発の工程によって、その対象や方法が異なる。
• レビューとは、設計内容や作成内容の検討会であり、開発者以外の第三者の目を加えることによって、バグの検出を目的とする。特にウォーターフォール型の開発の場合、ある工程の作業内容が、次の工程の入力となるために、バグの内容が次々に下流工程に引き継がれてしまい、修復に要するコストが増大していってしまう。そこで、テスト工程だけでバグの検出をするのではなく、各工程内でもバグを取り除くのが好ましい。そこでレビューが活用される。
• コードの作成者と説明者は分けたほうがよい。
  • 作成者は実際にコードに書かれている内容ではなく、自分が書いたつもりのコードを説明しがちだからである。
  • よって、作成者と説明者が同じ場合は、他のレビューアは本人が実際のコードについて説明しているかを注意を払う必要がある。
• コードのレビュー時にソースコードの印刷物を使う場合は行番号も表示する。またプロジェクタやモニタ上でレビューする場合は、IDEのエディタに行番号を表示させておく。すると、レビュー時に行番号を用いて的確に指摘することができる。
• プロジェクタやモニタ上でレビューする場合は、レビュー用のソースをコミットしておく（レビュー用のソースを用意するのは、本番用のソースコードを汚さないようにするためである）。レビューで指摘があった場所にFIXMEなどのタスクコメントを随時追加していく（指摘者と対応者も記述しておくとレビュー記録票を各担当者が後で書く場合に便利）。レビューが終わったときに、タスクコメントの追加済みのソースコードをコミットする。そうすれば、レビューの前と後の差分によって、修正すべき点がすぐわかる。
  • さらに、次回レビュー時にはそれらの修正が行われたかどうかを確認するときに、過去のレビュー用の履歴を参考にすればよい。
• レビュー中はレビューに専念する。
  • バグを発見した場合は修正方針の議論に発展しがちである。簡単な修正であればその場でも指摘してよいが、設計の変更を伴うような場合はレビュー後に議論した方が効率がよい。
• 設計書やソースコードの規模によって行うべきレビュー時間が決められるようなプロジェクトの場合は、設計書やソースコードを作成する段階から意識しておく。
  • そうしないとレビュー時間が足りないという事態が発生する可能性があるため。
• コードレビューでの指摘事項に対して修正を加えた場合は、再度司会者に見せて、問題がない場合は司会者が承認する。つまり、レビュー記録票の修正確認者のところに名前を記述することで、修正が行われたことを第3者が確認したことが保証される。
  • ここでいう修正内容の承認というのは、バグが存在しないとか、これ以上修正する必要がないという意味ではなく、その時点では指摘事項に対して対応を行ったという意味である。
• レビュー時には漠然と行うのではなく、注目する観点を決めておくとよい。
  • 形式的なコードレビューではバグが発見できない。
• 大きな手戻りを起こさないためにも、コードレビューは小さな単位で頻繁に実施すべきである。
• レビュー工程がなかったり、その工程の時間が少ない場合は、各メンバーのコードを一律にレビューするのではなく、開発経験の浅い初心者のコードを中心レビューを行う。
  • レビュー工程の時間がある場合は、開発メンバーはレビューに参加すべきである。
• マルチスレッドの問題などはテストで発見しにくいため、特にコードレビューが重要となる。
• TDDを行っているからといって、コードレビューが必要なくなるわけではない。
• ペアプログラミングを行っているからといって、コードレビューが必要なくなるわけではない。
• レビューには個人レビューと全体レビューがある。
  • それぞれの目的は異なっている。
• 一般的な流れとしては、まず与えられたテーマに従って個人がレビューを行う。レビュアーごとにそれぞれ異なったテーマに絞ってレビューしてもらうことにより、複数のレビュアーが同じ指摘をする無駄を省くことができる。その後で個人レビューの内容を全体レビューで、その誤りや漏れについて確認していくことになる。

レビューのポイント †

　主にソフトウェア開発者の担当になる内部設計とプログラム作成におけるレビューのポイントは次の通りである。

• 内部設計
  • 外部設計で規定された機能が漏れなく設計されているか。
  • 内部設計上の考慮点（入力仕様、内部・外部インタフェースなど）が適切か。
  • 標準化された設計方法や記述方法に基づいて設計されているか。
  • プログラム開発へ配慮された内部仕様書になっているか。
• プログラム作成
  • 内部設計の内容に対して、必要十分な機能が正しく実現されているか。
  • プログラム規約、命名規則に準拠して、標準化を考慮しているか。
  • プログラムの保守性を考慮して、構造化プログラミングを行っているか。
  • 規定された部品などを正しく使用しているか。

登場人物 †

• マネージャ
  • レビューを実施することを決め、実施のスケジュールを立て、レビューの目的が適切かどうかを判断する。
• モデレータ
• レビューア（インスペクタ、チェッカー）
  • ある特定の技術やバックグラウンドを持つ各個人。
  • 必要な準備の後に、レビュー対象物に対して気がついたこと（例えば欠陥）を示したり、述べる。
• 書記（記録係り）

レビューの分類 †

• 設計レビュー
  • プログラム開発者、プログラミング担当者、内部設計担当者などが参加し、あらかじめ決められたレビューチェックシートに従ってプログラミング設計者が説明し、出席者がプログラム設計に間違いなどを指摘する。
• デザインレビュー
  • 設計段階で行うレビュー。
    • 外部に対して行う。
    • 機能仕様書、入出力概要仕様書、ファイル概要仕様書、コード仕様書、テスト仕様書などの設計仕様書を対象に行う。
• プロジェクトレビュー
  • プロジェクト全体で行うもの。
• ピアレビュー
  • プロジェクト内のチームで行うもの。

レビュー技法 †

ウォークスルー（walk through） †

• ソフトウェアの作成者自身が主催する自主的なレビュー。
• 開発者がレビューイ（レビューで指摘を受ける人）となり、自分が書いたソースコードのリストをレビューアへ配布へ、そのプログラマの処理の流れ（シナリオ）に沿って説明する。
• 仕様や設計を行った者の言い訳の場でも、自己正当化の場所でもない。あくまでも今後にバグを残さないようにするための場である。

従来のレビューとの比較 †

　従来のウォークスルー以前のレビューの問題点として、次が挙げられる。

• レビュー対象のソフトウェアに対する批判会になりがち。
  • その結果、ソフトウェア作成者は防御的になり、前向きなミーティングとならない。
  • さらに、長時間に渡る会議になり、参加者の思考能力が低下する。

　この問題点を排除したのが、ウォークスルーである。ウォークスルーではレビュー本来の目的である問題点の早期発見と除去を実現化するために、次のような原則の下で行われる。

• レビューイ（レビューを受ける側）がミーティングを主催し、問題点を見つける能力のある少数の参加者（5,6人）に出席を求めて実施する。
  • 各参加者は、それぞれ別の視点からソフトウェアをレビューする。
• ウォークスルーの結果を、レビューイの業績評価に利用しない。よって、上司などの人事権限の持つ人は、原則として参加しない。
• レビューア（レビューをする側）は自分の役割を認識し、期待されている視点からレビュー資料を事前に検討しておく。
  • レビュー資料とは、ウォークスルーの目的、参加者各々の役割、スケジュール、レビュー対象の設計書やソースリスト、レビューチェックリストなどである。
• エラーの発見を中心に行い、エラー内容は文書化するが、修正方法などの検討や実施は、レビューイの責任においてレビュー終了後に行う。また、大きな問題点が発生した場合には、その修正内容について再度レビューを行うこともある。
• 実際のレビュー時間は、1〜2時間の短時間で行う。
  • 時間は厳守し、エラーの多発などで時間が不足した場合には、後日に改めてスケジューリングする。

仕様書ウォークスルー †

• システムの設計要因または機能仕様書をレビューする。
• 参加者：仕様書を作った担当者、システム分析者（設計者）、ユーザー
• 仕様書の中の問題点、あいまいな仕様、仕様の漏れを探す。

設計ウォークスルー †

• 参加者：設計担当者、システム分析者
  • 参加者の中に技術に携わっていない管理者が加わるのは一般的によくないとされる。
    • ウォークスルーの目的はバグを抽出するためのものである。しかし、その場に管理者がいるとバグを抽出することに対して心理的圧迫を加えてしまう可能性があるためである。

インスペクション（inspection） †

• ＝インスペクションレビュー
• モデレータ（moderator）と呼ばれるインスペクションリーダーが中心となって行う組織的なレビューである。基本的な原則はウォークスルーと同じであるが、次の点で異なる。
  1. モデレータの存在
     • モデレータとは、レビューについての知識や技術を持つ専門家である。
     • モデレータは、インスペクションを主催し、出席者の選定や、発見されたエラーの修正内容の承認までを行う。
  2. レビュー結果のフィードバック
     • インスペクションで指摘された内容については、モデレータによって記録され、分析される。
     • そして、この結果はソフトウェア作成上の留意点として周知され、エラーの未然防止のために活用される。
     • また、インスペクションで利用するエラーチェックリストにも反映されて、レビュー品質の強化が行われる。
• 形式の決まったフォローアッププロセスがある。
• 他のレビューよりもプロジェクトマネジメント色が強い。
• 標準化された開発プロセスで決められたチェックポイントに従って、レビュー対象の設計書やプログラムが作られているかを形式的なプロセスで進める。
• インスペクションでは、メソッド当たりのステートメント数、クラス当たりの欠陥数、プロジェクト全体の欠陥原因別の推移などの尺度（メトリクス）が使われる。
• インスペクションで欠陥が発見された場合は、単に欠陥の修正だけで終わるのではなく、欠陥が修正されたことを確認する再レビューなどのフォローアップが行われることもある。

コードインスペクション †

• 作成されたプログラムのコードを対象に、プログラムリストを1行ずつ読みながら行うレビューをコードインスペクションという。

テクニカルレビュー（technical review） †

• 技術的なことに的を絞ったレビュー。
• 技術的な問題の発見、解決策の決定、選択されている技術に起因する欠陥の発見、選択されている技術が他の技術的な選択肢よりも適当であるかの評価が行われる。
• レビューアはアキーテクト経験者やスペシャリストがふさわしい。
• テクニカルレビューは標準化されたレビュープロセスに沿って進められ、標準で用意されたチェックリスト、レビューレポート（議事録）、指摘点の一覧が用いられることもある。

ラウンドロビンレビュー †

• 参加者が順番に説明役を受け持つ方式。
• 参加者全員がそれぞれの分担について、レビュー責任者を務めながらレビューを行う。参加者全員の参加意欲が増す。

非公式レビュー（informal review） †

• 特に決まったやり方があるわけではなく、レビューア（レビューで指摘する人）が少人数なので、レビューの効果はレビューアの技量に大きく依存する。
• XPのペアプログラミングは非公式レビューの1つである。
• 決まったレビューのプロセスはない。

公式レビューのフェーズ †

1. 計画
   • 人選して、役割を割り当てる。
   • 公式性の高いレビューの場合（特にインスペクションレビュー）は、開始条件・終了条件を定義する。
   • ドキュメントのどの部分をレビューするか決める。
2. キックオフ
3. 個々の準備
4. レビュー・ミーティング
   • 結果を記述したドキュメントや議事録をもとに、議論し、その議論を記録する。
   • レビューの参加者は単に欠陥について述べ、欠陥の扱いに対する意見を示し、どう扱うかを決める。
5. 再作業
6. フォローアップ

レビューの効果 †

• コードレビューであればコードの質を上げること。
• 設計書のレビューであれば設計書の間違いをなくすこと。
• チームでレビューを行うため、仮に不具合がテストで発見されたとしても、コードを作成した人の責任ではなく、レビューでバグを発見できなかったのでチームでの責任になる。
  • つまり、原因の追及や対処の焦点が、個人ではなくプロセスになる。
• 開発メンバー全体のレベルを底上げすることができる。
  • 経験や知識が豊富なエンジニアからの知識の伝達が、開発メンバー（レビュー参加者）に対して効率的に行える。
  • ペアプログラミングと異なり、伝達された知識をレビュー出席者全員で共有できる。

レビュー記録票 †

• レビュー中にリアルタイムにレビュー記録票を書くと、後でレビュー記録票を書かなくてもよい。しかし、時間の都合やレビュー記録票を書く人がいないなどの理由があるに場合は、レビュー後にレビュー記録票を書くことになる場合がある。その場合に指摘点をレビュー記録票に反映するのを忘れないようにするために、工夫する必要がある。

レビュー記録票に記述する項目 †

• 日時
• 参加者
  • レビューイ、レビューア
• 工程
  • FD,DD,MK,UT,IT
• 対応者
• 指摘者
• 修正確認者、承認者
• 指摘内容
• 修正内容
• 修正対象
  • ソースコードのクラス名、ファイル名、行番号など
• バグの属性
• バグが混入した工程
• レビューのタイプ
  • 内部レビュー、グループレビュー

全体レビュー終了後のチェックポイント †

• 個人レビューの結果に漏れはなかったか。
• 誰のレビューに最も漏れが多かったか（与えたテーマは適切だったか）。
• 内容は議事録に漏れなく記録されたか。

参考文献 †

• 『ソフトウェア開発技術者試験対策　コンピュータサイエンス補足資料＋午後演習問題』
• 『ソフトウェア開発技術者　合格エッセンシャルハンドブック』
• 『演習で学ぶソフトウェアテスト特訓150問』
• 『The BUG』
• 『今すぐ使える!要求定義のチェックポイント427』
• 『プログラマー”まだまだ”現役続行』