シェア
ツイート
ブックマークソフトウェアレビューは、品質向上と開発効率アップに無くてはならない、非常に重要なものです。しかし、レビューを形だけ行って効果が得られなかったり、レビューの時間や回数が増大してレビューの参加者が疲弊してしまったりすることがあります。
そこで今回は、レビューが失敗する姿とその原因、レビューを価値あるものにするためのポイントをご紹介します。
レビューが失敗する姿
本題に入る前に、改めて、ソフトウェアレビューの目的に立ち返ってみましょう。
レビューの目的は、欠陥の早期発見による手戻りコストの低減です。
品質を向上させるためには、妥当な仕様を最初から正しく・漏れなく定義し、それに基づいて妥当な設計・実装を最初から正しく漏れなく行うように、様々な努力を払うことが基本です。
これが基本ではありながらも、仕様を定義するのも設計・実装するのも人間ですから、過ちや漏れ抜けはどうしても起こってしまいます。作り込んでしまった欠陥は、開発工程の後ろになればなるほど、欠陥は見つけにくくなり、かつ、手戻りコストは増大することになります。
そこで、レビューで早期に欠陥を見つけて早期に修正することで、手戻りコストを最小限に抑える必要があるのです。
しかし、レビューの目的を見失ってしまって、「レビューを実施した」という事実に満足してしまい、効果が得られないケースもあります。典型的な姿は以下があります。
・レビューで欠陥が検出できない
レビューは実施するものの、ほとんど指摘が出ないというものです。
レビュイー（レビューを受ける側）がレビュワー（指摘をする側）に説明するだけに留まり、レビューと称していながら、実態は単なる説明会となっていることもあります。
たまにレビュワーから指摘があっても、「てにをは」の表現、誤字・脱字といった表面的なものだけで、仕様や設計の中身に対する指摘はほとんど出ない、といったものもあります。
こうなってはいつしかレビューが儀式的なイベントになってしまい、悪くすると「レビューをしていてはかえって時間の無駄」という、誤った認識が横行することもあります。
・レビューが非常に長時間に及ぶ
一回のレビューが３時間も４時間にも及んでしまうものです。
レビューに注力することは良いことではあるのですが、あまりに長時間に及んでしまっては、肝心の開発の作業が進まず、効率化を狙ってレビューする意義が薄くなってしまいます。
また、人間は集中力を長時間に渡って持続するのは困難ですから、かえって欠陥が検出できなくなる、ということもあります。
レビューが失敗する原因
前章ではレビューが失敗する姿を示しましたが、続いて、レビューが失敗する原因を見ていきましょう。
1.そのレビューの目的を定義していない
レビューの目的が曖昧であると、色々な面に悪影響を及ぼします。
まず一つ目。
そのレビューの目的は何なのか、目的がはっきりしていないと、レビューする観点が定まらず、たまたま気が付いた点を五月雨的に指摘するだけ、という状況に陥ってしまいます。
レビュー指摘が「てにをわ」や体裁の面で終始してしまうのは、これが大きな原因です。
二つ目。
適切なレビュアーを選定しない、という形です。
例えば、設計書のレビューを行う場にエンジニアのみを参加させてしまい、「画面UIやユーザービリティに関わる指摘ができる人物がいなかった」という事態になる可能性もあります。
三つ目。
レビューの目的を見失うと、レビューがあまりに長時間に及んでしまうことにもつながります。
レビューが欠陥の早期抽出が目的ですが、レビュー場で、検出した欠陥の「解決方法」の議論にまで及んでしまうことがあります。こうなってはレビューの時間はいくらあっても足りませんし、「欠陥を見つける」という意識が削がれて、肝心の「欠陥の早期抽出」が損なわれてしまうことになります。
レビューで欠陥を見出したら、それを記録するに留め、その解決策の検討は、改めて別の機会で行うことが必要です。
2.レビュー対象物の体裁がバラバラ
レビュー対象の体裁が整っていないとレビュアーは資料の読み込みに時間がかかり、資料に記載された内容の吟味にまでなかなか踏み込めなくなります。これはレビュー指摘が出てこない、レビュー時間が長時間に及んで効率が悪くなることにつながります。
何よりも、設計で盛り込むべき項目がごっそり抜けている、といったような状態では、レビュー対象の中身を深く吟味する、ということには届きようもありません。
それに、ページ番号が抜けているといったような指摘は、レビューという貴重な時間を利用して行うべきではありません。
3.レビュー対象物をレビュワーに事前に渡していない
レビュー対象物をレビュー当日に配布されても、レビューの時間は限られていますから、十分に吟味することはできません。このことは、指摘が十分に出せなかったり、再レビューの必要が生じて効率が悪くなったりすることに繋がります。
4.レビュイーに個人攻撃
「不具合を検知すること」が目的である以上、ソフトウェアレビューの場がレビュイーに足りない点をレビュアーが非難するような雰囲気になってしまうこともあります。よくある例としては、レビュアーが不必要に厳しい口調で不備・不足している点を非難してしまうといったものです。
レビュイーとレビュアーは社内で上下関係がある場合も多く、本人が自覚していなくてもレビュアーの語気が荒くなってしまったり、レビュイーが指摘内容を個人の能力に対する非難として受け取ってしまったりする可能性もあります。
このような状況に陥ってしまうと、不具合の検知という本来の目的に必要なコミュニケーションが取れなくなります。単なるコミュニケーションの問題と軽視しがちなポイントではありますが、人間関係の悪化まで深刻化すると解決が難しくなります。
レビューで失敗しない3つのポイント
レビューにおいて上記で述べたような失敗をしないためには、関係者間の認識合わせと事前の情報共有が欠かせません。どのようなポイントに留意すればよいか、3つのポイントをご紹介します。
1.レビューの目的についての認識のすり合わせ
まず第一に重要なことは、レビューの目的について参加者全員で認識のすり合わせを行うことです。特に「今までのレビューでの指摘内容と修正状況」と、それに基づく「今回行うレビューの位置付け」の2点をよく確認しましょう。
レビューを実施する日時を調整を行う際に、そのレビューの目的を併せて周知するとともに、最初のレビュー会議で改めて確認することで、指摘内容の重複やズレ、目的に沿わない議論による時間の浪費を防ぐことができます。
2.レビュー対象物の体裁の統一
レビューの場で不要な指摘に時間を浪費しないよう、レビュー対象物を統一した様式で作成しておくことも有効です。チームで決めたフォーマットで仕様書や設計書が作成されていれば、レビューの場で体裁に関わる指摘は上がら無くなりますし、基本的な事項が大きく抜けていてレビュー不能な状況に陥るようなことも防止できます。
3.レビュー関係者間における情報共有の仕組み
ソフトウェアレビューの回数・時間を短縮するため、レビュー関係者間で情報共有する仕組みを作り、参加者が事前にレビューに関する情報を得られるようにしましょう。
例えば、レビュー対象物は、レビューの少なくとも１日前には関係者に配付することを、ルールとして定めておきましょう。
他にも、公式のレビューとは別に15～30分程度の非公式な相談・雑談の場を設け、懸念点などを前もって共有しておくことも効果的です。非公式なミーティングであるため資料を作りこむ必要がなく、レビュイー・レビュアー同士ざっくばらんに会話ができます。
上記の方法は一例で、関係者間での認識のすり合わせと必要な情報共有ができれば、どのような方法でも構いません。開発チームや組織で複数の手法を試し、最も効果の出る方法を模索してみてください。
おわりに
今回の記事では、ソフトウェアレビューのよくある失敗例と失敗しないためのポイントについてご紹介してきました。レビューを成功に導く最も重要なポイントは「レビュー目的の把握・共有」です。
レビューを目的に沿った有意義な場とするためには、レビュイー・レビュアー双方の努力が必要です。チームメンバー全員がレビューの時間を有効活用しようという意識を持ち、成果の得られるレビューにしましょう。
