ID:77434さん

プロジェクト概要（目的・人数・体制） - 目的: 研究開発部門のアプリケーション基盤の最適化と運用効率の向上。 - 規模感: チーム構成は6名から始まり、後に2つのスモールチームを編成。 - 自身の役割: チームリーダーとして、技術選定、プロジェクト管理、成果最大化の推進。組織横断的な連携も担当。 当時の背景 R&D部門では基盤構築や運用が属人的になり、非効率な作業やトラブル対応が頻発していた。R&D部門ではアプリケーション基盤を導入したものの、一部のシステムでの利用に留まっていた。部署内には100を超えるシステムが存在しており、それらにも基盤のメリットを広げることが求められていた。しかし、そのためには基盤の有用性を客観的に示し、より多くのチームが採用するための仕組みを整える必要があった。 取り組んだ課題 1. EKS基盤の構築と標準化 - 課題: 基盤が統一されておらず、アプリケーション開発チームごとに異なる環境を利用していたため、運用負荷が高く生産性が低下していた。 - アプローチ: EKSをデファクトスタンダードとして採用し、以下の改善を実施： - Namespaceごとに権限を整理し、セキュリティと運用効率を向上。 - ArgoCD、Workflows、Rolloutsの統合運用を推進。 2. コスト最適化 - 課題: Fargateの利用が広範囲に及び、運用コストが膨らんでいた。 - アプローチ: FargateからEC2への移行をリードし、スポットインスタンスを活用した構成を設計。 - 成果: 年間55,000ドル以上のコスト削減を達成。 3. 負荷試験基盤の導入 - 課題: システム品質が不十分であり、リリース後に障害が発生するリスクが高かった。 - アプローチ: K6を用いて負荷試験基盤を構築し、R&D部門内の12サービスに適用。 - 成果: 全社的な品質向上を実現。 4. Observabilityの強化 - 課題: システム障害時の問題特定に時間がかかり、可観測性が不十分だった。 - アプローチ: MiddlewareやDBにSLOを導入し、異常検知とノイズ削減を実施。 5. チームマネジメント - 課題: チームメンバーの増加に伴い、目標達成のための効率的な運営体制が必要だった。 - アプローチ: - 2つのスモールチームを編成し、チーム単位でKR達成を推進。 - 朝会やドキュメント作業を英語化し、グローバル対応力を強化。 技術的なアプローチや工夫した点 - 技術スタック: AWS（EKS, EC2, CloudWatch）、ArgoCD、Terraform、K6、Istio。 - プロジェクト管理: チーム全体の目標をKPIで可視化し、進捗状況を定期的にレビュー。 成果 - 基盤の統一化: EKSが新規アプリケーションの標準基盤として採用され、年間リリース数が10倍以上に増加。 - コスト削減: FargateからEC2への移行により、年間55,000ドル以上のコストを削減。 - 品質向上: 負荷試験基盤とObservability強化により、障害発生率が低下し、運用効率が向上。 - チーム拡大と成長: メンバー増員やサマーインターン受け入れを通じて、チーム力を向上。新卒1名と海外エンジニア1名の採用を成功させた。 このプロジェクトで発揮したバリュー - 技術リーダーシップ: 新技術の採用と導入プロセスを主導。 - コスト意識: 運用効率とコスト削減を両立した設計。 - マネジメントスキル: チームの成長を促し、個々の成果を最大化。 - 全社的影響: R&D部門全体の基盤利用効率を向上させ、全社的な品質改善と生産性向上に貢献。

プロジェクト概要（目的・人数・体制） - 目的: システムのサーバレス化と運用コストの最適化。 - 規模感: 対象システムは10以上、チーム構成は5名。 - 自身の役割: Knative Serving導入のリード、設計・検証、導入計画の策定。 当時の背景 利用頻度の低い検証環境や非リアルタイムシステムの運用コストが高騰していた。特にアイドル状態でのリソース消費が大きく、効率化が求められていた。 取り組んだ課題 - サーバレス基盤の導入に対する技術的な未経験領域への挑戦。 - レイテンシに敏感でないシステムでの効果的な導入。 技術的なアプローチや工夫した点 - Knative Servingを用いて、Podサイズをゼロにスケール可能な環境を構築。 - Istioを併用し、サービスメッシュを導入して可観測性を向上。 成果 - サーバレス化により年間コストを70%削減。 - スケーラビリティと柔軟性を兼ね備えたシステム運用を実現。

プロジェクト概要（目的・人数・体制） - 目的: Kubernetesクラスタのバージョンアップ効率化とユーザー負荷の軽減。 - 規模感: R&D部門のクラスタを対象、チーム構成は6名。 - 自身の役割: リーダーとして移行戦略の設計・推進、技術選定・実装を主導。 当時の背景 EKSのクラスタバージョンアップに約3ヶ月を要しており、ユーザーや基盤開発チームに大きな負荷がかかっていた。バージョンアップの遅れにより、最新機能の利用やセキュリティ対応に課題が生じていた。 取り組んだ課題 - 移行時のシステムダウンタイムや、ユーザーへの影響を最小限にする必要があった。 - チームのスキルセットを考慮した効率的なプロセスの設計。 技術的なアプローチや工夫した点 - 移行戦略として、ユーザーの影響を軽減する「ブランチ移行戦略」を採用。 - 自動化スクリプトを作成してアップグレードのプロセスを効率化。 成果 - バージョンアップの所要時間を約3ヶ月から4営業日に短縮。 - ユーザーの業務への影響を最小限に抑え、クラスタの安定運用を実現。 - テックブログの執筆 https://buildersbox.corp-sansan.com/entry/2024/05/01/110000

プロジェクト概要（目的・人数・体制） - 目的: 開発生産性の定量的な評価と改善。 - 規模感: チーム3名で推進。 - 自身の役割: GitHubデータの収集システム設計、Four Keysのダッシュボード作成。 当時の背景 開発の進捗や品質が属人的に評価される傾向があり、データに基づいた意思決定が行われていなかった。 取り組んだ課題 - データ収集の自動化と、全社展開のための標準化。 - 各チームに対する分析結果の浸透。 技術的なアプローチや工夫した点 - Looker Studioを用いてFour Keysを可視化。 - GitHub ActionsとBigQueryを連携してリアルタイムでデータを更新。 成果 - データに基づく開発改善の文化を醸成。 - 開発リードタイムやリリース頻度の継続的な改善を実現。