Slide 1

Slide 1 text

© Alp, Inc. 2025/02/17 QA engineer at a Startup vol.6 ユーザーストーリーマッピング から始めるアジャイルチームと 並走するQA

Slide 2

Slide 2 text

© Alp, Inc. はじめに 自己紹介 あきさん(Akihiro YOKOTA) - アルプ株式会社 QAエンジニア - X: @katawara 名刺管理の会社でバックエンドエンジニアやEMを経 て、QAチームの立ち上げから、全社横断のQA組織を 作るまでを経験。 2023年からアルプ株式会社に入社。社内唯一のQAエ ンジニアとしてできることは何かを日々模索する。

Slide 3

Slide 3 text

© Alp, Inc. BtoBサブスクリプションビジネスのための 販売管理システム 売上回収まで実現する法人向け 請求・決済システム 提供する2つのプロダクト 販売管理システム 請求‧決済システム

Slide 4

Slide 4 text

© Alp, Inc. 多くのビジネスがサービス化(XaaS)している ● 顧客起点での継続的な関係が重要視され、またIoTやAIのようなデジタル技術の普及により、サービス型のビジネスモデルへのシフトが一層 進んでいる。 ● SaaSを始めとして市場規模も右肩上がりで伸びており、今後もさらなる成長が見込まれる。 SaaS PaaS IaaS MaaS DaaS BPaaS ・ ・ ・ SaaS 1兆2,284億円 (2022年度) 1兆8,330億円 (2026年度予測) PaaS 4,221億円 (2022年度) 7,166億円 (2026年度予測) IaaS 6,272億円 (2022年度) 8763億円 (2026年度予測) 参照:株式会社富士通キメラ総研『2023 クラウドコンピューティングの現状と将来展望 市場編/ベンダー戦略編』

Slide 5

Slide 5 text

© Alp, Inc. サービス化に伴う変化と課題 ● 従来のモノ売りからサービス化へのシフト伴い、プライシングや販売オペレーションに大きな変化が発生します。 ● それらの変化に対しては、従来の仕組みでは対応できないことが多く、新たな販売管理の仕組みを整えることが必要です。 モノ 単一価格 一括売り サービス 月額課金 年額課金 毎月請求 一括前払い 日割り など 定額課金 従量課金 アカウント課金 利用実績に応じた課金 成果報酬に応じた課金 など 継続的なプライシング 戦略や顧客ニーズ、市場トレンドに合わせて流動的にプライシングも変化 プライシングの変化 オペレーションの変化 モノ 期間の概念なし サービス 契約管理 請求管理 請求/決済 入金管理・督促 事業分析 基本的に単価×数量の 1回課金 販売時に1回 請求書払いがメイン 1回課金の為頻度は少ない 新規販売の分析がメイン 期間の概念あり 時系列での管理が必要 継続的な課金が発生 従量課金の計算も必要 継続的な業務が発生 決済手段も多様化 継続的な課金の為高頻度 MRR/チャーンレート等 特有のKPI分析が必要 継続的な契約が前提となる為、販売オペレーションは複雑化する一方、正確性の担保は必要 新たに考慮が必要な要素が増加

Slide 6

Slide 6 text

© Alp, Inc. © Alp, Inc. はじめに

Slide 7

Slide 7 text

© Alp, Inc. 2023/03 - 06 2023/07 - 2024/12 2025/01 - 変化する環境、変化するQA 時系列でのQAロールの内訳の変遷 - アルプには3つのQAロールがあり、同じQAでも時期とともに力の掛け方が徐々に変わってきている - 入社当初は全体向けの施策や活動が多めだったが、それからしばらく長期にわたってE2Eの整備にウェイトを置いていた - 最近、また事情が変わってきてチーム寄りの活動にシフトすることになった

Slide 8

Slide 8 text

© Alp, Inc. 変化する環境、変化するQA - 今までメインプロダクトのScalebaseに軸足を置いてきたが、だいぶ安定してきた - これからの成長を見据える中で、Scalebaseペイメントでよりリスクの高い領域への進出が始まった - 「決済」という、顧客 ↔ 取引先間での直接の金銭の授受が絡む機能の誕生 - 一定顧客もつき始め、品質への追加投資が可能になった - 今まではどちらかといえばチームの外 から各チームを平等に支援してきたが、今度は特定のチームの中 に入っ て進化を促していくほうが、事業全体で見てプラスと考えるに至った - さらに、チームの中で機能するQAの型 が作れれば、各チームに横展開できてGood、という裏ミッショ ンも発生 変化する環境、変化するミッション

Slide 9

Slide 9 text

© Alp, Inc. 2023/03 - 06 2023/07 - 2024/12 2025/01 - 変化する環境、変化するQA 時系列でのQAロールの内訳の変遷 ということで、今回はこの一番最近のお話

Slide 10

Slide 10 text

© Alp, Inc. © Alp, Inc. アジャイルチームとQAの型?

Slide 11

Slide 11 text

© Alp, Inc. そうは言っても 当初、答えは持ってなかった (開発者やPdMに代わってテストすればいいのだろうか?  それとも  後手に回りがちなテスト作成を巻き取ったらいいのだろうか?)

Slide 12

Slide 12 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 ユーザーストーリーマッピングとの出会い そんな中、新規のフィーチャー開発が始まり、 いつもの流れとしてユーザーストーリーマッピング のワークをすることになった 聞けば今まで我流でやってきたとのことで せっかくなら一回原典を参照しつつやってみよう となり、改めて書籍を読み込んだ そしてひらめきが訪れる

Slide 13

Slide 13 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 ユーザーストーリーマッピングとは ざっくり解説: - 提供する機能が、誰に、どういう時系列で使われていくかを 付箋でマッピングしていくワークショップ - 付箋には目的を達成するまでの行動が1ステップごとに記載さ れる - 書いた付箋を「スライス」と呼ばれる機能が成立する単位に 分解し、限られた期間でどこまで作るのかを定めていく

Slide 14

Slide 14 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 ユーザーストーリーマッピングとは ぶっちゃけ、→の本の0〜5章ま でを読んで手を動かしてもらうの が一番話が早いのでそうしてほし い(台無し)

Slide 15

Slide 15 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 実際の活動風景 @FigJam

Slide 16

Slide 16 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 ライブで得られる体験知 - 言葉・画像・図表のミックスにより得られるイ メージの記憶 - 言外の微妙なニュアンス - 「これはやらなきゃね」という感覚 その場で得られたもの 多くの問いに対する答え - なぜこの機能がほしいのか - 誰の何を助けるものなのか - 誰が関係者なのか - どういう流れで使われる想定なのか - この機能のMVPは - どこまで作ればリリースできるのか 関係者間の共通の理解のゾーンが増えた

Slide 17

Slide 17 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 「ストーリーを作る本当の目的は、共通理解をつかむことだ。」 Jeff Patton, ユーザーストーリーマッピング, p.7 声に出したい日本語

Slide 18

Slide 18 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 「ストーリーを作る本当の目的は、 共通理解をつかむことだ。」 Jeff Patton, ユーザーストーリーマッピング, p.7 声に出したい日本語

Slide 19

Slide 19 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 型へと至るキーワードは「伴走」なのではないか ここでチーム内での立ち回り方と型化への仮説が生まれる - もともとのプロセスにリアルタイムで並走する - 同じものを同じタイミングで、ただし別の視点もあわせて見る - Question Askerとして立ち回り、共通理解を拡張する

Slide 20

Slide 20 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 仮説をもとに ユーザーストーリーマッピングが終わって早々に シナリオテストを書き起こしてみることにした シナリオテスト

Slide 21

Slide 21 text

© Alp, Inc. アジャイルチームと一緒に活動するQAのあり方の模索 - ユーザーストーリーマッピングを見ながらであれば、開発の進捗よりやや先行気味、かつあまり手間取ること なく、シナリオテストが起こせた(!) - ビジュアルなものから逆に文章で一通りの流れを書き起こしてみると、「ここってどうなるっけ?」みたいな ものにも自然と気付く - 成果物を開発・PdMとも共有してみると、さらにお互いの共通認識が深化していく体感があった - シナリオを進める中で考えられそうなイレギュラーパターンも随時詰めていくと、手戻りも減りそう - 間違いなく、ドキュメントを後追いしてテストを考えるより、コミュニケーションコストが減っている シナリオテストの感触の変化 テストが開発速度を押し上げる可能性

Slide 22

Slide 22 text

© Alp, Inc. © Alp, Inc. なんかうまくいくかも?

Slide 23

Slide 23 text

© Alp, Inc. まとめ ここから先のプロセスはまだこれからだが、シナリオテストができるなら、E2Eも同様に検討できる予感がする お互いを補完し合いながらこんな感じで前進できたら、開発しながら品質を作り込めるのではないか? 展望

Slide 24

Slide 24 text

© Alp, Inc. © Alp, Inc. アジャイルチームとQAの型(β)

Slide 25

Slide 25 text

© Alp, Inc. まとめ ここまでの活動と思考をまとめてみたが、実際のところかなりβ版 理論上は期待感があるけど、本当にうまくいくのかについては、もうしばらく仮説検証が必要 おわりに

Slide 26

Slide 26 text

© Alp, Inc. © Alp, Inc. Thank you 🙇