ID:85524さん

### 概要 人材と企業をマッチングするWebサービスの内製開発基盤で、約100のAWSアカウントを対象にSRE／CCoE・Platform Engineeringを推進した。少人数のインフラチームに知識・判断・作業が集中していた中央集約型の運用から、各開発チームが自らインフラを管理・改善できる体制への移行を進めた。 - 規模：約100 AWSアカウント、Platform Engineeringグループ約15名 - 役割：Member／Tech Lead ### 担当 - SRE／CCoE・Platform Engineeringの推進 - AWSサービス利用ガイドライン、SRE関連ドキュメント、Terraformモジュールの整備 - Terraform／HCP Terraformを用いたIaC・CI/CD基盤の設計・構築 - AWS CDKを用いたIAM／権限管理基盤の整備 - EC2／SQL Server等のレガシー基盤刷新、RDS・ECS Fargate等への移行 - Savings Plans／Reserved Instancesの試算・購入、FinOps運用 - 期初ロードマップ策定、スクラムマスター、タスクリファインメント - 1on1、目標設定・評価、採用面接 ### 使用技術 - AWS基盤：AWS Organizations、IAM、VPC、EC2、ECS／Fargate、RDS - IaC／Platform：Terraform、HCP Terraform、AWS CDK - CI/CD／開発基盤：GitHub、GitHub Actions - Observability：CloudWatch、New Relic、PagerDuty - FinOps：Savings Plans、Reserved Instances、Cost Explorer - チーム運営：Jira、Confluence、GitHub ### 課題 約100のAWSアカウントを扱う環境に対し、少人数のインフラチームへAWSに関する知識・判断・作業が集中しており、開発チームがインフラ変更を行う際にはインフラ担当者への依頼や支援が必要となる中央集約型の運用になっていた。 また、環境やチームごとにインフラ構成、IaC、デプロイ方法が異なり、変更方法や判断基準が属人化していた。インフラチーム自身も定型作業や個別支援に時間を取られ、アーキテクチャ改善やレガシー基盤刷新に十分な時間を使いにくい状態だった。 ### 取り組み AWSサービスの利用ガイドライン、SRE関連ドキュメント、Terraformモジュール等を整備し、モブプログラミングや設計支援を通じて開発チームへ知識と運用を移管した。インフラチームが直接作業するのではなく、開発チーム自身が変更・運用できる範囲を増やすことで、中央集約型の運用から開発チーム主体の運用への移行を進めた。 IaCについてはTerraform／HCP Terraformを導入し、インフラ変更をコード化するとともに、CI/CDパイプラインを整備した。IAM／権限管理ではAWS CDKを用い、変更内容をレビュー可能な形で管理・デプロイできる仕組みへ移行した。 レガシー基盤については、EC2上で稼働していたSQL ServerのRDS移行や、アプリケーション基盤のECS Fargate化など、マネージドサービスを優先する方針で刷新を進めた。 FinOpsではSavings Plans／Reserved Instancesの利用状況を継続的に確認し、試算・購入プロセスを整備した。あわせて、試算・購入方法そのものを開発チームへ移管し、インフラチームだけがコスト最適化を担うのではなく、各チームが継続的に判断できる運用へ変更した。 ### 工夫した点 単にTerraformや共通基盤を提供するだけでは開発チームの自律性は上がらないと考え、ガイドライン、モジュール、CI/CD、設計支援を組み合わせて提供した。完成した仕組みを渡すのではなく、モブプログラミングやレビューを通じて「なぜその構成にするのか」「どのように変更するのか」まで共有し、開発チーム側に判断基準を残すことを意識した。 また、Platform Engineeringを「インフラチームが便利な共通基盤を作ること」だけにせず、開発チームが自らインフラを扱える範囲を増やし、インフラチームは定型作業からアーキテクチャ支援や基盤刷新へ役割を移していくことを重視した。 FinOpsでも、Savings Plans／Reserved Instancesをインフラ担当者だけが購入・管理するのではなく、利用状況や将来計画を踏まえて開発チーム自身が判断できるよう、試算方法・判断基準の移管まで行った。 ### 成果 - 約100のAWSアカウントを対象に、中央集約型のインフラ運用から開発チーム主体の運用への移行を推進 - AWSサービスガイドライン、SRE関連ドキュメント、Terraformモジュール、IaC／CI/CD基盤を整備 - EC2上のSQL ServerをRDSへ移行し、ECS Fargate化などマネージドサービスを優先した基盤刷新を推進 - Savings Plans／Reserved Instancesの試算・購入プロセスを整備し、合計約3,000万円のコスト削減を実現 - FinOpsの試算・購入方法を複数の開発チームへ移管し、継続的にコスト最適化を行える体制へ移行 - ロードマップ策定、スクラム運営、1on1、目標設定・評価、採用面接まで担当し、技術とチーム運営の両面からPlatform Engineeringを推進

### 概要 医療従事者向けWebサービスを支えるSREチームの再設計プロジェクト。従来のインフラチームからSREチームへ移行するため、FY26のSREロードマップ策定、技術方針・アーキテクチャ判断、責任・権限設計、チーム運営、ピープルマネジメント、採用までを一貫して担当した。 - 規模：AWS Organizations 15アカウント、SREチーム3〜6名、重点施策8件 - 役割：Tech Lead／Engineering Manager ### 担当 - SREロードマップ策定、施策の優先順位付け - アーキテクチャ設計、技術方針・技術判断 - 一部施策のPoC・実装、メンバー担当施策の設計／PRレビュー - チーム運営、1on1・キャリア面談、採用・技術面接 - 評価案・社内規定レンジ内での報酬案の策定、異動検討への関与（最終承認はGL・経営層） ### 使用技術 - AWS基盤・ガバナンス：AWS Organizations、IAM Identity Center、IAM、SCP、AWS Config - Security：Security Hub、GuardDuty、Inspector - Observability／Reliability：CloudWatch OAM、CloudWatch Synthetics、X-Ray、Application Signals、OpenTelemetry／ADOT - Automation／Platform：Lambda、EventBridge、SSM Automation、Terraform、GitHub Actions - Infrastructure：ECS／Fargate、EC2、RDS／Aurora - FinOps：Cost Anomaly Detection、Trusted Advisor、Compute Optimizer、Cost Optimization Hub、Savings Plans、Reserved Instances - チーム運営：Jira、GitHub、GitHub Projects、Confluence、Slack ### 課題 権限付与、監視、セキュリティ、コスト管理、キャパシティ管理などの運用が個人の知識や手作業に依存しており、AWSアカウントの増加に伴って運用負荷と判断の属人化が拡大していた。 また、組織再編の中で責任者や意思決定者が曖昧になり、判断が特定メンバーに集中する領域と、誰も判断しない領域の両方が発生していた。単にチーム名をSREへ変更するだけでは、従来のインフラチームと同じ運用構造が残ることを課題と捉えた。 ### 取り組み 実際のシステム、運用、Issue、障害を事実ベースで棚卸しし、トイルや属人化している領域を整理した上で、FY26のSREロードマップを策定した。権限運用、IAM／SCP、Security Hub、監視・観測、DB管理、コスト管理、キャパシティ管理などの重点施策について、重要度・リスク・効果・実現コストを踏まえて優先順位を決定した。 あわせて、SREの基本スタンス（トイル排除、属人化の解消、障害は人ではなく構造で直す）と、開発／SREのオーナーシップ分界（開発＝サービスの信頼性、SRE＝プラットフォーム・ガードレール）を定義し、SLI／SLOやSREアンチパターン等を文書化してチームの判断基準とした。 技術施策だけでなく、SREチームの責任・権限・意思決定構造も整理し、チーム運営、技術方針、障害対応、採用など22領域の責任・権限表を作成した。あわせて、WIP制限、デイリー、リファインメント／プランニング等の運営プロセスを整備した。 採用では、7つの評価軸とジュニア／ミドル／シニアのレベル別基準を策定し、書類選考・一次技術面接を担当した。質問内容は候補者に応じて変えつつも、評価軸・採用ライン・根拠の記録方法は共通化し、面接官ごとの評価ブレを抑える設計とした。 ### 工夫した点 自分がすべて判断・実装すると新たな属人化になるため、自らPoCから実装まで担当する施策と、メンバーへ実装を任せる施策を分けた。設計・PRレビューでは、実装内容だけでなく「なぜその設計にしたのか」「どのリスクを見ているのか」まで共有し、メンバー自身が次の判断を行える状態を目指した。 また、責任・権限は単純な担当者表ではなく、最終責任、意思決定、実務、相談、エスカレーション先を分けて整理し、判断が一人に集中する状態と、誰も判断しない状態の両方を防ぐ構造とした。 採用基準では、「できないことを確認した」評価と「面接で確認できなかった」評価を分けて記録し、面接官の聞き漏らしで候補者が不利にならないようにした。また、評価者が独立に採点してから同時に開示する運用とし、他の評価者の意見に引っ張られない仕組みにした。 ### 成果 - 一時権限のセルフサービス化、クロスアカウント観測基盤、FinOps自動検知、キャパシティ判断自動化など、ロードマップ上の複数施策を稼働 - FinOpsでは月$3,351超の削減余地を可視化し、SP／RI更新で年間約$16,100の効果を確定 - チーム運営・技術判断・障害対応・採用など22領域の責任・意思決定範囲を明文化 - 技術面接の評価観点を標準化し、評価者間で同じ基準を用いて判断できる採用プロセスを整備