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