Mobius Outcome Delivery
先日Mobius Outcome Delivery Practitioner 研修を受けてきました。
もともと気になっていたフレームワークであり、今回その研修を受けられるということで飛び込んでみました。
今回はMobius Outcome Deliveryについてや研修で得たものを残したいと思います。
Mobius Outcome Deliveryとは
Mobius Outcome Deliveryは価値を生み出すためのナビゲーターであり、戦略からデリバリーまでを繋ぎ、見えるようにするフレームワークです。「最小限のアウトプットで最大限のアウトカムを達成する」ことをゴールとしており、研修でも度々アウトカム(価値)という単語が登場しました。
アイデアをいかにシンプルに小さく実験するか、を問いながらメビウスの輪の形状をしたメビウスナビゲーターに沿ってプロダクト開発を進めていきます。
アウトプットよりアウトカム
たくさんの機能を毎日、毎週リリースしていることはとても効率よく動けいてるかもしれません。でもアウトプットが多いと価値が高いかというと必ずしもそうではないと言います。
研修ではWordはたくさんの機能があってもほとんどのユーザーは20%ほどの機能しか使っていない、という例が上げられました。実際ほとんどの企業はWordほどの機能を作りづつけていく時間などないので、いかにこの使われる20%の機能を見つけるのか、を考える必要があります。
アウトプットが多くても、やりたいことができなければ意味がなく、求めるアウトカムを達成できるための機能を作ることを目指そう、というのがMobius Outcome Deliveryの目指すところです。
余談ですが、この研修で出会った人と話していて、「最近10点満点の機能ってリリースしましたか？」という問いを投げかけられました。正直うーんと悩んでしまい、5,6点の機能をリリースしてることが多いのかも、つまりアウトプットが先行してるのかも、という気持ちになりました。「最近10点満点の機能ってリリースしましたか？」という問いかけは日々自分に問いたい。
メビウスナビゲーター
Mobius Outcome Deliveryは戦略からデリバリーまでを見えるようにするためにメビウスナビゲーターというものを用います。
https://gyazo.com/3ab5f9de08cb393c2defe54d2493c30b
メビウスナビゲーターは主に3つのセクションで構築されています。
Discover
ナビゲーター左側の青い部分。問題を設定、発見するフェーズ。なぜやるのか、誰に向けてやるのかといった問題設定と達成して得られる計測可能なアウトカムを見えるようにします。
Decide
ナビゲーター中央の赤い部分。問題を解決する方法を判断するフェーズ。アウトカムを達成するためにどんな方法があるのかを探し、解決する方法を判断します。
Deliver
ナビゲーター右の黄緑色の部分。決定した方法を実際にユーザーに届け、うまく行ったこといかなかったことを確認し学びを得ます。
ほとんどのプロダクトは作って終わりではなく、仮説→実験→計測→学び...このループを行なって改善を進めていくことになりますが、そのループを表現しているのがメビウスナビゲーターですね。
では各セクションについて、もう少し詳しくみていきます。
Discover
https://gyazo.com/6b54f87ecf0b948bf008fcdd4a511347
Discoverは問題やニーズを捉えるフェーズです。左上の WHY&WHOでは、誰に向けてどんな問題を解決するのか、を発見していきます。デザイン思考がこのフェーズで行なっていることになってきます。
そこから右下OUTCOMESに移って、その問題を解決して状態ってなんなのかを決めていきます。この時研修では「計測可能なアウトカム」という言葉がとても印象的でした。
問題を解決した状態はどうやったらわかるのだろうか、どうなったら成功と言えるのか、を決めていきます。確かに、ここを決めておかないとやってみても良い悪いの判断ができないですよね。
ただ最初のうちはアウトカムはとても曖昧なものであることが多い、なので分析に時間をかけすぎずに現時点でのベストな方法で実験をしてみよう、ということで方法を決めるフェーズに移ります。
Decide
https://gyazo.com/5bae156daabfe51fc670d906df2043a4
DecideフェーズはOptionsというフェーズで紹介されてる記事も多いかと思います。オプションというのは実際に問題を解決するために試してみたい自分たちのアイデアのことです。
アイデアは次のフェーズにおける実験につながります。この時、アイデアは出るものの自信が持てない時ってなんでだろうと思うの「やったことがないから」というのが一番の不確定要素なのだと思います。なので実際にやってみて証拠を作る、そのための実験に繋がるので「一番簡単に実験できる方法はなんだろう」を問うのが大事と話していました。
ここで早くやるコツとして待たずにできる方法を自分たちでやるというものがありました。確かに、誰かの承認を待ってたりしたら早く動けないですもんね。
Deliver
https://gyazo.com/9ac4250c4d121dbaa4466bfa7d1779c8
実際に実験を行う、決定したオプションをユーザーに届けるフェーズになります。ここはいわゆる開発のフェーズになってきます。スクラムで利用されるカンバンはここを見える化しているものだと思っており、馴染み深いフェーズかもしれません。
ここで小さく早く実験することで多くの学びが得られます。実際に作って届けるまでは仮説はあくまで仮説であり、それが間違っているのかどうかはわかりません。大きいものを作って仮説が間違っていた場合、もう手遅れ状態かもしれません。小さくてもニーズがあるとわかると次の一歩に自信が持てます。
このフェーズではいかにシンプルに実験できるかを問いながらユーザーに届け、実際に何が起きたのかを計測して学びを得ます。
学びを得て、そこからどうするか
実際にデリバリーし、ユーザーに届けた後はどうするでしょうか。
ここが個人的にメビウスナビゲーターで一番よくできてるなぁって思ってる部分で、ナビゲーターを見ると分岐が発生しています。
https://gyazo.com/f3c05fdc091593d278044defdace9eb5
実験をした結果、次の選択肢が生まれます
もっと作る
実験をしてみた結果、もっと提供するために再度開発などを行う
もっと探す
発見に戻り、別の問題を探す
ピボット
新しいオプションを生成するか全く別の方向にピボットする
これは自然とプロダクト開発で行なっていることかと思うのですが、個人的にはここが見えるようになっている＝自分たちはどういう決断をして次に進んでいるのか、がわかるようになっているのがとても気に入っています。
前に進んでいる、を実感するために
実際のところ全く0から作り始める場合を除いては、何か始める時は何かが元になって始まってることがほとんどだと思います。実は線になっていることが点になっているように見えてしまうことで、自分たちは何を目指しているのか、本当に前に進んでいるのかがわからなくなる感覚に陥ることって多いのかなって思っています。というか実際にそういう感覚に陥ってました。
そんな中でMobius Outcome Deliveryの思想に出会い、学んだことで、この前に進んでいる感覚を得られるヒントになるのではないか、と思っております。
プロダクト開発を行なっていて、実際にユーザーに使ってもらえる機能を提供できる時って意外と少なくて、作っても反応がイマイチだったり、全然想定通りに使われなかった、なんてザラにあるかなと。でもそれって失敗ではなく学びであり、じゃあ次どうするのかを考えられれば、自分たちは前に進んでいると思うんですよね。
さらにそれが正しい道を進んでいるという感覚を得るために、小さく実験をして行って自信をつけていけるようなチーム作り、プロダクト開発ができたら良いなぁと日々考えております。
そのためのヒントとしてMobius Outcome Deliveryを今後も実践していきたいと思っています。