こんにちは。プラットフォーム開発部 EMのchikaです。

みらい翻訳の開発ではリーン開発を1つの目指す方向性としています。

誤解を恐れずに一言でその目的を言うならば、「小さく早く開発を回して施策の試行回数を上げ、学びを得る機会を最大化すること」だと思っていますが、それを実現するための重要な考え方として「フロー効率」があります。

フロー効率性について理解を深めるために書籍 This is Lean を中心に先人たちの素晴らしいブログなどを読み漁り、「なぜフロー効率が重要なのか？」について周りの皆の理解も進むといいなーと思い、まとめてみました。

This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント

Amazon

フロー効率とリソース効率
- リソース効率
- フロー効率
リードタイムについて
開発チームでリソース効率でなくフロー効率の方が重要な理由
- チームやプロジェクトによっても求める効率性は異なる
- フロー効率とリソース効率は二者択一なのか？
フロー効率を上げるには現場で何をすればよいのか
さいごに
We are hiring!

フロー効率とリソース効率

フロー効率について調べると必ず出てくるのは、フロー効率とリソース効率の比較です。

リソース効率

リソース効率とは、あるプロセスで使う人員や設備、資材などのリソースを最大限に活用することを目指す考え方です。以下のようなポイントに注力する必要があります。

無駄に使わない
稼働率を上げる（空きを作らない）
作業時間を短縮する
コストを下げる

身近にありそうな例をあげると、たとえば高価な機器や高額で雇ったコンサルタントには暇にさせずにガッツリ働いてもらわないともったいない！といったシーンを想像するとわかりやすいです。また、日常的にスクラムでスプリントを回す中で「手空き」の時間ができてしまうのを「もったいない」「効率が悪い」と感じることもあるかと思います。これはすなわち、リソース効率が悪いということです。

リソース効率を上げるということは、単位時間あたりでリソースがもたらす付加価値を最大化するということであり、高付加価値の仕事の割合の最大化と、価値を付加する時間の最大化を目指すということになります。

フロー効率

フロー効率とは、あるプロセスでの仕事の流れを最適化することを目指す考え方です。そのために必要な要素をいくつか挙げます。

プロセス間の作業の受け渡しをスムーズにする
プロセス間の待ち時間をなくす
ボトルネックの処理能力を上げる

こちらも身近な例でフロー効率の良い／悪いを表すと以下のようになります。

フロー効率が良い例
- 要求分析・設計・実装（フロント、バックエンド）・テスト・デプロイの工程をすべてを実施できるOneチームであればチームを跨ぐことなく一気通貫で開発できる
フロー効率が悪い例
- 開発工程やレイヤーごとに担当するチームが分かれていると、チーム間の受け渡し作業に時間がかかったり、別途ドキュメントが必要になったりする
- フロントとバックエンドの開発スピードに差があり、結合タイミングでスケジュール待ちが生じたりする
- 開発もテストも終わっているのだけど、リリース日の調整によりなかなかリリースできない

フロー効率の観点では、フローユニット（作業対象とするモノ）にフォーカスして、フローユニットが価値を受領する時間の割合を最大化することが焦点となります。

言い換えると、フロー効率を上げるということは、フローユニットのサイクルタイム（着手〜完了のリードタイム）を短縮することを意味します。

リードタイムについて

リードタイムを短縮することがなぜ重要なのかを、書籍にあったエピソードを例に理解を深めようと思います。

リードタイムが短い方が良いと分かる例（がん検査の診断プロセス）

This is Lean の中では、2人の女性がそれぞれ受けた乳がん検査の診断プロセスを例に、リソース効率とフロー効率を説明しています。

A リソース効率重視のプロセス

町医者での診察 → 総合病院での検査 → 結果診断 → 細胞検査 → 診断結果の通知と経て42日

B フロー効率重視のプロセス

専門のクリニックで診察～検査実施～診断結果の通知までワンストップで2時間

（出典：https://www.dfkompetens.se/webroot/documents/34/Modig.pdf ）

ここではフローユニットが患者である2人の女性です。がんの心配をする患者にとって診断結果を受けるまでの時間によって状況が大きく変わる可能性があるため、リードタイムが短い方が良いのは言うまでもありません。フロー効率の重要性を理解しやすいとても良い例だと思いました。

その他の参考例

上の例以外にも、言わずと知れたビジネスの名著ザ・ゴールでは、フロー効率重視の本家ともいえるトヨタ生産方式と同じ製造業が題材になっており、フローユニットは生産している製品の部品（仕掛品）です。

リードタイムが長くなると仕掛品の在庫が増えてしまいますが、これらは価値を生まない上に管理コストが余計にかかってしまうため、リードタイムを短くすることが非常に重要だと説明されています。

↓コミック版、分かりやすくてオススメです

ザ・ゴール　コミック版

Amazon

ITサービスの開発でもリードタイムの長さでフローユニット観点での価値は変わる？

ITサービスの開発ではフローユニットは人でも物理的な在庫でもなくプロダクト/機能であり、ぶっちゃけデータなので、リードタイムの長さでそんなに価値が変わるの？と疑いの気持ちをちょっと抱いてしまうかも知れませんが、ザ・ゴールの話を参考にするとこれだけは同じだと言えます。

開発中（WIP）のままリードタイムが長いと他の開発による変更を取り込む手間（フローユニットにとって価値のない作業を受領する時間）が増える
もちろん、リソース（エンジニア）にとっても付加価値の低い作業を行う時間（在庫管理コスト）が増える

また、少し観点をずらして「価値を受け取るユーザー」という観点で捉えると、完了すること＝リリースしてユーザーに価値を届けられること、なので、シンプルにリードタイムが短い方が良いのは感覚的に分かります。逆にリリースが遅くなると、こんな可能性が考えられます。

例1）機能改善のリリースが遅くなることでユーザーがその機能によって感じる満足度が半減する、しびれを切らして解約/退会してしまい受け取る価値がゼロとなってしまう
例2）リリースが遅くなることによって、競合企業が同じ機能を先に安価で市場投入してしまい、開発した機能を使うユーザー層がほぼ消滅する

いかがでしょうか。リードタイムが短いことの価値が少し分かりやすくなりませんか？

開発チームでリソース効率でなくフロー効率の方が重要な理由

プロダクト開発を行うチームにとって、なぜ「タスクを一度にたくさんこなせる」ような観点のリソース効率でなく、リードタイムに焦点が当たるフロー効率の方が重要なのかを一言で表すなら、施策の試行回数を増やして、学びを早く多く得られるからです。

このあたりはすでに語り尽くされた先人の知恵がありますので、こちらを読んでいただければよいかと思いますが、

フロー効率性とリソース効率性について #xpjug | PPT

この資料から一発でわかりやすい図がありましたので拝借します。

（出典：フロー効率性とリソース効率性について）

リソース効率重視で並行に多くの施策（開発）を進めていると、リリースまでの時間が長くなり、学びを得られるまでの時間も長くなります。仮説検証のための開発に長い期間とリソースを投入して作った結果、「外れていた」ということになると、多大なリソースを使って何の価値も生み出せなかったことになります。

一方でフロー効率重視で最初の1つの成果を早くリリースできれば、機能は不完全でも収益に貢献することが可能になりますし、チームはリリースまでの開発サイクルをいち早く体験することができ、且つ市場からのフィードバックを受けて次に活かすことができるようになります。つまり、施策を試し、学びを得る機会を多く得られることに繋がります。

また、後述するプラクティスのメリットを見ると分かりますが、フロー効率重視の開発をすることで、開発者体験（DX：Developer eXperience）も向上します。

チームやプロジェクトによっても求める効率性は異なる

フロー効率のメリットが目立つ説明をしましたが、開発するプロダクトやプロジェクトの違いによって、重視する効率は変わってきます。

開発におけるフロー効率とリソース効率の特徴については、以下の表でまとめた内容が分かりやすいです。

変化の大きい市場でプロダクトを出し、どんどん改善していくのが求められる場合は、職能横断型チームを組成してフロー効率を重視した開発を行うスタイルが適していますが、一方で変化の少ない、予算や仕様が予めカッチリと決まったような不確実性の低いプロジェクトでは、リソース効率を重視した進め方の方が合っているということも分かります。

	フロー効率	リソース効率
重視する指標	リードタイム	リソース稼働率
市場環境	変化が多いときに向いている	変化が少ないときに向いている
スケジュールリスク	市場リスクに比べて少ないときに向いている	市場リスクよりも大きいときに向いている
トータル期間	長く連続的に価値を出す	短くまとめて価値を出す
プロジェクト形態	固定されたチーム開発	柔軟にリソースを変化させるプロジェクト型開発
組織形態	職能的多様性を持つフィーチャーチーム	専門職能組織を持つコンポーネントチーム

（参考：「もったいない」マインドが逆に効率を悪くする。フロー効率とリソース効率から考えるチームで仕事をする理由）

フロー効率とリソース効率は二者択一なのか？

では、フロー効率とリソース効率はどちらか一方しか取れず、プロダクト開発では必ずしもフロー効率だけを考えればよいのか？というとそうではありません。両方良いに越したことはないですが、それが簡単ではないというだけです。

ただ、フロー効率とリソース効率のどちらも悪い場合、またはリソース効率だけが良い場合に、どうやって両方良い状態に持っていくのかというときには、フロー効率を改善していく方が、変化の多いビジネス環境に対応していくにあたって有効であるといえます。

（出典：フロー効率性とリソース効率性、再入門）

フロー効率を上げるには現場で何をすればよいのか

では、フロー効率を上げるには現場でどんなことに焦点を当てて改善すればよいのでしょうか。

今の私たちの現場でもまだ一部しかできておらず難しいものの、重要だなぁと思っているプラクティスから順にいくつか挙げてみます。

バッチサイズを小さく

開発するサイズが大きいと、全部をまとめてリリースしようとしたら当然リードタイムが長くなります。

そもそもそんなに大きなコストをかけてまで全部の機能は必要でしょうか？

「効果があるか試してみたい」という動機から作るベータ機能やプロトタイプの場合、コストはあまりかけられないですし見込み違いがあれば早く気づきたいものです。

小さい要件
- やることを小さくすれば早くリリースしてフィードバックも得られる
- MVP（Minimum Viable Product）
小さいストーリー、小さいリリース単位に分割する

WIP制限（並列度を上げない）

並列度を上げるのはチーム開発としてはデメリットが多いです。

WIP上限を設けて並列度を制限することで、以下のようなメリットが得られると思います。

ボトルネックの可視化がしやすい
- 次のToDoに着手したくてもWIPの上限に達していたら着手できない
- WIPのままの作業をフォローして解消に当たる
チーム内分業（各人バラバラのエピックアサインなど）の削減
- 問題発生時にフォローしやすい
  - チーム内での情報共有の解像度向上
    - チーム内分業が進むと他の人のタスク把握が難しい
  - それぞれが自分のタスクで忙しいとフォローできない
マルチタスク回避
- マルチタスクはコンテキストスイッチが大きい
無駄な作業待ちタスク（在庫）の削減
- 中途半端に着手しても停滞すると鮮度が落ちてやり直しが必要になる
  - 忘れる
  - 要件が変わる
  - 他の開発の取り込み・再テストが必要になる（在庫管理コスト）

ペアプロ、モブプロ

実践したことがない現場だと一見「複数人で時間を合わせて1つのタスクを行うのが効率悪い」というイメージを持たれがちですが、実はフロー効率とリソース効率の両方を上げる効果のあるプラクティスです。

レビューの削減
- レビューのために担当者間で受け渡す作業・説明が不要になる
- 実装中にお互いが意図を理解しながらコードを最適化して進められる
- 別途レビューする時間を取る手間、意図を読み取る/質問で理解する時間、指摘による手戻りの時間の削減
引継ぎ・共有のオーバーヘッド削減
- 担当者の突発的な休みや異動・離任時の作業引き継ぎの負担が減る
- ペアプロにより相互理解している状態であれば引き継ぎが不要
- モブプロにより内容を共有すれば、作る→(説明準備をして)説明会を開くの2ステップがなくなる
- それぞれがカバーできる領域を広げてシングルポイントの解消につながる