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

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

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

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

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

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

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

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

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

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

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

エラー棚卸し

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

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

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

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

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

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

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

QB Day

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

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

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

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

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

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

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

お茶会

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

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

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

• 各メンバーの自己紹介を深掘り
• 今住んでいる場所
  • 地図見ながらやると想像以上に盛り上がります
• ふるさと納税
• ボードゲーム
• ハンターハンター
  • ヒソカ・団長戦の考察など

その後、無事チームに慣れることはできたので、私個人としての当初の目的は達成されました。 しかし、お茶会は今でも継続して続けています。 その理由は チームにちょっとしたことを相談する場 としても活躍しているからです。 例えば以下のような内容も話したりしています。

• コードレビュー時の基準を整えたい
  • コード品質についての考え方にメンバー間で差異があるため
• フィードバックの 4A*1 を実践できそうか
• ペアプロもっと増やしていきたい
• CSS 辛い

こんな感じで仕事に関係する話をすることもあり、実際にチームの運用改善に繋がるようなケースもあります。 今ではオフィスで作業をする人も減っていて、雑談をする機会も減ってきているため、 こういった機会をスケジュールとして組んでみるのはとてもおすすめです。

最後に

プロダクトやコードの改善のために、チームが実践していることを紹介しました。 他にもいろいろやっていますが、社内の他チームや他社の方にお話ししたときに、特に評判が良かったものを挙げさせてもらいました。

こういった地道な活動を今後もチームみんなで続けていって、プロダクトやコードを改善していければと思っています。 興味がある方はカジュアル面談などもやってますので、ぜひお気軽にお声がけください。

Quipper では 世界の果てまで学びを届けたい仲間を募集 しています。

*1:フィードバックの 4A とは Netflix 社が実践しているフィードバックのためのガイドラインです。