まえがき
当記事はアメリカに拠点を置くアジャイル開発を支援するエージェンシー Ralley Software のチーフテクノロジストである Zach Nies氏の記事を許可の元、翻訳・再編した文章です*1。
日本でもソフトウェア業界をはじめ、関心が集まっている Lean Startup（リーン・スタートアップ）。無駄を徹底的に省くことに目が奪われがちですが、語源となったと言われている Lean Body（リーン・ボディ：引き締まった身体）を目指すためのダイエットに同じく、無駄がなくなることは結果であり、成果ではありません。リーン・スタートアップは正しいモノが生み出されることを成果とする、または正しいモノが生み出されるまでを支援する手法体系であり、正しくモノをつくるための方法論ではないと考えます。
"A company following the lean methodology is like a well-trained body - almost nothing but muscle. It can be large, like a bodybuilder, but only because it needs all those resources (muscles) to build the product customers want & need." ー The Lean Startup Circle Wiki / Misconceptions about Lean Startup
そんな中、原稿の記事を拝見し、リーン・スタートアップを主題としたものづくりにおける様々な現象の Framing（構成）と Unframing（分解）を繰り返し、意味性を追加する彼のメタ的視点に感銘を受け、翻訳を通じて読者のみなさまにご紹介をしようと思い立ちました。Product-Solution Fit という表現がありますが、その実現と効果的な検証のためには当記事も紹介されている Testing-Modeling Fit が必要不可欠だと確信しました。
その真髄は、結果の判断のみで「失敗した」と思考停止する状態を避けるための継続を促すフレームワークです。目先の利益や結果に捕らわれてしまい、失敗したから次の方法論へ…という悪循環に陥りやすい状態から脱却するためには、繰り返し実験をする、繰り返し努力をすることが重要だと考えます。
失敗するであろうと世間から言われてきたミドリムシ事業を発展させ、成功を収めている株式会社ユーグレナ― 代表取締役 出雲 充氏の言葉がそれを物語っています。
『例えば、「１回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99％は失敗する状況です。ではその状況であきらめずに２回挑戦した時の確率はどうなるか。２回とも失敗する確率は99％×99％＝98.01％です。つまり、成功確率は約２％（1.99%）となり、１％成功確率が上がります。３回、４回、５回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が１%の出来事は459回繰り返せば、失敗する可能性が１%」になるんです。』
これまで当ブログでご紹介してきた CPS仮説検証モデルを基軸に、繰り返しの実験をより生産的に実施するための「Frame-Build-Measure-Learn（構成-構築-計測-学習）」、ぜひご参考ください。
はじめに
著書『リーン・スタートアップ』で Eric Ries氏は Build-Measure-Learn（構築-計測-学習）のフィードバックループを提唱し、不確実性が高い状況下におけるものづくりの指針をアップデートしました。このフィードバックループの目的は前提となる思い込みやリスク、未開拓領域を知識に変え、不確実性が高い状況下でもチームやメンバーが効率的に前に進むためのイノベーティブな方法論として紹介されています。フィードバックループにおける最も大切な要因は学び（学習）や発見です。つまり、仮説となる思い込みや前提が実証あるいは検証されるまでの期間をどれだけ短縮しかつ無駄を省き、次に繋げるために有効活用できるのか、ということです。
言うのは易く行うは難し、という言葉があるようにこのような説明にはジレンマが生じます。 Build-Measure-Learn（構築-計測-学習）のフィードバックループを順番通りに着手し、学習の手前である実証や検証を目的とした実験の段階に突入すると多くの人がどのように実験をすればいいのかわからず、得られた結果が例え想定外であったとしても何を学びとすればいいのか確信が持てず、不確かな状況が続くことがあります。
但し、これは良い傾向にあると考えています。想定外の事情に直面することは正に実験の醍醐味であり、想定内の事情が起こった現象の背景や意図が理解できない状態よりも発見や収穫は多いはずです。設計や構築により多くの時間を費やすことに慣れている環境下では、学習期間に多くを費やすことに意味性を見出すことは難しいかもしれませんが、不確実性が高ければ高いほど、言葉を変えれば実証されていない要素が多ければ多いほど、このフィードバックループは有効だと考えています。
現時点で「フィードバックループの重要性は理解した、または理解している。では具体的にどのように実験や実証を通じて学びや知識を得れば良いのだろうか？」という疑問を抱いている方がいらっしゃると思います。ここで私が提案したいのは、フィードバックループのBuild-Measure-Learn（構築-計測-学習）には最も大事なステップである Frame（構成）が抜けているということです。私が提案する、「Frame-Build-Measure-Learn（構成-構築-計測-学習）」によって、今後実施される実験や実証をより効果的に消化することができると考えています。
Frame（構成）
新しく提唱したステップである Frame（構成）には2つの側面があります。課題の構成と実験の構成です。この2つのアプローチによって、以降の Build-Measure-Learn（構築-計測-学習）はより活きていきます。
課題の構成
実証や検証のためにモノをつくる前に、先ずはどのような学びを得たいのか、あるいはどのような課題を解決したいのか、という構成から始める必要があります。Build-Measure-Learn（構築-計測-学習）こそ Build（構築）からプロセスはスタートしていますが、思考順序は逆を進みます。 Learn-Measure-Build（学習-計測-構築）となり、仮説を軸とした学びや発見を得るためには、どのような実験を行えば、またはどのような計測をすれば対象の仮説が実証されるのかを先ずは考え、そのためのプロダクトやサービスを構築する、という手順です。
この構想そのものが Frame（構成）です。先ず始めに対象のユーザーに対して共感力を強め、顧客開発と共に顧客発見や理解を促進するような実験を検討していきます。昨今ではジャーニーマップなど優れた手法が紹介されているので、仮説ベースで可視化をし、ユーザーへの共感を強めていく準備を事前に進めることができます。アプローチすべき正しい課題や仮説を設定するためには、ユーザーへの共感こそが全てです。
実験の構成
では次に実験を構成するための手順をご紹介します。
- 背景：なぜそのような実験を試みようと思いましたか？なにを学び、そしてなぜ学びたいと思いましたか？これらの質問に対する回答を記載してみましょう。慣れない作業かもしれませんが、書くことによって学びや発見の可能性が更に広がります。
- 仮説：簡単にでも良いので、これから実施する実験への期待を考えてみてください。この場合の仮説とは、実験の想定結果です。科学実験と同じく、仮説が不在では実験後の結果の善し悪しの判断がつきづらくなってしまいます。
- 実験方法：考えられる実験方法や要素を洗い出してみてください。手順も詳細に書いてみましょう。これが最も重要です。後に言及する「Experiement Report（実験シート）」に従って各要素を書き出してみましょう。あわせて、実験の妨げや影響要因となるような可変要素も同時に把握することで、仮説の設定が容易になります。
- 期待する計測結果：定性及び定量の側面から実験を通じて仮説が実証・検証されたことを判断するための指標を書き出してみましょう。定量情報は「WHO（誰が）・ WHAT（なにを、なにが）・WHEN（いつ）」を明確にすることができ、定性情報はその背景にある「HOW（どのように）・WHY（なぜ）」を理解することができるため、双方の実験を推奨しています。
上記に記載の手順に従って各要素の洗い出しを進めることで、実験の最中に直面する想定外の現象に対しても冷静に検証を進めることが可能になります。人間の脳は検証の場において、目の前で発生する現象に対して疑いもなく期待していた結果だったと都合良く解釈してしまう癖があるようです。実験終了後にも必ず当シートを参考に確実に実験を振り返るように心掛け、失われかけた学びを取り戻すようにしましょう。課題と実験の Frame（構成）によって、その後の学びの質は決まります。
Build（構築）
仮説を軸とした学びや発見を得るためには、どのような実験を実行すれば対象の仮説が実証されるのかを先ずは考える…と前述しましたが、構築の対象となるプロダクトやサービスの目的は学習や発見の達成のためとして位置付けることができると思います。そのためには以下の3つのポイントを抑えておくと良いかもしれません。
1. 実験方法を考える
実験の構成が終わったら、次はデザインを施し、構築し、実際に運用するステージへと移っていきます。実験は細かければアジャイル開発に習って実験を細分化し、頻度を上げて実施してみましょう。但し、忘れてはならないのはすべての実験はひとつのプロダクトやサービスに紐付いていることです。得られた結果や学びを前に、正しい情報や必要とするデータに目が行くようにしましょう。実験終了後には次にすべきことが自然と明確になっている必要があります。もし不明確なのであれば実験方法から、ないしは仮説の設定から再考することを推奨します。
2. 実験の場をつくる
実験が大掛かりに、かつ複雑にならないように気をつけましょう。MVP という言葉があるように、可能な限り小さな単位で実験を計画・実行することで仮説が実証・検証しやすい環境をつくりだし、学びや発見を見失わないように心掛けます。対象となるプロダクトやサービスも同様に、小さくする必要があります。著者の推奨は、ペーパープロトタイプやランディングページです。どちらかで大半の仮説を実証・検証することができると思います。
3. 実験を行う
対象が整い、開始する準備ができたらいよいよ実験です。実験という言葉からはある程度の労力や準備が必要のように思えてしまうかもしれませんが、実際はユーザーインタビュー程度の負荷で実施できるサイズにまで最小化することを推奨しています。言わずもがな、一番の理想は最小の実験で最大の成果（学びや発見）を得ることです。
Measure（計測）
実験を行い、十分なデータや情報は揃いましたでしょうか？ここからは結果を計測するステージに入っていきます。実験の方法を考え、実験する際に事前にまとめた実験そのものの背景や仮説に立ち戻り、仮説を実証・検証する際に重要となる要素を事前に整理しておきましょう。
実験の場では実際にどのようなことが置きましたか？結果からはどのように仮説を評価することができますか？得られた結果は仮説を実証・検証するにあたって十分でしたか？ここでのポイントは、先ほどの実験シートにまとめた事前に期待していた結果と事後に発生した結果の差分を、可能であれば定量・定性の双方の側面から比較することです。
最後に、定量・定性データを整理し、最終的にどのような現象が発生したのかをチームメンバーに理解していただくために、ストーリーテリングの要領でストーリーにまとめて学びや発見を形式知化できるように工夫しましょう。もちろん、すべての結果を参照し、レポート形式にする必要はありません。サービスとして、ないしはプロダクトとして最も大きな収穫に関するデータや情報のみに絞り、やがてチーム全体の学びへと発展し、次のステップへ自然につながるような流れを生み出すようにしましょう。
Learn（学習）
Frame-Build-Measure-Learn（構成-構築-計測-学習）の最後のステップで期待される効果は、更なる実験の構想が浮かび上がること、ないしは次のステップに進むためのアクションが自然と明確になることです。実験の前にまとめた仮説と期待していた結果を実際の結果と照らし合わせてみましょう。なにが起こりましたか？時間やリソースを学びや発見のために費やしたのですから、得られた学びや発見は何でしたか？その学びや発見は、次に向けてどのように活かされるべきですか？次のステップはなにからはじめますか？
Experiment Sheet（実験シート）に戻り、上記内容と結果をまとめてチームメンバーに共有しましょう。これは、次のステップ、学びを得るために費やされたコスト、結果から得られた洞察などを含みます。実際の実験結果よりも、記載した洞察や学びのほうが価値がある場合が多いためです。
最後に、学んだことや得られたことを透明性を維持してチームに浸透させるかのように振る舞うように心掛けてください。オフィス内のワークスペース周辺に関連資料や写真などを貼ってみましょう。難しければ共有スペースにでも配置し、他者がいつでも閲覧できるように工夫してアクセシビリティを担保してみてください。結果としてそれぞれの立場から得られた学びや発見を独自で解釈し、自信の業務に活かすことができますし、予想もしていない第三者からの助言や追加の学びを共有してくれる空気を創りだすことができます。学びが多ければ多いほど、良いプロダクトやサービスは生まれます。
もちろん、チームメンバーと共同で実験を進めることが理想です。もし、実験から得られた学びや発見をサービスやプロダクトに最大限活かしたいのであれば、構築や計測をする前に実験と課題の構成をしましょう。そのための、Frame-Build-Measure-Learn（構成-構築-計測-学習）です。スピードも去ることながら、不確実性が更に高まりつつある昨今、我々のこの先の未来はこの思考回路に委ねられているのではないでしょうか。
関連記事：
*1:This article is copyrighted by Rally Software Development Corp. Used with permission.
