※ アジャイルのもっとも導入されているスクラムフレームワークをベースにしています。
アジャイルは速いが品質が悪い？
スクラムチームはスクラムガイドに従って実践していますが、スクラムはあくまでフレームワークなのでプロダクトの品質をどう高めていくかはチームの自己組織化に委ねられます。
しかしながらプロダクトを早く顧客に届けるプレッシャーの中でやっていくと厄介な状況になってしまうことはよく見かけています。
- テストの日：テストが終わらないから、スプリントの最終日を「テストの日」にする
- テストは後で、外で：スプリントで完成したものに自信はないのでテストをチーム外で回してからリリース判断する
- 新しい技術や学びなどは放課後に：新たなプラクティス（例えばテスト自動化）を取り入れたいチームに対してベロシティを下げないようにプレッシャーをかける
- 要件と仕様はビジネスの仕事、実装とテストは開発に仕事：ビジネス側が顧客が望むもの、ビジネスが求めるもの、全てを把握していると思い込んで、単独に要件、仕様、デザイン、受け入れ基準を細かく書き込んでからチームに回す
※ どんな要因でこういった状況になって、そしてそれがどんな影響をもたらすかは省略します。
結局スクラムを実践しているのに、俯瞰してみると開発工程モデル（いわゆるウォーターフォール）とサイロ化が根付いることで本来アジャイルで目指すビジネス効果の逆働きをしてしまいます。
ビジネス、経済、環境、顧客ニーズの変化が激しい現代では素早く反応して適応していく必要があります。そのためにはアジャイルは役に立ちますがそれよりも組織（文化、構造、プロセス、ルールなど）そのものが変わっていけるようにならなければなりません。
スクラムと品質の関係
品質の話しに戻ります。スクラムガイドから「品質」を検索してみると4箇所あります：
- 開発者の責任：「 完成の定義を忠実に守ることにより品質を作り込む。」
- スプリント：「品質を低下させない。」
- スプリントレトロスペクティブ：「スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。」
- 完成の定義：「完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。」
つまり完成の定義で品質の基準を明らかにし、スプリントでそれを満たすプロダクトを作り込んで、そしてレトロスペクティブで品質をどのように高められるか完成の定義を見直しつつ継続的に改善活動を行っていきます。
スクラムガイドではこの大事なルールが強調されていないかもしれません。それ故うまくいかないケースがあるかもしれません。
完成の定義はスクラムガイド2020版から登場していますので比較的に新しいですが、高品質なプロダクトを顧客に届けるためには欠かせないと断言していいでしょう。
完成の定義で品質を明らかにする
完成の定義（Definition of Done、DoD）は簡単に言ってしまえば「品質基準の書」になるもので、チェックリストのような形になってます。
ビジネスの面、エンジニアリングの面、顧客の面で考えると様々な品質属性がでてきます。
- マーケットの規制や法律に準拠しているか
- 会社のブランドに反していないか
- 集中的なアクセスがあってもサービスの利用が継続できるか
- ユーザは自分の個人情報を安心して渡せるか
- プロダクトアーキテクチャがスケールできるか
- コードが安易に変更できるか
- ログが取れて、探せるか
- など
幅広い内容ですが、結果的には顧客が満足していくための内容です。そして一人の専門性では作りきれないものです。だからこそ完成の定義の作成と見直しはスクラムチーム全体の責任であり、必要に応じてステークホルダーや顧客を巻き込んで作っていくものなのです。
そのためにはサイロ化を打ち壊し、顧客に価値を届けるための考え方とアプローチを変える必要があります。つまりマインドセットを変えていく必要があります。
完成の定義の鉄則
新しく結成されてこれからスクラムを実践していくチームは初めて完成の定義を作っていくわけですが、いくつか大事なポイントをまとめておきます。
- チェックリストのようなものである
- スクラムチームは対話を通じて共同で作るもの
- プロダクトに変更を加える度に達成しなければならない条件である
- 常に保ちたい品質の状態を表すもの
- 定期的に見直すべきもの
- 徹底すべきもの
完成の定義の落とし穴
完成の定義はスクラムチームにとって大事なルールであり、確約でもありますがいくつの落とし穴があります。特に以下の事態に注意しておく必要があります。
- いきなり大きく、細かく、ほぼ達成不可能なものを作ってしまう → 小さく作ってから少しづつ内容を増やしていく
- 一度作ったが見直しもせず放置してします → レトロスペクティブで定期的に見直す
- 誰かが作ってきた完成の定義 → スクラムチーム主体で作る
- 徹底されない完成の定義 → もしそれが起きたらレトロスペクティブで話し合って改善する
- 一番大事なことを見落とす → ビジネス、顧客、エンジニアリング、QA、すべての観点で考えて作って、そしてそれが本当に顧客の満足に役立つものなのかを検証する
更に品質を高めるならアジャイルテスト
完成の定義はスクラムの確約であって品質の高いプロダクトを目指すためには欠かせないものですが、他にはたくさんの思考とプラクティスがあります。
リサ・クリスピンとジャネット・グレゴリーの「実践アジャイルテスト」書籍ではアジャイル開発でのテストでは誰が何をすべきかを、担当者の役割などから実践的に解説します。
また、yamanecoとAgoraxはアジャイルテストの考え方とプラクティスを体験しながら学べる研修を共同で提供していますので、現場で品質を本格的に高めたい方は是非検討してみてください。
