https://tech-blog.tabelog.com/entry/tabelog-reservation-system-external-integration

こんにちは！
食べログカンパニー飲食店プロダクト開発部の稲葉・南野です！
我々は食べログの予約システムと、外部システムとの連携に関する開発・運用をする業務を担当しています。
今回は外部システム連携に携わってきた二人の視点から、「食べログの予約システムにおける外部システム間連携」についてご紹介します！

はじめに

「食べログの予約システム」と聞くと皆さんどのようなものを想像するでしょうか？
普段食べログを利用してくださっている方は、飲食店を探したり、希望の日時をネット上から予約したりするシーンが思い浮かぶかと思います。
その一方、予約を受け付ける飲食店側の視点から見ると、予約情報の管理や在庫管理、顧客管理のように裏側で動いている仕組みも存在します。
今回は、特に飲食店側から見た視点や、利用体験をよりスムーズで便利にするために行っている外部システムとの連携についてご紹介します。

食べログの予約システムにおける外部連携

「外部システム間連携（外部連携）」とは主に異なるシステム間で情報を共有し、相互に連携させることを指します。
主に以下のような連携方式を通じて、シームレスなデータ管理が実現できます。

API連携：REST APIやGraphQLを利用して、システム間でリアルタイムにデータをやり取りする方式。
例）予約システムとGoogleカレンダーをAPIで連携し、予約情報を自動登録する。
Webhook：予約の作成・更新時にリアルタイム通知を送信し、外部システムと連携をする方式。
例）予約変更時に決済システムへWebhook通知を送り、自動で料金を更新する。
データベース連携：直接データベースを参照・更新する方式。
例）予約システムとPOSシステムが同じデータベースを共有し、リアルタイムに空き状況を反映する。
ファイル連携：CSVやXMLなどのファイルを定期的にバッチ処理で同期する方式。
例）予約データを毎晩CSVファイルでエクスポートし、外部の分析ツールに取り込む。

なぜ食べログの予約システムで外部連携をするのか？

外部連携をすると食べログの予約システムを利用して下さっている飲食店側、食べログ双方に以下のようなメリットが生まれます！

飲食店側のメリット

複数の予約サイトからの予約を利用する飲食店の場合、予約変更やキャンセル情報がリアルタイムで同期され、予約管理を統一できる。
予約管理を統一することにより、ダブルブッキングのリスクを無くせる。
キャンセル料請求を自動化してくれるなど予約に付随する業務のサポートを受けることができる。

食べログの予約システム側のメリット

飲食店側の利便性をアップさせることで「食べログ、いいじゃん！」と思ってくださる飲食店が増え、利用店舗の増加に繋がる。

食べログで実現している外部連携について

ではここで、食べログの予約システムが外部連携している主な連携先の紹介です。外部連携サービス図で示す通り、食べログではさまざまなサービスと外部連携を行なっています。

外部連携の開発における苦労・注意ポイント

外部連携をすることで利便性が向上する一方、実際に食べログの予約システムに外部接続を実装する場合にはさまざまな課題や調整が必要になります。
外部連携における開発の苦労や注意すべきポイントについて、「調整」「開発」「運用」の3つの観点から紹介します。

調整編

外部連携の開発は、食べログ内部で完結するわけではないので、外部システムのエンジニアと様々な調整事項のすり合わせが必須になります。
ここを不明瞭なまま開発フェーズに進んでしまうと、開発そのものが進まなかったり、品質の低いシステムになってしまうリスクが高まります。
開発フェーズに入る前の調整で気をつけるべきポイントを詳しく解説していきます。

相互の業務の理解が必要

外部システム連携先の企業の業務フローが理解できていないと、認識齟齬による不具合が発生する可能性があり、適切な連携ができません。
単に繋ぎ込み部分のI/F仕様を理解するだけではなく、連携先での業務全体を把握することが重要なポイントのひとつです。

ユビキタス言語の策定が必要

外部連携の開発を円滑に進める前段階として、共通のユビキタス言語を策定することも重要です。
企業によって、業務フローやデータ構造に関する用語がバラバラだったり、別の意味を持つこともあるため、双方が同じ理解を持てるようにすることが求められます。

開発文化の違い

グローバル企業との連携では、開発文化が異なるケースもあります。たとえば⋯

ドキュメントのフォーマットやプロジェクト管理手法が異なる
コミュニケーションスタイルに違いがある
開発スピードやプロダクトの質など、開発フローにおいて重要視する観点が異なる。

そのため、事前の認識合わせを丁寧に行い、共通の開発ルールを確立することが大切です。

コミュニケーションコスト

外部企業との連携では、物理的な距離や文化の違いからコミュニケーションが取りにくい場合もあります。
開発時、仕様変更や障害発生時には迅速な情報共有が求められるため、定期的なミーティングやドキュメント整備を通じて認識のズレを最小限に抑える工夫も必要です。

開発編

外部連携における開発フェーズでは、技術的な課題も多く発生します。
このポイントを適切に考慮しないと、データの不整合が発生したり、障害時の復旧が不可能になってしまったり⋯と利便性を上げるために実施する外部連携が逆に利便性を下げ、利用してくださる飲食店ユーザーからの信頼を失ってしまう結果になる恐れもあります。
開発フェーズで気をつけるべきポイントを詳しく解説していきます。

データ構造の違い

企業によってデータの持ち方が異なる場合が往々にしてあります。
既に開発、運用されている他社のシステムを連携させると、当然ながらデータ構造が完全には一致しないことがほとんどです。
実際に開発した際に直面したケースとして次のようなものがありました。

予約と休みを別のオブジェクトで管理する企業もあれば、一括で管理する企業もあった。
- 課題：異なるデータ管理方法がある場合、特定の運用方法を前提としたロジックが、他の運用方法では誤作動を起こす可能性がある。
  これにより、過剰なデータ生成や不整合が生じることがある。
IDの形式などが異なるデータ構造の変換処理を噛ませる必要があった。
- 課題：IDの形式や長さがデータベースの制限に合わない場合、既存の設計を変更する必要が生じる。

そのため、どこまで自社で異なるデータ構造を吸収するかを慎重に検討する必要があります。（ここがエンジニアとしての腕の見せどころでもあります！）

疎通可能な開発環境の整備

外部連携の開発では、異なるシステム間を接続する必要があるため、開発時にお互いが疎通可能な環境を整備しなければなりません。
初期の環境構築時には、接続確認に複雑な設定が必要となる場合が多く、スムーズに進まないことがよくあります。
また、追加開発や運用時の動作確認を行うためには、常に疎通可能な開発環境を維持し、テストが実施できる状態を保つ必要があります。
そのため、本番環境だけでなく開発環境の継続的なメンテナンスも欠かせません。

データの持ち方の責任

異なるシステム間でデータ連携をする際には、単にデータベースを同期するのではなく、業務フロー全体を同期することが重要です。
その際に注意する点として、どのシステムの業務プロセスが基準となるのかを明確にする必要があります。
業務フローの同期が不十分だと、データの一貫性が崩れるだけでなく、業務全体に支障をきたす可能性があるため、責任の所在（データの整合性や業務プロセスの管理責任）を明確にし、統一された業務フローを設計することが求められます。

依存関係

外部システムとの連携では、遅延や障害の影響を最小限に抑えるため外部システムとの依存関係を最小限に抑える必要があります。
依存関係が強いシステム間連携としてしまうと、連携先の処理が完了するまで一連のフローがいつまでも完了しない⋯待った上でエラーになった⋯などのような不便や機会損失に繋がってしまいます。
そのため、依存関係を最小限にするため非同期処理を利用して、外部システムの応答を待たずに自社の処理を完了させるように設計しています。
食べログの予約システムで採用している非同期のデータ連携は、バッチ処理（一定間隔で送信）と Kafka（リアルタイム処理）を使い分けています。

セキュリティ観点（認証・認可やAPIレートリミット）

API連携では、認証・認可の方式（OAuth、APIキーなど）APIのリクエスト制限（レートリミット）など、セキュリティ面での考慮が不可欠です。
認証・認可を適切に設計しないと、不正アクセスや情報漏洩の原因となり、重大な問題となる可能性があります。
また、APIのレートリミットが適切でない場合には悪意のある攻撃者による大量のリクエストを許容してしまい、場合によってはサービスが停止してしまうリスクにも繋がります。
さらに、食べログでは通信の暗号化（HTTPS）を徹底し、第三者機関による脆弱性診断を定期的に実施しています。
これにより、潜在的なセキュリティリスクを事前に発見し、迅速に対応する仕組みを整えています。

エラーハンドリング（ログの粒度、エラーメッセージなど）

外部システムとの連携時には、適切なエラーハンドリングが重要です。
ログの粒度を適切に設定し、障害発生時に迅速に対応できるようにする必要があります。
ログへ出力するエラーメッセージの粒度が適切でないと、どちらのシステムで何が原因でトラブルとなっているかの切り分けが行えなくなり、解消までに時間がかかってしまいます。
また、利用者向けのエラーメッセージも同様に適切な設計をすることで利便性のアップに繋がります。

リトライ機構

外部連携では、性質上どうしても一時的なネットワーク障害やシステムエラーが起因となり正しく処理が行えないトラブルが発生することがあります。
そのため、再試行（リトライ）の仕組みを組み込むことで、処理が失敗した場合でも自動で復旧できるよう対策を講じることも大切です。
ただし、データ操作に関わる処理の場合など単純に全てをリトライしてはいけない場合もあるため、適切なリトライ制御を設計する必要があります。

フェールセーフな作りになっているか

システム障害が発生しても、後続の処理に影響を与えない仕組みを構築することが重要です。
以下の観点を注意して開発する必要があります。

エラー発生後の処理フローの考慮
冪等性（同じリクエストを複数回送信しても結果が変わらない設計）
結果整合性の確保

シーケンスの合意

APIを通じてI/Fを提供する際には、その使用方法について事前に合意を得ることが重要です。
想定外の使われ方を防ぐためには、APIのシーケンスや利用方法を明確に文書化し、利用者に共有することで事前の合意形成をするべきです。
また、APIが想定外の使われ方をされた場合でも、適切にエラーハンドリングを行い、問題を迅速に発見・解決できるようにしておくことが重要です。

運用編

システム開発の段階を乗り越え、いよいよ運用フェーズに入ると、新たな課題が見えてきます。
特に外部システムとの連携をする場合、単なるシステムの安定稼働だけではなく、継続的なメンテナンスやスムーズな対応が求められます。
運用フェーズで気をつけるべきポイントを詳しく解説していきます。

スケーラビリティについて

システムが順調に運用されると、APIリクエスト数やデータの流量は増加していきます。
この増加に対し、サーバーが適切にスケールできるかどうかが、システムの安定性を左右します。

APIリクエストの増加に耐えられる設計になっているか？
負荷分散の仕組み（ロードバランサー、CDNなど）を導入しているか？
一時的なトラフィック急増（キャンペーンや予約開始時など）に対応可能か？

などといった観点から、事前に想定される負荷をシミュレーションし、適切なスケーラビリティ設計をすることが重要です。

問い合わせに対する対応

運用フェーズに入ると、利用者である飲食店や連携企業からの問い合わせが発生します。
特に、システム障害が発生した際には、連携先のシステムにも影響が及ぶため、迅速な対応が求められます。
障害発生時には外部連携先にも影響が出てしまうため、問い合わせ対応がスムーズに行えるよう、適切なFAQやドキュメントの整備が必要です。

システムメンテナンス時の影響を最小限に

システムは常に安定稼働するわけではなく、定期的なメンテナンスが必要です。
特に、外部システムと連携している場合、自社のメンテナンスだけでなく、外部連携先のメンテナンスにも影響を受ける可能性があります。
外部連携先のメンテナンスに対する対応のポイントとしては以下が挙げられます。

影響範囲の事前確認：相手側のシステムが停止した場合、自社システムのどの機能に影響が出るのかを把握。
スケジュールの共有：定期メンテナンスの予定を事前に共有し、影響を最小限に抑える。
フェールセーフの仕組み：メンテナンス中でも最低限の機能が動作するように設計する。

予約システムのようにステークホルダーの体験に直結するサービスでは、メンテナンスによる影響を最小限に抑える工夫が求められます。

まとめ

食べログの予約システムは外部連携により、飲食店の予約管理を統一し、業務効率化やダブルブッキングの防止を実現しています。
一方で、開発・運用をトラブルなく実現するためには業務理解の徹底や責任範囲の明確化を意識することが重要です。
外部システムとの連携に関する開発をする際にはデータ構造の違いやセキュリティ対策、エラーハンドリング・リトライ機構を意識した設計が求められます。
また、開発して終わりではなく、運用フェーズではスケーラビリティの調整や問い合わせ・メンテナンス管理も不可欠です。
今後もさらに快適で便利な予約システムを目指し、外部システムとの連携を通じてよりスムーズで安心して使える仕組みを提供できるよう、開発・運用に取り組んでいきます！

最後に、食べログでは新たな仲間を募集しています！今回の記事を通じて「食べログの技術」に魅力を感じていただけた方は、ぜひ以下の採用ページをご覧ください。
あなたのスキルを活かし、一緒により良いサービスを作り上げていきましょう！