千葉に帰り亭

# プロジェクト概要 自社サービスである「文章の自動照合・校正Webアプリ」の開発・運用を担当。バックエンド・フロントエンド・AWSインフラを横断し、直近では特にAWSを活用した運用改善・自動化基盤の構築に貢献。 ## チーム情報 20名 PO1名、PM1名、CS4名、エンジニア7名、デザイナー1名　他 ## 担当業務 - Spring Boot を用いたAPI開発・改修 - AWS（Lambda／S3／CloudWatch／IAM／CodePipeline等）の構築運用 - CloudWatch Logsの監視ルール整備、Lambdaを用いたアラート改善 - デプロイフロー自動化（S3トリガー → CodePipeline） - インシデント初動ルール策定。テンプレート化 - （特にテックリード期間）技術相談、コードレビュー、タスク分解 # 実績・取り組みなど ## ▼CloudWatch→Slack 通知自動化 ### 課題 従来のメールを用いたエラー通知では「メールを見る機会が減ったため気づかない」、 またデフォルトの設定のままだったため「内容が英語な上に、リンクをクリックしてAWSアカウントにログインしないとエラー内容が分からない」といった問題があり エラーへの初期対応が遅れた結果、インシデントに繋がったシーンが発生した。 ### 工夫 費用を抑えて最低限のサービスで構築したく、AWS Lambda(ランタイム：Python)を用いることに決定。 ``` mermaid graph LR; A[CloudWatch Logs で<br>ERROR 発生] --> B[サブスクリプション<br>フィルターが発火]; B --> C[Lambdaで内容を整形し<br>Slack Webhookを叩く]; C --> D[Slackチャンネルに<br>通知が届く]; ``` エラーの発生した環境やエラー文のはじめ3行だけを抽出し、 Slackに詳細情報を送る仕組みを要件定義～リリースまで全て主担当として実施。 ### 成果 - エラー検知→初期対応速度：30分→3分に改善 - インシデント数の減少に貢献 - Slack上で対応状況が共有されるようになり、二重対応を防止 - 「本番環境のadmin権限ログイン検知」にも応用し、セキュリティを強化 ### 参考URL この取り組みを自分なりに改善したものを、以下URLに載せています。 - Github：https://github.com/amomo0220/aws-automation-templates/tree/main/cloudwatch-to-slack-notifier - Qiita記事：https://qiita.com/return_chiba/items/2600e6f7c8922d6e0dd1 ## ▼S3アップロードを起点としたCodePipeline自動デプロイ化 ### 課題 権利・契約の関係上、Githubにて管理できないプロジェクトに関して 今までzipで受け取ったソースコードを、デプロイ方法を知っているエンジニアが30分かけ、手動でデプロイしていた。 その「属人化」によって、以下の課題が発生していた。 - そのエンジニアが休暇中等にはデプロイができない - そのエンジニアのタスクが増える - 手作業のため、ミスが発生することもあった ### 工夫 まずは、そのエンジニアのデプロイ作業を観察し、方法を手順書に落とし込んだ。 手順書にすることで、他のプロジェクトのソースコードデプロイにも使用していて慣れている CodePipelineにてデプロイができそうなことが判明。 zipで受け取るというルールはそのままに、 S3にソースコードを置くと自動でデプロイされ、デプロイが完了（または失敗）したらSlackに通知を送る仕組みを、要件定義から構築まで担当した。 ### 成果 - 属人化が解消され、エンジニア全員がデプロイ可能に - 手作業が30分→（zipをS3に配置する）3分に改善 - 手作業によるミスの防止に寄与 ## ▼インシデント対応フローのテンプレート化（初報速度：30分→5分に改善） ### 課題 インシデント対応時のフローが存在しなかったため、インシデント発生時に調査を優先してしまい、 ユーザーや上長への報告が遅れてしまうことがあった。 また、インシデント発生時に対応するメンバーが属人化しており、対応経験がないメンバーは何をするのが良いか分からず指示待ちになってしまった。 ###工夫 曖昧だった対応フローを、エンジニア、PM、上長それぞれにヒアリングしながら整理し、 手順のテンプレートを作成。 さらに、そのときに手に入れた情報をもとに 上長やPMに一斉に報告できる「インシデント第一報フォーム」の作成をエンジニアに依頼。 第一に何を報告しなければならないか、報告する宛先は誰なのかが自動で用意されるようになった。 ### 成果 - 属人化が解消されたことによるメンバーの負担軽減 - インシデント発生から第一報まで、それまで30分以上かかっていたところ、5分に短縮 ## ▼テックリード経験 指名を受け約半年間、テックリードを経験。 ### 工夫 - エンジニアそれぞれの得意分野やタスクの量を把握していたため、他のポジションとエンジニアを繋ぐ窓口になった - 大きな課題が発生した際、タスク分解しチケットに落とし込み、できるだけスプリントを跨がず実装→リリースが出来るよう貢献 - 特に初心者エンジニアに対して、コードレビューをする文化を作った ### 成果 案件の都合上、テックリード経験は半年に終わったものの、 その後根付いた「プルリクエスト文化」の土台を作ることに成功。

# 概要：「背番号フラッシュ暗算」とは 「プロ野球選手の顔写真と背番号を使って暗算に挑戦する」企画。 プロ野球の試合の途中で開催される「ファン参加型対抗企画」として千葉ロッテマリーンズが発案。 1. チームA・チームBの選手が1秒ごとに交互に、計6名分、表示される 2. 「6人分の背番号の合計」を素早く(10秒以内に)暗算して答える こちらの企画（本番）を再現したwebアプリを開発した。 ## （課題）なぜ「背番号フラッシュ暗算」練習アプリを作成したのか - 家族が、この企画に出場することになったため - しかし、企画開催までに残された期間は1週間…本番を想定した練習がしたかった - AWSを業務外でも活用したかったため（AWS学習のアウトプット） # 工夫 ## 基本機能はウォーターフォールを、機能改善はアジャイルを意識して開発 0.5日でウォーターフォール開発を意識しながら基本機能を構築し、家族に公開。 その後1.5日はアジャイル開発を意識し、レビューをもらいながら、機能改善や応用機能、オマケ機能を実装。 ## AWSのサービスを用いてサーバレスに構築 費用は抑えつつ、迅速なデリバリーが可能に。 # 成果 - 迅速にデリバリーできたため、出場するまでの間に練習する時間を多めに設けられた。 - 本番を再現したアプリで、正答率を（アプリ公開時）20%→75%に増加。 - 本番、球場にて、家族は見事に正解。 - 以下のようなフィードバックをもらった。 > 「助かった。思い出しているようでは勝ち目は無いので、 > 　このアプリでまるで**本番のように**“写真を見て1秒以内に瞬時に背番号を浮かべ暗算”が**実践できる**のは大きい。 > 　アプリのおかげで短期間でここまで仕上がった」 # 参考URL この取り組みは、以下でも公開しております。 - Github：https://github.com/amomo0220/pub_baseball-flash-math-2025 - Qiita記事：https://qiita.com/return_chiba/items/bbe768502f99c01db4e8