← エピソード一覧に戻る Episode 166 Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
0:00 / 0:00
スクリプト
Chapter 1 オープニング ― 書いたのに届かない時間の正体
タカシ
皆さんこんにちは、タカシです。今日は SaaS 開発の変更リードタイムを扱います。GitHub では昔、1 本の train に 15 件の PR が乗り、8 時間以上待った末に外されることもありました。書いたのに届かない、この時間こそ今日の主役です。
ミカ
ミカです。『実装は終わったのに、まだ顧客に届いていない』って、現場ではよくありますよね。レビュー待ちなのか、CI 待ちなのか、承認待ちなのか、何に時間を使っているのか見えないままになりがちです。
タカシ
DORA の定義では、Lead Time for Changes は commit が production に入るまでの時間です。つまり個人のコーディング速度ではなく、組織全体の流れがどれだけ滑らかかを測る指標なんですね。
ミカ
なるほど。荷物を作る速さじゃなくて、倉庫を出て、お客さんの手前まで届く速さを見る感じですね。途中の関所が多い会社ほど、実装が速くても全体は遅く見えるわけだ。
Chapter 2 基本 ― リードタイムは待ち時間の合計
タカシ
経営目線で重要なのは、lead time が『開発時間』ではなく『待ち時間込みの総時間』だという点です。レビュー、build、テスト、承認、デプロイ、migration、こうした工程が全部つながって初めて本番へ届きます。
ミカ
ということは、『エンジニアは 2 日で作ったのに、なぜ 2 週間もかかるのか』みたいな場面では、本人の生産性より、途中のキューや承認の仕組みを疑うべきなんですね。
タカシ
その通りです。GitLab はこれを Mean Time To Production として管理し、time to inclusion、package、staging、canary、production に分けています。しかも目標を 12 時間と置き、どこが詰まるかを工程別に見ています。
ミカ
見える化の粒度がいいですね。『遅い』で終わらせずに、『auto-deploy への取り込み待ちが長い』『canary の確認が重い』みたいに言えると、改善の打ち手がかなり変わりそうです。
Chapter 3 具体例 ― 良い改善と悪い改善の分かれ道
タカシ
悪い改善の典型が、さきほどの GitHub の train です。複数 PR をまとめて運ぶので一見効率的ですが、1 件の衝突や不具合で全体が止まりやすい。大きなバッチは待ち行列を育て、lead time を悪化させやすいんです。
ミカ
確かに、まとめて出せば楽そうに見えて、事故が起きた瞬間に全員が巻き込まれますね。『一気にやるほうが効率的』という直感が、むしろ遅さを生むのか。
タカシ
一方で Banorte は bi-weekly のリリースから multiple deployments per day へ進み、lead time for changes を 2 日未満まで短縮しました。しかも開発・運用コストを 20% 削減しています。速さとコスト改善が同時に起きた例ですね。
ミカ
『速くすると忙しくなる』ではなく、『速く安全に流れるから無駄な待ちや手戻りが減る』ということか。経営側から見ると、これはかなり大きいメッセージです。
タカシ
Decathlon Digital も似ています。自動化、small batch、WIP 制限、月次のメトリクス共有を進めた結果、優秀なチームでは lead time が 15 日超から 2 日未満まで縮みました。改善は気合いではなく、流れの設計で起きます。
Chapter 4 経営論点 ― production 到達と顧客価値は同じではない
ミカ
でも SaaS だと、本番に入っても feature flag で隠していたり、顧客ごとに rollout したりしますよね。その場合、lead time が短いと判断していいのか、ちょっと迷います。
タカシ
そこは重要です。DORA の基本定義は commit から production ですが、B2B SaaS では customer-available まで別で追う価値があります。migration 完了待ちや顧客別有効化が長いと、数字上は速くても価値提供は遅いままです。
ミカ
なるほど。社内の『出した』と、顧客の『使えるようになった』を混同すると、経営判断を誤るんですね。特に enterprise 向け SaaS ほど、このズレは大きそうです。
タカシ
その通りです。さらに承認会議、人手の release 判断、deploy と migration の抱き合わせも lead time を伸ばしやすい。GitLab が canary、blocking condition、post-deploy migration 分離を重視するのは、速さと rollbackability を両立するためです。
Chapter 5 クロージング ― 変更リードタイムを縮める5つの視点
タカシ
最後に整理します。良い変更リードタイムとは、単に早いことではなく、小さな変更が安全に流れ、必要ならすぐ止めたり戻したりできる状態です。速さは安心の敵ではなく、仕組みがあればむしろ味方になります。
ミカ
経営者や開発責任者は、まず何から始めるのがいいですか。『遅い気がする』はあっても、どこから手を付けるべきか分からない組織は多そうです。
タカシ
まずは commit から production までを工程別に測ってください。レビュー待ち、build、staging、canary、production、migration のどこで滞留するかを週次で見るだけでも、改善余地はかなり見えてきます。
ミカ
そのうえで、PR を小さくする、同時進行を減らす、承認を会議から自動テストや guardrail に寄せる、migration と rollout を分離する。このあたりが、明日から動かしやすい改善策になりそうですね。
タカシ
今日は SaaS 開発の変更リードタイムを取り上げました。次回は、この速さの裏返しとして品質面をどう見るか、変更失敗率を扱います。皆さんの組織では、変更が遅いのか、それとも待ちが長いのか、ぜひ見直してみてください。