「思い込み」でサービスをつくることは必ずしも悪いわけではない

但し、

  • 「思い込み」であることを自覚すること
  • 「思い込み」は実証されるべきであること

が前提として成立すると思っています。

サービス開発における2つのアプローチ

弊社コンセントのラボにも掲載されている「カスタマージャーニーマップのパターン」でも解説していますが、カスタマージャーニーマップ、つまりは顧客の体験や感覚を可視化するサービスデザインの手法のひとつとして企業が組織として顧客視点/ユーザー視点を維持し、サービス開発を支援するツールには2つの視点が存在します。

一つ目の軸は、Inside-out/Outside-inの視点。
Inside/Outsideとは事業者からの視点として、「自社事業の観点から=Inside-out」と、「自社事業の外側の観点=Outside-in」となる。ここではサービス事業者の観点となるから、Outside-inは、サービス利用者の観点となる。

自社事業観点のCJMとは、「サービスがどのように利用されるか」を示したものとなる。
CJMの特徴として、顧客の体験や感情などが記されることがあるが、Inside-out型のCJMでは、そのサービスでも顧客はどう感じているのかを把握することができる。ー カスタマージャーニーマップのパターン | ラボ | 株式会社コンセント

よってサービス開発はインサイドアウト(Inside-out)またはアウトサイトイン(Outside-in)のいずれかから始まると考えることができます。

多くの場合は前者で進行することが多いのではないでしょうか。著者が担当している新サービス開発支援プロジェクトでも多くがインサイドアウトのアプローチを実践しています。ところが、自社事業の観点からサービスを開発するもアウト(顧客)との Problem-Solution Fit(課題と解決策のマッチング)が成立しなければ意味がありません。後ほど詳しく述べたいと思います。

後者はオープンイノベーションとして位置付けられているプロジェクトに多く見られます。IDEO が展開している IDEO.org もその一例です。国内では NEC やパナソニックが関連特許を無償化し、アウトサイドインのアプローチを推進しています。

デザインとアート:アウトサイドインとインサイドアウト

デザイン的活動を「問題解決」と表現することがあります。顧客が潜在的に抱えている課題を特定し、解決手段を模索する行為は問題解決そのものであり、デザイン思考のルーツもロジカルシンキングに習っていると言われています。

f:id:separate-ks:20150418130658p:plain

問いを見つけることと問いに応えることがデザインの役割であるならば、アートは問いを問うことであると考えます。一見対極にあるように見える両者ですが、必ずしもそうではありません。デザインはもはや現代社会における決定的な差別化要因ではないと話すジョン・マエダ氏はデザインとアートの関係性を以下のように捉えています。

デザイナーが生み出すのが「解決策(答え)」であるのに対し、アーティストが生み出すのは「問いかけ」である。(中略)いま彼らー顧客ーが求めているのは、自分の価値観を思い出させてくれるような方法ーーつまり、この世界のなかでどのように生きることが出来るか、どう生きるつもりか、どう生きるべきかという価値観を思い出させてくれるものである。ー ジョン・マエダの考える「デザインを超えるもの」 « WIRED.jp

当ブログでも何度も言及している人間中心設計(Human Centered Design)ないしはユーザエクスペリエンス・デザインは「解決策(答え)」を導くアウトサイドインのアプローチ/設計思想です。

ところが、それだけでは差別化が図りにくく、誰もが同じ答えに辿り着いてしまう可能性があり、納得が行く解決策(答え)に至らないケースが多々あります。エンドユーザーからの価値や洞察の抽出には限界があり、答えにつながるエッセンスをすべて彼らに委ねることはほぼ不可能です。車が無かった時代に要求事項を探っても、車の開発に直結する解決策は導くことはできません。

著者が担当するプロジェクトでもイノベーティブなアイディやないしは製品の開発支援を求めるクライアントが多く、アウトサイドイン「のみ」のデザイン・アプローチでは期待に100%応えることが難しい場合があります。一方で、思い込みや仮説から立案された新規事業の開発支援では、未実証の項目が多いもインサイドアウト、問いを問うアートの設計思想に従って進めることができます。

これまでは著者含め多くのユーザエクスペリエンス・デザイナーは未実証項目ドリブンでコトが進むことに違和感を覚え、反抗する姿勢を見せていました。思い込みだけで設計や開発を進めることに嫌気が差し、ユーザー調査などのリサーチありきでやるべきである、先ずはユーザーに聞いてみましょう、などどいったブレーキをかけていました。

アウトサイドイン型である Problem-Solution Fit(課題と解決策のマッチング)のアプローチを批判しているわけではなく、イノベーションを促進し、差別化を図っていく上では製品開発よりも顧客開発が有効です。プロダクトやサービスは、何をつくるべきかを教えてくれるものでなければなりません。プロダクトやサービスは、そのためのひとつの手段であり、デザインもひとつの手段だと考えています。

アーティスト的思考のスペキュレーティブ・デザイン

スペキュレーティブ・デザインとは、空論の、未来のシナリオをデザインするための考え方です。既存の価値や信念、態度を疑い、様々な代替の可能性を提示するためのコンセプトとして注目を浴びています。

 

Speculative Everything: Design, Fiction, and Social Dreaming

Speculative Everything: Design, Fiction, and Social Dreaming

 

 

例えば、スマートフォンなしの生活は考えられないと思いますが、逆に保持することで大切な喜びをもたらしてくれているでしょうか?そもそもスマートフォンにはどんな価値が存在し、その価値はどのようにして取り戻せられるのかを考え、思想や思い込みを作品としてないしは製品として提示する。正に問いを問うアーティストのような発想がスペキュレーティブ・デザインと言われています。

問いかけは思い込みがあってこそ成立すると思っています。もっと言えば思い込みがなければ未来のシナリオをデザインすることができないのではないでしょうか。アップルのスティーブ・ジョブスはデザインの心得を大切にしていたことで有名ですが、その斬新な発想と彼なりのビジョン、思い込みはアーティストそのものでした。

アウトサイドインのデザインアプローチが Problem-Solution Fit(課題と解決策のマッチング)であるならば、インサイドアウト型であるスペキュレーティブ・デザインのアプローチは Vison-Customer Fit(ビジョンと顧客のマッチング)と言えるかもしれません。

f:id:separate-ks:20150418171230j:plain

結果、これからのデザイナーにはアーティストとしての要素が求められているのではないでしょうか。

まとめ

冒頭に戻りますが、思い込みがでサービスをつくることは必ずしも悪いわけではありません。インサイドアウトのアプローチですべてのサービスがつくられるべき、というわけではありません。

一番のリスクは思い込みだと自覚せず、ファクト(事実)として錯覚してしまうことです。そして、例え自覚していても実証せずに思い込みのままで終わってしまうことです。

実証には事前であれ事後であれ、アウトサイドイン(Problem-Solution Fit)のアプローチを採用すべきであり、著者含むユーザエクスペリエンス設計業務を担当する人は思い込みが発生した時点で「待った!」のブレーキをかけずに実現を構想に落とすための手段を考えるべきだと思います。「待った!」と思い立つこともひとつの思い込みであるという自覚が必要です。

  • 思い込みはなにか?
  • ファクト(事実)はどれか?
  • アイディアはなにか?

この軸で情報を整理し、製品を介した顧客の価値創出という名の顧客開発をどのように進めていくべきか?

これが今正に求められているデザインの役割なのではないでしょうか。

関連記事:

LEAN UX Japan Conference 2015〜LEAN UXが拓く未来〜

書籍「Lean UXーリーン思考によるユーザエクスペリエンス・デザイン」を基点に LEAN UX を実践・普及させることを目的とした有志による団体 Lean UX Circle の活動開始から約半年が経過しました。

f:id:separate-ks:20150312125005j:plain

活動中はファシリテーター制度を導入し、参画している企業担当者が自身でミートアップを企画し、イベントを開催する取り組みを月に1回の頻度で開催してきました。また、2014年冬からはワーキンググループ形式で複数の企業担当者を集めたコラボレーションを主体としたツールや方法論の制作・開発などを行ってきました。

そして2015年4月11日ではその集大成となる Lean UX Circle 主催の国内カンファレンスLEAN UX Japan Conference 2015〜LEAN UXが拓く未来〜を開催します。

f:id:separate-ks:20150312125110j:plain

日程:4月11日(土)
時間:13:30〜19:00(懇親会:19:00〜21:00)
会場:リクルート アカデミーホール
申し込み・プログラム:公式サイトをご覧ください

書籍「Lean UXーリーン思考によるユーザエクスペリエンス・デザイン」が刊行されてから1年以上が経過し、当ブログでも以前ご紹介したように様々な企業による取り組みがなされてきました。

本カンファレンスではこの1年間の各社による取り組み例をご紹介すると共に、組織への導入にあたっての課題解決に向けたヒント、並びに LEAN UX を取り囲むように誕生した、グロースハックやデザインスプリントのコンセプトをご紹介しながら、改めてLEAN UX の思想とその価値を参加者のみなさんと一緒に再発見・拡大していきたいと考えています。

400名以上の方が参加された昨年の LEAN UX 刊行記念セミナーとは異なり、今年は LEAN UX のオントロジーに主軸を置いたプレゼンテーションないしはディスカッションを主体としています。

開催背景と想い

LEAN UX はやり方ではなく、あり方です。手前味噌ですが、書籍が刊行されてから多くの企業様にお声がけいただき、ワークショップやプレゼンテーション、パイロット・プロジェクトをご一緒させていただいたと共に、様々なイベントで参加者の方々と意見交換をさせていただきました。

実に多かった意見として、

  • 構想に時間が要され、開発や実装との連動が難しく優先度が下がってしまう
  • 効果が見えにくい 

などがありました。 

LEAN UX は、他で言及されているようなデザインスプリントなどの手法とは異なり、マインドセットやコンセプトであると考えています。

それは、エンドユーザーにとって正しいプロダクトやサービスをつくることを念頭に置いた、組織における共創の文化を再確認・浸透させるための考え方であり、本来の組織としてあるべき姿を提示してくれる指針でもあります。

Lean Startup のルーツであるリーン生産方式は、無駄を省くことを徹底していましたが、誰にとっての無駄なのかを取り違えてしまうとスピードのみが重視され、かつ短期における結果を求める姿勢が強まってしまうことが背景としてあります。この「誰にとっての無駄なのか」を正すためにユーザー視点を取り入れた LEAN UX の思想が必要だと考えています。 

そのため、短期間で効果を期待するものではありあせんし、一度の実践では本質な価値が見出だせない可能性があります。

だからこそ LEAN UX の思想や価値を再確認し、再び探求していく必要性があるのではないかと考え、Lean UX Circle として本カンファレンスを開催する運びとなりました。

継続する努力

パレートの法則ではありませんが、Bloomberg の調査によると新規事業やスタートアップが18ヶ月で成功する確率は20%と言われています。ポイントは、18ヶ月という調査ながらも設けた期間が1年以上であることと、20%という数字です。

一時的な結果として捉えた場合に、20%という数値は低いですが、成功する確率を高める方法は継続だと考えます。もちろん、そのためにはプロダクトやサービスに込められた想いが大切であり、かつ継続するためのエンジンとなる軸を設ける必要があります。

答え合わせをするために無暗に回答を続けるのではなく、正しい答えを導きやすくするための仮説の設定と間違った理由を探るための視点を養うことができれば、数少ない回答で正解することができます。LEAN UX で度々ご紹介している CPS仮説検証モデルが、それに値します。 

話を少し戻すと、成功する確率を高めるためには一定の継続が求められます。ミドリムシビジネスで成功を収めているユーグレナ社長の出雲 充氏が提唱する実にシンプルな理論に納得が行きます。

例えば、「1回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99%は失敗する状況です。ではその状況であきらめずに2回挑戦した時の確率はどうなるか。2回とも失敗する確率は99%×99%=98.01%です。つまり、成功確率は約2%(1.99%)となり、1%成功確率が上がります。3回、4回、5回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が1%の出来事は459回繰り返せば、失敗する可能性が1%」になるんです。

失敗率99%のミドリムシ事業を成功させた男の"シンプルな法則" | Biz/Zine

 

失敗する確率が20%であろうと1%であろうと、数値のみで姿勢を変えるのではなく、継続して成功する確率を上げる努力と継続を支援するために LEAN UX があります。本カンファレンスでは大企業からスタートアップまで組織の規模や役職を問わず、LEAN UX の継続的な実践と実現をテーマとした様々な方のプレゼンテーションやディスカッションを行います。 

最後に

LEAN UX では構想のイメージが先行してしまいますが、書籍でも言及されているようにスタッガードスプリントの代替ソリューションとなるようなスプリントをはじめとする、構想から実現までを捉えた組織としての取り組み全体を視野に入れており、正しくモノをつくるためではなく、正しいモノをつくるための組織文化の醸成が価値に値します。

前後の工程を通じて同じ仕組みやプロセスを導入していないことを問題視するのではなく、同じ思想(想い)を用いてプロダクトやサービス開発に取り組めているかを考えるべきです。

結果として手法やプロセスも、以前ブログでもご紹介した人間中心設計の共通言語化に通じますが、組織ごとに異なるはずです。昨今話題のデザインスプリントも、Google Ventures が自身の組織ないしは自身がパートナーとして参画している組織形態に最適化するように設計されているがために、そのまま仕組みとして己の組織に導入することは創造性に欠けています。

このようなプロセスや手法の登場に伴い、組織への導入が騒がれると導入後の評価はプロダクトやサービスではなくプロセスや手法を軸に判断されてしまう恐れがあり、ユーザー視点が欠けてしまいます。

仕組み化は組織の状況にあわせて行われるべきだと考えます。そのような事態から打開すべく、本カンファレンスでは LEAN UX という思想をご紹介しながらものづくりや組織におけるやり方ではなく、本来のあり方を模索できればと考えています。

ぜひ、ご参加ください。

関連記事: 

リーンスタートアップのリフレーミング:Frame-Build-Measure-Learn(構成-構築-計測-学習)

まえがき

当記事はアメリカに拠点を置くアジャイル開発を支援するエージェンシー 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回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99%は失敗する状況です。ではその状況であきらめずに2回挑戦した時の確率はどうなるか。2回とも失敗する確率は99%×99%=98.01%です。つまり、成功確率は約2%(1.99%)となり、1%成功確率が上がります。3回、4回、5回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が1%の出来事は459回繰り返せば、失敗する可能性が1%」になるんです。

失敗率99%のミドリムシ事業を成功させた男の"シンプルな法則" | Biz/Zine

これまで当ブログでご紹介してきた CPS仮説検証モデルを基軸に、繰り返しの実験をより生産的に実施するための「Frame-Build-Measure-Learn(構成-構築-計測-学習)」、ぜひご参考ください。

f:id:separate-ks:20150227173049p:plain

はじめに

著書『リーン・スタートアップ』で Eric Ries氏は Build-Measure-Learn(構築-計測-学習)のフィードバックループを提唱し、不確実性が高い状況下におけるものづくりの指針をアップデートしました。このフィードバックループの目的は前提となる思い込みやリスク、未開拓領域を知識に変え、不確実性が高い状況下でもチームやメンバーが効率的に前に進むためのイノベーティブな方法論として紹介されています。フィードバックループにおける最も大切な要因は学び(学習)や発見です。つまり、仮説となる思い込みや前提が実証あるいは検証されるまでの期間をどれだけ短縮しかつ無駄を省き、次に繋げるために有効活用できるのか、ということです。

言うのは易く行うは難し、という言葉があるようにこのような説明にはジレンマが生じます。 Build-Measure-Learn(構築-計測-学習)のフィードバックループを順番通りに着手し、学習の手前である実証や検証を目的とした実験の段階に突入すると多くの人がどのように実験をすればいいのかわからず、得られた結果が例え想定外であったとしても何を学びとすればいいのか確信が持てず、不確かな状況が続くことがあります。

但し、これは良い傾向にあると考えています。想定外の事情に直面することは正に実験の醍醐味であり、想定内の事情が起こった現象の背景や意図が理解できない状態よりも発見や収穫は多いはずです。設計や構築により多くの時間を費やすことに慣れている環境下では、学習期間に多くを費やすことに意味性を見出すことは難しいかもしれませんが、不確実性が高ければ高いほど、言葉を変えれば実証されていない要素が多ければ多いほど、このフィードバックループは有効だと考えています。

f:id:separate-ks:20150227173453p:plain

((c) Ralley Software Development Corp.)

現時点で「フィードバックループの重要性は理解した、または理解している。では具体的にどのように実験や実証を通じて学びや知識を得れば良いのだろうか?」という疑問を抱いている方がいらっしゃると思います。ここで私が提案したいのは、フィードバックループの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.

This work is licensed under a Creative Commons Attribution 4.0 International License.
Others, like quotes and images belong to its original authors.