ID:65268さん

## ✅ Facebook広告APIの調査、データ取得、FastAPIでのアプリ開発を担当 ### ■規模感、チーム構成、担当した役割 3人チーム（バックエンド２名、フロントエンド1名）のバックエンドエンジニアを担当。 ### 担当した役割 ・Facebook広告API、EcforceAPIの調査 ・上記APIのデータ取得バッチ処理の設計、実装 ・テーブル設計、 API設計、実装 ・FastAPIでのマイクロサービスバックエンドの開発を担当 ・エラー通知の設計、実装 ### ■使用技術や開発環境等 ・OpenAPiを用いたスキーマ駆動開発体制。 ・構成 アーキテクチャパターン：Backends For Frontends バックエンド：FastAPI、Python フロントエンド：React、TypeScript インフラ：Cloud Run DB：Cloud SQL(MySQL)、Cloud storage ・使用技術一覧 Python、FastAPI、Google Cloud Platform(Cloud Run,、Cloud Build、 Cloud Functions、Cloud PubSub、Cloud SQL、Cloud storage、Cloud Loggingm、Cloud Monitoring、VertexAI)、Terraform --- ✅ FastAPI、CloudRunを用いたAPIサーバーの構築 ■成果・目標 社内で新たに、データビジュアライゼーションアプリケーションを作成することとなり、FastAPI、CloudRunを用いたAPIサーバーの構築の設計から実装までを担当した。 ■具体的な取り組み - APIの調査、要件に合わせた数値項目の設定、FastAPIのスキーマ設計、CloudSQLのテーブル設計 - Facebook広告APIからCloud Scheduler、Cloud PubSub、Cloud Functionsを用い、日次定時バッチ処理の実行。 - Cloud SchedulerからCloud PubSub経由でCloud Functionsを定時実行 - 毎日定時にFacebookAPIから取得したjson形式の生データをそのままCloud Storageに保存し、一部をRDBの形式に成形し、Cloud SQLへINSERT - FastAPIのAPIサーバーの開発 - FastAPIでCloud SQLからのデータ取得、スキーマに合わせたデータ成型 - VertexAIを用いた過去分のデータを手動で一気に取得 ■苦労、工夫 - FacebookAPIからいかに効率的にデータを取得できるかを工夫した。FacebookAPIのレート制限とCloudFunctionsのメモリや実行時間の制限から、FacebookAPIのドキュメントを調査し、エンドポイントを調整することで制限をクリアした。 - FacebookAPIのドキュメントからは読み取れない情報もあるため、社内の広告チームへのヒアリングと実際のAPIへのリクエストによる検証を行い、目的としているデータの取得を実現した。 ■成果 （最終的にプロジェクトをどのようなかたちで終えたのか） - 一旦の社内リリースを終え、社内の定例MTで使用予定。今後、追加開発も予定している。

## ✅ インスタグラム分析ツールの開発 ### ■規模感、チーム構成、担当した役割 4人チーム（バックエンド3名、フロントエンド1名）のバックエンドエンジニアを担当。 ### 担当した役割 ■開発 ・バックエンド新規機能の開発、保守改修(Flask) ・バッチ処理の実装 ・バグ改修 ・CSチームからの質問対応 ・Bigquery、データポータルを用いたレポート作成 ■開発以外の業務 - Bigquery、スプレッドシート、データポータルを用いた社外向けレポートデータの出力 - 手動タスクのドキュメント化 - プラン更新関連のドキュメント化 - MT時の議事録 ### ■使用技術や開発環境等 アーキテクチャパターン：MVC バックエンド：Flask、Python フロントエンド：JavaScript インフラ：Google App Engine DB：Bigquery、Cloud storage 使用技術： Python、Flask、Google Cloud Platform(Google App Engine,Bigquery, Cloud Build, Cloud Functions, Cloud PubSub, Cloud SQL, Cloud storage, Cloud Logging, Cloud Monitoring), Terraform --- ### ✅ GCPのモニタリング、エラー検知の導入 ■成果・目標 従来、Cloud Functionsで発生するエラーについては、エラー発生時にslack通知させる仕組みを使用していたが、メモリ超過とタイムアウトについては例外処理で検知されないため、気づくことができない問題があった。 ■具体的な実装 - Cloud Openration Suite（Cloud Monitoring, Cloud Logging）を用いて、メモリ超過とタイムアウトが発生次第、slack通知させる仕組みを構築した。 - 新しいプロダクトにおいては、上記をコードで管理するため、terraformでコード管理を実装した。 ■苦労、工夫 - 上記分野において、社内で知見のある人がいなかったため、独力で公式ドキュメントの調査、書籍での学習、他社のtechblogの参照、テスト環境での検証を行い、実装した。 ■成果 - 社内のメモリ超過、タイムアウトを検知する仕組みの構築、及びそれに伴うCloud Functionsに適切なメモリ、実行時間の割当が可能となった。 ## ✅障害、他部署から問合せ対応 ■取り組み - アプリケーションの仕様理解、チームの生産性向上を目的にバグ改修・他部署からの問合せは基本的に自分が巻き取り、対応した。 ■意識している点 - プロダクト・InstagramAPIへの理解が深まり、その後業務の生産性向上にも寄与した。 ## ✅他部署と連携した分析レポートの作成 ■背景、課題 - マーケティングチームが作成するインスタグラムのレポート作成に工数がかかり、顧客対応に時間が避けないことが課題となっていた。 - これまでスプレッドシート上で計算を行い、1つずつ確認していく作業に時間がかかっていた。 ■具体的取り組み - Bigqueryとデータポータルを用いたレポート作成の自動化を行った。 JupyterNotebookを活用し、Bigqueryのテーブルデータを成形し、スプレッドシートに出力、スプレッドシートからデータポータルに数値データを出力させた。 ■結果 - それまで数十分~数時間かけていた作業が数分で完了できるようになった。