【連載特集】エンタープライズアジャイルにおける品質担保をどう実現するか ―第4回 エンタープライズシステムに必要な品質管理

今までに、アジャイル開発における品質について、説明してきました。特に、テストに関連した品質がほとんどでした。ところが、従来型の開発プロセスでは、テストだけではなく、設計などの品質も担保しています。アジャイル開発での品質について、総合的な観点から見ていきます。

さらに、アジャイル開発の視点からだと、機能テストに集中する傾向にありますが、総合的には、パフォーマンスやセキュリティなどのシステムテストもおこなう必要があります。パフォーマンスのテストをしないで、システムをリリースできるわけではありません。

第1回 アーキテクチャーの変化
第2回 品質を支えるアジャイルテストとは
第3回 ツールで品質管理を始める

特約執筆者:長瀬 嘉秀

1.設計品質

 テストで検証できる品質の他にも、設計の品質もあります。従来型の開発では、設計フェーズで検証が行われ、それをパスすると、実装フェーズに進みます。各工程(フェーズ)に、ゲートが設けられているので、品質が工程ごとに担保されています。一方、アジャイル開発は、設計レビューをおこなう、というよりも、動くプログラムを早く作ることが重要視されています。そのため、設計が悪くなる可能性もあります。また、悪い設計でも、リファクタリングによって、修正していくので、改善はされます。アジャイル開発では、悪い設計とは言っていません。シンプルな設計を心がけよ、と言っています。悪い設計とシンプルな設計とは違います。

 それでは、設計品質とはどういうものでしょうか。オブジェクト指向が台頭する前は、モジュール化をしていき、共通関数にしていくことが良い設計の代名詞でした。オブジェクト指向が出てくると、継承によって、共通化をして、拡張性のある良い設計になります。一方、日本では、オブジェクト指向言語を使っても、継承などのオブジェクト指向の特徴を使わないプログラムが数多く作られました。業務系の大規模なシステムは、オブジェクト指向の機能を使っていないことがほとんどです。一回作って完成するアプリケーションであれば、これでも良いかもしれません。ところが、アジャイル開発のように、繰り返し開発をおこなうときには、プログラムの変更ができなくなってしまいます。従来の設計レビューはOKでも、アジャイル開発では良いということではありません。アジャイル開発では、オブジェクト指向の基本的なことを守っていかなくてはなりません。さもなければ、繰り返しのイテレーションが回っていかずに、開発が失敗してしまいます。

 オブジェクト指向の設計は、きちんとした教育により、できるようになります。ベテランのエンジニアは、非オブジェクト指向言語と同様なプログラムをベタ書きする癖を治す必要があります。きちんと、オブジェクト脳で考えて、プログラムを作っていく必要があります。

 設計をプログラマー任せにするのは心配な人は、最低限の設計書を作成して、レビューするべきです。

【図.1 設計品質】

第4回 エンタープライズシステムに必要な品質管理

このようなUMLのクラス図を書いて、設計に悪いところがないかを確認します。もちろん、アジャイル開発では、手書きの状態で、チーム全員で確認する方が好まれます。チーム全員で開発して、全員がプログラムコードを理解して、誰がどのコードを変更しても良いからです。従来型では、作る人と監査する人といように別れていましたが、アジャイル開発は、One Teamという思想なので、全く異なっています。ペアプログラミングやコードの共同所有など、プラクティスがOne Teamになるように、作られているのです。

 オブジェクト指向では、継承の機能を使って、共通するのが基本ですが、実際には、インターフェースが重要です。特にJava言語では多重継承がないため、インターフェースをうまく使うことが必要です。そして、継承というよりもインターフェースをうまく利用して、コンポーネントを状況に応じて、動的にスイッチできる設計にします。さらに、インターフェースを設計するには、テスト駆動開発で、インターフェースに対するテストを作成して、その後にインターフェースを実装するコードを書くようにします。テスト駆動開発は、いうなれば、インターフェース設計をしながらプログラミングをおこなっています。これには、エンジニアとしてのスキルが必要になります。よって、アジャイル開発には、フルスタックエンジニアと呼ばれるスキルの高いエンジニアが必要だと言われる由縁です。従来は、分業していた開発作業を一人でおこなうのです。これは、まさに、トヨタ生産方式で言うところの多能工です。

 品質の観点では、コードに対して、目視で確認するのは難しいことです。そのため、クラス図程度の図を作成して、チームメンバー全員で、確認するのがちょうどぴったりです。

 このように、設計品質と言っても、従来とは大きく異なることを理解していなければなりません。

2.シナリオテスト(結合テスト)

 アジャイル開発で、TDD(テスト駆動開発)を行えば、必然的にユニットテストはできあがります。ただし、従来型の単体テストとは異なります。TDDのユニットテストは、設計のためのテストなので、網羅性はありません。一方、単体テストは、単体アプリケーションを網羅性のあるテストを作成します。それでは、アジャイル開発で、網羅性のあるテストはどうするのでしょうか。それは、ユーザーが作成するシナリオになります。もちろん、ユーザーのシナリオが完全ではない場合も考えられます。そのために、アジャイルチームには、QAという品質の専門家が入るのです。このユーザーストーリーから派生させるシナリオによるテストは、従来型では、結合テストにあたります。アジャイル開発は、結合テストの工程は特には設けず、イテレーションの中で、結合テストを自動化して、常にテストします。自動化することで、工程として分ける必要がなくなります。いつでも、結合テストを動作することができるからです。

3.総合テスト

 リリース前におこなう総合テストに関しては、アジャイル開発では受入テストと呼ばれます。もちろん、総合テストもユーザーの確認のテストなので、検収のためのテストです。この受入テストを自走化すると、結合テストと同様に、リリースまでを全自動で行なえ、工程を分ける必要がなくなります。Webのシステムでは、全自動にするのは、比較的容易です。ただし、エンタープライズのような業務系のシステムでは、データの準備など手間のかかる作業があるため、なかなか自動化は難しいことです。そのため、リリース前に、総合テストだけのイテレーションを設けることもあります。アジャイル開発と従来型の開発との違い、対比を理解していることがエンタープライズアジャイル開発を失敗しない秘訣です。また、PMOなどの監査チームに対して、きちんとした証跡を提出できるようにもなります。アジャイル開発には、PMOはいらないと、というアジャイルの教科書のようなことを言っても、社内を説得するのは難しいことです。それよりも、違いを理解して、従来行ってきたことは、これで代用できます、と言った方が、問題なく開発を進めることができます。

 また、総合テストでは、機能面のテストだけではなく、パフォーマンスやセキュリティなどの非機能要件のテストもおこないます。従来は、これらのテストは、開発エンジニアのしごとではなく、どちらかというとインフラエンジニアの管轄でした。このため、開発エンジニアだけで、アジャイル開発をおこなうと、非機能要件のテストが甘くなり、リリース後に問題が起こることもあります。アジャイルチームには、必要な役割の人をきちんと揃えるようにしましょう。たとえば、スクラムでは、開発チームのメンバーをこういう役割の人にしろ、とは規定していません。プロジェクトによって、役割が異なるからです。従来型では、役割がはっきりしていて、工程も分かれていました。社内でアジャイル開発プロセスのテンプレートを作成する場合には、きちんと役割も想定したものを作るべきです。そうすれば、開発エンジニアだけでチームを組むことがなくなります。

 参考として、このようなテンプレートを作っておくと便利です。

「Open@ReeL 概要説明」(http://pw.tech-arts.co.jp/reel/docs/open_reel_abstract_v2_20111201.pdf

4.アジャイル開発の品質に関する動向

 アジャイル開発の提唱者が、Webやゲームアプリケーションだけをターゲットにしているわけではありません。たとえば、Joseph Yoder氏が提唱している「Agile Quality アジャイル品質パターン (QA2AQ)」などは、次のようなテストもきちんと想定しています。

Testing System Qualities
・ Usability
・ Security
・ Performance
・ Scalability
・ Internationalization
・ Availability
・ Flexibility
・ Accessibility
・ Location
・ Regulation

SEI資料より

これらのテストをきちんとおこなうことで、エンタープライズシステムでも、アジャイル開発での品質を担保できるようになります。今後は、エンタープライズシステムの開発を担っている情報システム部もしくは情報システム子会社でも、従来の品質とアジャイルの品質をきちんと整理して、Japan Qualityのシステムを開発運用していけるようになると思います。

5.まとめ

 これで、全4回のアジャイル開発の品質に関する連載は終了です。エンタープライズシステムに関わっている方々が、アジャイル開発を開発に取り入れていこうと考えても、従来型との違いに尻込みすることも多いと思います。今回の連載が、そのようなモヤモヤを整理するきっかけになれば、幸いです。開発プロセスや品質に関する考え方は、それぞれの企業にとって、異なることもあります。それ故、こうやれば良い、というひとつの解答があるわけではありません。各社が、自社の状況を踏まえて、アジャイル開発のテンプレートを用意していくことが必要です。テンプレートがあれば、プロジェクトでは、それをカスタマイズして使えます。アジャイル開発は、常にカイゼンによって、プロセスを変えていきます。テンプレート通りのプロセスで、第1イテレーションを行っても、第2イテレーションでは、レトロスペクティブによりカイゼンが行われ、まったく違うやり方になるかもしれません。本来は、日本がカイゼンは得意なはずです。ソフトウェア分野では、トヨタ生産方式をアジャイル開発として、欧米に先を越されてしまいました。これから、高品質なシステムを日本で、アジャイル開発で、構築できることを期待しています。

全編をまとめてお読みたい方、下記より全文をダウンロードできます。

全文ダウンロード

おすすめ記事