※ こちらはミツモアAdvent Calendar 2021の10日目の記事です。
こんにちは！ミツモアの佐藤（@koki621）です。
ミツモアは「確定申告めんどくさい…」「リモートワークが増えてエアコンを綺麗にしたい」「子供の卒業式の記念に写真を撮りたいな」といった生活のあらゆるシーンであなたにぴったりの専門家を無料で探せるサービスですので、ぜひ気軽に使ってみてください！
「アドベントカレンダーにBizサイドの視点でも何か書いてくれないかな？」
とCTOの柄澤さん（@fmy）から言われたので、初めてのtech blogにチャレンジします。
私自身、開発経験は全くないのですが、開発・デザイナーのメンバーと一緒にプロダクトのリリース・改善をする業務を行うことが多いです。 その中で、弊社のプロダクト開発のフローが近頃確実に良くなってきていると強く感じているため、今回はこの点をテーマに書いていきます。
これまでの問題点
弊社が提供するサービス「ミツモア」は、クリーニングやリフォーム、税理士などの士業まで、ありとあらゆるお仕事を依頼できるプラットフォームです。 サービスはこれからどんどん増えていく予定ではあるものの、現在展開しているサービスをさらに磨き込み、よりよい体験をユーザーに届けることを重要視しなければならないフェーズであると感じています。 確実に世の中にとって有意義なサービスになっているという自信がある一方、まだまだ課題が山積みです。 ユーザー体験向上のために日々頭をフル回転させているので、その数多くのプロジェクトが立ち上がっています。
そこで問題となっていたのは以下のような点です。
- 特定のサービスにしか適用できない部分最適な改善となってしまっていた
- 施策の決定～開発スタートまでの仕様検討の詰めが甘く、開発がスタートしてからの考慮漏れの発覚や手戻りが頻発していた
- 「なぜやるのか（why）」を突き詰めずに「how思考」でプロジェクトを進めてしまい、解決したい課題やKPIの認識のずれがチーム内で生じていた
特に問題と感じていたのは3つ目の「how思考」に陥っていたという点。
「こんな問題がある」⇒「こんな施策を打とう！」⇒「翌日にプロジェクト kick offします！」 というような感じで、検討フェーズをさらっと流してしまっていました。 「なぜやるのか・なにを良くしたいのか・プロダクト全体への影響はどれくらいなのか」等の掘り下げが甘く、実装された後にバグが大量に見つかったり、最悪のケースでは、実装が完了した後にリリースできない重大な仕様の漏れが見つかったり…
結果的に貴重な開発リソースを無駄遣いしてしまっていました。
どう変えたのか
組織が急拡大する中でこの方法のままではまずいということで、プロジェクトのフローを抜本的に見直しました。 具体的には、以下のようなPhaseに区切ってプロジェクトを進行させることにしました。
Issue Phase
- 誰の・どんな課題を解決したいのかを明確にする
- データやユーザーインタビューを通じて、イシューの解像度を上げる
- イシューが解決された場合、どれくらいのインパクトが出るのかを試算する
Planning Phase
- 開発・CX・デザイナー・Bizdevが一緒に施策の幅出しをする
- 最も良い施策を決定し、工数を確認する
- スコープや成功基準を決める
開発 Phase
- PRD（Product Requirements Document）・ユーザーストーリーを作成する
- 開発の詳細設計を行う
- デザインを具体化する
- テストケースを作成し、QAを行う
どう良くなったのか
結論、このように細かくphaseを区切ったことでプロジェクトのヒット率が大きく向上し、さらにはリリースのスピードも早くなりました。
その理由としては以下3つが挙げられます。
1つ目は、チーム横断で施策の幅出しをすることで、工数が少ないかつインパクトが出る施策を打てるようになったことです。
これまでは、施策を考えるのはBizサイドの役割で、Bizで決定したものを開発チームに伝えて実装してもらうという流れでした。 しかし、Bizで考えた変更がプロダクト的には難しかったり、CXチームがユーザーの声を日々聞くことで認識している根本的な課題感を共有できていなかったり、デザイン的に違和感のあるUIになっていたり… 1つの視点だけで施策を決定すると、結局後から振り出しに戻るということがしばしばありました。
幅出しの段階から様々な部署の視点を入れることで、実装コストが少なく、よりイシューにダイレクトに効いてくる施策を次々と打てるようになりました。
2つ目は、何をやるかだけでなく「何をやらないか」が明確になったことです。
プロジェクトが始まると、「あれも解決したい」「あわよくばあの数値も改善しないかな…」と欲が出がちです。弊社もそうで、開発がスタートしてから変更の提案が上がっていることがしばしばあったのですが、そのようなコミュニケーションがそもそもPlanning Phaseで行われるようになり、さらには「その施策はこのプロジェクトのスコープとは大きく外れるから、プロジェクトを別で立ち上げよう」という判断をスムーズに行えるようになりました。
3つ目は、結果の振り返りを確実に行えるようになったことです。
具体的な例で言うと、チャットの返信率を上げるためにスタートしたプロジェクトであったのにも関わらず、いつの間にか返信後の成約率を上げようと奮闘し、なかなか上がらずに意気消沈したことがありました。 現在は、あらかじめどの数値がどれくらい上がるのかを深く検討しているので、このような事態は起こらなくなっています。
まとめ
以上、ミツモアがプロジェクトのフローをどう変更し、どう良くなったのかについて書きました。 ヒットする施策をたくさん打てて売上を伸びたという点はもちろん嬉しいのですが、「何のために我々はこのプロジェクトをするのか」「誰にどれくらいの価値を提供できるのか」 について、プロジェクトの一番最初の段階で全員が共通認識をもつことで、よりワクワクしながらプロジェクトを進めることができるようになったという実感があります。
まだまだたくさんやりたいこと・やるべきことがあるので、世の中が良くなるプロダクトを本気で作りたいという思いを持った方が仲間に加わってくれると嬉しいです。
エンジニア・デザイナー・PdMを積極採用中ですので、ぜひWantedlyのリンクからカジュアル面談をしましょう。
