サービスのバグで悩んでいる人必見！BugBashしようぜ！
この記事はエイチーム引越し侍 / エイチームコネクト Advent Calendar 201925日目の記事です。
メリークリスマス
僕にとって29回目のクリスマスが来ました！新卒6年目で現在は株式会社エイチーム引越し侍で技術開発部のマネージャーをやっているざきです！
最近の趣味は、**インスタグラム**で映える写真を取りに色々なところへいくことを楽しみに生きています。
今回は、様々な組織が課題として抱えるであろう、バグ・不具合についてどう向き合っていくか（退治していっているか）の話を書いていきます。
安心して年を越していきたいですね！
やるまでの経緯
私は株式会社エイチーム引越し侍で主に引越し比較・予約サイトを運営しております。
更に、今年はWils（求人サイト）やまるごとスイッチ（引越し時の面倒な手続きをかんたん＆お得にできるサービス）をリリースし、新規サービスの創出、既存サービスの成長をさせおります。
その中で、新規サービスを作ったり、既存サービスを大きくしていつたりするとバグや不具合の類が出てきてしまうのは仕方がないことです。。
いくら設計やコーディング、インフラ構成をうまくやったとしても、サービスとバグは切り離せないぐらい親密なものだと思います。
実は、11月と12月で軽度なバグや大きなバグを含めて結構発生した月でした。
（正直、このバグ対応にはみんな疲弊していたと思います）
その中でとあるメンバーとの1on1で最近多いバグに対して話し合いをしている中でこういうのやっている会社があるよと紹介されたことがきっかけでした。
『B1グランプリ(Bug Bash)』を2時間やって細かいIssueを洗い出しました-Kyashさんのブログ-
これをみた瞬間、お！これうちでもやれればいいじゃん！と思い、善は急げということで、どうやってエイチーム引越し侍にあった形で開催していくかという考えで動きました。
バグに対して私が考える大事なことは以下の3点です。
- いかにバグを少なくするのか
- いかにバグを見つけていくか
- いかに早く対応をするのか
今回は、少なくするための構成や設計、コーディングの話ではなく、バグを見つけて対応する方法をちょっとイベントみたいな形にして対応した話をしておきます。
目的定義
前置きが長くなりましたが、BugBash（バグバッシュ）を行う目的を定義しました。
エンジニアとして事業に貢献できることの一つとして事業運営に影響するようなバグ、不具合を減らしていく
バグや不具合によって、サービスの停止や機会損失等により、売上利益が減ります。
その意識をエンジニアもしっかりと持つべき。
そして、バグや不具合を減らすための動きの一つとしてBugBashを行うことで、減らせるのではないかと定義しました。
実施までの準備
今回はせっかくだから全員でバグに対して向き合って行動しようと考えたので、技術開発部に属している全エンジニアを巻き込んでやろうと考えました。
そのため、全エンジニアが1日かけて対応するので、既存の開発業務は必ずストップします。
やはりここで大事になってくることは、各所への説明です。
- 経営陣
- 各部署の責任者（リーダークラスの人）
- 自部署のメンバー
ここはちゃんとおさえて説明しておきましょう。
また、説明するときも準備をしっかりしておきましょう。
対経営陣や対部署の責任者（リーダークラスの人）にする場合は、なぜを意識して背景、目的、費用対効果、やることを話していきます。
特に具体的にやるやり方等は話さなくてもいいと思います。（話が細かくなってしまうので・・）
聞かれたときに話せる準備だけはしておきましょう。
メンバーへ共有するときも上記に合わせて、ルールや当日のスケジュール、チーム構成、やり方を細かく説明していきます。
また、これを行うことでエンジニアとしてしっかりと事業に貢献するんだよという思いを伝えていきます。
当日の内容
ルール
- バグ発見PTと解決PTの合計PTでバグ王が決まります（バグ王というネーミングは不評
） - バグ発見時は共有を兼ねて共有シートに記載してもらい、早く見つけたところ勝ちです
- バグや改善系であれば記載OK
- リファクタリングもOKですが今回の趣旨とは少しズレるのでPT付与はなしとします（お掃除大会はまた別日に）
- 開発完了したらエンジニア側でコードレビューとテストを行い、マージリクエストの状態で置いて次の日に必要があれば事業部側にテストしてもらいリリース
- 基本的に全サービスが対象
- チームで話し合い、協力しつつ進めていくこと
- 他のチームが発見したバグを解決させていくこともOK、ただしステータスは変えてもらう
- ステータスが解決したものがPT付与の対象
- PTは1~3の間で付与、簡単に見つけれそうなバグは1PT、インパクトがおおきいものはさじ加減で2PT or 3PT
バグ共有方法
エイチーム引越し侍では、ChatWorkを利用しているため、普段使っている部屋ではなく新しくBugBash用の部屋を作成して全員招待しました。
そこで、見つけたバグや対応したバグ、なにか質問があれば投稿といったようにBugBashに関係する共有が必要そうなことをどんどんつぶやく形式で行いました。
また、全員が現状のバグを見つけるor対応する際に、重複してしまったらよくないので、GoogleSpreadSheetに全員書くようようしました。
GoogleSpreadSheetのヘッダー
- 対象サービス
- 内容（バグの発生条件を細かく書いてください）
- 対応チーム
- ステータス（未対応、対応中、解決、リリース済み）
- タスクURL
- マージリクエストURL
- 備考
しっかりと全員で共有できる環境をつくることを意識しましょう。
※ ホワイトボードに現状の点数とか書き込んでもよかったとあとから思いました
チーム分け
エイチーム引越し侍の技術開発部は役職者含めて社員が15名います。
15名いるので、普段関わる（触る）サービスが別れており、各自開発の得意不得意のサービスがあります。
普段、同じサービスを触らなさそうな人とチームを組んだら学びも多いかなということでバラバラにしました。
各チーム3名、合計5チームで行いました。
- Perfume
バグに対する嗅覚が強いチームという意味があるみたいです - 大自然 @僕が入ったチーム
3名の名前に自然に由来する漢字が入っていたからという - 練馬THEハッカー
すごいハッカー集団という意味があるみたいです - バリウムパワー
当日、人間ドックでバリウムを飲んだ人がいたのでそこから由来しました - チーム阿部
猫の阿部というキャラクターが好きなチームです
スケジュール
| 時間 | 内容 |
|---|---|
| 10:15 ~ 10:30 | ルールの確認 |
| 10:30 ~ 12:30 | バグ探し |
| 12:30 ~ 13:30 | チームでお昼ごはん |
| 13:30 ~ 18:30 | バグ潰し |
| 18:30 ~ 19:00 | 結果共有 |
| 19:00 ~ 20:30 | ビアバッシュ＠食堂（任意参加） |
余談ですが、エイチーム引越し侍の食堂は夜はバーにもなるので、お酒 飲めます！ |
結果
約100個ほど（BugBash以前に見つかっていたバグも含め）見つかり、約40個ほど修正ができました！
皆さん、お疲れ様でした！
振り返り
全員から集めたKPTを実施し、出てきたものを抜粋して紹介します。
本当に一部です！KPTそれぞれでめちゃくちゃ出てきました！（みんなに感謝
）
Keep
- どこかに集まってやる、というスタイルはやはりそのタスクに集中しやすい
- 様々なプロジェクトを触れて理解が深まった
- チーム分担するので周りの人にアドバイスをもらえるのはよかった
- ゲーム感覚で楽しみながらコードを書くことができた
- じっくりエラーと向き合えたのは良かった
- 定期的にやりたい(少人数持ち回りでもいいから)
- 普段と違うメンバーで協力し合って進めることができたこと
- そのあとの飲み会
Problem
- ポイント稼ぎのために、重要なものよりすぐ終わる方を優先させてしまう
- 様々なプロジェクトを触ることができる反面、環境構築などに時間がかかってしまう部分はもったいなかった。事前にこの辺りを準備しておけるとスムーズになる
- チーム内で別々のプロジェクトを触っていてあまり議論が生まれなかった
- クリティカルなものが発見されなかった
- ポイントがなぁなあな感じ
- しんみりしてるので音楽流れているとあがる
- 正しい仕様がエンジニアだけで判断できない箇所があった
- コードレビュー地獄
- 途中経過が知りたい
- 不具合をどう変更すべきか、事業部の人と詰める時間がない
Try
- 大変さだけでなく、重要さにポイントを上げたほうがよかった
- 事前に環境は作っておこう
- テーマ（サービス｜EFO）をもっと絞っても良かったかも
- 量を見つけたほうが有利なので、じっくり検証する時間がない
- もっと事前に決めておく
- Amazon Echoとかで音楽流す
- テストを書いておく
- 消すだけのやつとかはチーム内でできるのでは
- 点数見える化
- 発見する回と解消する回は別でもいいかも
KPTの考察と今後について
こう見てみると、ゲーム性を入れてしまったが故に重たいバグ（売上利益インパクトはありそうだけど、対応時間はかかりそう）というものがなかなか着手されなかったなと思います。
ただし、Tryにも書いてますが、ポイントの付け方を工夫すればこういった問題も解決できたかと思います。
今回は第一回目だったので、今回あがったKeepは更によくしていく工夫、ProblemについてはTryを参考にしつつ改善していく動きを行い、定期的に行えればいいかなと思いました。
結果としてバグを潰せたことや、チーム全員が同じ空間で一緒に同じ目標に向かって取り組んだことはとても良かったなと感じます。
まとめ
エンジニアとしてバグをしっかりと潰していくことは、事業に対して向き合う一つの動きだと思います。
ただし、今回のようにエンジニア全員が1日かけてバグを潰す動きをすること自体は必ず、経営者、事業部の人たちの理解が必須となります。
しっかりとやる目的をもって、事前準備をしっかりとしてやっていけば、より有意義な時間を過ごすことができるなと思いました。
実施する際に特に大事だったこととしてはやはり下記の5点かなと思いました！
- 経営陣に対してやることの意義を説明
- 事業部の人たちの理解をしてもらうための説明
- メンバーへの詳細説明
- 当日のための準備
- 当日楽しむこと！
この記事を読んで、もっと詳しく知りたい、自分のチーム（会社）でもやってみたいなと思ってもらえれば幸いです！
お知らせ
エイチームグループでは一緒に活躍してくれる優秀な人材を募集中です。
興味のある方はぜひともエイチームグループ採用ページ（Webエンジニア詳細ページ）よりお問い合わせ下さい。
イベントを振り返って
これで2019年のアドベントカレンダー25日間が終了です！
参加したみなさんお疲れ様でした！
Qiitaアドベントカレンダーは2016年から行っていて、4回目の参加でした。
エイチーム引越し侍/エイチームコネクトでは、今年はいいね数の多い人に豪華ディナー招待、全員で投票してエイチーム引越し侍/エイチームコネクトにとってよい記事に技術賞ということで豪華ガジェットプレゼントというようにゲーム性をもってアドベントカレンダーを書いてます！
是非、会社のことに興味をもったら**QiitaJobsに気になる**をどうぞ！