kmryst

# 歴史上のハンニバルのアルプス越えルートを可視化するWebアプリケーション 歴史上のハンニバルのアルプス越えルートを地図上で可視化するWebアプリケーションを題材に、アプリケーション実装からAWSインフラ、CI/CD、品質ゲート、権限制御、運用ドキュメントまでを一人で設計・構築した個人開発プロジェクトです。 単にWebアプリを作るのではなく、AI Agent / CLI / GitHub UI など複数の経路から変更が入る前提で、変更理由・影響範囲・検証結果・ロールバック手順を追跡できるDevOps基盤を作ることを重視しました。 ## 課題 AI Agentを活用すると実装速度は上がりますが、変更の目的、影響範囲、検証内容、戻し方が曖昧なままPR化されると、人間がレビューしづらくなります。 また、個人開発であっても本番運用を想定する場合、アプリケーションを動かすだけでは不十分で、CI/CD、IaC、権限制御、品質ゲート、デプロイ戦略、ロールバック手順、設計判断の記録が必要だと考えました。 そのため、このプロジェクトでは「アプリケーションを作ること」だけでなく、「変更を安全に流し、失敗時に戻せる状態を作ること」を主なテーマにしました。 ## 工夫したこと Issue / Branch / PR / Label / CI / Docs を前提にした変更管理フローを設計しました。 Issue本文、PR本文、必須ラベル、Conventional Commits、ロールバック記載をGitHub Actionsで検査し、変更の意図や戻し方をレビュー時に確認できるようにしました。AI AgentやCLI経由の変更であっても、実装前の計画、Issueリンク、PR説明、CI結果を通じて、人間が判断できる履歴を残すことを重視しました。 品質面では、Terraform fmt / validate、TFLint、Trivy、Gitleaks、CodeQL、backend / frontend build・test、Docker buildをGitHub Actionsに統合し、IaC、secret、脆弱性、アプリケーションの基本品質を継続的に検査する構成にしました。 Trivy Configの検出結果は、すべてを即時ブロックするのではなく、review signalとして扱い、修正対象、accepted risk、後続検討に分類してIssue化しました。検出結果を単なるエラーとして扱うのではなく、運用上の判断材料として整理することを意識しました。 ## アプリケーション実装 フロントエンドは React / TypeScript / Mapbox GL JS で実装し、ハンニバルの進軍ルートを地図上で表示できるUIを作成しました。 バックエンドは NestJS / GraphQL を使用し、ルート情報をAPI経由で取得できる構成にしました。データ管理には PostgreSQL を使用し、フロントエンド、バックエンド、データベースを含むWebアプリケーションとして一通り動作する構成を実装しました。 このアプリケーションを、DevOps基盤のデプロイ対象として扱うことで、単なるサンプルではなく、実際にCI/CD、AWSインフラ、権限制御、リリース戦略、運用ドキュメントの検証対象になるようにしました。 ## インフラ / CI/CD実装 インフラは Terraform でコード化し、ECS Fargate、ALB、CloudFront、RDS PostgreSQL、S3、Route53、IAM などのAWS基盤を構築しました。 GitHub Actionsから provisioning、deploy、destroy を実行できるようにし、必要なときだけ環境を起動するセルフサービス運用を整備しました。通常停止・必要時起動の運用により、月額コストを約30〜50USDから約5USDまで抑えました。 リリース戦略としては、CodeDeploy による Blue/Green / Canary デプロイを整備し、段階的なリリースと切り戻しを意識した構成にしました。単にデプロイできるだけでなく、失敗時に戻せること、影響範囲を抑えて変更を流せることを重視しました。 権限制御では、GitHub OIDC、用途別IAM Role、Permission Boundary を用いました。PRのterraform plan用Roleと deploy / apply用Roleを分離し、自動化に渡す権限を用途ごとに制御しました。 ## 運用ドキュメント・設計判断 実装だけでなく、設計判断や運用手順を後から追跡できるように、ADR、Runbook、Rollback Plan、IAM設計、GitHub Flow Guardrails などのドキュメントも整備しました。 ADRでは、WAF / GuardDuty などのセキュリティ施策について、用途、コスト、リスク、再検討条件を整理し、単に導入する・しないではなく、accepted risk として判断を記録しました。 Runbookでは、デプロイ、ロールバック、環境起動・停止、障害時の初動など、運用時に必要な手順を確認できるようにしました。Rollback Planでは、リリース失敗時にどのように切り戻すかを明文化しました。 これにより、コードだけでなく、「なぜその設計にしたのか」「どの条件で見直すのか」「失敗時にどう戻すのか」まで含めて、開発・運用の判断を追跡できる状態にしました。 ## 技術記事によるアウトプット Zennでは、terraform-hannibalで実際に設計・実装した内容をもとに、Terraform、GitHub Actions、Dependabot、OIDC / IAM、PR品質ゲート、DevOps運用設計、GitHub Actionsのバージョン管理などに関する技術記事を継続的に発信しています。 単なる学習メモではなく、個人開発で発生した課題、採用した設計、選択しなかった代替案、運用上の注意点を整理し、実装とドキュメントを往復しながらアウトプットしています。 ## 成果 変更の目的、影響範囲、検証結果、ロールバック手順をIssue / PR / CI / Docs上で追跡できる状態にしました。AI Agentを使った開発でも、人間がレビュー可能な単位で変更を確認できるようになっています。 また、AWS環境の起動・停止、デプロイ、品質検査をGitHub Actionsからセルフサービス化し、個人開発でありながら本番想定の開発・運用フローを再現しました。 このプロジェクトを通じて、アプリケーション開発だけでなく、開発チームが安全に変更を流すためのCI/CD、IaC、権限制御、品質ゲート、ADR、Runbook、Rollback Planを含む DevOps / SRE / Platform Engineering 領域の設計力を示せるようにしました。 GitHub: https://github.com/kmryst/terraform-hannibal Zenn: https://zenn.dev/kmryst

# 既存WebシステムのAWS移行およびクラウド基盤構築支援 受託開発チームにて、既存WebシステムのAWS移行およびECS / RDSを中心としたクラウド基盤構築を支援したプロジェクトです。 主な対象は、EC2上で稼働していたWordPress（Bitnami）環境を、ECS Fargateを中心とした構成へ移行するための基盤構築・構成整理・検証支援でした。 ## 課題 既存環境はEC2上で稼働しており、サーバ構成や作業手順が環境に依存しやすい状態でした。AWS上で今後も運用していくためには、ECS / RDS / ALB / EFS / Route53 / IAM / VPC などの構成要素を整理し、再現性のある形で構築・検証できる状態にする必要がありました。 また、移行にあたっては、単にリソースを作成するだけでなく、既存環境との違い、ネットワーク構成、データ永続化、ロードバランシング、名前解決、権限設定などを整理し、チーム内で共有できる形にすることが重要でした。 ## 工夫したこと CloudFormationを用いて、AWSリソースの構成をテンプレート化し、手作業に依存しすぎない構築を意識しました。 ECS / RDS / ALB / EFS / Route53 / IAM / VPC など、アプリケーションをAWS上で動かすために必要な構成要素を分解し、それぞれの役割や依存関係を確認しながら構築・検証を進めました。 特に、コンテナ実行基盤、データベース、ファイル永続化、ロードバランサ、DNS、IAM権限などがどのようにつながるかを意識し、構成情報や作業手順をチーム内で参照しやすい形に整理しました。 ## 担当したこと CloudFormationテンプレートの作成・修正、ECS / RDS環境の構築支援、既存環境からAWS移行するための構成整理・検証支援を担当しました。 また、ALB / EFS / Route53 / IAM / VPC などの周辺構成についても確認し、移行後のAWS環境として必要な構成要素を整理しました。 Dockerを用いたコンテナ化にも関わり、EC2上で動作していたアプリケーションをECS Fargate上で動かすための構成理解と検証を行いました。 ## 成果 ECS / RDSを中心としたAWS基盤構築を支援し、既存環境のAWS移行に向けた構成整理、検証、作業手順の可視化に貢献しました。 この経験を通じて、AWSリソースを単体で扱うだけでなく、アプリケーション、ネットワーク、データベース、ストレージ、権限、名前解決を含めたクラウド基盤全体の構成を理解しながら作業する力を高めました。 また、CloudFormationによるIaC、ECS / RDSを中心としたAWS基盤構築、構成情報・作業手順の整理を経験したことで、現在のTerraform / AWS / GitHub Actionsを用いたDevOps基盤設計にもつながる実務経験になりました。

# 学校向け教員用成績管理ソフトウェアの導入支援・カスタマイズ・保守 学校向けの教員用成績管理ソフトウェアについて、導入支援、初期設定、操作説明、学校ごとのカスタマイズ、導入後の問い合わせ対応、障害対応を担当したプロジェクトです。 教員が日常的に使用する業務システムであり、単にソフトウェアを導入するだけでなく、学校ごとの運用や要望に合わせて設定・カスタマイズし、実際に業務で使える状態にすることが求められました。 ## 課題 学校ごとに成績管理の運用、帳票、入力方法、確認観点が異なっており、同じソフトウェアであっても、そのまま導入するだけでは現場の業務に合わないケースがありました。 また、利用者は教員であり、必ずしもITに詳しい方ばかりではありませんでした。そのため、機能を作る・設定するだけでなく、利用者が迷わず使えるように説明し、問い合わせやトラブルにも対応できる状態を作る必要がありました。 ## 工夫したこと 導入時には、学校ごとの要望や既存の運用を確認し、必要な設定変更やカスタマイズ内容を整理しました。Access / MySQL を用いた環境で、データ構造や画面・帳票の扱いを確認しながら、現場の要望に合わせた調整を行いました。 また、導入時の初期説明やトレーニングでは、利用者の理解度に合わせて説明し、実際の業務でどのように使うかを意識して案内しました。問い合わせ対応や障害対応では、発生している事象、再現条件、影響範囲を整理し、原因調査と復旧対応を行いました。 ## 担当したこと 新規顧客である学校への導入作業、初期設定、操作説明、トレーニングを担当しました。 学校ごとの要望に応じたカスタマイズ、設定変更、導入後の問い合わせ対応、エラー対応、トラブルシューティングも行いました。Windows、Access、MySQL を使用し、業務システムの導入から保守まで一連の流れを経験しました。 ## 成果 学校ごとの業務要件を整理し、成績管理ソフトウェアを実際の運用に乗せるための導入・カスタマイズ・保守に貢献しました。 この経験を通じて、技術的な実装だけでなく、利用者の業務を理解し、要望を整理し、運用に落とし込むことの重要性を学びました。 現在取り組んでいる DevOps / SRE / Platform Engineering 領域でも、単に技術を導入するだけでなく、利用者である開発チームが実際に使える形に整えることを重視しており、この経験はその土台になっています。

# 給与計算アウトソーシング事業の基幹システム運用・保守 給与計算アウトソーシング事業の基幹システムについて、運用・保守、社内IT対応、定期メンテナンス、バックアップ作業、障害時の原因調査・復旧対応を担当したプロジェクトです。 現在のDevOps / SRE領域で重視している「安定運用」「障害時の復旧」「手順化」「運用負荷の低減」につながる、初期のインフラ運用経験です。 ## 課題 給与計算アウトソーシング事業の基幹システムは、業務継続性が重要なシステムであり、日常的な安定稼働、定期的なバックアップ、障害発生時の復旧対応が求められる環境でした。 また、社内PCやサーバの月次メンテナンス、社内ITシステムのトラブル対応も含まれており、単に決められた作業を行うだけでなく、業務影響を考えながら優先度を判断する必要がありました。 ## 工夫したこと 定期バックアップや月次メンテナンスでは、作業漏れや確認漏れが起きないよう、手順と確認観点を意識して対応しました。 障害や問い合わせ対応では、発生している事象、影響範囲、再現条件、復旧に必要な作業を整理しながら原因調査を進めました。業務システムでは、技術的な復旧だけでなく、利用者への影響を抑えることも重要だったため、安定稼働と業務継続を意識して対応しました。 また、データセンターでの定期バックアップ作業を継続的に担当し、システム運用におけるバックアップ、復旧性、作業手順の重要性を実務として経験しました。 ## 担当したこと 基幹システムの運用監視、保守作業、全社PC・サーバの月次メンテナンス、社内ITシステムのトラブル対応を担当しました。 また、データセンターでの定期バックアップ作業、障害発生時の原因調査、復旧作業にも携わりました。Windows環境、Oracle、DB2を利用する業務システムにおいて、運用作業と障害対応を経験しました。 ## 成果 基幹システムの安定稼働を支える運用・保守メンバーとして、日常運用、バックアップ、メンテナンス、障害対応に貢献しました。 この経験を通じて、システムは作って終わりではなく、運用、監視、バックアップ、障害対応、手順化まで含めて継続的に支える必要があることを学びました。 現在取り組んでいるTerraform / AWS / GitHub Actions / Runbook / Rollback Plan を用いたDevOps基盤設計においても、このときの運用経験を土台に、失敗時に戻せること、作業手順を明文化すること、安定運用を前提に設計することを重視しています。

# 医療システム電子化プロジェクト 医療システムの電子化プロジェクトにて、開発環境の構築、環境設定、各種ドキュメント作成、テスト支援、バグ再現・検証、品質管理を担当しました。 ## 担当したこと 仕様書、手順書、操作マニュアルなどの各種ドキュメント作成・更新を担当しました。 また、Windows Server、VMware、Oracle、COBOL、Cisco を利用する環境で、開発環境の構築、環境設定、テスト仕様書作成補助、テスト実施、バグ再現・検証を行いました。 ## 成果 医療系の業務システムを電子化するプロジェクトにおいて、開発・検証・品質管理を支える作業に携わりました。 この経験を通じて、業務影響の大きいシステムでは、実装だけでなく、環境構築、手順書、操作マニュアル、テスト、品質確認まで含めて整備することの重要性を学びました。 現在取り組んでいる DevOps / SRE 領域でも、環境構築の再現性、作業手順の明文化、検証可能な変更管理を重視しており、このときの経験が土台になっています。