Uber、With、Airbnbなど、ニーズ急増!マッチングアプリ/サービスのオフショア開発(メリット・注意点・成功事例)

Uber、With、Airbnbなど、ニーズ急増!マッチングアプリ/サービスのオフショア開発(メリット・注意点・成功事例)

急速なスマートフォンの普及によるコミュニケーションのあり方の変化、消費活動の変化、シェアリングエコノミーの発展、そして近年の新型コロナウイリス流行の影響など、大きな社会変革の流れの中、「人と人」や「人とモノ」、「人とコト」を繋ぐようなマッチングアプリ/サービスのニーズは急増しています。企業としてもそうしたサービスの開発に取り組もうとする流れが拡大しています。

 

一方で、日本国内におけるITエンジニアの不足から、国内開発会社での開発単価高騰は顕著です。また、マッチングアプリ/サービスの開発においてはオフショア開発によるメリットが大きく、その活用が進んでいる現状があります。

 

そこで、本記事では、オフショアにおけるマッチングアプリ/サービス開発について、そのメリットや成功のポイント、注意点、実際の開発事例などを解説していきます。

目次

・そもそも、オフショア開発とは?

・オフショア開発はマッチングアプリ/サービスの開発に向いている!

 - 欧米での成功事例が多いマッチングアプリ業界は海外企業の開発実績が多い!

 - 継続的なUI/UX開発は、オフショア開発を活用したラボ型がぴったり

・オフショア開発におけるマッチングアプリ開発の注意点

 - コミュニケーション体制の重要性

 - チームメンバーの固定と離脱

・オフショア開発におけるマッチングアプリ開発事例「SYNCA by WARC」

・まとめ

そもそも、オフショア開発とは?

さて、本題に入る前に「オフショア開発」について簡単に説明しておきます。オフショア開発とは、業務ソフトウェア開発やWebシステム開発、スマホアプリ開発、そしてそれらの運用保守管理などを海外の開発会社や海外子会社にアウトソースすることを言います。日本国内4000社を対象に総務省の行った調査によると2008年度時点で既にほぼ半数の企業がオフショア開発を既に行っているか、もしくは導入予定でした。CAGR(年平均成長率)についてはいくつかの数字がありますが、低く見て3.8%で試算しても2021年には日本の70%の企業がオフショア開発を行っており、今後も同じもしくはより高い成長率で推移していくと予測されます。

 

オフショア開発が多くの企業に選ばれる理由は大きく分けて二つあります。一つはコスト削減、もう一つはリソースの確保です。高騰する日本人エンジニアに比べ、海外のエンジニアは人件費が抑えられる傾向にあります。開発費用はエンジニアの人件費に拠るところも大きく、コスト削減が実現できるというわけです。リソースの確保という面では、ニーズに比して日本人エンジニアの数が不足し、大手事業会社であっても、IT開発リソースが不足している現状があります。更に今後の展望としても、技術者が高齢化し、定年退職、少子高齢化が進み、日本においてリソースを確保することが難しくなっていくでしょう。そのため、そのリソースを海外に求めているという側面があります。

オフショア開発はマッチングアプリ/サービスの開発に向いている!

| 欧米での成功事例が多いマッチングアプリ業界は海外企業の開発実績が多い!

 

さて、そのようなオフショア開発は、なぜマッチングアプリ/サービスの開発に向いているのでしょうか? まず、前提として、マッチングアプリ/サービスに関して、世界的なトレンドを作っているのは欧米で開発されたものです。そのため、日本市場よりも欧米市場での立ち上がりが早く、成功しているサービスに関しても数が多いです。当然、海外における開発実績の数も多くなっています。この開発実績の多さこそ、オフショア開発がマッチングアプリ/サービスの開発に向いている理由の一つです。

 

マッチングサービスと言ってもBtoC、CtoC、CtoB、BtoBなどと多くの種類があり、それぞれ共通の機能もあれば固有で必要になる機能もあります。開発を進めていく上では、いくつかの機能モジュールを組み合わせていかなければなりませんが、多くの開発実績を持つ企業であれば、様々な機能モジュールの開発経験があり、そのノウハウを転用することができます。そのような点で、多数の開発実績を持つ企業が見つけやすい「オフショア開発」が向いているということが言えます。

 

| 継続的なUI/UX開発は、オフショア開発を活用したラボ型がぴったり

 

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

 

マッチングサービスでWithを日本で運営するIGNIS社、Pairsを運営する株式会社エウレカ社、そしてCtoC市場をリードするメルカリ社の発表記事でも多くハイライトされていますが、成功している各社それぞれ例外なく「早期のマーケットへのサービスリリース」と絶え間ない「UI/UXの改善」を行っています。開発の観点からそれぞれを実現するには多くの開発リソースによる素早い開発とリリース、そしてPDCAサイクルなどで顧客からのフィードバックに基づくUI/UXの改善が必要となります。このような市況を踏まえた開発体制を構築するためには、豊富なリソースを抱え、そうした活動に強みを持つ開発パートナー選びが必要になります。

 

その点、オフショア開発における契約形態の一つである「ラボ型」の活用が有効になります。ラボ型開発とは、作業要員×期間に対する契約を指し、オフショア開発会社内に専任の作業チームを確保する形になります。PDCAサイクルを回し、顧客からのフィードバックに基づくUI/UXの改善を実施していく上で、まさにぴったりの開発体制と言えます。

オフショア開発におけるマッチングアプリ開発の注意点

一方で、オフショア開発におけるマッチングアプリ/サービス開発の注意点もあります。こちらを押さえておき、パートナー選定に活かすことが重要です。ラボ型を活用し、チームとして開発していくため「コミュニケーション体制」と「チームメンバー」についてがポイントとなります。ひとつひとつ見ていきましょう。

 

| コミュニケーション体制の重要性

 

開発チームのマネジメントはマネージャ、メンバー共に学習カーブが必要なので時間がかかります。日々顔を合わせる自社の開発チームであっても簡単ではありませんのでリモート、かつ言葉も違う、顔も合わせたことが無いオフショア開発企業側のチームマネジメントは難しいものとなるでしょう。これは開発体制の最適化にもつながる課題ですが、社内のメンバー同様に「問題意識とゴールの共有」と「指揮系統」は別と考えて良いでしょう。ましてやお互い母国語ではない英語でのコミュニケーションとなるので発注側企業がオフショア企業側のチームを全てマネジメントするのは困難です。

 

王道の解決策はありませんが、一つの確立された手法としては窓口集約体制があります。発注企業側は 「PM」、オフショア開発企業側は開発チームの「マネージャ (会社によりPM、リードエンジニアやブリッジなどとも呼びますが、基本はエンジニアチームのマネージャ)」が窓口となる体制です。プロジェクトの全体を把握しているPMと開発の詳細まで全て把握している開発チームマネージャが情報共有をすれば、それぞれの組織内ではきちんと情報が共有・実施される体制です。

 

もちろんチームメンバー同士のコミュニケーションを止めるものではなく、透明性は担保されつつ、チームマネージメントの負荷をPMにかけずにプロジェクトの推進とビジネスに集中できるサポート体制です。

 

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

 

| チームメンバーの固定と離脱

 

続いて、チームメンバーの問題です。オフショア開発において多く、見落とされがちなのが開発メンバーの交代です。それもシニアな取りまとめ役メンバーの交代は問題を生じさせます。あくまで一例として聞いていただきたいのですが、オフショア開発は競争が厳しく、顧客に提案する際はベストなメンバーを見かけ上揃えて提案する業者も少なくなく、キックオフ時には万全の体制で臨みますがいつの間にかシニアメンバーは交代している、シニアメンバーが管理していたメンバーも交代しているというのが珍しくありません。

 

有能なエンジニアは需要も多く常に業界内で「取り合い」の状態にあります。多くの有能なエンジニアを揃える事ができれば良いのですが、そうもいかないのが現実です。メンバーの入れ替えは再度の学習カーブ取得が必要になり生産性は落ち、そのコストは発注側の隠れた負担になります。退職によるメンバー交代も仕方がない面はありますが、オフショア開発に限らず、ソフトウエアの 受託開発は退職率の高い業界でもあるので、パートナー選定の際、退職率やキャリアパスについても質問をしましょう。

オフショア開発におけるマッチングアプリ開発事例「SYNCA by WARC」

さて、最後に実際にオフショア開発でマッチングアプリ/サービスを開発した事例をご紹介します。ご協力いただいたのは、マッチングアプリ/サービスの最前線である欧米での事例を多く持つWeb Factory MK様です。2010年創業のマケドニアの首都スコピエに本社を置くソフトウェア開発サービス会社となっています。開発対象として紹介するのは、SYNCAというサービスの事例です。東京に本社を置く急成長している人材サービス提供会社の株式会社WARC (以下WARC)が運営する採用マッチングサービスとなっています。

 

Web factory MK

http://www.offshore-kaihatsu.com/mypage/web-factory-llc/

Web factory MKはマケドニアなどに開発拠点をもつオフショア開発企業です。高い技術力、ノウハウがなければ難しい金融、医療といった業界での実績も持つ、実力ある企業です。特にAIの分野では、Google主宰のKaggleで表彰され、マケドニア政府からの出資を受けるほどです。ぜひお気軽にご相談ください。マッチングアプリ開発については右記を参照ください(https://www.webfactory.mk/ja/matching)。

 

◆ 開発の背景

WARC社は、自社の提供するハイエンドのヘッドハンティングサービスが市場で成長するにつれ、HR市場のさまざまなセグメントにおける未開拓市場を発見しました。優れた営業組織には優れたセールスオペレーションとサポートといった管理部門の人材が必要ですが、HR市場で管理部門の求人はセールスやマーケティングの人材ほどには開拓されていませんでした。そこで、ヘッドハンティングによるマッチングサービスのみならず急成長しているシェアリングエコノミー市場で管理部門の人材にフォーカスした人材と求人のマッチングサービス立ち上げを計画しました。


◆ サービスの概要

主に掲載企業向けシステム「Synca for Business」および求人社システムの「Synca for Clients」にて構成されており、Ruby on Rails on Backendで開発され、フロントエンドはVue.jsで開発されています。このアプリケーションのソリューションは、求人情報を提供するだけではなく登録ユーザーが持っているさまざまなタイプのスキルを考慮して、クライアントと企業の間のスキルの一致率を計算し、さらに登録ユーザーの経験値などを考慮して想定年収のレベルも自動計算するAIアルゴリズム機能もあります。

 

主な機能は、オフラインチャット、ビジネスチームの多くのメンバーが実行できるレビュープロセス、企業が最適なものを見つけるのに役立つAIを採用したマッチングアルゴリズムなどが組み込まれます。マッチング機能に必要な多くは既存または比較的導入がしやすいフレームワークやWeb Facotry MKが所有する対応する機能のソフトウェアスタックを利用して開発されています。

 

一般的にはこのようなサービスプラットフォームはリリースから継続した改善を経てプロダクトフィットを達成し、必要な最新の技術モジュールでスムーズなUX / UIを実現することが必要です。WARC社はWeb Factory MKとラボ型開発契約を結び、使用する企業側と求人側の満足度を高めるマッチングアルゴリズムとUI/UX改善に取り組み続けています。現在SyncaはBetaリリースかつプロモーションも行われていないにもかかわらず、1000人以上の求人登録者にサービスを提供し、20社以上の企業にサービスを提供しており、近日中に大規模なマーケティングキャンペーンと共に正式リリースが予定されています

 

◆ 開発体制構築の課題

WARC社の経営陣は、新しい人材マッチングのサービスプラットフォームのフレームワークとビジネスプランを作成し、社内の開発者が基盤と開発プランを設計しました。構想したサービスプラットフォームには、数名のフルスタックエンジニア、PM、DevOpsなど、多くのリソースが必要でした。

 

そうしたリソースを最適なコストで用意するために、多くのスタートアップ企業や新規事業立ち上げと同様、高い生産性を持ち緊密に効率良く運営されているチームが必要となります。

 

WARC社のビジネスのコアビジネスがソフトウェア開発ではないことを考えると、現実的にはハイレベルなデベロッパー人材を迅速かつ効率的に採用することは厳しく、 多くの選択肢の中で、彼らは開発チームにニアショアまたはオフショアの開発チームを自社の組織に組み込むことを決定しました。


一方で、社内の開発チームのメンバーは英語のコミュニケーションに課題があり、まずはベトナムでN1レベルで日本語対応可能のブリッジSEを提供する開発リソースを探していました。しかし、リサーチしていく中で、ブリッジSEがまずは優秀なPMである必要があり、N1レベルの日本語技能があってもPMとして優れていない場合、ブリッジSEがコミュニケーションのボトルネックになることを理解しました。また、通訳や翻訳を入れるとコスト追加とコミュニケーションに時間がかかり、効率的に開発は難しいと判断しました。


そこで、WARC社は開発に適切なパートナーを選択するためのプロセスを経て、Web Factory MKと開発カルチャーやコミュケーション方法などを詳細に話し合い、発注を決定します。

 

Web Factory MKはマケドニアの企業であり、コミュニケーションは英語ベースになりますが、それを超えるメリットがあると判断されました。コミュニケーションにおいて不要な重複や不足を避けるために、Web Factory MK側のPMがWeb Factory MKチーム内のコミュニケーションを全て管理・把握し、WARC社はPMとコミュニケーションを取れば良いという体制を構築したからです。

 

チーム編成においてWeb Factory MKは、生産性が高い優れたデベロッパーで構成されており、他のオフショア開発事業者と比較して開発者の人数を減らす事ができ、結果エンジニア単価ではより低価格の業者と比較しても効率的に開発チーム編成が可能になります。

 

◆ 技術的な課題

開発するプラットフォームのソリューションは当初 GolangとVue.jsで開発されており、パフォーマンスとスケーリングに問題があり、多くのレガシーコードが存在していました。 WARC社のようなスタートアップにとってテスト段階にて必要な機能に最適なソリューションを見つけるのには多くのエンジニアリソースと時間が必要になり、必然的に起こった課題です。Web Factory MKが SYNCAの開発チームに統合され、すぐにソリューションの安定化を提案し、新たなフレームワーク上にソリューション全体を最初からやり直す必要があると判断しました。

 

適用するフレームワークや技術の検討を重ね、開発効率も考慮してRuby on Railsの実績のあるフレームワークを選択して開発を開始しました。実績がありかつWeb Factory MKが開発経験のあるフレームワークを選択する事はプロトタイピングとMVPの開発工程最適に大きく貢献しました。

システムをゼロから構築するにあたりWeb Factory MKは WARC社の構想するビジネスの最終目標を理解した上で進め、アーキテクチャ、DB、および機能に関する多くのことに関して積極的にアイデアを提案し、実際に採用にもつながりました。 

まとめ

いかがでしたでしょうか? 今後、ビジネス活動上、ますます重要になっていくであろうマッチングアプリ/サービスの開発ですが、オフショア開発の利用が成功のポイントとなってきます。是非、本記事を参考にご検討いただき、取り組んでみてください。


企業選定にお困りでしたら、オフショア開発. comの専門スタッフが無料相談を受け付けておりますので、お気軽にご利用ください。

このページを見た人は以下の記事も見ています。(関連記事)