こんにちは。技術本部 Bill One Engineering Unit の向井です。Bill One では請求書受領領域のグループ TL として開発に関わっています。

Bill One は急速にサービス規模を拡大してきたこともあり、開発生産性の維持と向上が課題になっています。その課題への取り組みとして運用している技術バックログという仕組みについてご紹介します。

なお、この記事は【Bill One 開発 Unit ブログリレー】という連載記事のひとつです。

背景

Bill One は開発組織の急拡大にともない、開発生産性を維持・向上していくことの重要性が高まっています。また、システムアーキテクチャも機能が拡充されていき、構成要素が増加したことで課題の複雑性や規模も大きくなる傾向にあります。

各開発チームに対して負債の解消としてのリアーキテクティングやリファクタリングを実施する裁量は与えられているものの、複雑であったり規模の大きかったりする課題に対してなかなか取り組めずにいました。また、技術課題に対する方針も、組織が大きくなる中で各チームが裁量を持って判断していくことと、サービス全体として最適化していくことのバランスが取りにくく、課題となっていました。

そこで、技術バックログという仕組みをつくり、Bill One 開発組織全体として技術課題に向き合っている取り組みをご紹介します。

技術課題に向き合う体制

Bill One には各開発チームにATL（アジャイルチームリード）と PdL（プロダクトリード）、TL（テクニカルリード）の 3 つのロールがあります。そのうちの TL を中心として技術課題に向き合っています。Bill One において技術面をリードするロールは TL を含めて次のような体制になっており、これら 3 つのロールをまとめて「 TL 体制」と表記します。また、区別しやすいようこの記事では各チームの TL を「チーム TL 」と表記します。

	役割
チーム TL	チーム内の技術面における相談役や、担当領域のコード品質向上を担う。
グループ TL	機能領域（グループ）におけるチーム TL の相談役や、機能領域における技術的な意思決定を担う。
アーキテクト	グループ TL の相談役や、サービス全体に影響する技術的な意思決定を担う。

Bill One 開発組織におけるロールの詳細については下記の記事をご覧ください。

buildersbox.corp-sansan.com

技術バックログの定義

技術バックログとは、Bill One における技術課題として、技術的負債の解消や技術観点のチャレンジを扱うバックログです。プロダクトバックログとは別で管理されており、エンジニア主体で運用しています。技術バックログへの起票はエンジニア全員ができるものとしています。この技術バックログは下記の要素を満たすことで、前述の背景にある課題を解消するためのものとしてつくられています。

技術面での課題を集約する
技術課題の状況を可視化する
技術課題間の優先度を管理する

技術課題には大きく 2 種類があります。

実装によって解決できるもの（リファクタリングやアーキテクチャ変更）
ディスカッションによって解決できるもの（方針やルール整備）

技術バックログでは、この中でも実装によって解決できるもののみを扱います。事前に工数を見積もることで、技術課題の解決を推進しやすくするためです。ディスカッションによって解決できるものは必要になったタイミングでスピード感をもって判断していきたいという意図から、技術バックログで扱わないこととしています。

技術バックログの運用

技術バックログは TL 体制を中心に運用しており、具体的には下記の流れで進めています。

技術バックログへの起票
リファインメントの実施
プランニングの実施
技術バックログアイテムの対応

1. 技術バックログへの起票

技術バックログへは Bill One のエンジニアであれば誰でも起票できます。ただし、後述のリファインメントをするにあたって詳しい情報が必要になるため、起票した人には主体的に関わってもらうか、その人が所属するチームのチーム TL がフォローできるようにしてもらっています。

起票するには下記の 4 項目を記入します。起票時点で完全なものを書く必要はなく、以降に実施するリファインメントで詳細な議論をするための情報を用意することが目的です。

課題のタイトル
課題の概要
達成したい状況
方針 / 解決方法

具体的に作成されているものは、下記のイメージです。

2. リファインメントの実施

大きくグループ単位と開発組織全体の 2 つのステップでリファインメントを実施しています。

現在、Bill One 開発組織は 3 つのグループに分かれており、各グループに所属しているチーム TL で起票した内容に対してリファインメントを実施します。このリファインメントでは起票した課題に対する情報を収集したり、状況を整理したりすることで、解決の方向性を模索します。グループ内でリファインメントを実施するのは、グループに所属する少人数のメンバーでディスカッションすることで現場の肌感覚を反映した実現可能性と効果のバランスをとった方針を模索することを目的としています。

開発組織全体としてはアーキテクトとグループ TL でグループでリファインメントされた内容をもとに対応方針を確定させ、対応にかかる方針と工数のサイズ感、優先度を決定します。グループ TL はグループ内でディスカッションした背景を把握し、この判断の精度を高めることができるように動きます。また、このメンバーで判断をしているのは、技術的な意思決定が可能なメンバーでスピード感を持って進めるためです。

3. プランニングの実施

リファインメントと同様に、大きくグループ単位と開発組織全体の 2 つのステップでプランニングを実施しています。

開発組織全体としてのプランニングは、技術バックログの進捗確認と担当を決めるために TL 体制全員で定期的に集まるイベントとして設定しています。担当はグループ単位までを決めており、グループ内での進め方は各グループの判断に任せています。また、リファインメントで開発規模が小さいと判定されたもののうち、優先度があまり高くないものについてはあえて担当を決めないことで、手が空いたチームや新しく参画したメンバーが自発的に対応できるようにしています。

グループ単位のプランニングでは、グループに割り当てられた課題をチーム TL で分担や進め方を検討します。組織全体のプランニングでは拾いきれない進捗における課題を扱うことで、進捗をサポートします。

4. 技術バックログアイテムの対応

対応を推進する上で発生した課題についてはグループに所属するチーム TL やグループ TL がフォローする体制をとっています。例えば、リファインメントを通じて方針は明確にしているものの、対応を進める中で課題が見つかって、対応判断を要することもあるかと思います。こういった場合は、チーム TL 同士でディスカッションしたり、課題を再整理したりすることで、グループとして解決に導いています。

また、プロダクトバックログの開発に時間を取られて、技術バックログの対応時間を確保することが難しい場合もあります。こういった場合は、グループ内で担当者を調整したり、タスクを細分化して対応するメンバーを増やしたりして解決しています。

今後について

この技術バックログの体制をしばらく運用して、いくつかの成果が出ています。特にインパクトの大きかった成果の一部をご紹介します。

Cloud Tasks を使っていた処理を Cloud Pub/Sub に移行するにあたり、Cloud Pub/Sub で安全に運用するための仕組みを構築した
複数のマイクロサービスでコア機能として利用しているライブラリの破壊的変更を含むバージョンアップに対応した

その他にも、以下の効果が出ています。

技術課題が集約されたことで誰でも対応することができ、メンバーがチャレンジとして取り組むことができる
優先度が可視化されたので、機械的に対応すべき課題を判断できる
課題の対応にかかる工数感がわかるようになったので、プロダクト開発の合間に差し込む判断材料とできる

一方、プロダクトバックログの開発とのバランスをとることが難しいことや、課題解決をするメンバーが特定のメンバーに集中しているといった課題も残っています。この課題に対しては、技術課題に対して集中的に取り組む期間を設定して、エンジニア全員でプロダクトバックログの開発の合間では取り組みにくい技術課題の解消に向き合っています。プロダクトマネージャーといったビジネスサイドのメンバーも技術課題の開発生産性への影響は理解しているので、こういった取り組みをサポートしてくれています。