チームで事業推進と技術改善を両立していく話
この記事は Eureka Advent Calendar 2022 14日目の記事です。
こんにちは！Eureka で Back-end Engineer 兼なんでも屋をしてる emahiro です。
最近はW杯が原因でとても寝不足です。
今日も準決勝を見てしまいました…。
Overview
このエントリでは、プロダクト開発と並んでソフトウェアエンジニアの関心ごとの 1 つである「技術的な改善の取り組み(*1)」について Eureka の Back-end(*2) Team がどういうスタンスとアプローチで 1 年間 (実は１年以上前から) 取り組んできたのか？ということについて以下の3点を中心に簡単にご紹介させていただきます。
- 技術改善に対するスタンス。
- どうやって進めたか。
- 2022年やってみての振り返り。
また、本エントリで書かれる内容は、今年の夏に開催された勉強会にて私が登壇して発表した 資料 も合わせてご覧になっていただくとより Eureka の Back-end Team がどういった取り組みをしてきたのか？ということがわかるかと思いますので、是非目を通してみてください。
※1. Eureka ではメインの Back-end を支える技術について Go を採用しているので、具体的な進め方については Go を中心に記載します。
※2. 本エントリで取り扱う技術的な改善のフォーカスポイントは主に API, DB 周りの既存の技術的な負債と呼ばれる領域であり、 クラウドやクライアントの領域(Native App含む）については言及しません。
技術改善に対するスタンス
まず最初に Eureka Back-end Team として、Pairs の Back-end、主に API と DB, その他周辺のリソースについて支える技術領域の改善作業をどう進めていくのか？というスタンスについてですが、このスタンスは「事業を止めないこと」です。
Pairs のビジネスロジックは全て Back-end に集約しており、ありとあらゆる開発においては Back-end Team のリソースがなければ重要な機能やプロジェクトは進めるのが難しいです。
技術的な改善はもちろん進めるべきイシューではあるのですが、ここに Back-end Engineer のリソースを張ることで、本来進めなければならない事業を進めることができない、という状況に陥ってしまいます。
そのため技術的な改善作業には「事業推進に影響がないように進める」ということが求められます。
このような状況では通常、技術的な改善を進めるために、Back-end Team 以外の組織（ステークホルダー）への説明責任が必要になり、改善を進めたくても、すぐには進められないという状況にもなりかねません（事業と開発では関心事が異なるので、ある程度これは仕方のないことでもあります。）
ただ、Pairs は現状の Go のコードベースになってから 7 年以上経過しており、当時のベストプラクティスが時間を経て負債になっている箇所がいくつか有りました。これらをないがしろにしておくと、本来やりたいはずの事業推進そのものにも影響があるような負債（主に開発生産性に関する負債）があったので、改善作業も継続して進めていく必要がありました。
また、こういった技術改善系の作業は、1度始めると決めたなら、スピード感を持ってリズムよく進めないと、作業そのものが停滞する可能性があります。
改善作業を進めると決めても、同時並行で事業推進に関連するコードがコミットされている場合、延々と古い実装が残り続けることになります。
もちろん状況によってそれをしないといけない場合もありますが、ある程度改善作業を仕組み化し、極力新しい実装を使ってプロダクトの開発を行ってもらわないことには負債化してる状況はなかなか変わりません。
そして、改善作業に対するモチベーションはチームメンバーそれぞれで異なることがしばしば発生し、一部のメンバーに作業が集中、属人性が発生してしまうこともあります。現実的なリスクとして、モチベーションの差が進行を遅らせたり継続を断念させる1つの要因にもなりえます。
Eureka の Back-end Team としては、こういった状況に陥らないようにする（ = 極力ステークホルダーを自チーム、及び近しい関連組織* に制限し、アジリティ高く改善作業をメンバー全員で進める）というアプローチを取って改善作業を進めてきました。
※ 具体的には開発チームを取りまとめている CTO の kaneshin san とインフラ領域を担当している SRE チームには、いくつかの改善作業について事前に共有してから進めています。
どうやって進めたか
次に具体的に私達がどのように進めたのか、ということについて記載します。
専門チームの組成
Eureka の Back-end Team は実は2つの小チームに分かれており、本エントリで題材にしてる技術改善を専門に担うチーム(通称: Under the hood、以下 UTH *1) があります。これは今年だけでなく一昨年から作られた役割で、流行り言葉でいうと Enabling Team みたいなものになります。
この UTH では改善作業として何を進めるべきかを議論したり、それに関するツールセットの用意や、そもそも作業のタスク管理、実装プラクティスの用意やペアプロなど、事業推進に関連しない改善系の作業をメインで行っています。
※1. UTH のメンバー全員がプロジェクトに関する開発に一切関わらないのではなく、一部のメンバーはプロジェクトチームの開発作業も担当しています（役割が一部オーバーライドしています）
事業推進の妨げにならない粒度に改善に関するタスクを分解
そもそものスタンスが「事業を止めない」ことなので、このスタンスを堅持し、持続的な改善に繋げるために、何をやるか？どうやるか？を決めたら、どうやるかの部分で、サンプル実装を用意し、作業内容を Go の package 単位という細かい粒度で issue 化し、Back-end Team 全体にアサインして各自のタイミングで進めてもらえるようにしました。
大きな粒度にするとまとまって時間を取らなければならない事が多いですが、package 単位まで粒度を深掘ってあると、細切れの時間を使って改善作業を進めてもらうことができ、タイミングをメンバー個々人に一任することができるので、事業推進を止めることなく改善作業を進めることができます。
分解したタスクの可視化
上記の分解したタスクを全て GitHub の Kanban を使って管理しました。
ちょうどこのタスク管理を始めたタイミング (2021年時点）で GitHub の新しい Issue の Feature が GA になったので、この機能を最初から利用して改善項目全体の List や Kanban の View を作ったり、Back-end Team に依頼された作業や不具合修正項目の管理 View を作って運用を開始しました。
機械にできることは機械に任せる
また、この作業にあたって、 Eureka なりに工夫したポイントは、「どこを修正すべきかを警告」してくれる独自 Analyzer を daisuzu san に実装してもらい、gopls に組み込み、古い実装等を使ってる箇所があると Editor レベルで開発中にすぐに分かるようになったところだと思っています。
個人的にもこの自前の Analyzer を gopls に組み込むという方針を選択をして頂いたことで、 language server protocol に対応してる Editor であれば、どのツールを使うかを問わず動作する環境を用意できたことが、改善作業をより効率的にしてくれた1つの要因だと考えています。
機械にできることは、積極的に機械に任せていくアプローチの方法としてこういった標準規格に則った独自ツールを作っていくことの効果を実感した事例でした。
詳細は以下のエントリに記載してあります。
チーム内での優先順位の合意
ツールセットや仕組みの用意と合わせて、改善作業にもチームで取り組むことの合意を取りました。
基本的には事業推進と並行してやっていく、という前提をもとにプロジェクトに関するタスクがある場合はそちらを優先してもらって構わない、といういった感じである程度緩さを担保した合意をして、とりあえず走らせています。この場合あくまで改善作業に積まれたタスク類は各メンバーに進捗は一任する、という方針で、定期的な状況なアップデートを受けて調整するような運用に現在してます。
知識共有の場を作る
改善チームのMTGをOpenDoor 化
UTH は週一で定例を持っておりますが、これを Open Door 化して Back-end Team に限らず参加できるようにしました。
MTG では改善作業の進捗や今課題に思ってることを話し合う場でもあったのですが、ROM ってもらうだけでもその課題感の共有できましたし、そもそもこの手の改善作業に興味のあるメンバーも出てきたので、作業を少し手伝ってもらったりと、じわじわ仲間を増やしていきました。
GitHub Discussions での改善作業の提案
GitHub の Discussions を使って、やりたいことや Pairs のコードベースに対する提案を受け付けて日々議論しながら、改善の方向性を検討・決定するようにしました。
チームのMTGやコードレビューのタイミングで実装方針や、細かいところだと Go の書き方レベルの話まで、気になった所があれば頻繁に Discussions に起票してもらってカジュアルに議論したり、調査の進捗を管理しました。
実は作業内容や作業に関わるログはもともとJIRAで管理していたのですが、GitHub の方が コードを展開できたり、Repository や Pull Request を自動で参照、展開してくれて、Issue を管理し易かったりとメリットが大きかったので、改善作業の Kanban を作るときに一思いに JIRA => GitHub に移行しました。
Coding Guideline の作成
これは最近作ったのですが、ある程度コードの入れ替え作業を進める過程で Good/Bad パターンが見えてきたので、暗黙知となっていた Pairs の中での Go のコードのパターンのガイドラインを作成し、形式知としてチームの資産に変換しました。
Go 勉強会
毎週定例の Go に関するチーム勉強会です。
Go のトピックについて話すのが主だった活動ではありますが、改善作業についてのプラクティスの探索等を行ったり、特にオンボーディングの一環として、新しく Eureka に入社された Back-end Team ＆ SRE Team のメンバーを中心に Pairs 内の Go のコードの読み方講座みたいなものを開いて、最初からある程度のパターンをシェアするようにしました。
自分自身振り返ってみても、入社当初はどこに何が書いてあるのか、Repository の探索方法もさっぱりわからない状態であることが多いと思うので、このオンボの一環としての Pairs のコードリーディングは続けててよかったと思うポイントです。
ペアプログラミング・有識者へのヒアリング
一部ですが、ペアプロや改善作業を進めるにあたって、知見を持ってる人へのヒアリングを気軽に行えるようにしました。
チーム内でも Go に造詣が深い daisuzu san や jimeux san から Go についてのフィードバック受けながらコードを書いたり、package 単位で細分化されたタスクを行うときに、作業者が知らない package だった場合、実装者やその package を実装したときに在籍したメンバーにヒアリングをする時間をチームのデイリーMTGのときに取っています。
特に後者については、作業者自身が知らないドメインの package を触るときに、実装後何を検証すればいいかわからないと、そもそも作業に取り掛かるのに遅れたり、作業が終わってもデグレる可能性は否定できず、ある程度事前に影響範囲を絞り込んだ上で作業を開始するようにして、作業そのものへの心理的な負担や実際の検証作業の負担を軽減しました。
ここで紹介したこと以外にもありますが、大まかにまとめると「専門チームを中心にして、GitHub をフル活用し、知識共有や合意の時間をちゃんと取って、持続可能な仕組みで回す」ということをしてきました。
1 年やってみての振り返り
2022 年は（というか2022年も）引き続き事業推進と技術改善を両立し、させた Back-end Team だったと思います。
事業推進に関して言うと、例えば Pairs は今年、プロダクトとしての大きなアップデートをいくつか出しています。
グループトーク(GW にβ版、夏に正式リリース）
Pairs コンシェルジュ・コミットメンバーシップ（秋にリリース）
トークトゥデート（今週リリース！）
これらの大きなプロジェクトに推進にあたって、開発を支えた Back-end Team のメンバーはそれぞれ担当したプロジェクトのタスクもこなしながら、並行して一定程度改善作業に時間を割き、古い実装を極力使わずに実装したり、新機能の開発前にリファクタリングや負債返済作業を行ってからプロジェクトに関わる開発を行ったりしていました。
こういった技術改善の取り組みについては事業推進と並行するのが難しく、まずは作って、あとで改善の時間をもらう、というアプローチもありますが、あとになってその時間が取ってもらえるかどうかも不確実であることが往々にしてあります。事業状況は往々にして変化しますし、そういった変化に柔軟に対応できる開発チームの方がプロダクトにとってもより良い影響を与えることができるとも考えています。
Eureka の Back-end Team では事業推進を大事にしているので、時間をもらえることを当てにせず、日々の開発作業と並行して持続的に改善作業を進めていく道を選びました。
昨年に引き続きにはなりますが、特にこの 1 年間に関しては新しいメンバーのジョインしたり、育休から復帰したメンバーがいたり、多様性が増したチームになったにも変わらず、これら活動を継続できています。
次の１年もこのスタンスとアプローチは継続しつつ、事業をやりながら Pairs という大きなプロダクトを支える技術改善をして行きたいなと考えています！
最後になりますが、こういった改善作業について、色んなチームのお話を伺いたいなと思っているので、もし壁打ち相手になってくださる方がおりましたら気軽に Twitter で DM いただけると嬉しいです。
明日も Advent Calendar の記事もお楽しみに！
