スライドは以下になります。」がベースとなっております。Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。(と思ったら、元のポストより完成度高まってしまった。今後、誰かに説明するときはこっちをオリジナルにしよう。)フロー効率性とリソース効率性についてかんたんな説明リソース効率性についてリソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空きがあればタスクを与え全員が何かしらの手持ちのある状態を作るということになります。価値を発揮するまでのリードタイムが長くなります。上記の図は例えばA、B、Cという3つの機能追加開発(それぞれ工数15人日)があった場合、それらを同時に開発するパターンを示しています。複数のことを同時にやるとリリースまでまとめて同時に行われるため、3週間後にまとめてリリースされることになります。ABC機能がユーザに届くまで・その機能を使った検証を開始するまでのリードタイムは3週間かかります。これに対して後述するフロー効率性を重視した開発だと前倒しになります。この状況は皆に仕事が割り振られて手持ち無沙汰な人がいないため、リソースあたりの稼働率は高くなります。以下の図がリソース効率を高めるときのイメージです。フォーカスしているのはリソースそのもので、そのリソースの稼働を100%になるまで、流れてくるタスクに対して割り当てています。一般的にマルチタスクと言われている働き方です。フロー効率性についてフロー効率を高めるということは稼働率をある程度犠牲にした上で、全員で1つのことに取り掛かり1つ1つをリリースしていくことになります。これにより個々の価値発揮までのリードタイムはリソース効率重視に比べ短くなります。手持ち無沙汰な人が発生したりするので稼働率は下がります。前述の図と同様にA、B、Cという3つの機能追加開発(それぞれ工数15人日)があった場合、それらを1つ1つ順番に開発するパターンを示しています。一つ一つを順番に倒していくためAは大体1週間くらい、Bは大体2週間くらい、Cは大体3週間くらいでリリースされます。仮にA機能がC機能の前提だった場合、Aの検証結果がダメな場合は、Cは開発をやめて別のことをやるとか、まとめてやる場合よりも短サイクルでフィードバックループを回すことが可能になります。ここでフォーカスしているのはリソースではなく流れてくるタスクそのものです。そのタスク自体が享受するリソース時間を最大化するように割り当てられています。1つの対象が得られるリソース時間を最大化する手法としては以下が有名です。価値を発揮するまで(問題を取り除くまで)のリードタイムを短くするために行われています。このときにリソースの稼働率を気にしていないはずです。フロー効率性とリソース効率性のビジネス影響についてでは、実際にビジネス上、それぞれのスタイルがどのように影響するのかという点で見ていきます。様々なケースがありどっちが正義というわけでもないので今回は改善サイクルを回してコンバージョンレート(以下CVR)を上げていくという開発を例にします。ビジネス価値とリソース効率性重視の開発スタイルABCの機能がそれぞれCVR向上を目的とした場合、リソース効率重視でまとめて開発するとこの場合、6〜7週間後にリリースされます。説明のため超ざっくりですがABCそれぞれが仮に1ptのCVR向上の効果があるとした場合、それらの効果は同時にきます。ビジネスモデルにもよりますがそれがKPI数値に寄与するのかはたまた売上に直結するのかはありますが作ったものの成果が出るのがそのタイミングです。ビジネス価値とフロー効率性重視の開発スタイルそれに対して、ABCをフロー効率性重視で1つずつ作っていった場合、Aがリリースされるのが大体2週間後で、成果が出始めるのも2週間後からになります。そこからBの開発がはじまりますが、Aの効果は引き続き続いているので根雪構造として効果が蓄積していきます。4〜5週間後に差し掛かったときにBがリリースされます。A同様にそこかでBの効果も出始めるので、A+Bの効果が積み上がります。ここでポイントなのはビジネス上の成果は根雪構造をとるので早めに市場投下したほうが何らかのフィードバックを得やすくなります。それぞれのビジネス上での影響まとめると、上図のような感じになります。改善サイクルを回りてCVRをあげるような文脈における開発では、まとめてやること(リソース効率)を選択するということは、学んでいない期間、稼いでいない期間を最大化するという選択を取ったということを意味します。分析基盤がしっかりしていて、機能毎のコホートが取れていれば問題ないですが、何も準備無しでやった場合は効果も同時に濁ることになり、何が寄与したのかすら不明になります。学びがないので振り返れないです。それに対して、1つずつやること(フロー効率)を選択したということは学んでいない期間、稼いでいない期間を最小化する選択をしたことになります。稼働率は若干悪化するため、トータルでいうとABCを作り切るコストは高くなるかもしれません。ABCそれぞれがダメだった場合のリスクも下げられているので行って来いかと思います。○○効率性が正義、○○効率性は悪とかを言いたいわけではなく、これは場合によるとは思います。個人的には制約がない限りフローに倒したほうがリソース効率上の問題も浮き彫りになるためフロー改善を意識的にやるとよいと思います。そのためにバリューストリームマップとか考え方のフレームワークはあります。サービス開発において様々な制約が存在します。現実は簡単ではないです。そんな中でエンジニアリングを駆使して制約をコントロール対象にすることが求められていますし、DevOpsやアジャイルにおけるエンジニアリングプラクティスは制約をコントロール下においてフローを加速させる目的が含まれているように思えます。プロセス、スキル様々な制約がある中で制約をコントロール対象ではなく前提とした瞬間にリソース効率の引力が襲ってきます。まとめこの手の話というのは、ToCでもCCPMでもリーンでもTPSでもどこでも同じような話がされています。なんら新しい概念でもなんでもありません。その割には現実世界では何に当てはまるのかというように実業務に紐付けては理解されていないように感じます。そこで、サービス開発が対峙している状況にテーラリングすることで少しでもこの概念が現場(特に判断を行うロール:マネージャなど)にインストールできればと思います。ツイートはてなブログをはじめよう!i2keyさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。