最速思考でバクラク品質を！ スタートアップのリアルな課題とQAの実践

Transcript

1. © 2024 LayerX Inc. 最速思考でバクラク品質を！ スタートアップのリアルな課題とQAの実践 JaSST’24 Tokyo LayerX 中野直樹 (@TestingGolem)
2. 自己紹介 中野 直樹 LayerX QAマネージャー エンタープライズシステムの開発者、プロジェクトマネージャーなど を経験後、テスト技術者へ転向。 ネット証券のシステム開発部⾨のテ ストチームのリーダーや不動産情報ポータルの運営会社のQAマネ ージャーを経て2023年春よりLayerXのQAマネージャに従事 社外活動 - 共著「ソフトウェアテスト教科書 JSTQB Foundation 第4版」 - NPO法⼈ソフトウェアテスト技術振興協会（ASTER)理事 - JSTQB技術委員 - JaSST Tokyo 実⾏委員など
3. 目次 Agenda • プロダクト紹介と歩み • 弊社LayerXのQAのスタイル • 課題と取り組み • 今後について
4. © 2024 LayerX Inc. 4 高速なデリバリーと最適な品質を考えるうえで以下の取り組みについて • バグを無くすことを目的とはしない • Whole-Team での品質アプローチ 今日のテーマ：最速思考でのQA・テストの取り組み
5. © LayerX Inc. 5
6. © LayerX Inc. 6 LayerXの事業の中で、今回はSaaSである「バクラク」を対象とします バクラク事業 企業活動のインフラとなる法人支出 管理（BSM）SaaSを開発・提供 Fintech事業 ソフトウェアを駆使したアセットマネ ジメント・証券事業を合弁会社にて 展開 AI・LLM事業 先端ソフトウェアモジュールを提供し、 企業のデータ活用・生産性を向上を サポート +
7. © LayerX Inc. 7 バクラクのプロダクトビジョン 圧倒的に使いやすいプロダクトで わくわくする働き方を。 企業活動を支えるコーポレート業務は、ミスができない難しい業務。 バクラクはそんな業務の負担を少しでも軽くし、日常の業務がわくわくするような体験を届けます。 使いやすさへの圧倒的なこだわりと、深い顧客理解で業務効率化を実現。 手作業、ハンコ、紙のやり取りから脱却し、事業と組織を支える本来の仕事に向き合えるようサポートします。
8. © LayerX Inc. 8 バクラクシリーズラインアップ 体験にこだわり抜いたマルチプロダクトをリリース。単体でも使いやすく、連携するとさらに便利に。 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行 ・AIが領収書を５秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機 能 ・AIが請求書を５秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対 応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
9. © LayerX Inc. 10 コンパウンドなプロダクト志向 • 創業時から単一プロダクトではなく、複数プロダクトを意図的に提供 • 部署でサービスを区切るのではなく、データを中心にサービスを統合する • プロダクト間の連携の良さそのものが プロダクトである。 単純なマルチプロダクトではない。 • 複数のプロダクトを管理、 ローンチするケイパビリティを持つ
10. © LayerX Inc. 11 ２年半で6つのプロダクトと各連携を高速でリリース。 * ２０２３年10月時点 2021/01 バクラク請求書 2021/04 バクラク申請 2021/11 バクラク電子帳簿保存 2022/04 バクラク経費精算 2022/07 バクラクビジネスカード 2023/07 バクラク請求書発行
11. © LayerX Inc. 12 開発チームとQAエンジニアの 体制や動き方について
12. © LayerX Inc. 13 開発チームとQAエンジニアの体制や動き方について デリバリーチームA QA エンジニア デリバリーチームB QA エンジニア デリバリーチームC QA エンジニア QA エンジニア QA エンジニア QA エンジニア チームメンバー チームメンバー チームメンバー QAチーム • 2週間スプリントのスクラム開発 • QAエンジニアはプロダクト開発チームにQA担当として 入りつつ、QAチーム間で連携しながら活動 • リリース前のテスト、自動テストの保守、品質分析などを実施
13. © LayerX Inc. 14 バグを無くすことを 目的とはしない
14. © LayerX Inc. 15 価値あるプロダクトを高速にデリバリーするために • 追加機能の実装 vs 軽微なバグの修正 ◦ バグをなくす≒手戻りをなくすという 考え方もできるが、、、 • 上記の二つのタスクも同じリソースから生みだされる もので、一部のバグ改修を先送りにして価値のある 機能をいち早く市場に届ける判断もあって然るべき • 顧客の購買の意思決定とバグ有無はほぼ無関係 ◦ バグがあることは利用しない理由にはなる がバグないことは利用する理由にはならな い バグを無くすことを目的とはしない 充分 不充分 満足 不満足 顧客の満足感 当たり前品質 魅力的品質 一元的品質 気に入る 気に 入らない 物理的な充足度
15. © LayerX Inc. 16 バグを無くすことを目的とはしない ◦ 優先度や重要度の扱い方と「いつ」修正すべきかの視点 ▪ ユーザー影響という視点においては、現時点と数回先のリリースでは バグの優先度が変わっている可能性がある ▪ バグを修正してリリースを見送る vs リリース＋後追いでのバグ改修は お客様にとってどちらが嬉しいか「お客様を主語に」して考えリリースの判断に用いる
16. © LayerX Inc. 17 バグを無くすことを目的とはしない • プロダクトリスクに顧客視点を加える • よくあるプロダクトリスクの例として以下のようなものがあったときに 「〇〇機能が仕様通りには動かないかもしれない」 「計算処理で計算結果が状況によって正しくない」 「特定のデバイス、OS、ブラウザ環境において画面表示が崩れてしまう」 • 上記の粒度だとプロダクトリスクの顕在化がお客様に与える影響を考えきれていない • お客様の体験に大きく影響する≒リスクの大きさという意識で判断し、リリースまでのプロセスを安 全に進行するためにテストの実施順や重みづけにも適用することでお客様に届けたい価値とリスクの バランスをとることができる
17. © LayerX Inc. 18 Whole-Teamでの 品質アプローチ
18. © LayerX Inc. 19 Whole-Team での品質アプローチ Whole-TeamでQAエンジニアが何に取り組んだら正解なのか • 全員で責務を持つポイント ◦ Whole-Teamカルチャーを牽引するとは、 品質を議論する場づくりやファシリテート ▪ 例えば、品質改善に向けた課題の言語化、品質の改善活動のカルチャーを根付かせる ◦ 自分たちが届けたい品質とは何か ▪ 例えば、そういった場においてお客様の体験にはバグだけでなくUXの観点も重要 • QAエンジニア以外の職種の能力を品質に役立てる意識 ◦ 例えば ▪ PdMの深い顧客理解、ビジネスドメインの知識 ▪ デザイナーのUI/UXデザインに関する知見 ▪ 開発エンジニアの運用後を見据えたリスク検知の嗅覚
19. © LayerX Inc. 20 Whole-Team での品質アプローチ テスト期間前の探索的テストを実施する会（通称 ET会）の開催 • スプリントレビューではなく、開発者のセルフのテストでなくチームでの探索的テスト実施 • 早期のバグ発見も重要ではあるが、出来上がった機能に期待していたUXを検証する場 や機会に価値がある • テストだが、仕様変更のきっかけにもなっており、使いづらいものをリリースする前に ブラッシュアップしてその後のリリース前テストに挑む • 探索的テストで実際の体験を通して仕様の改善ポイントが見つけられることは リリース後に仕様変更することを考えると手戻りの観点で何倍も効率的である • お客様にとっては仕様かバグかは関係ない お客様にとって「使いやすいか」「使いづらいか」「使えない」という体験だけが残る
20. © LayerX Inc. 21 今後について
21. © LayerX Inc. 22 プロダクトの初期フェーズ以外のQA/テストのあり方はどうか 各QAエンジニアにとってのテクニッ クやナレッジを言語化しチームの共 通の型に加えることは意外な難しさ があります 加えて、プロダクトのフェーズによっ て求められる品質は変わります フェーズごとの品質の重要性を意識 した型作りと継続的なアップデート が重要です コンパウンドスタートアップとして、 複数のプロダクトが滑らかに連携す ることが製品の特性とある中で、担 当のQAエンジニアがプロダクトごと に担当割をしているとどうしても連 携部分の問題に気づきづらくなる事 象が発生しがち 型化と適用 仕組みやツール 汎用的に使えるQAやテストの仕組 み、または生産性に寄与するツール 例えば、バグチケットの起票から通 知する仕組みやテスト状況のレポー ティングなどをモダンな技術でシス テマチックに使えるように資産の積 み上げる必要があります コンパウンドの難しさ 少しずつあるべき姿の言語化や施策を打ち始めていますが、まだまだ課題はあります。
22. © LayerX Inc. 23 補足：QAエンジニアとしてのスタンスやあり方の課題 QAエンジニア個々に特有のドメイン 知識や技術が偏っている問題が存 在します。 このような状況の中で、どの知識や 技術を共通の技術として、どの程度 まで習得を目指すべきかは、組織全 体の成長と効率化の観点から常に 考える必要があります。 チーム全体での最適化を目指し、知 識と技術の均等な分配と向上をど のように進めるかが重要な課題とな ります。 ビジネスや競合プロダクトの理解や 開発側のエンジニア目線でのアーキ テクチャーや内部的実装をどこまで 理解し解像度を上げるべきか また、UXやUIのデザインの知識を どこまで高めるべきかなど学ぶべき ことが大量にある中での優先順位 づけが悩ましい 属人性と技術 責務 周辺技術の理解 例えば、仕様について何にどこまで 口を出すべきか 扱うデータの範囲は・・・？ バグや性能など分かりやすいですが、 お客様の体験に着目した場合には、 追加でどのようなデータを扱ってい くのか、メトリクスとして何を採用す るのか
23. © LayerX Inc. 24 まとめ
24. © LayerX Inc. 25 まとめ • 最速思考で価値あるプロダクトを提供するために ◦ バグがないことを目的としない 「バグ＝悪」ではなくどこまで作り込んで届けるかのQAとして見極めが重要 バグもプロダクトリスクも「お客様を主語」に考えることで判断しやすくなる ◦ Whole-teamでの取り組みの重要性 チームによる探索的テストは、バグを見つけるだけでなく、体験を通して 仕様の改善点を見つけることで大きな手戻りをなくせる可能性がある
25. © LayerX Inc. 26 LayerXでは絶賛採用中です！ • 新しい事業やプロダクトをつくり、一緒に進化させていくためのQAエンジニアを募集し ています。 ◦ https://jobs.layerx.co.jp/ ◦ （実際はQAに限らず、全方位募集しております！エンジニア、デザイナー、PdM、事業開 発、Sales、CS、マーケ、アナリスト etc…） • カジュアル面談もお待ちしています！ ◦ https://jobs.layerx.co.jp/1ec6bec508134f4b9c6018cb8b339254