Vol.08 2週間のタイムボックスを導入してリードタイムを短縮

この記事は、Bill One 開発 Unit ブログリレー2024の第8弾、かつSansan Advent Calendar 2024の23日目の記事です！

Bill One Engineering Unitの小松代です。

請求書受領からスタートしたBill Oneでは、現在サービス領域を拡大しており、新しい機能開発に取り組む機会が増えています。

私のチームでは、バーチャル口座を利用した入金消込機能という新しいサービス領域の機能開発に取り組もうとしていました（※1）。
このプロジェクトは、ユーザの課題と解決策が定まりきっておらず、短いサイクルで仮説検証を回しユーザからのフィードバックを得て仕様や優先度を柔軟に変えていく必要がありました。

しかし、チームはリリースまでのリードタイムが長く、優先度変更に対するアジリティに乏しいという課題を抱えていました。
このような状況で、2週間のタイムボックス（時間の制約）を導入しPBIを細分化することでこれらの課題を解決できました。

今回は、タイムボックスの導入のポイントと効果について、私のチームでの事例をもとに紹介します。

※1: Bill Oneのサービス領域拡大のお知らせ

従来の開発スタイルの課題

私のチームでは、スクラムのエッセンスを取り入れたアジャイル開発手法で開発していました。
PBI（プロダクトバックログアイテム）を優先度順にひとつずつ順番に着手し、PBIごとに厳格な納期は設けず開発が完了次第、次のPBIに着手するスタイルで開発していました。
PBIはリファインメントを行い、相対見積をつけ必要に応じて分割していましたが、1カ月程度の期間を要するサイズのまま着手することがありました。

短いサイクルでリリースを繰り返しその時々の状況に適応することが求められる中で、従来の開発スタイルでは次のような課題がありました。

1. リリースまでのリードタイムが長い

PBIのサイズが大きく開発に時間を要する
PBIのスコープが広いため仕様の認識齟齬を起こしやすく手戻りが発生する
開発着手後に仕様変更を柔軟に取り込もうとするあまりリリースが遅れる

2. 優先度変化に対するアジリティに乏しい

優先度の高いPBIが追加されても、サイズの大きいPBIを開発中であると着手が遅れる

これらの課題を解決するために2週間のタイムボックスを導入することにしました。

2週間タイムボックスの実践と効果

タイムボックスとは、所定の時間内に作業を完了させることを目指す時間管理手法（タイムボクシング）における固定長の時間枠のことを指します。
例えば2週間というタイムボックスを設けたら、毎回2週間で作業をすべて完了させることを目指します。

タイムボックスの活用例として、スクラムにおけるスプリントが有名です。
私のチームではスプリントプランニングなどのスプリントの基本的な型を取り入れつつ、
PBIの開発の「着手からリリースまでを2週間のタイムボックス内で完了する」という部分に焦点を当てることにしました。

タイムボックスの導入にあたっては次のような効果を狙いました。

PBIを分割することでリードタイムを短縮する
PBIのサイズとスコープを小さくすることで遅延リスクを早期に検知・対策できる
2週間単位の計画でアジリティが向上し、急な変更にも対応できる

ここからは、私のチームの2週間の具体的な過ごし方とタイムボックスを導入した効果を紹介しようと思います。

タイムボックスの過ごし方と導入した効果

タイムボックスが始まると2日間ほどかけて、システム処理フローを精査し、主要なクラスやテーブルなどの大まかな設計をします。
ある程度設計の見通しが立ったら細かな実装タスクに分解していきます。
タスク分解を終えたら、約6日間かけて実装し、残り2日間でテストをしてリリースします。

開発を進める中で遅延につながるような課題が発生することもあります。

よくある事象としては、設計中に現状の仕様では今後の拡張性が失われる可能性に気づいたり、エッジケースの対応方法によっては想定よりも工数が増えることもあります。

しかし、2週間のタイムボックス導入することで、PBIのスコープが小さくなり、初期段階でリスクを検知しやすくなりました。
プロダクトマネージャー(PdM)やデザイナーと早期に相談し、仕様変更を迅速に決定できるため、遅延リスクを序盤で潰せます。

他にも、遅延につながるリスクとしてQAとエンジニアの認識のズレがあります。
開発のスコープが大きかったり、開発の終盤に仕様変更が入ると、仕様の認識にズレが起こり得ます。
そうするとテストケース誤りやモレを起こし、これがテストの段階で発覚するとリリースが遅延することもありえます。

しかし、2週間のタイムボックスで開発をすると開発のスコープが小さいため、詳細な仕様でもQAと共通認識をもちやすいです。
加えて、仕様変更があってもQAがテスト方針やテストケース作成中に意思決定できるため、その場で変更内容をテストに取り込めるため認識のズレやモレが起きにくいです。
これによってテスト工程での手戻りを減らし遅延リスクを早期に潰せます。

最近では、2週間でリリースし切る習慣がチームに定着してきており、リリース日が後ろ倒しになることがなくなり、リリースまでのリードタイムやリリース数も向上させられています。

PBIの分割

このように2週間のタイムボックスを導入することで良いリズムで開発を進められています。

しかし、この仕組みは導入するだけではうまくワークしない可能性があります。
タイムボックスをワークさせるために何より重要であることは、2週間に収まるようにPBIを細かく分割すること、そしてその分割方法です。

一般的にPBIはタスク視点ではなくユーザにとって価値のある単位（フィーチャー単位）で分割するとよいと言われています。
私のチームでは1カ月を超えるような大きいサイズのPBIは次のような観点で分解しています。

1. 最小限機能の実現
2. 機能拡張の実現

まずは最小限の機能を実装することを目指してPBIを分割します。
例えば、できるだけ人の手を介さずに処理したいという要件があったとしても、まずは手動で処理をできること目指し、その上で自動化を実現します。
他にも、データを登録したいという機能要件の場合に、まずは単一のデータを登録できることを目指し、その上で複数のデータを同時に登録できること実現する場合もあります。

最小限の機能を見極めるポイントは、PBIに記載されているキーワードの対義語を考えることや、次数を下げてみることが有効だと思います。

分割の切り口を見極めるうえでもう1つ重要であるのがユーザの業務の観点です。
例えば、請求書発行という業務で考えると、請求書をメールで発行する機能と郵送で発行する機能という発行方法の切り口です。

これらの切り口を組み合わせることでさらに細かく分割できます。
例えば、発行方法の切り口に請求書を1件ずつ発行できる(個別発行)と、請求書を複数件まとめて発行できる(一括発行)という数の切り口を組み合わせることで次のように分割できます。

メールで個別発行
郵送で個別発行
メールで一括発行
郵送で一括発行

このようにフィーチャー視点で細かく分割すると優先度変更に対してアジリティを高められるというメリットがあります。

例えば、メールで個別発行する機能の開発着手中に、「メール発行しか使わないが個別でも一括でも発行できたらすぐに使い始めたい」という顧客が現れたとします。
この時、メールで個別発行とメールで一括発行する機能の優先度を上げることでこの顧客の要望をすぐに満たせます。

このようにフィーチャー視点でPBIを細かく分割すると、分解後のPBIはそれぞれ単独で機能が成立します。
それによって着手順序の変更や差し込みを行いやすくなり、状況の変化に対して迅速に対応できるようになります。

まとめ

2週間のタイムボックスを設けることで、次のようなメリットが得られました。

開発リードタイムの短縮：PBIを小さく分割することでリードタイムを短縮
リリース数の向上：PBIの細分化と定期的なリリースサイクルでリリース数が増加
アジリティの向上：業務視点でPBIを分割することで優先度変更に迅速に対応できるようになりチームのアジリティが向上

設計や実装といった実行フェーズでの軌道修正は負荷が大きいが、計画フェーズの軌道修正は負荷が小さいということが一般に言われます。
今回2週間のタイムボックスを導入してみて、ひとつひとつのPBIスコープを小さくすることで、実行フェーズでの変動を抑え計画フェーズで軌道修正する仕組みに変えられ、この効果を実感できました。

一方で、次のような課題も出てきました。