すずき

## ■ プロジェクト名 ECS向けCI/CDパイプライン再設計 --- ## ■ CI/CDパイプライン設計・構築 ECS環境におけるCI/CDパイプラインの再設計を担当。Build Once, Deploy Manyの思想をベースに、ビルドとデプロイの責務分離およびartifact管理方式の見直しを実施。 --- ## ■ 役割 リード / レビュアー --- ## ■ 技術スタック AWS（ECS / CodePipeline / S3 / Parameter Store ）、CI/CDパイプライン設計 --- ## ■ プロジェクト詳細 既存のCI/CDパイプラインは設計が曖昧なまま構築されており、ビルドとデプロイの責務が分離されていない状態であった。その結果、環境ごとに成果物が変化し得る構成となっており、再現性や一貫性が担保されていない課題があった。 これに対し、Build Once, Deploy Manyの思想に基づきパイプラインを再設計。ビルドは一度のみ実行し、生成したartifactを各環境に昇格させる構成へ変更した。artifactはS3で管理し、Version IDにより一意識別することで、同一成果物の再利用と環境差異の排除を実現した。 さらに、デプロイ時にVersion IDを選択する方式を導入し、手動操作によるミス防止とトレーサビリティを確保。不要なsource同期処理を削除し、artifactベースのデプロイに統一した。 これにより、artifactの一意管理とビルド・デプロイの責務分離を実現し、再現性と安全性の高いデプロイ基盤を構築した。とで、同一成果物の再利用を可能とし、環境差異の排除を実現した。 --- ## ■ 課題と工夫 課題は、環境ごとに成果物が変化し得る構成により、再現性や一貫性が担保されていなかった点である。 工夫として、ツール仕様に依存せず設計思想を優先し、Build Once, Deploy Manyを軸に再設計を実施した。また、従来のstagingブランチを廃止し、検証をブランチではなくデプロイで行うフローに変更することで、構成のシンプル化と責務の明確化を図った。 --- ## ■ 成果 - ビルドの一意性および再現性を担保 - 環境間の差異を排除し、デプロイの一貫性を向上 - 手動操作削減によるヒューマンエラー防止 - デプロイフローの簡素化と運用性の向上

### ■ プロジェクト概要 社内アプリケーションのデプロイパイプライン構築および、既存Terraform構成のリファクタリングを実施。 従来の手動デプロイフローをCodePipeline上に再現し、自動化と標準化を行った。 背景として、他開発者が進めていたパイプライン構築が納期逼迫により引き継ぎとなり、不足していた設計の補完および再設計が必要な状態であった。 --- ### ■ 役割 設計・実装・検証まで一貫して担当。 既存設計の意図を踏まえつつ、不足している要件の洗い出しと再設計を主導。 --- ### ■ 課題（Before） - デプロイフローに必要な処理・コマンドが整理されておらず、パイプラインとして成立していなかった - アプリケーションコードとパイプライン定義が同一ブランチに混在しており、パイプラインとアプリケーションのリリースを分離できない構造となっていた - Terraform構成が整理されておらず、環境ごとのリソース定義が混在（例：across/conversion-api/dev など）し、可読性・保守性が低い状態 - 手動デプロイ前提のフローであり、再現性・一貫性が担保されていなかった --- ### ■ 施策・設計（What & How） - 既存の手動デプロイフローを分解し、必要な処理を整理した上でCodePipeline上に再構築 - パイプライン定義とアプリケーションコードを分離し、リリース単位を明確化 - cherry-pickを活用し、ブランチ間の関心の分離を担保 - Terraform構成を見直し、environments/dev・prod・across のように環境単位でディレクトリを整理し、責務を明確化 - 既存実装の意図を尊重しつつ、不要な変更を避けた段階的リファクタリングを実施 --- ### ■ 工夫・意思決定 - 利用者（開発者）がデプロイフローを意識せずに利用できることを重視し、**「コードマージ＝デプロイ」**となるシンプルな構成を採用 - 設計過多による運用負荷増大を避け、必要十分なCI/CD構成に留めた - 既存構成を全面的に作り直すのではなく、意図を汲み取りつつ改善することで、リスクを抑えた移行を実現 --- ### ■ 成果（After） - デプロイフローが標準化され、手動作業に依存しない運用が可能となった - パイプラインとアプリケーションのリリースが分離され、変更影響範囲が明確化 - Terraform構成の整理により、環境ごとの差異が明確になり、保守性が向上 - デプロイの再現性および一貫性が向上し、安全性の高いリリース運用を実現 --- ### ■ 使用技術 - AWS CodePipeline - Terraform

### ■ プロジェクト概要 ビジネスサイドが本番データベースへ安全にクエリ実行できるよう、プロキシサーバーを構築。 従来バージニアリージョンに配置していた参照用DBを廃止し、東京リージョンの本番DBへ安全に接続可能な構成へ移行した。 背景として、コスト削減のためバージニアリージョンのDBを撤去する必要があり、代替としてセキュアなアクセス経路の設計が求められた。 --- ### ■ 役割 要件定義、設計、実装、切り替えまで一貫して担当。 利用者（ビジネスサイド約15名）の運用影響を考慮し、既存利用フローを維持したまま移行を実施。 --- ### ■ 課題（Before） - レポート用途のDBがパブリックに配置されており、セキュリティリスクが高い状態 - クロスリージョン（東京→バージニア）構成により、不要なインフラコストが発生 - 本番DBはプライベート配置であり、GASやBIツールから直接安全に接続する手段が存在しない - クエリ実行経路が複数に分散しており、アクセス制御や接続管理が統一されていなかった --- ### ■ 施策・設計（What & How） - ECS Fargate上にプロキシサーバーを構築し、NLB経由で外部クライアントからの接続を集約 - 本番DB（プライベートサブネット）への接続経路をプロキシ経由に統一 - セキュリティグループにてBIツールごとのIPレンジをPrefix Listで管理し、接続元を制限 - Lambda（GAS連携用）には固定IP（EIP）を付与し、アクセス元を明確化 - プロキシサーバーは443ポートのみ許可し、通信経路を限定 - 利用者は従来通りのクライアント操作で、READ権限によるクエリ実行が可能な構成とした --- ### ■ 工夫・意思決定 - Googleサービス（GAS / Looker Studio）のIPレンジをPrefix Listで管理し、動的IPに対してもセキュアな制御を実現 - Lambda経由のアクセスはEIP固定とすることで、セキュリティグループによる厳密な制御を可能にした - Fargateを採用し、OS管理不要とすることで運用負荷を削減 - プロキシサーバーをスケジュール起動（7:00〜2:00）とし、利用時間帯に限定してコスト最適化 - 移行期間中はバージニアDBへのフォールバック経路を残し、段階的に切り替えを実施 --- ### ■ 成果（After） - バージニアリージョンのDBおよび関連リソースを削除し、月額約850ドルのコスト削減を実現 - パブリック公開されていたDBを廃止し、セキュリティを大幅に改善 - アクセス経路をプロキシに集約することで、接続制御および運用管理を一元化 - 利用者の操作フローを変更することなく、安全なクエリ実行環境を提供 --- ### ■ 使用技術 - AWS（ECS Fargate, NLB, Lambda, API Gateway, Step Functions, S3） - GAS（Google Apps Script） - Looker Studio

### ■ 役割 - プロジェクト推進（OKR運用設計・合意形成・ファシリテーション） --- ### ■ 概要 OKR運用の立ち上げにあたり、目的や運用イメージの認識が揃っていない状態に対し、 定義整理および合意形成をリードし、継続的に改善可能な運用体制を構築。 --- ### ■ 背景・課題 - OKRの目的・運用イメージがチーム内で共有されていない状態 - 議論の前提やゴールが不明確で、合意形成が進みにくい状況 - ファシリテーションおよび運用設計の役割が不在 --- ### ■ 施策・設計 - OKRの目的・ゴール・評価観点を整理し、議論の前提を定義 - MTG前に論点およびゴールを明示し、議論の方向性を設計 - Figmaを用いた付箋ベースの可視化により、抽象的な議論を具体化 - 初期段階では完全定義を目指さず、レトロスペクティブ前提で改善可能な運用を設計 --- ### ■ 工夫・意思決定 - 実運用を前提に、再現性・運用負荷・継続性の観点で意思決定を実施 - 意見が出にくい状況に対し、具体案を提示しながら違和感ベースでフィードバックを引き出す形で議論を推進 - 想定されるボトルネック（運用負荷・責務分担）を先回りして提示し、意思決定の質を担保 - すべてを事前に決め切るのではなく、改善サイクルを回す前提で設計 --- ### ■ 成果 - OKRに関する共通認識を形成し、合意形成プロセスを確立 - 定期的な振り返りを前提とした改善サイクルが回る状態を実現 - 進捗共有に留まらず、改善アクションに繋がる運用へ転換