レビューで失敗しない8つのポイントレビューがうまくいかない理由(1/4 ページ)

ソフトウェア開発の品質・効率向上に欠かせないレビュー。しかし、やり方を間違えているために、かえって逆効果になっているケースが多い。本連載ではソフトウェアレビュー研究の第一人者、森崎修司氏が豊富な現場経験と研究成果を基にレビュー成功のポイントを分かりやすくリアルに解き明かす。

» 2014年04月07日 18時00分 公開
[森崎修司名古屋大学]
※本記事はアフィリエイトプログラムによる収益を得ています

なぜレビューがうまくいかないのか?

 ソフトウェア開発の品質・効率向上が求められている今、ソフトウェアレビュー(以下、レビュー)の重要性はますます高まっています。商用開発では「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが行われていますし、オープンソースソフトウェアのプロジェクトでも、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。

 しかし、レビューは自由度の高い活動です。レビュー会議では本質的な欠陥や問題を指摘しても、欠陥や問題に関係のない雑談をしていても、表面上は同じように実施したことになります。

 皆さんも「レビューしていたはずなのに……」という状況を一度は経験したことがあるのではないでしょうか。次のような状況です。

しっかりレビューしたはずだけど……

―― サブシステムのリーダーが参加する進捗会議でシステムテストの結果を見ながら……

統括リーダー 「サブシステムXで見つかっている欠陥は、レビューで検出されていて良さそうな欠陥が多いように見える。原田さんのところだと思うが、レビューが不十分だったのでは?」

サブシステムXのリーダー原田氏 「詳細な業務知識が必要でロジックも複雑な部分だったので、この分野に詳しい片山さんにお越しいただいてレビューしていただいたのですが……」

統括リーダー 「うーん。でもこの程度の異常系の定義漏れがあるのはレビューの質を疑うなぁ。他にもスループットをだいぶ改善すべき部分があるのも気になる」

サブシステムXのリーダー原田 「……」

―― 帰宅途中の電車でレビューを振り返る原田

サブシステムXのリーダー原田 (そう言えば、片山さんはかなり忙しそうでレビュー会議で詳細設計書を初めて見る感じだった。目に付きやすい表記揺れの指摘をしていたような気がする。

 片山さんとソリの合わない高原さんと些細な内容で長時間言い争っていて仲裁に苦労したんだっけか。そのせいか片山さん、高原さんの担当部分だと分かると必要以上に確認を繰り返していたような。そういうオレ自身も超多忙な片山さんのスケジュールが確保できて安心してしまって、レビュー会議中に重要な指摘をしてもらえているか、確認しなかったんだっけ。

 「有識者が参加するレビューを実施した」というエビデンスができることで必要以上に安心してしまってた。久々に参加した千原さんと同期入社の鈴木さんも同じレビュー会議に参加していて、楽しそうに昔話をしていた。レビューの後半は時間不足になってドキュメントの終盤はざっと見るだけで終わってたな。あらためて考えると、見逃しがあっても仕方のないレビューだったのかもしれない。)

 「レビューの効果が出るかどうかは、レビューアーの知識やスキルに依存している」と考えられていることが多いにもかかわらず、有識者を呼んで準備万端なはずだったレビューの効果がそれほどでもなかったということも少なくありません。何が問題なのでしょうか?

 連載の初回である今回は、レビューから効果を得るための前提を紹介します。前提の中には気を付けさえすればすぐにできるものもあれば、準備が必要であったり、定着まで少し時間がかかったりするものもあります。すぐに結果を求めず、少しずつ改善していきましょう。2回目以降で紹介するやり方や技法を取り入れる際には、今回の前提と併せて検討します。

 本連載では、レビューを取りまとめる立場の方(リーダー)向けに、うまくいっていないレビューを改善していく方法を紹介していきます。拙著「間違いだらけの設計レビュー」では、リーダー、レビューアー、作成者(レビューイ)の3つの視点からレビューの具体的な手順を示し、レビューの方法とともに関係者が持つべきマインドを紹介しています。「レビューではどうやって欠陥や問題(※)を検出したらいいの?」という、基本的でありながら極めて重要な疑問に答えています。

※「欠陥」は「誤りや抜け」、「問題」は「欠陥にはなっていないものの欠陥の原因となる可能性が高く、修正しておいた方が良いもの」を指しています。

参考リンク:設計レビューに私情を持ち込んでいませんか?

 本連載では、今のレビューを改善したいリーダーの視点から解決策を示します。もちろん、リーダー以外の立場でレビューに参加されている方にとっても、普段と異なる視点からレビューを知ることで、改善に役立つさまざまな気付きが得られるよう解説していきます。

 では早速本論に入りましょう。今回は論点を8つのポイントに整理しています。まずはレビューの効果を得るための前提を示します。レビュー全体を通じたマインドの問題(1〜3)です。

       1|2|3|4 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。