ID:71246さん

【プロジェクト概要】 - 目的：社内システムのインフラ構築・開発チームのインフラサポート 　(勤怠システム, 採用システム, 社内メールシステム, データ連携基盤, 社内申請ワークフロー) - 自分の役割：インフラ周りの設計構築 / 開発チームにおけるインフラタスク発生時のスポットメンバー - チーム構成：TechLead1名、フロントエンジニア1名、バックエンドエンジニア2名、自分　←　この構成で４チームほど兼任しておりました。 【課題】 - 独自仕様が多いが、ドキュメントが整備されていないプライベートクラウドでのインフラ構築 - 社内システムで利用しているCI/CD基盤の移行リードおよび利用の浸透促進 - 部門全体に発生していたインフラ業務以外でのリソース不足の解決 【解決策・工夫点】 - まずは、プライベートクラウドの開発部門とのコミュニケーション機会を増やし、気軽にクラウド仕様についてヒアリングができる関係性を築き、詳細な仕様をもとに独自仕様のプライベートクラウドでのインフラ構築をした。ヒアリング内容をもとにユースケースに応じたドキュメントの整備を同時に進行した - 既存システムが利用しているCI/CDパイプラインの構成の洗い出し、他システムへの影響度が低いパイプラインから移行を開始した。その際、既存のパイプラインに組み込みたい処理のヒアリングを実施することで開発業務の効率化を向上させた。最終的にはデータ連携基盤のディザスターリカバリー体制の立案 / 構築 / デモ の実施を行うまでに至った。 - 業務委託のバックエンドエンジニアが複数システムに対応していたため、リソース不足が発生していた。これがボトルネックとなり、作業に遅延が生じていた。一方で、インフラタスクの自動化によってインフラ側のリソースに余裕ができていた。そこで、この余剰リソースを活用し、バックエンド側の軽微な修正やバージョンアップ対応のタスクの巻き取りを実施した。この対応により、バックエンド側のリソース不足が解消され、連携をしていた他部署の作業遅延問題を解決することができた 【成果】 - プライベートクラウドの開発部門と社内システム部門との関係構築を通じて、独自仕様の詳細な把握とドキュメント整備を早急に進行させることができた。この取り組みにより、社内システムの監視基盤移行における技術検証や調査をリードし、移行作業を効率的に実施することができた。 - CI/CDパイプラインの段階的な移行と構築を通じて、手動デプロイの削減と業務委託開発チームの権限最小化を実現した。この過程で、ディザスターリカバリを行うJenkinsジョブの作成を行い、システムのセキュリティと耐障害性を強化した。さらに、新規導入したGitHub Actionsの普及活動として社内勉強会を実施したことで、チーム全体のCI/CD理解度と利用率が向上し、開発プロセス全体の効率化とセキュリティの向上を達成した。 - インフラタスクの自動化によって生まれた余剰リソースを活用し、バックエンド側の軽微な修正やバージョンアップ対応のタスクを引き受けた。具体的には、Airflow DAGのバージョンアップ対応や契約管理システムにおけるファイルコンバートの実装を行えた。この取り組みにより、バックエンド側の知識を得ることができた。自動化の末、他領域の技術キャッチアップを行うことで自身の市場価値の向上ができる事も知ることができた。

【プロジェクト概要】 ■ 基幹系システム(オンプレミス/Azure)の運用保守・監視(オンプレミス:280台、Azure:70~100台) ■ GroupWEBサイト(Azure)の運用保守 【業務内容】 ・Teratermでプロセス確認/疎通確認/リソース使用状況確認、Webブラウザでシステム動作確認を行い、トラブルに対して 暫定対応から恒久対応までを担当。 ・Windowsパッチ適用作業(対象サーバ数:45台 環境:開発/準本番/本番)を毎月実施、関係各所とのスケジュール調整 も担当。ログ収集においてはWSL上でAnsibleを用いたログ収集フローの確立を実施。 ・データセンター入館システム/ジョブ管理システム/ラック解錠システムのアカウント棚卸、監査ログ収集などのITGC全体 統制対応を実施。 ・AzureNSGでのポート穴開け作業やAzureLBの負荷分散設定をシステム要件に基づいて実施。 ・他社パートナーで行っていた運用業務の巻き取りをメイン担当として実施。 ・Azure環境の追加設備費用に対するコスト計算・提案をクライアントへ実施。 ・リソース監視用アラートルールの作成/実績に基づいた整理の実施を行いコスト削減を実現。 ・AutoScaling時の検知・アクションのチューニングを実施。 【業務改善に取り組んだ点】 ・定型業務の自動化をAnsible, シェルスクリプト等を利用して実現。 ・属人化している作業も新規参画者として俯瞰して洗い出し、暗黙知となっている箇所の手順書化を実施。 【工夫したこと】 3つのプロジェクトに並行して携わっていたため、「タスクの優先度決め方法」を工夫してました。 タスク依頼が届いた際、重要度・緊急度に基づいて振り分けを行い、さらに関連タスクの紐付けをして一度にタスク消化す ることを心掛けたことで対応時間の短縮を実現できました。

【プロジェクト概要】 - 目的：全社データ基盤の運用 / 開発、DB移行（ポジション名：SRE） - 自分の役割：データ基盤周りのMW管理およびサーバ運用 / 構築 / 開発 - チーム構成：PdM名、DBRE2名、自分 【課題】 - 分散DBの運用業務（主に障害対応）の属人化解消、SRE文化の導入 - 新規導入されたTiDBのユーザ管理基盤の構築 【解決策・工夫点】 - 属人化され、暗黙知となっているインシデント発生時の対応手順の形式知化を実施。インシデント発生の背景情報から対応手順の整理およびAnsibleでの自動対応に努め、障害対応時の属人化の解消を推進した。 - 社内および子会社向けへ利用促進および販売を実施する TiDB のユーザ管理基盤の改修を担当した。GitHubActionsで実施されていたユーザの管理（作成/削除/テーブルへの紐付け）周りの処理を WEBシステムへ移行。PullRequest限定で受け付けていた申請周りの処理をWEB上での申請に変更したため利用希望者の拡大に繋がった。 【成果】 - 参画して早い時期にインシデント管理やポストモーテムを実施することで "SRE文化" の導入を推進。自身の認知度向上およびチーム内の信頼を得ることができた。属人化の解消を行うことで、チーム全体のリソース比重をプロダクト開発に多く向けることにも成功。導入後、自発的にポストモーテムの実施が行われるチームになれたので本当の意味での導入が完了した - 自分自身、Go言語やTiDBに触れたことはなかったが、0からキャッチアップを実施。もう1名のエンジニアと共にフロント〜バックエンドまでの実装を行うことでWEBシステムやAPI開発の知識と経験を獲得

## プロジェクト概要 本番DBへの分析クエリ集中という構造的課題を解消するため、AuroraからBigQueryへのデータ分析基盤を移行。あわせて、SREプラクティスをAIを活用して組織に自然に浸透させるEnabling体制を構築し、データドリブンかつ自律的なSRE運用モデルを確立しました。 --- ## 役割・体制 ### 自身のポジションと役割 - SREおよびデータ分析担当として、分析基盤の移行・設計をリードしながら、bizサイドや分析担当者との折衝を通じて、健全なデータ活用環境の定着を推進しました。 - SRE Enablingの観点から、開発者が意識せずともSREプラクティスを実践できる仕組みの設計・導入を担いました。AIを活用したSkill開発はその中核であり、属人的な運用からの脱却を組織レベルで推進しました。 - 複数プロダクト（主プロダクト1、副プロダクト2）においてEmbedded SREおよびPlatformエンジニアリングとして横断的に関与し、チーム全体の技術水準の底上げを支援しました。 ### チーム規模と構成 - エンジニア部全体約40名のうち、SREチーム5名で複数プロダクトを横断的に担当。各プロダクトチームと密に連携しながらEnabling活動を展開しました。 --- ## 背景・課題 - 分析クエリが本番DBに直接集中する構造により、DB負荷と分析品質の両面でボトルネックが生じており、根本的な基盤の刷新が必要な状況でした。 - SREの知識やプラクティスは存在していたが、開発現場に自然に浸透する仕組みがなく、SRE担当者への依存が常態化していました。 - アラートノイズの多さとログコストの肥大化により、観測環境自体が信頼性を損なうという逆説的な状況が生まれており、観測基盤そのものの再設計が求められていました。 --- ## 実際の取り組み ### 解決アプローチ **分析基盤の刷新** Aurora → S3 → BigQuery というパイプラインを設計・構築し、本番DBを分析負荷から切り離す構造に転換。Redashのデータソース移行もあわせて推進し、分析環境の一体的な刷新を実現しました。 **SRE Enablingモデルの転換** 「人が教える」モデルから「仕組みが促す」モデルへの転換を目指し、Claude Codeを活用したSkill開発により、監視漏れの自動炙り出しや変更影響の自動調査など、SRE的な判断をワークフローに組み込みました。さらに関連タスクの実施時にSkillが自動発動する仕組みへの改善を進め、開発者が意識せずともSREプラクティスが適用される状態を追求しています。 **観測環境の質的転換** Datadog Anomaly Monitorのチューニングとログ分析の見直しにより、ノイズの多い観測から「意味のある観測」へ再設計。Datadog × GitHub × DevinによるAIエージェントを構築し、未検知エラーへの対応を自律化しました。 **リスク管理の構造的な自動化** EOL検知・脆弱性トリアージ・Terraform変更対応をAIが自律的に処理するワークフローを設計し、定常的なリスク管理コストの構造的な削減を実現しました。 ### アピールポイント - 個々の自動化にとどまらず、「SREが介在しなくても信頼性が維持される組織」という上位目標から逆算して仕組みを設計したことが、本取り組みの本質です。 - AIエージェント化を進める中で、一度構築したワークフローを3ヶ月で見直し再設計した経験もあり、速く作ることよりも正しく捨てる判断を重視する姿勢を持っています。 --- ## 成果・価値 | 項目 | 成果 | |------|------| | アラートノイズ | **80%削減** | | ログコスト | **約50%削減** | | セキュリティ対応・SLO改善工数 | **約70%削減** | | 本番DB負荷 | BigQuery移行により解消 | - 開発者が本質的な問題に集中できる観測環境を整備し、チーム全体の運用品質を向上させました。 - PdMやbizサイドとのデータドリブンな意思決定基盤が整い、プロダクト品質向上とビジネス価値最大化に貢献しました。