3.8    スペシャルセッション「ソフトウェア品質レビューの全て:生い立ちから先進技術まで」

3.8.1    はじめに

このセッションでは、レビューを実施してきて17年、日本アイビーエム株式会社の細川さんによるレビューの現状とレビューの課題、レビューはこれからどうなるか?といったことをお話いただきました。

3.8.2    レポート報告

3.8.2.1   AI(人工知能)におけるレビュー

はじめに、AI(人工知能)におけるレビューについて説明いただきました。

文章を見たときに「人」は自身の持っている経験や知識から意味を解釈するが、実際には自然言語にはあいまいな文章が多く一意に決定できない場合がある。また、AIを誤解させる技術、もあるため、正しいことだけを学習させても正しい結果は判断できない。そのために、「悪さの知識」を利用して、正しいAI、安全なAIのシステムを開発しているという内容でした。

3.8.2.2   レビューにおけるよくある誤解

レビューにおけるよくある誤解についても説明がありました。

    • 「レビューを多く行なえば、レビュー対象の品質があがる」
    • 「人数を多くすれば欠陥が検出される」
    • 「机上でチェックすれば欠陥が見つかる」

このように考えている人がいるが、それは間違いである。レビューで検出された欠陥を、どのように利用するか、開発者に気持ちよく直してもらうために受け入れやすいように欠陥を伝えることがレビューにおいて大事です。レビューワとして大事なのは、開発者が不安に思っていることを予測して、レビューを行なうことでその不安を取り除いてくれるようなレビューワになることが大事であるとも伝えられました。

3.8.2.3   レビューを効果的なものにするために

レビューを行なうために行ったほうが良いことがいくつか紹介されました。た問えば以下のようなことです。

    • レビューミーティング前の事前チェックは必ず実施する。
    • 軽微な欠陥はレビューミーティング前に検出して、まとめた結果をそっと渡す。
    • 深刻な欠陥やシステムに影響が大きい欠陥から指摘していく。
    • 参加者数は4人くらいを上限とし、それぞれの役割分担が重複しないようにする。
    • 作成者と他のレビューワの意見の齟齬がわかりにくくなるので、作成者は過度にコメントしない
    • 欠陥の検出を目的とする。欠陥検出以外のことは、レビューの効率を落とす原因になるため別の場で行なう。
    • レビュー対象の特徴や特異点を見極め、全体俯瞰して確認したのち、どこにどのような欠陥がありそうか推測しながらすすめる。
    • 開発の最後に1回だけ行なうレビューは負担や手戻りが大きいため、開発の進度にあわせて複数回実施するようにする。

 

レビューを効果的に実施するためのヒントをたくさんもらったと思います。まとめにあった、「レビューを価値あるものにするのは自分たちである」というフレーズは特に共感いたしました。

(報告:すずき しょうご)