〜1ヶ月以上の開発リソースを使って実装した新機能を、わずか半年でクローズ？！クラシルがPMを新設し、「リーンなプロダクト開発」をスタートした理由とは〜

プロダクト開発において、ユーザーが本当に求めている機能を「正しく作る」ことは、非常に難しい。

2018年12月に累計1,500万ダウンロードを突破した、レシピ動画サービス「kurashiru [クラシル]」を運営するdely株式会社。

同社でも、過去に「ユーザーの課題を受けて開発した新機能が、実はたった10人にしか使われていなかった」という失敗体験があったという。

そこで、従来の開発体制を見直し、2018年の7月頃より要件定義をアジャイル化する「リーンなプロダクト開発」へと移行。

具体的には、ユーザーの課題に対する「正しい解決策」の精度を上げるため、デザインのフェーズで「アイデア（解決策）→プロトタイプ→検証→ラーニング」のサイクルを回す開発手法を導入した。

その結果、機能をリリースする前に「ユーザーに価値のある機能かどうか」を検証し、正しいアイデアの確度を高められるようになったそうだ。

今回は、クラシルのプロダクトマネージャーを務める奥原 拓也さんに、過去の失敗からの学びと「リーンなプロダクト開発」の実態について、詳しくお伺いした。

「全員が意思決定者」の組織から、プロダクトマネージャー新設へ

僕は、2016年の9月にdelyに入社しました。当時、まだ大学院に通っていたのですが、自分で立ち上げたWebサービスがきっかけで、今の執行役員の柴田からメッセージをもらったんです。

そこで創業メンバーに会い、クラシルの立ち上げの話を聞きまして。「これは面白そうだな」と思い、次の週には研究室の教授に「辞めます」と伝えていましたね（笑）。

2人目のエンジニアとして入社した後、ずっとサーバーサイドの開発に携わっていました。そしてクラシルの成長に伴い、2017年の冬頃に、開発メンバーを一気に採用したんですね。

それまでは、iOS、Android、サーバーサイドといった各ポジション1名ずつの体制だったのですが、その人数を倍増し、さらに機械学習のエンジニアも加わったことで、組織の運営が難しくなってきてしまって…。

というのも、僕らはもともとボトムアップ型の組織だったんです。「こういう機能がいいんじゃないか」「じゃあこれをやろうか」といった感じで、当時は「全員が意思決定者」のような形でした。

ですが人数が増えてくると、たとえば「ボタンを追加する」といった小さな意思決定はできても、数ヶ月単位で開発リソースを取るような大きな意思決定や、ビジネス的インパクトの大きい施策が全然打てないと。

そうした課題から、プロダクトの意思決定者を明確にする必要があると感じ、プロダクトマネージャー（以下、PM）というポジションを新設することにしました。

外部からの採用が難しかったこともあり、開発部の中でもユーザーに近いCSの業務経験があり、施策の立案に強みを持っていた僕が、2018年の4月からPMを務めることになりました。

大きな開発リソースを使った新機能を、半年でクローズした理由

PMとして取り組んだ施策のひとつが、開発体制の変更です。というのも、以前はウォーターフォール型で要件定義をしていたのですが、実はいくつかの「失敗」も経験していて。

そのひとつが、1ヶ月以上の開発工数を割いたにも関わらず、リリース半年でクローズした「メニュー機能」でした。

▼当時の「メニュー機能」

これは、管理栄養士さん監修の献立や、調理の段取りを動画で見られる機能で、2017年の11月にリリースされました。その直後は、Twitter上のユーザーさんの反応もすごく良くって。

ですが、半年経った頃にデータ分析をしてみたところ、クラシルの莫大なDAUの内、実はたったの10人ほどしか、本質的にこのメニュー機能を使っていなかったんです。

この原因について考えた結果、「ユーザーの抱える課題に対して、その解決策がぴったり合っていなかったのではないか」という結論に行き着きました。

つまり、「日々の献立に悩んでいる」という課題設定そのものは正しかったと。一方で、ユーザーが本当に欲しかったものは、献立の「段取り」ではなく「彩り」なんだと気が付いたんです。

例えば、料理をする人がInstagramやGoogle画像などでレシピ検索をする時って、「今日のメインの副菜は何がいいだろう」みたいな感じで、食卓の彩りを探しているんですよね。

この失敗を振り返ると、問題は「解決策の立て方」にあったと思っていて。

なぜなら、当時はウォーターフォール型の要件定義だったので、リリース前に解決策の「確からしさ」を検証するアプローチが全くできていませんでした。

要件定義をアジャイル化！「リーンなプロダクト開発」とは

そうした中で、メルペイのPMの方が書かれた「リーンなプロダクト開発」に関する記事をちょうど拝見し、僕たちに足りていなかったのはコレだと気付かされたんです。

それを参考に、試行錯誤しながら組織の体制を整え、その開発手法を取り入れました。

この特徴は、デザインと呼ばれる要件定義のフェーズにおいて、「アイデア（解決策）→プロトタイプ→検証→ラーニング」のサイクルを回すというものです。

▼【左】以前の開発体制、【右】リーンなプロダクト開発

実際に手を動かすのは、プロダクトデザイナーとプロトタイプエンジニアのふたりですが、大元となる「解決すべき課題」の設定はPMの役割になります。

その課題としては、営業やCSからのフィードバック、開発のロードマップなどを踏まえて、ビジネスインパクトの観点から将来価値が高いと判断されるものを設定していますね。

そして、デザインフェーズに所属している開発メンバー全員で集まって、解決策のアイデア出しを行います。その中から筋の良さそうなアイデアをいくつかピックアップし、詳細を詰めていきます。

次に、選ばれたアイデアのプロトタイプを作り、その検証を行います。ひとつの課題に対して、1〜3個くらいの解決策を試すことが多いです。

こうして検証した結果を元に、学習サイクルを回し、より確度の高いプロダクト作りをしています。

定性データやNPSの指標をもとに、正しいアイデアを導き出す

例えば、「閲覧履歴の機能」をデザインした時は、「どこにボタンを置くか」「どのように履歴を残すか」を検証するプロトタイプを作り、一連のサイクルを回していきました。

最初のアイデアでは、閲覧履歴に遷移するボタンを、ファーストビュー画面の右上に設置していました。というのも、ユーザーから欲しいという声が多かったので、なるべく目立つ位置がいいだろうと考えていて。

ですが、社内メンバーに対してプロトタイプの検証を行った結果、実はそこまで重要でないことがわかったんです。

この検証の部分では、ユーザビリティテストの定性的な学びや「友人におすすめしますか」というNPSなどから判断しています。閲覧履歴の機能においては、どちらの指標も想定より低いものでした。

そして、再びアイデアの検証サイクルを回して、最終的にはメイン画面から階層をひとつ下げた「お気に入りタブ」の中に置くことにしました。

▼【左】検証前（メイン画面に設置）、【右】検証後（お気に入りタブの中）

以前の体制であれば、他の同種アプリを参考にして「重要な機能だからファーストビューに置こう」という意思決定をしていたと思うんですよね。

それを今回、機能としてリリースする前に「正しいアイデアかどうか」を検証し、階層を下げるという判断ができたことは、大きな成果だったと思います。

課題解決のできる開発組織で、成功確度の高いサービスを作りたい

一方で、デザインフェーズと実装フェーズに体制を二分したことで、後者のフェーズでは決められた仕様通りに実装するだけになってしまう、という課題も感じています。

つまり、ユーザーの課題解決を考える要件定義の部分に、実装フェーズのメンバーが関わりづらいんですね。

ですが、技術そのものがコモディティ化していくような時代において、エンジニアの市場価値をより高めるためには、課題解決のスキルが必要だと考えていて。

そのため、実装フェーズでも「解決すべき課題」を正しく設定することが大切だと思っています。

具体的には、良いアーキテクチャで良いコードを書いていかないと、開発スピードってどんどん落ちていってしまうんですね。

特に急速にグロースしていくプロダクトでは、こうした技術的な課題は後回しにされがちです。

しかし、要件定義をきちんとして確度の高い施策を打っていける体制になった今だからこそ、その課題に向き合える組織を作りたいと考えていて。

ただ、PMは「プロダクトの成功」に責任を負うという立場上、どうしてもグロースのための施策にフォーカスしてしまいがちで、「技術的な負債の解消」に重きを置きづらいという難しさがあります。

なので、そこはエンジニアリングマネージャーと役割分担をして、バランスを取りながら進めていますね。

今後は、クラシルが人々の「食」のインフラのようなサービスになる、という「大きな成功」を目指していきたいです。

そして、リーンなプロダクト開発によってアイデアの不確実性を減らすことで、成功確度の高い新規サービスをどんどん世に生み出していきたいですね。（了）