プロダクトやコード改善のためにチームでやっていることのご紹介

こんにちは。スタディサプリの Web エンジニアをやっている @ttokutake です。今日は、私の所属するチームがプロダクトやコードを改善するためにやっていることを簡単にご紹介したいと思います。

そもそもどんなチームなのか

私の所属するチームはプロダクトの Enhancement を担当しています。例えば、ユーザー登録画面で入力を勘違いしやすいようなわかりにくい部分があるので直すとか、 既存の機能で使いづらい・わかりにくい部分を改善していく ということをしています。実は「差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです」でも言及されているチームなので良かったらそちらも読んでみてください。軽く特徴をまとめると、 そこそこ広いドメインを担当しているため、急な差し込みや問い合わせ対応が多い 感じのチームです。

日々作業をこなすだけでは解決できないこと

プロダクトの改善はそもそもチームの使命なので、ロードマップを決めて作業をしています。しかし、それ以外にもやらなければならないことはたくさんあります。

急な差し込み対応
問い合わせ対応
エラーを発生させているバグの修正
コードをリファクタリング
必要なくなったコードの削除
その他いろいろ

当然ながら、すべてに対応する時間はないので優先度を考えて対応をしていますが、発生頻度の低いエラーやコードのリファクタリングなどはあと回しにされてしまうこともままあります。 Quipper は10年以上の歴史を持つ会社なので、あんまりメンテナンスされていない古いコードも存在します。

そんなこんなで積み重なってきた負の遺産も徐々に無視できなくなってきており、開発や調査のスピードを落とす要因となっています。

プロダクトやコードを改善するためにやっていること

それらの問題を少しずつでも解決するために、チームで実践していることをご紹介します。

エラー棚卸し

頻度: 1週間に1回
時間: 1時間
参加者: 基本的にはチーム全員

弊社ではエラーの監視に Sentry を利用しています。この場では、自分たちのチームが担当するサービス4つのエラーを確認していきます。例えばあるサービスのエラー一覧は以下のような感じです。

スクリーンショット 2021-04-20 22 50 35

これを1つ1つ確認していって、以下のように対応していきます。

すでに解決しているものは Resolve する
- 本当にやばいエラーが発生したら通常作業を中断して直しているので、この場では「直したね」と確認だけしています
シュッと直せそうであれば、その場でモブプロで修正
シュッと直せそうでなければ、直すためのタスクをバックログに積む
根本対応が明らかに難しそうなものは Ignore する

これをやることで普段起こっているエラーが整理されて、見覚えのないエラーを見かけると「妙だな...」みたいな感じで地味な異常に気づくことができたりします。

しかし、我々もすべてのエラーを棚卸しできてはいません。特にフロントエンドのエラーは手付かずの状態なので、これに関してはこれからどうしていくかを考えていく必要があります。

また別の解決していない問題があります。「直すためのタスクをバックログに積む」で積んだタスクです。これは次に紹介するイベントで直します。

QB Day

頻度: 2週間に1回
時間: ほぼ全日
参加者: 基本的にはチーム全員

QB は Quality Budget のことで、「通常の機能開発とは別でプロダクトの品質改善のために割く予算（＝工数）」という意味らしいです。私も今初めて知りました。何をしているかというと、エラー棚卸しで積んだタスクの消化とかリファクタリングとか必要ないコードの削除なんかをしています。私のチームではタスクの管理に ZenHub を利用していて、以下のようにいろいろなタスクが QB Day 用に積まれています。

スクリーンショット 2021-04-20 23 44 59

この場はあんまり優先度を考慮しておらず、メンバー各々がやりたいタスクに取り組みます。 1日の終わりには1時間くらい時間をとって、成果発表や振り返りもします。

以下にチームでやってきて、わかってきたことを上げます。

運用がだいぶ平和になった！
- あるサービスの1日当たりのエラー数は、去年の4月頃は100件程度あったのに対して、今年は10件程度まで減っています
  - (もちろん QB Day だけの成果ではありません)
- 開発や運用におけるトイルも着実に減っています
心が洗われる
全日取り組んでも終わらないようなタスクもあるため、ペアプロ・モブプロでの対応も検討すると良さそう

まだまだ改善の余地はあり、QB Day の運用方法は今現在もアップデート中です。

ここまででプロダクトやコードの改善に取り組んできましたが、チーム自体の運用を改善していくこともプロダクトやコードの改善には重要なことですので、そのためにチームで実施していることを次に紹介します。

お茶会

頻度: 1週間に1回
時間: 30分
参加者: 基本的にはチーム全員

これが何かというとチームで雑多なことを話す時間です。最初は「ランチ会」という名前でやってみたのですが、「食べているときにマイクをオフにするから意外と喋りづらい」という問題があり、ランチの時間を外して「お茶会」という名前になりました。

これを実施するようになった最初の目的は単純にチーム内の交流を促すためでした。私はコロナ禍に Quipper に入社したため、実は今でもチームのメンバーとオフラインで対面したことがありません。入社当初に「普通に雑談してみたいんですけど」とチームの Engineering Manager に相談してみたところ、お茶会をスケジュールしてもらえました。お茶会では以下のようなことを雑多に話したりしました。