食べログノートでスキーマドリブン開発をやってみた

この記事は食べログアドベントカレンダー2022 の11日目の記事です🎄✨☃🎅☃✨🎄

こんにちは！食べログでフロントエンドエンジニアをしている辻です。以前は食べログフロントエンジニアブログで記事を書いていましたがお引越ししてきました！
フロントエンドだけではない食べログ全体のブログになったということで、サーバーサイド、アプリも含めた開発フローについて書きます☺️

食べログノートとは

これは食べログノートのアイコン画像です。

2022年春、食べログネット予約をご利用の店鋪さま向けの予約管理台帳「食べログノート」をリリースしました！🎉

店舗さま向けの紹介：食べログノートとは

こちらのプロダクトではGrahphQLを導入し、スキーマドリブンでの開発を進めています。食べログノート開発における、スキーマドリブンを用いてサーバーとクライアントを跨いだ標準化と、それを半年ほど運用した振り返りを紹介します。

システム的な実現方法についてはフロントエンジニアブログで紹介されておりますのでそちらをご参照ください。

スキーマドリブンとは

「スキーマドリブン開発」、または「スキーマ駆動開発」と呼ばれる開発手法は、複数のシステム間のインターフェース（スキーマ）を定義し、スキーマを元にそれぞれのシステムの実装を進める手法です。

食べログノートの構成

食べログノートではPC/iPad用のWeb(Next.js)、iOSアプリ、Androidアプリが共通のGraphQLから情報を取得しています。更に、GraphQLからRuby on RailsのAPIを呼び出しています。

要件定義後、フロントエンドエンジニア、iOSエンジニア、Androidエンジニア、サーバーサイドエンジニアが集まってスキーマを設計します。

食べログノートの開発フロー

要件定義と優先順位付け

解決したい課題から企画、エンジニア、デザイナーみんなで要件定義を行ないます。優先順位や着手順を決めるため、要件定義時にざっくりの見積もりも行ないます。

既存の修正の場合、その場でGraphQLスキーマを確認し、修正範囲や規模感のすり合わせを行ないます。

設計

要件が決まるとサーバーサイド、アプリ、フロントエンドで設計に入ります。
ある程度方針が見えてきたところでGraphQLのスキーマ設計に着手します。

食べログノートではGraphQLはクライアントサイドとサーバーサイド両方の持ち物という位置づけになっており、スキーマは関係する全てのエンジニアが修正可能な共通言語となっています。

その時ちょうど余裕があった人、修正の影響を大きく受ける部分を担当してる人、その機能まわりに詳しい人など要件に応じて誰かがスキーマ修正のプルリクエストを出します。フロントエンド、サーバーサイド、iOSアプリ、Androidアプリの各エンジニア１人以上にapproveを貰えばマージできます。

また、規模が大きい追加/修正の場合はミーティングで関係するエンジニアが集まって設計を行ないます。

実装

インターフェースが確定しているため、サーバサイド、アプリ、フロントエンドはそれぞれ同時に実装着手が可能です。ちなみにクライアント側ではスキーマから型をジェネレートしています。

モックを用いた単体テスト

スキーマからモックも作成できるため、APIや画面の完成を待たずにテスト可能です。この段階で通信まわり以外の細かい挙動やロジックを重点的に確認します。

結合テスト

モック無しで全てのシステムを動かしてテストします。こちらでは通信まわりを重点的に、「予約の登録ができる」などのストーリーに沿って確認を行ないます。

リリース

WEBとアプリで共通のAPIを使っているため、既存スキーマの修正は古いバージョンのアプリや画面が壊れないように注意が必要です。事前にリリース順の調整や後方互換を考慮した設計にするなど工夫しています。

やってみて良かったこと

APIの完成を待たずに実装やテストが進められるのがスキーマドリブンの大きなメリットですが、それ以外にも効果がありました。

誰でも設計を始められる

以前はAPIの大まかな実装方針が決まるのを待つなど、あるタイミングで、特定のエンジニアでないとインターフェース設計が始められませんでした。スキーマドリブンでかつ、フロントエンドエンジニア、アプリエンジニア、サーバーサイドエンジニア誰でもスキーマ修正のプルリクを出せるので、誰でも設計着手が可能になりました。

手戻りが減った

以前もスキーマドリブンでなくとも実装前にインターフェースのすり合わせは行っていましたが、抜け漏れや認識違いも多く手戻りが多く発生していました。スキーマ設計のレビュー時に認識齟齬が解消されるため、実装着手以降の手戻りが減りました。

共通言語となった

規模が大きいとシステム全体に精通したエンジニアは少なく、サーバー側の細かい仕様変更がどこまでクライアント側に影響を与えるかの認識合わせに苦労していました。スキーマを共通言語とすることで、得意分野の違うエンジニア同士でも影響範囲や修正規模を容易に共有できるようになりました。

システム境界が明確になった

以前はAPIのレスポンスがどのような形か確定しないため、サーバサイドの修正でクライアントサイドで思わぬ影響を受けることがありました。また、それを防ぐためにサーバーサイドとクライアントサイド両方のエンジニアが修正の詳細を確認する必要がありました。スキーマ定義があることで、APIを修正してもスキーマに影響しなければ他に影響は与えないことが明確になり、サーバーサイドやクライアントサイドそれぞれの開発に集中できるようになりました。

改善の余地がある部分

nullや空配列などデータがない時の扱いの認識ずれ

スキーマ定義してもまだ認識がブレる部分があります。例えば、予約情報の領収書名の値がnullだった場合は「名前は現地で伝える」という意味でしょうか？それとも「領収書は不要」という意味でしょうか？値がない時の意味合いは積極的にコメントを書くなど工夫が必要そうです。

スキーマ設計が後から変わる

基本は最初に決めたスキーマに合わせますが、やってみるとどうしてもそうはいかない場合もあります。食べログノートにおいては、予約情報が確定するタイミングや予約情報の修正が可能な期間などを考慮する必要があり、値が取得できないパターンが存在します。実装時に気づくとスキーマ変更となり実装が進んでいると手戻りになります。スキーマレビューの観点整理に加えて、どのタイミングでスキーマ設計をすると精度を高められるのか検討しています。

まとめ

食べログノートの開発において、スキーマドリブン開発を導入し、以前と比べてコミュニケーションコストが削減され、手戻りが減りました。また、スキーマが共通言語となることでサーバーサイド、クライアントサイドを跨いだ影響範囲やその規模の認識合わせが容易になりました。まだたまに手戻りが発生してしまうこともあるため、改善をすすめていきます。