レビューを「数」だけで管理しているからコストが膨らむソフトウェアレビュー入門(5)(1/3 ページ)

「ソフトウェアレビューが適切に行われているかどうか」を測る代表的な指標として、「指摘件数」を「対象規模」で割った「指摘密度」がある。しかし、「指摘密度」だけでレビューの質を管理することは難しい。レビューを行う際には、「そもそも何のためにレビューを行うのか」を常に意識することが大切だ。

» 2010年08月19日 12時00分 公開
[森崎修司奈良先端科学技術大学院大学 情報科学研究科]

レビューが適切に行われているか、常に考えていますか?

 第4回『ソフトウェアレビューが成功する進行役の6条件』までは、本連載のタイトルどおりソフトウェアレビューのまさしく“入門”的な内容を扱ってきました。これで基礎は一通り押さえましたので、今回からは少しレベルアップしたいと思います。

 そこで、まず考えたいのは「レビューが適切に実施されたかどうか」を測る管理指標の生かし方についてです。

 管理指標は非常に多くのプロジェクトで導入されているものの、必ずしも期待どおりに機能しているわけではありません。第1回でも述べたように、レビューは“自由度が高い”取り組みであるだけに、ともするとなおざりに済まされてしまいがちなのです。しかし、明確な目的意識とそれに基づくレビューの“観点”を持ってシステマティックに行うことができれば、レビューはソフトウェアの品質、コストの問題に貢献する絶大な効果を発揮します。今回紹介する管理指標の考え方は、そうしたレビューの実施効果を高めるための軸と言える非常に大切な要素なのです。

 では、例によって事例から入りましょう。みなさんの周りでは、こんなことはありませんか?

プロジェクトが計画段階にあったある日のこと、PMOのメンバーAは、プロジェクトマネージャ(以下、PM)に内線電話をかけた――

メンバーA 「いまちょっと時間もらえるかい? この間、提出してもらったプロジェクト計画書の品質管理計画について、ちょっと聞きたいんだけれど」

PM 「はい、何でしょうか?」

メンバーA 「計画書の8ページ目、『管理指標』の所を見てもらえるかな? そこにページ当たりの目標指摘密度を表す『上限○件/ページ』『下限○件/ページ』という細目があるよね。それが『提示部』と『外部連携部』でまったく同じ値になっているよね?」

PM 「はい、確かに」

メンバーA 「この『提示部』『外部連携部』という2つの機能は、コーディングの難易度がかなり違うと思うんだけど、どうかな? 『外部連携部』の方が『提示部』よりも難易度が高いんじゃない? もしそうなら目標指摘密度もそれぞれ別の値にした方が良いと思うんだ。難易度が高い『外部連携部』についてレビューでの指摘が少ないと、結合テストの段階で問題が出てくる可能性が高いと思うんだよ」

PM 「そうですね。確かに機能ごとの難易度の検討が不十分でした。目標指摘密度を変更して提出し直します」

後日、設計レビューで――

PM 「ではみなさん、そろそろ始めましょうか。ちなみに今回のプロジェクトは規模が大きいこともあり、PMOでは週次でこのプロジェクトの進ちょくをレビューすることになっています。では早速ですが、設計書のレビューに入りましょう。今回のレビュー対象は『外部連携部(対X、 Y、 Zシステム)』『提示部』『制御部』です。全体で2時間くらいをイメージしてください」

このレビューにはレビューアB、C、Dが参加しています。ところが、 レビューアBは事前にレビュー対象に目を通していたものの、レビューアCとDは日ごろの忙しさから、ほとんど見ていませんでした――

レビューアB 「18ページの外部システムXとのやりとりなのですが、システムXは高負荷時には接続要求を受け入れず、リトライ要求を返します。この要求の中に『何ミリ秒(msec)後に再要求してほしいか』という値が入っているのですが、この値と、11ページにある『外部システムとのやりとり』で包括的に定義されている『3秒おきに3回。失敗すればエラーログを出力して、反応がなければ、3分後に30秒おきに3回』という記述との間で整合性がありません。どちらを優先するか記述しておく必要があります」

PM 「確かに。後で検討しましょう。ほかにはないでしょうか?」

レビューアC 「えーっと……。外部システムXが停止することはないんでしょうか?」

レビューアB 「それは17ページの最下行に記述があります。外部システムが停止するときには、計画停止の設定ファイルをチェックしにいくことになっています」

レビューアC 「そうですか……。では、その設定ファイルが読めないときの処理が定義されていないようなので、それを私からの指摘としたいと思います」

レビューアD 「システムXのリトライ要求に、異常値が入っていたときの処理が書かれていませんね。つまり、『外部システムXのリトライ要求の値を異常値とする基準と、異常値の際の処理方法が記述されていない』」

しばらくレビューが続いて――

PM (えーと、これで『外部連携部』については指摘密度の目標値をクリアしたな。次は『提示部』に移ってもいいかな)――「では『外部連携部』についてほかに指摘がなければ、次は『提示部』の指摘をお願いします」

レビューアC 「48ページの表3-2のキャプションですが、表の場合、キャプションは表の直前に書きます」

レビューアD 「49ページの図3-1のキャプションは図の直後じゃないと駄目ですね。図のキャプションは図の直後と決まってますから。あと、キャプションのフォントはゴシック体にしないと」

レビューアB 「52ページに『個人情報を表示する画面で毎回パスワードを要求するかどうかは、稼働環境のセキュリティポリシーに準ずる』と書いてありますが、具体的に何を参照すれば稼働環境のセキュリティポリシーが分かるのか、記述が必要だと思います。もし明確でないならば、運用担当の方と相談しないといけないのではないでしょうか」

PM 「確かに。ここは私が聞いておきます」

しばらくレビューが続いて――

PM (提示部も目標値はクリアしたな)――「だいたい2時間越えましたし、指摘密度も目標値を達成しているようです。このあたりで終わりにしたいと思いますが、ほかにないでしょうか?」

後日、コーディングにおいて――

開発担当者 「これじゃあ外部システムYとの連携部分で未定義が多すぎて実装できませんよ。設計を再レビューしてもらえませんか?」

さらに後日、今度は結合テストにて――

テストリーダー 「性能に関するテストはまだですが、ユーザー入力の異常系のテストで、レスポンスの悪さが指摘されています。『提示部』の設計時点で、性能に関してあまり検討されていないような感触を受けるのですが……」

PM 「そうですね……計画段階でPMOのAさんに指摘密度のことを言われてから、どうも指摘密度のことばかり考えてしまったようです。いま設計レビューの指摘票をあらためて見てみると、指摘個所や指摘内容にムラがある。指摘密度としては『適正なレビュー』として、PMOからも承認してもらえてたんだけど……」


 いかがでしょうか? レビューの効果を測るうえで「指摘密度」を測ることは大切ですが、以上のように、指標が“それだけ”になってしまっているということはありませんか? 1つの指標に縛られてしまうと、上記の例のように見落としが多くなりがちなほか、プロジェクトの進ちょくそのものにも影響を与えてしまいます。今回紹介する管理指標の生かし方とは、このような事態を避けるためのものなのです。

       1|2|3 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ