フロー効率から始めて、チームの生産性を向上させた話

■イベント


ローンチ4年でARR70億を達成するためのエンジニアリング組織の取り組み
https://sansan.connpass.com/event/292027/

■登壇概要

フロー効率から始めて、チームの生産性を向上させた話

登壇者：技術本部 Bill One Engineering Unit Smart インボイスネットワークグループ　江川 綾



■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. Sansan株式会社 部署 名前 フロー効率から始めて、 チームの⽣産性を向上させた話 Sansan技術本部 Sansan技術本部 Bill One Engineering Unit 江川 綾
2. 写真が入ります 江川 綾 Sansan株式会社 技術本部 Bill One Engineering Unit 2021年 Sansan新卒⼊社。 ⼊社以来、Webアプリケーション開発エンジニアとして インボイス管理サービス「Bill One」の開発に従事。 現在は、Bill Oneにおけるインボイスネットワークの拡⼤に向けた 開発に加えて、フロントエンドの技術的な改善をリードしている。 @er11161 @erm1116
3. アジェンダ - まずはフロー効率から始める > リソース効率とフロー効率 > 効率性のマトリックス - “効率性の海”における リソース効率への向き合い - さらに効率性を⾼めるためにやったこと - チームの⽣産性はどうなったのか - まとめ
4. まずはフロー効率から始める
5. リソース効率とフロー効率 リソース効率 - リソースを最⼤限に活⽤することを⽬指す考え⽅ - 複数のことを同時にやることで稼働率を上げる（100%を⽬指す） - 結果として、リードタイムは⻑くなる フロー効率 - リードタイムを短くすることを⽬指す考え⽅ - 待ち時間・ムダをなくす（プロセスの最適化を⽬指す） - 結果として、リソースの稼働率は下がる
6. リソース効率とフロー効率 出典: フロー効率性とリソース効率性について
7. リソース効率とフロー効率 - 開発チームやプロジェクトによって⽬指す効率性は変わる - 意図を持って効率性を上げていくことを⽬指すのが重要 - Bill Oneでは、ユーザーの価値を最⼤化するためフロー効率を重視 - 「本質を⾒極め、素早くアウトプットし、改善を繰り返す」というのを⼤事に している
8. 効率性のマトリックス 出典: This is Lean フロー効率 ⾼ 低 ⾼ 効率性の孤島 完璧な状態 荒野 効率性の海 変動 リソース 効率
9. 効率性のマトリックス 出典: This is Lean フロー効率 ⾼ 低 ⾼ 効率性の孤島 完璧な状態 荒野 効率性の海 変動 リソース 効率 理想 現在地
10. 効率性のマトリックス 出典: This is Lean フロー効率 ⾼ 低 ⾼ 効率性の孤島 完璧な状態 荒野 効率性の海 変動 リソース 効率 理想 現在地 ①まずはフロー効率から始めて
11. 効率性のマトリックス 出典: This is Lean フロー効率 ⾼ 低 ⾼ 効率性の孤島 完璧な状態 荒野 効率性の海 変動 リソース 効率 理想 現在地 ①まずはフロー効率から始めて ②リソース効率も⾼めていく
12. 効率性のマトリックス 出典: This is Lean フロー効率 ⾼ 低 ⾼ 効率性の孤島 完璧な状態 荒野 効率性の海 変動 リソース 効率 理想 現在地 ①まずはフロー効率から始めて ②リソース効率も⾼めていく ムダを炙り出し、プロセスの最適化をする中で フロー効率とリソース効率の両⽴を⽬指す
13. まずはフロー効率から始める - カンバンを採⽤ - チーム（4-5名）で取り組むバックログは1つのみ（WIP制限） - モブワークで設計・プランニング（タスクだし・⾒積もり・リリースターゲット決 定）をやる - レーンごとのWIP制限 - プルリクエストのレビューで待ちが発⽣することが多いため、 チームで「レビュー中」のレーンにWIP3制限を設けた > 後にふりかえりなどからWIP2に変えていった - チームの理想像や⼤切にすること・しないことを話し合う - 同じ⽅向性を向いて改善を進められるようにした
14. “効率性の海”における リソース効率への向き合い
15. リソース効率に向き合う バックログWIP1の中でも可能な限りタスクを細分化 - スキーマ駆動開発によるバックエンド・フロントエンドの作業の分離 - バックエンド: 各レイヤーごとにタスクを分割 - ex) ドメイン・リポジトリ・ API実装はそれぞれ分割 - フロントエンド: コンポーネント駆動開発で必要に応じてタスクを分割 - Storybook + msw上で動かしながらコンポーネントごとに実装進める
16. リソース効率に向き合う バックログアイテムのスコープを広げた - チーム状況・プロジェクト状況を⾒ながらバッチサイズを調整 - あえてフロー効率を下げて、リソース効率を上げた - プロジェクト状況に合わせて理想点をずらした - ⾒積もり精度とリードタイムのちょうどいい塩梅を取る 効率性の孤島 完璧な状態 荒野 効率性の海 フロー効率 ⾼ 低 理想 理想 ⾼
17. さらに効率性を⾼めるためにやったこと
18. さらに効率性を⾼めるためにやったこと バリューストリームマップ（VSM）でプロセスのムダに向き合う - プロセスのうち、どこで待ちや⼿戻りが発⽣しているのかを可視化し 改善案を⽴てる - ex) > モブワークをやるための待ち > リリースまわりの待ち > レビュー待ちなど
19. さらに効率性を⾼めるためにやったこと デイリースタンドアップでチームの⽬線を揃える - バーンアップチャートとカンバンの状況から、 個⼈ではなく「チームとして今⽇進めたいこと」を認識合わせする - 今⽇どのタスクをDoneしていくかを会話 - 中でも特に優先するタスクも認識合わせ > 例えばタスク間で依存会計があるようなもの（ドメインモデルの実装など）は 優先的にタスクを取り、レビュー依頼が⾶んできたら何よりも優先してレビュー する
20. チームの⽣産性はどうなったのか
21. チームの⽣産性の変化 PRのサイクルタイム - First CommitからPRマージまでの期間を計測 - 2⽉時点では44.1h ▷ 直近は23.1h
22. チームの⽣産性の変化 チームのキャパシティ - デイリーで完了できるタスクのポイント数を計測 - リリース予定⽇の決定や、⽇頃の検査・適応にも活⽤ - 2⽉時点では約4pt ▷ 直近は約8ptまで上昇（チームが4→5⼈になったと いうのもある）
23. まとめ
24. まとめ - まずはフロー効率から始めることで、改善の⼒学を働かせる - フロー効率に向き合う上でプロセスの最適化に向き合った結果、リソース 効率も⾼まる - チームやプロジェクト状況に合わせて理想を描き、チームで改善を進めて いくのが重要