旧態依然とした開発現場では、品質確保のためにテストと修正に多くの工数が費やされている。ソフトウエアの製造時から品質を確保することが、品質向上と開発工数の削減につながる。アジャイル開発のプラクティスを参考に品質の向上方法を紹介する。

今回のポイント
  • 品質状態は実際に動作するシステムで早い段階から確認する。品質確保のために作業項目が増えても、プロジェクト全体の作業工数が減るようにプラクティスの採用を計画する。
  • システム利用者の立場になって開発する。開発者視点より利用者視点を重視してシステムの使いやすさを優先する。システムの品質だけではなく、業務における操作の品質(操作ミスの防止)を向上させる。
  • 効率良く品質を確保するには、「反復」「イテレーション計画」「イテレーションレビュー」「テスト駆動開発」「継続的インテグレーション」というプラクティスが有効である。

 本連載は、従来のウォーターフォール型の開発プロセスにアジャイル開発のプラクティスを部分的に組み込み、プロジェクトに潜む様々なムダを排除する「ハイブリッドアジャイル」を提案している。今回は、ソフトウエア開発における品質向上の方法について解説する。

従来型の開発プロセスではテスト効率が悪い

 開発するソフトウエアの品質を向上するには、言うまでもなくテスト工程が重要である。ところが、ウォーターフォール型の開発では、テストの効率が悪くなってしまうことが多々ある。

 従来型の開発では、プログラムの製造工程の後にテスト工程を設けていることが多い。プログラムの構成要素単位にテストする単体テストを考えてみよう。単体テストを実施する際は、各システムエンジニアが担当する機能を一通りコーディングしてから、単体テスト用のテストチェックリストを作成する。そして、チェックリストを基に単体テストを行う。

 このような手順でテストすると、不具合を発見した場合に、製造した全ての範囲を問題箇所として調査しなければならない。その結果、調査と修正によるデグレードテストに時間がかかることになる。

 さらに、製造工程で単体テストまで終了し、結合テストの工程になった場合も、ウォーターフォール型の開発では効率が悪いことが多い。例えば、製造工程が遅れた場合や、単体テストの定義にこだわり過ぎて一連の動作確認まで行っていない場合だ。

 ウォーターフォール型の開発では、工程で進捗を管理する。自分の担当するプログラムの製造工程が遅れていれば、システムエンジニアは品質が悪いことを分かっていても、とりあえずコーディングを終了させて次工程に移ってしまうことがある。後のテスト工程で直せばよいと考えてしまうわけだ。これは仕方のないことである。システムエンジニアは、自分の遅れのせいで製造工程が完了しないのは申し訳ないと思ってしまう。その結果、全体の進捗を優先してしまい、何とか単体テストまではこなすものの結合テストのことは考えずに先送りしてしまうのである。

 単体テストにこだわり過ぎるのも問題だ。限られた時間をいっぱいに使い単体テストまでは終了しても、結合テストの工程を想定していなければ、一連の業務として動かした際にうまく動作しない。結合テストの前までには基本的な画面遷移を実施し、一連の動作に問題がないことを確認しておくべきだ。

テストは厳しく効率的に行う

 筆者の提案するハイブリッドアジャイルは、開発するソフトウエアの品質向上も期待できる。実際に筆者が携わったプロジェクトの事例を基に説明しよう。

 図1は、一般的なウォーターフォール型の開発事例とハイブリッドアジャイル開発事例の詳細設計から単体テストまでの工程を比較したものである。

図1●品質確保のための手順を比較
[画像のクリックで拡大表示]

 ウォーターフォール型の開発では、設計者が作成した設計書をプログラマが確認し、仕様を理解してコーディングする。そして、他のプログラマがコードレビューを実施して、単体テストを行うといった流れが一般的だ。

 一方、ハイブリッドアジャイルの開発では、イテレーション計画で仕様をチーム全員で理解する。コーディングの工程では、テスト駆動開発(TDD:Test Driven Development)で少しずつテストしながら開発していく。開発したプログラムは、継続的インテグレーションの環境で常にテストコードが実行された状態をキープする。これにより、正常に動作するシステムが維持され、プログラムに修正が発生しても常に正常動作することが保証されるのだ。

 目視コードレビューは、ウォーターフォール型の開発と同様である。一連の業務が動作することを画面で確認しておき、イテレーションレビューでプロダクトオーナーやユーザーに確認してもらう。確認時には、実際に動作するシステムを用いる。

 ハイブリッドアジャイルのテスト作業は、ウォーターフォール型の開発より厳しく行うのがポイントだ。当然、作業項目はウォーターフォール型の開発よりも増えてしまうが、ハイブリッドアジャイルではコミュニケーションを重視することで作成するドキュメント類の削減/簡略化が見込める。

 さらに、テストの自動化、イテレーション計画やイテレーションレビューによる仕様の確認などを行えば、不具合摘出率を減らすことも可能だ。イテレーションごとにレビューをするため、以降のイテレーションでは類似の不具合を作り込まないようになる。これで、テスト作業やプログラムの修正工数も削減できる。

 アジャイル開発によって品質が悪くなったというプロジェクトを聞くことがある。そのようなプロジェクトの多くは、テストのチェックリストを作成せず、テスト工程もおろそかにしている場合が多い。テスト作業の手を抜いて、品質を確保できるという考えは甘い。品質が悪くなるというのは、とてもアジャイル開発を理解している人の発言とは思えない。アジャイル開発の理解が不十分な人が、失敗の理由をアジャイル開発のせいにしているだけである。

 アジャイル開発を理解しているプロジェクトは、不具合摘出率も低くなる傾向があり、全体の不具合修正コストも抑えられる。開発するソフトウエアの品質も、生産性も高くなる傾向がある。もし、アジャイル開発を実践してもこのような結果にならないのであれば、理解が不足していると思ったほうがよいだろう。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。今なら有料会員(月額プラン)が4月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら