こんにちは。OptFitでエンジニアをしているKAZYです。
前回の記事から半年ぶりに筆を取りました。
この半年の間に弊社は創業5年半が経過し、シリーズBの資金調達も実施いたしました。
私自身、実はOptFitに関わって約5年になりますが、この節目のタイミングで2025年5月に正社員として入社しました。
入社後初の私のミッションが、「エンジニアリングの足腰を整える」 でした。
2025年、会社全体の目標として「今後も攻め続けられるように今守りに力を入れる」が掲げられました。開発部門も短期的には見えづらいものの、1〜2年後大きな障壁となりうる課題に向き合う時間を取りました。
この記事では、2025年に開発部門全体で進めてきた「守り」をまとめます。
入社当時に感じたこと
入社当時私は、以下のような課題を感じていました。
-
システムの全体像がわからない
新規参加者が「まず何を触っていいか」を判断しづらく、着手までに時間がかかっていました。 新メンバー向けにアーキテクチャ説明会を開く機会が何度かあり、オンボーディングの負担が大きいと感じました。 -
設計思想や開発方針がわからない
過去の決定理由が記録されていないため、時間が経つと「なぜそうしたか」が思い出せなくなり、結果として意思決定の確認に時間がかかっていました。 -
開発フローがわからない
デプロイや運用の“正解の手順”が明文化されておらず、「毎回やり方を調べる」状態になっていました。 -
開発からデプロイまでのステップが多い
手作業で行う部分が多く、デプロイをするためには何ステップも踏む必要がありました。
コンテナイメージのビルドなど、繰り返し行う作業が自動化されておらず毎回手順を調べる必要がありました。
業務委託を含め開発に関わるエンジニアが増えつつありましたが、この状態のままだとエンジニア数を増やしても組織としての速度が上がらないと感じました。
そこで、各々が自律的に、非同期で、複数人が同時に開発できる環境が必要だと判断し、開発環境の整備に着手しました。
方針
整備にあたって、次の3点を重視しました。
-
迷わない構造を作る
新しく入った人が迷わない・困らない状態を目指す。 -
非同期で複数人が開発できる状態を作る
人数が増えたときに“自然にスケールする型”に寄せる。 -
担当者が抜けても残せる仕組みを作る
属人性を減らし、決定や運用が積み上がるようにする。
具体的には、次のような状態を目指しました。
- 開発からデプロイまでの一連の流れを言語化できている
- 自動化された開発フローがある
- 設計思想や意思決定がドキュメントとして残り、辿れる
取り組み内容
1. コードベースの整理と再構築
GitLab から GitHub へ移行
創業期から使ってきたGitLabからGitHubへ移行しました。
GitHub Actionsを中心に据えたCI/CD基盤を構築したかったことや、GitHub CopilotなどAIツールとの親和性が高いことが理由です。
移行で最も苦労した点
創業期のコミット内に数GBに及ぶ巨大ファイルが混ざっていたことです。
GitHubは100MiBを超えるファイルを禁止しているので、これに引っかかりました。
これにより一部のコミットは移行できず、履歴を切り捨てる必要がありました。
移行は“ただのリポジトリ引越し”ではなく、これまでの全てを一度棚卸しすることになるので、一つ一つのシステムを見直す良い機会になりました。
マルチリポジトリから集約へ（20リポジトリ→5リポジトリ）
過去はサービスごとにリポジトリを分けていまいた。
そのため、リポジトリごとにCI/CDや運用方法の整備が必要で、そもそも整備の有無もリポジトリごとにバラバラでした。」 リポジトリ数がメンテナの数に対して増えすぎて全体像が不明瞭にもなっていました。
この機会にIaCとCI/CDを整備した上で、関連するシステムはまとめて1つのリポジトリに集約する方針に転換しました。
結果として、リポジトリ数を約20→5つに集約しました。
プロダクトごとにリポジトリを分け、プロダクト共通部分を別リポジトリとすることで、デプロイ単位と責任境界が明確になりました。
(厳密にはフルのモノリポジトリというより"集約寄りの形"ですが、目的は達成できました。)
稼働しているのに「見えなかった」システムの整理
リポジトリを見直す中で、
main に統合されないままブランチで稼働しているシステムがいくつも見つかりました。
存在に気づきにくく、後から来た人には追えない状態だったため、
内容を整理して 「main を見れば全体が分かる」構成に揃えています。
2. 稼働中のシステムの整理
IaCの整備（Terraform化）
稼働中のシステムをTerraformでIaC化しました。
その過程で、
- 一時的に追加された設定
- 理由が分からなくなっていた設定
- メンテナ不在で引き継がれていないシステム
- Terraformは使っているが、ステート管理されていない運用
など、Terraform import だけでは済まない問題が多く見つかりました。
一つずつ調べて整理する必要があり手間はかかりましたが、結果として 「何が動いていて、なぜそうなっているか」 を把握できたのは大きな収穫でした。
不要リソースの棚卸しと削除
IaC化と並行して、不要になったAWSリソースを棚卸して削除しました。
コスト削減だけでなく、システムの理解コストを下げる効果が大きかったと感じています。
途中になっていた旧→新システム移行の完了
一定のコストはかかりましたが、移行が止まっていたシステムを整理し、
旧システムを削除できる状態まで完了させました。
複数バージョンが並存する混乱が解消され、全体像の把握がしやすくなりました。
プロダクト間の責任境界整理（AWSアカウント整理）
PoCから始まったシステムが多く、
• クロスアカウント構成が多発している
• プロダクト横断で1つのAWSアカウントを使っている
といった状態になっていました。
そこで、プロダクト単位で責任境界を整理し、
• AWSアカウントの新規作成
• 不要なクロスアカウント構成の廃止
を進め、スケールしやすい構造へ寄せました。
メンテナ不在システムの引き継ぎ
メンテナ不在になっていたシステムを、
IaC化・デプロイ自動化によって共通のCI/CD・運用フローに統合しました。
久しぶりに触るタイミングで小さな改善も入れ、今後も継続して手を入れていける状態かを確認もできました。運用負荷を下げつつ、誰でも触れる状態を目指し整えました。
3. CI/CDの自動化と共通化
GitHub Actionsを軸に、CI/CDを整備しました。
- デプロイの自動化
- workflow_dispatch によるワンタッチデプロイ
- イメージビルド〜デプロイまで一気通貫
- 手元/Management Console中心の手動デプロイから、ボタン1つで再現できる運用へ移行
- lint / テストの自動化
- CIで必ず回るレールを用意し、あとからテストを増やせる土台を作った
- IaCの自動適用
- PRマージ時に Terraform の plan/apply を自動化
- 本番での手動 apply を廃止
- AWSアカウントやGitHubリポジトリ作成も同じ仕組みに寄せた
- 共通Workflowの整備
- ECR push など共通化できる処理を切り出し、各サービスから再利用可能に
人数が増えてきた今、「共通のやり方がある」というだけで、ずいぶんと運用が楽になりました。
Terraform Plan結果を表示するworkflow
Terraform Apply結果はSlackで通知
補足：
- Terraformは、PR作成時に
planが自動実行され、コミット追加の都度更新されます - mainブランチへのマージ時に
applyが自動実行されます - デプロイは
workflow_dispatchで手動トリガーし、stg/prod環境へ展開します
4. 意思決定と運用品質を“積み上がる仕組み”の構築
ADR導入と意思決定のドキュメント化
ADR（Architecture Decision Record）を導入し、意思決定を残すことを前提とした文化にしました。
各リポジトリのdocs/adrディレクトリに配置し、コードと一緒に管理しています。
AIや文字起こしを活用し、記録のコストを最小化しています。
システムドキュメントをGitHubへ集約
Notionも併用しつつ、システムドキュメントはGitHubに集約しました。
コードに近い場所に置くことで、人にもAIにも参照しやすくしています。
監視アラートの整理とNewRelic導入
監視アラートを洗い出したところ、Slackの通知チャンネルは 約70個 に増えていました。
通知が流れ続けるチャンネルもあり、監視がノイズ化している状態でした。
さらに、システムが直接Slackへ通知する設計が多く、デプロイ方法を知らないとアラート改善すらできないという構造的な課題もありました。
そこで、まず 「アラートはCloudWatch等のメトリクス経由でSlackに通知する」 方針に統一しました。
これにより、通知経路が統一され、設定がコード化しやすくなり、デプロイ手順を知らなくてもアラートの改善ができるようになりました。
不要な通知を棚卸して20個を削除、 50個 まで削減しました。
システム改修が必要なものは、引き続き順次対応しています。
あわせてNew Relicを導入し、エッジデバイスなどこれまで見えていなかった領域の監視も追加しています。
開発フロー整備とAI活用
- PRベースのコードレビューを徹底
- 人手不足を補うためのAIコードレビューを導入
- Slackにリリースチャンネルを設け、リリース情報を可視化
リリースが可視化されたことで、不具合のフィードバックが早まり、原因特定もスムーズになりました。
また、AIコードレビューにより事前に論点が整理されるため、人間のレビューが効率化されています。 gemini-code-assistと Claude Code Reviewer が現在活躍中です。
特に、週末や夜間に稼働する業務委託メンバーにとっては負担軽減の効果があり、
AIでの壁打ち後に人のレビューへ渡すことで、やり取りも円滑になりました。
輪読会の定期開催
監視や運用の目線を揃えるため、部署内で輪読会を定期的に開催しました。
書籍を題材に、実際の運用と照らし合わせながらチーム全体で議論しています。
結果
現在、正社員/業務委託を含めて15名以上で開発しており、入社時から2倍以上の体制になりました。
その中で、基盤整備の効果として以下の変化が出ています。
• 新規メンバーの参画がスムーズに（アカウント発行などの手続きが整理された）
• デプロイの異常検知が早くなった（共通Workflow＋Slack通知で可視化）
• 質問対応が軽くなった（ADR/ドキュメントを参照でき、説明の重複が減った）
加えて、Dev Container導入によりローカル環境構築も簡単になりつつあります。
CI/CDの自動テストが整ってきたことでテストが増え、意図しない変更の防止にもつながっています。
まだ道半ばですが、「人数が増えても回る形」へ着実に近づいている手応えがあります。
おわりに
2025年は、開発部門として将来の速度と信頼性を支える土台づくりに注力した一年でした。
日々の開発や運用と並行しながら、地味で伝わりにくい取り組みも多くありました。
それでも、チームメンバーそれぞれが改善に向き合い、少しずつ積み上げてきました。
その結果、今は人数が増えても開発が回り、運用も再現性をもって動き始めています。
日々のレビューや議論、改善提案に関わってくれたメンバー全員の積み重ねだと感じています。
2026年は、この基盤の上で、守りを維持しながら次の“攻め”をさらに加速させていきます。
OptFitでは、こうしたフェーズを一緒につくっていく仲間を募集しています。
ここまで読んでいただき、ありがとうございました。
Discussion