2024.02.07
ソフトウェアの品質を向上させるひとつの方法に「ソフトウェアレビュー」があります。
「レビューは必要」という認識は多くのエンジニアが持っているにもかかわらず、「レビューは無駄」と感じているエンジニアも少なくありません。その原因は、効果的なレビュー方法を知らないからかもしれません。今回はレビューの必要性に立ち返り、を行う方法について紹介していきます。
- もくじ
そもそもレビューは必要なのか？
そもそもレビューは何のために行うのでしょうか？
ソフトウェアレビューはソフトウェアの品質を高めるために、設計や実装などの各工程で「次の工程に進み得る状態にあること」を確認する作業です。
そのため、できるかぎりの知恵と知識を集め、客観的に成果物を評価し、事前に欠陥を検出し、継続的に開発することが求められます。
ソフトウェア開発はヒト・モノ・カネが有限であるからこそ、限られた開発工数を有効活用するためにもレビューは欠かすことのできない作業なのです。
「レビューは必要」が「レビューは無駄」になるワケ
欠陥検出、予防、そして生産性向上を実現するうえで多くのエンジニアが「レビューは必要」と認識しています。
ところが、実際の現場を覗いてみると以下のような理由から「レビューは無駄」と感じているエンジニアも少なくありません。
- レビューにかかる時間（工数）を確保できない
- かけた時間（工数）に対して有効な指摘が少ない
- レビューアによって指摘内容がバラつく
決して好ましいことではありませんが、場合によっては時間や余裕がなくなるとレビューそのものを省略してしまうこともあるようです。
「レビューは必要」が「レビューは無駄」になってしまうのは上記のように環境や状況などに左右される理由もありますが、レビューの手法や種類が多いために「実施すること」が目的となり、正しく理解されないまま形式的に行われていることも要因としてあるでしょう。
開発現場でどんなレビューが行われているか？
開発現場で実施されているレビューについて代表的なものを紹介します。
a) インスペクション
インスペクションは最も体系的で厳格なレビューです。
レビュー参加者に「レビューア」や「モデレータ」といった役割を与え、事前に定められた手順とチェックリストに従ってレビューを行い、欠陥や矛盾をその場で修正することを目的としています。
プロジェクトメンバー以外の第三者も参加し、成果物の品質を検証します。
レビュー対象はソースコードの他、プロジェクト計画、要件定義、設計などの各工程におけるドキュメントも含まれています。
b) チームレビュー
チームレビューは開発チームが行うレビューです。
インスペクションのような標準的なルールは存在しないため、手順やチェックリストはチームごとに定める必要があります。課題やその解決策について、チームメンバー間で合意を行うという目的があります。
c) ウォークスルー
ウォークスルーはレビューを希望する作成者（レビューイ）が数人の指摘者（レビューア）へ説明を行うレビューです。
第三者が参加しない非公式なレビューで、レビューイが作業の中心となることから「レビューイのためのレビュー」という目的があります。
d) ピアレビュー
ピアレビューはレビューイとレビューアがペアを組み成果物を確認するレビューです。
新人の育成目的に行われることが多く、成果物の欠陥と改善の機会を探します。
指摘内容がレビューアの経験や技量に依ってしまうところがあります。
e) パスアラウンド
パスアラウンドはこれまでのレビュー方法と異なり、多重かつ同時進行型のレビューです。時間的、空間的な理由で会議を開くことが難しい場合でも指摘結果を集めることが目的です。
レビュー対象となる成果物を電子メールやグループウェアを通して複数のレビューアに配布し、複数の指摘を依頼します。
ミーティング形式で行わないため簡易に指摘が欲しい場合に有効ですが、レビューアが積極的でない場合は指摘をもらえないこともあります。
f) アドホックレビュー
アドホックレビューは必要に応じて対応可能なレビューアに実施してもらう即席レビューです。即席で見てもらうことで、仕様書にない点もレビューしてもらう目的で行われることがあります。
レビュー記録を作成するなどの必要がないので気軽に実施できる反面、チーム内の優秀なレビューアにレビュー依頼が集中し負担になってしまうことがあります。
先に紹介したレビューの種類はほんの一部ですが、それぞれ目的や手法が異なっていることを把握できたのではないでしょうか。開発状況に応じてそれぞれのレビューを使い分けることで、「レビューは無駄」という感情から脱却する一歩になることでしょう。
効果的なレビュー方法とは
「レビューは無駄」から脱却するには、レビューの目的や手法を知るだけでなく、効果的なレビュー方法を実施することが有効です。
効果的なレビューを実施するには、チーム内でレビュー運用の決め事を用意しておくとスムーズです。
ここではレビューを始める前の準備段階に注目した決め事について紹介します。
1) 必要なレビュー観点を明確にする
レビューアによって指摘内容がバラついてしまうことは、「レビューアが指摘できることしか指摘していない」と解釈することができます。
レビューイが何を期待して依頼をしているのか、レビューイが明確に伝え、レビューア側もきちんと認識することで両者の間のすれ違いを防ぐことができます。
このようにレビューする観点を事前に設けることで、レビューで扱う・扱わないを切り分けることができ、狙いを定めたレビューを実施することができます。
レビューする観点に応じてレビューアを選定することも重要です。システムの使いやすさを確認してほしければ普段システムを使ったことがない人を選定する、作業内容であればチームメンバーを選定するといった具合です。
2) レビュー実施タイミングを決める
レビューする時間がない、という状況は実際に時間が足りない場合もありますが、後回しにするために捻出できないという場合も少なくありません。
後回しにするということは開発終盤にレビューを実施することとなり、レビューアにとってはレビュー対象が膨大に、レビューイにとっては指摘事項と修正内容が膨大になり、互いに負担と作業量が多くなってしまいがちです。
また、バグ混入からバグ検出までのリードタイムが長くなると、手戻り工数が膨らみ、生産性が低下し、品質確保が困難になってしまいます。
そこで、どのタイミングでレビューを実施するかをチームで事前に決めると良いでしょう。
例えば「モジュールのテストコードがパスしたタイミング」、「開発ブランチからステージングブランチにマージするタイミング」など、安定した開発を継続していくためにリードタイムを短くする工夫が必要になります。
3) レビュー単位を決める
レビューのタイミングだけでなく、1回あたりのレビュー規模を決めておくとよいでしょう。なぜなら、機能によっては作業量が大きすぎる場合があるからです。
人間の集中力に関する研究(*1)では、短い時間を複数回実施するほうが集中力を維持できるという結果が出ており、ソフトウェアレビューにおいても例外ではありません。
たとえば、レビュー単位を1回あたり30分程度でチェックできる程度とすることで、レビューア、レビューイの精神的・体力的な負担の軽減につながり、レビュー本来の目的である品質向上に寄与していけるはずです。
「ダメなところ」だけでなく「良いところ」もコメントする
レビューを円滑に進めるうえでチームのレビュー文化を無視することはできません。
理由はレビューが「成果物への指摘」だからです。
残念ながらレビューアの心無い指摘を起点としたさまざまなトラブルが起きることもしばしばあります。
レビューアが心がけたいのは「レビューは人格否定ではない」ということです。レビューアが行うのはあくまでレビューイの支援です。
出来・不出来にフォーカスし断定的な物言いをするのではなく、目的にフォーカスし相手が受け取りやすい伝達が重要です。
そして「良いところ」をフィードバックすることも重要です。
レビューといえば「ダメなところ」ばかりを指摘するイメージがありますが、それだけではチームの雰囲気は悪くなりがちです。
「良いところ」をフィードバックすることは雰囲気を良くするだけでなく、レビューイの工夫を発見する機会にもなります。
避けられるトラブルを確実に避けるためにも、良い雰囲気でチーム内のレビュー文化を醸成していく必要があります。
現状のレビュー方法をレビューする
レビューの必要性に立ち返り、「効果的なレビュー」を行うための方法として準備段階における決め事や、チーム内のレビュー文化を醸成していく必要性について紹介してきました。
レビューはソフトウェアの品質を向上させる方法であると同時にチームの生産性を向上させる方法であり、チームの成長を促す機会です。
また、よりよいレビューを実施していくには「ふりかえり」がとても重要です。
「KPT」などのふりかえりフレームワークを活用し、現状のレビュー文化についてふりかえり、組織・チームとして目指す目的、今後の方向性、そしてチームメンバー各自がやるべきことについて、チーム全員で同じ認識を持つことが大切です。
（*1）参考サイト
集中力の維持と長期的な学習効果につながる方法（東京大学・池谷裕二教授の見解）|朝日新聞デジタル
http://www.asahi.com/ad/15minutes/article_02.html
