リーンなスタートアップの『流れ化思考』:流れの見える化から流れ化まで

DevOpsバリューストリームマッピングカスタマージャーニーマップエクスペリエンスマップユーザーストーリーマッピングカンバンフロー効率性顧客ファクトリー…。これらの新製品開発のプラクティスを見ていると、これらに共通するのは「流れ」に着目することなのかなと感じています。

たとえば、リーンキャンバスの提唱で有名な Ash Mauyra は『リーンスタートアップ成長戦略』で顧客ファクトリーの概念を提示し、トラクションの流れの作り方を TOC の考え方をベースにしながら語っています。

作業やビジネスの流れに注目することで、「どこに淀みがあるのだろう」という発想に自然となったり、Maurya がやっているように TOC やリーン生産方式の考え方を応用できるというメリットがあります。

この記事は、冒頭に挙げたプラクティスを一段抽象化して、スタートアップでも『流れ化』の考え方を様々な領域で適用してみると、より「リーンな」スタートアップになれるのでは、というものになります。

流れへの注目の源流:リーン

リーンシンキングLearning to See などをはじめとしたリーン生産方式の文脈で、「流れ化」や「整流化」という概念はありました。これらでは流れ化を「一つのものが一つの工程から次の工程へと停滞なく(ムダなく)進んでいくこと」、理想的には一個流しを目指すこととされています。

そのためにバリューストリームマッピングを使って「モノ」と「情報」の流れを見える化し、現在と将来の二種類の価値の流れをより効率的にしてこうとしています(本記事題の「流れ化思考」もリーンシンキングの本から取ってきたものです)。

これらの考え方をソフトウェア開発に応用しようとしたのがリーンソフトウェア開発で、フローのモデルと整理されることもあるようです。

ミクロで言えば日常業務でも定常的な業務をワークフローに落とし込んで自動化や効率化していく手法は普通に使われていますし、マクロで言えばバリューチェーンなども流れに注目していると言えます。

なので、流れに着目すること自体は別段新しいことではありません。

ただもし最近の流れを重視する潮流で、新しいことがあるとすれば、現在は以下の特徴があるように思います。

  1. 主にソフトウェアが関わる製品開発やサービス設計、UX という抽象度のレイヤーで価値や体験の流れを見える化して、『独自の価値の流れ』を意識しようとしている (Customer Journey Map や Experience Map など)
  2. 「エンドユーザーへ提供する価値」や「顧客からの需要」などの不確実性の高い部分までを流れに含んだ上で、アイデア(仮説)発想から開発、そしてユーザーへのリリースまでの『独自のやり方の流れ』を全体最適化していくというスコープで流れを把握しようとしている (Value Stream Mapping や顧客ファクトリーなど)
  3. 定型的な処理の流れだけではなく、間違っている可能性の高い仮説を何度も流す(イテレートする)ことを前提としながら、「検証による学び」の高速化と「顧客スループット」の増大に徐々にたどり着いていくことを前提としている
  4. これらを効果的に実現するための『タスクの流れ化』の方法を模索している(Kanban など)

ここでの「独自の価値」と「独自のやり方」という言葉は、『マイケル・ポーターの競争戦略』で指摘される戦略の条件の「独自の価値提案」と「それを実現するのに必要な、特別に調整されたバリューチェーン」から取ってきています。また 3 つめのポイントはリーンスタートアップからです。

冒頭に挙げた一つ一つのプラクティスも重要だと思いますが、少し抽象化して、様々な領域でこうした「流れ」に着目することで、色々な洞察を引き出せるだけではなく、リーンスタートアップのベースとなった「リーン」の考え方をより広くスタートアップに応用することができるのかなと思っています。

「流れの見える化」から「流れ化」へ

こうした流れを把握するためにはどうすればいいのかというと、大きく二つのステップがあるように思います。それは大きく二つ、

  1. 流れの見える化
  2. 流れ化

です。

1. 現在の流れを見える化する

そもそもの流れを見える化するためにも、活動やムダを把握するーーつまり見える化する必要があります。ここでのムダとは顧客に何も価値を生まない活動、たとえば人の移動などを指します。

以下はバリューストリームマッピングの例です。こちらでは「モノと情報」の流れを時間(リードタイム)とともに図示しています。

https://commons.wikimedia.org/wiki/File:ValueStreamMapParts.png

こうしてフローを図示すると、どこでどれだけの時間がかかっているかが分かります。

製造業だけではなく、これはソフトウェア開発でも同様の図を描けます。以下はリクルートの黒田さんが描いた図です(厳密には VSM とは異なるとは思いますが…)。

http://i2key.hateblo.jp/archive/2017/05/15

VSM を書くときのポイントは以下でまとめられています。

また体験や価値の部分では、カスタマージャーニーをはじめとして、流れを『見える化』することで、チーム内での議論を生むツールとして使われることも多くあるようです。

たとえばカスタマージャーニーは特定の原型となる体験を、エクスペリエンスマップは一般的な体験を図示します。

https://www.slideshare.net/AdaptivePath/mapping-experiences-and-orchestrating-touchpoints-chris-risdon-patrick-quattlebaum-ux-week-2012/12

こうした流れの見える化を踏んだ後、流れ化はそれから一歩進んで、「見える化した流れ」をより淀みなく流せるような改善を加えていきます。

特に VSM では「現在の流れ」と「将来の理想的な流れ」の両方を書くことがオススメされています。またこうした流れを整理するときには、顧客のニーズや顧客からの学びから出発する「プル」の考え方で整理すると良いのではと思います。

2. 流れ化する

価値の流れにせよ、やり方の流れにせよ、流れ化のために注目するところは、おそらくムダとボトルネックです。ムダを排除したり、ボトルネックを学習/活用/強化 (GO LEAN の L) するための改善を繰り返すことで、流れを良くすることができます。

(本来的な流れ化は「1個流し」を目指すものですが、ここでは少し広く意味を取って、流れを良くする、という解釈で勧めます。)

流れを良くするためには、

  • 流れの安定化
  • 流れのスピード化

の二つが重要であることが、『よくわかる「流れ化」の本』で指摘されています。

カンバン』でも品質を向上させることに最初注力することが指摘されていますが、これは品質が高まることで欠陥によるムダやバラツキなどが抑えられ、流れの安定化に貢献するからです。流れが安定していると、途中の工程の監視やチェックの工数が不要になります。

またバッチサイズを小さく、かつWIP 制限をかけることで、リソース効率は下がりますが、フロー効率性は上がる傾向にあり、流れのスピード化を助けてくれます。

とりあえずはこの「安定化」「スピード化」の二つに着目しながら流れ化を目指していくのが良いのかなと思います。

流れ化の考え方を活用して、よりリーンなスタートアップになる

冒頭に挙げた一つ一つの具体的なプラクティスにこだわらず、「流れ」と「流れ化」という一段高い抽象度で考えてみると、様々な課題と改善点が見つかります。

この記事では触りだけを書きましたが、より詳しいところはリンクの張ってある本などに詳しいです。

大企業で淀みのない流れを追求すると、意思決定、ひいては組織の問題になりがちですが、スタートアップではそうしたことが起こりづらいはずです。

だからこそ、スタートアップでもこうした流れと流れ化を意識した価値の提供や作業の整理をしてみると、より「リーンな」スタートアップになれるのではと思い、少し記事にまとめてみました(先日の Lean Sartup Update! 2018 の p. 48 の補足でもあります)。

Written by

The University of Tokyo, Ex-Microsoft, Visual Studio; “Nur das Leben ist glücklich, welches auf die Annehmlichkeiten der Welt verzichten kann.” — Wittgenstein

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store