アジャイル開発でソフトウェアの品質を高める方法

2010年9月6日

9月4日土曜日に、有志によるアジャイル開発のイベント「XP祭り2010」が早稲田大学西早稲田キャンパスで開催されました。

招待講演には、日本XPユーザーグループ関西の細谷泰夫氏が「アジャイル×テスト開発プロセスを考える」の講演で、アジャイル開発などの開発プロセスとソフトウェア品質の関係について考察。アジャイル開発でのソフトウェアの品質を高める方法について、テスト開発プロセスからのアプローチが提案されています。

この記事では、この招待講演の内容を紹介しましょう。

アジャイルでソフトウェアの品質は良くなるか？

私は組み込み系で開発しているので、会社の性質上品質保証が非常に重視される。しかし一般的な受託開発にも当てはまるのではないかと思う。

さて、アジャイル開発でソフトウェアの品質は良くなるか？そう思う方、ちょっと手を挙げてください（4割くらい手が挙がる？）。けっこういますね。

自分の実感としては、アジャイルでは品質良くなる、と感じているが、一方で否定的な人もいる。

私がアジャイルを始めたころ、2002年あたりには、そういう否定的な人に対して「面倒くさいだけちゃうんか」とか「新しいプロセスに臆病なんじゃないか」と反発したりしていた。

考えてみると、ソフトウェアの品質には2つの側面がある。良し悪しという側面と、品質が確定しているかどうか、という側面。

品質保証担当の人が考えるアジャイルの品質確定のイメージは、こういうイメージなのかなと。アジャイルでイテレーションを繰り返して成果物が大きくなるにつれて、次のイテレーションで品質を確定させるためには、さらにたくさん作業をしなくちゃいけないなと。

一方でウォーターフォールでは、きちっとレビューして、テストフェーズでテストをしていけばリニアに品質が確定していきますよと。

この2つを比べると、ウォーターフォールの方が効率よく品質を上げられるように見えるのではないか。

でもウォーターフォールかアジャイルかで品質が良い悪いは、本質的にはないのではないかと思っている。

ウォーターフォールはみなさんも印象が悪いと思う。プロジェクトがうまくいかなかった記憶がウォーターフォールとともに呼び出されるから。でも、失敗の要因のほとんどはウォーターフォールだからではなく、人災だと思う。

うまくいかないときというのは、矛盾がある。工期に対して開発しているものがあまりに大きいといった矛盾や、テスト期間もないのに品質を上げろとか。ウォーターフォールを正しく行うには、やっぱり会社の上司とかリーダーとか作業する人が、自分のところでそういう矛盾を食い止めようという気概や覚悟がないと、するっと下流の工程に矛盾が流れていく。

そして、矛盾を突き上げて下流から上流を変えるのはすごくパワーも時間もかかる。だから矛盾を抱えて仕事をした結果、失敗しちゃったよとなる。そういう、気概のない組織では不幸になりやすいのかなと思う。

一方でアジャイル開発は、仕組みとして、動くものを作って、そのフィードバックをもらってと、プロセスとして強制的に矛盾が小さいサイクルで上流に戻っていくので、そこで矛盾が解消されていくところがある。

だからプロセスというより、品質を高めるために何をするか、が重要ではないか。

やるべきことをやれば品質確保はできる。でも難しい

どうやったら目標の品質に到達するのだろう？

その目標の品質とは何だろう？それは開発対象、ドメインなどのコンテキストによって異なる。計画において定義し、共有することが大切。

失敗すると人が死にますとか、ちょっとしたバグで何十億円も損失が出る、というソフトウェアと、問題があってもすぐに更新してくれればいいや、それよりすぐに作ってほしいなど、ビジネスによって目標とするソフトウェアの品質は異なる。それを計画によって定義して共有するのが大事。

目標の品質であることを確定させるには、このような手順が必要だと思う。

この図にある「テストモデル」という言葉は「品質を確定するためのテスト」というテストの概念。それによってテストを実施すると不具合が出て、で、それを修正していくと開発対象のソフトウェアは目標の品質に達する、というもの。

ところが、現実には開発対象のソフトウェアの品質がすごく悪いと、修正しても良くならないときもある。そういうソフトウェアはテストフェーズで頑張っても間に合わない。だから開発対象のソフトウェアの品質を最初から良くするのが大事。

そのためにウォーターフォールでは「Wモデル」で、要求設計とテスト設計などを同じ期間にやることで設計の品質を上げていく。

また、目標となる品質を達成するためのテストモデルも簡単には構築できない。だから、Wモデルの中にあるように、テストモデルを構築するための「テスト開発プロセス」も重要だ。

なぜテスト開発をしなければならないのかといえば、そもそも（あらゆる項目すべてをテストする）全数テストは現実的にできない。できないけれど、ユーザーが使う上で障害が発生しないようなテストは作らなければならない。そういう、よりよいテストはプロセスを経てきちんと開発しなければならない。

やるべきことをやれば品質確保はできる。でも難しい、スキルもいるしプロセスも必要。

で、アジャイルの話。

1回の本番は10回の練習に勝る

アジャイル開発では、テストと開発が協調し始めるのがソフトウェアの品質にとって大きいと思う。

ウォーターフォールでWモデルに従っていると、いざテストしようとしたら環境が合わなくて始められないとか、テストのための機能が抜けていたとか、ユーザー視点での改善点がたくさん指摘されたりとか。でもアジャイル開発ならそういう問題が早期に出てきて、テストエンジニアと開発者が一緒にその問題を解決していく。テスト設計を早期にやることで、設計の抜けや矛盾を減少させるWモデルと同じ効果が得られる。

私は趣味でコーラスをやっているが、「1回の本番は10回の練習に勝る」と先生によくいわれる。本番で全員揃って集中して歌うと、そのあとの練習でもすごく違ってくる。

それとソフトウェアの1回のリリースは似ているんじゃないか、そういうのがアジャイルのいいところではないかなと。

でも品質保証担当の人にとって、アジャイルだと柔軟にソフトウェアへの変更が加わるため、品質を確定していくという点で不安なのは理解できる。

繰り返しの中でテストモデルも成長させていけたら

だからアジャイル開発でのテスト開発を考える必要がある。私の大規模な組み込み開発での経験では、品質をどこで確定するか計画する必要があると考えている。

例えば、品質確定のためのテストをイテレーションの最後にやるべきとか。スクラムだと、実装がイテレーションごとに進化していくが、イテレーションごとに得た情報で、同時にテストも育てていくことが考えられないかなと思っている。

テストモデルを最初に考えるのは難しい、開発が難しいのと一緒でテストを開発するのも難しい。繰り返しのなかでテストモデルを成長させていけたらなあと思う。

一方で、テストを繰り返すのはオーバーヘッドだといわれることも多い。TDD（Test Driven Development、テスト指向開発）とか継続的インテグレーションではテストは自動化しようといわれているが、どうしても自動化できないところがある。そういうテストを（イテレーションごとに）繰り返さなければいけない部分はオーバーヘッドとしてマイナスにとられてしまう。

しかし目標の品質に達成するためのテストの開発が難しいものだととらえると、テスト自体を繰り返すことでテストモデルの品質を上げていくことができるのではないか。

そうすると、アジャイル開発と品質の高いテストモデル開発のための繰り返し、というのがポイントになるかなと思う。そしてこういう議論をしていくことで、品質の人と思いを共有できるようにならないかなと思っている。