一人目エンジニアとして取り組んだ「攻めの」SRE

著者：tyki
目次

はじめに

エンジニアが 0 人のスタートアップに一人目の正社員エンジニアとして入って、これまで取り組んできた SRE 的な活動の振り返りです。

なお、この記事でいう SRE は、専任のインフラ/SRE チームが担う狭義の信頼性エンジニアリングだけを指していません。現在の弊社の少人数（正社員エンジニア 3 名、業務委託 5 名ほど）の Web プロダクト開発において、開発速度を落とさず、安全にリリースし続けるための仕組みづくりも含めて、広義に SRE 的な活動として扱っています。

本稿では、可用性や障害対応を中心にした活動を便宜上「守り」、開発者が安全に速く価値を届けるための仕組みづくりを「攻め」と呼びます。

タイトルにあえて「攻めの」と付けました。SRE というと信頼性を上げる「守り」のイメージが強いと思うのですが、私がやってきたことの多くは、開発の速度を上げるための活動でした。なぜそこに振ったのか、という話を中心に書いていきます。

自己紹介

tykiと申します。現職には、2025 年の秋頃に大学で同じ研究室だった代表から声をかけられて一人目の正社員エンジニアとして入社しました。

前職は広告代理店で、3 万 QPS を超える広告配信サーバー（Golang, GKE）のエンジニアをやっていました。FinOps やログ配信基盤のリアーキテクチャを担当したり、インフラとバックエンドがメインの仕事でした。現職では、技術選定、アーキテクチャ設計、実装、運用まで、プロダクト開発に必要なことを幅広く担当しています。

前提

IRBANK は 10 年以上運用され、100 万 MAU を超える個人投資家向け Web プラットフォーム（https://irbank.net/）になります。これを AI 時代を前提としたサービスとしてリニューアルすべく、フルスクラッチで鋭意実装をしております。リニューアル版はまだベータ版のみ限定公開している段階です。なのでリリースされたプロダクトの信頼性をどのように担保しているかという話ではなく、「公開に向けて、SRE という軸で攻めの地盤をどう作っているか」という話になります。

技術スタック

技術スタックも簡単に触れておきます。言語はフロントエンド/バックエンドともに TypeScript で統一し、Bunと Nxでモノレポを採用しています。バックエンドはすべて Hono、Node.js で書いていて、用途に応じてデータストアを使い分けています。メインの API は Drizzle ORM + PostgreSQL、データは Cloud Spanner、Bigtable、キャッシュに Memorystore を採用しています。フロントエンドは Next.js、React。アプリケーションの実行基盤は Cloud Run です。CI/CD 基盤には GitHub Actions を利用しています。

私が入社してから半年あまりが経過し、フルスクラッチしているアプリケーションのコードベースは、TypeScript / TSX で 100 万行弱、7,000 強のファイル。アプリケーションが 25 個以上という構成のモノレポになっています。フロントエンド、いくつものバックエンド API、外部のデータ提供元に依存するデータパイプラインが数十本、それらを支えるインフラ関連のコンポーネントがあります。

スタートアップ規模の会社に SRE は必要なのか

私もSRE Magazine 011 号（2025/12/24）「スタートアップにおける SRE を考えてみる」での整理と近い考えで、スタートアップ規模かつ、特に PMF 前のまずプロダクトをリリースさせて、ユーザーのニーズを満たすプロダクトが完成するまでは専任のSRE の必要性は低いと思っています。だからと言って SRE 的な動きは不要だとは思わないです。むしろ、SRE の視点を持ち、人的リソースが追加されたときに、いかに速度を上げるか、あるいは減速させないか。そのためにできることをできる限りやっておく必要があるんじゃないかと考えています。

なぜ「攻め」なのか ── +1 を +1 のまま維持する

私が大事にしている考え方を書かせてください。

開発の人員を増やすとき、理想は 1 + 1 = 2 です。でも現実には、そう単純にいきません。新しく入った人のキャッチアップコスト、属人化した手順の引き継ぎ、「これを出して壊れないだろうか」という怖さ。こういうものが、せっかく追加された 1 を 0.5 に目減りさせてしまう。さらに悪いと、その面倒を既存のメンバーが見ることになって、自分の 1 まで削られる。気づくと 1 + 1 が 2 を下回っている、ということが起こります。

人を足しても出力が線形に増えない。これは、規模が小さくてスピードが命の会社にとっては致命的です。

だから、追加された人の「+1」を、目減りさせずに「+1」のまま維持、もしくは「+1.5, 2.0」にすることに全力を注ぐべきだと考えました。言い換えると、新しく入った人が、低いキャッチアップコストで、すぐに、安全に、自分で価値を出せる地盤を先に作っておく。これが、一人目の正社員エンジニアの自分が出せるいちばん大きなレバレッジだと考えていました。

続いて、その具体的な中身をご紹介できればと思います。

攻め① トイルを削る

インフラについては、入った時点でそもそも存在していませんでした。新しい IRBANK を作るタイミングで Google Cloud を選定して、最初から Terraform で管理する方針で進めました。

いまでは、インフラのコードは Terraform で 200 弱のファイル、約 3 万行。管理しているリソースは 700 を超える規模になってきています。環境（検証環境 / 本番）や組織レベルの設定で state を分割し、モジュールで共通化する構成です。これだけの規模を少人数でも宣言的に管理できているのは、最初に IaC 化へ振っておいてよかったと思える部分です。新しく入った人が、コンソールの暗黙知や「あの人しか知らない手順」に頼らずに、コードを読めば構成を理解できて、再現もできる。これが +1 をそのまま維持するための土台の一つになったと振り返っています。

インフラと並んで最初に手を入れたのが CI/CD です。アプリケーションを作る以上、ビルド・テスト・デプロイは必ず発生する作業で、ここを整備しないまま人が増えると「リリース手順を知っている人しかリリースできない」という属人化が真っ先に生まれます。なので、デプロイは GitHub Actions に寄せて、人手の手順を残さない方針で進めました。

具体的にやってきたことを羅列すると、こんな内容です。

  • 全アプリ共通の CI（format / lint / test / build、後述）と、テストカバレッジゲート
  • main マージを起点に各アプリを Cloud Run へ自動デプロイする CD（アプリ・パイプラインごとに 25 本以上）
  • release-pleaseによるリリース PR / バージョニングの自動化と、検証環境 → 本番環境の順次デプロイ
  • DB スキーママイグレーションの CI/CD（PR でのスキーマ検証 → マージ後に検証環境 / 本番環境へ適用）
  • Terraform の plan を PR で、apply をマージ後に実行する IaC の CI/CD と、IaC 管理外の変更を検出するドリフト検知
  • PR にラベルを付けると差分入りの実環境が払い出されるプレビュー環境（後述）

こうして CI/CD を整備していく中で、いちばん悩んだのは、インフラをどこまで自動化するかの線引きです。

スピードを出すことだけを考えれば、すべてを CD で自動 apply してしまう、という手もあります。ただ、それはセキュリティ的にかなり危ないし、破壊的な変更も起こりやすくなる。ここ半年ほどのセキュリティインシデントを見ていると過剰な権限付与による事故は本当に怖いです。なので、自動化していい領域と、手動でやるべき領域の選定は、今も一定悩みながらやっています。

現状は、特に権限まわりは手動で変更するようにしています。それ以外でも、破壊的な変更は CD では実行できないようにしています。考え方としては、自動化そのものにも最小権限を効かせる、ということです。日常的で影響範囲の限られた変更は自動化して速さを取る。一方で、権限の変更のように影響範囲が大きく、特権の昇格を伴うものは、CD の実行サービスアカウントにあえてその権限を持たせず、人が必ず apply する。攻め（速さ）と守り（安全）を、二層に分けて両取りする、というのが今のやり方です。

攻め② 安全に、速く出す

続いて、PR を出してからマージされるまでの体験を磨いた話です。

テストカバレッジレポート

PR を作成すると、実装差分とアプリケーション単位のテストカバレッジ（Lines, Functions）がコメントとして出力されます。これが 80% を下回ると CI エラーとなって PR マージができないようにしています。カバレッジのレポートは自前で PR コメントに自動で作成するようにしていて、レビューのたびに手元で測らなくていいようにしています。

テストは書いた方がいい、というのはベースの考えとしてあります。ただ、カバレッジ 100% を目指すといったことは本質的ではないと思っていて、適切なテストを適切な量だけ書くのが大事だと考えています。数字そのものを目的にすると、意味のないテストで数字だけ上げることになりかねないので、現時点では、目安として 80% に置いています。

プレビュー環境

PR を作成して、Preview Label をつけると PR 差分を含む Web アプリケーション（Cloud Run）とバックエンドアプリケーション（Cloud Run）が自動で払い出されて、PR に URL 付きでコメントがつくようになっています。検証環境の DB を参照しているので、ローカルよりも実際の環境に近い動作確認が可能です。

追加したきっかけは、フロントエンドとバックエンドをつないだ動作確認を、レビュアーがしづらいという課題でした。プレビュー環境を見れば、レビュアーも、開発者自身も、検証環境の実環境につないだ状態で動作確認ができる。ローカルだけでは再現しきれないデータやケースがあるので、そこを実環境で確認できるのが便利だと思ったのが狙いです。

これが、思っていた以上に効いている場面があります。例えば UI のちょっとしたスタイル変更や、文言の修正。これまでは、エンジニアが修正した内容を QA に出し、QA 担当者が修正すべき箇所に気づいたら連絡し、それを受けてエンジニアが再度修正する、というフローでした。それが、QA 側の人がその場で軽微な修正をそのまま PR に出して、エンジニアがレビューするだけで取り込めるようになりました。

CI/CD の高速化

一つの PR を作成すると、変更内容に応じて最大で十数本のワークフローが走ります。内容は build / test / lint / format に加えて、テストカバレッジ計測、DB スキーマ検証、シークレットスキャンや IaC のセキュリティスキャン、Terraform の plan、UI のビジュアルリグレッションテストなどです。ただし全部が毎回走るわけではなく、モノレポの変更検知（Nx affected）で「その PR が触ったアプリのぶんだけ」実行されるようにしています。それでも移行前は平均 1〜2 分、長いものだと 3 分近くかかっていました。

高速化のためにやったのは、まず「走らせない」工夫です。Nx の affected 検知で影響のあるアプリのジョブだけを実行し、ドキュメントだけの変更では重い CI 自体をスキップする。同じ PR に push が続いたら古い実行はキャンセルする。次に「走るものを速くする」工夫で、アプリ単位にジョブを分割して並列実行し、ジョブの中でも format / lint / test を直列ではなく同時に走らせる。ツールチェーン・依存関係・フロントエンドのビルドキャッシュもそれぞれ用意して効かせる。

ここまでやった上で、それ以上の高速化を目指し、実行環境を Blacksmithに移しました。結果、直近の実行履歴を集計すると、アプリ単位の CI ジョブはおおむね半分の時間になりました。バックエンドやデータパイプラインのジョブは平均 30 秒前後〜1 分弱、いちばん重いフロントエンドのジョブでも平均 1 分半ほどです。コスト面でも割に合っています。実請求から時間単価を出すと、1 分あたりの単価は GitHub ホストランナー比で約 30% 安くなりました。さらにジョブの実行時間そのものが約半分になっているので、同じジョブあたりのコストでは約 65% の削減です。この間に開発量が増えて CI の実行量自体は数倍になっているので請求の絶対額は増えていますが、同じ量を GitHub ホストランナーでさばいていたら 2〜3 倍の請求になっていた計算です。導入して本当に良かったなと思っています。

こうした積み重ねの結果として、いまは 1 日あたり約 25 回、本番にデプロイしています（直近 90 日で約 2,270 回）。冒頭で触れたとおり、このモノレポにはフロントエンドや複数のバックエンド API に加えて、数十本のデータパイプラインなど 25 以上のアプリケーションが同居していて、この数字はそれらすべての本番デプロイの合計です。少人数体制でこの頻度で出せているのは、ここまで整えてきた地盤があるからだと思っています。

まだ解けていないこと

やりたいけれど、まだ手をつけられていないことはいくつもあります。

一つは、AI を使った Ops の自動化です。インシデントの一次対応、FinOps、バグ改修あたりを、もっと自動化で進めたいと思っています。

もう一つはオブザーバビリティで、ここはまだまだ整備できていません。弊社には大量のデータをクライアントの Web ページに表示しなければならないという要件があります。例えば（今はまだ機能としてありませんが）毎秒移り変わる株価を、しかも複数社ぶん同時に UI に表示する、といったケース。こうなると、フロントエンドからバックエンド、ミドルウェア、データベースまでを一気通貫で見て、どこにボトルネックがあるのか、どう改善するのかを押さえる必要があります。そこで OpenTelemetry をフロントにもバックにも通して、可観測性を高めていきたい。そして、本当にそれをやり切るには、公開前に負荷試験でシステムの限界を把握し、キャッシュ層や配信経路まで含めてキャパシティを設計しておく必要があると思っています。

そして、サービスの公開に合わせて、いわゆる「守り」の SRE にも本腰を入れていくことになります。SLI / SLO / SLA の策定はその中心ですが、IRBANK の場合、ここで主役になるのは普通の Web サービスのレイテンシやエラー率だけではありません。IRBANK の価値は「データが正しく、新しい」ことそのものなので、データの鮮度・欠損・正確性を SLO として定義していきたいと考えています。すでにデータの鮮度を監視する仕組みは持っているので、それを SRE の中心に格上げしていきます。

あわせて、公開後も今の開発スピードを保つために、リリースを全量一発ではなく段階的に出して影響範囲を絞る仕組み（プログレッシブデリバリ）や、正社員が増えた時でも属人化しない最小限のランブックと、責めないポストモーテムの型も、公開前に用意しておきたいところです。

まだ攻めの整備の途中で、守りはこれから、やることは尽きません。

最後に

ここまで攻めの SRE 観点でどのように開発に貢献したのかという話をしました。上記では詳細は省きましたが、もちろん、守りという意味で最低限の監視やアラートは設定しています。

宣伝になってしまい恐縮ですが、もしこの記事を読んでくださる方の中に、IRBANK に興味を持ってくださる方がおりましたら嬉しいです。現在、SRE という明確なロールはありません。「SRE に強みの軸足を持ちながら、フルサイクルでプロダクトを作っていきたい」そういう人と、ぜひ一緒に働きたいと思っています。

IRBANK は、金融という機能・非機能要件の高さ、扱うデータ量、求められるパフォーマンス。データの鮮度や正確性といった プロダクト の価値そのものを最上段に置き、ユーザー体験、そしてフロントエンドからバックエンド・データベースまでを一本のトレースで貫いてボトルネックへドリルダウンしていく、そんなオブザーバビリティの基盤を、自分たちの手で設計していけるフェーズです。 プロダクトとしての技術的な要求レベルが高く、エンジニアとしては面白い領域だと思っています。

投資を支援するサービスとして、少なくとも日本一、近い将来に世界一を目指して日々開発に取り組んでいます。そういう野心的なプロダクトを作ることに興味がある方とは、ぜひご一緒したい。さらに言えば、投資判断を人ではなく AI エージェントが行う未来に向けて、ユーザーとして AI エージェントが利用することを前提としたプロダクト作りにも、興味がある方とお話ししたいです。

corp.irbank.net corp.irbank.net

最後までお読みいただきありがとうございました。またどこかで、リリース後の運用フェーズについてもご報告できればと思います。