マッチングサービスの効率的な開発

Web Factory MK 東京オフィスでBizDevを担当している菅です。

今日は最近お問い合わせや開発依頼が多いマッチングサービスの開発について、どのような開発プロセスが主流か、また効率的な開発手法についてデータを検証しながらお伝えします。マッチングサービスの具体的な機能や実例については、マッチングサイト構築の概要もご覧ください。

拡大するマッチングサービス市場

マッチングサービスの国内市場規模は2021年は対前年比で23%の拡大、5年後の2026年には200%の拡大が予測されています (出典: Cyber Agent マッチングサービス市場規模予測2021)。また、マッチングサービスを含むシェアリングエコノミー市場規模は2020年で2.1兆円、2030年には14兆円と急成長すると予測されています (出典: 一般社団法人シェアリングエコノミー協会 市場調査2020年)

マッチングサービスでPairsやCtoC市場をリードするメルカリ社、Withを日本で運営するIGNIS社の発表記事でも多くハイライトされていますが、成功している各社それぞれ例外なく「早期のマーケットへのアプリやサービスリリース」と絶え間ない「UI/UXの改善」を行いプロダクトフィットを達成するまで続けられます。

プロダクトフィット達成まで開発が必要

プロダクトフィットとは製品/市場適合度（製品市場適合度とも呼ばれる）と日本語では表され、製品が強い市場需要を満たす度合いを示します。 プロダクトフィット(製品/市場への適合)は、サービスやアプリ提供側がアーリーアダプターと出会い、フィードバックを収集し、製品への関心を評価し、成功するベンチャーを構築するための最初のステップとして認識されています。

開発の観点からそれぞれを実現するには多くの開発リソースによる素早い開発とリリース、そしてPDCAサイクルなどで顧客からのフィードバックをUI/UXの改善（すなわち短期間でのアップデート機能の開発とリリース）が必要となります。MVPモデル構築など、急成長する市場に対してはマーケットの成長より早く機能改善が必須となります。このような市況を踏まえた開発体制には下記のような条件を満たす開発パートナー選びが必要になります。

マッチングサービスの開発実績があるパートナーを選ぶ

開発パートナーの選定ですが、当たり前にも思えますがマッチングサービス、それも市場で成功しているマッチングサービスの開発実績があるパートナーを選定するのが必要です。

マッチングサービスと言ってもBtoC, CtoC, CtoB、数は少ないもののBtoBと多くの種類があり、それぞれ共通の機能が多く、またサービスによっては固有で必要になる機能もあります。また、マッチングサービスで重要な要素の一つに、興味をもったユーザーが登録をしてくれる、そしてアクティブなユーザーになってもらう必要があります。ユーザー登録も画面の設計によって成功率が大きく変わります。また、アクティブなユーザとして稼働してもらうためには様々なインセンティブや施策が必要です。これらは成功体験のある企業が保有するノウハウであり、一般的な開発仕様で賄える部分ではありません。

また、開発実績と共に開発会社が蓄積した開発ノウハウや開発に当たりホワイトラベル化された既存ソフトウェアのモジュールを使った効率的な開発が特に重要な確認ポイントです。

先に書きましたが、マッチングサービスの多くは共通の機能が多く、すでに開発済みで利用できるソフトウェアのモジュールがあればゼロから開発する必要はありません。

例えば、CtoCの恋愛マッチングアプリを想定した際に必要な標準的な機能はMVP (Minimum Viable Product)構築に最低限機能のユーザープロファイル、写真やビデオアップロード機能、通知機能などで構成し、それぞれの純粋な開発期間を積み上げるだけでも50日、企画、キックオフまでの工程QAなどを含めると最低4〜6ヶ月が開発に必要となります。

同様の機能を既存の開発済み機能モジュールを使用して開発すれば20日~程度で開発してリリース可能です。もちろん、企画やキックオフまでの工程はこれに追加して必要ですが、開発工程は大幅に最適化をし、時間とコストを削減可能になります。

MVPは想定したコンセプトをいち早くテストするためのPoC (Proof of Concept)に早期投入が必要です。また、本開発に移行しても同様でリリース後に頻度の高いカスタマーフィードバックを反映したUI改善と全体のUX改善が必要となります。

既存の機能を利用するとこんな短期間で、とお考えかもしれませんが、ノーコード開発とも呼ばれるCRMプラットフォームでは当たり前となっているのが実情です。ECサイト構築なども、数年前はゼロベースから開発が必要でしたが、Shopifyのように多くの標準機能とサードパーティー製プラグインを利用して開発不要でモジュール選択だけで高機能なECサイト構築が可能です。マッチングサービスに関しては同様のCRMサービスはまだありませんのでそれに次ぐような開発済みモジュール提供が可能な開発パートナーを選ぶ事が現時点では最適な回答です。

マッチングサービス共通の機能開発時間例

問題提起ができる開発カルチャーであるか

開発を発注するに当たり何かと不安があると思いますが、外部の開発企業であり普段顔を合わせない相手ではあるものの、社内で開発するようにゴールの共有はもちろん課題の共有も必要です。また、その課題に対して解決方法を指示出しをしてコーディングだけを任せると言った開発体制ではなく、積極的に課題を見つけて解決策を提案する、また発注側のビジネススキームやアプリのカテゴリの文化やトレンドを理解してアーキテクチャレベル、採用するフレームワークや最適な要素技術の提案ができる開発カルチャーがある事が必要です。 社内であれば当然行われる事です。コーディングができる開発企業は多数ありますが、開発チームとして当事者意識を持ち、プロジェクトの目的を理解するプロセスがある開発パートナーを選ぶ必要があります。これはプロダクトフイットを目指す過程でのUI/UXの改善・開発継続に必須となります。

開発チームとのコミュニケーション体制

開発チームのマネジメントはマネージャ、メンバー共に学習カーブが必要なので時間がかかります。日々顔を合わせる自社の開発チームであっても簡単ではありませんのでリモートでの開発企業側のチームマネジメントはどうでしょうか。

これは開発体制の最適化にもつながる課題ですが社内のメンバー同様に問題意識とゴールを共有させるのと指揮系統は別と考えて良いでしょう。

王道の解決策はありませんが、一つの確立された手法としては窓口体制です。　発注企業側はPM、オフショア開発企業側は開発チームのマネージャ (会社によりPM、リードエンジニアやブリッジなどとも呼びますが、基本はエンジニアチームのマネージャ)が窓口となり、プロジェクトの全体を把握しているPMと開発の詳細まで全て把握している開発チームマネージャが情報共有をすればそれぞれの組織内ではきちんと情報が共有・実施される体制です。　もちろんチームメンバー同士のコミュニケーションを止めるものではなく、透明性は担保されつつ、チームマネージメントの負荷をPMにかけずプロジェクトの推進とビジネスに集中できるサポート体制です。

依頼主と開発会社の間に入るブリッジSEはブリッジはあくまでもブリッジ、すなわち開発チーム及び発注側の間に入るので「ワンクッション」を置くことになります。例えば発注側からの要望を開発チームのマネージャに伝えて、それからアクションをとってもらうようになり効率的ではありません。また、指揮系統としても開発チームメンバーとブリッジは同列になり、指示出しはできません。窓口体制ではダイレクトに情報共有、開発チームのマネージャが直接チームメンバーに指示をしてアクションをとるのでより明確な指揮系統であり、ワンクッションもありません。

開発チームメンバーの固定と離脱について

多くの顧客のフィードバックで一番多くて見落とされがちなのが開発メンバーの交代です。それもシニアな取りまとめ役メンバーが交代する場合も多く見受けられます。

ソフトウェア開発のビジネスは競争が厳しく、顧客に提案する際はベストなメンバーを見かけ上揃えて提案する業者も少なくなく、キックオフ時には万全の体制でのぞみますがいつの間にかシニアメンバーは交代している、シニアメンバーが管理していたメンバーも交代しているというのが珍しくありません。有能なエンジニアは需要も多く常に業界内で「取り合い」の状態にあります。多くの有能なエンジニアを揃える事ができれば良いのですがそうも行かないのが現実です。　メンバーの入れ替えは再度の学習カーブ取得が必要になり生産性は落ち、そのコストは発注側の隠れた負担になります。

退職によるメンバー交代も仕方がない面はありますが、ソフトウエアの受託開発は退職率の高い業界でもあるので、パートナー選択の際、退職率やキャリアパスについても確認が必要です

開発内容とプロジェクトのスケールにより、メリット・デメリットの双方があり、開発要件や開発の進める手法による部分ももちろんありますが、一概にエンジニアの単価だけで開発パートナーを決めることは、避けた方が賢明です。マッチングサービスの開発実績が豊富、かつ成功体験があり、 優れたエンジニアを多く抱え、積極的な問題解決を提案する企業文化を持つWeb Factory MKでの開発を検討されて見てはいかがでしょうか。マッチングサイト構築のサービス概要もご覧ください。

著者について
菅伸吾 スガ シンゴ
米国NDSU大学卒業後日本マイクロソフトにてプロダクトマネージャとして組み込み機器むけWindows製品を担当。Windows製品本部にて製品ローンチを経験後、インテル株式会社にて大手PCメーカーダイレクト営業、タブレットやモバイル機器の新規事業開発従事。2012年にApple Incに入社、iOSプロダクトマネージャとしてiPhoneのマーケティングをリード。AIスタートアップを経て2020年よりWeb Factory MKの営業統括及び開発をサポート。