開発の記事一覧 | マッチングワン

開発

TodoONadaでは、各種マッチングサービス（恋愛系・不動産・求人）にフォーカスを宛て、必要な機能や開発期間、そして開発費についてご紹介しました。

しかしその中でも一番ネックになるのは『開発費』の部分だと思います。
最低でも400万円程度……ともすれば1,000万円もの費用がかかる事業は、なかなか踏み出すのに勇気が要るでしょう。

しかしその開発費用をもっと圧縮できる開発手法があればどうでしょうか？
今日はそのような素晴らしい開発手法『ノーコード・ローコード開発』についてご紹介します。

ノーコード、ローコード開発とは？

『ノーコード開発』『ローコード開発』とは『コードを書かずに、あらかじめ用意したシステムを組み合わせる事により、ソフトウェアを作成する』開発方法です。

そもそもソフトウェア開発になぜ膨大な費用が必要か、と言えば『人がコードを書いているから』です。
何百時間も掛けてソフトウェアについて学習したエンジニアが、０からそのソフトウェアのためにプログラム言語を書き、設計し、バグがないかテストを行うからこそ、大きな開発費と長い開発期間が必要になります。

しかしそのコードをパーツごとにあらかじめ用意しておき、レゴブロックのように組み合わせるならばどうでしょうか？
ドラッグアンドドロップでデザインを作成したり、マウス操作でデータベースを構築したり、数クリックで決済を導入することができるのです。
しかもその『組み合わせの作業』を行う人は、プログラミングの知識がなくとも構いません。
０からコードを書くよりもだいぶ開発期間を短縮することができますよね。
そして開発期間を短縮できるということは、開発コストも圧縮することも可能になるのです。

このようにプログラミングを必要としない開発手法を『ノーコード』
そして最小限の部分のみプログラミングを行う手法を『ローコード』と言います。

ノーコード、ローコードの開発事例

そのような素晴らしいノーコード・ローコード開発ですが、『実際のところ上手くいくの？』と疑問に思われたかもしれません。

しかし安心してください。世の中には『ノーコード・ローコードからスタートし、成功したサービス』がたくさん有ります。いくつか例を挙げてみましょう。

PM School・PM Career

『PM School』はプロダクト作りを学べるオンラインスクール、『PM Career』はプロダクト開発者のための転職支援サービスです。

どちらも非常に優れたサービスであり、特に『PM Career』の方には、リクルートやマネーフォワード等名だたる企業が利用しています。
しかしこれらのサービスは、間違いなくノーコード開発で作られました。

これを言うと驚かれるのですが、PM SchoolとPM Careerはリリース時には本当に一行もプログラムを書いていません。せいぜいGoogle AnalyticsやTag Managerのタグくらいでしょうか。本当にプログラムっぽいものは一切書きませんでした。（引用元）

Webエンジニアの単価上昇や、短期でのリリースを目指すためノーコード開発を選んだとのことですが、それぞれリリースまでに『３～４ヶ月しか掛かっていない』らしく、ノーコードならではの低コスト・短期間リリースを成功させています。

Flexiple　エンジニアと企業のマッチングサービス

海外からも事例を挙げてみましょう。
この『Flexiple』というサービスは技術系の人材と企業をマッチングするサービスで、その使いやすさ・エンゲージメントまでのスムーズさから、多くの人に支持されています。
登録者は10万人を超え、約10億円もの報酬額が動くサービスですが、なんとこれも『Bubble』というノーコードツールで開発されています。

同社によればノーコードツールを利用することによって、年間３万ドル（約４5０万円）もの開発費を節約することに成功しているとのことです。

ノーコード、ローコード vs スクラッチ開発　どちらが適切？

ここまでノーコード・ローコードの素晴らしさについてご紹介してきましたが、逆に欠点はないのでしょうか？
そのような素晴らしい開発手法であれば、なぜ現在でもスクラッチ開発（１から作る手法）されたサービスのほうが多いのでしょうか？

残念ながら、ノーコード・ローコード開発にも欠点はあります。

ノーコード・ローコードの欠点：機能・デザインの制限

序盤にノーコード・ローコード開発は『あらかじめ用意したシステムを組み合わせる』ことにより開発を行うとご説明しました。
逆に言えば『用意されていないシステムは実装できない』という欠点があります。

例えばユーザーから『Facebookアカウントで登録・ログインできるようにしてほしい』という要望があったとしましょう。
スクラッチ開発であれば、『Facebook SDK』や『OAuth』を用いることにより実装が可能です。
しかしノーコード・ローコードの場合は、開発ツール側が対応していなければ実装することができません。

対応している機能であれば、簡単に、それこそエンジニアでなくとも数クリックで実装が可能でしょう。
代わりに対応していない機能、実装されていない機能については実装できないか、フルスクラッチ開発での実装よりも多くの手間をかけて実装する形になってしまうのです。

なお、これはデザインでも同じことが言えます。
ノーコード・ローコード開発は、用意されたデザインパーツを元に、誰でも見栄えのするデザインを当てはめることができます。
しかしその代わりに、あなたの理想とするデザインコンセプトを実装することは、かなり難易度が高いです。
ノーコードツールによっては実装が不可能ですし、デザインできるツールだったとしても、相応の手間と難易度が要求されるでしょう。

もし『特別な機能を実装したい』『ブランドコンセプトにあったデザインを施したい』という場合、ノーコード・ローコード開発は向かないかもしれません。

エラー・予期しない動作をした際、原因がつかみにくい

ノーコード・ローコードで組み合わせるツールは、一流のエンジニアが作成したものであり、また多くのユーザーが利用している物なので不具合やエラーが起きにくいです。
しかし不具合やエラーが０という訳ではありません。

どのようなシステムでも不具合やエラーは起こります。
ここで問題になるのは『ノーコード・ローコード開発ではどこでエラーが起きたのかわかりにくい』という点です。

例えば『メールフォームを実装したのに、メールにデータが届かなかった』としましょう。
この場合、スクラッチ開発ならば原因究明は難しくありません。
悪いのはフォームなのか、設定なのか、送信サーバ、もしくは受信側のメールサーバなのか、ログやエラーメッセージを追うだけで問題の切り分けができるでしょう。

しかしノーコード・ローコードの場合、そうはいきません。
間違っているのはあなたのフォーム設定かもしれませんし、メールの設定かもしれません。
単に受信したいメールアドレスの入力を間違えている可能性もありますし、あなたに原因はなく本当にシステム側のバグかもしれません。
問題は多くのノーコード・ローコード開発ツールでは、エラーログ・サーバログを確認できないため、どこで処理が止まったのか分からないことにあります。

スクラッチ開発では、ログも読めますし、開発者はどのようなプロセスでメールが送られているのか把握しています。よって解決は短時間で済むでしょう。
しかしノーコード・ローコード開発では、原因の究明に時間がかかりますし、本当にシステム側の不具合だった場合は、ノーコードツールの開発者が不具合を改善するまで長時間待つか、その機能を諦めるしかないのです。

なお、こういった不具合やエラーは大規模なシステムになるほど発生する可能性が高くなります。
よって恋愛系マッチングのように、複雑な機能をたくさん用意する必要があるサービスについては、ノーコード・ローコード開発を避けたほうが無難です。

第三の選択肢『パッケージを使う』という手も

ここまでご説明した通り、ノーコード・ローコード開発には『カスタマイズ性に欠ける・多様な機能を持つサービスに向かない』といった欠点があります。
しかしフルスクラッチ開発にも『費用が高い・開発期間が長期にわたる』といった問題があるのはご承知のとおりです。

そこで検討していただきたいのは『パッケージソフトによる開発』です。
パッケージソフトであれば、マッチングサービスに必要な基本的な機能があらかじめ実装されています。
ノーコード・ローコードと同じく、あらかじめ開発されたベースを用いるため、導入コストを抑えることが可能です。

それでいてパッケージソフトであれば、追加機能の実装も問題有りません。
ご要望に応じて開発元が直に機能を追加するため、『あらかじめ用意された機能しか使えない』といった制約に縛られることは無いのです。
例えば『AIによるマッチング』や『外部のシステムとの連携』といった、ノーコード・ローコード開発では行いにくい機能も、自由に追加することができます。

もしマッチングサービスを作るにあたって『予算と開発期間のバランスを取りながら、自由度の高いサービスを作りたい』と考えておられる場合は、是非『マッチングワン』等のパッケージをベースにしたサービス開発を検討していただければと思います。

マッチングサービスを運営するには？

『マッチングサービス』は、今大変需要が高まり、急成長している分野です。
ただし、その運営は決して簡単ではありません。

TodoONadaでは、マッチングサービスを低コストに始める方法や、サービスで決めないといけないこと・運用方法等について本ブログでご紹介しています。
各記事をご拝読いただければ幸いです。

セキュリティで守るべき情報

まずマッチングサービスを運営するに当たり、どのような情報を守らなければ行けないのか、その点について理解を深めましょう。

『個人情報』及び『要配慮個人情報』

個人情報は、守るべき一番基本となる情報です。氏名やメールアドレス、年齢・性別・住所等がこれに当たります。

これらの情報は『外部に漏らさない』というだけでなく、『個人情報保護法』に沿った形で用いる必要があります。
いずれ別記事で詳しく説明しますが、『利用目的を通知する』『通知した用途以外では使用しない』『第三者（委託先）等へ勝手に渡さない』といった制約が定められています。

また『個人情報保護法』では、特に慎重な取り扱いが求められる情報を『要配慮個人情報』と定義したうえで、厳格な規定を定めています。

『要配慮個人情報』に該当する情報

人種
信条
社会的身分
病歴
犯罪の経歴
犯罪により害を被った事実
その他本人に対する不当な差別
偏見その他の不利益が生じないようにその取扱いに特に配慮を要するもの

これら『要配慮個人情報』を取得する際には『本人の同意』が必要となり、更に『第三者提供』は禁じられています。
マッチングサービスを作るにあたって、これらの項目を登録させるのは基本的に避けたほうが無難です。ましてや表示したり、検索できるようにしたり……といったことも避けるべきです。

クレジットカードなどの決済情報

クレジットカード情報や、各種決済手段の情報も取り扱いに注意が必要です。

なお月額利用料を取るとしても、取引を仲介するとしても、現在クレジットカード情報の非保持化が法律で定められています。（改正割賦販売法）
なので守る・守らない以前にカード番号等の情報は『保有しない設計』としなければなりません。

基本的に『決済代行会社』と契約を結ぶ形となると思いますので、『決済代行会社』及び『システム会社』にこの点は詳しく聞きてください。

マッチングサービス固有の情報

また他のサービスと違って、マッチングサービスだからこそバレたくない情報というのも存在します。

例えば『転職マッチングサービス』であれば、多くのユーザーが”登録していること自体”を『今の会社にバレたくない』と思っています。
そこで多くの転職マッチングサービスでは、『現在働いている会社のマッチング画面に出てこないようブロックする機能』や『個人情報非公開機能』といったものを用意しています。

また恋愛系マッチングサービスでは、『近くにいる人』をマッチングする機能が備えてあります。
ただしこれも精密に調べられるようにしてはいけません。何箇所かで計測することにより、自宅住所や職場等を特定できるようになってしまうからです。

マイナンバー情報

そして念の為触れて置きたい点として『マイナンバー情報』が挙げられます。
この『マイナンバー情報』ですが、仲介型のマッチングサイトであっても、基本的には取得が必要ない情報です。

しかしながら、クラウドソーシング等でユーザー同士が仕事のやり取りをする際、支払調書等でマイナンバー情報の取得が必要になることはあります。
その際、サービス内のチャットでマイナンバー番号等をやり取りしてしまうと、サービス運営側に責任が課せられる可能性もないとは言えません。
よってマイナンバーをやり取りする際は、直接やり取りをしてもらう等の案内が必要となります。

また、最近ではマイナンバーカードを利用した『本人確認』『年収証明』といったシステムも推進されるようになってきました。
大手サービスも導入が始まっているため、今後あらゆるサービスで使われるようになるかもしれません。
基本的にマイナンバー情報を直接保持する形にはなっていませんが、適切な運用・システムの構築に努めてください。

セキュリティを強化するための対策

ではここまで取り上げたような情報を守るためには、どのような対策が必要でしょうか？

信頼できるサービスを使う

サービスの構築を依頼するシステム会社や、パッケージソフトがどの程度セキュリティを意識しているのか、外部から調べるのはとても難しいです。

しかし実際に打ち合わせを行う際、その点を聞いてみることはできるでしょう。
例えば以下のような質問を投げかけることができます。

個人情報保護方針はどのようなものですか？
他要素認証には対応していますか？
ユーザー権限の管理方法は？
サードパーティライブラリの脆弱性チェック方法は？
外部サービスとの連携におけるセキュリティ対策は？

またこれらの質問と同時に、導入実績についても聞いてみて下さい。
大手企業は自社で導入するシステムに関して、厳重なセキュリティ基準を敷いていることが多いです。
もし大手企業でも採用されているサービスであれば、それらの基準をクリアしているかもしれません。

ブラウザなどのクロール対策

まず外部に公開される情報についても、第三者に利用されないよう対策が必要です。

特にビジネスマッチングや求職マッチングサービスに関しては、スクレイピングを行うことで営業名簿を作られてしまうことも多々あります。
そこから営業されてしまうと『個人情報を売りさばいているのではないか』という疑念を持たれてしまうこともあるでしょう。

対策としては、まず利用規約で『スクレイピング』を禁止することが必要です。（万一訴訟等になった際、規約は大きな意味を持ちます。大手のマッチングサービスでも、ほとんどスクレイピング禁止が規約に入っています）
また、『レート制限』『CAPTCHAの実装』『ロボット排除規約』等の設定によって、スクレイピングからデータを保護することもできます。このあたりはシステム会社の方に相談してみてください。

外部製品の脆弱性対策

また、直接的なシステム部分だけでなく、外部製品を使う際の脆弱性対策も必要です。

例えば決済部分を実装する際、決済代行会社からシステムが提供されることはよくありますが、これらのサービスも日々状況に合わせてセキュリティアップデートが行われます。
それらアップデートは自動で反映される訳ではないので、度々更新を確認し、必要な作業を行うことが肝要です。

また、認証サービスや通知サービス、CDN・FaaS・チャットサービス等、外部サービスを使うケースは多々あることでしょう。
それら全てを適切な形で接続し、日々アップデートし続けなければ、脆弱性をシステムに抱えることとなります。

セキュリティ体制及びプロセスの構築と実行

そしてセキュリティの漏洩元は、システムだけとは限りません。
マッチングサービスに登録された情報というのは、とても価値があります。
なので従業員や関連会社等がその情報を盗み出し、外部に販売するといった事件が過去に幾度か起きています。

そういった事態を避けるため、情報の管理は徹底しなければなりません。
誰にでも管理者権限を渡すのではなく、権限のある人物を限定し、その人物のみアクセスできるような仕組みづくりが必要です。
また、セキュリティガイドラインの作成、社内教育と確認テストの実施、インシデント発生時の適切な対応手順と訓練等も行った方が良いでしょう。

更にサービスが大規模になってきた際は、セキュリティ部門の作成や、コンサルへの依頼、監査の実施等を視野に入れることができます。

マッチングサービスの情報漏洩は、信頼問題へ直結し、事業の継続を脅かします。
『きっと大丈夫だ』と楽観視するのではなく、最初から力を入れて取り組まれてください。

マッチングサービスを運営するには？

『マッチングサービス』は、今大変需要が高まり、急成長している分野です。
ただし、その運営は決して簡単ではありません。

通話機能やビデオ電話機能を使うにはWebRTCが必須

WEBであれアプリであれ、通話機能を使うには何らかの通信を行わなければなりませんが、一般的なHTTPのリクエスト（WEBページ等と同じ手法）だと遅すぎます。ざっくりと語ると、こちらから『こんにちは』と相手に行ってから届くまでが1～3秒、更にそこから相手が『こんにちは』と返事を返してくるのに、更に1～3秒掛かるレベルです。これではとても通話が成り立ちません。
更にクライアントからサーバへの一方的な通信が基本なので、その点でもリアルタイムの会話は難しいです。

これを『WebSocket』という方式にすれば、少しはマシになりますが、それでもまだラグがあります。

WebSocketの通信イメージ

WebSocketを使えば、サーバとクライアント間でリアルタイムな双方向通信が可能です。ただし、通信は一旦サーバを経由するため、チャット等のテキストデータなら問題ないのですが、音声データや動画データで快適な通話を行うのは難しいです。
またサーバにも負荷がかかるため、AWS等の従量課金制のサーバを使う場合、コストも問題になります。

そこで最善策となるのが『WebRTC』なのです。
『WebRTC』は『Web Real-Time Communication』の略称です。
先程のWebSocketが『サーバとクライアント間のリアルタイムな双方向通信が可能』と説明しましたが、WebRTCは『クライアントとクライアント間でリアルタイムな双方向通信が可能』な通信方式です。

WebRTCのイメージ図

最初にサーバ側で接続を確立した後は、音声データ・動画データを直接クライアント間（P2P）でやり取りします。
大きなデータはサーバ側を通さずやり取りするため、接続環境さえ整っていれば、ほとんどラグを感じさせること無く通信が可能です。

しかもこのWebRTCはブラウザでやり取りが可能です。よってファイアウォールの設定を変更したり、ポートを開放したりといった一般ユーザーには難しい手順も踏む必要はありません。

よって、もしマッチングサービスで通話機能をつけようとするならば『WebRTC』が一番現実的な選択肢となります。

各種クラウドサーバで『WebRTC』を使うには

ではその『WebRTC』はどのように実装できるのでしょうか？
先ほどの図では割愛しましたが、『WebRTC』を実装する場合、「STUNサーバー」や「TURNサーバー」というものが必要になります。
詳しい説明は割愛しますが、『セキュリティやプライバシーを保ったまま、直接通信を実現するために必要なサーバ』と思ってください。

本来それらを導入するのはとても手間が掛かるのですが、各クラウドベンダーが使いやすい形で提供してくれているため、そちらをご紹介します。

AWS：Kinesis Video Streams

『Kinesis Video Streams』は、ビデオ通話やライブ配信を簡単に実現するためのサービスです。
先ほど出した「STUNサーバー」や「TURNサーバー」としての役割はもちろん、スケーラブルなインフラとして使えるため、急に通信量が多くなっても問題なく対応できます。
またSDKで簡単に実装できるため、複雑な専門知識がなくとも利用が可能です。

Azure：Azure Communication Services

『Azure Communication Services』は、Microsoftが提供しているマルチチャネルコンピューター APIです。
音声通話はもちろん、ビデオ通話・チャット・テキストメッセージ・SMS等、多岐にわたるコミュニケーションを実現できます。
なおこのサービスにはMicrosoft Teamsの技術が使われているため、品質は十分でしょう。

なお、こちらもSDKが用意されているので導入は用意です。また従量課金制なので無駄なコストを払う必要もありません。

Google Cloudは専用のサービスがない…

AWS、Azureとくれば、次はGCPと言いたいところですが、GCPには前述したようなサービスがありません。
理由は諸説ありますが、GoogleはそもそもWebRTCそのものの利便性を追求しており、プラットフォームに依存しない実装を推奨している……という説もあります。
（実際、webrtc.orgはGoogle for Developers上で管理されています）

Twilio、Vonage、Agora、Daily.coなどのPaaSベンダーもあり

なお大手クラウドサーバ以外にも、PaaSとしてこれらの通話サービスを展開している企業があります。
AWSやAzureを使うと、ベンダーロックイン等が気になるところですが、こちらであれば自由な環境で、手軽に導入ができるためより手軽です。（どのサービスでも、おおむねSDKやAPIが提供されています）

ただし、利用状況によってはAWSやAzureよりも高額となるケースが有るため、予めどの程度の利用が見込まれるか調査を行いましょう。

オープンソースも存在するが……

『他社にお金を払うのではなく、自分で全てを賄いたい』という方には、オープンソースで全てを揃えることも可能ではあります。
WebRTCに必要な『シグナリングサーバ・STUNサーバ・TURNサーバ・ICEサーバ』各種に、オープンソースのプロジェクトが存在するので、これらを組み合わせ、構築し、自身で管理するのです。もし実現できれば、毎月の利用量を節約できます。

……ですが、実際のところこれらを使うのは至難の業です。
まずWebRTCの複雑な仕組みを理解した上で、各プログラムを適切に設定する必要があります。
またサーバのセットアップやメンテナンスも自分で行わなければなりません。一度設定したら終わり、ではなくセキュリティパッチも定期的に当て続ける必要があります。
更に利用者が増えた際には、それに耐えられるようインフラを整えなければなりませんし、減ったら減ったでまたスケールダウンが必要です。
もしサービスがダウンして停止した場合、運営側が直さなければなりません。365日、24時間対応する必要があります。
もしオープンソースの開発が止まり、整合性が取れなくなった際は、新たなサービスを見つけるか自前で作成する必要もあるでしょう。

……とてもではないですが、割が合いません。
一応オープンソースのプロジェクトを紹介しておきますが、基本的には前述のクラウドサービスかPaaSを強くおすすめします。

シグナリングサーバー：Socket.io、PeerJS、Signalmaster
STUNサーバ：Coturn、stund
TURNサーバ：Coturn
ICEサーバ：Pion ICE、JSEP (JavaScript Session Establishment Protocol)

そもそも通話機能が必要か熟考を

ここまでマッチングサービスに付随させる通話機能について、システム的な面からご紹介しました。

しかしながら、まず考えていただきたい点としては『通話機能の実装が必要か？』という点です。
最初に話した通り、大手のマッチングサービスでも通話機能・会議機能をつけているサービスは多くありません。
それは実装の難易度・コストに比べて、プラットフォーム側の旨味がほとんどないからです。

先ほど書いた通り、通話機能は実装そのものが簡単では有りません。ほとんどの人はZoomやGoogle Meet等の使い慣れたサービスを使いたがるため、オープンソースのプロジェクトはもちろん、導入に関するナレッジ（知識）も、それほど世に出ていなかったりします。

AzureやPaaS等のサービスを使えば、実装は比較的容易になりますが、それでもUI周りの設計等でコストは掛かりますし、毎月のサービス利用量もそれなりの規模になります。
そのような多額の費用を掛けて、プラットフォーム側は何を得るのでしょうか……？
取引仲介型のマッチングサービスであれば、『外部コンタクトを取らせない』という一応のメリットはあるかもしれませんが、それも微々たる効果であり、とてもコストに見合った効果はでないでしょう。
（なお、やり取りを録音してデータ収集に役立てる……という案もあるかもしれませんが、WebRTCの会話は仕組み上録音が出来ません）

なので今一度『マッチングサービスに通話機能は必要か？』という点を熟考していただき、コストに見合った設計を考えていただければと思います。

マッチングサービスを運営するには？

『マッチングサービス』は、今大変需要が高まり、急成長している分野です。
ただし、その運営は決して簡単ではありません。

1. マッチングアプリの仕組み

基本的に、マッチングアプリは以下のような流れで動作します。

ユーザーが登録・プロフィール作成
興味のある相手を探す（スワイプ機能、検索機能）
マッチング（お互いが「いいね」した場合）
チャット・コミュニケーション
オフラインでの出会い

2. 開発に必要な技術スタック

マッチングアプリを開発するには、以下の技術が必要です。

技術	用途
React Native / Flutter	モバイルアプリのフロントエンド開発
Next.js / React	Web版のフロントエンド開発
Node.js / Express / Django	バックエンドAPI

3. ユーザー認証とセキュリティ

マッチングアプリでは、ユーザーの安全を確保することが重要です。そのため、以下の認証方法を組み合わせるのが一般的です。

メールアドレス & パスワード認証
Google / Apple / Facebook OAuth 認証
電話番号認証（SMS認証）

「セキュリティが甘いマッチングアプリは、すぐに信用を失ってしまう。」 — 開発者B

4. スワイプ機能の実装

多くのマッチングアプリでは、スワイプ機能が採用されています。以下は、React Native でスワイプ機能を実装するサンプルコードです。

import { View, Text, Animated, PanResponder } from "react-native";
const SwipeCard = () => {
  const position = new Animated.ValueXY();
  const panResponder = PanResponder.create({
    onMoveShouldSetPanResponder: () => true,
    onPanResponderMove: Animated.event([null, { dx: position.x, dy: position.y }], { useNativeDriver: false }),
    onPanResponderRelease: () => {
      Animated.spring(position, {
        toValue: { x: 0, y: 0 },
        useNativeDriver: false,
      }).start();
    }
  });
  return (
    <Animated.View style={[{ transform: position.getTranslateTransform() }]} {...panResponder.panHandlers}>
      <Text>👩‍💻 マッチング候補</Text>
    </Animated.View>
  );
};
export default SwipeCard;