レビュワーの指摘の価値を上げるほんのちょっとした工夫

レビューとは

システム開発ではレビューはソースコードだけでなく、
要件定義、設計、ソースコード、試験計画、試験項目など、幅広く行われています。

レビューは品質を向上させるために行われるため、
文言の「てにをは」や、表記ゆれの指摘よりも、
システム利用者への不都合が起きる問題・リスクへの指摘のほうが価値が高いといえます。

では、どうすればレビュワーは価値の高い指摘ができるようになるでしょうか？

レビュー価値の向上のためにどうするか

成果物に対する深い知識・経験は必要です。
要件定義でいえば、システムが利用されるビジネスおよび利用者に対する
深い知識と経験がなければ、価値のある指摘は難しいでしょう。

しかし、年々システムは短納期化・複雑化し、人手不足はますます解決困難になり、
レビュワーの熟練を待てる状況にはありません。

手持ちの駒ですこしでもレビュー指摘価値を上げる方法

そんな状況下でレビューの指摘価値を上げる、
ほんのちょっとした工夫なんてあるのでしょうか？

あります。ソフトウェア品質特性の活用です。

ソフトウェア品質特性

ソフトウェア品質特性（ISO/IEC 9126）とは、ソフトウェア品質の評価に関する国際規格です。
品質を6つの主特性と、その下に合計27の副特性に細分化・モデル化した規格です。

ウェブレッジさんのWEBページが非常によくまとまっていますし、
図式は秀逸です。

ソフトウェアの品質は上記の27の副特性で評価することができます。
例えば、バグがあるか・ないかというのは、正確性の評価になります。

バグがなくても、使い勝手が悪ければソフトウェアの質が悪いという評価されますが、
それは使用性が低いという評価になります。

システムによっては障害が起きても何とか動き続けることが求められるなら、
障害許容性で評価しないといけません。

クレジットカードの決済機能を有しているなら、
クレジットカード会社の規約、経済産業省の省令に従っているかを評価しないと、
ルール違反のシステムをリリースすることになってしまいます。
これは基準適合性という品質特性になります。

レビューというのは、煎じ詰めると「これで良い／悪い」を判定することですが、
全体的にざっくりばっくり「良い／悪い」を判定してしまうと、
どうしても大事な部分が漏れてしまい、後工程やリリース後で問題を発生させてしまいます。

どう活用するのか

• レビュー前に、対象成果物がどの品質特性を重視するのか確認する
  • システムによっては、不正確であっても応答速度が求められる場合などがあるため、
    対象成果物ごとに、どの品質特性でレビューするか選別する
  • 全部の品質副特性でレビューしたほうがいいのはやまやまだが、
    時間は有限なので３～７に絞る。
    またじっくり見る特性とさらっと見る特性など、濃淡をつける
• 選別した品質特性で一つずつレビューをする
• というか成果物作成前に、作業者とレビュワーとで選別・濃淡を決定しておき
  品質チェックではなく、品質作りこみが行われるよう誘導する

どうなるか

メンバのレビューに対する感想が、
「レビューめんどくさい、うるさい」
から
「なるほどね。力入れる箇所がわかっていいものが作れるようになるわ」
に変わる

レビュー嫌いのエンジニアのみなさんもたくさんいらっしゃると思いますが、
エンジニアのみなさんって、基本的に、よりいいものを作りたいという欲求を持っています。
価値のあるレビュー指摘は、システム価値の向上のみならず、
エンジニアのみなさんの精神衛生にとっても大きな効果があります。

想定される質問・反論への回答

• 例えば「障害許容性」で、何をどう見ればいいの？
  • 多少の解説はできますが、本稿の趣旨とはずれるので割愛します。
  • 本稿では、ほんのちょっとの工夫で、相対的に今より改善する漸進の提案です。
  • 何をどう見ればいいかよくわからない人でも、「障害許容性」に視野を限定すれば、
    そうでないときに比べてより相対的に良い指摘ができるようになります。
• 結局人頼みじゃん
  • そうです。結局、具体的に価値のある指摘をするのは個々の人間の創造性です。
  • 自動化、定型化を進めても、最後には人間の創造性を発揮する余地が残る。それでいいじゃないですか。
  • そしてこの提案はすべてを最終解決させる案ではなく、ちょっと改善する工夫の位置づけです。
• そういう指摘って蓄積していつでも参照できるようにしとけよ、いちいちレビューするな・させるな
  • 私もそう思って蓄積を試みたのですが、「対象システムごとに重要な観点が異なる」
    「それを全部記載すると重厚な基準書になり使わなく・使えなくなる」と断念しました。
  • ただ、私の判断が間違っている可能性もあるので、ぜひ試してみてください。
• そもそもこれらは、レビュワーが決めることじゃなくて要件定義で決めることでしょ？
  • そこに気づくとはさすがです！
  • 私はこれを要件定義の定義カテゴリとしても使っています。
  • 要件定義の内容は工程が下るごとに、成果物への反映が薄れてしまうので、
    各成果物の作成前で再確認する、作成後チェックするというのは、
    少なくとも自分の現場では必要でした。