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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

はじめに 2

Slide 3

Slide 3 text

はじめに Agileな開発に切り替えていくことで、開発スピードが上がり、高速にリリース可能な状態まで持っていける組織が増えてきました。しかし、安定した事業を進める中で「そのままリリースするとバグが発生するのではないか？」「こんなに素早くリリースなんてできないよ」と考えている人も多いのではないでしょうか？本セッションでは、品質を保ちつつ、Agileのような変化を歓迎して価値を最大化するための方法を議論していきます。

Slide 4

Slide 4 text

Slide 5

Slide 5 text

セッション紹介の補足登壇タイトルに「開発スピード」と表記しましたが、実際にスピードが上がっているのは「価値提供のスピード」です品質に注目すると… ● 提供する価値を増やせるのではないか ● 価値提供のスピードについていけないのではないかということが考えられます。

Slide 6

Slide 6 text

各登壇者の立ち位置 ● 雄介さん ○ アーキテクトとして ○ アジャイルプラクティス実践者として ● 🥦 ○ QAとして ○ Agileな開発におけるテスト活動の実践者として ● 安達さん ○ 雄介さんと🥦が話した内容で分かりづらいところのツッコミ役として

Slide 7

Slide 7 text

雄介さんの発表 7

Slide 8

Slide 8 text

Agileな品質と構造鈴木雄介 @yusuke_arclamp

Slide 9

Slide 9 text

自己紹介 ● 鈴木雄介 ● Graat　代表取締役社長 ● アイムデジタルラボ　取締役 ○ 三越伊勢丹グループ ● 社外活動 ○ 日本Javaユーザーグループ　CCC運営委員長 ○ X：https://x.com/yusuke_arclamp ○ ブログ：https://arclamp.hatenablog.com/

Slide 10

Slide 10 text

DXリーダー必修講義 ● 2024年12月23日発売 ○ 日経BP社 ● アジャイル(2001年)から始まる四半世紀のテクノロジーの歴史を紹介しながら、どのように変化に強いシステムを作ってきたのかを解説 ○ 大企業で採用するときの注意点付き

Slide 11

Slide 11 text

品質って何

Slide 12

Slide 12 text

利用時の品質利用時の品質そもそも品質って何？プロセス品質内部品質外部品質利用時の品質 JIS X 25010:2013より作成構造 (残る) 挙動作業 (残らない)

Slide 13

Slide 13 text

これまでの品質

Slide 14

Slide 14 text

これまでの品質 1/2 ● 目指すのは「外部品質」の確保 ○ 挙動が「仕様通り」「バグがない状態」 ○ リリースする瞬間に十分な品質になることを目指す利用時の品質利用時の品質プロセス品質内部品質外部品質利用時の品質

Slide 15

Slide 15 text

これまでの品質 2/2 ● 品質を確保するための考え方 ○ 機能を定め、テストプロセスで頑張る ■ 単体テスト、結合テスト、総合テスト... ■ 構造(≒内部品質)を標準化すると尚良し利用時の品質利用時の品質プロセス品質内部品質外部品質利用時の品質

Slide 16

Slide 16 text

アジャイルの品質

Slide 17

Slide 17 text

アジャイルの品質 1/3 ● 最終的に目指すのは「利用時の品質」の向上 ○ まさに「価値」の向上 ■ 「価値」はユーザーの体験によって生まれる ■ 「価値」は相対的に変化する ● 競合他社がより良いものを提供する ■ 良い価値とは何か？は本日の対象外 ● サービスデザインとかユーザビリティとか ● 価値を向上させ続けるには機能をどんどん変えていく必要がある

Slide 18

Slide 18 text

アジャイルの品質 2/3 ● 開発として目指すのは「外部品質」の維持 ○ 機能や構造を変え続けても外部品質を維持したい ■ 新しい技術やプロダクトを採用したい ■ 利用時の品質に大きな影響がなければ、多少のバグも許容できる利用時の品質利用時の品質プロセス品質内部品質外部品質利用時の品質

Slide 19

Slide 19 text

アジャイルの品質 3/3 ● 品質を維持するための考え方 ○ これまでのテストプロセスを頑張るだけはスピードが落ちてしまう ○ なので、構造(内部品質)にも取り組むべき利用時の品質利用時の品質プロセス品質内部品質外部品質利用時の品質

Slide 20

Slide 20 text

構造に取り組む

Slide 21

Slide 21 text

構造に取り組む ● DevOps ○ IaC、Gitによる構成管理、ビルド・デプロイの自動化、GitOps... ● マイクロサービスアーキテクチャ ○ 部分の変更が全体に影響を及ぼさないようにする ■ サービス同士を疎結合にする ● クラウドネイティブ ○ オブザーバビリティ、サービス間連携の高度化、データ連携の高度化...

Slide 22

Slide 22 text

内部品質の定量化 1/2 ● DORAによるDevOpsのFour Keys ○ デプロイの頻度 ○ 変更リードタイム ○ 変更失敗率 ○ サービス復旧時間 ● 「優れたチームはスピードと品質を兼ね備える」 ○ スピードと品質はバーターにならないスピード品質書籍：LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する

Slide 23

Slide 23 text

内部品質の定量化 2/2 ● GoogleによるSREのエラーバジェット ○ SLOの停止時間を「予算化」して管理 ■ 予算が余っている間はリリース速度を上げる ■ 予算が足りなくなってきたら品質を重視する ○ ○ 十分に素早くリカバリできるなら、障害が起きても利用時の品質は大きく毀損しない ● 書籍：SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

Slide 24

Slide 24 text

構造に取り組む ● 要注意 ○ 内部構造を安定させすぎると変化しにくくなる ■ 例：やりすぎた自動テストは、変化を阻害する ○ 疎結合化すると構造は複雑になる ■ 例：やりすぎたマイクロサービスは、以下同文 ○ 最先端な技術が正解なわけでもない ■ 例：扱いきれないKubernetesは、以下同文 ● 機能の変更を許容できる構造を育てることは重要だが、バランスは常に意識すべし

Slide 25

Slide 25 text

まとめ

Slide 26

Slide 26 text

まとめ ● アジャイル開発は「利用時の品質」が重要になので「機能や構造が変更し続けても外部品質を維持する」ことが大事になった。 ○ そのために構造へのアプローチが超重要になった ○ テストプロセスの変化は🥦の話でどうぞ利用時の品質利用時の品質プロセス品質内部品質外部品質利用時の品質

Slide 27

Slide 27 text

🥦の発表 27

Slide 28

Slide 28 text

Agileな開発に対応してどのように品質保証を行うか？ブロッコリー @nihonbuson

Slide 29

Slide 29 text

自己紹介 ● 風間裕也（ブロッコリー） ● 株式会社10X 品質管理チーム ● 副業：B-Testing（個人事業主）として ○ 株式会社MonotaRO （テストコンサルタント） ○ グロース・アーキテクチャ&チームス株式会社他数社でお手伝い ● 社外活動 ○ JaSST Review（ソフトウェアレビューシンポジウム）実行委員長 ○ WACATE（テストの合宿型ワークショップ形式勉強会）実行委員長 ○ SReEE（ソフトウェアレビューをエンジニアリングっぽく捉える会）リーダー SNS上のアイコン

Slide 30

Slide 30 text

翻訳書籍今日のメイン

Slide 31

Slide 31 text

Agileな開発に対応する品質戦略 ● 戦略1.自動テストをたくさん作成する ○ 手動テストに比べてテスト実行時間の短縮になる ○ 自動テストのケース数の選定をしないといずれ限界が来る ○ 仕様が固まっていない段階から自動テストを作るのは大変 ● 戦略2.早い時点から段階的にテスト活動を行う ○ バグの発見だけでなく、バグの予防に繋がる ○ 今回話す内容はコッチ

Slide 32

Slide 32 text

複数のテスト活動を組み合わせてプロダクトを作り上げる

Slide 33

Slide 33 text

高速道路の出口標識のようなテスト活動を目指す

Slide 34

Slide 34 text

高速道路の出口の手前には予告標識がある葛西 2km Kasai 3-1

Slide 35

Slide 35 text

予告標識は出口の手前に複数回表示される

Slide 36

Slide 36 text

テスト活動はリリース前に複数回行うテストテストテスト

Slide 37

Slide 37 text

受け入れ基準作成時のテスト活動

Slide 38

Slide 38 text

適用するタイミング 38 スプリントプランニングレトロスペクティブリファインメントスクラムとは（オージス総研）を参考に一部書き換え ※リファインメントは　スクラムイベントではない

Slide 39

Slide 39 text

受け入れ基準作成の事例

Slide 40

Slide 40 text

今回の対象となる機能 ● とあるtoCのプロダクト ○ 会員登録をすることでサービスを利用できる ● 今回新たに「管理者による強制退会機能」を開発することになった ● ユーザー本人による退会機能は既存機能として存在

Slide 41

Slide 41 text

リファインメント中の会話 PO 今回新たに管理者による強制退会機能を作ってほしい

Slide 42

Slide 42 text

リファインメント中の会話「ユーザー本人の退会機能」のロジックを流用する形で、コストをかけずに実装できるのかなと想像してたんだけどどうだろ？ PO 開発者確かに開発コストは低いかも

Slide 43

Slide 43 text

リファインメント中の会話 QA ちょっと、今回の機能の背景を知りたいです！どうして強制退会機能を作ろうと思ったんでしたっけ？

Slide 44

Slide 44 text

リファインメント中の会話 QA ちょっと、今回の機能の背景を知りたいです！どうして強制退会機能を作ろうと思ったんでしたっけ？ PO 他人に迷惑をかけるユーザーがいるので、そのユーザーはサービスを利用できないようにしたいからです

Slide 45

Slide 45 text

リファインメント中の会話 QA そしたら、強制退会になったユーザーは再度の会員登録はできないようにしないと意味がないですかね？ああ、確かにそうですね。 PO

Slide 46

Slide 46 text

受け入れ基準の作成【タイトル】管理者による強制退会機能【受け入れ基準】 ● 管理者がユーザーのアカウントを指定して退会させることができること ● 退会させられたユーザーは同じメールアドレスで会員登録できないこと

Slide 47

Slide 47 text

リファインメント中の会話 QA じゃあ、開発が終わってテストする時は強制退会させられたユーザーが会員登録できないかもテストしますね！了解です！開発者

Slide 48

Slide 48 text

受け入れ基準作成時に関わることの効果 ● 実装担当者が設計・実装を行う時に、「リファインメントでこんな会話をしたな…」と思いながら実装する ○ その部分でのバグの作り込みを防ぐことができる ● バグが発生しなければ色々な工数が削減できる ○ 実装内容を思い出すコスト ○ 修正をするコスト ○ もう一度テストするコスト ○ 影響範囲のある箇所をテストするコスト ○ バグチケットの操作をするコスト　　　　など

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

まとめ ● Agileな開発に対応する戦略として、自動テストの作成以外に、早い時点から段階的にテスト活動を行う方法がある ● リファインメントなどでの受け入れ基準作成時にテストの考え方を用いる ● 事前にテスト内容を伝えておくことで、バグ作り込みを防ぐことができる

Slide 51

Slide 51 text

パネルディスカッション 51

Slide 52

Slide 52 text

自己紹介 ● 安達賢二 ● 株式会社ＨＢＡ経営企画本部／イノベーション推進室・理事 ● 社外活動 ○ NPO法人ソフトウェアテスト技術振興協会（ASTER）理事 ○ JaSST nanoお世話係 ○ JaSST Review（ソフトウェアレビューシンポジウム）実行委員 ○ ソフトウェアレビューをエンジニアリングっぽく捉える会：SReEE(スリー) メンバー

Slide 53

Slide 53 text

議論1：それぞれの発表を聞いた感想 ● 共感した部分：（口頭で） ● 確認したいところ1：すべての案件がAgileで？ ● 確認したいところ2：便利なツールも永遠ではない ○ ツール採用決定要因は？ ● 確認したいところ3：QAエンジニアが開発に参加 ○ 参加するコツ／強みである客観性が失われないか？ ● 確認したいところ4：どっち？どのくらい？ ○ 鈴：やりすぎた自動テストは、変化を阻害する ○ ブ：戦略1.自動テストをたくさん作成する

Slide 54

Slide 54 text

安達さんによる整理 Balus上に公開してます https://balus.app/view-mod els/851tc5ez1l545vy1ldytt m8njoyo8d

Slide 55

Slide 55 text

どうして強制退会機能を作ろうと？受入基準議論2：🥦リファインメント事例の構造新たに管理者による強制退会機能を作って欲しいユーザー本人の退会機能のロジックを流用する PO 開発コストは低くできそう！開発者 QA 迷惑をかけるユーザーはサービス利用できないように強制退会ユーザーは会員再登録できないように！ QA PO PO

Slide 56

Slide 56 text

議論3：2人の提示をマッピング早期の段階的テスト活動早期の段階的テスト活動マイクロサービスアーキテクチャ DevOps クラウドネイティブクラウドネイティブテスト自動化鈴木さん

Slide 57

Slide 57 text

おわりに 57

Slide 58

Slide 58 text

各登壇者から一言！ ●

Slide 59

Slide 59 text

鈴木さんのお知らせ CodeZine Academy アーキテクチャ設計実践講座 ● 次回は3/7 ● オフライン開催

Slide 60

Slide 60 text

🥦のお知らせ CodeZine Academy 開発を加速するためのテスト講座 ● 次回は3/14 ● オフライン開催 ● バグを予防するテスト活動についてワークショップ形式で体験できます！

Slide 61

Slide 61 text

安達さんのお知らせ約2時間後にB会場（ココ）で登壇します ● 15:20～15:50 ● レビュー/テストからのフィードバックにどう立ち向かうのがよいか？～レビュー観点活用で開発が変わるかも〜 ● 【テーマ】品質とスピードとコストをまるっとよくするためにどうしたらよい？

Slide 62

Slide 62 text

おしまい 62 ご清聴ありがとうございました！