コネヒト開発者ブログ

コネヒト開発者ブログ

仮説→実験→検証→学び...プロダクト開発のループを実現するために行っていること

こんにちは! @TOC@takapy です。

最近は期の終わりも近づいてきたので、普段利用しているREALFORCEのキーボードを大掃除しました。めっちゃ綺麗になって気分も一新できたので、定期的にやらねばと思いました。いつもありがとうREALFORCE!

さて、今回はプロダクト開発においてMobius Outcome Deliveryの思想を取り入れた話をご紹介しようと思います。

私は7月にこのMobius Outcome Delivery研修を受け、実際にこの考えをプロダクト開発に取り入れてみることでプロダクト開発をする上で感じていた課題感を解消できるヒントになるのではないか、と思いました。

Mobius Outcome Deliveryとは何なのか、またその思想を実際にプロダクト開発においてどう取り入れたのかの具体的な事例について興味ある方の参考になれば幸いです。


目次


Mobius Outcome Deliveryとは

Mobius Navigator(https://www.mobiusloop.com/)

www.mobiusloop.com

Mobius Outcome Deliveryは価値を生み出すためのナビゲーターであり、戦略からデリバリーまでを繋ぎ、見えるようにするフレームワークです。「最小限のアウトプットで最大限のアウトカムを達成する」ことをゴールとしており、研修でも度々 アウトカム(価値) という単語が登場しました。 アイデアをいかにシンプルに小さく実験するか、を問いながら上図のようなメビウスの輪の形状をしたMobius Navigator(メビウスナビゲーター)に沿ってプロダクト開発を進めていきます。

プロダクト開発のループを大きくDiscover, Decide(Options), Deliverの3セクションで表現しており、プロダクト開発における羅針盤的なものになり得るフレームワークになっております。

弊社では「プロダクト開発は作って終わりではない」とよく言われています。Mobius Outcome Deliveryはその言葉を表現できるフレームワークである点が一番気に入っています。 ユーザーに届けて終わりではなく、届けた結果どうなったのか、そこから学びを得て次に何をやるのか、を意識できるようになっており、プロダクト改善におけるループを辿っていけるフレームワークとなっております。

当時の課題感、何がやりたかったのか

弊社では現在、アジリティが全社におけるキーワードとなっており、チームでもいかに小さく実験していけるか、が関心ごととして強くなっています。

その際に「仮説を立て、実験し、検証する」のサイクルを回しているのですが、下記のような課題感を感じておりました。

  • 各実験が点になっていて繋がっていないのではないか、繋がっていたとしてもそれが見えていないのではないか
  • なんとなく進みが遅いと感じるが、どこがボトルネックになっているのか特定がしづらいのではないか
  • やったことがチーム内に閉じていて、その知見をチーム間や将来の誰かのために活かせられてないのではないか

当時、プロダクトマネジメント本の輪読会を行ったメンバーとプロダクト開発におけるプロセスの改善を行おうと思ったときに課題感を擦り合わせたのですが、上記3点がほぼ同じ課題感として挙がっており、「仮説→実験→結果→学び→仮説 … のループを回したい、それを見える化したい」という共通の思いが一致したので、これを実現できる方法を模索することになりました。

解決に向けて、方法の模索

Mobius Outcome Deliveryが仮説→実験→結果→学び→仮説 … のループをうまく表現していると思ったので、この研修で得たものを共有し、どうやってこの思想を表現できるか、プロダクト開発に取り入れられるか、を考えてみました。

そこでこの思想をプロダクト開発に取り入れるためのツールとして、 Miro など色々な方法を模索したのですが、Notionのプロジェクト管理テンプレートが一番やりたいことを実現できるのではないか、と思いました。

www.notion.so

Notionのプロジェクト管理は1つのプロジェクトに対して複数のタスクが紐づく形で構成されています。

Notion Projectについて

これを弊社のプロダクト開発に応用して、1つのやりたいこと、達成したい価値に対して実験を紐づけることでやりたいことができるのではないか、と考えました。

実際に作成したものをもとにどう実現したのかを具体的に説明します。

Mobius Outcome Deliveryを実現するために、どうやってNotionを活用したのか

以下Mobius Outcome Deliveryを実現する上でポイントになる点に絞って説明していきます。

Discover:テーマを作成する

Discoverの道のり

まずは上図の左側、Discoverの部分です。ここでは「なぜやるのか、誰に向けてやるのか」といった問題設定を行い、それを解決した際に得られるアウトカム、を決定します。

この部分をNotion Projectsにおける プロジェクト として作成します。これを自分達は テーマ と呼ぶようにしました。

データベースから新規テーマを作成すると下記のようなテンプレートが表示されます。

テーマのテンプレート

このテンプレートを埋めていくことでMobius Outcome Deliveryの左側Discoverを辿っていく形式になります。

Options, Deliver:実験を作成する

Options, Deliverの道のり

実際にやりたいことが定まったら、実現するための実験を考えていきます。

どうやったら一番シンプルに簡単に実験できるかを考え、やることが決まったら実験を作成します。

実験の作成

実験を作成するボタンを押すと、このテーマに紐づいた実験が作成されます。

実験はテーマが紐づいた状態で作成されるので、この実験は何を実現するためのものなのか、といった紐付けが見えるようになります。

このドキュメントは弊社では実験ドキュメントと呼ばれており、どうやって実験するのか、この実験で得た学び、などを記載できるようになっています。

この実験ドキュメントについては後の章で詳しく説明します。

テーマと実験の紐付け

実験が終わり、学びを得たら、次の一手を決めていきます。

Decide:もっと作るのか、別の問題を見つけるのか

Decideの道のり

実験をしても必ずしもうまくいくとは限りません。やってみて実際に得た反応をもとにもっと作っていくのか、はたまた別の問題を見つけるのか、といった選択をする必要があります。

これはMobius Outcome DeliveryでいうDecideのフェーズであり、ここで分岐が発生します。 この次への繋がりが一番実現したかった部分であり、今回のこだわったポイントでもあります。

私たちはこの繋がりをNotionのリレーションを用いて表現しました。

1. もっと作るという判断をした場合

例えば実際にユーザーに使ってもらい反応をみた際に、ニーズはありそうだが、少し別の形で実装をしてみたい、と思ったとします。Mobius Navigatorでいうところの再度Createのループに入るイメージです。

もっと作る判断をした場合

この時は実験ドキュメントで「次の実験を作成する」ボタンを押します。

次につながる実験を作成する

これを押すと2回目の実験が作成され、 前の実験 プロパティに1回目の実験とのリレーションが作成されます。

このリレーションにより2回目の実験は何を根拠に生まれた実験なのか、の繋がりを表現できるようになりました

実験の繋がり

2. 別の問題を見つけるという判断をした場合

実際にユーザーに届けてみるとニーズがないことがわかったり、実験をすることで別の問題を見つけることもあります。次に繋がる実験だったということですね。

この時Mobius Navigatorでいうところの再度Discoverのループに入るイメージです。

別の問題を見つけた場合

テーマのドキュメントに戻るとネクストアクションが設定されています。ここで「次のテーマを作成する」ボタンを押すと、次に繋がるテーマが作成されます。

次に繋がるテーマを作成する

このリレーションが作成することで、テーマ間での繋がりも作成されます。

こうすることで下図のように1つ1つのループにおける繋がりも表現できるようになりました。

ループが繋がっていくイメージ

まとめると

テーマと実験の関係図をまとめると下記のようになります。

テーマと実験の関係図

また、一連の流れをMobius Navigatorのループに当てはめると下記のようになります。

Mobius Navigatorに沿ってやること

このようにNotionを利用することで、Mobius Outcome Deliveryのフローをできるだけ簡単に、かつテンプレートに沿っていくことで実現できるような仕組みを作成しました。

最終的に作成したものはコネヒトカンバンと命名し、PdMを中心に展開をしていきました。

コネヒトカンバン爆誕

補足: 実験ドキュメントについて

ここで、先程説明をスキップした実験ドキュメントの詳細について改めて紹介します。

上記で説明した「テーマ」に紐づく形で、「実験ドキュメント」が作成されます。

前述した通り、この実験ドキュメントは1つのテーマに対して複数紐づくものとなっています。また、実験同士の繋がり(前後関係)も表現することができます。

実験ドキュメントのテンプレートは、以前のブログでも紹介した「A/Bテスト標準化テンプレート」を土台として、少しブラッシュアップして作成しました。

tech.connehito.com

テンプレートに入れ込んだ最終的な項目は以下のようなものです。

  • 実験の背景
  • 実験の概要
  • モニタリング指標
  • 実験後のアクションプラン
  • 実験結果

以降ではブラッシュアップしたポイントを中心に紹介します。

ステータス管理を容易に

冒頭で述べた通り、課題感の1つに「なんとなく進みが遅いと感じるが、どこがボトルネックになっているのか特定がしづらいのではないか」というものがありました。

そこで

  • 各実験は今どのステータスなのか
  • ステータスが暫く変わっていないのであれば、何が原因で変わっていないのか

などの現状を知り、そこでボトルネックを共有して解決を図れるような仕組みにできるよう、ステータス管理を簡単に行えるようにしました。

Notionで以下のようなテンプレートを用意しておき、「開発開始」や「検証開始」などのボタンを押すだけで、ステータスが変更されるようにしました。(ボタンのロジックなどは後述)

ステータス変更を簡単にするためのボタン

テンプレートの末尾には、実験終了したタイミングでステータス更新 & 結果記入欄が表示されるボタンも追加しています。

実験が終了した際のボタン

実験のサマリを把握しやすく

実験ドキュメントは現在の状態を把握できるだけでなく「過去に何がうまくいって、何がうまくいかなかったのかを振り返ることができる」ドキュメントとしても効果を発揮します。

過去の実験を一覧で見たときに「どの実験がどんな目的で行われて、結果はどうだったのか」がパッと分かるとハッピーですよね。

そこで、実験のサマリをNotionのページプロパティに持たせることで、一覧で見たときに逐一ドキュメントの中身を開かずとも大まかな内容を知ることができるようにしました。

実験サマリプロパティのテンプレート

一覧で見るとこんな感じです(マスク部分が多くて分かりづらいかもしれませんが雰囲気だけでも感じていただければと)

実験一覧

カンバンを作成する上で工夫した点

以上が大まかなカンバンの仕組みと詳細になります。

今回このコネヒトカンバンを作成するにあたって、実際に使ってもらうようにする工夫をいくつか行ったのでご紹介します。

利用者はできるだけ流れに沿うだけで利用できるようにする

今回カンバンを作成するにあたって、とにかく流れに沿えば自動的にメビウスループに乗っているような設計を心がけました。

その際に役に立ったのがNotionのボタン機能です。

www.notion.so

この機能を使うことで、ボタンをクリックした時にプロパティの操作やページ作成などを自動で行ってくれます。

例えば「次のテーマを作成する」ボタンはクリックすると下記のような動作を自動でおこなってくれます。

操作するページのステータスを 完了 にする→繋がりを紐づけてページを作成する→新規ページを開く

ボタンを使ったプロパティの変更設定

このように利用者はボタンを押すだけで自然とループに乗っている状態を目指すことで利用側のハードルをできるだけ下げるようにしました。

目的や思想、使い方のドキュメントを用意する

今回カンバンを作るにあたって、目的や思想の設計を入念に行いました。

実際にこのカンバンを作った人はいいのですが、利用する人たちはやりたいことなどを理解しないと「これをやる目的ってなんだろう…」といった状態になってしまいます。

なので、このカンバンの目的やどういった思想のもとで作成しているのかを書いたドキュメントを用意しておきました。

カンバンの目的を書いたドキュメントの一部

ただ、用意しているだけでちゃんと読んでもらえるとは限りません。そこは読んでもらう工夫だったり、仕組み化を今後も考える必要があると思っています。

実際に運用してみてどうだったか

PdMを中心に実際に利用してもらい、数ヶ月が経ちました。実際に使ってみた感想をアンケートで取ってみたので一部ご紹介します。

全チームの状況が一箇所で見れるのが最高

ステータスが俯瞰でみれるのがけっこう好き

特に繋がりの部分はポジティブな意見が多かったです

前の繋がりがあるから文脈思い出しやすい(あーこのゴールに向かう施策ね〜的な)

前後の繋がりが圧倒的にわかりやすくなった!

みんな書いてるけど、つながりがみえるようになったのはとても良い!

嬉しい声もありつつ、下記のような課題感もあらためて発見できました。

説明されると理解できるが、自分だけだと構造や使い方を理解するのにハードルがあった

実験というワードが強く、1回きりの施策の時(実験じゃない場合)に書いていいのかちょい悩むことがある

前後のつながりが見えるようになったのはとても良いが、まだ運用して時間が経っていないので本当に効果的かは長い目で見たい

ある程度想定はしていたり、対策をしたつもりでしたが、やはりこの辺は難しいですね。

浸透に関しては辛抱強く、でも楽しみながらみんなで続けていって、より良いものになるようにしていきたいと思ってます!

今後の展望

このカンバンを導入して、約2ヶ月ほどが経過しました。 色々書きましたが、まだ道半ばであり実験的な取り組みです。

改めて自分達がやりたかったこと、達成したかったことができてるかと言われると、できつつあるけど、まだまだこれから、と言う状態です。なので、今後もブラッシュアップしていきたいと思っています。

例えば、実験で得た知見をPdMやチーム間で共有できるような仕組みを用意したり、もっと過去の繋がりを遡って追加したり…などなど。

やりたいことがたくさんありすぎ状態ですが、同時にワクワクもしているのでこの取り組みを今後も続けていって、Mobius Outcome Deliveryの知見と実践を積んでいきたいと思います。