Mobius Outcome Deliveryの導入と実践 - アウトカムの定義と計測をいかにして実現するか

Agile Journeyをご覧のみなさん、こんにちは。コネヒト株式会社でプロダクトマネージャーをしている田中俊也です。

コネヒト株式会社は、「あなたの家族像が実現できる社会をつくる」というビジョンの実現に向けて、家族のライフイベントにおける意思決定をITの力でサポートしています。子育て支援アプリ・情報サイト「ママリ」の開発・運営を中心に、子育て包括支援や自治体および企業向けの産休・育休の取得支援を行っています。

私は元々エンジニアとしてアプリ「ママリ」の開発に携わっており、プロダクトマネージャーと共に、日々プロダクト開発やその改善について議論や勉強を行っていました。 そのような中、去年の7月に開催されたMobius Outcome Delivery研修のことを知ったのです。Mobius Outcome Deliveryの名は以前から知っていましたが、その詳細やプロダクト開発への具体的な活用方法は理解していませんでした。

いざ研修に参加し学んでいくと、Mobius Outcome Deliveryには私がプロダクト開発において感じていた課題を解決するヒントがたくさんあり、研修後Mobius Outcome Deliveryの思想をプロダクト開発に活かす取り組みを実践するようになったのです。この記事では、Mobius Outcome Deliveryの概要とそのプロダクト開発への取り入れ方について、私のチームの取り組みを中心に紹介します。

Mobius Outcome Deliveryとはなにか？

Mobius Outcome Deliveryとは価値を生み出すためのフレームワークで、「組織がアウトカムに焦点を当てる」ことを支援します。「最小限のアウトプットで最大限のアウトカムを達成する」ことを目的としており、メビウスの輪の形状をしたMobius Navigatorという図版を用いて、ディスカバリーからデリバリーまでを繋ぎ、プロセスを可視化します。 Mobius Navigatorは次の 3 つのセクションで構成されています。

1. Discover - 問題を設定、発見する Discoverセクションは問題を設定し、発見するフェーズです。ここではまず「なぜやるのか、誰に向けてやるのか（図中、Why & Who）」を定義します。 次はアウトカム（図中、Outcome）の定義です。ここでいうアウトカムは、「自分たちがうまくいっているのか」「設定した問題の解決に近づいているのか」を表すものになります。そして自分たちがうまくいっているのか、を把握するために、アウトカムは計測可能であることが非常に重要になります。研修の中でも「計測可能なアウトカムは何か？」という問いがポイントである、ということを学びました。このアウトカムが自分たちの目指すべきものになっていきます。

2. Decide - やり方を決める アウトカムを達成するためには様々な方法が考えられます。このアウトカムを達成するための手段を「オプション（図中、Option）」と呼び、このオプションから適切な方法を選択するのがDecideセクションです。 オプションを選択するための方法として、インパクトと作業量をマッピングしたものなどが例として挙げられます。 次はこのセクションで決めたオプションを実際に届けるフェーズに入ります。

3. Deliver - 適切に作る 実際にアウトカムを達成するためのオプションを決めたら、実際に届けるフェーズに入っていきます。このフェーズをDeliverセクションといいます。実際に作って届けたら、それで終わりではなく、計測し学習すること（図中、Measure & Learn）も、このセクションに含まれます。自分たちが目指すアウトカムに対してどのくらい進捗したのか、実際にユーザーに価値を届けてわかったことは何か、といったことをを考え、学びを得て次のセクションへと進みます。

この3つのセクションを1回巡って終わり、ではありません。Deliverセクションで学びを得たら、再度Decideのセクションに入ります。学びを得て、次に何をするのか。別の問題を探すのか、もっと実験をするのか、チームの次の行動を決め（Decide）、再度、DiscoverやDeliverのセクションに入っていきます。 このように作って終わりではなく、まるでメビウスの輪のようにプロダクト開発がつながり続けていくことになります。

Mobius Navigatorは普段行っているプロダクト開発の流れを非常に簡潔に表し、可視化したフレームワークといえるでしょう。

Mobius Navigatorを見える化し、チームの取り組みを支援するプラクティス

さて、Mobius Navigatorは図版として簡潔に表されていますが、実際には各セクションで多くの活動が行われます。Discover、Decide、Deliverの各セクションで活用できるプラクティスは世にさまざまありますが、Mobius Outcome Deliveryにおいては特定のプラクティスを行うように定義づけされていません。絶対的な正解などないので、自分たちのお気に入りのプラクティスを選んでいくことが推奨されています。 しかし、「さあ、やって！」と言われても、どのように進めればいいか、きっと戸惑うことがあるはずです。ですから、Mobius Outcome Deliveryの中では活動を見える化したり、活動のきっかけを与えてくれるツールも提供してくれています。

たとえば上記のマップです。このマップはMobius Navigatorの各セクションでの活動の見える化をサポートします。誰に向けてやるのか、ニーズや課題、アウトカムは何か、といったことを記載し、マッピングできるようになっています。 研修でもこのマップを使用してチームで議論し、各項目を埋めながらサービス開発をするワークに取り組みました。

もうひとつが、こちらのMobius Trigger Cardsです。このカードは、各セクションでどんなプラクティスがあるが記載されていて、「自分たちはこのセクションでどういったことができるのか」というきっかけを与えてくれます。Mobius Outcome Deliveryに取り組む人にパターンを与えてくれるのです。「次に何をしようか」と考えたとき、カードをめくっていくことで「このプラクティスを使えそうだ」といった気づきを与えてくれるので、パラパラとカードをめくりながら自分たちがどのように活動をするのか思考したりするのにも有効です。絵柄もかわいく、楽しい気持ちでカードをめくれるので、個人的にはとくにお気に入りのツールです。

これらのツールの一部はMobius Outcome Delivery のホームページからダウンロード可能ですので、興味のある方はぜひご覧ください。（ただし、カードは現在売り切れており、すぐには入手できないかもしれません。）

なぜ、Mobius Outcome Deliveryを取り入れたのか

私たちがMobius Outcome Deliveryを取り入れたのには、ある課題を感じていたからです。研修を受ける前、私が当時所属していたチームでこんな会話がありました。

• 「なぜ自分たちはこれをやっているのか」
• 「今期行うことは前期の学びを活かせているのか」

これらの会話は、普段行っている開発が繋がっていない、線ではなく点になっているのではないか、といった課題感からくるものだと思います。実際には、私たちの開発は完全な点ではなく、過去の学びを活かせていることもあるはずですが、それが見えない、追えていなかったことは確かでしょう。それゆえに、ふと「あれ、なんでこれやってるんだっけ」という気持ちになってしまったのかもしれません。

• 「なんとなく進みが遅いと感じる」

この会話もチームのレトロスペクティブで行われていました。しかし、「どこが遅いのか」や「ボトルネックがどこにあるのか」について十分に把握できていなかったのです。スプリントに焦点を当てると、つい「作る過程」に目が行きがちです。しかし実際には、「何を作るか」や「何をするか」を決定する段階にボトルネックがあるかもしれません。これらなんとなく感じている課題を見える化したい、見えるようにしてチームみんなで議論をし、改善したい、助け合いたい、という思いから、私はMobius Outcome Deliveryの研修に参加したのです。

Mobius Outcome Deliveryは、その存在自体は知っていたものの、どのようにプロダクト開発に取り入れることができるのか、今ひとつ想像ができない状態でした。しかし、研修の最初期に「Mobius Outcome Deliveryは、価値を生み出す旅程を見えるようにするため、3 つのパーツからなる統合された構造を持っています」と学び、これが私が抱えている課題を解決する手がかりになるかもしれないと感じたのです。

また、研修で学んだ、「Mobius Navigatorはチームの羅針盤となる」 という言葉は私を強く刺激しました。Mobius Navigatorをチームの羅針盤として利用することで、自身が課題に感じていることにアプローチできるのではないか、と感じ、どうすればこの思想を取り入れることができるか、を考えるようになったのです。

Mobius Outcome Deliveryを導入する

研修を終えた私は、早速、Mobius Outcome Deliveryを実践するべく取り組みはじめます。こうした新しいアプローチを組織に導入するのは容易ではありませんが、私が恵まれていたのは、当時同じ課題感を共有するメンバーがいたことです。 そのメンバーに研修で得た知識を共有すると、この取り組みに興味を持ってくれ、2人でNotionを使いプロダクト開発運用（後述）を作成し、導入を進めていくことになりました。この際、意識したのは「小さく、少しずつ広げていくこと」「こまめに振り返って改善すること」です。

主に自チームのメンバーに使用してもらい、フィードバックをもらっていきます。不完全な状態であっても、実際に使用しながら得たフィードバックをもとに少しずつ改善を重ねることで、スピード感を持って導入の一歩目が踏み出せたと思います。

では、実際にどういった手段を用いて導入したのかを次に紹介いたします。

Mobius Outcome Deliveryを駆動させるNotionを用いたプロダクトマネジメント

弊社では現在、Mobius Outcome Deliveryの活用方法としてNotionを用いたプロダクトマネジメントを行っています。この方法は研修中に推奨されたものではなく、自分たちで考案したものですが、一つのHowとして参照してもらえれば幸いです。

私たちはMobius Navigatorの見える化をする方法としてNotionを活用しています。Notionにはさまざまなテンプレートが用意されており、特に「Project Management」のテンプレートを活用して、Mobius Navigatorを実現できると考えました。

具体的な方法については、Regional Scrum Gathering Tokyo 2024（登壇動画、発表スライド）や弊社テックブログに詳細が記載されていますので、ぜひご覧ください。

Notionではボタン機能を使うことでボタンを押したら自動的にテンプレートを展開するといった機能が豊富に揃っています。これら機能を活用し、できるだけ簡単に利用できるように設計をしましたが、運用を手軽にすることもMobius Navigator導入を進める上で意識した点の一つです。

アウトカムをどのように定義し、測定するか？

Mobius Outcome Deliveryでは「アウトプットよりもアウトカム」という言葉があるように、最小限のアウトプットで最大限のアウトカムを実現することをゴールと位置付けています。これを達成するためには、複数の選択肢の中から実験を行い、得られた学びをもとにベストな選択肢を実装しアウトカムを実現することが求められています。

また、最近ではさまざまなカンファレンスなどで「アウトカム」という言葉は耳にしたりする機会が増えてきたように思います。 弊社の中でも「アウトカムってなんだろう」という会話がされることがあります。

Josh Seidenの著書「Outcomes Over Output」によると、アウトカムは「an outcome is a change in human behavior that drives business results.（「アウトカムはビジネス的な成果をもたらす人間の行動変化である」）」と書かれています。

さらに、アウトプット、アウトカム、そしてインパクトの関係については、以下の記事で詳しく解説されています。

アウトプットは「作り出された機能」、アウトカムは「その機能によってもたらされる行動の変化」、インパクトは「その行動が生み出す結果（例：売り上げの増加）」という関係性です。

弊社の場合、アウトカムを定める上でのキーワードは「主語は顧客（ユーザー）」です。つまり、「主語は顧客（ユーザー）にどういう変化が起こせると良いのか？」を意識してアウトカムを考えるようにしています。

具体的な施策フロー

弊社で行なっている具体的な施策実施のフローについて、アウトカムに関する箇所を中心に紹介します。

1. アウトカムを定義する

Notionにアウトカムを記載する箇所があります。ここで顧客を主語として、どういう行動の変化が起こせるといいか、を意識して記載するようにしています。

例えば、弊社Q＆Aコミュニティアプリ「ママリ」の場合、回答数が増えることはコミュニティが盛り上がる一つの要因であり、アプリにとって重要な要素と考えています。 この回答を増やす行動につながる取り組みとして、回答をしてくれたユーザーにお礼のポップアップを出す施策を実施しました。この時のアウトカム定義としては下記のように記載しています。

アウトプット：
・回答を特定の件数を行ったユーザーに対して、回答件数とママリからのお礼をポップアップで表示する

アウトカム：
・ユーザーが、喜びや貢献実感を感じることができ、今後さらに回答をしようと思えている
↓
その結果、一人当たりの回答数が上がる

繰り返しになりますが、Mobius Outcome Deliveryにおいて重要なのは「最小限のアウトプットで最大限のアウトカムを達成する」であり、「アウトカムは計測可能であること」です。上記の例示でもアウトカムは「一人当たりの回答数が上がる」と、定量的で、かつ計測可能な指標になっていますが、これこそ私たちがアウトカムを設定する上で大事にしていることです。

1. アウトカムを測定する

アウトカムが計測可能ならば、当然、計測する手段が必要です。分析・測定ツールは企業によってそれぞれだと思いますが、弊社ではRedashやMixpanelといったツールを利用して、アウトカムを観測することが多いです。

※画像は開発環境の数値であり、実際の数値ではありません

上記のように1ユーザーあたりの回答数が上がっているかどうかをMixpanelで測定し、実際にアウトカムが達成できたかどうかを確認していきます。なお、弊社でのMixpanelの活用パターンはこちらの記事にも記述がありますので参照してみてください。

アウトカムを実現するために行っている取り組み

アウトカムを定めたとしても、それを実現することはやはり簡単ではありません。仮説を立てても実際に使ってもらうまで、結果はどうなるかわからない、いわゆる不確実性が高いと言われるソフトウェア開発をしている中で、私はRegional Scrum Gathering Tokyo 2024での発表において「自信を持ってリリースしたい」と発言しました。 これまでやったことない、また、不確実性が高いことに盤石の自信を持つのは困難ですが、私たちはアウトカムを実現する自信を少しでも高めるためにいくつかの取り組みを実施しています。

1. ユーザーインタビューの実施
現在、弊社では週に1回のペースでユーザーインタビューを実施しています。もともとは2〜3ヶ月に1回ほどのペースで、かつ一部のスタッフのみが行う属人的な運用になっていました。そこを週に1回コンスタントに行いつつ、インタビュアーを属人化させないようにローテーションさせていく取り組みを行なっています。また、プロダクトマネージャーやデザイナーだけでなく、エンジニアやその他の職種の人も参加できるようにしています。

このユーザーインタビューの中で、新規機能を利用したことがある人を対象にインタビューを行い、機能に対してのフィードバックを得て、次の実験に対するヒントを得るようにしています。ユーザーインタビューに関する取り組みは、以下の資料にもまとまっています。

2. 見てもらう、だけじゃなく実際に触ってもらう
スプリントレビューではデモを見せるだけではなく、実際に触ってもらってフィードバックをもらうことを重視しています。スプリントレビューで動くものを見せることの大切さはもちろんですが、よりリアルなフィードバックを得るために「実際に触ってもらう」ことでユーザーの立場に立った、本気のフィードバックをもらいにいきます。 スマホアプリの場合だと、実際に端末を触って初めて気づくこともあります。例えば「タップやスクロールをした際、想定した挙動にならなかった（しづらかった）。これって触ってみないと気づかない」といった会話もスプリントレビュー中にみられます。 得られたフィードバックをもとに、本当に自分たちが達成したいことは実現できるのか、といった議論のきっかけとして機能しています。

3. 深いフィードバックと広いフィードバックをとりに行く
弊社はママさん向けのプロダクトを作っており、社内のママさんから得られる意見は実際のユーザーに近く、非常に貴重です。ですから、スプリントレビューにはステークホルダーだけでなく、社内のママさんに実際に使ってもらいフィードバックをもらう機会を作っています。 さらに、最近では全社員が集まる機会でもプロダクトを触ってもらい、フィードバックを得るようにしています。より幅広い視点からのフィードバックには、開発チームだけでは得られなかった気づきがあります。 以下は実際に動画に関する機能追加を行った時の全社員からのフィードバックの一例です。

上記のようにユーザーとの距離を近くすることやフィードバックを素早く得る機会を作ることで、「やってみなければわからない」不確実なことであっても、ある程度の自信を持ってリリースをできるようになります。 この取り組みもまだまだ実験の途中なので、継続して改善を重ねていきたいと思います。

Mobius Outcome Deliveryがもたらしたもの

Mobius Outcome Deliveryの思想を導入してから、約1年（執筆時）が経とうとしていますが、以下のような変化が見られてきています。

施策のつながりやチーム状況の見える化

Notionを用いた可視化により、各施策のつながりが見えるようになりました。これにより、「いま行っている施策はどういった経緯から実施しているのか」といったことが振り返りやすくなっています。

さらに、このつながりを半期ごとに棚卸しすることで、自分達が何をやったのか、なぜやったのか、どうやったのか、その結果といったことを観測しやすくなっています。

また、Notionは各チームの状況を可視化することにもつながります。あるチームが何を行っているのかが把握しやすくなり、また、多くの実験を行っている際に「実験が多すぎるのでは？」という会話ができ、マネジメントの観点でも効果が感じられるようになりました。実験が多い時は「なぜ進められていないのか？」という会話から障害やボトルネックの解消に向けて動くきっかけにもなっています。

アウトカムに関する関心の高まり

私自身を含め、組織内でアウトカムについて会話をする機会が増えたと実感しています。「アウトカムとはなにか？どう定義するか？」といった会話がプロダクトマネージャーを中心に広がりつつあり、ユーザーへの価値提供意識がこれまで以上に高まっています。 また、Notionテンプレートではアウトプット、アウトカムをセットで記載できるようにしてあり、作るものと作ったその先にユーザーがどうなって欲しいかを思考できるようになり、「なぜやるのか？」を考えやすくなった、というフィードバックも得られています。

アウトカムを中心に議論できる組織へ

関心は高まりつつありますが、組織としてアウトカムを中心に思考できているのかというと、まだ多くの課題があると感じています。

例えば弊社ではアプリをグロースさせるチーム以外にも新規事業を担当するチームなどが存在しております。既存のユーザー像コンテクストを踏襲できない新規事業ではアウトカムをイメージしにくかったり、まずアウトプットが求められることもあり、アウトカムに関する議論にたどり着くことが難しいという局面があります。

ただし、こうした局面でも、プロダクトマネージャーやチームで集まる機会にアウトカムに関する議論を重ねるなどして、少しずつアウトカムに対する関心を広げていくことを行なっていきたいと思っています。

私はこの4月からプロダクトマネージャー職になりました。今回紹介したNotionの取り組みは今までプロダクトマネージャーを中心に扱っていましたが、自分自身がその当事者となったことで、よりMobius Outcome Deliveryの取り組みに時間を掛けられるようになりました。

使ってもらうのではなく、自分自身がちゃんと使う、そしてその学びを組織に発信していくことを行なっていく予定です。

ただ今回紹介した方法は一つのHowでしかなく、あくまでやりたいことは、求めるアウトカムは達成できたのか、成果を出せたのか、です。 その求めるアウトカムに向き合うためにできることとして、Mobius Outcome Deliveryは一つのヒントになるかと思います。みなさんにとっても、本稿がアウトカムを追求するうえでのヒントになれば嬉しいです。

記事内で紹介した資料のいくつかはMobius Outcome Delivery研修の講師であるGabrielle Benefield（@gbenefield）からご提供いただきました。また、本稿へのコメントやアドバイスもいただきました。Gabrielleのご好意とサポートに深く感謝いたします。

合わせて読みたい関連記事

編集：はてな編集部

田中俊也（たなか・としや） @toc_toc05

エンジニアとして2021年、コネヒト株式会社に入社し、「ママリ」の開発などを担う。2024年4月よりプロダクトマネージャーに。同社へのMobius Outcome Delivery導入に取り組み、同フレームワークに関する社外へのアウトプット活動も盛ん。