アジャイルテストの4象限を 活用したリリース戦略の実践 熊川 一平 (ican.lab) [email protected] 

自己紹介 • 熊川 一平 (くまがわ いっぺい) • https://icanlab.net/ • 2023年に大手SIerを退社後、国家公務員(非常 勤) をやりながら、兼業個人事業主としてソフ トウェアテスト/品質管理を対象とした、コン サルティング/支援業務を提供。 • 趣味は野球観戦でしたが、今年は心身の負担が 大きいので、あまり見れていません。 

発表について • 本日は「個人事業主」としての熊川が発表します。 • 本発表は個人的な見解であり、所属する組織とは全く関係ありませんので、ご留 意ください。 • 本発表について、営利目的でなければ、写真撮影/録音/録画、資料の再利用、な らびにSNSでの発信をしたいただいて構いません。但し、意見や論評の度を越え て誹謗中傷とならないようにご注意ください。 • なお、営利目的での利用/流用については個別にご相談ください。（無許可での利 用が以前ございました。） 

エンタープライズ領域での アジャイル開発の現状 エンタープライズ領域でもアジャイル開発（主にScrum）が採用されるケースが増えて いるが、失敗事例も多く見られる。 【失敗例】 • プロダクトオーナーの承認によってリリースを行っているが、リリースを優先す るあまりに市場への不具合流出が後を絶たない。 • 開発しているソフトウェアの特性上、市場への不具合流出のリスクを許容できな いため、アジャイル開発の適用が困難になっている。 特にBtoB領域、ミッションクリティカル性のあるプロダクトでは本当によく見かける。 

Water-Scrum-Fall • エンタープライズ領域では、品質問題を回避するために、Scrum開発の前後で、要 件定義や結合テスト・総合テストといった工程を定義することが多い。 • いわゆる「Water-Scrum-Fall」になっている。 

Water-Scrum-Fallの弊害 Sprint期間が終わると、スク ラムチームがテストに注力 するようになり、開発のリ ズムが失われる。 1 レトロスペクティブなどが 開催されなくなり「透明 性・検査・適応」の３本柱 が機能しなくなる。 2 スプリントの完了基準と、 テストの完了基準が一致し ないため、プロダクトオー ナーや開発者の責任・権限 があいまいになる。 3 上記のような状態で、もう １度スプリントを回そうと しても、割れ窓理論で被害 は拡大しており「自己組織 化」とは遠く離れたチーム になってしまう。 4 

Water-Scrum-fallの弊害を回避しつつ、品質リスクを低減し、Scrum開発のメ リットを最大限に生かす方法を考えたい。 3つの対策 • リリースの定義を明確にする • チーム間の役割分担を明確にする • チーム内のロールを明確にする 

リリースの定義を明確にする ココって何？ ココって何？ ココって何？ 

リリースの定義を明確にする スクラムチームのリリースは内部リリースとし、内部リリース後の テストはスクラムチーム外の第三者が実施する。 ※内部リリースは様々な「限定的なリリース」といった形で実現される（次頁参照） Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 … 内部批評 内部批評 内部批評 … 内部リリース 市場リリース スクラム チーム IV&V チーム Ver1.0 Ver1.1 Ver1.2 

限定的なリリースを行う戦略の活用例 

役割分担を明確にする アジャイルテストの４象限に補助線を引き、チーム間の責務を明確 にする。Scrumチームの責務はDoneの定義に、IV&Vチームの責務 は市場リリースの基準に反映する。 

Scrum チーム IV&V チーム 市場で検証 Scrumチーム 限定 ユーザ 分担の仕方は状況に合わせて自由に選ぶ Scrumチームがやり切れる（＝Doneの定義に落とし込めて達成で きる）範囲であればどう分担しても構わない。 市場で 検証 

MTPとMVP • 顧客に価値提供できる最小限のプロダクト • 多くの場合、顧客の課題を解決できる最小限の 製品であったり、そのプロダクトらしさを少な からず内包している状態 MVP（Minimum Viable Product） • IV&Vチームの所掌するテストが可能な最小限 のプロダクト • 多くの場合、MVPよりも小さく、第3象限や第 4象限のテストが可能な状態 MTP（Minimum Testable Product） 

ロールを明確にする リリースの定義に合わせ、チーム内ロール（役割/責務/権限） を明確にする。特にスクラムチームの独立性に配慮する。 ロール名称 役割 ビジネスオーナー プロダクトへの投資判断と、最終的な市場へのリリース判断を行う。 また、デザイナーに対してビジネス上のニーズを伝える。 デザイナー/アナリスト ビジネス動向やユーザフィードバック、ユーザ分析などを通じ、プロダクトデ ザイン/改修案を作成し、プロダクトオーナーに伝える。 プロダクトオーナー デザインチームから連携された情報を元に、スクラムチームにおける開発内容 を決める。また、スクラムチームの成果物についてリリース判断を行う。 スクラムマスター （一般的なスクラムマスターの定義と同一であるため省略） デベロッパー （一般的なデベロッパ－の定義と同一であるため省略） 

Water-Scrum-Fallの悪い例 発注者 プロジェクト マネージャ デベロッパー プロダクトオーナー QA 要件定義 【外部リリース】 アプリケーション ユーザー フィードバック 市場情報 ビジネス結果 POがリリースを 判断していない 

ロールを明確にする デベロッパー ビジネスオーナー プロダクトオーナー スクラムチーム IV&Vチーム QA ビジネス要件 【内部リリース】 インクリメント (成果物) テスト結果 【外部リリース】 アプリケーション ユーザー デザイナー/アナリスト フィードバック 市場情報 ビジネス結果 サービス デザイン結果 POがリリースを 判断している 

ロールを明確にする デベロッパー ビジネスオーナー プロダクトオーナー スクラムチーム IV&Vチーム QA ビジネス要件 【内部リリース】 インクリメント (成果物) テスト結果 【外部リリース】 アプリケーション ユーザー デザイナー/アナリスト フィードバック 市場情報 ビジネス結果 サービス デザイン結果 

まとめ 手法 概要/特徴 Scrum • (DevOpsを体現する場合）デザインから開発/テストは同じチームが一貫 して実施する。 • 開発とテストを分断しない。 • 「リリース」は市場へのリリースを指し、その判断はプロダクトオーナー が実施する。 Water-Scrum-Fall • 要件定義から開発、テストまでを同じチームが一貫して実施する。 • 要件定義と開発とテストは分断されている。 • 「リリース」は市場へのリリースを指し、その判断はプロジェクトマネー ジャや発注者が実施する。 提案手法 • 要件を考えるチーム、Scrum開発を行うチーム、テストを行うチームがそ れぞれ独立している。 • Scrumチームにとってのリリースは内部リリースであり、プロダクトオー ナーが判断する。 • 市場へのリリースはIV&Vチームのテスト後に、ビジネスオーナーの判断 で行う。 

事例紹介 某製造業様 スマホアプリ刷新プロジェクト • 高額な製品と併せて利用するスマホア プリ＝品質の期待値が高い • 当初は厳格なスクラム開発でDevOps を志すも、小さな不具合を多数流出し てしまい、ユーザ評価が極めて低く なってしまう。 • 上記の問題に対応するため、開発後期 はWater-Scrum-Fallに移行。 • リリース速度は低下し、技術的負債を 抱え、ユーザ評価も改善せず。 

Four-Keysによる比較 • DORAのFourKeysを用いて、開発 初期/後期の比較を行った。 • 変更失敗率は後期になり改善して いるものの、その他の数字は悪化し ており、結果として顧客からの評価 も変わっていない。 開発段階 初期 後期 開発手法 Scrum Water-Scrum-Fall デプロイ頻度 High Medium リードタイム High Low 変更失敗率 Low Elite サービス復元時 間 Medium Medium 

（参考） DORAのFourKeys https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance 

提案手法の採用 • 品質/生産性改善のコンサルタントとして、1日/週で参画。 • 提案手法をベースとした新たな開発体制/手法を策定。 • Scrumチームのインクリメントはプロダクトオーナーの判断でβリリースと して、IV&Vチームと身内ユーザに配布。 • IV&Vチームの活動結果によってビジネスオーナーが市場リリースを決定する 仕組みに。 • 全体の人数に大きな変化なし。肥大化していたスクラムチームのメンバやプ ロジェクトマネージャをしていた人を、改めて割り振りなおした。 • 全関係者に事前教育を実施。 • 各ロールの担当者には個々の責務/役割の刷り込みを徹底。 

具体的な対応内容 • アジャイルテストの4象限を対角線で分け、左半分 をScrumチームの責務として設定し、Doneの定義 に取り込み。 • 右半分はIV&Vチームの責務とし、ビジネスオー ナーのリリースを判定する基準の1つに取り込み。 • チーム間で跨る象限（Q2/Q4)は、品質特性やテス ト観点を用いて、事前に話し合い境界を明確にした。 • Q2：スクラムチームはスモークテストとPOの 受け入れ条件のみ検証 • Q4：スクラムチームはAPI単体の性能のみ検証 • 見つかった不具合や問題は、一定の基準を設けた上 で、どのチームの検証範囲であるかどうかに関わら ず、どうすれば防ぐことができたのかをそれぞれで 検討し、改善を実施した。（その過程で、上記の境 界を変更したりもした。） 

細やかなパフォーマンス測定 FourKeysの各種指標はチーム全体・スクラムチーム単体の2つで取 得することで、改善したほうが良い箇所をわかりやすくしている。 Sprint1 Sprint2 Sprint3 Sprint4 Sprint5 … 内部批評 内部批評 内部批評 … 内部リリース 市場リリース スクラム チーム IV&V チーム Ver1.0 Ver1.1 Ver1.2 スクラムチーム単体のパフォーマンスとして、 内部リリースまでのFourKeysを取得。 チーム全体としては市場リリースまでの FourKeysを取得。 

実施結果 • リードタイムはMediumとなって 開発初期の厳格なScrum手法に比べ て若干の低下がある • その他の指標は現状維持or改善で きており、優秀な成績を収めた。 • 各チームの担当者やオーナーに対 してヒアリングを行ったが、総じて 好意的な評価を得ることに成功した。 • リニューアル後のアプリはリリー ス済みであり、ユーザ評価は非常に 高く、評価を下げるような不具合を 市場に流出させることもなくなった。 開発段階 初期 後期 リニューアル 開発手法 Scrum Water-Scrum-Fall 提案手法 デプロイ頻度 High Medium High リードタイム High Low Medium 変更失敗率 Low Elite Elite サービス復元 時間 Medium Medium Medium 

アンケート 結果 ヒアリングで得られた主な意見 • スクラムチーム • スクラムのプラクティスを逸脱する必要がなくなり、継続 してチームが自律的に動けている。 • 今まではテスト期間になると、スクラムのイベントが意味 をなさなくなっていたが、改善後はスクラムに集中できる ので、着実にリズムよく開発でき、改善が進むようになっ てきた。 • 各チームの役割分担が明確になり、自分の権限や責任がわ かりやすいので主体的に動きやすい。 • IV&Vチーム • 最初はどうなることかと思ったが、MTPの単位でテストの 依頼がリズム良く来るだけで、仕事がしやすかった。 • 責務領域のテストに集中できるので、チームパフォーマン スをあげる改善策が検討しやすく、色々な挑戦ができた。 • ビジネスオーナー/プロダクトオーナー • 市場リリース前に客観的な視点でテストされる安心感があ り、不要な心配をしてリリースを遅らせるようなことがな くなった。 • IV&Vチームによるテストがあるため、市場へのリリースを 安心して実施できるようになった。 

今後に向けて • 各種指標は良化しており、何よりも顧客満足度が大きくあがっ たことから、取り組みは成功したと判断している。 • 品質とデリバリーの両立に対しての悩み、特にスクラム期間内 でテストをどう実施すればよいかわからないエンタープライズ 領域におけるアジャイルの困りごとを解決できる手法になった。 • Undoneなタスクが多い場合や、bugfixが中心でMTP/テスト対 象のインクリメントが余り生まれない場合に、IV&Vチームへの タスク提供が滞ることがあったので事前策を考えたい。 (実際はそのすきに改善活動をしていた。） • 今後は同手法を展開することで、エンプラ領域でのアジャイル 開発の成功を支援していきたい。 

ご清聴ありがとうございました。 問い合わせはこちらまで。 [email protected]