チーム全員で品質課題の改善のために取り組んだことを振り返る / Quality improvement team reflection

ソフトウェアテストシンポジウム JaSST '25 Tokyo

Transcript

1. 0 チーム全員で品質課題の 改善のために 取り組んだことを振り返る JaSST ’25 Tokyo Awata Kyosuke 2025.03.28
2. 1 自己紹介 2019年に、石油精製工場のプラントエンジニアからソフトウェアエンジニアに転生 しました。その後はエクセルスクショ職人の時期などかくかくしかじかありまして、 2023年10月からログラスでエンジニアとして働いています。 これまではフルサイクルエンジニアとしてプロダクト開発に注力することが多かった ですが、ログラス入社後はより一層「チームの成果を最大化するためには、なにをす るべきか？」を常日頃から考えて仕事をするようになりました。 最近は、スケーリングスクラムのフレームワークである「FAST Agile」にチャレンジ していて、その中でも持続可能な開発組織であり続けるために、ボトムアップな改 善活動などに力を入れて取り組んでいます。 愛車はスバルのBRZ（ZC6）で、推しは元AKB48の柏木由紀です。 株式会社ログラス エンジニア 粟田 恭介 Kyosuke Awata
3. 2 時は遡ること 2024年7月31日
4. 3 クラウド経営管理システムを提供する「ログラス」、Sequoia Heritageと ALL STAR SAAS FUNDを共同リード投資家とし、シリーズBで70億円 の資金調達｜PR Times
5. 4 当時のチーム状況 この調達を達成するまでに 私たちのチームで起こっていた 品質課題についての話をします
6. 5 当時のチーム状況
7. 6 当時のチーム状況 プロダクトは一気に機能が増え より複雑になったにも関わらず チームはケイパビリティを増やしきれず 特に品質面での課題が顕在化しはじめていた
8. 7 当時のチーム状況 ストレッチなビジネス目標に全力でフォーカス 「セコイア決戦」を経て、海外展開を加速 ー ログラスCEOが明かす、著名海外投資家からの資金調達の裏側｜MUGENLABO Magazine この投資ラウンドを進行させていた当時、ログラスは売上成長率の停滞という課題に直面していたそうです。 この状況を打開するために、打ち出されたのが「セコイア決戦」でした。 セコイア決戦の核心は、会社全体を「戦時」体制に移行させることでした。 この取り組みでは、長期的な成長のための投資や活動を全面的に停止し 短期的な目標達成に全力を注ぐことが求められました。 こうした取り組みは営業だけでなく、コーポレートや開発などの部門を含めて 「決戦」だという意識を全社でもちながら敢行されたといいます。 例えば開発部門では、長期的な技術負債の解消よりも、顧客が求める機能の迅速な開発に注力したそうです。
9. 8 当時のチーム状況 組織の急拡大によるメンバーの入れ替わり 年月 出来事 メンバー構成 2023年10月 エンジニア入社 EM, PdM, デザイナー, エンジニア×4 2023年11月 スクラムマスター入社 EM, PdM, デザイナー, スクラムマスター, エンジニア×4 2023年11月 エンジニアからEMにコンバート EM, PdM, デザイナー, スクラムマスター, エンジニア×3 2023年12月 エンジニアが入社 EM, PdM, デザイナー, スクラムマスター, エンジニア×4 2024年01月 デザイナー異動 EM, PdM, スクラムマスター, エンジニア×4 2024年06月 エンジニア入社・PdM交代 EM, PdM, スクラムマスター, エンジニア×5
10. 9 当時のチーム状況 プロダクトとチームの成長にギャップが生まれ始める イメージ
11. 10 当時のチーム状況 さらに専属QAが不在のスクラムチーム チーム① EM PdM Designer Engineer QA チーム② EM PdM Designer Engineer QA チーム③ EM PdM Designer Engineer チーム④ EM PdM Designer Engineer
12. 11 当時のチーム状況 私たちは路頭に迷いつつあった 仕様もコードもどんどん 複雑になりますね 専属のQAがいたら 解決するんですかね そもそも何が一番の課題 なんですかね?
13. 12 品質ナラティブとの出会い
14. 13 品質ナラティブとの出会い - 品質ナラティブとは 書籍「LEADING QUALITY」で以下のように定義されている LEADING QUALITY｜Ronald Cummings-John, Owais Peer. LEADING QUALITY. 河原田政典(訳). Kadokawa, 2023 品質ナラティブとは、企業で品質について考えたり話したりしている、その「語られ方」だ。 ジェイソンが述べたように、その存在を知っていようといまいとナラティブは存在し、 企業の品質文化に日々影響している。 自組織のナラティブを明晰に理解すればするほど、組織に変革をもたらし、目標を達成するために、 どのようにナラティブを調整する必要があるかを楽に考えられるようになる。
15. 14 品質ナラティブとの出会い - 品質ナラティブとは 品質ナラティブは３つのナラティブに分けられる LEADING QUALITY｜Ronald Cummings-John, Owais Peer. LEADING QUALITY. 河原田政典(訳). Kadokawa, 2023 責任ナラティブ テストナラティブ 価値ナラティブ 品質ナラティブ
16. 15 品質ナラティブとの出会い - 責任ナラティブとは 誰が品質に責任を持つかが考えられ、語られている LEADING QUALITY｜Ronald Cummings-John, Owais Peer. LEADING QUALITY. 河原田政典(訳). Kadokawa, 2023 テストチームやエンジニアチームだけが品質の責任を持てばいいわけではなく、むしろ、責任ナラティブを広げて、 高品質なプロダクトを確実にリリースするために全員が自身の役割を理解できるようにしなくてはならないのだ。
17. 16 品質ナラティブとの出会い - テストナラティブとは 品質向上につながる正しいテスト技法は どれか・どのツールを使うべきかが考えられ、語られている LEADING QUALITY｜Ronald Cummings-John, Owais Peer. LEADING QUALITY. 河原田政典(訳). Kadokawa, 2023 最高のテストナラティブは、次の2つのことに焦点を当てている。 まず、テストに関するさまざまなオプションや実現方法を明確に理解することだ。 これがわかれば、各オプションの利点や限界、および、プロダクトに関するどんな情報が得られるかを評価できる。 これにより、より良い戦略的な意思決定が下せる。そして、チーム・プロダクト・組織の成熟度を明確に理解しよう。 状況を把握することで選択肢が現在の開発段階に適しているかを確認できる。
18. 17 品質ナラティブとの出会い - 価値ナラティブとは 品質に投資した場合の 見返り（ROI: 投資収益率）が考えられ、語られている LEADING QUALITY｜Ronald Cummings-John, Owais Peer. LEADING QUALITY. 河原田政典(訳). Kadokawa, 2023 品質への投資がもたらす価値を議論する場合に重要なのは 3つの主要な分野である収益性・コスト削減・リスク軽減に焦点を当てることだ。
19. 18 私たちのチームの 品質ナラティブって？
20. 19 私たちのチームの品質ナラティブって？ - 私たちのチームの品質ナラティブを言語化してみる 私たちのチームの品質ナラティブを言語化してみる LEADING QUALITY｜Ronald Cummings-John, Owais Peer. LEADING QUALITY. 河原田政典(訳). Kadokawa, 2023 名前 理想度 理由 責任ナラティブ ★★★ • 自分たちで品質保証をするべきだとチーム全員が考えている • なにを作るべきなのか？からチーム全員で議論できている • QA不在を言い訳にせず品質をよくしていくぞという気持ちを持っていた テストナラティブ ★★☆ • 最低限のテストに関する知識は全員が持ち合わせていた • 体系的な知識が不足していて我流になっている部分もあった • 客観的に評価してどこが未熟かを判断できていない状態だった 価値ナラティブ ★☆☆ • ユニットテストはどんなテストを書くべきか？が活発に議論されていた • E2Eテストはユニットテストに比べると議論が少なかった • これらの議論をROIまで考慮して判断できていたかは怪しい • 意思決定の精度はまだ低いと感じていた
21. 20 具体的な取り組みの紹介
22. 21 ① タスクベースではなく チームにとって価値がある単位の スプリントゴールを置く
23. 22 具体的な取り組みの紹介 - タスクベースではなくチームにとって価値がある単位のスプリントゴールを置く タスクを分割したゴール＋フェーズに分けた進め方 実装フェーズ テストフェーズ スプリント １ ２ ３ ４ ゴールの例 ユーザー登録の バックエンドを 実装する ユーザー登録の フロントエンドを 実装する ユーザー登録の テストを実施する テストで見つけた 不具合を修正する 価値 0 0 0 100 フェーズ
24. 23 具体的な取り組みの紹介 - タスクベースではなくチームにとって価値がある単位のスプリントゴールを置く この進め方には以下のような問題が潜んでいた 思ったように動かなくて スプリントレビューが できなかった... レビューができなくても実装できたら ゴール達成としていいのか...？ もうすぐ完成なのに 仕様の考慮漏れが...
25. 24 具体的な取り組みの紹介 - タスクベースではなくチームにとって価値がある単位のスプリントゴールを置く スクラムの基本に立ち返って考えてみる スプリントごとに 価値を積み上げられて いるだろうか？ フィードバックサイクルを 早く回すためにはどうすると良い？ スプリントレビューが 動かないものを見せて意味ある？
26. 25 具体的な取り組みの紹介 - タスクベースではなくチームにとって価値がある単位のスプリントゴールを置く スプリントゴールに対する認識を再定義 タスクを完了するじゃなくて チームにとっての価値を 実現するのが良さそう 「何らかの価値がある成果物を作る」 を ゴール達成の最低条件としよう テストで不具合を発見した際の 修正コストも考慮して ゴールを決めないとですね
27. 26 具体的な取り組みの紹介 - タスクベースではなくチームにとって価値がある単位のスプリントゴールを置く フェーズを消し去り、価値が小さく積み上げられる状態に フェーズの概念は消え、スプリントごとに実装とテストと修正が行われる スプリント 1 ２ ３ ４ ゴールの例 ユーザー情報を フォームに入力できる 入力した情報をもとに ユーザーが登録される 入力値が不正な場合 エラーメッセージが 表示される ユーザー登録後は メールで通知される 価値 25 50 75 100 フェーズ
28. 27 具体的な取り組みの紹介 - タスクベースではなくチームにとって価値がある単位のスプリントゴールを置く チーム全体での意識変革と行動変容に繋がった 今までテストを最後に まとめてやってたけど こまめにやっていった方が楽だね スプリントレビューで何を見せたいか からゴールを考えてみるのも いいんじゃないかな テストして不具合が なければ、余った時間で 斧を研げますね
29. 28 ② テスト分析・設計を活用して 影響範囲の考慮漏れに立ち向かう
30. 29 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう テストは小さくできたが、考慮漏れが発生してしまう まさかそこも影響するとは... 見落としてしまいました 複雑になってきてますからね 自分も指摘できずに申し訳ない 自動テストやレビューなど やることはやってるつもりだけど どうしたら防げるのかな
31. 30 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう テスト分析・設計のプロセスが足りないという発見 ※ テストに関連する部分限定のPFD 要求定義 受入基準 作成 要件定義 レビュー前 受入基準 レビュー 承認済み 受入基準 　テスト実装 レビュー前 テストケース レビュー 承認済み テストケース 実装に進む
32. 31 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう テストケース「だけ」のレビューは難しい （なんかたくさんケースが あるけど、足りてるのかな？） （結構たいへんなんだよなあ） （このパターンがないのは 意図的か...？どっちだ...？）
33. 32 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう テスト分析を取り入れていく 今回はどんなテストをすると 価値があることを 確認できそうですかね？ マインドマップを使ってみたら こんなところにも影響がありますよ リスクやスコープ、目的など テスト設計に必要な情報を 言語化しておきましょう
34. 33 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう テスト設計を取り入れていく テスト分析の結果に沿って テストケースを考えてみますか 今回はデシジョンテーブルを使って パターンを整理してみます あ、そこは同値だから テストケースを削れますね
35. 34 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう そして最後にテスト実装 テスト設計までで パターンも整理されているし フォーマット整えて終わりですね テストの目的や意図から テストケースまでが繋がって 理解しやすいですね これならレビューコストも かなり低く抑えられそうです
36. 35 承認済み テスト設計結果 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう テスト分析・設計をチームに取り入れた新たなプロセス 要求定義 受入基準 作成 要件定義 レビュー前 受入基準 レビュー 承認済み 受入基準 　テスト実装 レビュー前 テストケース レビュー 承認済み テストケース 実装に進む ※ テストに関連する部分限定のPFD 　テスト分析 レビュー前 テスト分析結果 レビュー 承認済み テスト分析結果 　テスト設計 レビュー前 テスト設計結果 レビュー
37. 36 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう このプロセスを全員で一緒にやっていく 最初は大変かもしれないけど みんなでこのプロセスの練度を 高めていこう 特定の誰かだけができる状態は 自分たちの目指す姿じゃないよね 困ったらペアやモブの割合を 増やして助け合っていこう
38. 37 具体的な取り組みの紹介 - テスト分析・設計を活用して影響範囲の考慮漏れに立ち向かう 定性的ではあるが、想定以上の効果を得られた テスト分析・設計を通して 暗黙知的な内容をチームに 広げられていいですね テスト工程が細分化されて それぞれの目的がシャープになって やりやすくなりました コードを書くまでの時間は 伸びたかもしれないけど 手戻りは減ったよね
39. 38 ③ チームで大事にしたい 文化、価値観をDoDとして定義
40. 39 具体的な取り組みの紹介 - チームで大事にしたい文化、価値観をDoDとして定義 Definition of Done（完成の定義）とは スクラムガイド｜Scrum Guides 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。 … プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。 ましてやスプリントレビューで提⽰することもできない。 そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。 … 開発者は完成の定義に準拠する必要がある。
41. 40 具体的な取り組みの紹介 - チームで大事にしたい文化、価値観をDoDとして定義 新たなプロセスはそう簡単には浸透しない この修正内容なら テスト分析・設計は 不要だと思っていました あ、ごめんなさい！ シンプルに忘れてました！ テスト分析・設計を やる/やらないって どういう基準ですか？
42. 41 具体的な取り組みの紹介 - チームで大事にしたい文化、価値観をDoDとして定義 DoDを用いて価値観や文化の共通認識を揃える そもそもこういったプロセスに 改善した理由を振り返ってみよう お客さんに価値がある 高品質なプロダクトを届けたい 主体的にこういった活動が 行われている状態を 当たり前にしたいよね
43. 42 具体的な取り組みの紹介 - チームで大事にしたい文化、価値観をDoDとして定義 価値観や文化を醸成するための運用方針に DoDを満たしていることって いつ、誰が、どうやって 確認しますか？ 実装者とレビュワーに任せるのが 自分たちの目指す姿に 近いんじゃないかな 言われなくてもやれるように ならなければ本当の意味で 価値観は揃わないよね
44. 43 具体的な取り組みの紹介 - チームで大事にしたい文化、価値観をDoDとして定義 参考：実際のDoDと使用方法
45. 44 その後、わたしたちは
46. 45 ① 不安になってくる
47. 46 その後、わたしたちは - 不安になってくる やってみたけど、うまくやれているのか分からない ちゃんと改善の 効果出ているのかな プロセスはちゃんとやっているけど 作業の質としてはどうなんだろう テスト関連のコストが 増えすぎてないかな
48. 47 その後、わたしたちは - 不安になってくる コスト・価値・リスクを正しく評価して認識を揃える これまでは必要だけど やってなかっただけで 払うべきコストなんじゃない？ 後から多くのコストを払う可能性を 事前に潰せているとしたら 実は増えてないんじゃ？ 見合う価値はありそうだけどね 逆にコストをかけなかったときの リスクはどうだろう？
49. 48 その後、わたしたちは - 不安になってくる 不安をチームで共有し、少しずつ成長していく 正解は分からないけど 「自信を持ってリリースできる」 状態を目指してみませんか？ ペアやモブで雑談しながら進めたり QAに助けを求めて 一緒にやってみませんか 間違いなく効果は出ているから みんなで焦らずに 地道にスキルを磨いていこう
50. 49 ② そしてチームは新たなステージへ
51. 50 その後、わたしたちは - そして私たちは新たなステージへ FAST Agileへの移行で爆散したが品質保証を牽引している シフトレフトのメリットを もっとみんなに広めていこう 定量的に成果は測れなかったけど 確実に今後も活用できる 取り組みだったよね QAと協力しながら 開発組織の品質保証を リードしていこう FAST｜fastagile.io
52. 51 まとめ
53. 52 まとめ - 今回の取り組みのおさらい 今回の取り組みのおさらい 1. 品質ナラティブを使ってチームの置かれている状況を把握する 2. 価値ベースのスプリントゴールを置いて高品質な価値を積み上げていく 3. テスト分析設計を取り入れてテスト工程を細分化し、それぞれの精度を向上させる 4. DoDを活用してチームの文化や価値観を揃え、全員で品質改善に立ち向かう
54. 53 まとめ - 品質について学んでみての感想 品質について学んでみての感想 1. 品質ナラティブを使った整理は、数値偏重にもなりにくく効果が高いと感じた ❏ 同時にどんなチームになりたいのかという理想像についても議論ができる 2. 早い段階から小さく頻繁にテストする方が、品質も上がるしコストも低く抑えられる ❏ シフトレフトの効果と価値を身をもって体感することができた 3. コスト、価値、リスクを正しく評価することが大切 ❏ まずはリスクや価値に注目し、それに見合うコストはどれくらいだろう？という考え方をしていきたい
55. 54 まとめ - チームで進めていくために大事だったこと チームで進めていくために大事だったこと 1. 自分がファーストペンギンになることの大切さ ❏ WACATEに行ったり研修に出たりもした 2. 自分だけでやり切れない部分は積極的に人を頼る ❏ QAやスクラムマスター、チームメンバーの協力なくして不可能だった 3. ルールで縛りすぎずに、文化や価値観として醸成していく ❏ ルールを守ることが目的ではなく、ルールの意図や背景を守ることが目的
56. 55 明日からなにか一つでも 改善活動に取り組めそうですか？
57. 56 明日からなにか一つでも改善活動に取り組めそうですか？ - 「自分の考え」を伝えるところから始めよう 「自分の考え」を伝えるところから始めよう 最後になりましたが、みなさんが勇気を出して、一歩目を踏み出せることを陰ながら応援しています！ ホンダ流ワイガヤのすすめ｜朝日新聞出版 私も、品質保証に関する知識や経験を持ち合わせていない状態で、この取り組みを始めました。 きっかけは 「自分がチームに貢献して価値を出したい」 という強い想いでした。 新しい価値をつくりだすには「自分の考え」を大切にすることが必要です。それがすべての出発点になります。 自分が本気で「これが良い」と思っている考え・アイデア・想いのことです。 熱意が感じられる「自分の考え」（志と言い換えてもよいかもしれません）には、人々の心を動かす力があります。 この「自分の考え」という種をぶつけあうことで、あいまいだった種がだんだんと形を帯びてきます。