HagaSpa

- 期間: 2025/08〜現在 - 役割: Platform Engineer として設計・実装を担当し、nginx-ingress から Gateway API への移行を主導 - 規模: 複数プロダクト（クラウドファクタリングの OLTA、請求書サービスの INVOY ほか）の GKE クラスタと CI/CD - 技術: GKE, Kubernetes（HPA / VPA）, Gateway API, Terraform, GitHub Actions, Cloud Monitoring - 課題: Platform（インフラ・デプロイ・監視）の運用が実質 1 人に依存しており、障害対応もコストの判断もその 1 人に集中していた。開発環境もマルチゾーン構成で動いており、必要以上のコストがかかっていた。ingress には EOL を迎える nginx-ingress を使い続けていた - 取り組み: - 全開発環境の GKE クラスタをシングルゾーン構成へ移行。新クラスタの構築から DNS の切り替えまでを担当した - 負荷試験で Resource Request を適正化し、HPA の上限に達したときの最大処理能力を明らかにした。VPA の推奨値も本番に反映した - INVOY の CPU 高騰障害で、高負荷の Pod が特定ノードに偏る原因を特定し、livenessProbe の設定不備による無限ループも見つけて修正した - 1 つのリポジトリが GitHub Actions の実行時間の 42% を占め、そのうち約 7 割が E2E テスト（Playwright）であることを特定し、E2E を main へのマージ時だけ実行するようにした - nginx-ingress から Gateway API への移行に向けて ADR を書き、annotation の互換性、LB 経由でのヘッダー変化によるアプリケーションへの影響、Gateway + IAP による Service 単位の認証を検証した。移行手順書と計画も作り、プロダクトチームに引き渡した - 他のエンジニアが GKE の構築などを実際に手を動かして学ぶ場「Platform Contributors」を始めた - 成果: - 開発環境のシングルゾーン化で GKE のサーバ費用を約 43% 削減 - GitHub Actions の実行時間を月約 14,700 分削減（当該リポジトリの約 9 割、Org 全体の約 1/4） - Gateway API への移行や GKE の構築を、プロダクトチームが自分たちで進められる体制にした。この取り組みはテックブログで公開し、全社員が集まる会でも開発組織の代表として AI 活用をテーマにした LT に登壇した - テックブログ: https://techblog.olta.co.jp/entry/2026/07/22/071625

- 期間: 2026/05〜現在 - 役割: 方針の決定から実装、全社への周知までを担当 - 規模: GitHub Org（約 130 リポジトリ）、Terraform Cloud、Jenkins など、全社共通の開発基盤 - 技術: GitHub（Teams / Ruleset / Secret Scanning / GitHub Apps）, Terraform, Jenkins - 課題: 前任者の退職や担当者の不在で、GitHub Org や開発系 SaaS の管理者がいない状態になっていた。全メンバーがリポジトリを作成でき、作成者以外からは見えないリポジトリが増えていた。権限も UI から個別に付与されていたため、誰が何にアクセスできるかを追えなかった - 取り組み: - GitHub Org と Terraform Cloud の管理、Jenkins の認証を CTO 室で引き継いだ。Jenkins の GitHub 認証は、より権限の狭いトークンに切り替えた - GitHub の Teams を雇用・契約形態（正社員・業務委託）に基づいて再設計し、リポジトリ作成・fork の権限を管理者に限定した。権限付与を Terraform の PR 経由で行う運用に切り替え、全社に告知した - 社内リポジトリに残っていた本番環境の認証情報を発見し、インシデント対応を主導した。証跡を保全し、監査ログから不正利用がないことを確認したうえでキーをローテーションした - 再発防止として、全リポジトリへの Secret Scanning の導入、アクセスログの永続化、全プロダクトの認証経路の棚卸しを行った - 他社のサプライチェーン攻撃事例を受け、個人アクセストークンを削除して GitHub Apps に移行した。開発ツールをどこまで統制するかを Low / Mid / High の 3 段階に整理し、判断材料としてまとめた - 成果: - GitHub の権限変更が PR として残り、誰がいつ何を変えたかを追える状態になった - インシデントは不正利用がないことを確認して収束させた。同じ種類の漏洩は全リポジトリで検知できるようになった - 2026 年度下期は、Ruleset / branch protection の Terraform 管理への移行と、未使用リポジトリの整理を進めている

- 期間: 2025/08〜現在 - 役割: Data Engineer として、dbt・Looker の設計・実装と運用を担当 - 規模: BigQuery 上のデータ基盤（dbt / Looker / Airbyte）。ビジネス部門を含む全社が利用 - 技術: BigQuery, dbt, Looker（LookML）, Airbyte, GitHub Actions, Salesforce - 課題: dbt の変更はローカルで確認するしかなく、後続モデルの実行漏れなどの不具合がマージ後に見つかっていた。マスタの手動管理やハードコードも残っていた。データの登録漏れや更新の停止にも気づけない状態だった - 取り組み: - 提携金融機関に支払う収益分配（レベニューシェア）の計算方法を見直すプロジェクトで、データ仕様書の作成から dbt・Looker の model / explore の追加まで一貫して担当した - dbt では PR ごとに BigQuery のデータセットを自動で作る CI（GitHub Actions）と、manifest を使った差分ビルドを実装した。Looker にも LookML の CI を導入した - ユーザーを経由元の提携金融機関ごとに分ける区分はハードコードされていたため、dbt の seed（マスタ）で管理する形に移し、翌朝の自動チェックで登録漏れに気づけるようにした - INVOY の分析用データ（77 テーブル）の更新が約 4.5 か月止まっていたため、原因を特定して復旧し、影響を受けた集計も補正した - GA4 のイベントログのモデルを incremental 化し、Partition Pruning が効く形にした - Salesforce から BigQuery へ同期する Airbyte のコネクタをバージョンアップし、データ検証のアラートを整えた - 成果: - 2026/05 に新しい計算方法での本番運用を始めた。提携金融機関向けのデータ抽出は保存済み Look にして、非エンジニアの担当者が自分で CSV を出せるようにした - PR の時点で変更後のデータを確認できるようになり、ローカルでの動作確認が不要になった - 手動の CSV 運用を廃止し、登録漏れを自動で検知できるようにした - GA4 のスキャン量を 72.9GiB から 25.5MiB に削減（99.97% 減） - テックブログ: https://techblog.olta.co.jp/entry/2026/06/29/161346

- 期間: 2025/12〜現在 - 役割: 開発組織で AI 活用の推進を担当 - 規模: 開発組織全体と、PdM・非エンジニアを含む社内メンバー - 技術: Apache DevLake, Grafana, GCE, IAP, Claude Code（Plugin Marketplace / Routine） - 課題: 開発生産性の計測のために外部 SaaS（FindyTeam+）の正式導入を検討していたが、年間約 63 万円の費用がかかる見込みだった。AI ツールの使い方は個人任せで、スキルやノウハウを共有する仕組みがなかった - 取り組み: - 外部 SaaS の正式導入の前に、OSS の DevLake を GCE 上に構築し（認証は IAP）、開発生産性と投資配分を Grafana で可視化した - Claude Code の全社展開に向けて予算を申請し、利用方針を全社で合意した - 社内向けの Plugin Marketplace を用意してスキルを配布できるようにし、PdM や非エンジニアにも広げた - Claude Code Routine で社内の申請通知などを自動化した - AI による PR レビューの体制を設計し、ISMS の要件（1 人で本番にコードを入れられないこと）と両立するかを確認した - 成果: - 外部 SaaS の正式導入を見送り、導入していればかかっていた年間約 63 万円を削減 - Claude Code の全社展開が決まり、非エンジニアからも活用の相談が直接来るようになった - テックブログ: https://techblog.olta.co.jp/entry/2026/02/25/113341

飲食店向けモバイルオーダー・POS サービスのインフラを担当し、全環境の GCP リソースを Terraform により IaC 化して構成を統一。GCP Alert と Cloud Monitoring によるサービス監視を強化し、インフラ運用知見の共有とドキュメント整備を実施。これにより IaC と実リソース間の差分を解消し、特定メンバーに依存せずアラートで障害検知できる体制を構築し、検知から対応までの時間を短縮した。 - 期間: 2023/06〜2025/08 - 役割: Platform Engineer として、インフラの設計・構築・運用を担当 - 規模: 全環境の GCP リソースを管理する、数千行規模の Terraform コード - 技術: GCP（Cloud Run, AlloyDB, Cloud Monitoring）, Terraform - 課題: インフラの作り方が人によってばらばらで、IaC のコードと実際のリソースに差分が生じていた。またアラートが十分に整っておらず、障害に気づけるかどうかが、経験が豊富で感度の高い一部のメンバーに依存していた - 取り組み: - GCP のリソースをすべて Terraform で IaC 化し、構成を統一した - GCP Alert と Cloud Monitoring でサービスの監視を強化した - インフラ運用の知見の共有とドキュメントの整備を進めた - 成果: - IaC のコードと実際のリソースが一致し、構成が統一された - 特定のメンバーに頼らず、アラートで障害に気づけるようになった。障害の検知から対応までの時間も短縮した

秒間 5,000 リクエストを超えるサービスに対して、Platform Engineer 兼 Incident Manager として信頼性向上を担当。ピークタイムや繁忙期を考慮したキャパシティプランニングを実施し、リリース後もパフォーマンスを継続監視。大規模障害に備え全社員向け緊急対応訓練を企画・主導し、週次ポストモーテムを開催してインシデントの振り返りと改善提案・クロージングを推進。プロダクト固有課題には分科会を設けて対応し、SLI 低下の早期検知と実際の大規模障害時の影響最小化を実現した。 - 期間: 2023/06〜2025/08 - 役割: Platform Engineer / Incident Manager - 規模: 秒間 5,000 リクエストを超えるサービス。チームは 4 名ほど - 技術: GCP（Cloud Run, AlloyDB, Cloud Monitoring） - 課題: ピーク時の負荷に耐えられるかを事前に見積もる仕組みがなかった。また、障害などの緊急事態が起きたときに、状況に合わせた対応体制をすばやく組み、顧客への影響を最小限に抑えられるようにする必要があった - 取り組み: - ピークタイムや繁忙期を考慮したキャパシティプランニングを行い、リリース後も定期的にパフォーマンスを監視した - 大規模障害に備えて、全社員を対象にした緊急対応訓練を企画・主導した - Incident Manager として週次のポストモーテムを主催し、インシデントの振り返りから改善策の提案、クロージングまでを主導した。プロダクト固有の課題には、関係者だけを集めた分科会を設けた - 成果: - SLI の低下を早く検知して対応できるようになった - 実際に大規模障害が起きた際は、訓練の成果を活かして顧客への影響を最小限に抑えた

社内初の DevRel 専任担当エンジニアとして、事業拡大に向けたエンジニア採用強化を目的に活動。自社主催の採用目的の技術イベントや勉強会を企画・実施し、エンジニア向け採用ページを構築・公開。会社として初の TSKaigi 出展でオーナーを務め、各種調整とブースコンテンツの企画・実施を主導。TypeScript 利用者向けイベントでは会場手配や予算算出、登壇者調整、スポンサー対応を含む運営全般を担当。エージェント連携や転職サービス選定・運用を行い、カジュアル面談を継続実施できる体制を作り、自身も年間約 50 件のカジュアル面談を担当した。 - 期間: 2025/01〜2025/08 - 役割: 社内初の DevRel 専任担当 - 規模: 部署横断の取り組み（組織の OKR に紐づけて実施） - 課題: 事業拡大に向けてエンジニア採用を強化する必要があり、より効果的な採用広報のやり方を探っていた - 取り組み: - 採用を目的にした自社主催の技術イベントや勉強会を企画・実施した - エンジニア向けの採用ページを構築・公開した - 会社として初めての TSKaigi 出展でオーナーを務め、各種調整とブースのコンテンツの企画・実施を主導した - TypeScript 利用者向けのイベントを企画・運営し、会場手配、予算の算出、登壇者の調整、スポンサー対応など運営全般を担当した - エージェントとの連携や転職サービスの選定・運用を担当し、カジュアル面談を継続的に行える体制を作った - 成果: - 採用ページは公開から 2 週間で 1,000 PV を達成 - TSKaigi のブース来訪者は 400 名超、自社の X アカウントのフォロワーは 200 名増加。TSKaigi のアンケートで「もっとも印象に残ったブース」に選ばれた - TypeScript のイベントには、オンライン・オフライン合わせて 250 名が参加 - 社内全体のカジュアル面談の数が従来の約 2 倍になり、自身も年間約 50 件を担当した

ワールドグループのブランド Original Stitch の生産管理システム構築を担当。業務運用が定まっていない領域の課題に対し事業部門と連携し、要求の鵜呑みではなく根本課題を抽出して解決策を提案。2021/08 からリードエンジニアとしてスクラム開発を導入し、要求整理・タスク起票・JIRA でのスプリント管理・ロードマップ策定を実施。週 1 回の定期リリース運用と月次レトロスペクティブにより、認識齟齬によるスケジュール遅延やリリース漏れを削減し、継続的改善の文化を醸成。Golang と MySQL による API、GitHub Actions による CI/CD、GCP と Terraform によるインフラ、React と Vercel によるフロントエンドを実装した。 - 期間: 2021/01〜2023/05 - 役割: 2021/08 からリードエンジニア。要求の整理、タスクの起票、スプリント管理と、API・フロントエンド・インフラの開発を担当 - 規模: 平均 5 名のスクラムチーム - 技術: Golang, MySQL, React, Vercel, GCP, Terraform, GitHub Actions, JIRA - 課題: 業務の運用が定まっていない領域が多く、商品生産の効率化が求められていた。チーム内の認識の食い違いによるスケジュールの遅延やリリース漏れも起きていた - 取り組み: - 事業部門と密に連携し、要求をそのまま受けるのではなく、根本的な課題を抽出して解決策を提案した - スクラム開発を導入し、要求の整理とタスクの起票、JIRA でのスプリント管理、ロードマップの策定を自ら行った - 週 1 回の定期リリースを始め、リリース管理を整えた - 月次でレトロスペクティブを行い、チーム内の小さな課題も拾って改善を続ける文化を作った - Golang と MySQL で API を開発し、GitHub Actions で CI/CD、GCP と Terraform でインフラ、React と Vercel でフロントエンドを構築した - 成果: - スケジュールの遅延とリリース漏れを減らし、毎週リリースできるようになった

モール型 EC 事業と KDDI の広告効果測定を目的とした DMP を少人数体制で構築・運用。生データが AWS 上に限定される制約の中で BigQuery を用いた分析環境を実現するため、AWS と GCP をまたぐマルチクラウド構成を採用。構成複雑化を見越して全インフラを Terraform による IaC とし、日次で生データを更新し日付単位パーティションのデータマートを構築してアナリストの分析効率を向上。Python と Golang でバッチ処理を開発し、Tableau でダッシュボードを作成することで営業活動や広告施策の効果測定を迅速化し、データドリブンな意思決定文化に貢献した。