※本記事は登録会員限定記事ですが、現在限定公開中です。
現在は「VUCAの時代」と言います。VUCAとはVolatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字をとったビジネスシーンで使われる言葉です。これら4つの言葉が表すとおり、「未来の予測が難しい状況」を表しています。
過去を振り返ると、使い古された言葉になりますが、高度経済成長時代に象徴されるように「作れば売れる」時代でした。しかし、VUCAという言葉が登場したように、現在は、「何が売れるかわかりにくい」状況です。ソフトウェア開発においても「何を作ればいいかわからない」時代になっています。
この連載では、現在やこれからの時代で求められる「ソフトウェア開発における品質」を再定義し、あるべき姿への道筋を示し、代表的なプラクティスなどを紹介しながら、アジャイルQA（アジャイルな品質保証、もしくは品質合意）活動や、具体的な手段としてアジャイルテスティングのあり方を議論していきます。
第1回目のテーマは、アジャイル時代に求められる「品質」とは何か？ です。
従来型とアジャイル型開発の違い
まずは、ウォーターフォールに代表される従来型の開発と、アジャイル型の開発を比較してみましょう。
それぞれ目的が異なる方法論のため単純比較はできませんが、特徴を見ていくと違いが明確になっていきます。
たとえば、従来型は作るものが決まっているプロジェクトが得意です。ゴールが明確なので、そこから逆算してプロジェクトを構築できます。前述の作れば売れる時代であれば、この方法が確実かもしれません。
一方、アジャイル型はというと、未来の予測が難しい状況が得意です。この問題に対応するために短くリリースを繰り返し、漸進的に成果物を開発していきます。馴染みある言葉を使うとすればPDCA（Plan：計画、Do：実行、Check：評価、Action：改善）を繰り返していくプロセスです。
従来型の品質とテスト
それでは、品質とテストについてはどうでしょうか？ 品質を基準とし、それを満たすための手段をテストとして、従来型とアジャイル型を比較してみます。
従来型は一般的に、工程ごとにチェックポイントを定め、事前に決めたレベルに達していない品質であれば、次の工程に進めなくすることで品質を守ります。
従来型の品質とは、「依頼した内容で作られていること」です。これが品質の基準となり、重要視されます。品質保証という言葉があるように、約束したことが「保証」されるのが重要です。
一方で従来型のテストは、「依頼したとおりになっているかの確認」が主眼になります。これを満たさないと納品できないので、開発側だけでなく依頼側も受け入れテストなどでダブルチェックします。よって、依頼された機能などを網羅的に確認していくテストが必要になってきます。仕様を完全網羅するテストを行わなければ、「依頼したとおりになっているかの確認」ができないので、開発規模が大きければ大きいほど、テストも膨大な量になります。
品質改善の方法にも特徴があります。プロセスの中にある独立したテスト工程によって品質の基準をクリアしているかどうかを確認したり、問題を可能な限り検知したりして、品質を高めてからリリースします。プロジェクトは特定期間を指すことが多く、プロジェクト後（リリース後）の品質改善は、その後の契約などに依存します。
誤解を恐れずにまとめると、従来型は作ったらそれで終わりです。リリースまでに品質の基準が契約などによって定められており、リリース時にはそれらがすでに確認されています。よって、契約にもよりますが、リリース後に開発や品質をどうしていくかはあまり考慮されないプロセスになります。
この方法にマッチする現場では問題ありませんが、残念ながら「未来の予測が難しい状況」に対応できません。たとえば、プロジェクト期間が3年といった長期にわたる場合、3年間で世の中がどう変わるか誰にもわからないので、プロジェクトの初期に決めた基準、内容で開発をすすめるしかありません。3年後、リリース時に「これじゃなかった」としても、プロジェクトは完了してしまいます。
アジャイル型の品質とテスト
アジャイル型開発は万能ではありませんが、変化に強い特徴を活かして開発をすすめていきます。これは品質に対しても同じです。
アジャイル型品質にとって、仕様通り作るのは「当たり前」であるため、その後、「期待通りユーザに価値として届くか」がより重要になります。これがアジャイル型品質です。ユーザへの価値提供には終わりがなく、予想も難しいため、品質保証（QA: Quality Assurance）が難しいと言えます。よって、ステークホルダー同士で品質の基準を決め合意する品質合意（QA：Quality Agreement）を行う現場も多いです。
アジャイル型品質では、従来型のように「仕様を確認するテスト」だけでは不十分です。フィードバックを得ながら、成功したり失敗したりしながら経験を積み、少しづつ開発を進めていくため、基準を決めにくく、「これをやればばっちり」というテストができないからです。
だから、価値を届ける可能性を高めるための「テスト」を実施します。アジャイル型開発では理論上、工程が存在しないため、開発に関わるあらゆるアクティビティに対してテストが必須となります。
上記は、[翻訳] DevOpsにおける継続的テストとは何か？ から引用した図です。DevOpsのプロセスには「テスト」という活動がありません。しかし、それぞれの活動の中で品質を高める責務を持たないとプロダクトが崩壊してしまいます。
従来型のようにどこかでまとめてテストする方法も取れますが、そこで問題が見つかった場合の手戻りが大きくなるため、問題を局所化してスピードを上げるならあまりいい方法ではありません。
そして、ここでの「テスト」は広い意味で使われています。
たとえば、コード（Code)でのテストなら、単体テスト（UT：Unit Test）やスクリプトテスト（いわゆる網羅的な手動テスト）が一般的でしょう。まさに「テスト」という印象を持たれるはずです。
では、リリース後のモニタリング（Monitor)をテストする場合はどうでしょう？ 何をどうやってテストすればよいでしょうか？ まずは、モニタリングするための情報が取れているかのテストがあります。複数のパターンをリリースしたのであれば、リリース後のテストとしてA/Bテストもできそうです。データによってテストする新しいスタイルであり、開発の外側にテストが飛び出していったのは興味深いことです。
このように、従来のテストのように、画面や動きなど何かを確認するような「テスト」だけでなく、互いにレビューして成果物の質を高めたり、データをもとに意思決定したりするのも広義の「テスト」と言えます。
アジャイルQAでは、（ある程度はがんばれますが）確実な保証ができません。よって、プロセス内でも品質改善活動を行っていきますが、プロダクトが続く限り改善を進めていきます。
まとめ
今回は、従来型の開発や品質をアジャイル型と比較しながら、それぞれの特徴を整理していきました。これらは対立の関係ではなく、時と場合によって選択する手段のひとつでしかありません。
しかしながら、本来は変化に柔軟な開発や品質が求められているはずなのに、従来型の開発や品質が行われている開発現場がとても多いように感じています（もしくはその逆のケースもあります）。筆者はアジャイルコーチとして様々な現場の支援を行ってきましたが、うまくいかないアジャイル開発のほとんどの原因が「使い方の間違い」です。
アジャイル開発に向かない現場にアジャイル開発を適用してもいいことはありません。たとえ自分の現場では導入できなくとも、アジャイル開発を知ることで、新しい選択肢が手に入ります。向き不向きはあれど、場合によっては適用できるケースもあり、問題解決のヒントにもなります。
変化の激しい現在では、どちらかを選ぶよりも、様々な選択ができる状態になる方が、変化に対応しやすいはずです。
第1回目は、アジャイル時代に求められる「品質」をテーマにお話させていただきました。次回は、アジャイルQAトランスフォーメーションと題して、アジャイルなQAになっていくためのロードマップを考えていきます。
