FE負債解消の取り組み〜Sentry監視運用とオンラインモブプロ〜

こんにちは。FEエンジニアの fujino です。
ポケットモンスター新作（ブリリアントダイヤモンド・シャイニングパール）は楽しまれましたか？
シロナさんミロカロスの強さは異常でしたね。勝てなくて暴れました。
来月発売のPokémon LEGENDS アルセウスも楽しみです！

FEチームの定期的な取り組み

先月のブログでFEチームの取り組みを紹介させていただきました。

こちらの記事で触れていた「負債解消」について、本記事では具体的な取り組みを紹介したいと思います。
テーマは大きく二つあり、「Sentry監視」と「オンラインモブプロ」です。

FE負債解消

私たちFEチームでは、毎週木曜日に3時間半使って負債解消に取り組んでいます。以下のような流れになります。

1. Sentryエラー確認と対応の決定（30分〜1時間）
2. 休憩（10分）
3. モブプロ対応タスクの決定（5分）
3. モブプロ開始（1時間ごとに10分休憩）
4. 振り返り（15分）

弊社ではFE/BEともにSentryによる監視を行なっています。
今年の初めにSentryの契約プランをBusinessに変更したことにより、メッセージごとの横断的フィルタリング等が可能になり、重要度の高いエラーの発見速度が以前より速くなりました。

Sentryで検知したエラーの中で対応が必要なものをモブプロで解決する運用にしています。また、Trelloにてカスタマーサポートチームから依頼が出ているタスクや既存バグもモブプロの題材としています。

次に、Sentryエラーを確認する時間で具体的に何を行なっているのかを説明します。

Sentry監視

Sentryで新規エラーを検知した際はSlackに通知が入る運用になっております。新規エラーに関しては毎日の朝会5分を使って、「対応不要・静観・要対応」の判断を下しています。

負債解消の時間では、各リポジトリにて1週間で発生したエラーTOP5を詳細まで確認する時間にしています。以下の流れになります。

1. SentryのDashboardを各々で確認（20分）
2. 確認内容を簡潔に共有、クリティカルなものがないか議論（10分〜30分）
3. 議論を元にフィルタリング対象を決定し、検知しない設定をする（5分）
4. 対応すべきエラーを洗い出す（5分）
→モブプロへ

確認作業
全員がリモート参加であるため、Slackのhuddle機能を使った状態で各々調査し、何かあれば誰かに話しかけたりしつつ確認作業をしています。

エラーの振り分け作業
今後も調査/対応が必要なものと、見る必要のないエラーを決定します。
負債解消の時間で確認するエラーは発生数が多いものになるため、この時間で解決する（修正対応する or 検知から外す）ことで全体のエラー検知数を大きく減らすことができます。

Sentry監視運用をやってどうなったか

日々の新規エラーを拾い上げる習慣ができた
これは負債解消の延長である「朝会の5分」によるものですが、日々通知されるエラーを拾い上げる習慣ができました。

エラーを一人で抱えるだけの無駄な時間が大幅に減った
「長時間調べたけどわからなかった」というエラーはよくあります。
これを解決するために全員が同時でSentryに向き合う時間を作り、時間制限を設けながら個人でタスクを持つようにしました。これにより、難しい内容はその場でメンバーに相談して方針を決められるようになったうえに、短時間で多くのエラーに対応できるようになりました。

頻発しやすいエラーを全員が認識するようになった
決まった時間にSentryエラーを確実に全員が見るようになったことで、ライブラリやブラウザ起因エラーの存在を把握できるようになりました。
「全員が知っている」というのは大事なポイントです。

それぞれの調査方法の共有がチームの知見となる
調査に詰まった時、知見あるメンバーが調査方法をリアルタイムで共有してくれるため、メンバー全員の調査スキル向上を見込めます。特にシニアメンバーの取り組みや思考を見聞きできるメリットは大きいです。

オンラインモブプログラミング

Sentry調査が終わると、次はモブプロの準備に入ります。
対応すべきSentryエラーやTrelloに上がっているタスクから題材を決定し、チーム分けを行います。（全員でひとつのタスクを行うことが多いです）

弊FEチームのモブプログラミング環境を紹介します。

モブプロ環境
・通話 / 画面共有：slack huddle
・アイディア共有：JIRA（※）
・実装環境：タイピストのローカル環境

※ miro を使っていた時期もありましたが、情報構造を整理したいケースに合わず変更しました

モブプロ実行環境の補足
通信状況が安定しないメンバーもいるので、以下サイクルで行います。

1. 最初のタイピストがモブプロ作業用ブランチ作成
2. 15分経ったら、その時点で作業を止めremote push
　実装内容が途中でも迷わずpush
3. 次のタイピストはremoteからpullし、画面共有、作業開始
4. 1〜3を繰り返す

モブプロルール
・意見を求められたら、まずわからないと言わないこと
・出てきた意見を否定から入らないこと
・タイピストは15分で必ず交代すること
・タイピストはモブの手足に徹し、自分で考えて実装しないこと
・TL相当の人間は極力タイピストにならないこと
・議論している中でゴールと関係ないものが出てきた場合、Todoに積んで後回しにすること

モブプロのメリットと最初に感じた課題

巷の記事でもモブプロのメリットはよく挙げられているかと思います。
弊社ではモブプロ経験のあるエンジニアからの提案と、モブプログラミング・ベストプラクティスという有名な本からTipsを取り入れつつ始めました。

ここは私個人の意見になりますが、自分の場合は「モブプロを布教されたnotシニアエンジニア」だったので、最初はメリットよりも申し訳なさを感じて取り組んでいました。というのも、難しいテーマの時にモブとして参加すると、全然意見が出せず、周りの知見を得るだけだったからです。
確かにチームのスキル底上げにはなるが、一人ひとり別で取り組む時間の方が有益ではないだろうか？と感じていました。

思ったことをそのまま相談してみると、
・モブの役割は指示をすることだけではない
・（本来はタイピストの役割だが）ゴールからズレた時に誘導したり、わからないところは素直に聞いて全員が今やっていることを理解できるよう発言することも大事
・タイピストがただ実装をしていて疑問が流れていくこともあるので、上記発言がそれを防ぐ効果もある

といった回答をいただき、気楽に取り組めるようになりました。
気楽に参加できるようになり、議論への参加やスムーズな実装を楽しめるようになりました。回数重ねることで慣れた部分もあると思いますが、シニアエンジニアが議論して設計を決定していく様子からは学びが多いです。

最初は申し訳なさばかり感じていましたが、回数を重ねることでモブプロには以下のようなメリットがあると感じるようになりました。

・ナレッジ共有、スキルの底上げに繋がる
・チーム感を持って取り組める
・コーディングのコミュニケーションが増える
・レビューに時間が取られない
・効率的な作業に便利なツール等を知るきっかけになる
・シニアエンジニアの設計思考を学べる

定期的なモブプロの実施により、最初のネガティブな印象から非常に楽しくて有意義な時間という印象に変わりました。

振り返りの時間

FE負債解消では、よく使われる振り返り手法のKPTではなく、
Fun / Done / Learn で振り返りを実施しています。

Fun / Done / Learn の効果か、すごく楽しそうですね！
（実際書き出す時もポジティブな気持ちでいっぱいです）
この回では初めてのTDDを経験したことが印象的ですね。

以上、FE負債解消の取り組み紹介でした！

最後に

まだまだ新メンバー募集しています！
最近新しいFE/BEメンバーも増えてより一層楽しいチームになりました🎉

一緒にワイワイ開発しましょう🙌