ソフトウェアレビューが成功する進行役の6条件：ソフトウェアレビュー入門（4）（3/3 ページ）

[森崎修司，奈良先端科学技術大学院大学 情報科学研究科]

全員に配慮し、よりよい指摘を引き出すスキルが必要

　さて、以上のような役割を1人1人が明確に認識したうえでレビューに取り組むと、あらゆる無駄がなくなり、効率、効果ともに大幅に向上します。そのイメージをつかんでもらうために、前のページで紹介した「進行役が配慮すべきポイント」を実践に落とし込んだ進行例を紹介します。同じレビューでありながら、冒頭の例とは雲泥の差があります。進行役の言動について、（ ）内に解説を加えましたので参考にしてください。

進行役　「今回のレビューの目的は、タイミング問題になりそうな部分がないかを確認することです。タイミング問題が原因となってテスト工数が大きく膨らむことは、経験的に理解していると思います。安定したリリースに向け、この場でタイミング問題をつぶしておきましょう」

（まず、レビューの目的を明確化している）

進行役　「なお、自身の作成物のエラーを指摘されることは恥ずかしいことではありません。また、決して人を攻撃するために使ってはいけません。問題の早期発見に貢献したレビューアへの感謝の気持ちを忘れずに。メンバー全員がレビュー対象の品質を上げることを目指していることを思い出してください。では、約2時間で今回の対象全体に目を通せるようなペースで。特に、『個々の機能やサブシステムを結合すると、意図とは異なる動作になってしまわないか』レビューをお願いします」

（レビューで陥りがちな問題を最初に指摘。時間制限があることや、レビューの着眼点についても、さりげなく伝えている）

レビューアA　「私が担当する処理aと、Bさん担当の処理bは、タイマーをトリガーにa、bの順で連続して実行されると思うのですが、Bさんの処理bは、処理aの実行時間が考慮されていないように思います。つまり、このままでは処理aを実行するトリガーの発火時刻を、そのまま処理bの実施時刻として記録してしまうことになりませんか？」

進行役　「Dさん、いまの指摘内容を書けますか？」

記録係D　「理解できない部分がありました。スピードも少し速かったので、もう一度お願いできないでしょうか」

進行役　「これはAさんとBさんの間では共通の話になりますよね。指摘票には何と書いたらいいですか？」

（記録係に配慮するとともに、同じ人に同じことを二度言わせるような愚を犯さず、より適切な指摘を促している）

レビューアA　「『処理bで記録する時刻は、処理bの実行中にタイマーから取得するよう修正する。現在、処理aの実行開始時刻を記録するようになっているが、処理aの実行時間が長くなるほど誤った時刻を記録してしまう』でしょうか……」

進行役　「BさんとCさんの担当する部分がユースケース2-3で実行される場合にも、同じことが起きないでしょうか？」

レビューアC　「起き得ます。あと、直接関係ないですが、Bさんのここの記述方法はいまいちだと思います。修飾語の係り受けがあいまいで、何を意図しているのか分からない部分があります。Bさんには、前にもこの話をしたように思うのですが直っていません。こういう雑な記述が問題を起こす原因なんじゃないかと思うのですが」

進行役　「Cさん、ちょっと待ってください。いま、ユースケース2-3に関して問題が発見できましたね。これは非常に良かったですよね。まずこれを記録しておきましょう」

（レビューが目的からそれ始めたら、即座に軌道修正を図りつつ、問題点を整理している）

進行役　「つまり、こういうことですよね？ BさんとCさんの担当している処理で、処理bと処理cがユースケース2-3で実行される際に、時刻取得の問題が起きると。それは先ほどの処理aとbの間で起こる問題と同じ原因であるということですよね？ ではDさん、それを記録しておいてください。あと、もう1件指摘してもらったBさんの記述方法の問題については、この会議が終わったら相談しましょう。Bさんからは何かないですか？」

（記録係に配慮するだけではなく、Cさんの声も尊重している。意見を促すことで、Bさんの意図を確認しつつ、顔も立てている）

レビューアB　「処理aの最後で実施している初期化（終了後処理）と、処理cの冒頭で実施している初期化は同一のものです。処理aの終了後処理はやらなくてもいいのではないでしょうか？」

進行役　「確かに。処理aの方を削って問題が起きないようであれば、少し処理時間が短縮されますね。AさんとCさん、問題ないでしょうか？」

（1対1の対話で終わらせず、関係する全員が問題を発見できるよう確認を促している）

レビューアA、C　「大丈夫です」

進行役　「では、時刻取得とユースケース2-3の話はこれでいったん終わりにしましょう。ほかにタイミング問題に発展しそうなところはないでしょうか？」

---

　いかがでしょうか。進行役の配慮1つで、脱線の芽を即座につむことができるのです。もちろん現実には、この例ほどスムーズには進まない場面もあると思います。しかし、場数を踏めば進行役のハンドリングスキルは着実に向上しますし、何よりメンバー1人1人が役割を自覚することで、脱線そのものを大幅に抑制することができるのです。

進行役をサポートするのは、メンバー全員の自覚

　さて、今回はソフトウェアレビューにおける役割分担を紹介しました。冒頭で述べたように、通りかかった開発メンバーに「ここをちょっと見てほしいんですけど……」と声を掛けて始まるような、ごく日常的なアドホックレビューならその必要性は低いですが、会議を開いて網羅的にエラーを検出するような場合は、明確な役割分担はレビューを有意義なものにするための必須条件となります。

　特に、 第3回『“読み方”を知って、レビューをもっと効果的に』で紹介したリーディング技法のうち、読み方を指定しないアドホックリーディングをはじめ、進め方の自由度が高い技法ほど役割分担が重要になりますし、進行役のスキルが問われるようになります。

　とはいえ、進行役と同等かそれ以上に重要な要素があることも、最後にあらためて強調しておきましょう。それは、上の事例でも簡単に触れていますが、「メンバー全員の自覚が大切だ」ということです。メンバー全員が進行役の役割を認識するとともに、1人1人が自分の役割に徹すれば、脱線せずに、効率的なレビューを実現すべく、自然に協力し合うことができるのです。

　ぜひ、この機会にレビューの役割を見直してみませんか？ 例え、進行役としてのスキルを持ったメンバーがいまはいなくても、“役割分担という心掛け”1つで、レビューの密度が飛躍的に高まると思います。

筆者プロフィール

森崎 修司（もりさき しゅうじ）

国立大学法人 奈良先端科学技術大学院大学 情報科学研究科 助教

ソフトウェアレビュー／ソフトウェアインスペクション、ソフトウェア計測を専門とし、研究・教育活動をしている。奈良先端科学技術大学院大学にて工学博士を取得後、情報通信企業でソフトウェア開発、開発管理、レビューに従事。現在、同大学院に奉職。研究成果を業界に還元していくことをミッションの1つと位置付け、ソフトウェアレビュー研究の国際連携ワーキンググループの主導、多数の企業との共同研究、文部科学省「次世代IT基盤構築のための研究開発: StagEプロジェクト」に従事。アイティメディア オルタナティブ・ブログで「森崎修司の『どうやってはかるの？』」 を執筆中。

ソフトウェアレビュー／インスペクションの研究グループ：

http://se.aist-nara.ac.jp/html/review/

ソフトウェアレビュー／インスペクション研究の国際連携ワーキンググループ：

http://www.software-inspection-wg.org/

StagEプロジェクト：

http://www.stage-project.jp/

「ソフトウェアレビュー入門」バックナンバー

• レビューを「数」だけで管理しているからコストが膨らむ
• ソフトウェアレビューが成功する進行役の6条件
• “読み方”を知って、レビューをもっと効果的に
• 全関係者の“納得”が、レビュー成功の大前提
• “確実な記録”こそが、品質・コストに貢献する