連載最終回の今回は、COMMONDATION-ReeLの品質管理方法と、なぜ修正コストを低減して要件変更に対応することができるのかについてお話しします。
品質管理
COMMONDATION-ReeLでは、要求/作成/検証の3つのフェーズを設けています。品質に対する強い拘りは、日本の誇るべきところでもありますので、コスト削減のために安易に省略せずに検証フェーズとして独立して設けています。
ソフトウェアテストは、作成フェーズで行うテストと検証フェーズで行うテストに分けています。作成フェーズでは、図1の「①開発」の中でプログラミングと同時に単体テストを行います。並行して「②テスト計画」を進め、「③開発者テスト」と「④顧客テスト」に向けたテスト項目を決めておきます。③では開発者が結合テストを行い、④ではお客様に確認テストを行っていただき仕様との違いや仕様変更がないかを早期に確認します。もし、変更が必要となった場合には、次のイテレーションで対応します。
検証フェーズは、ウォーターフォール型の総合テスト以降の工程とプロセス的には特に変わりはありません。検証フェーズでは、「⑤開発者テスト」と「⑥顧客テスト」を行います。開発者テストは、総合テスト/システムテスト/品質管理部門検証を行います。顧客テストはお客様による検証ですが、既に作成フェーズで行われているため、ここでは回帰テストとして行われます。そのため、この工程で見つかる不具合の数も、ウォーターフォール型に比べて少なくなることが期待できます。
作成フェーズの「①開発」作業をもう少し詳しく説明させていただきます。ステージという一定の期間内で計画された機能を開発します。ステージはイテレーションを繰り返し、計画的に開発を進めていきます。テストはTDD(Test-Driven Development)を基本としており、少なくとも単体テストについては、テストケースを先行して作成しプログラム開発を行います。
COMMONDATION-ReeLでは、日々の開発状況を繰り返しチェックし問題を早期に検出するために、継続インテグレーション(Continuous Integration)環境を図2のように整備します。この環境では、開発者PC上で開発したプログラムソースを共有サーバに格納するとビルドされ、単体テストやコード解析などのテストが自動的に実行されます。ここで実行されるテストケースは、繰り返し何度も利用することができます。テスト結果や進捗などは、タスク管理ツールなどと連携を行い、常に現状を管理することができます。また、ツールにより実行ログの解析結果をまとめ、テスト件数とテストケースパターンの分析を行い、単体テストでの品質確認を行います。
修正コスト低減
修正コストを減らすためには、修正量を減らすことと修正スピードを上げることが求められます。これは、アジャイルに限らずウォーターフォール型でも言えることですが、アジャイルではお客様と一体となったプロジェクトを原則としているため、お客様からのフィードバックを早い時期に得られるというメリットがあります。
修正量の削減
修正量を減らすために、設計ドキュメントはできる限り減らすか簡略化します。COMMONDATION-ReeLでは、プログラム修正に影響するアプリケーション設計ドキュメント量を大幅に減らしています。表1は、当社のウォーターフォール型開発手法で標準としている必須成果物の種別数との比較ですが、アプリケーション基本設計とアプリケーション詳細設計の成果物種類数(設計ドキュメント)を21種類から7種類としています。
保守用に必要となる詳細設計ドキュメントは、8種類をリバースしてエンハンス時に困らないようにしておきます。削減したドキュメントは、要求フェーズで直接画面作成を行うため画面設計用のドキュメントとリバースして作成するテーブル定義書/クラス・メソッド定義書/CRUD図などが主なものとなります。
修正スピードアップ
最近は、アジャイルプロセスに向いた管理ツールやテストツールも整備されてきました。修正スピードを上げるためには、自動化が有効な方法となります。品質管理の開発のところでお話ししたように、継続インテグレーションによる自動テストと管理ツールとの連携が有効な方法となります。
さらに、継続インテグレーションとリファクタリングは、デグレード防止としての仕組みとしても有効です。リファクタリングとはプログラムの外部振る舞いを変えずに内部構造を改良することです。修正の影響範囲を狭くするために、プログラム構造もできる限り疎結合な関係となるのが望ましいと思いますが、COMMONDATION-ReeLでは、プログラム構造に対する規定は今のところできていません。
おわりに
最後までお付き合いしていただきましてありがとうございました。COMMONDATION-ReeLの一部でありますが、今回ご紹介させていただく機会を設けてくださったgihyo.jpに感謝いたします。少しでも皆様のご参考になることができましたら幸いです。
私は、何にでもアジャイルプロセスを適用したほうが良いという考えではありません。今求められているのは、要件変更に対応しコストを計画された予算内に収めるような開発手法だと思っております。その参考となるプラクティスがアジャイルプロセスの考え方の中にはあります。日本の特徴を生かした開発手法として当社ではCOMMONDATION-ReeLを開発しましたが、常に改善を行っていきたいと考えています。