ID:80678さん

### プロジェクト概要 **背景・目的** AI導入が業界全体で進む中、事業部では誰も手を挙げない状況だった。「AI活用で開発体験・開発効率が向上する」という仮説のもと、自らプロジェクトを立ち上げた。目的は、エンジニアの生産性向上と、プロダクト開発の本質的な部分に集中できる環境づくり **規模感・役割** 予算取得から導入、運用まで一気通貫で担当。開発チーム全体（約8名）を対象に、AI活用の仕組み化を推進 **使用技術** GitHub Copilot、Claude、GitHub Actions、Sentry、自社開発のAIボット(Claude Code SDK) ### 取り組んだ課題 **課題：導入しても利用率が上がらない** 当初「エンジニア一人あたりの能力底上げ」を狙ったが、利用率は期待通りに上がらなかった。個人の使い方に依存するアプローチでは限界があると判断 **方針転換：タスク削減による本質的作業へのシフト** AWS移行プロジェクトで培った「仕組み化」の知見を活かし、方針を転換。「個人の能力向上」から「エンジニアのタスクを削り、ユーザー価値向上につながる開発に時間を使える仕組みづくり」へ **技術的アプローチ** - **PRレビュー自動化**：AI によるコードレビュー、CIでの脆弱性チェックを導入し、レビュアーが仕様やアーキテクチャなどプロダクトの本質に集中できる環境を構築 - **仕様問い合わせ自動化**：PDM等からのサービス仕様問い合わせをAIで自動応答する仕組みを構築 - **定型タスク自動化**：軽微な修正タスク、エラー原因調査を自動化 - **段階的導入**：AWS移管で学んだ「一気に変えない」アプローチを適用し、既存フローに自然に組み込む設計 ### 取り組みの成果 - エンジニアが「コードの細かいレビュー」から解放され、仕様議論やアーキテクチャ検討に時間を使える仕組み - PDMからの問い合わせ対応時間削減 - エラー調査時間の短縮により、本質的な開発タスクに集中できる環境を実現 - 最新のAI技術を実用レベルで運用に乗せた実績 - AIモデルのアップデートのみで継続的に品質向上できる拡張性の高い仕組みを構築

### プロジェクト概要 **背景・目的** オンプレミス環境からAWSへの移行指示を受け、単なる移行ではなく「社内エンジニアから選ばれる事業部の開発環境」を目指した。3カ年のモダン化計画を策定し、プロダクト開発と並行で実行 **規模感・役割** 責任者として、移行計画の策定から実行、開発環境の整備、文化醸成まで担当。プロダクト開発チーム（約7名）の開発体験を維持・向上させながらの移行を実現 **使用技術** AWS（EC2、ECS、RDS、S3等）、Fastly、Docker、Terraform、GitHub Actions、Sentry、Datadog、Slack ### 取り組んだ課題 **課題：プロダクト開発を止めずに移行** プロダクト開発タスクと並行で進める必要があり、一気に変えるとリスクが高い。以前のマイクロサービス化で学んだ「計画の柔軟な見直し」の重要性を踏まえ、段階的アプローチを採用 **フェーズ1：リスク最小化の移行** まずオンプレの構成を維持したままAWSに乗せることを優先。安定稼働を確認後、次のステップへ。 **フェーズ2：コンテナ化とモダン化** - **デプロイ自動化**：SSHでサーバに入ってデプロイする環境から、GitHub Actionsによる自動デプロイへ - **プレビュー環境**：検証サーバ払い出しから、画面操作でプレビュー環境を構築できる仕組みへ - **監視基盤**：エラー通知をSentryに集約、DatadogのAPMでパフォーマンス計測を可視化 **フェーズ3：文化の定着** 仕組みだけでなく、運用文化も整備： - エラー管理とパフォーマンス計測の定例確認 - オペレーションログ、ポストモーテムの文化導入 - バージョン最新化、脆弱性対策の継続的実施 ### 取り組みの成果 - 3カ年計画を完遂、サービスのロールバックなしでの移行を実現 - デプロイ時間を6分に短縮 - プレビュー環境構築が手動1日→自動10分に改善 - エラー検知から対応のタスク管理 - パフォーマンス劣化の発見と改善

### プロジェクト概要 **背景・目的** 組織拡大計画に伴い、将来的なスケーラビリティを見据えたマイクロサービス化を推進。サービスの独立性と柔軟性を重視した設計を採用し、3カ年計画で段階的に移行 **規模感・役割** エンジニアとして、アーキテクチャ設計、実装方針の策定、負債解消施策の立案・実行を担当 **使用技術** Ruby on Rails、Go、Docker、MySQL、マイクロサービスアーキテクチャ ### 取り組んだ課題 **課題：事業計画の変更と技術選択のミスマッチ** プロジェクト途中で組織規模の拡大が想定を下回り、当初設計したマイクロサービスアーキテクチャが実態に合わなくなった。独立性を重視した設計が、結果として保守性の課題を生む結果 **課題の認識と分析** - 年単位の固定計画では、事業の変化に追従できない - 技術選択が「将来の想定」に過度に依存し、現状最適ではなかった - サービス間の依存関係整理が不十分で、メンテナンスコストが上昇 ### 取り組みの学び **獲得した知見** この経験から以下の重要な学びを得て、以降のプロジェクト設計思想に反映： - **段階的アプローチの重要性**：大規模な変更は一気に行わず、フェーズを分けて検証 - **定期的な計画見直し**：【四半期/半期】ごとに計画と実態の乖離を検証し、柔軟に軌道修正 - **現状最適の技術選択**：将来予測よりも、現在のプロダクト・組織の状態に最適な選択を優先 - **仕組み化による解決**：属人性を排除し、誰でも運用できる仕組みづくりの重要性 **次プロジェクトへの展開** この知見をAWS移管プロジェクトで実践し、3カ年計画を完遂。さらにAI導入プロジェクトでは「個人の能力に依存しない仕組み化」というアプローチに昇華させ、組織全体の生産性向上を実現