プロダクト開発を前に進めるためにMobius Outcome Deliveryの思想を導入した道のり
みなさんこんにちは！コネヒト採用担当の芦刈です！
突然ですが、日頃プロダクトを開発していく中で「開発したことが点になっていて、未来に繋がっていないのではないか？」と感じることはないでしょうか？
コネヒトでもそのような課題を感じていたのですが、エンジニアの田中と野澤がMobius Outcome Deliveryを取り入れて、繋がりをもったプロダクト開発を目指し、日々奮闘しております。
今回はその道のりをインタビューしました！
2人の経歴を紹介
大学院でプログラミングに出会い、新卒でIT人材企業にエンジニアとして入社。
主に社内向けの営業支援ツールの開発を行う。
その後、2021年にコネヒトへ入社。ママリアプリのバックエンド開発をメインに行う。
1年後にはグループリーダーとして開発に加え、
PdMと協業し、よりよいプロダクト開発ができるように日々探求中。
大学で情報科学を学んだのち、新卒でSIerに就職。
製造業向けのERPパッケージの開発・導入に5年ほど従事。
その後趣味で勉強し始めた機械学習の面白さにハマり、
1人目のMLエンジニアとして2019年にコネヒトへ入社。
レコメンドや検索、MLOpsなど、機械学習やデータを軸としたプロダクト導入に携わる。
「この実験は何のためにやっているのか？」「実験したことが次に繋がっているのか？」と日々疑問に思っていた
ー プロダクト開発でコネヒトが課題に感じていたことを教えてください。
野澤：2022年、コネヒトでは社内のABテスト標準化を行うために「実験ドキュメント」というテンプレートを導入しました。（実験ドキュメントの詳細は後述）
これを1年ほど運用してみて、実験のプロセスや結果は見える化できたものの、その実験の反省点などを次の実験に活かせているのか？過去の実験で得た知見を未来に繋ぐことができているのか？という課題感を感じていました。
僕は機械学習周りの開発を行うことが多いのですが、一般的に、機械学習は不確実性が高く、且つコストもかかります。
過去の実験で得た学びを活かしつつ、そもそも機械学習を使う必要があるのかなども含めて、施策の見直しやモデルの改善などをしていく必要があると思っている中で、過去の実験で得た知見を未来に繋ぎ、PDCAを回していくことの重要性は強く感じていました。
田中：僕はコネヒトのメインプロダクトであるママリのバックエンド開発を日々しているのですが、エンジニアがただプロダクトを開発するだけではなく、「何をつくるのか？」「どうやってユーザーに届けるか？」そこからエンジニアが入り知見を持ち寄ることで、よりプロダクト開発を前に進めることができると思っています。
僕も野澤さんと同じく、仮説→実験→検証→学びの開発プロセスで、この実験は「次に繋がっているのか」「本当に自分達は前に進めているのか」と疑問を感じることがありました。
「過去のこの実験は何のためにやったのか？」が見えるようになると、例え実験がうまくいかなかった時も、「次はどうするか」「何をすればいいか」という会話を行うことで、学びを活かした開発を行えるのではないかと思っていました。
また僕と野澤さんはPdMメンバーと一緒に、プロダクトマネジメントのスキルアップを目的とした会を定期的に行っているのですが、そこでも「今のプロダクト開発を線でみれるものがあるのか？」「学びを活かした開発ができているのか？」という議題が上がり、同じ課題感を感じている僕たちでオーナーシップを持って改善していこうという話になりました。
実験の繋がりが見える＋誰でも使える仕組みづくりがプロダクト開発を前進させるために必要だった
ー 具体的にどうやって改善したのでしょうか？
田中：結論からいうと、プロダクト開発で使用していた実験ドキュメントの記載内容の見直しと、実験の繋がりを見える化する仕組みづくりを行いました。
野澤：実験ドキュメントとは、新しい機能のABテストを行う際に記載するドキュメントで、「なぜ実験をするのか」「どんな指標をモニタリングするのか」「実験結果はどうだったか」「どんな学びを得られたか」等をまとめておくものです。
実験用の標準テンプレートが用意されており、ある程度誰でも同じ品質のドキュメントが作れるように工夫しています。
（参考：https://tech.connehito.com/entry/2022/07/29/170913）
冒頭でも話しましたが、このドキュメントのおかげで「全社で今どのような実験が行われているのか」や「過去どんな実験が行われたのか」などが把握できるようになりました。
しかし、記録としては残るものの、過去の実験を未来の資産として活かせていないのではないか、という課題感も生まれてきました。
そこで、この実験ドキュメントを含めた開発フロー全体を改善することで、より良いプロダクト開発の形が見えてくるのではないかと思っていました。
田中：どうすれば過去の学びを活かして次に繋げることができるのか？と考え始めた時に、Mobius Outcome Deliveryの研修（https://www.attractor.co.jp/info/outcome-delivery-20230710/ ）を受けました。
Mobius Outcome Deliveryは探索フェーズからデリバリーフェーズまで、プロダクト開発全体を見える化できるフレームワークであり、繋がりを持ちながら開発プロセスのサイクルを回したいというコネヒトの課題を解決するためのヒントになる思想だと感じました。
（2024年1月にRSGT2024でMobius Outcome Deliveryを活かした開発プロセスについて登壇したので、詳しい内容についてはこちらの登壇資料とブログを見てもらえたらと思います。）
コネヒトの実験ドキュメントでいうと、Mobius Outcome DeliveryにおけるDeliverの部分が中心なので、Discoverの部分も見える化することで、「なんで実験をしたいのか？」という背景もセットに残せるので良さそうだよねと野澤さんと話し、記載内容をアップデートしました。
野澤：田中さんがMobius Outcome Deliveryの研修を受けて得た学びをシェアしてくれたおかげで、僕自身もその思想を知ることができましたし、
コネヒトのプロダクト開発を、より良いプロセスにアップデートできるのではないか？！とワクワクした気持ちになったのを今でも覚えています。
次に開発フロー全体で繋がりを持たせるために、どのようにしてMobius Outcome Deliveryの思想を運用に落とし込むのがベストなのか？を2人で考えていきました。
コネヒトではNotionを導入しているので、Notionのプロジェクト管理機能を使うことでMobius Outcome Deliveryのループを回せるのではないかという話になり、その会話の流れで簡易的なテンプレートを作り、具体的なイメージをしていきました。
この時は1時間くらいで動くものが作れてテンションがあがりました（笑）
田中：テンション上がりましたし、「これいけるかも！」と思いましたよね（笑）
そこから更に誰でも簡単に使えることを意識してテンプレートをアップデートしていきました。大体の型を作成した後、実際に僕たち以外の社内メンバーにも触れてもらい、運用する上でのフィードバックをもらいました。
そのフィードバックを参考にしながら、3週間ほどでNotion上に開発フロー全体が見える仕組みを導入しました。実験ドキュメントの改善ができたのでよかったです。
野澤：田中さんがリーダーシップを発揮し推進してくれたおかげて、短いスパンで運用に載せることができたのはめちゃくちゃ良かったなと感じています。
今回Mobius Outcome Deliveryの思想をプロダクト開発に導入したことで、当初課題に感じていた繋がりを意識した開発ができる体制を目指していけるようになったと思います。ループを回せるようになってきたので、過去の実験を参考にした開発はこれからのフェーズなので、引き続きやっていきたいと思います！
田中：野澤さんと同じく、繋がりを意識したプロダクト開発をする土台はできつつあるんじゃないかなと思っています。
ただ、まだまだ運用面であったり、組織に浸透させるための課題は多いし、最終的にやりたいことは価値あるプロダクトを届けること、アウトカムを出すことなので、引き続き僕自身も学びながら、Mobius Outcome Deliveryの実践をしていきたいと思っています！
