現在は「VUCAの時代」と言います。VUCAとはVolatility（変動性）、Uncertainty（不確実性）、Complexity（複雑性）、Ambiguity（曖昧性）の頭文字をとったビジネスシーンで使われる言葉です。これら4つの言葉が表すとおり、「未来の予測が難しい状況」を表しています。
過去を振り返ると、使い古された言葉になりますが、高度経済成長時代に象徴されるように「作れば売れる」時代でした。しかし、VUCAという言葉が登場したように、現在は、「何が売れるかわかりにくい」状況に陥っています。ソフトウェア開発においても「何を作ればいいかわからない」時代になっています。
この連載では、現在やこれからの時代で求められるであろうソフトウェア開発における「品質」を再定義し、あるべき姿への道筋を示し、代表的なプラクティスなどを紹介しながら、アジャイルQA（アジャイルな品質保証、もしくは品質合意）活動や、具体的な手段としてアジャイルテスティングのあり方を議論していきます。
第2回目のテーマは、アジャイルQAトランスフォーメーションです。アジャイルQAを目指すためのロードマップを考えていきます。
はじめに
前回は、アジャイル時代に求められる「品質」について考えました。アジャイルな開発が行われる現場であれば、従来型の品質保証がうまくマッチしない可能性があるため、アジャイルなQAが求められてきます。さらに、アジャイルなQAにうまく移行していく必要があります。
アジャイルQAへの道のりはいくつかありますが、アジャイルコーチとしていくつかの現場で実際に行った方法を紹介させていただきます。すべての現場で同じ方法が通用するわけではないでしょうが、だいたいの方向性は似たようなものになるように思います。
この方法は、品質保証部門のメンバーが主体的にやる場合もありますが、開発全体で取り組む課題も多いため、開発全体でCTOやエンジニアリングマネージャーを巻き込みながらすすめるのがおすすめです。
ヒアリングのすすめ
最初のステップは情報収集です。まずは、現状を把握しましょう。みなさんの組織には様々な役割の方がいらっしゃるはずです。
・ビジネス
・プロダクトオーナー
・デザイナー
・エンジニア
・カスタマーサポートなどなど
それぞれの役割にとっての「品質」とはなんでしょうか？
もしすぐに回答できないのであれば、残念ながら、サイロ化したQA組織になってしまっている可能性があります。品質を保証する立場に固執すると、品質を提供する相手の期待が理解できなくなってしまいます。これでは他の組織からの期待に答えられるはずがありません。
こういったケースでは、まずそれぞれの役割の人たちに協力していただいて、「彼らにとっての品質」を確認していきましょう。そして、その品質をおびやかす問題や課題を集めていきます。
たとえば上の図のように、縦軸に役割、横軸にDevOpsの活動を定義して整理もできます。図はよくある課題例ですが、様々な問題が現場にあることがわかるはずです。また、役割を超えて共通する課題も見えてきます。共通する課題は難解な物も多いですが、解決すると大きな成果が見込めるとも考えられます。
コラム：継続的デリバリーの成熟モデル 継続的デリバリーの成熟モデル 上記のヒアリング図は、書籍『継続的デリバリー』の成熟モデルをベースに作ったものです。この成熟モデルはちょっと古いものですが、自分たちの現場がどれぐらいできているのか？ 5段階のレベルで確認できます。 たとえば、「テスト」においてLevel -1だと「開発後にマニュアルテストしている」です。次のレベルに進むなら「部分的にUTが自動化できている」用になる必要があります。もっとも高いLevel3になるためには「本番でのロールバックがほとんどなく、欠陥が見つかってもすぐにFixされる」状態にならなければなりません。 |
品質向上活動をまとめる
ヒアリングによって現状の課題が見えてきました。次は、今やっている品質向上活動をまとめていきます。
上記のヒアリングと同じく、サイロ化したQA組織では、組織内の品質向上活動について、開発全体の視点で説明できる人は少ないかもしれません。もちろん、それぞれの役割ががんばって品質改善活動をすすめれば、全体として品質はよくなるかもしれませんが、お互いが連携しないのは非効率です。
また、従来型のフェーズを活用した品質保証活動では、最後にまとめて品質をなんとかしようとしてしまいがちです。たしかに、フェーズの最後にまとめてテストするほうが効率的な場合もあります。しかし、アジャイル・DevOps時代では、プロセスの最後にやるリスクのほうが問題視されます。最後に問題が起きて手戻りが起きていては、開発スピードが下がってしまうからです。
上の図は設計やテストといった活動ごとに、どういった品質改善活動を行っているかを整理した図です。
それぞれの方法ごとに、何をしたいか？ 誰がするのか？ いつやるのか？ 何をしているのか？ を整理していきます。整理しながら非効率な重複を発見し、足りていない場所を洗い出します。
| コラム： まずは手戻りを撲滅しよう さまざまな現場で、QA活動のコンサルティングを行ってきましたが、問題や課題を抱える現場において、手っ取り早く成果を出す方法が「手戻りを撲滅する」です。 たとえば、RedmineやJIRAを使ってバグ管理されているのであれば、原因分析を行ってみてください。ここで手戻りがよく発生しているのであれば、発生回数ゼロを目指します。 |
| プロセス | 原因例 |
| 要求・要件・仕様 | ・要求・要件の間違い・仕様不備や不足など |
| 設計 | ・検討不足・考慮漏れ・データ制御ミス・システム間連携ミスなど |
| コーディング | ・コーディングミス・レビュー漏れ・実装漏れ・デグレードなど |
| テスト | ・考慮漏れ・実施ミス・スコープ漏れなど |
| リリース | ・マージミス・リリース漏れ・影響範囲考慮漏れ |
| 設計ミスやコーディングミスをゼロにするのは難しく、やるとしても時間がかかってしまいますが、仕様矛盾や要件定義ミスはコミュニケーションを改善するだけでかなりの問題を減らせます。さらに、手戻りほどムダなものはないので、成果や効果を感じやすいはずです。 さらに、手戻りは様々な人が関わる部分で発生します。よって、必然的にプロダクトオーナーやエンジニアを巻き込んだ改善活動になっていくため、開発全体に影響を与えやすいはずです。 社内に品質を改善していく文化を浸透させていく上で、「手戻りをゼロにする」というゴールは、わかりやすく、共感を生みやすく、実現しやすいアクションになると思います。 |
アジャイルQAへの計画を立てる
ヒアリングによって、組織全体の現状を把握し、現状行っている品質改善活動を整理することで、どこで何をしているかが見えてきたはずです。次に、開発の流れにまとめていきましょう。
上記のように、開発の流れを誰にでもわかるように図にまとめます。この図を見るだけで開発の流れが理解できるはずなので、新しく入ってきたメンバーへのオンボーディングプロセスでも活用できます。
現状の流れをもとに、理想の流れを考えます。そして、現状とのギャップを埋めるためのアクションを洗い出し、アクションに落とし込んでいきます。
アクションが整理され、優先順位をつけられたら、誰がいつまでにやるかを決めます。みなさん、通常業務を抱えているでしょうから、徐々に進めていく方法も取れますし、タスクフォース型の専任チームを作って進める方法もあります。この改善を自分ごととして広めるのであれば、前者のほうがいいでしょう。
まとめ
今回は、アジャイルQAへの道のりを紹介しました。今回紹介した方法を、誰かが主体的に進めていく方法もできますが、それぞれの方法を、関係者全員でワークショップ形式で進めていくのもおすすめです。
大切なことは「開発全体で品質改善活動に取り組む」文化を作っていくことです。
アジャイル時代の品質は、誰か一人やどこか一部署ががんばってなんとかできるものではなくなってきています。ぜひ、誰もが「自分ごととして」、自分たちのプロダクトの品質を考える文化を作っていきましょう。
今回はアジャイルQAに向けてのロードマップを考えました。次回は、具体的なアジャイルQAプラクティスを考えていきます。
参考文献：
テストを導くためのテストアーキテクチャの組み立て方。
テストアーキテクチャを使ってプロジェクト全体のテスト活動の方針だてを行う手法が具体的に紹介されています。
