1. 目指す姿から、いまを眺める
新しい提案をすると、「それはいいですね」と言われる。説明も伝わっている。けれど、そこから話が進まない。
たとえば、そんな場面を考えてみる。提案する側は、もっと機能が必要なのか、価格を下げるべきなのかと考える。ところが相手は、導入したあと、誰が毎日の運用を引き受けるのかを気にしているのかもしれない。提案の中身と、相手が判断するために必要なものが、少しずれている。
私は、差分に気づくことこそ、ビジネスの始まりだと思っている。いま実際に起きていることと、こうなっていたらよいと思うこと。そのあいだを見ていると、誰にどんな働きかけが必要なのか、少しずつ見えてくる。
現在の姿をAs Is、目指す姿をTo Beと呼ぶ。私は、この二つを見るとき、To Beの側からAs Isを眺めてみる。目指す姿に立って現在を見ると、そこへ向かうために取り組むべき課題が見えてくる。
先ほどの提案なら、現状の問題は「導入が進まない」ということだ。ここで「顧客が無理なく使い続けられる状態」をTo Beに置いて、現在を眺めてみる。すると、取り組むべき課題は「使い続けられる運用をどう成り立たせるか」と捉えられる。目指す姿があることで、現在の何に働きかけるかが変わる。機能を増やすという案も、その課題に応えるかどうかから考え直せる。
差分は大きな隔たりばかりではない。欲しいものが存在していても、必要なときに使えないことがある。提供する側にとっては十分な説明でも、受け取る側には判断材料が足りない。ここでは、そうした位置やタイミング、認識の小さなずれを「オフセット」と呼んでみたい。
何かが決定的に欠けているわけでもないのに、うまくつながらない。その状態は、当事者にとっては当たり前になっていることがある。毎回、誰かが手間をかけてつないでいるので、仕事は一応回っている。外から見れば小さな差でも、その人は毎日そこで立ち止まっている。
2. ボトルネックをどう活かすか
To Beから課題を捉えたら、その実現を何が制約しているのかをたどっていく。そこで見えてくるのが、ボトルネックである。目指す成果に対して、全体の動きを制約しているもの。仕事が多く滞留している場所は候補になるが、忙しそうな場所が必ずしも全体の制約とは限らない。目の前の不便と、成果を止めている原因を取り違えると、改善したはずなのに全体は変わらないということが起きる。
私はボトルネックを見つけると、課題に応えるためにそれをどう利用できるかを考える。To Beから現在を見たことで、制約のどこに働きかければよいか、その手がかりを掴める。
たとえば専門家の確認時間が全体の処理量を決めているなら、その時間を専門家にしかできない判断へ使えるようにする。資料が揃うまで待たせたり、同じ確認を繰り返させたりしていないか。人を増やす判断の前にも、確かめられることがある。
TOC、制約理論には、制約を特定し、その能力を最大限に活かし、ほかの活動をそれに合わせるという考え方がある。必要に応じて制約の能力を高める段階も含まれている。「利用する」は、制約を永久に残すという意味ではない。まず、いまある制約を踏まえて全体をどう動かせるかを見ることだ。
3. 仮説を、顧客と確かめる問いにする
この視点を、事業の始まりにも持ち込めるのではないかと思う。冒頭の提案に戻ってみる。運用負担が導入を制約していると見立てたなら、「初期の運用を一緒に引き受ければ、相手は使い始められるのではないか」という仮説が生まれる。顧客にとって、よい機能があることと、自分の仕事で使えることには距離がある。その距離に気づいたことで、初めて提案に入ってくる仕事がある。
もちろん、その見立てが当たっているとは限らない。相手は別の理由で迷っているかもしれないし、そもそも私たちが望ましいと思ったTo Beを求めていないかもしれない。
そこで、仮説を確かめるための論点を設定する。論点は、次へ進むか、考え直すかを判断するための問いである。先ほどの例なら、「導入時の運用負担を引き受けることで、顧客は実際に利用を始めるか」が一つの論点になる。負担が理由だと話してくれることと、条件を変えたときに使い始めることは、分けて確かめる必要がある。
この問いを持って、顧客や、顧客になりうる人に会う。話を聞くだけでは互いに想像しにくいなら、コンセプトを見せる。提案の仕組みが成立するかを小さく実証するPoC、Proof of Conceptを行うこともある。ただ、仕組みが動いたという結果だけでは、顧客が使い、対価を払うかまでは分からない。何を確かめた実験なのか、その範囲は明らかにしておきたい。
実際に使う場面から学ぶ必要があるなら、MVP、Minimum Viable Productとして、検証に必要な最小限の製品やサービスを届ける。MVPの役割は、早く顧客の現実に触れ、観察した結果から次の判断を変えられるようにすることにある。
先ほどの仮説なら、最初から運用支援の全体をシステム化する必要はないかもしれない。対象と期間を絞り、人が支援する形で使ってもらう。そのとき、説明後の感想に加えて、実際に利用を始めたか、どこで手が止まったかを見る。継続や支払いを確かめたいなら、それが起こりうる条件まで実験を設計する。
4. 試した先に、次の差分が見える
たとえば、運用を引き受けても、利用は始まらなかったとする。ところが、一緒に作業するうちに、担当者が社内で説明できずに困っていたことが分かるかもしれない。そうなれば、次に確かめるのは、運用支援の量よりも、社内で判断できる材料のほうになる。
これは仮想の例だが、仮説と顧客の現実のあいだには、こうして新しい差分が現れる。その差から、最初の見立てを考え直せる。利用されなかった理由が、実験の条件にあったのか、顧客の望む状態を読み違えたためなのかは、さらに確かめる必要がある。一度の反応で原因が決まるわけではない。
それでも、相手と試したことで、次に話せる内容は変わっている。何を見て仮説を変えたのかが残れば、次の提案はその学びから始められる。同じように困っている人にも役立つか、自分たちが続けて届けられるかという検討へ進むと、個別の工夫から事業の形が見えてくる。
前作「差分は、ノイズではない」では、差分を消す前に、その意味を読むことを考えた。その意味を、顧客と確かめられるところまで進めてみたい。
差分に気づき、To Beから現在を眺めて課題を捉える。ボトルネックの活用に仮説が生まれても、まだ価値は私たちの頭の中にある。顧客と試すことで、その人の仕事や暮らしに何をもたらすのかが見えてくる。そこで得た理解を次の具体へ戻していくことが、ビジネスをつくる仕事なのだと思う。
大きな市場の空白を発見したときだけ、ビジネスが始まるわけではない。誰かが毎日引き受けている小さな手間や、よいと思っているのに進められない事情。その差分に気づいたところから、始められることがある。
次に顧客と会うとき、その人と実現したい状態から、いま話が止まっている場所を眺めてみる。そこに見える課題について、相手と何を確かめてみたいだろうか。
参照
TOC Institute — Five Focusing Steps →
制約の特定・活用・従属・能力向上・再確認の考え方。
AWS — Generative AI: Getting Proofs of Concept to Production →
PoCの実証から、利用や価値の検証へ進む際の論点。
The Lean Startup — Principles →
MVPと顧客から学ぶ検証の考え方。