はじめに
こんにちは。弁護士ドットコム株式会社エンジニアの@shinfkdです。 普段は社名と同じ弁護士ドットコムというサービスを運営する開発部で、部長をやっております。
本記事では、弁護士ドットコム事業における技術課題に対する取り組み、 Tech Focus Day(通称 TFD)についてご紹介します。
- はじめに
- Tech Focus Day(TFD)って何
- TFDをはじめた背景
- TFDの前身 Bug Fix Week
- TFDの誕生
- TFDの運用と変遷
- TFD Ver2.0 クエストボード制
- TFD の成果とまとめ
Tech Focus Day(TFD)って何
弁護士ドットコムでは現在、毎週金曜日を Tech Focus Day(以下 TFD) と称し、集中的に技術課題の対応をしています。TFD は Tech に Focus する Day、すなわち技術課題に集中して取り組む日という意味です。
普段のプロジェクトからは離れ、メインタスクとの関連性が薄いため優先度を上げづらい、けれども対応したほうが絶対に良いような課題の対応をしています。
TFD の活動の例としては、弁護士ドットコムのユニットテスト速度改善があります。具体的な活動内容を紹介していますので、よろしければ併せてご覧ください。
TFDをはじめた背景
多くの開発企業に共通することだと思いますが、日々開発業務を進めていくとどうしても技術的負債が貯まります。 弁護士ドットコムでもご多分に漏れず、さまざまな形で技術的負債・技術課題が存在しています。
そんな技術課題に対応するため、過去には大規模なアーキテクチャのリニューアルを試みたこともあります。また日常的にリファクタリングもしてきました。
しかし、大規模なリニューアルでは規模の大きさから当初の理想を妥協する形で実装せざるをえなかったり、日常的なリファクタリングでは、機能開発を優先するために優先度を上げづらいということが発生しがちです。
弁護士ドットコムでも、一部の課題が蓄積されたままとなってしまい、じわじわ苦しくなる状況がつづいていました。
そんな状況を打破するために、導入されたのが TFD になります。
TFDの前身 Bug Fix Week
そんな背景をもとに始まった TFD ですが、いきなり毎週金曜日に技術課題を対応し始めたわけではありません。 最初は、3 年前に実施した、アラート通知の改善を目的とする Bug Fix Week というものから始まりました。
3 年前の弁護士ドットコムでは、細かなバグが多く存在し、またアラート通知のしきい値をきちんと整理できていなかったことから、日常的に通知が多くされるという状況にありました。
通知が来てもその多くは実際には運用に問題がないもので、実際に緊急度の高いアラートが発生しても数の多さに埋もれ、緊急度の判断に支障をきたす状況です。
この状況を改善するために実施したのが、Bug Fix Week です。
ビジネスチームとの調整のもと 1 週間メイン開発を止め、エンジニア全員でバグの対応とエラー通知の改善をしました。 普段なかなか手を出せなかったバグ Fix に取り組み、ひたすら通知周りを改善するということで、多くのエンジニアがお祭り騒ぎ的に対応を進め、ある程度改善が進みました。 しかし、やはり 1 週間という期間内ですべてのバグを対応することは難しく、成果はあったもののさまざまな課題は残ったままでした。
とはいえこの Bug Fix Week をとおし得られた「まとまった時間をひたすら技術課題に使う」「エンジニア間でワイワイしながら改善を進める」という体験は非常に良いものでした。
またこの種の技術課題（バグのみならず、種々の技術的負債やアップデート作業、パフォーマンスチューニングなど）は、定常的に時間を確保し、対応することが重要であるという学びも得られました。
TFDの誕生
Bug Fix Week での学びから、定常的な技術課題対応の重要さと、エンジニア間で楽しみながら改善を進める体験の良さを認識した私たちは、これをなんとか仕組み化できないか考えました。
各チームが自律的に技術課題対応の時間を日常業務に組み込めれば良いのですが、すべてのチームでエンジニアがビジネスメンバーと交渉し、都度そういった時間を確保するのは大変です。
そこで、もう最初から「毎週この日はプロジェクトから離れて、技術課題のタスクのみ実施します」とビジネスメンバーと調整し、毎週金曜日はTFDということを事業部全体に周知、日常へ組み込むことにしました。
TFDの運用と変遷
そんな形で開始することになった TFD ですが、漫然と「技術課題の対応をしましょう」と言っても、何をしてよいのか、どう進めればよいのかわかりません。 走り始めとなる第 1 回は、下記のような運営方針でスタートしました。
- 事前にエンジニアリング・マネージャーで技術課題を整理し、いくつかテーマを絞っておく
- テーマごとに目標・ゴールを定める
- テーマ内容に沿って、最適と思われるメンバーをマネージャーがアサインする
- 対応方針やコミュニケーション設計は、各チームに裁量を委ねる
- まだリーダー経験の少ない若手メンバーを中心にリーダーポジションを任せ、経験を積んでもらう
- 四半期で期間を区切り、成果報告・振り返りを実施する
これらはうまくいった部分、あまりうまくいかなかった部分と両方ありましたが、おおむね想定通り機能しました。 そのため、細かな改善を加えつつも、3 年弱の間この方式で運営を続けることができました。
しかし、微調整では改善できないこと、また長年運営を続けることで起こる惰性感やマンネリ感も出てきてしまったため、昨年末に大きく方針を変更しました。
TFD Ver2.0 クエストボード制
運営を続けることで出てきた TFD の課題は下記です。
- 課題のテーマがトップダウンで決まってしまう
- 与えられたテーマがメインのプロジェクトと離れすぎてしまうことがある
- チーム編成がエンジニアリング・マネージャーによって決められてしまう
これらを改善するために、思い切りボトムアップ方式にしてみました。 それがクエストボード制です。
クエストボード制では、各メンバーが解決したい技術課題をクエストという形でボードに張り出してもらいます。
各自はボードを見て「このクエストを実施したい」という人で集まってもらい、受注をしてもらいます。 クエストにはそれぞれ達成条件まで記述されているので、それがクリアできたらクエスト終了。また次のクエストへという形で運営しています。
イメージ的には、ゲーム モンスターハンターのクエストです。
（そのため、みんなでやる必要がありそうな規模のクエストは「集会所クエ」。一人で対応できそうなものは「村クエ」などと呼んだりしています）
ただ、課題が全くないわけではありません。
例えば、各チームの終了時期の足並みが揃わないので、終わったところから次のクエストにいきます。すると、チームを組んで実施するということがやりづらくなり、ソロクエストが多くなってしまいました。 このあたりは近いうちに改善していく予定です。
TFD の成果とまとめ
こんな形で運営を続けてきた TFD ですが、この取り組みにより、多くの技術課題が解決・改善され、日常の開発体験も 3 年前に比べてかなり改善されました。
例としていくつか上げると下記になります。
- フロントエンドのパフォーマンス改善
- Google Tag Manager の整理
- CDN サービス移行
- 住所マスタデータ改善
- View 層開発方針の策定
他にも細かなものからやや規模感の大きいものまで、さまざまな改善を実施しました。
メンバーも手応えを感じており、節目、節目で実施しているメンバーからのフィードバックアンケートも、毎回おおむね好評です。
しかし何より良いのが、これがエンジニアだけに閉じたものではなく、事業部全体に浸透したということです。
他職種・他チームのメンバーに対しても「TFD で〜」と言ってもすんなり話が通じ、それに対する説明コストなどはほとんどありません。 また 2 年前からはデザイナーチームも「Design 課題を改善する日」として、Design Focus Day (DFD)を実施するようになりました。
こうした、技術やデザインが持つ中長期視点での課題に、一定の投資をし続ける必要があるということが周囲に理解され、継続可能になったことが TFD の一番の成果かもしれません。
