複数プロダクトを横断して気づいた検証可能な開発の必要性

※この記事は、2025 Speee Advent Calendar10日目の記事です。昨日の記事はこちら

はじめに

不動産事業部でtoB向けプロダクト群「ツナガル」を開発している篠島（24新卒）です。ツナガルでは、査定書作成SaaSや架電代行BPOサービスなど、不動産会社の業務効率化を支える複数プロダクトを提供しています。これらのプロダクトを横断的に運用保守・改善しながら、新規プロダクトの立ち上げにも並行して取り組む。そんな複雑でおもしろい環境が、今の開発チームの特徴です。

新卒入社から1年9ヶ月。去年のAdvent Calendarでは「プロジェクトをメンバーとしてどう進めるか」というテーマで書きました。あれから1年、確かにプロジェクトのメンバーとして動くことはできるようになりました。でも同時に、ある違和感も感じるようになっていました。

「このままだと、無駄なものを早く作れるようになるだけじゃないか？」

今回はその違和感から学んだ、検証可能な開発の必要性について書きます。

「リリースしたら終わり」だった

振り返ると、「リリースすること」がゴールになっていました。

ツナガルのプロダクトをさらに活用していただくため、エンジニアも商談の録画を見たり、お問い合わせを分析したりしながら、不動産会社のオペレーションを理解する取り組みを行なっていました。ドメイン知識を獲得してから、システムやUI/UXを設計し、開発し、リリースする。ユーザーストーリーを明確にするために良い取り組みだったと思います。

でも、リリース後すぐに別プロダクトの開発テーマに切り替わってしまい、振り返りを全く行えていませんでした。その結果、このプロジェクトが実際にどんなインパクトを生んだのか、開発チームの誰も把握できていない状態でした。

別のケースでも、同じように検証ができていませんでした。「アジャイルだから早く価値提供する」という考えから、機能を細かく分割してリリースすることが多くありました。小さく刻めば早く価値が届くと考えたのです。

しかし現実は違いました。便利になるはずの機能が、かえって不動産会社の担当者や自社の営業メンバーを混乱させることになりました。「これはどう使うんですか？」「設定できないのですが」という問い合わせが増え、結局数ヶ月後に削除することになりました。削除後、お問い合わせは減り、指標にも変動なし。つまり、相関がないただわかりにくい機能だったのです。

複数プロダクトを横断しているからこそ気づけた

これらに加えて、3〜4ヶ月後、ほとんど同じ機能を別ページに実装するプロジェクトが立ち上がりました。「あれ、これ前にも作ったよね？」と気づいた時の虚しさは忘れられません。2回目のプロジェクトもプランナーと週次で話しながらUI/UXにもこだわったはずですが、最終的にはうやむやになってしまいました。

なぜこんなことが起きたのか。リリース後、週次で振り返っていくうちに、根本原因が見えてきました。それは「測定可能なKPI(評価指標)を設定していなかった」ことです。

KPIの何が問題だったのか。SMARTの法則に基づいて振り返ってみると、私たちの指標設定には穴だらけでした。

「SMARTの法則」とは、目標を達成するための5つの成功因子「Specific（具体性）」「Measurable（計量性）」「Assignable（割当設定）」「Realistic（現実的）」「Time-related（期限）」の頭文字を取ったフレームワークです。 https://www.mdsol.co.jp/column/column_122_1350.html

特に計量性(Measurable)の欠如です。たとえば、通話機能を提供していないのに「不動産会社の架電頻度を向上する」という目標を立てたことがありました。telリンクを貼れば測れるだろうと考えたのですが、そもそも不動産会社のオペレーションでtelリンクを踏むことはありませんでした。

他にも問題がありました。プロダクト全体の「解約率をn%下げる」のような営業施策の影響も受ける大きな指標から中間的な指標を立てなかったり、期限を設けずにぬるっと終わってしまったり。開発した機能が本当に効果があったのか、切り分けられない状態でした。

とりあえずできる範囲で測ろうとすると、やってみたら測定不可能だったり、解釈できない指標を設定してしまいがちです。そしてユーザーストーリーに基づいた施策だけど成果がわからない状態を放置すると、改善につながらず負債として残る。実際に体感して、検証可能であることの重要性を学びました。

特にSpeeeはAI活用を推進しており、プロダクトにもAIが組み込まれることがあります。適切な指標を設定できていないと、長期的にAIを改善できないどころか、品質悪化にも気づけないリスクがあります。プロダクトの未来を良くするためにも、指標は検証のためのものである必要がある。そう強く感じました。

検証を前提とした開発へ

これらの失敗を踏まえて、検証を前提とした開発に変えていこうとしています。

例えば、現在動いている新規プロダクトのMVP開発では、コア機能を評価できる定量的な指標を定義しています。週次で不動産会社にヒアリングする定性評価だけではなく、リリース後に機能の利用状況で継続的に品質を追えるよう設計しています。その指標が測定不能に陥らないよう、仮説が棄却された時に打ち手なしにならないよう、計画段階からプランナーと話しながら指標自体を改善し続けています。以前なら見切り発車していた場面で、本当に計測できるのか？計測不能にならないかという観点で一度立ち止まって検証設計を詰められるようになったのは、小さいけれど確かな変化だと感じています。

とはいえ、そもそも何をどの水準で検証するのか。私は複数のプロダクトを横断して開発しているため、それぞれのコンテキストが異なり、優先順位が不明確になることもありました。半年後・1年後にツナガルが目指す状態を基準に、直近で達成すべき目標を「開発成果定義」として整理し、いまはそれを開発計画や意思決定の軸として扱うようにしています。この軸から逆算して各プロジェクトの指標を設定し、計画を実行することで、優先順位の揺らぎを抑えるようにしています。例えば、架電代行プロダクトで「一見良さそうだが、あるべき状態が不明で評価が困難」な機能の開発を見送り、その時間を新規プロダクトの技術検証に充てるといった意思決定が行われるようになりました。

そして何より大切なのは、リリース後の振り返りです。リリースしたら終わりではなく、リリースしてから始まる。この意識を自分自身はもちろん、チーム全体で持ち続けることを目指しています。