Tabelog Tech Blog

食べログの開発者による技術ブログです

AIを使わずに見積もり5人月のサービスを0.5人月でリリースした話。〜プロセスの見直しで開発の劇的短縮〜

はじめに

こんにちは。ウェブ開発1部 メディアマネジメントチームの齊藤です。
メディアマネジメントチームでは、他社とのシステム連携や広告系の業務を中心に扱っています。

今回は、AI活用により様々な業務が高速化しつつある最近だからこそ、人間主体で出来る作業の高速化をおざなりにしない意識の大切さを、事例ベースで改めて確認していきたいと思います。

今回受けた相談

今回相談を受けた要件は以下のようなものでした。

  • 閲覧中のレストラン詳細ページのエリアや料理ジャンルに合致したレストラン情報をページ内の広告で表示したい(いわゆるコンテンツマッチ配信やレコメンド配信)
  • 表示される店舗の評点を常に最新の状態にしたい

また、社内の別サービスでは、広告サーバーの使用と合わせて独自実装のAjaxでコンテンツ情報をリアルタイムで取得している先行事例がありました。

まずは見積もり

ひとまず先行事例と同様の形で作ることを想定し、大まかに見積もりをしたのが以下になります。

  • 設計 1.5人月
    • 要件定義
    • データ・アーキテクチャ設計
    • 既存システム調査・影響分析
    • セキュリティ設計
  • 実装 2人月
    • バックエンド開発
    • フロントエンド開発
    • 単体テストコードの作成
  • テスト 1.5人月
    • 結合テスト
    • 総合テスト
    • セキュリティテスト
    • 受け入れテスト

ざっくりとした項目ではありますが、合計でだいたい5人月です。

特に今回は食べログのレストラン詳細ページトップのようなユーザーアクセスの多い部分に表示する想定のため、トラフィックへの影響の調査と対応を慎重にやる必要がありました。
また、広告配信プラットフォームから情報取得用のWebAPIを呼ぶ関係上、食べログの外部からアクセス可能なWebAPIが必要となるため、セキュリティ関連で事前に考慮しなければならないことも多いです。

このままでは大体5人月と相当な工数がかかると判断したため、別の方法がないか模索することにしました。

プロセスの見直しで別の道を探す

要望を満たす代替案を探すため、まずは広告の配信に係るプロセス全体の把握から始めました。
というのも、食べログでは広告配信は複数のチームが関わる横断的な業務であり、お互いの作業内容を完全に把握できていなかったからです。
これまでエンジニアは、食べログ側での配信の設定と準備という限られた部分にしか関わっていなかったため代替案を探すにはまず全貌を知ることから始める必要があったのです。

関係チームへのヒアリングで作業の全体の流れを整理すると以下のようになっていました。

  1. 受注 (広告事業部)
  2. バナー作成 (プロダクトデザインチーム)
  3. 広告配信プラットフォームの配信設定 (広告企画チーム)
  4. 食べログ側の配信設定 (メディアマネジメントチーム)
  5. 配信

プロセスを整理し作業の内容まである程度把握した結果、WebAPIを作るとコストが重いという問題の解決の糸口があるとすれば、エンジニアの作業の前段にあたる「広告プラットフォームの配信設定」ではないかと考え、広告プラットフォームでできることをさらに調査することにしました。
その結果、使用している広告プラットフォームには、JSON形式で店舗データをあらかじめ登録しておくと動的にバナーを生成できる機能があると判明しました。

この機能は大量のデータ作成が必要なため今までの運用では活用されていませんでしたが、広告配信プラットフォームが提供する登録用のWebAPIを活用してエンジニアがデータを一括作成できれば、今回の要望を満たせるという結論になりました。
要望にあった情報の鮮度の問題に関しては、食べログの評点は月に2回の決まったタイミングで更新されるため、評点更新日にWebAPI経由でデータを更新することで常に最新のデータが表示されます。

この方法であれば広告配信プラットフォームの機能のみで表示を完結させることができ、高トラフィックへの考慮やセキュリティ対策のような非機能要件はプラットフォームに任せることで考慮する必要がほとんどなくなります。 これにより、作業を機能要件への対応に絞ることができ、工数を大幅に削減できる見込みが立ちました。

上記の方法での見積もりが以下になります。

  • 実装 5人日
    • 要件定義
    • 新しい業務フローの策定
    • WebAPIによる食べログ店舗情報登録スクリプト作成
  • テスト 5人日
    • 総合テスト
    • 受け入れテスト

合わせて2週間の為、大体0.5人月となります。なんと初期の見積もりの1/10になりました。

広告配信プラットフォーム提供のWebAPIを使用して食べログの持っている店舗情報をjson形式にして登録するスクリプトの作成のみの作業です。 内製開発をせず広告配信プラットフォーム上で完結させることで、作業は要件定義、業務フローの策定、そして総合テストのみにまで減らせるため、開発コストの削減が見込めると判断し、この方法で対応することに決定しました。

実際にやってみた

計画に沿って実装を進めていたところ、思わぬ壁にぶつかりました。広告配信プラットフォームの公式ドキュメントには記載されていなかった「バナー登録数の上限」という隠れた制限によって、WebAPIによる一括登録が想定通りに動作しなかったのです。

内製開発と違いブラックボックスのため自力での原因究明は困難と判断し、すぐサポート窓口に相談しました。
幸いにもサポートから迅速な回答を得られ、バナー登録数上限の仕様について知ることができ、地域ごとに分割して別の広告バナーとするといった回避策を検討し、期限に影響を及ぼすことなく実装を完了させることができました。

この経験から、外部のサービスを活用する上では、サポート体制の手厚さはスピード感を損なわないためには非常に重要なポイントだと実感しました。
もしもサポート窓口がなかったりレスポンスが遅かった場合。問題の原因を探し解消するために時間を取られていたことでしょう。

プロセスの見直しで削減できたもの/得たもの

今回、全体のプロセスを見直した結果、多くのものを得ることができました。

まず、レストランデータを連携するためのWebAPI開発が不要になりました。
もしWebAPIを開発していた場合、広告表示のたびにWebAPIの通信が発生し、表示遅延によるCTR低下のリスクや、継続的な運用コストが発生していたでしょう。
今回は広告プラットフォームにあらかじめデータを渡しておく方式にしたことで、余計な通信がなくなり、表示の仕組みをシンプルにできました。
また、すでに使用しているSaaSの活用であるため追加の利用料も発生していません。 上記開発が不要になったことで、2週間強で案件を完了させることができ、0.5人月という見積もりは妥当なものでした。

さらに副次的な効果として、業務プロセスの整理を通じて各チームの役割分担がより明確になりました。
今回データ登録用WebAPIを使用するために、エンジニアが新たに広告配信プラットフォームを直接操作する必要が発生しました。
しかし事前にプロセスを整理していたおかげで、必要最小限の権限を持つアカウントを用意でき、作業の単純化と事故の予防に繋がることができました。 リリース後の運用フェーズにおいてもこの仕組みは安定稼働しており、少ないエンジニアの工数で多くのリピート依頼を頂ける人気広告商材となりました。

得た学び

今回の案件を通して、いくつかの重要な学びがあったので振り返ります。

全体を理解することの重要性

効率的な業務のためには、与えられた要件をそのまま実装するのではなく一度立ち止まって他のアプローチがないか考えることはやはり大事です。
そのためにも、関連する業務プロセス全体を把握しておくこと、または把握しようとすることが大切になります。 特に、サービスは大きくなるほど分業が進み知らない領域が増えがちですが、自分の担当領域だけに固執せず常に全体を俯瞰する視点を持つことを大切にするべきです。

介入プロセスの局所化

特にSaaSのような外部サービスを最大限に活用するには、SaaSではカバーできない部分を特定のプロセスへ局所化させることが有効です。
信頼できるサービスに任せる範囲を最大化することで考慮する必要があることを大きく減らすことができると同時に、保守性も上がるためメリットが多いです。
今回の事例だと、食べログ側でWebAPIを用意することはせず表示を広告配信プラットフォームに全て任せたことが該当します。

事前のデータ量の想定

特に大規模なデータを扱う際は、データ量がSaaSの想定の範囲内に収まるかを事前に確認し、懸念点があれば早めにサポートへ相談等の対応をしておくことでよりスムーズに開発できます。
今回はサポートの対応が早かったため問題なかったですが、早めに手を打っておくことで、そうでなかった場合にも大きな遅れにならないようにできるはずです。

おわりに

今回の案件では、業務プロセス全体を見直しSaaSの機能を活かすことで、AIに頼らずとも開発工数を5人月から0.5人月へと大幅に削減することに成功しました。
エンジニアの作業を広告配信プラットフォームへのデータ投入という一点に変更し、それ以外のプロセスは既存のフローを維持できたため、案件相談からわずか2週間程度でのスピードリリースが実現しました。

また、内製にこだわらずSaaSを活用するというアプローチは、特にコモディティ化しやすい領域で大きな効果を発揮すると実感しました。
食べログでは、お店探しや口コミ、ネット予約といったコアな機能から遠い領域については、自社で一から開発するよりも、確立された外部サービスや技術を組み合わせる方がより高い価値を迅速に生み出せると判断しています。
無駄な開発を減らし、競争優位性が高く戦略的に重要な開発にリソースを集中させることで、これからもユーザーにより価値のあるサービスを届け続けていきたいと考えています。

最後になりますが、食べログでは一緒に働ける仲間を募集しております! 興味のある方は是非下記の採用ページをご覧ください!