フロー効率性とリソース効率性について XP祭り2017で発表してきた #xpjug

先日、開催された XP祭り2017 にて発表してきました。スライドは以下になります。

www.slideshare.net

また、上記発表のベースは以前のポストである「 フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ） - @i2key のBlog 」がベースとなっております。また、Slideshareに上げたスライドが画像が若干ガビガビになってて見にくいので補足がてら要点だけ記載します。（と思ったら、元のポストより完成度高まってしまった。ので今後、誰かに説明するときはこっちをオリジナルにしよう。。。。）

フロー効率性とリソース効率性についてかんたんな説明

リソース効率性について

リソース効率を高めるということは稼働率を100%にあげていくことであり、リソースに空きがあればタスクを与え全員が何かしらの手持ちのある状態を作るということになります。ただし、価値を発揮するまでのリードタイムが長くなります。 f:id:i2key:20171001171953p:plain 上記の図は例えばA、B、Cという3つの機能追加開発(それぞれ工数15人日)があった場合、それらを同時に開発するパターンを示しています。複数のことを同時にやるとリリースまでまとめて同時に行われるため、3週間後にまとめてリリースされることになります。ABC機能がユーザに届くまで・その機能を使った検証を開始するまでのリードタイムは3週間かかります。これに対して後述するフロー効率性を重視した開発だと前倒しになります。ただし、この状況は皆に仕事が割り振られて手持ち無沙汰な人がいないため、リソースあたりの稼働率は高くなります。以下の図がリソース効率を高めるときのイメージです。 f:id:i2key:20171001171959p:plain フォーカスしているのはリソースそのもので、そのリソースの稼働を100%になるまで、流れてくるタスクに対して割り当てています。一般的にマルチタスクと言われている働き方です。

フロー効率性について

フロー効率を高めるということは稼働率をある程度犠牲にした上で、全員で1つのことに取り掛かり1つ1つをリリースしていくことになります。これにより個々の価値発揮までのリードタイムはリソース効率重視に比べ短くなります。しかしながら、手持ち無沙汰な人が発生したりするので稼働率は下がります。 f:id:i2key:20171001172007p:plain 前述の図と同様にA、B、Cという3つの機能追加開発(それぞれ工数15人日)があった場合、それらを1つ1つ順番に開発するパターンを示しています。一つ一つを順番に倒していくためAは大体1週間くらい、Bは大体2週間くらい、Cは大体3週間くらいでリリースされます。仮にA機能がC機能の前提だった場合、Aの検証結果がダメな場合は、Cは開発をやめて別のことをやるとか、まとめてやる場合よりも短サイクルでフィードバックループを回すことが可能になります。 f:id:i2key:20171001172015p:plain ここでフォーカスしているのはリソースではなく流れてくるタスクそのものです。そのタスク自体が享受するリソース時間を最大化するように割り当てられています。1つの対象が得られるリソース時間を最大化する手法としては以下が有名です。

上記は、価値を発揮するまで（問題を取り除くまで）のリードタイムを短くするために行われています。このときにリソースの稼働率を気にしていないはずです。

フロー効率性とリソース効率性のビジネス影響について

では、実際にビジネス上、それぞれのスタイルがどのように影響するのかという点で見ていきます。ただし、様々なケースがありどっちが正義というわけでもないので今回は改善サイクルを回してコンバージョンレート（以下CVR）を上げていくという開発を例にします。

ビジネス価値とリソース効率性重視の開発スタイル

f:id:i2key:20171001174654p:plain ABCの機能がそれぞれCVR向上を目的とした場合、リソース効率重視でまとめて開発するとこの場合、6〜7週間後にリリースされます。そして、説明のため超ざっくりですがABCそれぞれが仮に1ptのCVR向上の効果があるとした場合、それらの効果は同時にきます。ビジネスモデルにもよりますがそれがKPI数値に寄与するのかはたまた売上に直結するのかはありますが作ったものの成果が出るのがそのタイミングです。

ビジネス価値とフロー効率性重視の開発スタイル

f:id:i2key:20171001174701p:plain それに対して、ABCをフロー効率性重視で1つずつ作っていった場合、Aがリリースされるのが大体2週間後で、成果が出始めるのも2週間後からになります。そしてそこからBの開発がはじまりますが、Aの効果は引き続き続いているので根雪構造として効果が蓄積していきます。そして4〜5週間後に差し掛かったときにBがリリースされます。A同様にそこかでBの効果も出始めるので、A+Bの効果が積み上がります。同様にCも（略）。ここでポイントなのはビジネス上の成果は根雪構造をとるので早めに市場投下したほうが何らかのフィードバックを得やすくなります。

それぞれのビジネス上での影響

f:id:i2key:20171001174713p:plain まとめると、上図のような感じになります。改善サイクルを回りてCVRをあげるような文脈における開発では、まとめてやること（リソース効率）を選択するということは、学んでいない期間、稼いでいない期間を最大化するという選択を取ったということを意味します。また分析基盤がしっかりしていて、機能毎のコホートが取れていれば問題ないですが、何も準備無しでやった場合は効果も同時に濁ることになり、何が寄与したのかすら不明になります。学びがないので振り返れないです。 それに対して、1つずつやること（フロー効率）を選択したということは学んでいない期間、稼いでいない期間を最小化する選択をしたことになります。しかしながら、稼働率は若干悪化するため、トータルでいうとABCを作り切るコストは高くなるかもしれません。しかしながら、ABCそれぞれがダメだった場合のリスクも下げられているので行って来いかと思います。

個人として、組織として、マルチタスクをとるか、シングルタスクをとるかという選択

f:id:i2key:20171001164457p:plain ○○効率性が正義、○○効率性は悪とかを言いたいわけではなく、これは場合によるとは思います。が、個人的には制約がない限りフローに倒したほうがリソース効率上の問題も浮き彫りになるためフロー改善を意識的にやるとよいと思います。そのためにバリューストリームマップとか考え方のフレームワークはあります。しかしながら、サービス開発において様々な制約が存在します。現実は簡単ではないです。そんな中でエンジニアリングを駆使して制約をコントロール対象にすることが求められていますし、DevOpsやアジャイルにおけるエンジニアリングプラクティスは制約をコントロール下においてフローを加速させる目的が含まれているように思えます。

例えば、リリース日が固定で沢山の実装すべき機能がある場合、そのリリース日を制約としてすべてをまとめて作っていくやりかたを選ぶ(リソース効率)か、Feature Toggleを用いて1つ1つ段階的にDark Launchしていき、リリース日にトグルオープンにする(フロー効率)か、エンジニアリングで制約をコントロールできたりします。

契約、環境、組織、プロセス、スキル様々な制約がある中で制約をコントロール対象ではなく前提とした瞬間にリソース効率の引力が襲ってきます。ただし、開発の特性上、制約を前提とおかねばならない場合もあるのは当然で、制約をコントロール出来る上限こそがその開発組織の文化的、組織的、技術的練度なのかと思います。

まとめ

この手の話というのは、ToCでもCCPMでもリーンでもTPSでもどこでも同じような話がされています。なんら新しい概念でもなんでもありません。その割には現実世界では何に当てはまるのかというように実業務に紐付けては理解されていないように感じます。そこで、サービス開発が対峙している状況にテーラリングすることで少しでもこの概念が現場（特に判断を行うロール：マネージャなど）にインストールできればと思います。あくまで真理に対して初心者でもわかりやすく特定の方向から光を当てているだけであり、全方位をケアするような目的ではありませんので、今回光を当てていない影の部分に対して、やれ、ToCではこうだとか、TPSだとあーだとか、いやいやリーンだとこうだけど？みたいなツッコミはご配慮いただけると幸いです（笑）