top of page

マッチングアプリで開発実績が無いまま受託、開発した結果、機能実現に対応できずに失敗


ただ、マッチングアプリに関しては機能要件などが複雑かつ特殊であることが多いため、開発実績を持たずにチャレンジするのはリスクが大きいと思われます。



【失敗例】管理者側の機能が複雑かつ特殊性が強いため開発実績が無いとトラブルになる確率は9割近い


取引先のシステム会社からマッチングアプリ(もちろん合法的なアプリです)開発について紹介をいただきました。


開発資金も多く、納期もそれほどタイトではないことから社内で提案をあげたところ積極的に受託していく方向で話がまとまりました。


企画会議から参加することになりまずは構築するシステムの全体構成を確認し、方向性など使い方に関する絞り込みからスタートしました。


現在のシステムが古くなってきており回収よりも新規構築のほうが後々の管理が楽になるということから新規構築として依頼が入りました。



稼働中のシステムについてはドキュメントが無く、どのような仕様になっているのかを把握するには稼働中のシステムを確認するしかなく、調査時間だけで1か月ほどかかってしまいました。


調査によって全体像が把握できて来たころ合いから現機能をまとめ、新規で追加になる要件を盛り込み要件定義書を作り上げました。


先方からGOがおりたので基本設計、詳細設計の作成に入ったところでクライアント様から新機能要件について追加が出たりはしましたが大勢に影響はありませんでした。


その関係で多少の遅れも発生しましたが基本設計、詳細設計共に出来上がり構築フェイズに入りました。


アジャイル開発で機能ごとに成果物を納品していたのですが、機能要件で修正ラッシュになってしまい早々と納期が遅れる事態が発生してしまいました。



問題になったのは管理者側の機能要件があまりにも特殊過ぎて理解が出来なかったことだと認識しています。


ただし途中で開発会社を変更することはできないと言われ追加予算などの協議を行いながら開発を継続していました。


その間も出来上がる機能についてはほぼNGがでてしまいその度に修正する事態が発生。



その中でも特に問題になったのは動画に関して新しい手法が出てきた際、新技術を積極的に取り入れてほしいというものでした。


調査に時間がかかると提案をしたのですが、トラフィック量を考えると新技術にするほうがスムーズに稼働しランニングコストも安くなるとして追加予算を払っても新技術対応を求められました。


その間も納品する機能に関して修正依頼が入り続けており当初の予定よりも納期遅れが出ることが深刻化してきていました。


受託に際し、追加予算や納期遅れについて了承していただいていたものの、やはり遅れが頻発してしまったことで最終的な納期を決めてほしいと言われてしまいました。


このまま開発を続けていては正確な納期を出すことが出来ないと、正直に話をしたところ大幅値引きを提案されてしまいました。


ただでさえ工数がかさんでリソースを相当取られてしまっていることもあり、値引きには応じられないと反論したところ、マッチングアプリ経験のあるPMを入れてほしいと要望が入りました。


自社内でマッチングアプリを構築した経験があるPMがいなかったのでランサーズなど外部のサイトで募集を募りましたが費用が全く合わなかったり、そもそも経験者が少なすぎて期待に沿う人材が見つかりません。


そこで既存のPMがクライント様に常駐し逐一、開発内容を報告することで対応となりました。


それでもあまりにも特殊な開発であるため、理解するだけでも精一杯という状況は変わらず、開発に携わっているエンジニアからもギブアップしたいという声が出てしまいました。


そこで社内検討した結果、案件をギブアップすることで方向性が決まり、これまでのドキュメント、開発内容を成果物として開発途中でギブアップすることで決定しました


クライアント様からは途中清算についていくつか条件を出されましたが、あまりにも厳しいもの多かったことや、代わりの開発会社を見つけてほしいといった要望などが強く、いくつか取引先に連絡をしたものの、どこもリソースが足らず案件を振ることが出来なく八方ふさがりになってしまいました。


最終的にクライアント様側で開発会社を見つけてこられたので引き継ぎ期間としてPMとエンジニア1名が1か月常駐することになりました。


引継ぎが完了した時点で撤退になったためその後、システムが完成したのかはわかりませんが、社内ではマッチングアプリの開発案件はNGになってしまいました。


【失敗の理由】マッチングアプリを含む特殊ジャンルは専門の開発会社に任せる


この失敗例に関しては先に結論から話したいと思います。


マッチングアプリについては出会い系サイトの開発経験を持っているシステム開発会社にお願いするべきです。


ノウハウのかたまりであるマッチングアプリは開発実績を持っていない開発会社では勘所がつかめないのでまず失敗してしまいます。


なぜか?


マッチングアプリの前身は出会い系サイトです。


ここでいう出会い系サイトとはサクラと呼ばれるオペレーターが異性に対してやり取りを積極的にすることで課金を伸ばすビジネスモデルを持ったサイトのことです。


ダイヤルQ2が陰りを見せてきていた1999年にドコモのI-modeが運用を開始しました。


それに合わせるように出会い系サイトが登場しています。


モバイル端末向けサイト自体が少なかった時代ですがi-modeは爆発的な利用者数の増加ににより一気に電話からSMS時代に入りました。


その時代登場したのが出会い系サイトです。


集客すればお金になる、ということでダイヤルQ2を展開していた業者が一気に出会い系サイトになだれ込みました。


集客方法は今でいうスパムメールですが、当時はチェーンメールなどと呼ばれていました。


それからマッチングアプリ時代に入るまでサクラを使った出会い系サイト全盛の時代になるわけです。

※諸説ありますが実は、サクラを使うこと自体は違法ではありません。システム上100%出会うことが出来ない場合は法律に抵触する可能性があります。



マッチングアプリを展開しているいくつかの企業は前身が出会い系サイトであり、20年以上のノウハウを持っていますからシステムの隅々まで熟知しています。


このビジネスのポイントは管理システムです。


およそ通常の企業では考えられないような複雑な管理システムを組み上げることで課金率、滞在率、やり取り率を上げてきているのがマッチングアプリの本質です。


私が知る限り、出会い系サイトのシステム開発を専門で行っていた開発会社は日本で10社もありませんでした。


縁が合ってその開発会社の1つとお仕事をさせていただいたことがありますが、その内部設計の複雑さに驚きを隠せませんでした。


あまり書くことはできないのですがシステムの基本は以下のような感じです。


・広告管理システム

・オペレーター管理システム

・検証プログラム

・課金システム

・キャラクター管理システム

・自動返信システム


これらが複雑に組み合わさってシステム全体が構築されていました。


特に驚いたのは、オペレーター管理システムです。


やり取りごとのメッセージが管理されていて、どのメッセージで課金に結びついたのか、といった効果検証プログラムと連動していました。


さらに、どのオペレーターがやり取り率が高いのか(やり取りで課金されているためこの率が高いと課金率が高いのと同義になる)をリアルタイムに計測するプログラムが走っていました。


マッチングアプリはいわゆるメッセージ交換サービスです。


メッセージに係わるすべてのアクションに対して計測プログラムが裏側で走っており、効果検証されていました。


もちろん、計測プログラムとポイント購入を制御する課金プログラムも連動しています。


こうしたプログラムは売り上げを上げるために実装された完全なるノウハウです。


門外不出のノウハウが外に出ることはありません。

従ってマッチングアプリ開発をした知見の無い開発会社がそのノウハウを身に着けることはほぼ不可能です。


スマホが一般化し、誰しもがマッチングアプリを使うことに抵抗感が無くなってきたため、今ではマッチングアプリで婚活をする方も増えてきており市場の盛り上がりは過去最高を更新しているとさえ言われております。


ただし、そのシステムはユーザービリティ、管理項目の増加などからさらに複雑、特殊化しています。


その特殊性を把握しようとするとベテランでも半年から1年はかかると思っています。


そこまでの調査時間をかけて開発を行うほど懐の深い企業は稀です。


従って特殊性が求められる業種においては開発実績が無ければお断りをする勇気を持つことも大切です。


ちなみに弊社では


5年ほど前にマッチングアプリに関する開発で企画から保守まで手掛けた経験があるので、お話に関して即お断りすることはありません。


企画段階ではよくTinderのようなシステムを作りたいです、といったお話をいただくことが多いのですが、Tinderは外国のシステムなので、いろいろな面で使い勝手を日本仕様に合わせなくてはなりません。


それは日本のマッチングアプリが諸外国と異なりしっかりと管理されているからです。


管理側の要件をまとめるなどは弊社でも行っておりますが、開発に関しては弊社パートナー企業でマッチングアプリ作成経験がある開発会社と一緒に進めるようにしています。


どれだけ要件定義をまとめても、構築途中でかならず内的、外的要因により修正もしくは機能追加が発生するからです。


どの程度の読みを想定するかについては実際に構築を行った開発会社さんでなければ難しいからです。


無料相談も開設しておりますのでご興味のある方はご連絡願います。


bottom of page