連載
» 2009年05月11日 12時00分 UPDATE

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

“レビュー”は、ソフトウェアの品質向上や開発コストの削減に有効な手段だが、シンプルな内容だけに、なおざりにされがちだ。本連載では、ソフトウェアレビューのあらゆるメソッドを紹介し、“いますぐできて、効果が出る”レビュー方法を実践的に解説する。

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

“形だけ”になりがちなソフトウェアレビュー

 近年、ソフトウェアレビューに対する認知はますます向上しつつあります。例えば商用開発なら、「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが実施されていますし、オープンソースソフトウェアのプロジェクトなら、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。

 その背景として挙げられるのは、ビジネスや社会におけるITの重要性が高まっていることでしょう。われわれの日常にこれだけITが浸透しているいま、ソフトウェアの品質は、システムの運用に大きな影響を及ぼします。その品質が低下すれば、ビジネスなら機会損失や収益悪化、社会的信用の失墜につながりますし、社会インフラなら公共交通機関などのサービスがストップすることも起こり得ます。ソフトウェアレビューの認知度が向上しているのは、ソフトウェアテストの浸透と同様、より確実で、品質の高いサービスの提供を求める、社会や企業のニーズを反映したものといえるのです。

 ところがソフトウェアレビューの場合、合否がテストケースごとに明確に判定できるソフトウェアテストに比べると、少し様子が異なることが多いようです。例えば、“途中からベテランの世間話を拝聴する場”になっている、単なる“間違い探しの儀式”と化している──そんな話を聞いたことがありませんか? これらはソフトウェアレビューで陥りがちであり、実際、よく耳にする失敗例でもあります。あなたの周りではいかがでしょうか?

 本来、ソフトウェアレビューは、ソフトウェアテストと並んで、ソフトウェアの品質向上、開発コスト削減を図るうえで、非常に重要かつ有効な手段です。

 しかしながら、「ドキュメントやソースコードを読んで、間違いを指摘する」といったシンプルな内容であり、その進め方の自由度も高いばかりに、正しく実行されず、形だけのものに陥っているケースがよく見受けられます。実はこれらを防ぐためのレビューの方法がたくさん存在し、それらを適切に活用することで、結果ががらりと変わることも多いのです。

 そこで本連載では、品質向上にきちんと効果が出る、正しいソフトウェアレビューの方法を紹介していこうと思います。それも、レビュー内容の記録方法、参加者の役割分担といったごく基礎的なものから、プロジェクトの状況に応じたレビューのカスタマイズ、レビューとテストのバランスといった高度な内容まで、現場の実例に基づいた実践的なアプローチで解説していきます。ぜひ、自社のソフトウェアレビューを見直してみてはいかがでしょうか。

テストの前に問題を修正して、無駄なコストを解消する

 では、本題に入る前に、2点だけ大切なことを確認しておきましょう。1つ目は、ご存じとは思いますが、「ソフトウェアレビュー」の定義です。

 ソフトウェアレビュー(以下、レビュー)とは、『設計ドキュメントをはじめとした各種ドキュメントやソースコードを人が読み込んで、その問題点を見つける作業』のことです。こう書くと、ソフトウェアテスト(以下、テスト)と混同されがちですが、両者には大きな違いがあります。レビューは、プログラムを動かさずに(静的に)、ドキュメントやソースコードを人が目で追って問題点、すなわち潜在的な不具合を発見しますが、テストはプログラムを動作させながら(動的に)、不具合を発見します。

 つまりレビューはプログラムが動作する前の状態──要求定義や設計などを含め、コンパイルや実行ができない段階でも問題点を発見できるのです。これがテストとの大きな違いです。また、レビューとテストは、どちらか一方を使うと他方は使えないというものではなく、相補的に使うものであり、それぞれを適切に実施することが大切です。

 もう1つは「なぜレビューをするのか?」という目的です。これは、おおよそ以下の4つに集約できます。

  1. 開発中のソフトウェアの潜在的不具合(エラー)を早期に見つけて、その後の作業を円滑化し、修正コストを低減するため
  2. ソフトウェアの保守性や可読性を高め、次のバージョンを開発するときに再利用しやすくすることで、次のバージョンの開発コストを低減するため
  3. プロジェクトメンバー間の情報共有や新しいメンバーへの教育のため
  4. 現在の設計や実装の代替案がないかを考える場として

 これらのうち、中心的な目的は「潜在的不具合(エラー)を早期に見つけることで、その後の作業を円滑化し、修正コストを低減するため」だと思います。では、なぜレビューがそうしたことに寄与できるのでしょうか?

 一般に、プログラムを作った後は、期待どおりに出来ているかをテストで確認します。しかし、テストで誤りが発見されると、誤りを修正してから、再び修正確認テストをしなければなりません。修正確認テストでは、修正部分だけでなく、これまで期待どおり動いていた部分に悪影響が出ていないかを確認する回帰テストも行います。これらには当然、手間もコストも掛かります。その点、プログラムの実装前にレビューで問題を洗い出し、修正・確認しておけば、テストだけで問題を把握・修正・確認するよりも、修正コストを抑えられることが多いのです。

 また、ウォーターフォール・モデルのように、段階的に詳細化が進んでいく場合、要件定義段階での誤りがテストで発見されると、再設計や再コーディングを要する場合が多く、「初期工程での誤りほど、修正コストが大きくなる」ことが知られています。その点、レビューは要件定義が終わった段階で行うことができます。要件定義の成果物である要求仕様をチェックし、その段階で潜在的不具合を取り除けるため、再設計や再コーディング、そのためのコストも必要なくなる、というわけです。

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

Copyright© 2016 ITmedia, Inc. All Rights Reserved.

Loading

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -