開発スピードは上がっている…品質はどうする？ スピードと品質を両立させるためのプロダクト開発の進め方とは #DevSumi #DevSumiB / Agile And Quality

Developers Summit 2025での登壇資料です。

【発表資料中のURL】
◆P22
『LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する』（Nicole Forsgren Ph.D, Gene Kim, Jez Humble　著、武舎 るみ, 武舎 広幸　訳）

◆P23
『SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム』（Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy　編、澤田 武男、関根 達夫、細川 一茂、矢吹 大輔　監訳、玉川 竜司　訳）

◆P30
『Agile Testing Condensed Japanese Edition』（Janet Gregory, Lisa Crispin　著、風間 裕也　訳）

『A Practical Guide to Testing in DevOps Japanese Edition』（Katrina Clokie　著、風間 裕也, 河原田 政典　訳）

『The BDD Books - Discovery (Japanese Edition)』（Gáspár Nagy, Seb Rose　著、風間 裕也　訳）

『The BDD Books - Formulation (Japanese Edition)』（Gáspár Nagy, Seb Rose　著、風間 裕也　訳）

◆P54
安達さんによる整理

◆P59
アーキテクチャ設計実践講座（2025.03.07） | CodeZine Academy

◆P60
開発を加速するためのテスト講座　〜アジャイル開発にも適用できるシフトレフトなアプローチ〜（2025.03.14） | CodeZine Academy

Transcript

1. 開発スピードは上がっている …品質はどうする？ スピードと品質を両立させるための プロダクト開発の進め方とは 1 #DevSumiB
2. はじめに 2
3. はじめに Agileな開発に切り替えていくことで、 開発スピードが上がり、高速にリリース可能な状態まで 持っていける組織が増えてきました。 しかし、安定した事業を進める中で 「そのままリリースするとバグが発生するのではないか？」 「こんなに素早くリリースなんてできないよ」 と考えている人も多いのではないでしょうか？ 本セッションでは、品質を保ちつつ、Agileのような変化を 歓迎して価値を最大化するための方法を議論していきます。
4. はじめに Agileな開発に切り替えていくことで、 開発スピードが上がり、高速にリリース可能な状態まで 持っていける組織が増えてきました。 しかし、安定した事業を進める中で 「そのままリリースするとバグが発生するのではないか？」 「こんなに素早くリリースなんてできないよ」 と考えている人も多いのではないでしょうか？ 本セッションでは、品質を保ちつつ、Agileのような変化を 歓迎して価値を最大化するための方法を議論していきます。
5. セッション紹介の補足 登壇タイトルに「開発スピード」と表記しましたが、 実際にスピードが上がっているのは 「価値提供のスピード」です 品質に注目すると… • 提供する価値を増やせるのではないか • 価値提供のスピードについていけないのではないか ということが考えられます。
6. 各登壇者の立ち位置 • 雄介さん ◦ アーキテクトとして ◦ アジャイルプラクティス実践者として • 🥦 ◦ QAとして ◦ Agileな開発におけるテスト活動の実践者として • 安達さん ◦ 雄介さんと🥦が話した内容で分かりづらいところ のツッコミ役として
7. 雄介さんの発表 7
8. Agileな品質と構造 鈴木雄介 @yusuke_arclamp
9. 自己紹介 • 鈴木雄介 • Graat　代表取締役社長 • アイムデジタルラボ　取締役 ◦ 三越伊勢丹グループ • 社外活動 ◦ 日本Javaユーザーグループ　CCC運営委員長 ◦ X：https://x.com/yusuke_arclamp ◦ ブログ：https://arclamp.hatenablog.com/
10. DXリーダー必修講義 • 2024年12月23日発売 ◦ 日経BP社 • アジャイル(2001年)から始まる 四半世紀のテクノロジーの歴史 を紹介しながら、どのように変 化に強いシステムを作ってきた のかを解説 ◦ 大企業で採用するときの注意 点付き
11. 品質って何
12. 利用時の 品質 利用時の 品質 そもそも品質って何？ プロセス 品質 内部品 質 外部品 質 利用時 の 品質 JIS X 25010:2013より作成 構造 (残る) 挙動 作業 (残らない)
13. これまでの品質
14. これまでの品質 1/2 • 目指すのは「外部品質」の確保 ◦ 挙動が「仕様通り」「バグがない状態」 ◦ リリースする瞬間に十分な品質になることを目指す 利用時の 品質 利用時の 品質 プロセス 品質 内部品 質 外部品 質 利用時 の 品質
15. これまでの品質 2/2 • 品質を確保するための考え方 ◦ 機能を定め、テストプロセスで頑張る ▪ 単体テスト、結合テスト、総合テスト... ▪ 構造(≒内部品質)を標準化すると尚良し 利用時の 品質 利用時の 品質 プロセス 品質 内部品 質 外部品 質 利用時 の 品質
16. アジャイルの品質
17. アジャイルの品質 1/3 • 最終的に目指すのは「利用時の品質」の向上 ◦ まさに「価値」の向上 ▪ 「価値」はユーザーの体験によって生まれる ▪ 「価値」は相対的に変化する • 競合他社がより良いものを提供する ▪ 良い価値とは何か？は本日の対象外 • サービスデザインとかユーザビリティとか • 価値を向上させ続けるには機能をどんどん変えていく 必要がある
18. アジャイルの品質 2/3 • 開発として目指すのは「外部品質」の維持 ◦ 機能や構造を変え続けても外部品質を維持したい ▪ 新しい技術やプロダクトを採用したい ▪ 利用時の品質に大きな影響がなければ、多少の バグも許容できる 利用時の 品質 利用時の 品質 プロセス 品質 内部品 質 外部品 質 利用時 の 品質
19. アジャイルの品質 3/3 • 品質を維持するための考え方 ◦ これまでのテストプロセスを頑張るだけはスピード が落ちてしまう ◦ なので、構造(内部品質)にも取り組むべき 利用時の 品質 利用時の 品質 プロセス 品質 内部品 質 外部品 質 利用時 の 品質
20. 構造に取り組む
21. 構造に取り組む • DevOps ◦ IaC、Gitによる構成管理、ビルド・デプロイの自 動化、GitOps... • マイクロサービスアーキテクチャ ◦ 部分の変更が全体に影響を及ぼさないようにする ▪ サービス同士を疎結合にする • クラウドネイティブ ◦ オブザーバビリティ、サービス間連携の高度化、 データ連携の高度化...
22. 内部品質の定量化 1/2 • DORAによるDevOpsのFour Keys ◦ デプロイの頻度 ◦ 変更リードタイム ◦ 変更失敗率 ◦ サービス復旧時間 • 「優れたチームはスピードと品質を兼ね備える」 ◦ スピードと品質はバーターにならない スピード 品質 書籍：LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する
23. 内部品質の定量化 2/2 • GoogleによるSREのエラーバジェット ◦ SLOの停止時間を「予算化」して管理 ▪ 予算が余っている間はリリース速度を上げる ▪ 予算が足りなくなってきたら品質を重視する ◦ ◦ 十分に素早くリカバリできるなら、障害が起きても 利用時の品質は大きく毀損しない • 書籍：SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
24. 構造に取り組む • 要注意 ◦ 内部構造を安定させすぎると変化しにくくなる ▪ 例：やりすぎた自動テストは、変化を阻害する ◦ 疎結合化すると構造は複雑になる ▪ 例：やりすぎたマイクロサービスは、以下同文 ◦ 最先端な技術が正解なわけでもない ▪ 例：扱いきれないKubernetesは、以下同文 • 機能の変更を許容できる構造を育てることは重要だ が、バランスは常に意識すべし
25. まとめ
26. まとめ • アジャイル開発は「利用時の品質」が重要になので 「機能や構造が変更し続けても外部品質を維持する」 ことが大事になった。 ◦ そのために構造へのアプローチが超重要になった ◦ テストプロセスの変化は🥦の話でどうぞ 利用時の 品質 利用時の 品質 プロセス 品質 内部品 質 外部品 質 利用時 の 品質
27. 🥦の発表 27
28. Agileな開発に対応して どのように品質保証を 行うか？ ブロッコリー @nihonbuson
29. 自己紹介 • 風間裕也（ブロッコリー） • 株式会社10X 品質管理チーム • 副業：B-Testing（個人事業主）として ◦ 株式会社MonotaRO （テストコンサルタント） ◦ グロース・アーキテクチャ&チームス株式会社 他数社でお手伝い • 社外活動 ◦ JaSST Review（ソフトウェアレビューシンポジウム） 実行委員長 ◦ WACATE（テストの合宿型ワークショップ形式勉強会） 実行委員長 ◦ SReEE（ソフトウェアレビューをエンジニアリング っぽく捉える会）リーダー SNS上の アイコン
30. 翻訳書籍 今日のメイン
31. Agileな開発に対応する品質戦略 • 戦略1.自動テストをたくさん作成する ◦ 手動テストに比べてテスト実行時間の短縮になる ◦ 自動テストのケース数の選定をしないと いずれ限界が来る ◦ 仕様が固まっていない段階から 自動テストを作るのは大変 • 戦略2.早い時点から段階的にテスト活動を行う ◦ バグの発見だけでなく、バグの予防に繋がる ◦ 今回話す内容はコッチ
32. 複数のテスト活動を 組み合わせて プロダクトを作り上げる
33. 高速道路の出口標識のようなテスト活動を目指す
34. 高速道路の出口の手前には予告標識がある 葛西 2km Kasai 3-1
35. 予告標識は出口の手前に複数回表示される
36. テスト活動はリリース前に複数回行う テスト テスト テスト
37. 受け入れ基準作成時の テスト活動
38. 適用するタイミング 38 スプリント プランニング レトロ スペク ティブ リファイン メント スクラムとは（オージス総研） を参考に一部書き換え ※リファインメントは 　スクラムイベントではない
39. 受け入れ基準作成の事例
40. 今回の対象となる機能 • とあるtoCのプロダクト ◦ 会員登録をすることでサービスを利用できる • 今回新たに「管理者による強制退会機能」を 開発することになった • ユーザー本人による退会機能は既存機能として存在
41. リファインメント中の会話 PO 今回新たに 管理者による強制退会機能 を作ってほしい
42. リファインメント中の会話 「ユーザー本人の退会機能」の ロジックを流用する形で、 コストをかけずに実装できるのかな と想像してたんだけどどうだろ？ PO 開発者 確かに開発コストは低いかも
43. リファインメント中の会話 QA ちょっと、今回の機能の背景を 知りたいです！ どうして強制退会機能を作ろうと 思ったんでしたっけ？
44. リファインメント中の会話 QA ちょっと、今回の機能の背景を 知りたいです！ どうして強制退会機能を作ろうと 思ったんでしたっけ？ PO 他人に迷惑をかけるユーザーが いるので、そのユーザーはサービスを 利用できないようにしたいからです
45. リファインメント中の会話 QA そしたら、強制退会になったユーザーは 再度の会員登録はできないように しないと意味がない ですかね？ ああ、確かにそうですね。 PO
46. 受け入れ基準の作成 【タイトル】 管理者による強制退会機能 【受け入れ基準】 • 管理者がユーザーのアカウントを指定して 退会させることができること • 退会させられたユーザーは同じメールアドレスで 会員登録できないこと
47. リファインメント中の会話 QA じゃあ、開発が終わってテストする時は 強制退会させられたユーザーが 会員登録できないかもテストしますね！ 了解です！ 開発者
48. 受け入れ基準作成時に関わることの効果 • 実装担当者が設計・実装を行う時に、 「リファインメントでこんな会話をしたな…」と 思いながら実装する ◦ その部分でのバグの作り込みを防ぐことができる • バグが発生しなければ色々な工数が削減できる ◦ 実装内容を思い出すコスト ◦ 修正をするコスト ◦ もう一度テストするコスト ◦ 影響範囲のある箇所をテストするコスト ◦ バグチケットの操作をするコスト　　　　など
49. まとめ
50. まとめ • Agileな開発に対応する戦略として、 自動テストの作成以外に、 早い時点から段階的にテスト活動を行う方法がある • リファインメントなどでの 受け入れ基準作成時にテストの考え方を用いる • 事前にテスト内容を伝えておくことで、 バグ作り込みを防ぐことができる
51. パネル ディスカッション 51
52. 自己紹介 • 安達賢二 • 株式会社ＨＢＡ 経営企画本部／イノベーション推進室・理事 • 社外活動 ◦ NPO法人 ソフトウェアテスト技術振興協会 （ASTER）理事 ◦ JaSST nanoお世話係 ◦ JaSST Review（ソフトウェアレビューシンポジウム） 実行委員 ◦ ソフトウェアレビューをエンジニアリングっぽく 捉える会：SReEE(スリー) メンバー
53. 議論1：それぞれの発表を聞いた感想 • 共感した部分：（口頭で） • 確認したいところ1：すべての案件がAgileで？ • 確認したいところ2：便利なツールも永遠ではない ◦ ツール採用決定要因は？ • 確認したいところ3：QAエンジニアが開発に参加 ◦ 参加するコツ／強みである客観性が失われないか？ • 確認したいところ4：どっち？どのくらい？ ◦ 鈴：やりすぎた自動テストは、変化を阻害する ◦ ブ：戦略1.自動テストをたくさん作成する
54. 安達さんによる整理 Balus上に 公開してます https://balus.app/view-mod els/851tc5ez1l545vy1ldytt m8njoyo8d
55. どうして強制 退会機能を作 ろうと？ 受入基準 議論2：🥦リファインメント事例の構造 新たに管理者 による強制退 会機能を作って 欲しい ユーザー本人 の退会機能の ロジックを流用 する PO 開発コスト は低くでき そう！ 開発者 QA 迷惑をかけるユー ザーはサービス利 用できないように 強制退会ユー ザーは会員再 登録できないよ うに！ QA PO PO
56. 議論3：2人の提示をマッピング 早期の段階的 テスト活動 早期の段階的 テスト活動 マイクロ サービス アーキテクチャ DevOps クラウド ネイティブ クラウド ネイティブ テスト 自動化 鈴木さん
57. おわりに 57
58. 各登壇者から一言！ •
59. 鈴木さんのお知らせ CodeZine Academy アーキテクチャ設計実践講座 • 次回は3/7 • オフライン開催
60. 🥦のお知らせ CodeZine Academy 開発を加速するためのテスト講座 • 次回は3/14 • オフライン開催 • バグを予防するテスト活動について ワークショップ形式で体験できます！
61. 安達さんのお知らせ 約2時間後にB会場（ココ）で登壇します • 15:20～15:50 • レビュー/テストからのフィードバックに どう立ち向かうのがよいか？ ～レビュー観点活用で開発が変わるかも〜 • 【テーマ】 品質とスピードとコストをまるっとよくするためにど うしたらよい？
62. おしまい 62 ご清聴ありがとうございました！