こんにちは、freeeでQAエンジニアをやっている西出(@ichikoich)です。freeeのQAエンジニアは、E2Eテストを作ったり、ドメインスペシャリストを巻き込む仕組みを作ったり、手動テストのアウトソースをしたり、品質に関する様々なことをしています。
その中でも今回は、不具合の見える化にフォーカスして話します。freeeでは不具合のことを「ハッピー」と呼んでいます。（ハッピーと呼ばれている背景）
難しい運用
今までもハッピーの見える化にはトライしていたのですが、いろいろな問題がありました。
freeeでは長年、不具合報告に関するサポート⇄エンジニア間のコミュニケーションやタスク管理をAsanaのタスクとして起票することで運用していました。この運用をはじめた当時のAsanaには、タスクに「対応中」や「デプロイ待ち」というような「ステータス」を表現できるフィールドがなかっため、「すぐ対応する」「あとでやる」のような「優先度」と同じフィールドで「ステータス」を管理していました。
<Asanaの画面例>
例えば、「すぐ対応する」に振り分けられているタスクを、エンジニアが修正に取りかかるときには、「開発者対応中」ステータスに変更します。ところが、それをすると、優先度の情報が消えてしまいます。逆もしかりで、優先度をつけると、ステータスの情報が消えてしまいます。
温かみのある見える化
Asana上の不具合の報告数や消化数の見える化は、Googleスプレッドシートで運用していました。最初はシンプルで、Google App ScriptでAsanaのAPIを叩いて調理するだけでしたが、エンジニアやサポートの運用が変わるたびに、集計が複雑になってしまい、いつの間にか集計するのに1ヶ月にトータル30時間ほどの手作業が発生するようになっていました。
もちろん、ステータスや優先度の情報がよく消えるため、集計した結果も正しいとは限りませんでした。
品質トゥギャザーの誕生
そこで、思い切って、仕組みを変えて定量的に品質改善を測定できるようにしました。この取組みを品質トゥギャザーと呼んでいます。品質を良くしていくためには、みんなでやっていくのが一番ということで、印象づけのためにトゥギャザーと連呼していくことにしました。
JIRAとembulkとRedshiftとRedashをトゥギャザー
まず、より正しく情報を扱うために、AsanaからJIRAへ移行しました。チケットのステータスと優先度が別々のフィールドであるのはもちろんですが、それ以上に柔軟にカスタマイズができることがJIRAへ移行した理由です。これまでビジネスや組織の成長により、集めたい、見たい情報やその運用が変わっていくことを経験してきたので、柔軟にカスタムフィールドを追加したり、ワークフローをシステム上で定義できることが魅力的でした。また、バグトラッキングツールとしてマジョリティなので、他サービスとの連携プラグインが豊富にあるところにも将来性を感じました。
次に、集めた情報を調理しやすいように、スプレッドシート × Google App Script からRedshift × Redash に切り替えました。データの調理がしやすいように、会社の中の様々な情報をできるだけひとつのデータウェアハウス（freeeではRedshiftを採用）に蓄積させていきたいので、デイリーでJIRAの全チケットをAPI経由で取得し、Redshiftに保存しています。毎日作られるチケットはそれなりの量になりますが、バルク処理に特化したembulkを採用することで簡単に実現することができました。treasure-data/embulk-input-jira というJIRA用のインプットプラグインを使っています。
あとは、Redash上で集計用のSQLを書いておけば、グラフや表などの見える化されたものが日次で更新されるので、コストほぼ０で最新の集計結果を見ることができるようになりました。
RedshiftやRedashなどの仕組みは既にfreeeが誇るすごいデータ基盤エンジニア(@krt)が構築していたので、ただそこに乗っかるだけでした。あっ、すみません、トゥギャザーですね。
freeeのデータ分析基盤について speakerdeck.com
ビジネスチームもトゥギャザー
社内の誰もが簡単にハッピーを起票できるように、JIRAに直接起票するのではなく、質問形式のGoogleフォームに用意しました。起票される内容に不具合の内容や発生条件などの対応に必要な情報の漏れがないようにするためです。Asanaの時も一部の製品に関してはGoogleフォーム経由での起票を試しており、これが好評だったのでJIRA移行を機に全製品のハッピー起票をGoogleフォームにしました。
実は、JIRA移行する時に一番苦労した点はハッピー運用フローの構築でした。Asanaでは、運用自体が複雑だった上に、エンジニアと他チームの責務分担や優先度の認識が明確ではありませんでした。そこで、各チームの関係者と一緒に話をして下記のような運用を明確にして、そこからフローを改善していくことにしました。明確なベースがないと改善していくことはできないので、大きな一歩だと思います。
エンジニアもトゥギャザー
freeeのエンジニアはローテーションでハッピーの対応を担当しています。この対応エンジニアたちをハッピーピーポーと呼びます。ハッピーピーポーは毎朝集まってハッピー朝会をします。ハッピー朝会ではハッピーピーポーたちが物理的に集まって２つのことをやります。
- 新しく起票されたハッピーの優先度振り分けと一次回答
- ハッピーのアサイン
これをみんなでやることで、ハッピーによるユーザのインパクトや、解決までにどれくらいの時間がかかりそうかが共有されるのを期待しています。始めた頃はみんなでやるのは高コストかなと思っていましたが、やっていくと今まで知らなかったことをたくさんインプットできるので、しばらく続けていきたいなと思っています。
簡単にハッピー消化のパフォーマンスが見られるようになったため、ハッピーピーポーを増やさなければまずいのか、逆に減らしても大丈夫なのかといったこともアラートしやすくなりました。
おわり
品質の可視化を話そうと思ったら、トゥギャザーの話ばかりになってしまいました(｢・ω・)｢
