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

プロダクトフェーズごとのQAの役割の変化

taikyy
March 13, 2024
360

 プロダクトフェーズごとのQAの役割の変化

taikyy

March 13, 2024
Tweet

Transcript

  1. © LayerX Inc. 3 経歴 • 語学学習アプリPM • 株式会社LayerX(2021/5 〜)

    好きな食べ物:うなぎ 画像を入れてね 自己紹介 taikyy
  2. © LayerX Inc. 4 全ての経済活動を、デジタル化する。 会社概要 会社名 株式会社LayerX(レイヤーエックス) 代表取締役 代表取締役CEO 福島

    良典 代表取締役CTO 松本 勇気 創業 2018年 8月1日 資本金 約132.6億円 拠点 東京本社 〒103-0012 東京都中央区日本橋堀留町1丁目9−8 人形町PREX 関西支社 〒530-0003 大阪府大阪市北区堂島1-1-5 関電不動産梅田新道ビル 中部支社 〒453-6111 愛知県名古屋市中村区平池町4-60-12 グローバルゲート 九州支社 〒810-0801 福岡県福岡市博多区中洲3-7-24 従業員数 250名 (2023年12月末日時点)
  3. © LayerX Inc. 5 プロダクトラインナップ 稟議・支払申請・経費精算 仕訳・支払処理効率化 法人カードの発行・管理 帳票保存・ストレージ 帳票発行

    * 経費精算のSlack連携は申請内容の通知のみ ・AIが領収書を5秒でデータ化 ・スマホアプリとSlack連携あり ・領収書の重複申請などミス防止機能 ・AIが請求書を5秒でデータ化 ・仕訳・振込データを自動作成 ・稟議から会計までスムーズに連携 ・年会費無料で何枚でも発行可 ・インボイス制度・電帳法対応 ・すべての決済で1%以上の還元 ・AIが書類を5秒でデータ化 ・あらゆる書類の電子保管に対応 ・電子取引・スキャナ保存に完全対応 ・帳票の一括作成も個別作成も自由自在 ・帳票の作成・稟議・送付・保存を一本化 ・レイアウトや項目のカスタマイズも可能
  4. © LayerX Inc. 6 チーム体制:プロダクトごとにスクラムチームが組成され、スクラムの1メンバーとして QAも入っている メンバー構成: - プロダクトマネージャー(1名) -

    エンジニア(1-5名) - QA(1名) - デザイナー(他チームと兼務) 開発スタイル:LayerXでは、機能の開発(アウトプット)が速いことではなく、顧客への価値提供(アウトカム)が速いことを重 視 - 早く失敗、早く修正 - 守るものは決めつつ立ち上げからちゃんとしすぎない - フェーズによって重心を変える(立ち上げからちゃんとしすぎない、 PMF後に品質へ重心を移していく) LayerXの開発方針
  5. © LayerX Inc. 8 サービス立ち上げ期のQA QAの気持ち - 細かいバグがたくさん出てくるけど大丈夫なのだろうか →バグ改修してリリースを後ろ倒した方がいいのでは -

    ファーストリリース後に本番障害出してしまったらどうしよう →性能効率性など抜けてる観点まだまだありそう - そもそもバグやエラー、QAの用語みんな認識バラバラ →一定チームにインプットした方がいいのかな この状態で進んでいくと、
  6. © LayerX Inc. 9 サービス立ち上げ期のQA QAの動き - 安心できる状態でリリースできるようにバグを出し切る - バグ数とバグ改修をきちんと管理する

    - 性能効率性などの非機能要件なども追加で確認してエンジニアにFBする - チーム全体でQAの用語や品質の定義を合わせる というような方向に進んでいきがち、(一見悪くはないですが) 結果 重大度に関わらずバグの数が多いというだけでチーム全体が不安になる バグの確認/切り分け、バグ改修にチーム全体の工数を多く使ってしまう →QAプロセスがブロッカーとなりリリースが遅れ仮説検証も遅れていく
  7. © LayerX Inc. 10 (一方)PdMの気持ち - ユーザーに刺さるかどうか心配 →軌道修正も見越して仮説検証を早く回したい - とにかく早くリリースして手応えを得たい

    →競合他社とのスピード勝負に負けるとthe end サービス立ち上げ期のQA (一方)エンジニアの気持ち - リリースまでとにかく時間がない →最短で効率的に機能実装をしたい
  8. © LayerX Inc. 12 QAとしてどういうマインド? - バグのなさを目的化しない - 例)ボタン連打したらバグった -

    優秀なテスター思考になりすぎない - 例)×しない→エッジケースバグの報告、バグ数の管理、仕様の細かいFB - 一発アウトをケアする - 例)セキュリティ観点など 結果 デリバリー速度が上がり仮説検証サイクルが早く回る サービス立ち上げ期のQA
  9. © LayerX Inc. 13 実際に行った業務の例 具体の業務:プロダクト価値をユーザーに届けるところと仮説検証はなんでも柔軟に - 一発アウト観点のFB(セキュリティー周りなど) - リリースに伴うマニュアルテストの比重大きめ(自動化戦略は後回し)

    - お客様のサービス導入のサポート - 問い合わせバグ/エラーの調査 - テクニカルサポート →プロダクト仕様とユースケース(特にお客様が詰まるところ)を深く理解していく 求められる力:柔軟性、事業推進 サービス立ち上げ期のQA
  10. © LayerX Inc. 15 サービス立ち上げ期〜PMFのQA QAの気持ちも変化 - 初回リリースから大きな本番障害なく進めることができほっとしている - バグが多くでる機能、抑えるべきポイントが少しずつ見えてきた

    - ユースケースのなかでも特に使いにくいところや説明が必要なところが見えてきた - 機能拡充や複雑化に伴いセールス・CSなど他チームやスクラムチーム内でも細かい仕様把 握ができなくなり始めた気がする どういう切り口でいこうか
  11. © LayerX Inc. 16 サービス立ち上げ期〜PMFのQA QAの動き - プロダクトのテストやお客様への導入サポート、ユースケースケースの理解などの仮説検証 にディープダイブしてきたので、 -

    ここで生まれている前提: 社内で(≒世界で)最も担当プロダクトの仕様を把握している →深い仕様理解からチーム全体をイネーブルメントする
  12. © LayerX Inc. 17 実際に行った業務の例 具体の業務:プロダクトへの深い仕様理解から派生する業務色々 - 仕様書の作成・整理 - ユーザーガイド・リリースノートの作成

    - 社内プロダクト仕様勉強会 - 社外向け新機能セミナー - テクニカルサポート(商談同席) - 問い合わせバグ、エラーの切り分け →ユーザーがプロダクト利用でつまるところやバグなど含めユースケースや仕様をチーム全体 に還元・イネーブルメントする 求められる力:イネーブルメント的な発想 サービス立ち上げ期〜PMFのQA
  13. © LayerX Inc. 19 PMF〜成熟期のQA QAの気持ちも変化 - ユーザー数増えると細かいバグでも複数ユーザーに影響が出る - ユーザー数増えるとバグの問い合わせが増える

    - 非機能要件とかすごく心配になってきた - 気づいたらリグレッションテストが膨大になってる - 新機能開発ごとにデグレする範囲も広い どういう切り口でいこうか
  14. © LayerX Inc. 21 実際に行った業務の例 具体の業務:いわゆる品質保証活動なんでもやっていく - リグレッションテストの整備(リファクタ) - リスク分析、バグ分析

    - 魅力的品質向上の活動(ユーザビリティの検証) - 問い合わせ削減(偽陽性バグ) - テスト自動化(コードベース) →品質をより安定的にスケールする形で高めていきたい 求められる力:QAEとしての底力 PMF〜成熟期のQA