こんにちは！ SmartHRで開発したり、アジャイル推進したり、筋トレしたりしてるkouryouです。
突然ですが、皆さんのチームの生産性は高いでしょうか？
この議論を始めると必ず直面する壁が、そもそも生産性とは何か？です。
生産性を上げようとする際の効率化の考え方には、リソース効率とフロー効率という2種類の考え方があります。
そしてSmartHRでは、特にフロー効率の方を重視しています。
そこで本記事では
- リソース効率/フロー効率とは何か
- なぜSmartHRはフロー効率を重視しているのか
について解説していきます。
リソース効率とフロー効率
リソース効率とは
リソース効率とは、リソースの稼働率のことです。
リソース効率を高めるということは、リソースに空きがあればタスクを与え、全員が何かしら手持ちのタスクがある状態を作ることになります。
手が空いてる人を作らないという至って普通の考え方なので、ほとんどの企業はこのリソース効率を重視しています。
リソース効率でのシミュレーション
ではここで、リソース効率での一般的なweb開発をシミュレーションしてみましょう。
- PM, デザイナー, エンジニアがそれぞれ1人ずつというリソースを想定
- 仕様策定3日, デザイン2日, 実装5日という機能A/B/Cの開発を想定
- ※A/B/C以外の仕事はグレーで表現
図の見方
- まずPMが仕様策定をA, B, Cと順番に行っていきます。A, B, Cは3日ずつで仕上がり、それ以降も何かしら別の機能の仕様策定をしていますが、単純化して考えるためにグレーで表現しています。
- PMの次にデザイナーがデザインを二日で仕上げます。4~5日目でAを仕上げたところ、6日目はBの仕様策定が終わってないため別のデザイン(グレー)をし、7日目にはBの仕様策定が終わったためデザインに着手・・・と繰り返していきます。
- エンジニアの最初の5日は何か別の実装をしている想定です。6日目から仕様策定・デザインが終わったAを実装します。Aが終わったらB、Bが終わったらCと実装していきます。
このように次から次へと何かしら手を動かしてる状態を作るのがリソース効率を高める考え方です。
フロー効率とは
フロー効率とは、ニーズが発生してから提供できるまでのリードタイムの短さに関する効率性の考え方です。
フロー効率を高めるには、１つの機能がリリースにたどり着くまでに待ち時間をどれだけ減らせるかがポイントになります。
結果としてフロー効率を極限まで高めようとすると、全員で1つのことに取り掛かり、1つ1つをリリースしていくことになります。
フロー効率でのシミュレーション
フロー効率での一般的なweb開発をシミュレーションしてみましょう。
- リソース効率と同様にPM, デザイナー, エンジニアがそれぞれ1人ずつで、機能A/B/Cの開発を想定
- フロー効率の場合は全員で仕様策定〜実装を行う
- 仕様策定〜実装は6日でできることを想定
非常に単純な図になりました。
このシミュレーションにおいて、全体工数が6日に減っていることに違和感を覚える人がいるかもしれません。これは全員が一緒に働くことで以下のメリットを得られるため、全体の工数が削減されることを想定しています。
- 引き継ぎコストの削減
- 考慮漏れなどによる手戻りの削減
- プロセスが創発的になり、より実装工数の低い仕様やデザイン案が出ることによる工数削減
全体工数が6日になることが妥当かどうかは、開発する機能やチーム状況によると思います。
個人的な経験値としては、未成熟なチームでも6日は妥当な印象です。
実際SmartHRではフィーチャーチームで全員が一緒に働くことになった結果、VSMは非常に短くなりました。
成熟しクロスファンクショナル が進んだチームでは、さらにVSMが短くなり、3~5日ぐらいになることも可能な印象です。
なぜSmartHRではフロー効率を重視してるのか
結論から言うと、ユーザーの価値を最大化するためです。
ここからは、フロー効率がなぜユーザーの価値を最大化することにつながるのかについて説明していきます。
仮説検証と軌道修正
まず前提として、SmartHRが置かれている環境について説明します。
SmartHRではユーザーやプロダクトが多様化しているために、開発を取り巻く不確実性は増す一方です。
多様な要望/ユースケース/データ量に対応するための正解、あるいは新規プロダクトの勝ちパターンの正解は、最初は誰も持っていません。
そのため、仮説の検証とそれに基づく軌道修正を高速に繰り返すことで、プロダクトの正しい方向性を細かく探っていく必要があります。
設定した仮説を検証し、その結果に基づいてプロダクトを方向づけることで、ユーザーにとって価値を最大化できるのです。
まとめると、ユーザーの価値の最大化には仮説検証とそれに基づく軌道修正が大事になってきます。
一段掘り下げましたが、ここからはなぜフロー効率が仮説検証とそれに基づく軌道修正に繋がるのかについて説明していきます。
フロー効率vsリソース効率
フロー効率とリソース効率がもたらすユーザーの価値を図を用いて比較してみましょう。
開発する機能が全てユーザーの価値につながる場合
まずは開発する機能が全てユーザーの価値につながる場合について考えてみます。
ユーザーの価値は最終的に売上につながるため、ここでは全ての機能が1日1ptの売上を出すと想定しましょう。
平等性のため、先ほどのシミュレーションに以下の条件を付け加えます。
- リソース効率のシミュレーションにおける最初のエンジニアの5日間について、グレーにせずプラスでα機能を開発してリリースしたと想定
- 逆にフロー効率では、余った最後の二日間でαの開発に着手することを想定
すると、売上は以下のようなグラフになります。
面積が合計の売上になるため、価値があるものが分かっている世界線では、より多くの機能を開発できるリソース効率*1の方がユーザーの価値の最大化が見込めそうに思えます。
開発する機能が必ずしもユーザーの価値につながらない場合
現実の世界では、作った全ての機能がユーザーの価値に直結するわけではありません。
先ほど説明したSmartHRを取り巻く現状も、正解や勝ちパターンはわからないのが実態です。
そのため、今回は作った機能のうちCしか価値(売上1pt/day)につながらなかった場合を考えてみましょう。
この場合、早めにCをリリースできるフロー効率の方が売上が大きいことがわかります。 フロー効率は早くリリースすることを重視しているので、当然の結果ではあります。
しかし、フロー効率のメリットはこれだけではありません。
フロー効率ではAをリリースした際のFBを元に、学習した内容をBに反映できるのです。
Aがユーザーの価値につながらないと判明した結果、Bの軌道修正が必要だと学習したとしましょう。
もし軌道修正した結果1pt/dayの売上につながった場合、グラフは以下のようになります。
リソース効率の場合、Aをリリースした時点でBは仕様策定もデザインも終わっているため、軌道修正は困難になります。
あくまでシミュレーションではありますが、フロー効率の方がユーザーの価値を最大化できました。
フロー効率のメリット
フロー効率の最大のメリットは、仮説検証とそれに基づく軌道修正をしやすいことにあります。
そして最初の前提にあったように、仮説検証とそれに基づく軌道修正は、ユーザーの価値を最大化させることにつながります。
そのためユーザーの価値を大事にしているSmartHRでは、フロー効率を重視しているのです。
リソース効率も上げていくには
当然ですが手空きの人を放置はしたくないので、リソース効率を軽視してはいません。
ではフロー効率もリソース効率も高い状態にするにはどうしたらいいでしょうか？
答えはフロー効率を先に上げて、その後リソース効率を上げていくことです。
なぜなら、その逆はできないからです。
というのも先にリソース効率を上げてしまうと、全員が手一杯の状態になり、全体の流れの中で最適化するのが難しくなるためです。
最初のリソース効率が高い状態のシミュレーションを思い出してみましょう。PM/デザイナー/エンジニア全員が別々のことで手一杯の状態で、BやCを早くリリースするのは困難です。
なのでまず先にフロー効率を上げ、後でリソース効率を上げる必要があります。
PR
SmartHRがフロー効率を重視しているのは、ユーザーの価値の最大化につながるからです。
SmartHRのプロダクトエンジニアはただ実装するだけでなく、ユーザーの価値を常に意識してプロダクト作りに携われます。
興味を持たれた方は、ぜひ一緒に価値あるプロダクトを作りましょう！
参考文献
*1:リソース効率を重視しすぎると、実際には生産量を増やせないことが多いです。これは効率性のパラドックスと呼ばれてる話ですが、本記事では長くなるため扱いません。
