QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'

Transcript

1. 　 QA出⾝スリーアミーゴスでDeep Dive！ スクラムで品質とスピードを意識したOne Teamを構成するために 必要だったもの 2024.05.11
2. 　 2 経歴 新卒1年⽬は医療系システムの設計検証チームとして、 テスト設計〜テスト実⾏を担当。 2021年に「freeeカードUnlimited」カードのQAエンジ ニアとしてJoin。後述のoryoさんとともにカードプロダ クトの⽴ち上げ期を経験。 バックエンドQA⼿法や様々なチームに⼊りOne Teamで のアジャイルQAの⽴ち回りを実践し、定着させた。 2023年には決済プロダクトチームに移り、⽴ち上げ期の プロダクト2⼈⽬QAを経験。 同年9⽉からはスクラムマスターを兼任中。 田邉 澄春 / barus QAエンジニア / スクラムマスター Subaru Tanabe プロフィール画像の トリミング⽅法
3. 　 3
 QA歴5年目 → PdM（1年目）
 
 2018年にQAとしてのキャリアを歩み始める
 以降、金融プロダクトのQAとして、主にアンチマネーロン ダリングシステムの開発に携わる
 その後、2021年に現職であるfreee株式会社へ入社。自 社発行クレジットカードであるfreeeカードUnlimitedのQA を担当
 昨年、PdMへキャリアチェンジし、金融系新規サービスの 立ち上げ期からPdMを担当中
 長田 亮介 / oryo
 Product Manager（PdM）
 Osada Ryosuke
 Twitter : @oryo_126

4. 　 4 経歴 • オプティムに新卒⼊社 ◦ Android開発を経験した後、２年⽬から QAに転⾝ • freeeに中途⼊社 ◦ 同期マイクロサービスのQAを担当し、同 期ジョブのintegration testを導⼊ ◦ 現在は決済プロダクトのQAを担当し、 eng留学を経験した後、Agile QAに挑戦 中 好きな⾷べ物 • カレー 苅⽥蓮(ren) QAエンジニア Ren Karita JaSST Tokyo実⾏委員 プロフィール画像の トリミング⽅法
5. 5 前提の認識合わせ： 私たちのチームで アジャイルQA採⽤に⾄る背景 1
6. 　 6 背景：なぜアジャイルQAを採⽤したか Fintech分野は競合がひしめき合う魔境。。。互いに如何に早く他社よりも質の⾼い機能を提供して顧客 を獲得できるかを⽇々意識せざるを得ない。 ⼀⽅、⾦融の世界はソフトウェアのバグが⾦銭的損失に直結するため、確実な品質保証が求められる領域 でもある。 →品質とスピードの両⽴を追及しなければならない 提供スピード 品質価値
7. 　 7 背景：なぜアジャイルQAを採⽤したか② ※ymty(yumotsuyo)「freeeのQAの⽬指す姿-1/3」freee developers Hub (https://developers.freee.co.jp/entry/freee-qa-to-be-1) ymtyさんの「freeeの⽬指すべきQAの姿」記事において、TraditionalなQA (WFな下流⼯程としてのテスト、ビックバンテ スト化、フェーズゲート的QA)の問題点を指摘、アジャイルQAへのシフトを⽬指した。
8. 　 8 ※ymty(yumotsuyo)「freeeのQAの⽬指す姿-2/3」freee developers Hub (https://developers.freee.co.jp/entry/freee-qa-to-be-2) 当時の
9. 　 9 背景：なぜアジャイルQAを採⽤したか③ ※ymty(yumotsuyo)「【連載 第8回】QAがfreeeカードUnlimitedのスクラムチームメンバーとして取 り組んでること」freee developers Hub  (https://developers.freee.co.jp/entry/2021/10/28/100000) freeeカードUnlimitedのプロダクト⽴ち上げに際し、EMの⽅と会話があり、アジャイルQAを採⽤しようという話に。 →アジャイルQAの成果が出て、決済プロダクトの⽴ち上げにおいてもアジャイルQAを採⽤。
10. 　 10 決済プロダクト及びfreeeカードUnlimitedチームでは株式会社Red Journeyさんのアジャイルコーチの元、スクラムガイド (2020年版)をベースに解釈しつつ、最⼩限の不確実性に切り分けやすくするための開発⼿法として「仮説検証型アジャイル 開発」を取り⼊れている。 = ⾦融プロダクトという、実装が複雑になりがち、かつ求められるものの変化も早く、品質の⾼さも重要とされる、ニーズ やリスクの早期発⾒が求められる領域のため。 開発スタイルについて 仮説検証型アジャイル開発の図 引⽤：正しいものを正しくつくるための「仮説検 証型アジャイル開発」とは？ 市⾕聡啓⽒が語る POの戦略 (https://productzine.jp/article/detail/5)
11. 　 11 Q.現状の開発スタイルは？ A. 図に表すとこんな感じ。 体制 PdM eng QA PD 1⼈ 複数⼈ 1⼈or 少数 1⼈ 互いのロールの知識を少しずつ内包している状態 この中の誰かがSM、POを 兼任する状態 ✅ 開発着⼿〜スプリント 中盤にはテストを開始 できるくらい SEQ/QA チーム ⾃動化の インフラ整備 チーム横断の 分析、改善 ⾃動化のサポート、 プロセス標準の周知 PoC協⼒、 プロセス順守 Biz/Ops チーム 顧客コミュニ ケーションや サービス運⽤ 経営戦略の検 討など スプリントレ ビュー、 リスク洗い出し 会の開催 統合プロダクト 全体の戦略、 商談情報の提供 他プロダクトチーム 互いの影響範囲のレビュー、 リスク洗い出し会の参加
12. 　 12 今⽇の主題はここの話！！！ 品質とスピードに向き合うOne Teamな体制を作っていくために、各ロールは品質に対してどのように向き合ったのか、 結果、チームではどのような取り組みを⾏ったのかを語っていきます！
13. 13 各ロールの視点で⾒る、 品質とスピードを両⽴した OneTeamを構成するために 意識していること 2
14. 　 14 品質とスピードを両⽴したOneTeamを構成するために必要な こと‧意識していることって何？ 〜PdM(PO)編〜 ＊“価値の提供スピード”と“品質価値”のバランス‧相関性を                  “開発チームの全員”で意識する
15. 　 15 マーケット環境（market environment） 機能価値（function value） 顧客理解（customer understanding） ユーザビリティ（usability） 品質価値（Quality Value） Product 開発コスト（development cost） 提供スピード（speed） スケーラビリティ（Scalability） 事業性（feasibility of the business） プロダクトマネジメント要素
16. 　 16 マーケット環境（market environment） 機能価値（function value） 顧客理解（customer understanding） ユーザビリティ（usability） 品質価値（Quality Value） Product 開発コスト（development cost） 提供スピード（speed） スケーラビリティ（Scalability） 事業性（feasibility of the business） QA出⾝PMとしての意識しているプロダクトマネジメント要素
17. 　 17 品質価値の定義 品質価値とは、  利便性‧可⽤性‧正確性‧安全性といった品質特性が  ⾼⽔準であることによって提供することのできる  プロダクト体験（PX）に付随する価値 と定義します。
18. 　 18 品質価値の計測‧評価   利便性‧可⽤性 正確性‧安全性 品質価値 機能価値 機能価値 KPI ex)       利⽤継続率（CRR） 離脱率（churn rate） 顧客⽣涯価値（LTV） 年間経常利益（ARR） 売上維持率（NRR） 顧客満⾜度（CSAT）        品質価値 KPI ex)     重篤度別⽋陥件数       ⽋陥密度（defect density）       ⽋陥除去率（Defect Removal Efficiency） 経済性‧顧客ニーズ適合性 重篤度とは、ユーザーが利⽤している時に発⽣するとどれだけ良くないことになるかの度合いのこと 引⽤：【連載 第8回】QAがfreeeカードUnlimitedのスクラムチームメンバーとして取り組んでること
19. 　 19 品質価値と提供スピードのバランス関係 早く価値を デリバリー した い！！！ ちょっと 満⾜度が犠 牲に。。。 提供スピード 品質価値 競合優位性を獲得 したい 継続利⽤率を維持 したい ARPUを向上させた い 利⽤継続率が低迷 する 新規顧客獲得数が 上がりきらない レピュテーション リスクの懸念 5/15までに リリースしたい AとBとCとDは無理 だからCとDを削ら ないといけない
20. 　 20 満⾜度の ⾼い体験を 届けた い！！！ 価値の デリバリーが遅 くなっちゃう... 品質価値と提供スピードのバランス関係 提供スピード 品質価値 競合劣位の状態に マーケットトレン ド を逃す可能性 機会損失 継続利⽤率の向上 新規顧客獲得数の 向上 レピュテーション リスクの低減 6/15にリリースが 遅延してしまう AとBとCとD全て 含めてリリースを 実施する
21. 　 21 この⽔準の 体験を提供 できれば OK！ この時期ま でに出せれ ばOK！ 品質価値と提供スピードのバランス関係 提供スピード 品質価値 5/31にリリース出 来れば、事業的側 ⾯でもOK AとBとCとDは無理 だが、AとBとDだけ なら5/31までに間に 合いそう
22. 　 22 品質価値と提供スピードの相関性 提供スピード（speed） 品質価値（Quality Value） 過剰品質 ⾮理想的 スピード先⾏ 理想的
23. 　 23 新規事業のMVP開発時の組織戦略 提供スピード（speed） 品質価値（Quality Value） 過剰品質 ⾮理想的 スピード先⾏ 理想的 重篤な障害を発⽣させる蓋然性の⾼い⽋陥を含むような品質状態 新規事業は早く仮説検証（PoC）が出来る ことが望ましいためスピード先⾏型になり がち。 MVPでは、死守すべき品質価値ラインを チームで合意形成し、そのラインより上に 存在する品質価値を毀損する可能性のある 事象は、許容判断として進めている。
24. 　 24 提供スピード（speed） 品質価値（Quality Value） 過剰品質 ⾮理想的 スピード先⾏ 理想的 クリティカルな障害を発⽣させる蓋然性の⾼い⽋陥を含むような品質状態 価値提供のスピードを維持したま ま、品質価値の向上を図ることは あまり現実的とは⾔えない 品質価値の向上に注⼒し過ぎて、 結果的に価値提供のスピードが犠 牲になってしまうということも望 ましくない 品質とスピードの両⽴に向けたアンチパターン テストを 増やす ⼈を 増やす 実際はこんな⾵には 進まない...
25. 　 25 提供スピード（speed） 品質価値（Quality Value） 過剰品質 ⾮理想的 スピード先⾏ 理想的 クリティカルな障害を発⽣させる蓋然性の⾼い⽋陥を含むような品質状態 ⼀時的に価値提供のスピードを落とし て、エミュレーターの実装やテスト⾃動 化を優先的に乗せるスプリントを意図的 に設けることで、スピードと品質価値を 両⽴出来る組織体制への移⾏を試みた 品質とスピードを両⽴可能な組織への導き⽅
26. 　 26 総括 ＊“価値の提供スピード”と“品質価値”のバランスを                  “開発チームの全員”で意識する 準備として、 - 品質価値の計測‧評価基準（KPI）の認識を合わせる - 品質価値とスピードのトレードオフ関係についての認識を合わせる（バランス） - スピードを⼤切にする上で、最低限死守しなければいけない品質価値基準についての認識を 合わせる（相関性） 実践として、 - 品質価値とスピードのバランスを意識したプロダクトマネジメントを⼼がけている（バランス） - 品質価値とスピードの両⽴について継続的に全員で対策を考え、チャレンジしている（相関性）
27. 　 27 ＊チーム全員で機能横断⼒を⾼め、品質‧スピード両⽅の向上に 繋がる取り組み‧カイゼン創出の確率を上げること → なぜ越境することが必要なのかについての話！ 品質とスピードを両⽴したOneTeamを構成するために必要なこ と‧意識していることって何？ 〜SM編〜
28. 　 28 スクラムガイドでは品質という⾔葉は出てくるものの、品質が何であるかは出てこないのはもちろん、スピードという⾔葉は 出てこない。よって、それぞれのスクラムチームで解釈すべきものと考えられる。 しかし、スクラムガイド中の「プロダクト」と「価値」という⾔葉に着⽬してみると、「品質」と「スピード」の⽴ち位置が ⾒えてくる。 その前に...スクラムマスター(私)から⾒た品質とスピードの捉え⽅ ※スクラムガイド(2020年版)「確約（コミットメント）：プロダクトゴール」 (https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japa nese.pdf) 「プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、 既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。 プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある」 スクラムガイド先⽣
29. 　 29 品質 =「プロダクトがターゲットとするユーザー‧ステークホルダーに対して、適切な価値を提供してい ること」 スピード ＝ 「ユーザー‧ステークホルダーに適切な価値を提供するまでのデリバリータイム 」 と解釈！ 品質とスピードを両⽴する...とは 「ユーザーやステークホルダーにとって適切なプロダクトの価値(機能や体験)を爆 速で提供する」こと！ スクラムマスター(私)から⾒た品質とスピードの捉え⽅ こういう機能欲しいんだけど この時はこういう⾵に使えると嬉しい できました！ 恐ろしく早いリリース...俺でなきゃ(ry しかも欲しかったものより便利だ...！
30. 　 30 ユーザーやステークホルダーにとって適切なプロダクトの価値(機能や体験)を爆速で提供したい！が... 現実には⼀発で様々なユーザー‧ステークホルダーにとっての魅⼒的な価値で提供するのは難しく、かつ価値の形はすぐに 変容してしまう。 なので... 品質 ‧プロダクトをリリースしてみて、ニーズから逸れたか、⽋陥が⼊ってしまったかを検査‧適応する …△ ‧検査‧適応を繰り返すことで、よりニーズから逸れた機能や意図せぬ⽋陥をできるだけ作り込まな くなる状態を⽬指す！ 💯 スピード ‧検査‧適応を繰り返し、指摘されたら改修する …△ ‧検査‧適応を繰り返すことで、魅⼒的な価値を提供するための試⾏回数やリードタイムを 短くできる状態を⽬指す！ 💯 どうやって品質とスピードを⾼める？
31. 　 31 ここに、「役割に閉じた専⾨知識だけを持ったメンバーが集まり、与えられた役割の範囲で仕事をこなす」 実質コンポーネント型のスクラムチームが... 品質とスピードの両⽴に⽴ちはだかる課題 フロ ント エン ド バッ クエ ンド A 機能 バッ クエ ンド B 機能 業界 ドメ イン 知識 UI テス ト ユー ザー ドメ イン FEeng BEeng BEeng PdM QA Sales Biz プロ ダク ト 戦略 PD UI ‧ UX 専⾨性 の深さ 専⾨性の広さ
32. 　 32 実質コンポーネント型のチームではこんなことが起こりがち... 品質とスピードの両⽴に⽴ちはだかる課題①  A機能の画⾯完成しました！ ユーザーさん、こういう使い⽅をしていて... (PdMさんには伝えたんだけどな...) あっ...でも今から改修するとリリース予定に間に合わない... PdM(リリースオーナー)的にどうしますか？ ⼀旦リリース or リリース伸ばして対応？ (PdM)さん最近忙しいし、細かい挙動どうしようかな... でもユーザー的にどうなのかもわからんし... せや！MVPで作って後で改修すればええんや！ ~~~~~~~⽉⽇は流れ、リリース予定直前のスプリントレビューにて~~~~~~~~ FEeng eng’s CS PdM 今回は許容するのでリリースしましょう。 (エンジニアなんだしこうすべきって 普通わかるやろ...) ミスコミュニケーション による、 ニーズから逸れた機能、 ⽋陥の作り込み
33. 　 33 実質コンポーネント型のチームではこんなことが起こりがち... 品質とスピードの両⽴に⽴ちはだかる課題② UX的にこういう機能の⽅がイケてると思うので、このようなUIデザイン にしてみました。 レビュー指摘お願いします！ 実際にプロダクト チームが実装始めて みないと分からん XXプロダクトチーム じゃ無いから レビューのしようが なぁ 他の⼈は特に指摘して ないし、問題なさそう ヨシ！ ‧‧‧。 問題なければこれで進めます！ ~~~~~~~⽉⽇は流れ、eng設計中~~~~~~~~ このUIで表⽰する箇所、外部サービスの制約上無理そうです。 分かりました。UIデザイン練り直します。。。 ⼿戻りや追加開発 による遅延 PD BEeng PD チーム 触ったことない 機能だしなぁ
34. 　 34 実質コンポーネント型のチームではこんなことが起こりがち... 品質とスピードの両⽴に⽴ちはだかる課題③ ~~~~~~~さらに⽉⽇は流れ、経営戦略会議にて~~~~~~~~ ⽊こりの ジレンマ状態 ロードマップに書いてある機能、なぁい！！！！！ 競合他社に追いつくために、ますます機能開発にリソースを割いてください！ はい...。 (今の体制を改善しないと負のスパイラルなのは⾒えてる... でも原因分析に時間かかるし、忙しい。。。) ニーズから 逸れた機能、 ⽋陥の作り込み ⼿戻りや 追加開発 による遅延 が重なり... ~~~~~~~さらに⽉⽇は流れ、別機能の要求定義中にて~~~~~~~~ このプロダクト、 何か変... Biz PdM カイゼンして、でもむしろスピード上げて機能開発して eng’s はい、やります。。。 (時間なぁい！！！！！) 以下、ループ
35. 　 35 すなわち... ‧ミスコミュニケーションによるニーズから逸れた機能や⽋陥の作り込み ‧上記による⼿戻りや追加開発による遅延 ‧カイゼン‧実験を⾏わず、鈍⾜なプロセス‧体制を続けること(⽊こりのジレンマ状態) を防ぐ‧改善するために必要なこと‧意識していることは何か？ → 機能横断型OneTeamを⽬指し、役割の専⾨性を超えたコラボレー ションを促進させること！ 品質とスピードの両⽴に⽴ちはだかる課題を倒すために必要なこと‧ 意識していることって何？
36. 　 36 スクラムガイド「スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えてい る。また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する」 下記の記事「クロスファンクショナルチームは、会社のさまざまな機能分野の⼈々で構成されるグループです。」 「機能横断型」チームってなんだっけ ※ ”What is Cross-Functional Team in Agile?”  (https://www.visual-paradigm.com/scrum/what-is-cross-functional-team-in-agile/)
37. 　 37 T字型プロフェッショナル...役割の専⾨性を超えるための考え⽅ ※ ”What is Cross-Functional Team in Agile?”  (https://www.visual-paradigm.com/scrum/what-is-cross-functional-team-in-agile/) T字型プロフェッショナル(T-shaped Skills)...1 つの専⾨分野に深みがあり、他の分野にも幅があるという状態。 これをチーム全員が⽬指していければ、より他分野の視点を絡めた観点でフィードバックできる確率が⾼まる。 →機能横断型One Teamを構成していくために有⽤な考え⽅！
38. 　 38 スクラムガイドでは以下のように記載されている。 ‧集中...スクラムの価値基準の5つのうちの⼀つ。 「スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する」 ‧透明性... 経験主義のスクラムの三本柱の⼀つ。 「創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。 ~(中略)~ 透明性の低い作 成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある」 集中‧透明性を⾼めることに着⽬し、役割の専⾨性を超えたコラボ レーションしやすさ(機能横断⼒)を促進する
39. 　 39 以下のように解釈している！ ‧集中...フロー効率に⽐重をおくことにより、認識を合わせやすくし、属⼈化を防ぐ。さらに、後からキャッチアップする ことになる時間を減らし、より互いにフィードバックしやすい状態にする。 →後からキャッチアップすることやマルチタスクによる余分な認知負荷を低減させ、 他の情報を取得できる「余⼒」を作るため。 ‧透明性... ⽬線が合っているかどうかの視認性はもちろん、困った時の相談のしやすさ(⼼理的安全性)や詰まっていないか の検査、さらにはあえ共(あえて共有)といった、その⼈の考え⽅や共有知の⾒える化を促進する。 →他の⼈の考え⽅や知識に触れる機会を増やし、その知識‧考え⽅を使ったコミュニケーションが出やす くなるため。 なぜ機能横断⼒を促進することに繋がる？
40. 　 40 スクラムや他ロールで扱う技術(フロントエンドやバックエンド、QA技術など)、業界ドメインを題材にチーム全員参加で開 催。 テーマにしたい箇所を選んで、「なぜそう書かれているのか」「背景となる根拠は何か」「⾃分たちのチームはどうか」を出 して議論し、チームで認識を揃えたり、勉強会後にアクションすべきと思ったものは、Tryとして実践していくネタに。 ちなみに決済プロダクトチームでは週2で1時間、時間を取っている。 具体的なアクション その1 「Learning Session → Try化」
41. 　 41 スクラムマスターとしてチーム全員と1on1を⾏い、直近の困りごとや、雑相(雑談ベースのカジュアルな相談)、カイゼンアイ デアなどを話す。 ただ話すだけでなく、出たアイデアで良いものはチームのSlackにあえ共*の精神で投稿。その次の⽇のデイリーやプランニ ングでのTryとして扱い、チームで認識を合わせてアクションに起こす。 ちなみに決済プロダクトでは⽉1でやっている。 具体的なアクション その2 「1on1 あえ共 → Try化」 *あえ共...freeeの⾏動指針の⼀つ：あえて、共有する (https://note.com/ari_freee/n/n2ba0f06cba12)
42. 　 42 チーム全員が機能横断⼒を⾼め、役割の専⾨性を超えたコラボレーションを当たり前のように⾏えるようになった 理想的なチームでのメンバーの状態 例/ 機能横断型OneTeamがもたらすインパクト フロ ント エン ド 業界 ドメ イン 知識 UI テス ト ユー ザー ドメ イン FEeng プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 完全なT字ではなく、少し ずつ他の領域の深い部分も 出てくる！ フロ ント エン ド 業界 ドメ イン 知識 UI テス ト ユー ザー ドメ イン QA プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 機能横断⼒を⾼めることに より、複合的な領域や 新たな領域を開拓できる！ API テス ト BE テス ト フロ ント エン ド 業界 ドメ イン 知識 ユー ザー ドメ イン プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 テ スト フロ ント エン ド 業界 ドメ イン 知識 ユー ザー ドメ イン プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 テ スト チーム チームの複数⼈、 理想的には全員が 他の領域を深く カバーできる状態！
43. 　 43 より早期に、より⾊々な視点を知ることにより、課題‧不具合‧考慮漏れの発⾒やプロセス 改善、魅⼒的な価値を提供できるアイデア創出に繋がる「確率」を上げる！ 例/ 機能横断型OneTeamがもたらすインパクト ユーザーさんはこういう使い⽅をしていて... ってPdM、CSの⽅が⾔ってたけど、このタイプのユーザーをターゲットに するなら、こういう使い⽅をしたいはずだよな... はじめから考慮に⼊れて設計しておこう！ 機能横断⼒を⾼めた FEeng 機能横断⼒を⾼めた PD 今はこういう意図で実装して、過去にこういう制約があって... 現状このレイアウトだと該当する機能がないから、開発⼯数伸びちゃい そうです...？ こんなレイアウトの案も考えてみたので、こっちなら実装的にも軽く済 みそうだし、ユーザー体験も悪くなさそうです！ 機能横断⼒を⾼めた BEeng 今はこれ改修されてるので、この実装シュッとしていただけそうです！ ってQAの⽅から教わった箇所を確認してみたので、元の案でもそんなに 実装⼯数は掛からなそうです！
44. 　 44 つまり... 機能横断型OneTeam で、役割の専⾨性を超えたコラボレーションを促進させることで、 品質‧スピード両⽅の向上に繋がる取り組み‧カイゼン創出の確率を上げる！ 総括 フロ ント エン ド 業界 ドメ イン 知識 ユー ザー ドメ イン プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 テ スト フロ ント エン ド 業界 ドメ イン 知識 ユー ザー ドメ イン プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 テ スト よりニーズから逸れた機能や意図せぬ⽋陥を作り込まなくなり、魅⼒的な 価値を提供するための試⾏回数やリードタイムも短くなっていく！ ユーザーやステークホルダーにとって適切なプロダクトの価値(機能や体験)を 爆速で提供できるように！
45. 　 45 品質とスピードを両⽴したOneTeamを構成するために必要な こと‧意識していることって何？ 〜Eng編〜 ＊whyを理解し、重要な仕様検討をチーム全体で⾏うこと   (他ロールの視点を積極的に求めること) ＊認知負荷が⾼まりすぎないように、   チームで進める開発の並列数を検査し続ける
46. 　 46 why(なぜ作るのか)を理解しないと、what(何を作るのか)を正しく理解できない whyを理解し、重要な仕様検討をチーム全体で⾏うこと(他ロールの視点を積極 的に求めること)
47. 　 47 why(なぜ作るのか)を理解しないと、what(何を作るのか)を正しく理解できない whyを理解したいという意識が、PRD(プロダクト要求仕様書)やユーザーストーリー、ユーザーの業務を深く理解するため の⾏動に繋がる whyを理解し、重要な仕様検討をチーム全体で⾏うこと(他ロールの視点を積極 的に求めること) PRD説明会への参加 業務観察 コア機能が何か 共通理解の形成
48. 　 48 プロダクトのコア機能(※)は、チーム全員が⾼い⽔準で理解している状態を⽬指す ※コア機能は、ユーザーに提供したい価値において最重要な機能 その上で、精度の⾼い仕様検討を達成するために、開発上⽣じる重要な仕様検討はチーム全体で⾏う →チーム全体で⾏うことで、「チーム全員が同じ⽔準でコア機能を理解している状態」も達成できるpositiveなスパイラル が⽣まれる whyを理解し、重要な仕様検討をチーム全体で⾏うこと(他ロールの視点を積極 的に求めること) 重要な仕様検討を チーム全体で⾏う チーム全員が⾼い⽔準で コア機能を理解する コア機能に 対する ⾼い解像度 精度の⾼い 仕様検討
49. 　 49 プロダクトのコア機能(※)は、チーム全員が⾼い⽔準で理解している状態を⽬指す ※コア機能は、ユーザーに提供したい価値における最重要な機能 その上で、精度の⾼い仕様検討を達成するために、開発上⽣じる重要な仕様検討はチーム全体で⾏う →チーム全体で⾏うことで、「チーム全員が同じ⽔準で理解している状態」も達成できるpositiveなスパイラルが⽣まれる ⼀⽅で、動かしてみないと⾒えにくい部分があるなら、まず動くところまでをゴールにし、いかに提供価値の議論をスピー ディに⾏えるかを⽬指している 重要な仕様検討をどのように達成するか。仕様の複雑さや状況を踏まえて、適切にアプローチすることを意識している whyを理解し、重要な仕様検討をチーム全体で⾏うこと(他ロールの視点を積極 的に求めること)
50. 　 50 • 認知負荷が⾼まると、設計実装の精度やレビューの質が落ちやすくなり、サイクルタイムも⻑くなる • サイクルタイムが⻑くなると、それだけ価値検証をするのが遅くなる • チームが重要な仕様検討に集中し早くから価値検証を⾏うために、同時に着⼿するフィーチャーの数を3つ以上にしな いように、また開発タスクを滞留させないことを意識している Cycle time zooms in on the “active work" phase of the Kanban system, measuring the time between when a team member starts a task and when they complete it. (サイクルタイムは、カンバンシステムの「アクティブな作業」フェーズに焦点を当て、チームメンバーがタスクを開始してから完了するまでの時 間を測定します。) 4 Kanban Metrics You Should Be Using in 2024 | Atlassian (https://www.atlassian.com/agile/project-management/kanban-metrics) 認知負荷が⾼まりすぎないように、チームで進める開発の並列数を検査し続け る
51. 　 51 品質とスピードを両⽴したOneTeamを構成するために必要な こと‧意識していることって何？ 〜QA編〜 ＊チームやプロダクトのコンテキストにあったQA活動を⾏うこと ＊チームメンバーと同じメンタルモデルを持つこと
52. 　 52 • 品質とスピードどちらも達成するために、チームの状態やプロダクトのコンテキストに合わせてQA活動を⽬指して いる • 私たちのプロダクトは新規性の⾼いプロダクトであり、現在は、AQUAフレームワークにおけるAccelerating project の実践を意識している チームやプロダクトのコンテキストにあったQA活動を⾏うこと イマドキのソフトウェアのテストやQAの考え⽅ (https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation)
53. 　 53 チームやプロダクトのコンテキストにあったQA活動を⾏うこと • 品質とスピードどちらも達成するために、チームの状態やプロダクトのコンテキストに合わせてQA活動を⽬指してい る • 私たちのプロダクトは新規性の⾼いプロダクトであり、現在は、AQUAフレームワークにおけるAccelerating project の実践を意識している - AQUAフレームワーク - Accelerating project - とにかく速く何度もリリースを⾏って市場で存在感を⽰したり、市場で学ぶべき時期に⾏う品質保証活動 - Qualifying value - プロダクトのポジションやミッションが分かってきた段階で、製品の価値を最⼤化するQA活動 - Unveiling weakness - 多くのユーザを獲得し、市場で存在感を確⽴した時期に⾏うQA活動 - Accumulating knowledge - 次世代、発展型、ファミル的なプロダクトの開発を検討すべき∕始めている時期に⾏うQA活動 イマドキのソフトウェアのテストやQAの考え⽅ (https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation)
54. 　 54 チームやプロダクトのコンテキストにあったQA活動を⾏うこと • とにかく速く何度もリリースを⾏う ◦ →どの順序でテストを⾏えばリードタイムを短くできるかを考え、開発エンジニアと調整する • 主要な価値 ◦ →コア機能が何かを理解する。重篤度で認識を合わせる • UX ◦ → 動かしてみた感想をいち早くチームに共有する。そのために、実装成果物を最速でテストすることを⽬指す - Accelerating project - コンテキストとフォーカス - とにかく速く何度もリリースを⾏って市場で存在感を⽰したり、市場で学ぶべき時期に⾏う品質保証活動 - >> プロダクトサイズは⼩さく、信頼性や安全性はそれほど要求されない時期 - 主要な価値やUXが損なわれないことと、開発スピードが上がること、成⻑できるチームになっていること、などに品質保証 をフォーカスさせる イマドキのソフトウェアのテストやQAの考え⽅ (https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation)
55. 　 55 開発エンジニアの「作りやすい順序」とQAエンジニアの「テストしやすい順序」は異なることがある 「最速で価値を届け切りたい」という同じ⽬的を達成するために、リファインメントやスプリントプランニングの度に話し合 う機会を設けている チームやプロダクトのコンテキストにあったQA活動を⾏うこと 取り組みの紹介 1. 開発順序にQAの意⾒も取り⼊れる チームで話している様⼦
56. 　 56 • 重篤度とは、freee社内で定義している「事象のヤバさ」を表現する指標 ◦ 4段階の指標であり、重篤度が⾼い順にcritical, major, normal, minorとしている • Eng, QA, PdM, PD全員で、プロダクトの重篤度を定義している チームやプロダクトのコンテキストにあったQA活動を⾏うこと 取り組みの紹介 2. 重篤度の定義
57. 　 57 • バックエンドに焦点を当てたテスト活動 • QA Readyになった実装成果物をすぐにテストし、criticalなバグを早くから検出することを⽬指している チームやプロダクトのコンテキストにあったQA活動を⾏うこと ※「決済プロダクトのマジ価値を最速で届けるためのバックエンドQAの事例」 (https://developers.freee.co.jp/entry/freee-qa-advent-calendar-day11) 取り組みの紹介 3. バックエンドQA
58. 　 58 チャーターベースのテスト • テストチャーターとはテストケースより粒度の⼤きいテスト設計の成果物 • 軽量だが勘所を押さえるテスト活動を実現している チームやプロダクトのコンテキストにあったQA活動を⾏うこと 取り組みの紹介 4. チャーターベースのテスト <ミッション> 何のためのテストか？ <テストチャーター> 【確認箇所】 テスト対象の画⾯などを書く 【期待結果】 テストしたい箇所/事柄を書く 【P-V (事前条件と⼊⼒)】 テストの事前条件や⼊⼒についての因⼦/⽔準を書く <テストチャーターのポイント> テストチャーターの補⾜として書いておきたいこと、難しい⼿順などがあれば書く
59. 　 59 視点は様々、切り⼝も様々で良い。けど、私たちがプロダクトをどう理解しているのかのメンタルモデルは、擦り 合わせていく。 メンタルモデルとは、個々⼈が頭の中に持つ「これはこういうものだ」という概念 プロダクト開発においては、ユーザーのバーニングニーズが何であるか メンタルモデルは議論の前提であり、メンタルモデルが揃わないとそもそも議論を⾏えない チームメンバーと同じメンタルモデルを持つこと
60. 　 60 各ロールの視点で⾒る、品質とスピードを両⽴したOneTeamを構成するために意識していること まとめ 役割 回答 PdM ・価値の提供スピードと品質価値”のバランス・相関性を開発チームの全員”で意識する SM ・チーム全員で機能横断力を高め、品質・スピード両方の向上に 繋がる取り組み・カイゼン創出の確率を上げること Eng ・whyを理解し、重要な仕様検討をチーム全体で行うこと(他ロールの視点を積極的に求めること) ・認知負荷が高まりすぎないように、チームで進める開発の並列数を検査し続ける QA ・チームやプロダクトのコンテキストにあったQA活動を行うこと ・チームメンバーと同じメンタルモデルを持つこと
61. 61 さいごに 3
62. 　 62 freeeでは「スモールビジネスを、世界の主役に。」をミッションに掲げ、「アイデアやパッション やスキルがあればだれでも、ビジネスを強くスマートに育てられるプラットフォーム」の実現を⽬ 指してサービスの開発および提供をしています。 QAチームでは、社会の進化を担う責任感をもって品質にコミットし、⾃律的に⾏動できる仲間を募 集しています。 さいごに QAエンジニア QAマネージャー