5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

フィナジーと駆け抜けた技術的挑戦の軌跡

Last updated at Posted at 2025-12-20

はじめに

@Adacchi3 は2019年の新卒で株式会社エイチームフィナジーに配属され、主に保険代理店事業部に関するシステムを担当してきました。

サイトの立ち上げから、吸収分割・事業承継といったビジネスの大きな転換点まで、約6年間におよぶ開発・運用の現場を駆け抜けてきました。今回は、その中で私たちが取り組んできた4つの主要な技術的挑戦に焦点を当て、当時の記事を引用しつつ振り返りたいと思います。

Cloud Run でのサービス運用

2019年の設立当初、インフラ構成はAWSが中心でしたが、チーム内に深いインフラ知見を持つメンバーが少なく、VPCやECSの構築・運用に対する不安がありました。

容易にサービスを公開したい、インフラについてあまり管理せずに開発者がアプリケーション開発に集中できるようにしたい、コストを削減したい、という方針のもと、新規事業のサービスにて Google Cloud の Cloud Run を採用しました。

Cloud Run は、サーバーレスのコンテナ化されたマイクロサービスをデプロイしてスケールするためのフルマネージドコンピューティング環境です1。自動的にスケールアップ・スケールダウンを実施してくれるため、急なトラフィックの増加に伴うサーバー数を増やすオペレーションがなくなりました。

本格的に運用を始めた2020年では、Cloud Run に最小インスタンス数設定がなかったため、安定的にサービスを提供するために一時期は Google Kubernetes Engine で運用していた時期もありましたが、徐々に Cloud Run にも最小インスタンス数等の機能追加が行われ、安定して運用できるまでに至りました。

DB マイグレーションや rake タスクといったコマンド実行についても当初は試行錯誤していましたが、Cloud Run ジョブの登場によって改善されました。

約6年間、Cloud Run にて運用していました。当初は悩む部分もありましたが機能追加や更新によって、より安定的・わかりやすく運用することができたのではと考えております。

Cloudflare でのエッジコンピューティング

Cloud Run の前段に Cloudflare を使っていました。2020年の導入当時は CDN や WAF としての役割を期待していましたが、次第に Cloudflare Workerを活用したエッジでのロジック実装へと活用の幅が広がりました。

AB テストの運用やページキャッシュ、apple touch iconの作成等に Wragler を用いて Cloudflare Worker のアプリケーションを構築しました。また、静的ページを AWS S3 から Cloudflare R2 に移管したり、認証周りを自身のアプリケーションで実装するのではなく、ZeroTrust を用いて対応したりしました。

インフラを触り始めるようになった当時は、Google Cloud だけでなく、Cloudflare も触れるとは思いもせず、把握に時間を要した記憶があります。しかし、メンバーと一緒に新しい情報をキャッチアップしながら、試してみることができたことは非常に良い経験だったと思います。

また、イベントでのライトニングトークにもCloudflareをテーマに参加させていただきました。当時のCTOからお声がけいただき、緊張しながらも登壇させていただきました。

Serverless Framework による ETL 基盤の開発

事業成長に伴い、多様なフォーマットのデータ分析が必要となりました。当初は人手によって整形しながら運用しており、ExcelやSpreadsheetに登録しているデータ数が多く、処理しきれずにフリーズしてしまうといったことを耳にしました。

事業に必要なデータを分析できる状態にしようと、毎年いくつかのプロジェクトが進行しており、そういった中で ETL(Extract/Transform/Load)の考え方を意識してアプリケーションを開発していました。

  • Extract(抽出): 特定フォーマットの Excel が S3 にアップロードされると、それをトリガーに Lambda が起動。シートから必要なデータを抽出し、中間ファイルとして別バケットへ保存

  • Transform(変換): 中間ファイルの生成をトリガーに、別の Lambda が起動。分析に適した形式へデータ変換・保存

  • Load(ロード): 最終成果物のアップロード、またはスケジュール実行をトリガーに、データウェアハウスへデータをロード

1つのAWS Lambdaのハンドラーがシンプルになり、読みやすく、エラーが発生した際にはそれぞれの成果物を確認して問題を切り分けるといったことができ、データフローとしては運用に乗れていたと感じております。

Serverless Framework自体も便利なプラグインがあり、Serverless Prune Plugin や Serverless Offline, serverless-s3-localなどのプラグインを導入し、ローカルでの開発環境を整えていました。

Salesforce の開発・運用

お客さまの情報を管理するにあたって、顧客管理システムを構築することを検討していました。いくつかの要望・要件を整理し、Salesforceの導入に至りました。私たちはいわゆるWebエンジニアであり、Salesforce の開発や運用はゼロから覚えていきました。

導入初期は、ビジネスサイドのユースケースを汲み取りきれず、苦労した時期もありました。私はSalesforceが導入されてから約1年半後のタイミングで開発・運用に参加させていただきました。リードやアカウントといった単語が何を意味しているかも理解していない状態からスタートしたことを今でも覚えております。

Salesforceを約3年間学んだタイミングで、ロック解除済みパッケージを用いた業務システムの開発に従事することとなりました。ある程度慣れ親しんだタイミングであったからこそ、ロック解除済みパッケージで開発することに踏み切ることができたり、スクラッチ組織での開発環境構築、CI/CDでのデプロイ等ができたのだと感じております。

おわりに

2019年から2025年にかけての歩みを振り返ると、常に「変化する事業課題」に対して「最適な技術」をぶつけていく挑戦の連続でした。

新卒でこの環境に飛び込み、Cloud Run、Cloudflare、Serverless Framework、Salesforceといった多岐にわたる技術スタックに触れさせていただけたことに深く感謝しています。この6年間の経験を糧に、これからも技術の研鑽を積み、より良い価値を創造していきたいと思います。

  1. https://cloud.google.com/blog/ja/topics/developers-practitioners/cloud-run-story-serverless-containers

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?