目次
はじめに
こんにちは！ 食べログ開発本部飲食店システム開発部でマネージャーをしている新井です。 2018年に食べログに入社し現在は販売管理チームに所属しており、飲食店向けの契約や請求などを管理するバックオフィス系システムを開発しています。
皆さんが想像している食べログエンジニアのお仕事としてはレストラン情報、口コミ、予約といった一般ユーザーに向けたサービスの開発エンジニアかと思いますが、 実はその裏側の食べログ運営のバックオフィス各種業務においても社内で包括して取り組んでいます。
今回はその社内システムの一部をSaaSに切り替えるプロジェクトについてお話ししたいと思います。
1章 課題の認識とZuora導入の決断まで
販売管理システムの課題
今回お話をするバックオフィスシステムは販売管理システムと呼ばれているものとなります。
食べログでは飲食店向けにさまざま機能を提供する商品を有料販売しているのですが、その情報を管理するシステムが販売管理システムとなります。
私達エンジニアはその社内システムを内製で管理していましたが、多数の業務が絡むことで度重なる改修が加わることにより、システムがとても複雑になってしまっていました。
このままでは新たな取り組みをするにもどんどんシステムが複雑化し開発効率が悪くなっていってしまうため、システムの根幹から見直す必要性が出てきました。
何を最初にやるべきか
システムの複雑さを解消し開発効率をあげたい、障害の起きにくいわかりやすいシステムにしたいなど、達成したいゴールは明確ではあるものの、 ここまで大規模で複雑化されたシステムを根本から変えるためにはどう進めれば良いのか、進め方を考えることも難しい問題でした。
そのため、まずは基本的な2つの軸で考えることにしました。
実情を知る
属人化した業務も含め、まずは全部テーブルの上に並べることにしました。 ただし、ステークホルダーも多かったり、契約処理においては時系列の流れも重要なためなかなか情報が集まらない状態でした。 とはいえ、1つでも考慮すべき業務が欠落すると契約処理が回らなくなり、お店にご迷惑おかけしてしまうため、ここは慎重に進める必要があります。
そこで、エンジニアがソースコードから仕様を洗い出し企画側に積極的に提供することで、正常系のみでなく異常系も含めた細かいケースを出し、ひとつひとつ見える化していくような進め方をしていきました。
理想像を固める
どうなっていれば業務改善＋理想のデータモデルとなるのかを検討しました。 とはいえ、業務の実情がわからないとなかなか前に進まない状態なので、実情を知るのを優先し、それが固まったら理想像を固めるという流れで地道に進めました。
何を作り、何を作らないか
業務も見えてシステムの理想像がわかってきたあとは、このシステムを一から作るべきなのかを議論しました。 販売管理システムを内製した頃と異なり、売上規模は飛躍的に伸び、業務もより複雑となったことにより、内製で全て作るにはかなりのコストがかかります。 また、SaaSシステムの提供するデータモデルやシステムのフレームワークに乗っかることで、一般的で会計監査観点での「正しい」システム作りが実現できます。 そのため、食べログではシステムを一から作らずSaaSを導入することにしました。
どのSaaSを使うか
SaaS選定においては食べログでの業務プロセスにフィットしそうなものをいくつかピックアップした後、Zuora*1を採用することになりました。
※あくまで2018年当時の話なので、現在は異なる可能性があります。
Zuoraとはサブスクリプションデータモデルを得意としており、販売、契約管理、請求計算・発行、クレジットカード決済連携、入金・回収管理、売上計上、会計締め処理、分析・レポートまでの業務が自動化できるSaaSアプリケーションです。 ZuoraはCRMの代表格であるSalesforceと連携・共存できることも魅力の1つです。
もともと食べログとしてもCRMツールとしてSalesforceを使っているため、見積、契約管理、請求機能を拡張・強化できる機能を有しているZuoraは食べログの求める要件にマッチしていました。 また、コロナ禍といった未曾有の状況時にはフレキシブルに休会ができるようなデータモデルにする必要もあり、サブスクリプション型のデータモデルが最適だったため、Zuoraを導入するという決断に至りました。
2章 Zuora導入設計
さて、このZuoraを導入するためにどこから変えたらよいものかを考える必要がありますが、Zuoraに完全に合わせたデータモデルにするためには現業務を大幅に見つめ直す必要がありました。 この章ではZuoraを導入するにあたり、どのようにシステムを設計していったかを話そうと思います。
Zuoraプロジェクトチーム体制
プロジェクトが動き出したら、まずはチーム作りから行いました。
ステークホルダ選定としては大きく以下のグループに分かれて進めました。
- PO（プロジェクトの決定権を持つ事業部長、システム部部長）
- PM（プロジェクト推進者。要件定義や業務構築、ステークホルダ調整を担う）
- PMO（PM補佐）
- エンジニア（要件定義、設計、開発、運用）
- 販売管理、財務部等の業務担当者（約10部門）
関わるエンジニアの人数も通常のプロジェクトに比べるとかなりの人数となりましたが、 それ以上に販売管理の業務の根幹に関わる改修となったため、さまざまな部署の方を巻き込んだ一大プロジェクトとなりました。
Zuoraを知ろう！
まず、エンジニアもZuoraで何をどうするのかのイメージができないと、食べログシステムとZuoraのデータ責務を検討できません。 そのためZuoraに向き合う時間を多く取り、Zuoraのデータモデル、API、システム仕様やサービスレベル、セキュリティ観点などを詳細まで調べました。
サンドボックス環境(Zuoraの開発環境)で砂遊びしつつ、Zuora社のコンサルタントや有識者と話をし、エンジニアも徐々にZuoraを理解していきました。
それにより、ZuoraAPIを使う上で、レスポンススピードを鑑み一括大量更新を避けるような仕組みが必要であるなど、Zuoraを利用する上での制約も判明していきました。
Zuoraプロジェクトにおいて何を開発するのか
Zuoraの管理画面を使うか、それとも内製で作るか
Zuoraもそうですが、一般的なSaaSシステムは管理画面が用意されておりこの管理画面にてデータ登録・更新・削除からSaaS独自の機能を使うことができます。 食べログでもZuoraの管理画面を使うか、内製で契約・取引先の管理画面を作り、Zuoraと繋ぐかを検討しました。
結果、食べログでは業務設計を含めてフレキシブルに対応していきたかったこともあり、内製で食べログ業務が遂行できるように管理画面を作成することにしました。
ただ、全てを完全に新しく作成するのは工数が莫大になり現実的でなかったことから、必要最小限の機能を新設し、その他は既存の管理画面をそのまま利用することで開発工数を下げることをしました。
新設機能のモック作成
Zuoraプロジェクトの新設機能の中の重要な機能の1つに、データ生成する機能、つまりZuoraに投入するための契約・取引先データの入口となる登録画面がありました。 これは販売管理業務の核であり、新設することでドラスティックな業務変更が発生することになるため、現場との連携は重要でした。
少しでも認識齟齬が発生すると手戻りが痛いことになります。 そのため、Zuoraと現行業務を理解したエンジニアが率先してモックを作ることで要件を固めていくことを行い、現場と認識の齟齬が起きないように注意深く開発を進めていきました。
食べログとのマッピング
食べログのデータモデルとZuoraのデータモデルは似ているようで全然違うため、ここはかなり設計に労力をかけたところとなります。
エンジニア的に説明すると、レコードの単位としては
- Zuoraの契約データの粒度＝「契約」の単位
- 食べログ＝「掲載月ごとの契約」という単位
です。
ちなみにZuora側のデータモデルは変えられません。
正確には、SaaSシステムとして提供する財務会計機能を利用するため、データモデルが確立されており、変えるべきではないというものです。
単位が違うデータモデル同士を帳尻合わせする方法としては、以下2案でした。
- 食べログ側でZuoraのデータを掲載月毎の契約に変換して既存モデルで対応する
- 食べログ上の契約データ利用機能を全てZuoraのデータモデルとなるように業務フロー含めて作り替える
当初は案2で進めていましたが、業務側のドラスティックな変更は既存の業務やお店に対しても影響が大きく、 運用にも支障が出てしまうことから、早々に案1の方針でZuoraのデータを食べログのシステムがそのまま利用可能なように食べログ側で変換して進める方針となりました。
最終ゴールとしてはもちろん案2の業務も含めた改革なのですが、食べログとしては徐々に変更していくことを選択しました。
3章 Zuora移行
Zuoraで開発するものを決め開発を少しずつ進めていきましたが、プロジェクトを進めるうちにさまざまな課題に直面しました。 ここではその中でSaaSに乗り換えるにあたり必ず直面する課題となる、データ移行、データ切り替えについて、その課題への食べログとしての解決方法について話をしたいと思います。
データ移行
ここでデータ移行といっても「少しの間止めてdumpして投入すればいいんじゃない？？」というものではありません。
簡単にまとめると
- データモデルが変わる場合のデータ移行はシンプルにInsert・Updateするという考え方ではない
- データ移行が1円の差分もなく正しく行われているか、あらゆるデータ検証が必要
- Zuoraへのデータ投入はAPIを介して投入する必要があるため、一括で大量データの投入はできない
といった考慮が必要になります。
もし、APIを介して順次送り込むことにすると、その場合データ投入はざっと10日間かかることが判明しました。 つまり、データ移行期間を設けるというやり方では、10日間はできるだけ業務を止めてもらい、契約系データはフリーズしておく必要があるということです。
また、Zuora側に投入されているデータと財務データとの整合性を取る必要があり、 10日間の業務停止期間で整合性チェックをする予定だったのですが、 不整合が発覚した際の切り戻しなどのことを考慮すると、データ移行期間を設けるというやり方はリリース判定する側としては厳しいものでした。
そのため、食べログでは最終的にはデータ移行期間を設けるというやりかたではなく、Zuoraと既存システムを並行稼働させるという方法を取ることとしました。
当たり前といえばそうなのですが、並行稼働はエンジニアだけでなく運営や企画側にもかなりのコストがかかります。 それでも、障害がおきたらサービスが止まってしまう危険性のあるリリースを安全に進めることができたことから、 Zuoraプロジェクトにおいて並行稼働を行うという選択を取ったことは良い判断だったと思っています。
データ検証
並行稼働を行い、稼働中の本番データとZuora上のデータの整合性の検証をできるようにしようと考えましたが、そこでも大きな問題が発生しました。 それは、ZuoraのデータにAPIを用いて大量にアクセスする場合、データの取得や更新に時間がかかりすぎてしまうというものでした。 また、Zuora側で気軽にデータ削除ができる環境ではないため、検証する上でも様々な障壁がありました。
そのためZuoraに直接送り込まず、食べログシステム内だけである程度検証し、Zuoraのデータと稼働中の本番データの整合性が取れる方法を考えねばなりませんでした。
そこで、それまでは契約関連データはZuoraのみに保持させ食べログでは保持する予定がなかったのですが、 契約関連のテーブル構成をほぼZuora同等の構成で食べログで作ってプーリングし、プーリングしたデータをZuoraに送り込むというワンクッション置いた流れとしました。
つまり、契約関連データに変更が発生したときはZuoraに直接データを送るのではなく、 食べログ内部に保持するデータプールを作る処理とデータプールの差分をZuoraに送る処理を分割し、それぞれの責務で完遂させる仕組みとしました。
結果、稼働している本番データとZuoraのデータの整合性が合うまで、気軽に検証することができるようになりました。
突合バッチによる検証
整合性を検証するためには以下のような突合バッチをデイリーで走らせ、不整合を検知したものを都度修正かけていくようにしました。
- データプールと稼働している本番データの突合
- データプールとZuora上のデータの突合
毎日何らかの検知や本番データとの齟齬が発生していましたが、本番稼働までは時間もあったため安心して修正に取り掛かることができました。 こうして、本番並行稼働期間である程度の見通しがついたため、業務検証に回すことができました。
データプールの副産物
このデータプールは必ずZuoraと整合性が合うレベルのデータであったため、データ移行だけでなくもっと幅広く活用できることがわかりました。 例えば、参照系APIの処理としてはZuoraから直接データを取得することなく、食べログシステム内に存在しているデータプールを参照するようにすることで、パフォーマンス観点でも速度を改善できました。 また、Zuoraの通信状況を気にせず処理ができるようになったことで、バッチなどの運用もしやすくなりました。
最終的なシステム構成
最終的にはZuora移行において、システムは以下のような構成となりました。
管理画面でデータを更新したらZuoraにデータを更新させるだけを想定していた初期とは違い、システムが大きくなってしまいましたが、
データの突合や検証などを気軽に行うことができ、かなり安定したシステムを構築することができました。
データ切り替え
食べログでは上記の通りZuoraと現システムを並行稼働させるという選択を取ったため、データ切り替えはデータの向き先を変えるだけで行えるようにしました。
具体的には、Zuoraリリース前まではv1として現システムのデータを参照し、Zuoraリリース後はv2としてデータプールを参照するようにしました。 その際、切り替えを漏れなく行えるように、切り替えの必要な参照箇所を全てAPIに置き換え、Zuoraリリース時には大量のコードをリリースするのではなく、APIの向き先を変更するだけでデータの参照先を切り替えることができるようにしました。 また、APIの参照先はAPIごとに参照先情報をもち、それを切り替えることで向き先を変更できるようにしました。
これにより、事前に直接データを参照しているところがないことを確認することでデータ切り替え漏れを防いだり、 リリース時に参照先の向き先を変更するだけの対応で済むことで、安全にリリースを行うことが可能となりました。
4章 Zuora運用
開発が完了したらついにリリースです。
リリースするにあたり対応したことは以下の通りです。
財務突合
財務突合に関しては業務側が主体的に財務データとの突合を進めていきました。 この財務突合はなかなか差分のない状態にするのに苦労しましたが、粘り強く突合を繰り返すことで、長い期間をかけついに1円も差分のない状況をつくることができ、Zuoraへの切り替えステップに進みました。
Zuoraへの切り替え
システム開発は完了し、業務調整やトレーニングも進み、ステークホルダとの調整も整い、ついにZuoraへの切り替えです。
切り替え作業は業務が発生しない土日に行い、週明けから新環境のZuoraを利用することにしました。 事前の移行手順に従い、エンジニア側最大の切り替えイベントである500ファイル程のデプロイになります。 固唾をのんで見守りましたが、大きな障害発生なくスムーズに切り替え完了できました！
これもこの記事で説明した様々な作戦が功を奏した結果でした。
Zuoraでの運用開始
業務切り替え後、流石にリリース規模が大きかったため細かなバグは発生しましたが、大きな混乱はなく運用を開始できました。
そして、Zuoraに切り替えることによって商品追加やキャンペーンへの対応工数が減り、営業チャンスを逃すことなくスピーディーに事業展開ができるようになるなど、業務側のメリットもありました。
5章 結論
Zuoraという大規模なSaaSの導入を行いましたが、さまざまな対策を行うことで大きな障害が起きることなくリリースできました。
今回のプロジェクトを振り返り、大規模なシステムを扱う上で私が実践すると良いと考えるポイントは以下の2つです。
- 開発を始める前に可能な限り時間をかけ、現状の業務やシステムを正しく把握し、何をどのように作るべきかを決める。
- 安全にリリースを行うために、段階的にリリースする計画を立てる。
大規模なシステムの改修の場合は、この2つのことをいつも以上に考えることが重要だと実感しました。 特に、データプールを作り事前にデータを移行したり、APIの向き先を切り替えるだけでリリース時に参照するデータを変更するように計画を立てたことは、今回のプロジェクトにおいてとても大きな功績だったと感じています。
Zuoraを導入することにより、今まで内製で作っていた機能をSaaSに置き換えることができ、販売管理システムのバグ件数は大きく減らすことができました。 Zuoraリリース後、約1年ほど運用をしていますが、何か新しいことをやりたいとなった際にZuoraが提供している機能においてはすぐに運用を開始できZuoraを入れたメリットを享受できています。
しかし、今回はまずはZuoraを導入しデータモデルを徐々にサブスクリプション型に切り替えていっただけとなります。 そのため、業務側は大きくまだ変えられておらず、それゆえにZuoraの機能を全て使い切れていない状態です。 次なる戦略へ向かってまずは第一歩を踏み出したばかりのため、引き続き販売管理システムの改善は続けていかなくてはなりません。
最後に
プロジェクトを振り返って、自身の経験の中でも最も大規模なプロジェクトであり、 ステークホルダーも多く、開発する際にさまざまな立場の人とコミュニケーションをとりプロジェクトを前に進めていったことは、とても良い経験となりました。 さらに、最終的には大規模な障害を起こすことなくプロジェクトを完遂できたため、自分への自信ともなりました。
とはいえ、プロジェクトを通して全て開発がうまく進んだかというとそうではなく、 業務や仕様の洗い出しが甘く、途中で大きな問題が発覚し軌道修正が発生してしまったりと、 規模の割にリリースまで時間がかかってしまったのも事実です。 そのため、次回同じ様なプロジェクトに参画する際は、 わからないからとりあえずプロジェクトを前に進めようとするのではなく、 仕様や業務の洗い出しなど動き出しの基礎となるところにより時間をかけ、 最初の行動をより的確にやるべきだなと感じました。
この記事では食べログのバックエンドのシステム開発の一端をお話ししました。
食べログでは一緒に働いてくれる仲間を募集しております。
興味を持っていただけたら是非採用ページをご覧ください。
