【第5回】［#2］何のためにやるの？｜ソフトウェアレビューをエンジニアリングっぽく語ってみる

みなさんこんにちは。

「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”弦音”です。

今回は「何のためにやるの？」がテーマです。

＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞※クリックで開きます

レビューって、何してますか？

「これ、レビューしておいて」「さて、レビューしようか」

さて、レビューと言われて何を思い浮かべますか？

誤字脱字を探すのでしょうか。
仕様の抜け漏れを調べるのでしょうか。
設計や実装に問題がないかを評価するのでしょうか。

どれもレビューで行われることですが、これだけだとレビューの目的を十分に表しているとはいえません。

レビューでは、成果物を読み、内容をさまざまな観点から評価します。その結果、問題や改善の余地が見つかれば、指摘や提案として伝えます。

ここで見つける問題や改善の余地とはどのようなことでしょうか。

レビューで指摘すること

レビューでまず思い浮かぶのは、成果物に含まれる欠陥をみつけることです。

ここでいう欠陥とは、成果物に含まれる不備があることや、要求・仕様に合っていないことを意味します。

たとえば、次のようなものです。

要求や仕様と異なる内容が記載されている
お客様が本当にやりたかったことと仕様がずれている
計算式や条件分岐に誤りがある
必要な処理や仕様が抜けている
前提条件が考慮されていない
仕様の解釈が曖昧で、関係者によって理解が分かれる
ドキュメント内に誤字脱字衍字がある

このような欠陥は、発見した時点で指摘し、修正する必要があります。

しかし、レビューで扱うのは、すでに存在している欠陥だけではありません。

現在は問題なく動作するように見えても、将来、問題につながる可能性があります。たとえば、データ量が増えると性能が低下する恐れがある、構造が複雑なので保守が難しい、アクセス権限の設定が不十分である、といったケースです。これらはレビューでは欠陥ではなくリスクとして扱います(一緒に扱うこともあります)。

また、欠陥やリスクには該当しなくても、よりよい方法を提案できる場合があります。処理結果は同じでも、より効率的なアルゴリズムを選べるかもしれません。現在の仕様でも要求を満たしていても、別の仕様のほうが利用者にとって使いやすいかもしれません。

このように、レビューで指摘するものには、次の三つがあります。

欠陥：要件や仕様を満たさない不備や欠点
リスク：将来、障害や損失につながる可能性
改善点：欠陥やリスクではないものの、よりよくできる点

レビューでは、これらを見つける(指摘する)ことが目的だ、と考えてよさそうです。

レビューで指摘するものの深堀（何に着目しているか）

レビューで指摘する欠陥やリスク、改善点にはどのようなものがあるかもう少し見ていきましょう。

たとえば、次のようなものがあります。

表1　レビューで着目しているものの例

機能性	要求された機能を実現できるか
信頼性	障害が発生しにくく、発生時にも適切に対応で
効率性	性能に関すること。必要な処理速度やデータ量に対応できるか
安全性	不正アクセスや情報漏えいなどのリスクを抑えられているか
使用性	利用者にとって理解しやすく、操作しやすいか
保守性	将来の修正や機能追加を行いやすいか
運用性	監視、障害対応、バックアップなどを適切に行えるか
互換性	他のシステムや既存の仕組みと適切に連携できるか
法令・規約への適合性	関連する法令や規約、社内標準などに適合しているか

レビューでは、対象となる成果物や開発の段階に応じて、必要な品質の観点から内容を評価します。

たとえば、要求された機能を実現していても、個人情報の扱いが不適切であれば、安全性や法令・規約への適合性に関する問題になります。

また、仕様に適合した処理であっても、プログラムの構造が複雑であれば、将来の変更時に欠陥を作り込むリスクが高まります。

このように、レビューの目的に、機能が成立しているかどうかだけではなく、利用者、運用、保守、性能、安全性、法令などの観点から、成果物に必要な品質が備わっているかを確認するということがあります。

問題を早い段階で発見する

これらの問題は一部を除いて(この一部、は大事なので次で説明しますね)、テストで見つければいいじゃないか、と、思う人も多いでしょう。確かに、多くの問題はテストして(モノを動かして)見つけることができます。でも、レビューで見つけることの良さがあるのです。レビューを行うことの良さの一つに開発の早い段階で発見できる、ということがあります。

ソフトウェア開発では、要求、仕様、設計書、プログラムなどの成果物を順に作成していきます。

ある段階の成果物に欠陥やリスクが残ったまま次へ進むと、それらが後続の成果物に引き継がれます。

たとえば、要求に含まれる問題を発見しないまま仕様を作成し、その仕様をもとに設計や実装を進めると、後になって複数の成果物を修正する必要が生じます。

安全性や法令・規約への適合性に関する問題であれば、設計やデータの扱いを根本から見直さなければならない場合もあります。

一方、要求や仕様の段階で問題を発見して指摘できれば、その段階で修正できます。

問題の発見が後の工程になるほど、指摘後に必要となる修正の範囲や影響は大きくなりやすくなります。

そのためレビューの目的には、問題が後の工程へ広がる前に発見し、手戻りや将来のリスクを小さくするということもあるのです。

表2　欠陥の修正：レビューとテストの比較

項目	レビュー	テスト
発見してから修正にかかる時間	短い(数分～数時間)	長い(数日～数週間)
修正に必要なプロセス	指摘されたところの修正、再レビュー	原因究明(デバッグ)、修正、ビルド、再現環境の構築、テスト
再確認方法	修正箇所をレビューアが確認	テスト、リグレッションテスト