ハッピーの重篤度でみんなで 品質の⽬線合わせするぞ！ ymty(ゆもつよ) 2024年6⽉1⽇ 16:40-17:00 katariba

2 ymty / ゆもつよ ▼略歴/Brief History 1991.03 ~ ⼤学卒業 2013に社会⼈⼤学院⽣になり2018 年に博⼠号取得（⼯学） 1991.04 ~ 社会⼈スタート テスター、テストリード、テスト マネージャー、テストツールプリセー ルス、テストコンサルタント etc. 今⽇に⾄るまでテストの仕事⼀筋 2019.07 ~ freee株式会社 QAチーム JM(ジャーマネ) ▼趣味/Hobby ‧ビール⇨⼈間ドックの前⽇以外毎⽇飲む ‧エレキギターの練習：週末練習してる ‧好きな⾷べ物：⽇本そば

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストもフィード バックの⼀つ もっと速く、 もっと⼿前で！！ freee QA

お客さんにとっての品質の全体像：魅⼒、⼀元的、当たり前 ・新しいサービス、コンセプトは魅力、一元的品質を向上させる
 ・魅力的、一元的品質は、時間とともに当たり前品質になっていく


お客さんにとっての品質の全体像：魅⼒、⼀元的、当たり前 ‧⼀元的、当たり前品質がヤバいゾーンに⼊ったら⼗分な対 処が必要になる

プロダクトの品質が悪いと起こる損失 仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ もっと速く、 もっと⼿前で！ 経済的な損失 時間の浪費 信用の失墜 ● お客様機会損失 ● 損害賠償 ● 本来の仕事が止まる ● 玉突き問題 ● SNS炎上 ● 不買運動

ハッピーの特徴：後になるほど損失が増える 仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ There’s a famous example as per which if a bug is detected in the requirements phase, the cost might be $1. If it is uncovered in the design phase, the cost will increase to $10, $100 during coding, and $1000 during testing. ※ハッピー(freee⽤語) ➢ バグのこと ➢ 修正するとお客さんがハッピーになるのでfreeeではハッピーと呼ぶ もっと速く、 もっと⼿前で！

　 こういうことがおきないようにしないといけない！

　 QA（Quality Assurance）エンジニア 開発したプロダクトが「お客さんに使ってもらってOKだ！」 ってわかる情報提供をするエンジニアたち

QAが「OKだ！」と⾔えるためにやること ひとつめ 仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ 成果物が「定めたレベルの出来栄え」に到達する/していることが わかるよう仕組みを作って遵守できるようにする ...例えば ● 起きたらいけないこと（リスク）をみんなで意識合わせする ● 要件（PRD）、設計（DesignDoc）をチームで愛でる ● PRにユニットテストの結果が書いてないとマージできないような仕組みを運⽤する ● ぽちぽち会‧UXぽちぽち会を開く ● ⾃動テストを使ったリグレッションテストを⾏ってから本番にリリースしている ○ もっと速く、 もっと⼿前で！

QAが「OKだ！」と⾔えるためにやること ふたつめ 仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ 「仕組みの品質」と「お客さんに使ってもらうプロダクトの品質」 を確認する。 ...例えば ● 要件、設計をレビューして修正するまでを確認 ● 開発者⾃⾝によるユニットテストをコードカバレッジなどで定量的に確認 ● テスト環境で統合テスト、システムテストをして、ハッピーがあれば修正をしてリリースOKかを確認 ○ テスト結果はリリースOKかを確認をするための（とても鮮度の良い）基礎データとなる ● ハッピーを分類して件数を計測し続けて、傾向を確認 ○ ハッピーは品質を改善するための基礎データとなる もっと速く、 もっと⼿前で！

freee QAのミッション‧ビジョン 仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ ミッション ○ 起こしちゃいけないハッピーが起きにくい体質にすることでマジ価値※を継続的に届け続け る ※マジ価値：ユーザーにとって本質的に価値があると自信を持って言えること ○ ■ 込めた意志 ● 当たり前品質にフォーカス。品質という⾔葉は広くいろいろやると中途半端に なってしまうので、どこに⼒を⼊れていくかが重要 ● リリーススピードにこだわりたい。継続的にマジ価値を届けていくことが重要 ビジョン ○ 当たり前品質の⾼速フィードバックの実現 ■ どのフェーズでも⽬指すべき品質とのGAPを⾼速フィードバックすることで、⼿戻り がなく⾼頻度にユーザに価値を届けられるようにしていく もっと速く、 もっと⼿前で！

freee QAの活動の特徴 仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ ※重篤度：Severity ➢ 事象のひどさであり、ユーザーのもと で発⽣してはいけない度合いを⽰す ● リリース頻度が⾼いので、リスクベースドテストを中⼼に⾏っている ○ 各プロダクト、サービスごとに重篤度：Severity※を定め、開発チーム全体で認識をあわせている ○ 重篤度が高い事象が起きる可能性（リスク）があるかを話し合い、高いリスクを確実に潰すようにテストする ● アジャイル開発しているチームが多く、QAエンジニアも上流⼯程から参加している ○ QAエンジニアが各開発チームにアサインされているため、企画段階から関わり、さまざまな意見を言い合える環境がある ○ ドメイン知識のない領域にチャレンジするメンバーも少なくないため、開発チームで勉強会を開催するなど、チームで知識 を高めていく活動も盛ん ● リグレッションテストを⾃動化し、QAエンジニアも⾃動テストをコーディングして活⽤し ている ○ Seleniumなどいくつかのオープンソースを活用してfreee独自のテストフレームワークを構築している もっと速く、 もっと⼿前で！

freee QAの軌跡 - QAチーム誕⽣ - ⾃動E2Eテスト運⽤開始 - 不具合データを JIRAに⼀元化 - 品質KPI誕⽣ - リスク洗い出し 会の運⽤開始 - 網羅的テストから⽬的重 視のテストチャーターへ - 全プロダクトの重篤度を 定義 - SEQチーム誕⽣ - ジュニア採⽤と育成体制 構築 - QAテストプロセス標準 化 - グローバルQA誕⽣ - 新卒QA採⽤開始 仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ もっと速く、 もっと⼿前で！

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ freee QAの現状の課題 ● ⽬指すべき品質のブレ ○ プロダクト増、組織拡大に伴って、みんなが同じ品質目標に向かってるとはいえない 当たり前なことかもしれないが、これが難しい。みんな一丸となって品質目標に向かっていけるようにしたい ● ⼈材の育成と流動性 ○ 最低限の育成体制は構築したが、育成のPDCAを回せておらず、QAのキャリアパスもこれから定義する段階 ○ 1チーム1人QAの体制が多く、属人性が強い組織になっている ○ 人材の流動を容易にすることで、変化に強い、チャレンジしやすい組織にしていきたい ● テストアーキテクチャの最適化 ○ 統合ERPでは連携機能が多く、機能開発時の影響範囲も広い ○ このままだとテスト工数も増えていき、スピードのある開発が難しくなってくる。今は、ユニットテスト、統合テスト、システム テストが個別に設計しているので、テスト全体で最適化をしていきたい このためにやったことを話します（やっと本題） もっと速く、 もっと⼿前で！

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ 重篤度で⽬線合わせするためにやったこと ● 定義を決める ○ 4段階で定義 （全面的に使えない、主要機能が使えない、代替手段がある、実影響なし） ○ 優先度と重篤度の違い（病気で例える、糖尿病と擦り傷） ○ 重篤度とお客さんへの影響の関係を定義（マグニチュードと震度） ● ひたすら周知する ○ Slack、ブログ ○ いろいろな振り返りに参加、なんかといえば重篤度の話をする ○ 全社ミーティングでも重篤度の話をする ○ 「重篤度おじさん」を名乗る ● 具体例はプロダクトごとに決めていく ○ 同じような事象がプロダクトごとに重篤度が変わることもある ○ 2020年にも決めたが、メンバー、プロダクト拡大で再度定義の必要があった もっと速く、 もっと⼿前で！

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ プロダクトごと定義できたことを情報集約 一部抜粋 もっと速く、 もっと⼿前で！

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ 重篤度判断早⾒表を作成するチーム現れる！ もっと速く、 もっと⼿前で！

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ 通常作業のテンプレ改善が進む！ もっと速く、 もっと⼿前で！

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストも フィードバック の⼀つ まだ道半ばですが、⽬指すところ ● 重篤度の⽬利きでハッピー未然防⽌ ○ エンジニアもデザイナーもQAもどのような機能でハッピーがでるといけないかわかるので、意 識して開発／テストができる ○ PRレビューのときも「このPRの変更がCriticalなハッピーの可能性があるな！」ってわかる ● リスクベースドテストの達⼈になる ○ 重篤度が高くない機能はメインの動作だけ確認する、重篤度の高い機能に対して多くテストを 行うといった選択と集中でリソースの有効活用をする ○ 無駄にたくさんのリグレッションテストをしなくなる ○ 重篤度が高くなる機能から先にテストができるように開発をして、ハッピーがあれば直し、なけ れば安心できるのが早くなる もっと速く、 もっと⼿前で！

仮説定義 課題整理 設計 実装 テスト コード レビュー リリース 効果測定 振り返り QA テスト フィードバック フィードバック フィードバック フィードバック QAテストもフィード バックの⼀つ もっと速く、 もっと⼿前で！！ ありがとうございました！

No content