ID:83877さん

### プロジェクト経験概要 保守性が低下していたレガシー自社フレームワーク+EC2構成のふるさと納税ポータルサイトを、Laravel+ECS構成へ全面リアーキテクチャしました。モダンな開発プロセスへの移行が困難になっており、自社フレームワークからの脱却はチーム共通の課題でした。2026年6月に本番リリースを完遂しています。 ### チーム情報 - PM(課長)、アプリケーション担当3名(本人含む)、インフラ担当ほか、計7名 - 役職上の肩書はない対等な体制 - 以下のうち、ジョブキュー・キャッシュの提案、一次レビュー体制の立ち上げ、性能改善、インフラ担当との連携は、私が主体となって進めた部分です ### 開発・実装内容A: 性能問題の計装と検索の高速化 **【概要】** 本番相当データで応答が遅い画面について、計測の仕組みを先に作り、原因を特定してから改善しました。 **【どのような機能の開発・実装か】** - 性能ログへの計装の追加(担当:**自分**) - 約250万件のデータに対する検索処理の改善(担当:**自分**) **【課題・問題点】** - 約250万件のデータに対する検索で、20〜30秒の応答遅延が発生していました - 「体感で速くなった」では改善の判断ができず、修正のたびに効果を比べられる状態がありませんでした **【打ち手・使用した技術】** - 改善に着手する前に、ローカルで定量判定できる状態を作ることを優先し、性能ログにクエリ数・DB I/O比率・実行時間の計測を追加しました(**自分**) - 計測の結果、遅延の原因が `%LIKE%` 検索による全件走査であると特定しました(**自分**) - 改善策はGitHub Copilotに複数の候補を挙げさせ、比較したうえでMySQLのFULLTEXTインデックス導入を私が選定しました(**自分**) - `%LIKE%` の中間一致では通常のインデックスが効かないため、追加費用をかけずにインデックスを効かせられる方法としてFULLTEXTを選びました - Elasticsearchも検討しましたが、新たなサービス利用で費用が発生すること、チームに知見がなく実装に時間がかかりリリースに間に合わないと判断し、見送りました - 日本語検索のためngramパーサを使い、トークンサイズは2に設定しました。既存の `%LIKE%` 検索の挙動にできるだけ近づけるためです - 実行時間ログで、数秒台への改善を確認しています - 同じ計装から、アクセサ経由の処理でEagerLoadの宣言漏れによるN+1を発見し、修正しました(**自分**) ### 開発・実装内容B: Redisジョブキューの導入 **【概要】** 重い処理を非同期化するため、Redisジョブキューの導入を提案し実装しました。 **【どのような機能の開発・実装か】** - ジョブキュー導入の提案(担当:**自分**) - アプリケーション側のジョブ実装(担当:**自分**) - キューワーカー・Redis基盤の構築(担当:**インフラ担当**) **【課題・問題点】** - 画像の保存処理(URLからの画像ダウンロード、画像名のテーブル登録、S3への保存)は時間のかかる処理で、新構成で同期実行するとタイムアウトが問題になると予見していました **【打ち手・使用した技術】** - 他チームのAPI開発でジョブキューの採用実績があることを知っており、本件にも適用できると判断して自ら提案しました - Laravelのキュー機能を使ってジョブを実装し、ワーカーに必要な設定をインフラ担当へ要件として伝えて構築してもらいました ### 開発・実装内容C: 状態の外部化(セッションのRedis化) **【概要】** ECS移行に伴い、ファイルで保持していたセッションをRedisへ移しました。 **【どのような機能の開発・実装か】** - セッションの保存先をファイルからRedisへ変更する処理への組み込みと設定調整(担当:**自分**) - Redis基盤の構築(担当:**インフラ担当**) **【課題・問題点】** - ECSではスケーリングでコンテナが頻繁に入れ替わるため、セッション等の状態をコンテナ内に持てません(チーム共通の認識) **【打ち手・使用した技術】** - LaravelのセッションドライバをRedisへ切り替え、既存処理への組み込みと設定調整を行いました ### 開発・実装内容D: マスターデータのキャッシュ **【概要】** 都道府県・地域情報などのマスターデータのキャッシュ処理を提案し、実装しました(担当:**自分**)。 **【どのような機能の開発・実装か】** - 更新頻度が低いマスターデータをRedisにキャッシュする処理 **【課題・問題点】** - 以前から、Botによる過剰アクセスでDBリソースが高騰することが問題になっていました - 小さな部分でも、削減できるDBアクセスはなくすべきだと考えました **【打ち手・使用した技術】** - 対象は都道府県・地域など、更新されないマスターテーブルに絞りました - 更新がない前提のため、更新時の破棄処理は持たせず、有効期限1か月のシンプルなキャッシュにしています ### 開発・実装内容E: バッチ処理のECSスケジュールタスク移行 **【概要】** EC2上で動いていたバッチ処理を、ECSスケジュールタスクへ移行しました。 **【どのような機能の開発・実装か】** - 各バッチの作成と適用調整(担当:**自分**) - スケジュールタスク自体の構築(担当:**インフラ担当**) **【打ち手・使用した技術】** - 移行に合わせて各バッチを作成し、スケジュールタスク上で動くよう適用調整しました - 各バッチの実行に必要な設定は、インフラ担当へ要件として伝えて構築してもらいました ### 開発・実装内容F: 二段レビュー体制の立ち上げ **【概要】** MRのレビュー滞留を解消するため、一次レビュー担当を引き受けました。 **【どのような機能の開発・実装か】** - MR承認フローの設計(担当:**PM**。私は意見を出す形で参画) - 一次レビュー担当として、二段レビュー体制への変更(担当:**自分**) **【課題・問題点】** - 運用開始後、課長のみがレビューする体制だったため、レビュー待ちの滞留と課長への負荷集中が起きていました **【打ち手・使用した技術】** - 一次レビューを自ら申し出て、一次(私)→最終(課長)の二段体制に改めました - 一次レビューでは、次の3点を重点的に確認しました - 変数名・関数名が規約に沿っているか - N+1などの非効率な処理になっていないか - エラーパターンやエラーハンドリングに不足がないか ### 開発・実装内容G: テストとローカル開発環境・CI **【どのような機能の開発・実装か】** - Unit/Featureテストの骨組み作成(担当:**PM**) - 骨組みに沿ったテストコードの実装(担当:**自分**。GitHub Copilotを活用) - ローカル開発環境のベースイメージ選定、Dockerfile・docker-compose作成(担当:**自分**) - GitLab CIによるビルド〜ECRプッシュのジョブ構築(担当:**自分**) ※ 開発環境の標準化(DevContainer等)は「開発環境の標準化・DX改善」に記載しています

### プロジェクト経験概要 シリアルコード型の新規ふるさと納税サイトと、その管理CMSをゼロから立ち上げました。技術スタックとインフラ構成を白紙から決められる一方、選定を誤ると長期の負債になる局面でした。期間内にリリースを完遂しています。 ### チーム情報 - 課長(PM)と私の2名。2名とも初めて扱う技術スタックだったため、ライブラリ選定や実装ノウハウを相互に共有しながら進めました - インフラ構成は、ECS構築経験のある他部署のインフラ担当と協議 ### 開発・実装内容A: BFF構成の採用 **【どのような機能の開発・実装か】** - フロントエンドNext.js(App Router)+Nginx、バックエンドPHP-FPM+Laravelの分離構成。管理CMSはNginx+PHP-FPM・Laravel(担当:**チーム**。提案は**課長**) **【課題・問題点】** - かねてよりチーム内で、フロントとバックエンドを分離した構成を試したいという話が出ていました **【打ち手・使用した技術】** - 課長の提案をもとに、部長・CTO・インフラ担当へ相談したうえで採用が決まりました ### 開発・実装内容B: Next.jsによるフロントエンド実装 **【どのような機能の開発・実装か】** - サイトのフロントエンド実装(担当:**自分**が比重多く担当。GitHub Copilotを活用) - 主な画面:トップ、商品一覧・詳細、カート、購入(決済処理は対象外)、購入履歴、利用規約、パスワード変更 **【打ち手・使用した技術】** - ブラウザからバックエンドAPIを直接呼ばず、Next.jsを経由してデータを取得するBFFの形を徹底しました ### 開発・実装内容C: 画像ストレージのS3+CloudFront化 **【概要】** CMSとサイトで画像を共有する方式として、EFSを使わない構成を考え、インフラ担当と検討して採用しました。 **【どのような機能の開発・実装か】** - 構成の発案(担当:**自分**) - 構成の検討・構築(担当:**自分+インフラ担当**) **【課題・問題点】** - 他サイトで実績のあるEFSはFargate構成では一般的ですが、コスト面が課題でした **【打ち手・使用した技術】** - 画像キャッシュ用にもともと導入予定だったCloudFrontで、オリジン・ビヘイビア設定によりS3バケットに接続すれば、CMSとサイトで画像を共有しつつEFSを不要にできると考えました - この構成は、後のリアーキテクチャでの静的配信のS3+CloudFront化にもつながりました ### 開発・実装内容D: トークン方式の認証 **【どのような機能の開発・実装か】** - 認証をセッション管理からトークン方式へ変更し、リフレッシュトークンを併用する形で実装(担当:**自分**) **【課題・問題点】** - フロントとバックエンドを分離したBFF構成に合わせて、認証方式を見直す必要がありました **【打ち手・使用した技術】** - Laravel Passportでアクセストークンとリフレッシュトークンを管理しました - トークンはJavaScriptから読めないHttpOnly Cookieに保存し、アクセストークンの有効期限は1時間にしています ### 開発・実装内容E: バッチ実行基盤の検証とインフラ・CI **【どのような機能の開発・実装か】** - Bref+Lambdaでのバッチ実行の検証(担当:**自分**) - ECS構成の初期インフラ策定(担当:**自分+インフラエンジニア**の協議) - ECS構成のTerraformを、AIを活用してプロトタイプとして作成し、インフラ担当へ引き渡し(担当:**自分**。以降の管理は**インフラ担当**) - Dockerfile作成、GitLab CIによるビルド〜ECRプッシュのジョブ構築(担当:**自分**) - バックエンドのLaravel実装(担当:**自分**) **【打ち手・使用した技術】** - Bref+Lambdaを検証した結果、次の2点が運用上の負担になると分かりました - Bref用のファイルをバッチごとに作成・管理する必要がある - Lambdaの実行時間上限(15分)を常に意識する必要がある - この検証結果を、後のリアーキテクチャでECSスケジュールタスクを採用する判断材料にしました

### プロジェクト経験概要 リアーキテクチャで7名の並行開発が始まり、それまで表に出ていなかった環境差異の問題が顕在化しました。個別対応ではなく仕組みで解決するため、環境そのものの配布と、品質チェックのCI化を提案・推進しました。 ### チーム情報 - 提案・構築・定着まで、いずれも**自分**が担当 ### 開発・実装内容A: DevContainerによる環境の統一 **【課題・問題点】** - 各メンバーのローカル(WSL)環境の差異で、コードフォーマッタ(Pint)の設定に不整合が生じていました - 個別に直しても、人が増えるたびに再発する構造でした **【打ち手・使用した技術】** - 環境そのものを配布物にする方針をとり、DevContainerを提案・構築して設定をコンテナ内に統一しました - 新規メンバーの環境構築時間は、約半日から2〜3時間程度に短縮されました(目安) ### 開発・実装内容B: ポート競合の解消 **【課題・問題点】** - ローカル環境でのポート競合が、開発のボトルネックになっていました **【打ち手・使用した技術】** - ポート競合防止ツール「tug」を導入しました - ツールは入れるだけでは定着しないため、勉強会を開いて全メンバーへ浸透させました ### 開発・実装内容C: Pint/PHPStanのCI自動実行 **【課題・問題点】** - フォーマットや静的解析が、各自の注意力に依存していました **【打ち手・使用した技術】** - GitLab CIにPint・PHPStan(レベル4)の自動実行ジョブを追加しました - プッシュ時とマージリクエスト作成時のパイプラインで実行し、警告があればパイプラインが失敗してマージできないようにして、品質チェックをCI段階で強制しています

### プロジェクト経験概要 放送局・鉄道会社・大手コンビニエンスストア・自治体など、複数の運営主体が展開するふるさと納税ポータルサイト/管理CMSの機能開発・保守運用です。 ### チーム情報 - エンジニアは私1名のため、技術面の調査・設計・実装・障害対応の意思決定は一貫して**自分**が担っています ### 開発・実装内容A: 不正検知サービスのAPI連携 **【どのような機能の開発・実装か】** - 注文時の配送先住所・電話番号を外部の判定システムへ連携し、判定結果で処理を分岐させるAPI連携部分(担当:**自分**) **【打ち手・使用した技術】** - 外部APIが遅延・停止したときに返すレスポンスコードを判定し、その場合は注文処理を止める設計にしました ### 開発・実装内容B: 決済機能の追加 **【どのような機能の開発・実装か】** - Amazon Payの追加、3Dセキュア対応(担当:**自分**) **【課題・問題点】** - 決済の途中で外部サイトの画面を経由するため、自サイト内で処理が完結しません **【打ち手・使用した技術】** - 外部サイトへの遷移前後で、どこでトランザクションを区切るかを設計しました - 起こり得るエラーパターンを洗い出して対応しました ### 開発・実装内容C: PHP/MySQLのバージョンアップ **【どのような機能の開発・実装か】** - PHP・MySQLのバージョンアップ対応(担当:**自分**) **【打ち手・使用した技術】** - 公式ドキュメントから、新バージョンで使えなくなった機能を洗い出しました - それらが実際のソースで使われているかを、人による確認とAIによる確認の2重チェックで調べました ### 開発・実装内容D: SVNからGitLabへの移行 **【どのような機能の開発・実装か】** - 移行の主導とブランチ戦略の検討(担当:**課長**。ブランチ戦略は**課長と自分**で検討) - 本番・ステージング環境のソース差異の確認・調整と、開発用ブランチへの反映(担当:**自分**) ### その他の担当 - OEM連携機能の開発、専用LP管理機能の開発(担当:**自分**)

### プロジェクト経験概要 企業運営ポータルサイトの管理CMSを、EC2環境で新規開発しました。部内ではそれまで自社フレームワークのみで開発しており、本案件が部内初のLaravel採用案件です。 ### チーム情報 - プロジェクト全体6名、うちCMS担当2名 - Laravel採用の提案は同僚エンジニア(現・課長)が主導し、私は選定の補佐と開発を担当 ### 開発・実装内容A: Admin-LTEによる管理画面の構築 **【課題・問題点】** - スケジュールが短く、管理画面のUIをスクラッチで作る工数が残っていませんでした **【打ち手・使用した技術】** - 管理画面テンプレートAdmin-LTEの活用を自ら提案しました(担当:**自分**) - UI構築の工数を圧縮し、その分をドメインロジックの実装に充てることで、期間内のリリースを実現しました ### その後への影響 - この案件を起点に、新規サイト開発(BFF構成)やリアーキテクチャでも部内でLaravelが標準的に採用されるようになり、私自身もそれらの案件で中心的に開発を担っています

### プロジェクト経験概要 客先常駐で、AWS/GCP上に構築されたサービスのリソース監視・ログ監視、障害一次対応・エスカレーションに従事しました。 ### チーム情報 - 8名チームのリーダー(**自分**) ### 業務内容A: 監視・障害一次対応 - AWSマネジメントコンソールでのリソース確認、Lambda・CloudShellでのバッチ実行、LinuxサーバへのSSHオペレーション(担当:**自分**) ### 業務内容B: チームリーダー業務 - 障害発生時の指示出し、アラート発生時のメンバーへの対応割り振り、次シフトへの引継ぎ仕様の作成と実施(担当:**自分**) ### 業務内容C: 業務効率化と開発 - 既存Slack Bot(GAS)の改修・保守(担当:**自分**) - Vue.jsを用いた社内教育システム開発への参画(途中参加。中心メンバーの退場後は、保守・機能追加のヒアリングを**自分**が担当) ### 現在の業務へのつながり - 3年間で「障害がどう起き、どう検知されるか」を体で覚えたことが、現在の開発での設計判断(計装の導入、検知可能性を考えた実装)の土台になっています

Claude CodeとOSSのマルチエージェント基盤「multi-agent-shogun」(階層型エージェント構成)をフォークし、自然言語の指示から要件定義→実装→品質チェックまでを自動実行する個人の開発環境として構築・運用しています。動かすだけでなく、運用で起きた問題を仕組みで解決することをテーマにしています。 【運用で直面した課題と工夫】 - 待機中のポーリングによるAPI消費が無視できなかったため、inotifywaitを用いたイベント駆動方式へ変更し、待機コストをゼロ化しました - エージェントの停止や無応答が「静かに」発生して検知できない事象があったため、障害が必ず音を立てるフェイルラウド設計(死活監視と例外時のみの通知)に改めました - エージェントによる意図しないファイル書き込みを防ぐ書き込みガードを導入しました - 承認フローは「可逆な操作は自動進行、不可逆な操作は人間の承認必須」という基準で分岐させています - AIのレビュー指摘は採用/棄却を記録し、委任範囲の判断材料として蓄積しています これらの構築・運用の知見(モデル更新の自動適用をやめて検知だけ自動化した判断、監視スクリプトの誤判定対応など)はZennで継続的に記事化しています。AIへの委任と人間の判断の線引きを、実運用のデータに基づいて改善し続けることがこの取り組みの中核です。

Go言語の学習を目的とした個人開発です。複数の情報源(RSS/GitHub)を定期チェックし、新着を検知・通知する常駐プログラムを、Goの標準ライブラリ中心で開発しています(net/http、encoding/xml、goroutine/channelによる並列fetch、contextによる制御)。 学習の進め方に方針を設けています。業務ではAIコーディングを活用していますが、本プロジェクトでは「AIには解説とコードレビューのみを依頼し、コードはすべて自分で実装する」という制約を課しています。言語の基礎体力は自分の手で書いてしか身につかないと考えているためです。AIのレビュー指摘は採用/棄却を記録しながら進めており、「解説→自力実装→レビュー」のサイクルで学習過程をドキュメント化しています。