Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

ropQa
May 21, 2024

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

ropQa

May 21, 2024
Tweet

More Decks by ropQa

Other Decks in Technology

Transcript

  1.   2 経歴 新卒1年⽬は医療系システムの設計検証チームとして、 テスト設計〜テスト実⾏を担当。 2021年に「freeeカードUnlimited」カードのQAエンジ ニアとしてJoin。後述のoryoさんとともにカードプロダ クトの⽴ち上げ期を経験。 バックエンドQA⼿法や様々なチームに⼊りOne Teamで

    のアジャイルQAの⽴ち回りを実践し、定着させた。 2023年には決済プロダクトチームに移り、⽴ち上げ期の プロダクト2⼈⽬QAを経験。 同年9⽉からはスクラムマスターを兼任中。 田邉 澄春 / barus QAエンジニア / スクラムマスター Subaru Tanabe プロフィール画像の トリミング⽅法
  2.   3
 QA歴5年目 → PdM(1年目)
 
 2018年にQAとしてのキャリアを歩み始める
 以降、金融プロダクトのQAとして、主にアンチマネーロン ダリングシステムの開発に携わる
 その後、2021年に現職であるfreee株式会社へ入社。自

    社発行クレジットカードであるfreeeカードUnlimitedのQA を担当
 昨年、PdMへキャリアチェンジし、金融系新規サービスの 立ち上げ期からPdMを担当中
 長田 亮介 / oryo
 Product Manager(PdM)
 Osada Ryosuke
 Twitter : @oryo_126

  3.   4 経歴 • オプティムに新卒⼊社 ◦ Android開発を経験した後、2年⽬から QAに転⾝ • freeeに中途⼊社

    ◦ 同期マイクロサービスのQAを担当し、同 期ジョブのintegration testを導⼊ ◦ 現在は決済プロダクトのQAを担当し、 eng留学を経験した後、Agile QAに挑戦 中 好きな⾷べ物 • カレー 苅⽥蓮(ren) QAエンジニア Ren Karita JaSST Tokyo実⾏委員 プロフィール画像の トリミング⽅法
  4.   11 Q.現状の開発スタイルは? A. 図に表すとこんな感じ。 体制 PdM eng QA PD

    1⼈ 複数⼈ 1⼈or 少数 1⼈ 互いのロールの知識を少しずつ内包している状態 この中の誰かがSM、POを 兼任する状態 ✅ 開発着⼿〜スプリント 中盤にはテストを開始 できるくらい SEQ/QA チーム ⾃動化の インフラ整備 チーム横断の 分析、改善 ⾃動化のサポート、 プロセス標準の周知 PoC協⼒、 プロセス順守 Biz/Ops チーム 顧客コミュニ ケーションや サービス運⽤ 経営戦略の検 討など スプリントレ ビュー、 リスク洗い出し 会の開催 統合プロダクト 全体の戦略、 商談情報の提供 他プロダクトチーム 互いの影響範囲のレビュー、 リスク洗い出し会の参加
  5.   15 マーケット環境(market environment) 機能価値(function value) 顧客理解(customer understanding) ユーザビリティ(usability) 品質価値(Quality

    Value) Product 開発コスト(development cost) 提供スピード(speed) スケーラビリティ(Scalability) 事業性(feasibility of the business) プロダクトマネジメント要素
  6.   16 マーケット環境(market environment) 機能価値(function value) 顧客理解(customer understanding) ユーザビリティ(usability) 品質価値(Quality

    Value) Product 開発コスト(development cost) 提供スピード(speed) スケーラビリティ(Scalability) 事業性(feasibility of the business) QA出⾝PMとしての意識しているプロダクトマネジメント要素
  7.   18 品質価値の計測‧評価   利便性‧可⽤性 正確性‧安全性 品質価値 機能価値 機能価値 KPI ex)       利⽤継続率(CRR)

    離脱率(churn rate) 顧客⽣涯価値(LTV) 年間経常利益(ARR) 売上維持率(NRR) 顧客満⾜度(CSAT)        品質価値 KPI ex)     重篤度別⽋陥件数       ⽋陥密度(defect density)       ⽋陥除去率(Defect Removal Efficiency) 経済性‧顧客ニーズ適合性 重篤度とは、ユーザーが利⽤している時に発⽣するとどれだけ良くないことになるかの度合いのこと 引⽤:【連載 第8回】QAがfreeeカードUnlimitedのスクラムチームメンバーとして取り組んでること
  8.   19 品質価値と提供スピードのバランス関係 早く価値を デリバリー した い!!! ちょっと 満⾜度が犠 牲に。。。

    提供スピード 品質価値 競合優位性を獲得 したい 継続利⽤率を維持 したい ARPUを向上させた い 利⽤継続率が低迷 する 新規顧客獲得数が 上がりきらない レピュテーション リスクの懸念 5/15までに リリースしたい AとBとCとDは無理 だからCとDを削ら ないといけない
  9.   20 満⾜度の ⾼い体験を 届けた い!!! 価値の デリバリーが遅 くなっちゃう... 品質価値と提供スピードのバランス関係

    提供スピード 品質価値 競合劣位の状態に マーケットトレン ド を逃す可能性 機会損失 継続利⽤率の向上 新規顧客獲得数の 向上 レピュテーション リスクの低減 6/15にリリースが 遅延してしまう AとBとCとD全て 含めてリリースを 実施する
  10.   21 この⽔準の 体験を提供 できれば OK! この時期ま でに出せれ ばOK! 品質価値と提供スピードのバランス関係

    提供スピード 品質価値 5/31にリリース出 来れば、事業的側 ⾯でもOK AとBとCとDは無理 だが、AとBとDだけ なら5/31までに間に 合いそう
  11.   23 新規事業のMVP開発時の組織戦略 提供スピード(speed) 品質価値(Quality Value) 過剰品質 ⾮理想的 スピード先⾏ 理想的

    重篤な障害を発⽣させる蓋然性の⾼い⽋陥を含むような品質状態 新規事業は早く仮説検証(PoC)が出来る ことが望ましいためスピード先⾏型になり がち。 MVPでは、死守すべき品質価値ラインを チームで合意形成し、そのラインより上に 存在する品質価値を毀損する可能性のある 事象は、許容判断として進めている。
  12.   24 提供スピード(speed) 品質価値(Quality Value) 過剰品質 ⾮理想的 スピード先⾏ 理想的 クリティカルな障害を発⽣させる蓋然性の⾼い⽋陥を含むような品質状態

    価値提供のスピードを維持したま ま、品質価値の向上を図ることは あまり現実的とは⾔えない 品質価値の向上に注⼒し過ぎて、 結果的に価値提供のスピードが犠 牲になってしまうということも望 ましくない 品質とスピードの両⽴に向けたアンチパターン テストを 増やす ⼈を 増やす 実際はこんな⾵には 進まない...
  13.   25 提供スピード(speed) 品質価値(Quality Value) 過剰品質 ⾮理想的 スピード先⾏ 理想的 クリティカルな障害を発⽣させる蓋然性の⾼い⽋陥を含むような品質状態

    ⼀時的に価値提供のスピードを落とし て、エミュレーターの実装やテスト⾃動 化を優先的に乗せるスプリントを意図的 に設けることで、スピードと品質価値を 両⽴出来る組織体制への移⾏を試みた 品質とスピードを両⽴可能な組織への導き⽅
  14.   26 総括 *“価値の提供スピード”と“品質価値”のバランスを                  “開発チームの全員”で意識する 準備として、 - 品質価値の計測‧評価基準(KPI)の認識を合わせる - 品質価値とスピードのトレードオフ関係についての認識を合わせる(バランス)

    - スピードを⼤切にする上で、最低限死守しなければいけない品質価値基準についての認識を 合わせる(相関性) 実践として、 - 品質価値とスピードのバランスを意識したプロダクトマネジメントを⼼がけている(バランス) - 品質価値とスピードの両⽴について継続的に全員で対策を考え、チャレンジしている(相関性)
  15.   29 品質 =「プロダクトがターゲットとするユーザー‧ステークホルダーに対して、適切な価値を提供してい ること」 スピード = 「ユーザー‧ステークホルダーに適切な価値を提供するまでのデリバリータイム 」 と解釈!

    品質とスピードを両⽴する...とは 「ユーザーやステークホルダーにとって適切なプロダクトの価値(機能や体験)を爆 速で提供する」こと! スクラムマスター(私)から⾒た品質とスピードの捉え⽅ こういう機能欲しいんだけど この時はこういう⾵に使えると嬉しい できました! 恐ろしく早いリリース...俺でなきゃ(ry しかも欲しかったものより便利だ...!
  16.   31 ここに、「役割に閉じた専⾨知識だけを持ったメンバーが集まり、与えられた役割の範囲で仕事をこなす」 実質コンポーネント型のスクラムチームが... 品質とスピードの両⽴に⽴ちはだかる課題 フロ ント エン ド バッ

    クエ ンド A 機能 バッ クエ ンド B 機能 業界 ドメ イン 知識 UI テス ト ユー ザー ドメ イン FEeng BEeng BEeng PdM QA Sales Biz プロ ダク ト 戦略 PD UI ‧ UX 専⾨性 の深さ 専⾨性の広さ
  17.   32 実質コンポーネント型のチームではこんなことが起こりがち... 品質とスピードの両⽴に⽴ちはだかる課題①  A機能の画⾯完成しました! ユーザーさん、こういう使い⽅をしていて... (PdMさんには伝えたんだけどな...) あっ...でも今から改修するとリリース予定に間に合わない... PdM(リリースオーナー)的にどうしますか? ⼀旦リリース

    or リリース伸ばして対応? (PdM)さん最近忙しいし、細かい挙動どうしようかな... でもユーザー的にどうなのかもわからんし... せや!MVPで作って後で改修すればええんや! ~~~~~~~⽉⽇は流れ、リリース予定直前のスプリントレビューにて~~~~~~~~ FEeng eng’s CS PdM 今回は許容するのでリリースしましょう。 (エンジニアなんだしこうすべきって 普通わかるやろ...) ミスコミュニケーション による、 ニーズから逸れた機能、 ⽋陥の作り込み
  18.   33 実質コンポーネント型のチームではこんなことが起こりがち... 品質とスピードの両⽴に⽴ちはだかる課題② UX的にこういう機能の⽅がイケてると思うので、このようなUIデザイン にしてみました。 レビュー指摘お願いします! 実際にプロダクト チームが実装始めて みないと分からん

    XXプロダクトチーム じゃ無いから レビューのしようが なぁ 他の⼈は特に指摘して ないし、問題なさそう ヨシ! ‧‧‧。 問題なければこれで進めます! ~~~~~~~⽉⽇は流れ、eng設計中~~~~~~~~ このUIで表⽰する箇所、外部サービスの制約上無理そうです。 分かりました。UIデザイン練り直します。。。 ⼿戻りや追加開発 による遅延 PD BEeng PD チーム 触ったことない 機能だしなぁ
  19.   34 実質コンポーネント型のチームではこんなことが起こりがち... 品質とスピードの両⽴に⽴ちはだかる課題③ ~~~~~~~さらに⽉⽇は流れ、経営戦略会議にて~~~~~~~~ ⽊こりの ジレンマ状態 ロードマップに書いてある機能、なぁい!!!!! 競合他社に追いつくために、ますます機能開発にリソースを割いてください! はい...。

    (今の体制を改善しないと負のスパイラルなのは⾒えてる... でも原因分析に時間かかるし、忙しい。。。) ニーズから 逸れた機能、 ⽋陥の作り込み ⼿戻りや 追加開発 による遅延 が重なり... ~~~~~~~さらに⽉⽇は流れ、別機能の要求定義中にて~~~~~~~~ このプロダクト、 何か変... Biz PdM カイゼンして、でもむしろスピード上げて機能開発して eng’s はい、やります。。。 (時間なぁい!!!!!) 以下、ループ
  20.   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を構成していくために有⽤な考え⽅!
  21.   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 機能 テ スト チーム チームの複数⼈、 理想的には全員が 他の領域を深く カバーできる状態!
  22.   43 より早期に、より⾊々な視点を知ることにより、課題‧不具合‧考慮漏れの発⾒やプロセス 改善、魅⼒的な価値を提供できるアイデア創出に繋がる「確率」を上げる! 例/ 機能横断型OneTeamがもたらすインパクト ユーザーさんはこういう使い⽅をしていて... ってPdM、CSの⽅が⾔ってたけど、このタイプのユーザーをターゲットに するなら、こういう使い⽅をしたいはずだよな... はじめから考慮に⼊れて設計しておこう!

    機能横断⼒を⾼めた FEeng 機能横断⼒を⾼めた PD 今はこういう意図で実装して、過去にこういう制約があって... 現状このレイアウトだと該当する機能がないから、開発⼯数伸びちゃい そうです...? こんなレイアウトの案も考えてみたので、こっちなら実装的にも軽く済 みそうだし、ユーザー体験も悪くなさそうです! 機能横断⼒を⾼めた BEeng 今はこれ改修されてるので、この実装シュッとしていただけそうです! ってQAの⽅から教わった箇所を確認してみたので、元の案でもそんなに 実装⼯数は掛からなそうです!
  23.   44 つまり... 機能横断型OneTeam で、役割の専⾨性を超えたコラボレーションを促進させることで、 品質‧スピード両⽅の向上に繋がる取り組み‧カイゼン創出の確率を上げる! 総括 フロ ント エン

    ド 業界 ドメ イン 知識 ユー ザー ドメ イン プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 テ スト フロ ント エン ド 業界 ドメ イン 知識 ユー ザー ドメ イン プロ ダク ト 戦略 UI ‧ UX バッ クエ ンド A 機能 バッ クエ ンド B 機能 テ スト よりニーズから逸れた機能や意図せぬ⽋陥を作り込まなくなり、魅⼒的な 価値を提供するための試⾏回数やリードタイムも短くなっていく! ユーザーやステークホルダーにとって適切なプロダクトの価値(機能や体験)を 爆速で提供できるように!
  24.   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) 認知負荷が⾼まりすぎないように、チームで進める開発の並列数を検査し続け る
  25.   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)
  26.   54 チームやプロダクトのコンテキストにあったQA活動を⾏うこと • とにかく速く何度もリリースを⾏う ◦ →どの順序でテストを⾏えばリードタイムを短くできるかを考え、開発エンジニアと調整する • 主要な価値 ◦

    →コア機能が何かを理解する。重篤度で認識を合わせる • UX ◦ → 動かしてみた感想をいち早くチームに共有する。そのために、実装成果物を最速でテストすることを⽬指す - Accelerating project - コンテキストとフォーカス - とにかく速く何度もリリースを⾏って市場で存在感を⽰したり、市場で学ぶべき時期に⾏う品質保証活動 - >> プロダクトサイズは⼩さく、信頼性や安全性はそれほど要求されない時期 - 主要な価値やUXが損なわれないことと、開発スピードが上がること、成⻑できるチームになっていること、などに品質保証 をフォーカスさせる イマドキのソフトウェアのテストやQAの考え⽅ (https://www.slideshare.net/YasuharuNishi/line-developer-meetup-in-tokyo-39-presentation)
  27.   56 • 重篤度とは、freee社内で定義している「事象のヤバさ」を表現する指標 ◦ 4段階の指標であり、重篤度が⾼い順にcritical, major, normal, minorとしている •

    Eng, QA, PdM, PD全員で、プロダクトの重篤度を定義している チームやプロダクトのコンテキストにあったQA活動を⾏うこと 取り組みの紹介 2. 重篤度の定義
  28.   58 チャーターベースのテスト • テストチャーターとはテストケースより粒度の⼤きいテスト設計の成果物 • 軽量だが勘所を押さえるテスト活動を実現している チームやプロダクトのコンテキストにあったQA活動を⾏うこと 取り組みの紹介 4.

    チャーターベースのテスト <ミッション> 何のためのテストか? <テストチャーター> 【確認箇所】 テスト対象の画⾯などを書く 【期待結果】 テストしたい箇所/事柄を書く 【P-V (事前条件と⼊⼒)】 テストの事前条件や⼊⼒についての因⼦/⽔準を書く <テストチャーターのポイント> テストチャーターの補⾜として書いておきたいこと、難しい⼿順などがあれば書く
  29.   60 各ロールの視点で⾒る、品質とスピードを両⽴したOneTeamを構成するために意識していること まとめ 役割 回答 PdM ・価値の提供スピードと品質価値”のバランス・相関性を開発チームの全員”で意識する SM ・チーム全員で機能横断力を高め、品質・スピード両方の向上に

    繋がる取り組み・カイゼン創出の確率を上げること Eng ・whyを理解し、重要な仕様検討をチーム全体で行うこと(他ロールの視点を積極的に求めること) ・認知負荷が高まりすぎないように、チームで進める開発の並列数を検査し続ける QA ・チームやプロダクトのコンテキストにあったQA活動を行うこと ・チームメンバーと同じメンタルモデルを持つこと