ID:84114さん

### AWS運用改善・保守構築支援 **期間**：2025年11月〜現在 **担当工程**：仕様設計, テスト・QA, 保守運用 #### 概要 進行遅延および品質リスクを抱えた金融系システム開発案件に参画。単なる保守対応に留まらず、運用観点でのシステムテスト再設計、標準化されていない運用プロセスの整備、AWS環境における権限管理・障害対応・保守安定化・セキュリティ統制まで、現場の運用課題を能動的に洗い出し改善へつなげる形で一貫して担当。炎上状態にあった開発後半工程の立て直しおよび本番リリース後の運用体制確立を主導した。 #### 担当業務 - 運用観点でのシステムテスト工程再設計、品質リスク洗い出し - テスト進行管理および後続工程を見据えた標準化対応 - 運用手順／ナレッジ整備による属人化排除 - AWS環境におけるアカウント／権限管理設計、運用案策定 - 障害対応および復旧作業（RDS／EC2／AWS Backup） - 本番リリース後の運用体制設計・整備 - 本番環境の不要リソース棚卸しおよびセキュリティリスク是正提案 #### 思考プロセス - **IAM権限管理の設計判断**：AWSのベストプラクティスに準拠すると金融系の厳格なルール（個人特定・作業証跡の要件）を満たせず、逆に金融ルールを全IAMユーザーに一律適用すると運用が回らないという対立があった。そこで保守担当者と運用担当者で権限モデルを分離する折衷案を設計。保守用の個人名ユーザーはパスワード払出制で金融ルール寄りに、運用用ユーザーは常時ログイン可能だが参照権限のみでベストプラクティス寄りとした。また本番作業用の共有IAMユーザーも案として検討したが、個人特定ができずシステム的な作業者証跡が残らないと判断し不採用とした。単なる技術的な正しさではなく、監査要件を満たせるかを判断基準の軸に据えた - **不要リソース棚卸しからの発見**：サービスイン後の安定稼働フェーズで「不要リソースを削除しましょう」という地味なタスクとして着手。ルートテーブルを一つずつ確認していく中で、IGW・NAT GWが計4つ、実質的な利用者がいない状態で残っていることを発見 - **技術的事実と業務判断の切り分け**：「技術的に削除可能かどうか」と「業務として削除してよいかどうか」は別軸だと考え、あえて結論を急がず整理した。具体的には、SFTP削除と無関係なVPC02側の2リソースは判断を待たず先行撤去可能と提示する一方、VPC01側はSFTP削除の可否・WebAP/Hulftの外部通信要件という業務判断が必要な論点として明確に分離 - **非技術者への伝え方の工夫**：IGWを「建物の正面玄関」、NAT GWを「中から外に出る通用口」に例えるなど、プロパー担当者が構成を知らなくても判断できるよう、専門用語をたとえ話に置き換えて資料化 - **保守用に残す場合のリスク提示**：SFTPサーバーを保守用に残す判断になった場合を見越し、現状の0.0.0.0/0（全許可）のアウトバウンド設定はセキュリティ上望ましくないと判断。TCP/443限定への変更、またはS3 Gateway Endpoint経由への切替という2案を用意し、「残すなら安全な形に変えた上で残す」という選択肢を示した #### 主要実績 ■ 運用観点の整理が必要な工程の立て直し・品質強化 - 停滞していた運用観点のテスト工程を分析し、工数・観点・優先度を再定義して現実的なスケジュールへ再構成 - 既存テストの不足を補い、クリティカル障害に直結する確認観点を追加 → テスト工程を再始動させ、**約3週間**で予定スケジュールへ回復、品質リスクの可視化および低減を実現 ■ 運用標準化および属人性排除 - テストエビデンス、定常作業手順、障害確認手順を整理し、**10件以上**の標準手順書として作業頻度・目的ごとに再利用可能な形へ統一 - AWS（EC2 / RDS / AWS Backup / CloudWatch / CloudTrail）確認手順を抽象度を下げて一本化し、経験の浅いメンバーでも実施可能なナレッジへ再設計 - 誤操作リスクの高い操作について安全な運用範囲を定義 - サービスイン後は課題一覧表と週次定例での確認フローを整備し、属人対応に留めずチーム全体で継続的に改善するサイクルを構築 - 日次の定常運用で必要だった手順書・チェックリスト計6枚の個別印刷作業をPowerShell/batで一括化し、準備の手間を削減 → 作業品質均一化、教育負荷軽減、運用リスク低減を実現 ■ AWS権限管理および運用統制ルール整備 - 障害時連絡経路、作業申請フロー、ID払い出しルールなど未整備であった運用を整理・明文化 - IAMユーザー約20アカウントを含む計約40アカウントを対象に、ベストプラクティス準拠・金融系の厳格なルール準拠・両者のバランスを取った折衷案という3つの運用案を策定 - 関係者へ提案し、折衷案ベースで採用。承認フローを含めた統制運用を設計し、運用負荷とセキュリティ統制の両立を実現 → リリース後の運用混乱を抑制する運用基盤を構築 ■ 本番リリース後の障害対応・保守安定化 - 実データを含む本番環境において、RDS 1台・EC2 2台のリストア対応を影響範囲を考慮のうえ実施し、**約4時間**で復旧を完了 - AWS Backupジョブ異常を調査し、EC2リストアに伴うインスタンスID変更を原因として特定 - バックアップ設定修正および確認手順追加により正常動作を回復、リストア手順へ再発防止観点を反映 → サービスイン直後の運用リスクを早期解消 ■ 不要リソースの棚卸しと業務判断の整理 - 本番環境のIGW・NAT GW計4つについて、ルートテーブル・SG等を横断確認し利用状況を洗い出し - 技術的な削除可否と業務要件としての削除可否を切り分けて整理し、判断ポイントを3点に構造化して提示 - SFTPサーバーを保守用に残す場合のセキュリティリスク（全許可アウトバウンド）を指摘し、改善案を提示 → 判断に迷いがちな「棚卸し」を、事実・選択肢・トレードオフが明確な意思決定資料として整理し、関係者がスムーズに判断できる状態を構築

### 分析基盤構築プロジェクト **期間**：2025年3月〜2025年8月 **担当工程**：要件定義, DB設計, テスト・QA, インフラ構築 #### 概要 AWS新規開発案件でCloudFormationを用いた基盤構築、Lambda・SNS・AWS Chatbot・Amazon Athena等のマネージドサービスを組み合わせた業務自動化基盤およびデータ活用基盤の整備を担当。 #### 担当業務 - CloudFormationを用いたVPC／EC2／CloudTrailログ保管用S3バケット等のAWS環境構築 - LambdaによるS3連携データ処理自動化、SNSおよびAWS Chatbotを用いたSlack通知連携 - IAM実行権限設計および各種ポリシー調整 - Amazon Athenaを用いたデータ抽出基盤整備、テーブル設計、汎用クエリ作成 - CloudFormation管理外リソースのタグ未付与に対する洗い出し・個別付与対応 - 非技術ユーザーとの要件整理およびデータ活用支援 #### 思考プロセス - **タグ未付与リソースの洗い出し**：CloudFormation管理外のリソースは棚卸しの記録が残らないため、放置すると用途不明リソースとして蓄積するリスクがあると判断。ある程度の見当をつけながらも、見落としがあると後の運用に禍根を残すため、約2日かけて慎重に全件確認した。**この「CFn管理外リソースが野良化する」という課題感が、後に個人開発したAWSガバナンス自動化エージェント（TagWatchman）の着想の原点になっている** - **IAM権限設計**：新規構築案件のため、最小権限の原則を最初から設計に組み込む方針を取った。後から絞り込むより、必要な権限を都度追加していく方が事故のリスクを抑えられると判断 - **Athenaクエリ設計**：非技術ユーザーが自走できることをゴールに据え、個別最適なクエリではなく汎用性を意識したクエリ設計とした。都度エンジニアに依頼が発生する状態を避ける狙い #### 主要実績 ■ AWSマネージドサービスを活用した業務自動化基盤構築 - CloudFormationを用いてVPC、EC2、CloudTrailログ保管用S3バケット等のAWS環境を新規構築 - 受領データの構造課題を整理し、LambdaによるS3連携データ処理自動化を実装 - SNSおよびAWS Chatbotを用いたSlack通知連携、IAM実行権限設計も実施 → 手動作業削減、処理再現性向上、運用監視性向上を実現 ■ データ活用基盤の整備 - 非技術ユーザーとの要件整理を実施し、Amazon Athenaを用いたデータ抽出基盤を構築 - 利用しやすさを考慮したテーブル設計および汎用クエリ5本を作成 → **2部署・約30名**がユーザー単独でデータ抽出・分析を行える状態を実現し、業務効率化に寄与 ■ ガバナンス基盤整備（棚卸し対応） - CloudFormation管理外リソースのタグ未付与を全件洗い出し（約2日）、個別にタグ付与を実施 → リソースの用途・管理責任が可視化され、運用時の追跡性を向上