“確実な記録”こそが、品質・コストに貢献する：ソフトウェアレビュー入門（1）（4/4 ページ）

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

こんな項目も作っておけば、いっそう確実

　以上6つの項目が記入できれば、レビュー記録として最低限の情報がそろったことになります。以下では、レビュー会議の進行中、指摘内容の質を測り、一定のレベルを維持するうえで役立つ項目と、開発完了後に振り返る際に役立つ項目を挙げました。仮にこれらの項目をまだ記録したことがなければ、無理に記録しようとすることなく、許されるコストに応じて、段階的に採用することをお勧めします。

指摘内容カテゴリ

　指摘内容が「エラー」なのか、「質問」なのか、「意味不明」なのか、あるいは「ほかとの調整が必要」なのか、指摘内容をカテゴリ分けして記録します。そうして分類しておくと、どのような対応が必要なのか、第三者が見ても一目で分かります。また、会議の進行中、カテゴリ分けしながら指摘していくことで、どの分類にも当てはまらない指摘が自ずと減り、話がわき道にそれにくくなる効果もあります。もちろんカテゴリは必要に応じて増減、改変して下さい。

事由

　指摘した理由を一言で示す項目です。例えば、指摘内容が仕様、設計、コードの誤りを示す場合は「エラー」、検討ができていない、あるいはドキュメントやソースコードの記述や説明が不十分といった指摘なら「未検討」、それ自体は正しく実現できているものの、ほかの部分やほかのサブシステムとの整合性が取れていないといった指摘なら「考慮不足」、ドキュメントの書き方があいまいだったり、分かりにくかったりという指摘なら「表記上の問題」といった具合に記入します。プロジェクト終了後、改善に向けて何を強化すべきかを検討する際、議論の円滑な進行に寄与する有効なヒントとなります。

重要度

　指摘したエラーが、対象ソフトウェアやプロジェクトに対して、「どのくらいのインパクトがあるものなのか」を記入します。例えば、誤字脱字などの指摘は「軽微」であり、ロジックの矛盾などは「重要」といった具合に記入します。レビュー会議中、指摘内容とともにこの項目を記録していけば、例えば「重要度の低い指摘ばかりなされている」など、指摘内容のレベルが明確に把握できます。これにより、より本質的な指摘ができるよう、参加者らに進行中にその場で促すことができるのです。

エラーの混入工程

　そのエラーがどこで混入し、どこで発見されたかを分析し、記録します。これにより、エラーが混入した工程で何が足りなかったのか、何が間違っていたのかを確認することができます。また、エラーが混入した工程と、それが発見された工程が大きくずれている場合、「何が原因でそうなったか」も分析し、記録することで、改善の糸口が見えることもあります。

修正期限

　クリティカルパス上にあるドキュメントを対象とするときは、修正期限を明確にして、修正担当者との間で意識合わせをしておきましょう。修正担当者が、修正作業の優先順位付けをする際にも役立ちます。

修正確認者／完了日

　会議の際、指摘が反映されたかどうかを誰が確認するかを決めておきましょう。また、確認したら「完了日」欄にその日付を記入します。

　いかがでしょう。こうして挙げてみると、“読んで間違いを発見する”といっても、検討すべき項目数が意外に多いと思われたのではないでしょうか。しかしフォーマット化しておけば、これらも取りこぼしなく、確実に押さえられるというわけです。

指摘内容を、その場で全員が確認できる環境を作ろう

　しかし、それだけではまだ十分とはいえません。真にレビューを有効なものとするためには、フォーマットを生かせるような会議を行うことが大切です。そこで最後に、前述した「レビュー会議4つのポイント」の残り3つについて解説しましょう。

　ただ、その前提として、レビュー会議の記録担当者が、参加者らの指摘内容をフォーマットに記入すると同時に、参加者全員が即座に確認できる環境を整えることをお勧めしたいと思います。以下の図2のように、PCを使ってファイルに入力している様子をプロジェクタに映す、といった具合です。

図2　1つ目のポイント「記録フォーマットの整備」のほか、レビューでの指摘内容や記録内容を、参加者全員が逐一確認できる会議体制を作ることが大切だ

　プロジェクタが使えない場合には、指摘内容を入力済みのフォーマットをネットワーク上のファイル共有できる場所に置いて、参加者全員が随時閲覧できるようにします。そうすることで、「記録内容」「指摘内容の確認」「見直し」が確実に行えます。また、レビュー会議が終われば、社外の関係者などにも、共有リポジトリやメールで入力済みフォーマットをすぐに配布することもできます。

　まずはこうした環境を整えたうえで、レビュー会議の残りの3つのポイントを心掛けましょう。まず「取りこぼしなく、きちんと記録できているかの確認」ですが、たとえ面倒でも、記録担当者が入力する指摘内容を、逐一レビューア全員で確認することをお勧めします。指摘個所の誤りや指摘内容の誤りはレビュー自体の意味を大きく損なってしまうからです。

　特に、記録作業に慣れていない人が記録担当者を務める場合、記録内容が意図どおりのものか、参加者全員で確認しながら進めましょう。また、レビューアらが指摘するスピードが速すぎて、記録担当の記録が追いついていないことも意外に多いものです。参加者全員で記録状況を確認しつつ、記録担当に配慮しながら進めていくことで、格段に記録の質が上がります。

　「レビュー会議進行中の指摘内容の確認」についても、記録担当者のPC画面をプロジェクタ画面に映し出すことで、参加者全員が指摘内容のリストを確認することができます。それを基に、指摘が特定部分に偏っていないか、レビューしていない部分がないかを確認しつつ、対象ドキュメントをまんべんなくレビューすることを心掛けましょう。

　また、記録フォーマットに、前述の「指摘内容カテゴリ」欄や「重要度」欄などを設けておけば、指摘がレビューの目的と一致しているかどうかを常に確認できます。その際、指摘内容カテゴリ」において「質問」に当てはまるような指摘ばかりが目立つ場合は、進行担当者が「エラー指摘も増やしましょう」などと、軌道修正を促すことも大切です。

　最後のポイントは「レビュー会議終了間際の指摘内容の見直し」です。レビュー対象をひと通り確認し終えたら、指摘内容を参加者全員でもう一度見直し、抜けやモレがないかを確認します。また、「類似した指摘内容を1つにまとめられないか」、あるいは「2つ以上に分けた方が正確なのではないか」など、指摘内容の記録が適切か否かを検討します。ときには、指摘した時点ではエラーと考えられていたが、「よくよく考えたらエラーではなかった」ということもあるため、最後にもう一度見直し、確実を期しましょう。

---

　さて、いかがだったでしょうか？ 「設計ドキュメントやソースコードを人が読み込んで、その問題点を見つける作業」と一息にいってしまえば、とてもシンプルに思えるレビューですが、実はこれほど配慮すべきポイントがあるのです。確かに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条件
• “読み方”を知って、レビューをもっと効果的に
• 全関係者の“納得”が、レビュー成功の大前提
• “確実な記録”こそが、品質・コストに貢献する