この記事は 食べログアドベントカレンダー2024 の4日目の記事です🎅🎄
はじめに
初めまして。食べログ開発本部アプリ開発部オーダーチーム、新卒1年目の伊藤です。
私は現在、バックエンドエンジニアとして食べログオーダーの開発に携わっています。
8月に現場配属されてから、いくつかのリリースを経験させていただきましたが、4月入社時点ではバックエンドの開発経験はほとんどありませんでした。
学生時代に研究関連でXAMPPを少し触ったことがある程度です。
そんな私が短期間で実務に馴染むことができたのは、生成AIを活用した学習・実務支援がありました。
この記事では、OJT初期に生成AIを活用した事例やそこで得た学びを紹介します。
食べログで導入されているAIツール
まずは食べログで導入されている生成AIについて簡単に説明します。
GitHub Copilot
2023年5月から食べログではコーディングを支援するGitHub Copilotが導入されています。
主な機能として、「コード補完」と「チャット」が挙げられます。
- コード補完：コードを書き始めると、編集中のファイルや関連するファイルから推測してコードを補完してくれる機能
- チャット：コードの生成やデバッグの方法を質問できる機能（既存のコードを選択しつつ、質問することも可能）
メソッドやクラスの中身をすべて補完するのは難しい印象ですが、使用する変数やメソッドを素早く入力する際によく活用しています。
2024年10月の時点で、食べログエンジニアの72.2%がGitHub Copilotを活用しています。
食べログ全体で生成AIの利用を推進しており、詳細については本Tech Blogに記事がありますので、気になる方は是非読んでみてください。
PR-Agent
GitHubのPull Request(以下PR)レビューの場面では、コードレビュー負荷軽減と品質向上を目的にPR-AgentというAIレビューツールが導入されています。
食べログでは、各プロダクトチームごとに利用するツールや設定が多少異なりますが、オーダーチームを例に取ると、以下のような機能が活用されています。
- PRの説明に必要な要素(タイトル、タイプ、概要、変更内容、ラベルなど)を自動で生成
- 調整可能なフィードバック(PRに含まれる問題点やセキュリティの懸念、レビューにかかる推定労力など)を提示
- PRの品質向上に役立つ具体的な修正案を提示
- 自由形式の質問への対応
個人的には、PRの概要と変更内容を自動生成する機能はPRの概要を書く手間を減らせるうえに、意図しない実装が含まれていないかをレビュー依頼前に最終チェックできるため、使い勝手が良いと感じています。 また、チームのメンバーは同じPRで複数のレビューがある場合に、前回の差分を除いた変更内容を生成し、レビュアーに変更点を分かりやすく伝える方法を取っていました。
Dify
Dify(読み方：ディファイ)はエンジニアリソースを必要とせず、視覚的に生成AIをチューニングできるOSSプラットフォームです。
ChatGPTのようなチャットボットとしての利用に限らず、業務で使うドキュメントデータやGoogle検索などの各種ツールと連携したAIアプリケーションの開発など、業務に合わせた生成AIの活用が可能です。
食べログでは2024年の8月から全開発者向けに公開されており、Dify上で目標設定/OKRや開発支援、文章校正などといった多種多様なチャットボットが構築・活用されています。
OJT初期のAI活用事例
ここからは、OJT初期におけるAI活用の具体例を2点紹介します。
単体テストの作成
私が配属後に担当した主なタスクは、既存APIの拡張やリファクタリングでした。
バックエンド開発の経験が浅い私にとって、コードの品質を担保することにどうしても課題がありました。
そこで、単体テストの作成時にDifyのチャットボットを壁打ち相手として活用を始めました。
まずは自分で実装コードから条件網羅的にケースを割り出し、それらのケースに漏れがないか、より精査すべき箇所がないかをチャットボットと共に検証しました。
例えば、食べログオーダーに登録するテーブル名に対して複数の追加バリデーションを実装した際、作成・修正する単体テストケースに漏れがないか念入りに確認できました。
ここでバグが発生すると、来店から会計までの一連の処理がすべて通らなくなるため、テストを通じてサービスの品質を保てて良かったです。
単体テストの品質向上に加えて、作成時間の短縮にもつながったため、実装箇所の変更がシステム上で正しく動作しているか、伝票系のタスクなら伝票の文言が間違いなくプリンターから正常に出力されているかといった、結合テスト手前のような作業に力を注ぐことができました。
その結果、リリース後に手戻りで作業することなく、サービスの品質を維持・向上できたと思います。
また、複数のタスクを積み重ねていくうちに、ユーザーの操作体験を意識してテストケースを考えるようになりました。 カカクコムがサービスづくりにおいて大切にしている「ユーザー本位」を言葉だけでなく、実際の感覚として理解できるようになったと感じています。
サーバーの負荷状況のモニタリング
インフラサイドへの興味を持っていたことをきっかけに、ユニットリーダーと相談し、食べログオーダーのサーバー負荷状況をモニタリングする取り組みを始めることになりました。
食べログオーダーでは、New RelicやGrafana、Google CloudのCloud Loggingを用いて、CPU使用率やPumaワーカーの余力数など、システムの特定の活動を数値化したデータやログを可視化・収集しています。
これらツールのダッシュボードをもとに、毎週サービスの負荷状況をチームメンバーへ共有することになりました。
そのように始まったサーバーの負荷状況のモニタリングですが、初めはKubernetesやクラウド・サーバー知識が不足していたため、ダッシュボードのグラフが何を示しているか理解できない状態でした。
そこで、Difyのチャットボットに搭載されている画像認識機能を活用し、ダッシュボードに表示されるグラフを画像として取り込み、自分がグラフから読み取った内容に大きな誤解がないかをチェックするサポート役として使用しました。
特に、データのスパイク箇所がサービスに影響を与える異常値であるかについては、重点的に確認することにしました。
こうして徐々に負荷状況を把握し、異常が発生した際には迅速に報告できました。
例えば、非同期サーバーのConnectionの最大数が更新されたとき、その原因になっていそうなCronを取り上げてユニットリーダーなどに報告し、対応を依頼できました。
こうした報告を重ねるうちに、素早さに加えて、可能であれば原因を明確にして報告することで、チームメンバーがより迅速に対策を講じられることを学びました。
負荷状況のモニタリングの報告以外でも、背景を伝えることを意識するようになり、コミュニケーションが円滑になった感覚があります。
チャットでのコミュニケーションが多い都合上、以前は簡潔にまとめようとするあまり、言葉足らずになっていたのではないかと今では思います。
また、モニタリングを続ける過程で、今週オーダーサービスにどのようなことが起きていたかを、Teamsのチャットを通じて積極的に追うようになりました。
発生した事例がサーバーの状況変化に繋がるからです。
執筆をしている今では、離れた情報を俯瞰して関連付けて見るというマクロ的な視点を持つことの重要性を強く感じています。
最後に
上記の経験を通して、生成AIを活用することで不慣れな知識の範囲を確認・補足でき、エンジニアとしての質を高められました。
その結果、微力ながらもリリースに携わるようになり、素早くチームにジョインできたのかと思います。
引き続き新しい技術を取り入れ・学び続け、ユーザーにとってより良いサービスを意識して開発に励んでいきたいと考えています。
生成AIを活用したツールは今後ますます普及し、OJTのようなオンボーディングの場面でも活用される機会が増えていくと考えられます。 これからOJTを実施するエンジニアのメンターの方々にとって、今回紹介した事例がOJTに生成AIを導入する際の参考になれば嬉しいです。
明日は @uromy の「スマホアプリエンジニアからバックエンドエンジニアへ領域横断して得たもの」です。お楽しみに!
