経験1年のエンジニアでも、新規プロダクトのEmbedded SREに初挑戦できた理由 — 仕組みと個人の学習で踏み出す
はじめに こんにちは、ファインディ株式会社でエンジニアをしている中嶋（@nakayama__bird）です。現在は、新規プロダクトであるFindy Contextの開発に携わっています。 ファインディでは、これまでSREチームが担っていた新規プロダクトのクラウド環境の構築から監視体制の整備までを、プロダクト開発チーム主体で行う体制に切り替えました。 本記事では、私自身がFindy Contextの環境立ち上げを担当した経験を、アプリケーションエンジニアの視点で振り返ります。 経験の浅いエンジニアにとって、0→1のクラウド環境構築は不安の大きい領域です。「自分にできるのか」と思いながら着手した私が前に進めたのは、「SREチームが整えてくれた仕組み」と「自分で進めた学習」、その2つが揃っていたからでした。 それぞれがどう機能したかを、これから体験ベースでお伝えします。 はじめに Findy Contextとは 背景: なぜ開発チーム主体に切り替わったのか これまでの体制 直近の事情の変化 方針転換: 開発チームメインの立ち上げへ 着手前の筆者スペック 委譲のスコープと私が担当した範囲 AWSアカウント発行とインフラ構築基盤整備 インフラリソースの構築 デプロイと運用の整備 監視（Datadog）の整備 個人として取り組んだこと 今後の伸び代 自分側 仕組み側（汎用モジュール・テンプレートへの改善余地） まとめ Findy Contextとは Findy Contextは、ファインディが2026年4月にリリースしたAI駆動開発支援プロダクトです。 プロダクト開発で日々生まれる文脈（過去のPR、関連議論、意思決定の経緯）をAIが資産化し、開発の調整コストを削減することを目指しています。 Findy Contextが目指すのは、特定の個人に依存せず、少人数でも高い開発能力を維持できる組織運営です。 あちこちに散らばっていた判断のプロセスを蓄積していくことで、組織の経験を資産として再活用できる土台を作っていきます。 findy.co.jp このFindy Contextの本番運用基盤を、なぜSREチームではなく開発チームが主体で構築することになったのか。その背景から振り返ります。 背景: なぜ開発チーム主体に切り替わったのか これまでの体制 ファインディにはSREチームが存在し、共通インフラやプラットフォームの運用、汎用モジュール・テンプレートの整備、セキュリティ・コスト最適化など、全社横断の取り組みを担っています。 インフラはTerraformでコード管理されており、SREチームが提供する汎用モジュールやテンプレートもTerraformで書かれています。オブザーバビリティの基盤としてはDatadogを採用しています。 また、既存プロダクトでは、プロダクトの一部メンバーがEmbedded SREとして、次のような役割を担っています。 アプリケーション開発に必要なインフラの整備・管理 モニタリングの整備 SLOの振り返り 一方、新規プロダクトの立ち上げに関しては運用が異なっていました。 SREチームが環境を構築し、ある程度の運用準備を整えてからプロダクト開発チームに引き渡す形が基本でした。 直近の事情の変化 ここ1〜2年で、事業成長や生成AIの追い風もあり新規プロダクトの立ち上げ件数が大きく増えたことで、これまでの体制で支えられる範囲を超えつつありました。 一方で、SREチームの人員を急に増やすことは難しく、既存プロダクトの運用や全社横断の取り組みも並行して走り続けています。新規プロダクトすべての環境構築をSREチームが担う体制は、現実的に維持できなくなりつつありました。 方針転換: 開発チームメインの立ち上げへ そこで、新規プロダクトの立ち上げ〜運用フェーズを、プロダクト開発チームが主体となり、SREチームがイネーブリングを担う体制へと切り替わりました。 これは、「開発側にオーナーシップを置く」というEmbedded SREの発想を、新規プロダクトの立ち上げフェーズにも広げた形と言えます。 SREチームが整備した汎用モジュール・テンプレート・イネーブリング体制を活用して、開発チームが自分たちの責任で立ち上げる。Findy Contextの立ち上げは、この新方針の第一弾として位置付けられたプロジェクトでした。 着手前の筆者スペック 未経験からファインディに入社し、当時は経験1年のエンジニアでした。業務の中でAWSの一部サービスを使うことはあっても、新規プロダクトの基盤として複数のサービスを組み合わせて構築した経験はありませんでした。0→1のクラウド環境構築は今回が初めてです。 そんな中、Findy ContextのEmbedded SREとして配置されることになりました。 開発チーム主体で環境構築を進める新方針のもと、その構築をメインの担当者として進めてほしいと依頼されました。 着手当初はそもそも「何から手をつければいいのか」が分からない状態でした。設計の手順も、優先順位も、判断基準が自分の中にありませんでした。 委譲のスコープと私が担当した範囲 まず、SREチームと開発チームの担当範囲を整理しておきます。 領域 SREチームが担当 開発チームが担当 AWSアカウント Organizations管理 アカウントの発行、発行後の初期設定 インフラリソース（ネットワーク・アプリケーション基盤） 共通方針、汎用モジュール・TerraformのCI/CDテンプレートの整備 汎用モジュールを使ったリソース構築（足りないものは個別作成）、CI/CD設定 監視（Datadog） Datadogの管理 ダッシュボード・モニター作成、運用 開発チームが引き受けた範囲は、SREチームが整備してくれた仕組みを使って自分たちで構築する、という形でした。 今回のFindy Contextの環境構築は、約2ヶ月をかけて、主にSREチームが事前に分解してくれた作業を順に消化する流れで進めました。ここからは、その流れを4つのフェーズに分けて振り返ります。 AWSアカウント発行とインフラ構築基盤整備 最初のフェーズは、Findy Context用のAWSアカウントを作り、Terraformで管理する基盤を整える作業でした。次のようなタスクです。 新規AWSアカウントの作成 HCP TerraformへのProject作成 Terraform用のGitHub Actionsワークフロー作成 ファインディには、SREチームが整備した初期セットアップ用のテンプレートがあり、Terraform用リポジトリの初期化はこのテンプレートで一気に進められました。 CI/CD・Docker・Trivy・TFLintなど、新規プロダクトに必要な基盤が一式揃った状態でスタートできます。 それでも詰まったのは、GitHub ActionsからAWSへのOIDC認証の設定でした。 Identity ProviderやIAM Roleの信頼ポリシーといった、IAM周りのポリシー理解が必要になります。IAMポリシーの仕組みをこれまで触る機会がなく、何をどう書けば期待通りの認証が通るのかが最初は全く分かりませんでした。 乗り越え方は、既存プロダクトのTerraformリポジトリを参考に、動いている設定を「型」として読み解くことでした。 特に初期は、SREチームの方と毎日ペアで作業する時間を持ち、レクチャーを受けたり質問を重ねたりしながら、自分の中に手順のイメージを作っていきました。 インフラリソースの構築 ここからが、Findy Contextのインフラを実際に組み立てるフェーズです。約1ヶ月かけて、次のようなリソースを順に構築していきました。 ドメイン / DNS Zone / 証明書（ACM） ネットワーク（VPC・サブネット等） コンテナ関連（ECSなど） データベース関連（RDSなど） 認証（Cognito） 配信（CloudFront） ここで強く助けられたのが、SREチームが整備した汎用モジュールです。汎用モジュールの整備については、別の記事で詳しく紹介されています。 tech.findy.co.jp ネットワーク・コンテナ・データベースなど、アプリケーション開発で標準的に必要なリソースは汎用モジュールが用意されており、変数を指定するだけで適切な構成が組み上がります。 「ベストプラクティスを毎回ゼロから調べる」必要がない状態でスタートできることは、学習コストを大きく下げる効果がありました。 それでも詰まったポイントが2つありました。 1つ目は、汎用モジュールにないリソースの作り込みやレビューです。Findy Contextでは、まだ汎用モジュール化されていないリソースを複数扱う必要がありました。 作成だけでなくレビューも、構成のイメージが頭の中にないと判断が難しく苦労した部分でした。AWS公式ドキュメントに加え、Claudeを活用して疑問に思った箇所を一つずつ理解していくアプローチで進めました。 2つ目は、リポジトリ構成とリモートステートの設計です。新規のリソースを作成する際、AWSのサービスごとに細かくstateを分割しようとしていたところ、SREチームから「リモートステートを多用しすぎない設計」をお勧めされました。 stateを分けるほど依存関係が複雑化し、apply順や terraform_remote_state の管理コストが増えるためです。アプリケーションエンジニア側のみで進めていたら気付けなかった視点で、SREチームのレビューを受けながら進められた価値を強く感じました。 デプロイと運用の整備 インフラリソースが揃ったら、次はアプリケーションをデプロイし、運用できる状態にするフェーズです。デプロイ用ワークフローの作成、Operationコンテナ環境の整備、Cognitoとアプリケーションの繋ぎこみなどを進めました。 ここで助けになったのは、既存の他プロダクトでしっかり整備されていたCI/CDフローでした。 tech.findy.co.jp デプロイの流れもOperationコンテナの構成も、基本的に「ゼロから設計する」のではなく「動いているフローを参考にする」アプローチで進められたのです。 SREチームと既存プロダクトを担当するエンジニアの両方に相談しながら、Findy Contextの構成に合わせた設計を組み立てていきました。 監視（Datadog）の整備 環境構築のクローズ後、別途取り組んだのが監視体制の整備です。Datadogでのダッシュボード作成、モニター（アラート）設定、ログ・メトリクスの収集設計、エラー検知の整備などを進めました。 SREチームが整備したDatadog基盤のおかげで、「Datadog自体をどう使うか」は迷わずに進められました。 このフェーズで一番大きな気付きは、監視や可視化はインフラ側だけでは完結しないということです。 例えばログ・エラー検知の領域です。エラーを正しく追跡できるようにするには、アプリケーション側で例外ハンドリングの設定を見直す、ログの出し方を整える、といった作業が必要でした。 「Datadogでエラーが見えない」という現象の根本原因が、Datadogの設定ではなくアプリケーションコード側にあるケースがありました。 詰まったポイントは2つです。 1つ目は、アラートの閾値とチューニングです。「何を、どの値を超えたらアラートを出すべきか」は、各サービスや時期に応じて判断が必要で、最初は誤検知が頻発したり、逆に本来検知すべき異常を見逃したりしながら調整を重ねました。 2つ目は、ダッシュボード設計とアプリ側のログ整備です。「何を載せるか、載せないか」「どんなログをどう出せば後で追跡できるか」は、メトリクスやログの選定だけでなく、アプリケーションの実装と表裏一体でした。 SREチームや既存プロダクトを参考にしつつ、Findy Contextのコードにも並行して手を入れていきました。 監視整備は、「インフラだけ知っていればよい」という認識を一番大きく崩した経験でもありました。可視化の基盤として、アプリケーション側の知識が必要だと、身をもって学んだフェーズです。 個人として取り組んだこと ここまで「仕組みが整っていた」という話を中心にしてきましたが、それだけで踏み出せたかというと、そうではありません。仕組みを活かすには、自分側でも一定の準備が必要でした。 私が並行して取り組んだのは、AWS認定ソリューションアーキテクト アソシエイト（SAA）の取得でした。 試験勉強の中ではAWS公式の「AWS Hands-on for Beginners」も活用し、書籍だけでは身につきにくい「実際にコンソールを触ってリソースを作る」感覚も合わせて身につけました。 SAAを通して、実際の業務で使うサービスだけでなく、AWSの主要サービスとアーキテクチャパターンを体系的に学べたことで、知識の幅が広がりました。 例えばコスト最適化のように、業務で直接深掘りしていない領域でも、「ここはもう一歩改善できそう」という気付きを得られる引き出しが増えた感覚があります。 「環境が整っていれば誰でも自走できる」わけではなく、整った環境を活かすための準備として、自分の側に基礎知識のストックを作ることが、踏み出す上で大きな支えになりました。 今後の伸び代 今回の構築で見えてきた、自分側と仕組み側の伸びしろを書いておきます。 自分側 複数リポジトリにまたがるサービスならではのオブザーバビリティ設計です。 Findy Contextは複数リポジトリで構成されており、1リクエストが複数サービスを跨ぐ場合の追跡や、ログ・メトリクスの相関付けには、まだ改善の余地があります。 Datadog APMなどを活用しながら、どう設計していくかは今後の課題です。 仕組み側（汎用モジュール・テンプレートへの改善余地） ここまで書いてきたとおり、SREチームが整備してくれた汎用モジュールやテンプレートには、非常に大きな価値を感じています。その上で、実際に使ってみて感じた「もう一歩テンプレート化されると嬉しい」領域も挙げておきます。 初期セットアップ（AWSアカウントの発行 → OIDC認証 → Terraform / GitHub Actionsの初期構成）の部分は、想像以上に時間がかかった領域でした。 中核のリソース構築は汎用モジュールのおかげで早く進められた一方で、初期のアカウント・認証まわりは、まだ個別対応の比率が高めだと感じました。 ここがもう一段テンプレート化されると、次に立ち上げる新規プロダクトの初動はさらにスムーズになりそうです。 まとめ Findy Contextのクラウド環境立ち上げを通して、最も強く感じたのは、「仕組み」と「個人の学習」の両方が揃って初めて、経験1年のエンジニアでも0→1に踏み出せるということでした。 仕組み側（SREチーム）が整備してくれた汎用モジュール、テンプレート、既存プロダクトの参考実装、相談しやすいサポート体制など、これらが
- SRE
- Terraform
- AWS
- Datadog
- CI/CD