ID:29768さん

# プロジェクト概要 自社クレジットカードのイシュアリングを担うシステムの機能開発と運用。カード発行、決済、債権回収機能及び明細管理機能、ユーザー向け、社内管理者向け画面を、複数のスクラムチームでScrum of scrums体制で開発を行っています。 複数チーム全体のスクラムマスター及び、1チームのPdLを担当しています。 # プロジェクトにおける自身の役割 機能開発保守全般を行うと同時に複数チーム全体のスクラムマスターと1チームのPdLを担当しています。 基本は案件ごとに要件定義〜Delivery全てを1チームモブワークで行っていますが、案件によっては私自身がメイン担当者として、あるいは他のメイン担当者のサポートとして、レビュー全般を担っています。 # 当時の背景/抱えていた課題等 現在はScrum of scrumsの形をとっていますが、当初は大人数でスクラムを行っており、スクラムの形骸化やコミュニケーションコストの増加、また1チームで複数案件を取り扱うことによる認知負荷が大きな問題となっていました。 スクラムチームを複数に分割し、かつチームごとに担当するドメインを定義することでコミュニケーションと認知負荷のコストを下げました。 また、スクラムの原理原則の啓蒙を行い、アジリティのあるスクラム運用をすることができるようになりました。 スクラムチームが分割することによるチーム横断のディスコミュニケーションや実装箇所の競合等を防ぐための取り組みも行い、各自が並行して開発ができるようになりました。 # 課題に対して自身が発揮したバリュー及び成果 スクラムマスターとしてチーム分割を主導しました。 並列開発するためのCI/CDフローやルール整備を行いました。 それらの改善と機能開発のアウトプットを出し続けました。

所属する開発チームへFBする目的で、SRE Enablingチームへ3ヶ月間留学し、プロダクトチームのSRE力向上とシステムの信頼性向上に貢献しました。 元々前職での"何でも屋"での経験があり、基本的なインフラ業務のバックグラウンドがありつつも、色々な課題に直面した濃密な時間を過ごすことができました。 「プロダクトチームのSRE力を高める」というEnablingの役割を通じて、単なる技術提供ではなく「プロダクトチームの裁量領域を増やす」ことで事業貢献するというSREの本質を学びました。環境構築、SLO策定、可観測性向上、共通基盤整備を通じて、サービス信頼性を維持する仕組みの提供ができるようになりました。また、アジャイル手法の移行支援などチーム運営にも貢献し、開発経験をSRE # 主な実績 ## SLO策定とモニタリング基盤の構築 - 担当プロダクトのSLO/SLI策定を主導し、可用性・レイテンシ指標をDatadogに実装 - SLO管理用Terraformモジュールを改善し、アラートメッセージに運用シートURLを自動挿入する機能を実装 - Error Budget枯渇時のトラブルシューティング手順を自動化し、運用負荷を軽減 - 複数サービス（マイクロサービス構成含む）のパフォーマンス分析を実施し、SLO目標値を策定 ## 可観測性の向上 - CDNからDatadogへのログ転送基盤を構築し、可用性・レイテンシ監視を実現 - 高負荷サービスの可観測性を大幅に向上 - CDN連携からDatadog統合まで一気通貫で実装 ## 環境構築とEnabling活動 - 複数プロダクトの新規/追加環境構築を実施（staging/本番環境、EKS移行など） - タイトなスケジュールに対応するため本番→staging構築と逆順での実施を提案・実行 - 社内のIaC標準構成を習得し、実装 - プロダクトチーム単独で環境構築できるよう出口戦略を意識したEnablingを実施 ## 共通基盤の整備 - 負荷試験の共通方針を策定し、各プロダクトチームが迷わず実施できる仕組みを構築 - CI/CDパイプライン改善（kubectl認証問題の解決、kustomize動的インストール） - Fluentd設定拡張によるログ収集基盤のS3出力機能実装 ## 日常運用とインシデント対応 - 社内問い合わせチャンネルやアラート通知への日次対応を通じてプロダクトチームとの関係構築 - セキュリティインシデントの初動対応を実施 - 障害通知チャンネルの可視化推進によるインシデント認知改善

# 概要 Google Cloud上にコンソール直入力で作られた既にサービス運用されてるリソース群のIaC化とデリバリーの運用改善をしました。 # 課題 リリースして数年、すでにユーザーもついているサービスで下記の課題がありました。 - 全てのインフラリソースがコンソール直入力で作られており、リソースにまつわるコンテキストがパッと見て不明。 - CDが特定ブランチへのmergeをトリガーとするgit syncを利用しているに関わらず、特にデリバリー手順が確立していなかったので意図に反したリリースがされていた。 # アプローチ - 既存リソースを可能な限りterraformによりIaC化し、Git管理する土台を作成しました。 - デリバリーをtagデプロイに運用変更して運用手順もド確立した。 ## 既存リソースを可能な限りterraformによりIaC化し、Git管理する土台を作成しました。 - 自分自身がスポットメンバーだったので、構築後に自分が関わることができないという事情がありました。そのため残留メンバーでもメンテできるように下記のような取り組みをしました。 - サービスごとにGCPプロジェクトにおける本番、検証環境のサービス境界の分け方が異なったため、それぞれの実態に合わせたterraformのstate構成を作りました。 - GitOpsで変更、承認フローを実現することをモットーとして機密情報も含めて可能な限り全ての設定をGit管理しました。 - その他、カナリアリリースができるようにできるだけ自前共通moduleを使わないなどの工夫をして、効率よりは安全を重視した構築にしました。 ## デリバリーをtagデプロイに運用変更して運用手順もド確立した。 - アプリケーション側のリポジトリでtagデプロイの設定をしました。 - tagデプロイはチームで運用実績がなかったのと、tagデプロイ運用にあたって必要なフィーチャーフラグの導入等のアプリコードへのcommitややブランチ戦略の策定についても行いました。 - さらに上記運用を定着する活動の一環としてドキュメンテーションやレクチャー会など色々行いました。