新米CPOが考えるプラットフォームにまつわるプロダクトの3つのフェーズとイシュー

こんにちは、Unitoで8月からCPO（Chief Product Officer）になりました新米の八尾です。
お笑いが好きです。（M-1が今年も始まりましたね）

新卒でクラウドワークスというマッチングプラットフォームの開発に携わり、また現在暮らすユーザーとホテルの部屋をマッチングさせるプラットフォーム「unito」を開発するなかでの考えを整理ながら、プロダクト開発に関わる方々とも意見交換ができればと思い、noteを書くことにしました。
まず始めに今回は、マッチングプラットフォーム開発の3つのフェーズを整理し、全貌を説明できればと思います。

軽く自己紹介

自己紹介をすると、前職がクラウドワークスという仕事のマッチングプラットフォームを運営している会社で、リリースして5年当たりのタイミングで新卒入社し、UXデザイナーとして約5年間サービスの成長を見てきました。（直接関わったのは1年だけですが）
また、2年目以降は新規事業のPdMとして3度の事業立ち上げを行い、中でもクラウドリンクスという副業マッチングサービスは現在も成長しています。

自分のキャリア全体では、
・一定の規模に達しているサービス
・0→１の立ち上げフェーズのサービス
・現在3年目に入ったunito
という、フェーズの全く違う3つのマッチングプラットフォームを経験することができています。

そんな自分が、マッチングプラットフォームにおけるプロダクトのフェーズをどのように捉え、何をプロダクトのイシューと捉えているかを書いてみたいと思います。
もちろん会社のリソースや強みなどによって変わってくるかと思いますが経験として感じている一つの勝ちパターンの仮説として読んでいただければと思います。

少しだけunitoのご紹介

unitoは利用した分の料金で暮らせる自分らしい暮らしのマッチングプラットフォームです。
利用しない日は専用アプリから申請をすることで月額料金を割引できる「リレント」機能が大きな特徴になっています。

マッチングするのは暮らしを求める方（以下、ゲスト）と、リピーターや中長期の利用者を集客したい宿泊施設や賃貸物件です（以下、施設）。

マッチングプラットフォームの主役は誰か？

unitoを含め、マッチングプラットフォームの主役はやはり「参加者」になるかと思います。

クラウドワークスのようなサービスだと、「発注者（仕事）」と「受注者（働き手）」が参加者となりますし、unitoだと、「施設」と「ゲスト」が参加者になります。

マッチングプラットフォームの本質は、これらの参加者が出会える場を提供し、参加者の課題を解決することになるでしょう。

この「出会いを促進し、参加者の課題を解決すること」を事業として効率的、かつ、高い質で満たすためにソフトウェアプロダクトが存在します。
このプロダクトの役割自体は、事業のフェーズによって大きく変化していくことになると思っています。

検証期：プロダクトはできる限り薄く、マッチングは人力で

想定する開発体制：
PdM（他職種と兼任）1名、エンジニア1~3名、デザイナー0.5~1名

サービス初期のプロダクトは参加者が少なく、場としての盛り上がりがありません。
参加者を集め、出会いを生み出すことがコンセプト自体の証明にもつながるので絶対条件です。

プロダクトの力だけで勝手に参加者が集まって出会いが生まれるようなフェーズではないので、ユーザーサポートやセールスの力でマッチングを生み出すことが重要になります。

逆に、プロダクト自体はただの掲示板レベルと言っても良いくらいの薄いプロダクトにすることもこのタイミングでは重要です。
（unitoもサービス初期は全てstudioで作っていたりもしました。）

プラットフォーム自体のコンセプトが変わる可能性も大いにありますし、事業としての勝てるユースケースの特定などもできていない状態なので、捨てやすいプロダクトにとどめておいた方が方向転換がしやすくなります。

この薄いプロダクトのフェーズでは、カスタマージャーニーの線を人力も含めて成り立たせるにはどういった機能が必要かという点と、サーバーレスなどの移行しやすい・捨てやすい技術選定が重要なイシューになります。

また、このフェーズで人力でのマッチングを実施することで、チーム全体でのユースケースやユーザー理解が促進され、プロダクトを作り込む際にドメインロジックを正しくシステムに反映させることにつながるのでとても重要です。

成長期：必要機能を揃えつつ、次のフェーズへの布石を考える

想定する開発体制：
PdM1~2名、エンジニア5~15名、デザイナー1~2名

少しずつ参加者が集まり、マッチングが作れると、そろそろ人力の限界がやってきます。
このフェーズになると、事業コンセプトの検証完了も同時に意味するため、プロダクトに必要な機能をそろえていくことに注力します。

必要な機能とは、ユーザーにとって快適な体験を提供するための機能と、これまで人力で耐えてきたビジネスオペレーションを自動化する機能の大きく二つあります。

また、初期のプロダクトからしっかりとしたプロダクトになるということで、アーキテクチャや技術構成の見直しもしたくなってきます。

事業的にはこのタイミングでしっかり機能を揃えてイケイケでいくべきという観点と、開発のそろそろアーキテクチャを見直したいという観点のバランスが最も重要なイシューになります。
色々な会社さんの話を聞いていてもこのタイミングでシステムのリプレイスをガッツリやるケースも多いようです。

検証期にしっかりとコンセプトやユースケースなどの検証ができていれば、それをプロダクトに反映させることで、アーキテクチャの見直しとユーザー体験のアップデートが同時に必然的にできるようになるので、検証期の頑張りがここで効いてきます。

（unitoではデータ構造とカスタマージャーニーとUIのプロトを行き来しながら同じFigmaファイルで議論しています）

逆に、このタイミングでユーザー向けの改善や機能追加に集中しすぎて裏側の仕組みの整備を怠ると、プロダクト全体のバランスが破綻します。
機能を早くリリースするためにま解像的にロジックを組み合わせたり、「今だけ」のユニーク対応を増やしていくと、その瞬間は成長させられたように感じますが将来の可能性を狭めてしまいます。

やりたいことや作りたい機能が多すぎる中でバランスを取る必要があるので、個人的にはこのフェーズの意思決定が最も重要で難しいのではないかと思っています。

unitoは今このフェーズの中盤〜後半にいて、一番面白いタイミングです。（という話を別のnoteに詳しく書きたいと思います）

成立期：ソフトウェアだからこそ提供できる体験でプロダクト中心に

想定する開発体制：
PdM3~5名、エンジニア15~30名、デザイナー3~5名

プラットフォーム自体が一定の規模を超え始めるとマッチングが人の手を介さなくとも自然と発生するようになり、ブランドパワーが高まってくることでネットワーク効果も高まり、ユーザーがユーザーを呼ぶような状態になっていきます。
いわゆるティッピングポイントを超えるタイミングです。

こうなるとソフトウェアプロダクトだからこそ提供できる体験をいかに届けられるかが重要になります。
膨大なユーザーデータを元にしたレコメンドなどがわかりやすい例です。

データ量も増え、この頃にはマーケットも広がり、ドメインの複雑さが増したことで、システムの運用も簡単ではなくなります。
一方で、さらに新しいマーケットに挑戦できるような付加価値が求められます。

成長期にアーキテクチャの見直しが一定度進んでいると挑戦がしやすく、新たな体験を提供できる基盤が出来上がっているので、当時の頑張りが報われてきます。

この規模になるとシステムが複雑になることは一定度仕方がなく、あらゆるユースケースやマーケットに対応した結果になるので、複雑さへの対応を組織的にどう向き合っていくかが重要なイシューになってきます。

おわりに

プラットフォームがティッピングポイントを超えるまでのプロダクトの動きとイシューを整理してみました。

いかに次のフェーズを意識して、未来の幸せのための意思決定ができるかどうかがPdMとして非常に重要な仕事であることが自分で書きながら再度実感することができました。

次回はこのnoteで紹介した3つのフェーズの中の真ん中にいるunitoが一番面白いという話を書きたいと思いますのでぜひ読んでいただければと思います。

もうすでにunitoが面白そうだと思ってくださった方、ぜひ詳しくお話させてください。

meety.net