ID:34925さん

EMとして10名規模（iOS／Webフロント／API・バックエンド）のエンジニアグループをマネジメント。技術力だけでなくプロダクト成長を共に考え、より高い価値を提供できるエンジニアの育成を目的に、開発生産性の定義と改善に取り組んだ。

エンジニアの育成責任を担い、その中で目指す姿を自ら定義した。単に技術を磨くだけではなく、プロダクトのWhy・Whatを主体的に考え、ユーザーとプロダクト双方に価値を提供できるエンジニア集団へと成長させることを責務とした。 このため、日々のタスク消化に留まらず、プロダクトの背景や目的を理解し、自ら改善や提案を行える状態をチームに根付かせることを重視した。

# 背景と考え方 エンジニアリングマネージャーとして育成責任を担った際、単に技術力を高めるだけでなく、エンジニア自身が「プロダクトのWhy・What」を理解し、価値提供に主体的に関われる状態を目指しました。そのために「開発生産性を定義・可視化し、自律的に改善できるチーム」を作ることを重点施策としました。 # 課題 - 生産性の定義が曖昧で、改善活動が属人的・一過性に留まっていた - QAテスト段階で不具合が多発し、開発〜リリースのサイクルが遅延 - 改善活動が「追加の負担」と捉えられやすく、継続性が課題 # 施策と工夫 1. **開発生産性の定義と可視化** - DevOpsのFour Keys（デプロイ頻度、リードタイム、変更障害率、平均修復時間）をベースに指標を設定 - Findy Team+ を導入し、コミット〜マージ、レビュー時間、PR差分量などを定量的に可視化 2. **改善文化の定着** - Slack自動通知やダッシュボードを整備し、日常的に数値を確認 - スプリントレビューで数値を元に改善アクションを議論し、改善を「日常業務の一部」として定着 3. **プロダクト志向の醸成** - 機能開発時に「この機能はどのKPIに寄与するのか」を全員で確認 - エンジニアがWhy・Whatを理解した上でHowを考える仕組みに転換 # 障害と対応 - メンバー間の温度差に対しては、「数値は評価のためではなく課題共有のため」と繰り返し伝え、心理的安全性を確保 - 事業サイドからの短期成果圧力には、中長期での改善ロードマップを提示し合意形成 - 改善活動が形骸化しないよう、必ず「数値→課題→アクション」まで落とし込む運用を徹底 # 成果（数値改善） - **デプロイ頻度：約2倍向上**（1.5件/週 → 3.0件/週） - **変更のリードタイム：約1.5倍短縮**（105.4h → 64.4h） - **QAテストでの不具合検知数：38件 → 2件に大幅減少** - **PR差分量：920.8行 → 205.4行** に削減 - 結果としてリリースサイクルの高速化と品質安定を実現し、Findy Team+ Award 2025を受賞 # 今後の展望 現在は、MCPやAIクライアントを活用したLLMベースの開発環境を整備中。単純作業の効率化を進め、エンジニアがプロダクトのWhy・Whatに集中できる状態をさらに強化し、組織全体の「開発効率 × プロダクト価値創造」を両立させることを目指しています。