na117

## ＃プロジェクト経験概要 データベースのCPU高騰・スロークエリ課題に対し、原因調査からクエリ/インデックス最適化を一気通貫で主導してインフラコスト削減を実現。さらに、改修に伴い必要となった大規模テーブル変更のための深夜メンテナンスにおいて、手順のmake/Runbook化と作業自動化を完遂したプロジェクト。 ## ＃チーム情報 * 役割：インフラ・バックエンドエンジニア（課題特定からメンテ主導まで担当） * チーム構成：開発2名 ## ＃取組内容1：AWS Auroraのスロークエリ分析およびデータベースパフォーマンス最適化 ### 【概要】 スロークエリの徹底分析、複合インデックス設計、およびアプリケーション層の改修によるデータベース負荷の劇的低減とインフラコスト削減 ### 【どのような機能の開発・実装か】 クエリ改修、最適な複合インデックスの設計・適用、不要なデータロード処理のリファクタリング。 ### 【課題・問題点】 データベースのCPU高騰エラーが頻発しており、特定の画面等でUXに関わるほどレスポンスが極めて重く（最大34秒）、UXを著しく損なっていた。また、スパイク的な負荷に伴いサーバー（またはDB）が頻繁にオートスケールし、無駄なクラウドインフラ費用が発生し続けていることも課題であった。 ### 【打ち手・使用した技術】 * AWS Performance Insightsやクエリログを徹底解析し、ボトルネックとなっているスロークエリおよび原因箇所を特定。 * アプリケーション側の不要データ取得処理を削減するとともに、データアクセスパターンに合わせた最適な複合インデックスを追加・検証。 * 使用技術・ツール：AWS Aurora (MySQL), PHP, CakePHP, Performance Insights, Redash, Docker ### 【成果】 * 特定画面のレスポンスを **34sec から 177ms へ劇的に短縮（99.4%削減）**。 * その他重かった主要クエリを数十ms〜数百ms単位へ改善（例: 7.26sec → 222ms [96.9%削減]、240ms → 47ms [80.4%削減]）。 * データベースのCPU高騰を抑え込んだことで過剰なオートスケールを防止し、**クラウド利用費用（インフラコスト）の削減**を実現。 * システム全体の安定運用と快適なUXを両立させた。 ## ＃取組内容2：深夜メンテナンスの主導およびリリース手順の標準化・自動化 ### 【概要】 大規模テーブル変更に伴う深夜メンテナンスの主導、Make/Runbook化による作業標準化およびオペレーションの自動化 ### 【どのような機能の開発・実装か】 スロークエリ改善に伴うDB構造変更やメンテナンス作業において、コマンド一発で実行可能な Makefile / 詳細手順書（Runbook）の作成、およびGitHub Actionsを活用したメンテナンス作業の自動ワークフロー構築。 ### 【課題・問題点】 取組1のスロークエリ改修の過程で大規模テーブルの変更が必要となり、安全な適用のために深夜メンテナンスの実施が必要となった。しかし、当時のメンテ・リリース手順は手動かつ特定個人に属人化しており、オペレーション負荷とリリースミスのリスクが非常に高かった。 ### 【打ち手・使用した技術】 * 事前に緻密なRunbookを作成し、複雑な実行コマンドやメンテナンス切り替え処理を make 化して作業を標準化・簡略化。 * 実行プロセスを makeファイル 等で自動化し、インフラ知識が浅いメンバーでも安全かつ確実に実行できる体制を構築。 * 使用技術・ツール：AWS, GitHub Actions, Makefile, Docker ### 【成果】 * 深夜メンテナンス当日のトラブルゼロを達成し、予定より1時間前倒しで作業を完了。 * 属人化を排除し、誰でも安全に作業を実行できる体制を確立。社内共有セッションを通じてチーム全体にノウハウを展開した。

## ＃プロジェクト経験概要 全6リポジトリのフレームワークおよび言語を最新バージョンまで引き上げるプロジェクトを主導。過去実績と比較して大幅な工数削減を実現するため、AI（Claude Code）を活用した移行プロセスの設計や手順のスキル化（標準化）を推進し、2名体制で安全かつスピーディーに順次アップデートを進行中。 ## ＃チーム情報 * 役割：プロジェクトリード / バックエンドエンジニア * チーム構成：2名（自身含む） ## # 詳細内容 ### 【どのような機能の開発・実装か】 管理画面・Web表示用等を含む全6リポジトリにおける非推奨コードのリファクタリング、ライブラリ依存関係の解決、並びにAIを活用したセルフレビュー・テスト・リリース運用の構築とノウハウのドキュメント化。 ### 【課題・問題点】 EOL（サポート切れ）に伴うセキュリティ・パフォーマンスリスクが存在していた。過去の実績では1リポジトリの移行に2〜3人体制で半年間を要していたため、全6リポジトリの対応を少人数（2名）で達成するには、従来の運用法を抜本的に見直し、作業効率と安全性を飛躍的に高める必要があった。 ### 【打ち手・使用した技術】 * **安全かつ高速な運用プロセスの構築**：PR（プルリクエスト）を小さな単位に分割して安全性を担保。さらにClaude Codeを開発プロセスに組み込み、コード解析、非互換箇所の抽出、セルフレビュー精度向上、および手動テスト項目書作成の自動化・効率化を徹底推進。 * **知見のスキル化・標準化**：バージョンアップの検証手順やAI活用のプロンプト・ノウハウをドキュメント化・体系化（スキル化）。2名体制でも迷いなく作業を並列化・高速化できる再現性の高い移行フレームワークとして定着させた。 * 使用技術・ツール：PHP 8.1 → 8.3, CakePHP 4.3 → 5.4, Docker, GitHub Actions, Claude Code, Notion ### 【成果】 * 全6リポジトリの最新化（PHP 8.3 / CakePHP 5.4）に向けて、2名体制で順次アップデートを進行中。 * 過去「1リポジトリに2〜3人で半年」かかっていたEOL対応に対し、AI活用と移行プロセスのスキル化によって大幅な工数圧縮・スピード向上を実現。 * PR分割とAIを活用したテスト・レビュー自動化により、バグ混入リスクを極小化した安全なリリースプロセスをチームに定着させた。

## ＃プロジェクト経験概要 自社サービスにおける大規模抽選キャンペーンの開催に伴い、同時アクセスに耐えうる抽選基盤の構築から、PdMが毎月手動で行っていた当選者へのギフト送信業務の完全自動化までを主導・実装し、システム安定性と運用効率化を両立したプロジェクト。 ## ＃チーム情報 * 役割：バックエンドエンジニア（主導・設計・実装） * チーム構成：開発4名、PO 1名、デザイナー 1名 ## ＃取組内容1：排他制御と拡張性を考慮した大規模抽選基盤のDB設計・開発 ### 【概要】 大量の同時アクセスに耐える行ロックを用いた排他制御の実装および拡張性の高い抽選ロジック・DB基盤の構築 ### 【どのような機能の開発・実装か】 キャンペーン応募・抽選処理における同時アクセス時のデータ不整合（二重当選等）を防ぐ排他制御機構、および将来的なキャンペーン条件の拡張に対応可能な抽選基盤のDB設計・バックエンド実装。 ### 【課題・問題点】 大規模な抽選キャンペーンの実施にあたり、多数のユーザーが同時にアクセスした際のデータベース整合性の担保が必須であった。また、今後の多様なキャンペーン施策に柔軟に対応できるよう、拡張性の高いシステム構成が求められていた。 ### 【打ち手・使用した技術】 * 行ロック（排他制御）を用いたデータベース処理を実装し、同時アクセスが発生した場合でもデータの不整合や重複当選を確実に防ぐ安全なトランザクション設計を実施。 * 将来的な抽選条件の変更やパラメータ追加に柔軟に対応できるよう、拡張性を担保したスキーマ・クラス構造を設計。 * 使用技術・ツール：PHP 8.2, CakePHP 4.5, AWS (Aurora/RDS), Docker ### 【成果】 * 高負荷・多重リクエストが発生する状況下でもエラーや不整合を起こさない堅牢な抽選システムを構築し、キャンペーンの安定運用を実現。 * 拡張性の高い基盤としたことで、今後の類似キャンペーン開発工数を大幅に抑制できる設計基盤を確立。 * 排他処理の知見を[テックブログ](https://tech.connehito.com/entry/2023/03/17/095312)に公開し、社内LT会で発表。 ## ＃取組内容2：ギフト送信自動化バッチ処理およびデータ可視化基盤の開発 ### 【概要】 Amazon API連携によるギフト送信業務の完全自動化と問い合わせ・運用可視化基盤の構築 ### 【どのような機能の開発・実装か】 Amazon APIと連携した機密データの安全な保持・自動送信バッチロジック、エラー時の自動再実行（リトライ）機構、およびRedashによるデータ可視化機能の開発。 ### 【課題・問題点】 抽選後の当選者へのギフト送信において、PdMが毎月出社して2〜3時間かけて手動運用を行っており、出社負担やヒューマンエラーのリスク、運用工数の増大が大きなボトルネックとなっていた。 ### 【打ち手・使用した技術】 * Amazonの各種ドキュメントを深く解析し、機密データを安全に保持・通信する堅牢なDB設計およびセキュリティ対策を実施。 * 送信エラー発生時にも自動でリトライを行い、障害発生時に安全かつ確実に復旧できるバッチ処理機構を一人で構築。 * Redashを用いて問い合わせ用・送信状況確認用のデータを可視化し、非エンジニアでも簡単に状況把握が行える仕組みを整備。 * 使用技術・ツール：PHP 8.2, CakePHP 4.5, AWS (Aurora/RDS, S3), Redash, Docker ### 【成果】 * 毎月発生していた現場の手動運用工数を完全ゼロ（完全自動化）へ削減。 * PdMの出社義務および手作業によるヒューマンエラーのリスクを完全に解消。 * 開発で得た自動化の知見・技術的工夫を[テックブログ](https://tech.connehito.com/entry/2023/08/10/161434)へ執筆・公開し、社内外へのナレッジ還元にも貢献。

## 概要 所属会社のSES事業にて、予約サービスを運営している企業に常駐し現在も継続中。 4名の開発者、1名のプロジェクトマネージャー、1名のプロダクトオーナーのチームで開発をしている。 4年弱運用されていた予約サイトのリプレイスプロジェクトにアサインされ、API設計、システム設計、開発、テストを担当。 PHP+HTMLというシンプルだが複雑かつ重複の多いプロダクトをLaravel+Vueに置き換える開発者として参画した。 ## 担当領域 - 設計 - 開発 - テスト ## 工夫した点、力を入れた点 ### 業務領域の拡大 当初はコーディング担当として派遣され、開発に期待されていた。 しかし以下のような課題があると感じた。 1. プロジェクトリーダーに業務が集約され、負荷が高い状態になっている 2. 開発者は設計やビジネス理解をする部分がないので、何をどうして作るのかの共通認識が持てていない サービスを開発する上で派遣されていようと目線をビジネスサイドと開発チームで揃え、より迅速に価値あるプロダクトを提供したいという思いから以下のようなアクションを行い、効果につなげられたと考えている。 - 開発者でAPI設計、内部設計を巻き取り、共通認識を持ちながら開発につなげていく - この動きにより、何をどのようにして作るのかという点をチームで持ちながら開発を進めるということができた。 - より仕事を分散させることで、ビジネスに対する理解を均等にするとともに、新たな提案に繋げることができた - 開発者が設計プロセスまで行うことで、スケジュールをより正確な形で見積もることができた。 ### 内部品質の向上 プロジェクト初期から、スケジュールが決められ、そこに間に合わせることにばかり目線がいってしまい内部品質の向上が後回しにされていた。それに対し、内部品質を高く保ち開発後期になっても負荷を減らしたいという思いから以下のようなアクションを行なった。 - コードレビュープロセスの徹底 - コードレビューがなかったところにそのプロセスを追加した。開発者によるコーディングの差異をなくし、ロジックのミスや重複を減らすことができたと考えている。また、導入の際は、コードレビューがないとよりスケジュールが遅れる可能性がある点、保守の難易度が上がる点などを説明しながら取り入れた。 - ユニットテストの追加 - テストコードを書いたことがないメンバーもいたため、重要かつ最低限やりやすいところから始めることでハードルを下げるように心がけた。結果今までテストコードを書いたことがないメンバーも取り入れるようになったこと、同じコードを触る中で共通部分のロジックの変更に気づけるようになった。

社内メンバー（ビジネス、バックオフィス含む）が日々感じているムダや負荷の多い業務の工数を削減しより働きやすくするために、エンジニアリングの力で解決できることはないかと考え自ら一人で立ち上げたプロジェクト。 社員一人一人にヒアリングし、課題を抽出、一覧化。実現可能で効果が大きそうなものに取り組んだ。 とにかくヒアリングからプロトタイプ提供までのリードタイムを短くすることを意識し、より多くの改善をメンバーと二人三脚で達成できるように働きかけた。 ## 取り組んだプロジェクト例 ### SEOランク自動通知ツール開発プロジェクト #### 概要 外部のSEOランク自動取得ツールと社内ツールを連携したプロダクト。 #### どのような機能の開発・実装か ビジネスサイドからの企画を元に進捗管理・要件定義・開発・テスト・リリース・保守全てを担当した。 当初は社内向けのプロダクトであったが、グループ他社から利用したいとの声があり、有償での導入にも成功した。 #### 課題・問題点 自動取得ツールが見づらいということと、毎日変動を追わなくてはいけないのが面倒だった。 #### 打ち手・使用した技術 - SEOランクを社内で利用する優先順位に計算し直すロジックの開発 - SEOの順位がそのまま優先順位として高いわけではなかったため利用者へのヒアリングを繰り返し、その時点で最適だと考えられたロジックを作った - よりユーザーが利用しやすい形での提供 - ユーザーが日々の業務で使用している社内ツールとともに利用することが想定されたため、その社内ツールの1機能として提供した。また、結果をSlackでの確認もできるようにするなど、ユーザーの要望をなるべく取り入れるように心がけた。上記したグループ会社への提供の際は、ロジックを同じにしつつ他の環境を提供することで対応した。 ### 自動レポートツール開発プロジェクト #### 概要 社のクライアント向けレポート作成の工数を削減するための自動レポートツール開発プロジェクト。 #### どのような機能の開発・実装か 開発者2人+プロダクト企画1人。 #### 課題・問題点 営業マンがクライアントへのレポート作成に週5時間ほど繰り返しの手作業をしているという点があった。 この作業時間を削減すべく、要件定義から改善施策企画開発を担当した。 #### 打ち手・使用した技術 - 手作業をなるべく減らす - ビジネスサイドの人との密なコミュニケーションにより、その作成過程を可視化。1つ1つをプロダクトに落とし込んでいくことにより、週5時間かかっていた作業を欲しいレポートに対して1クリックで提供できるようにした。結果、月間20時間ほどの工数を削減できることに成功。 - なるべく早い価値提供 - 複数レポートある中で、1つずつ機能解放していくことにより、少しでも早く価値を感じてもらい、フィードバックを次のレポートに取り入れるという点を心がけた。 このプロジェクトは社内外で評価され、今までは与えられた仕事をこなしていたのに対し自分から行動し達成できたことを嬉しく思い、今後もこのような姿勢で仕事をしていきたいと思えたプロジェクトだった。

## 概要 メイン事業であるアフィリエイトサービスの社内運用を管理するツールの開発PJ。 開発者4人+プロダクト企画1人。 実行環境にGCP、開発環境はdocker、言語はPHP/Laravelを利用したプロダクト。 開発未経験からスタートしたので少しずつ職務範囲を広げていった。 1年目は設計済みの新規機能の実装を担当し、開発からテストまでのプロセスを経験。1年で10機能ほどの開発をメインで担当し、基礎力をつけた。 2年目からは上記の開発に加え保守運用も担当した。主に社内で出てきた要望を集約し適宜、要件定義・設計を行いながら運用を続けた。 3年目から更に業務領域を拡大に挑戦した。当初は開発者は４人いたが私を含め２人に減り、タスク分担など取りまとめをするよう上長から頼まれた。開発部分のみではなくチーム全体の開発フロー整備・PJ全体進捗管理をした。デイリーでの進捗共有及び各開発者の業務を可視化し、よりチームとして動いて開発を進められるように心がけた。 今まで苦手分野であったインフラも慣れるよう調査などを積極的に行い、とあるインシデントにも対応できるようになった。 また、それまでPJに導入されていなかったテストコードを導入するなど、さらに保守性を高めることにも貢献した。