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