チームでリファクタリングを進めるために

チームでリファクタリングを進めるためにチームと個人のリファクタリング実践談 / 関ジャバ'25 9月度 1

今日お話しすること感じていた課題：なぜチームでリファクタリングが進まないのか試行錯誤の経緯：技術的アプローチから責任範囲明確化へ転換点：責任範囲を明確化したら何が変わったか実践方法：やったことと各チームへの働きかけ学んだこと：チームでリファクタリングを進めるコツ 2

感じていた課題：なぜチームでリファクタリング含めた改善活動が進まないのかみんな改善が必要であるという認識しているが、実際には後回し「誰かがやるだろう」の心理で主体性が欠如既に複雑化したコード：積み重ねで複雑化していて触りづらい責任の曖昧さ：全チームが全サービスを触る体制継続性の欠如：プロジェクト毎に触るコンテキストが変わるので、習熟しづらい調整の複雑さ：他チームとのコンフリクトで改善が発生しやすく調整が面倒 3

試行錯誤の経緯：技術的アプローチから責任範囲明確化へ最初は技術的なアプローチを試した（約1年間） 1. 危機感の共有：責任者への継続的な問題提起（2023年下期） 2. 専門チーム立ち上げ：若手中心の技術負債返済チーム（2023年下期） 3. 限定的な成果：少しの改善はできたが根本解決に至らず（2023年下期） 4. 専門家参加：イベントストーミングでコンテキスト再整理（2024年上期）
4

試行錯誤の経緯：理想と現実のギャップ理想的な設計の限界（2024年下期）イベントストーミングで完璧なコンテキスト分割を設計しましたが、既存システムや製品開発プロセスとの整合性が取れませんでした。製品責任者・本部長への説明：「このレベルでのリファクタ/リアーキテクトは費用対効果が合わない」原点回帰：「何がしたかったのか」を再考問い直し：完璧な技術的解決が本当の目的だったか？本来の目的：技術負債解決、主体的改善文化の醸成
気づき：責任範囲の明確化だけでも効果があるのでは？ 5

転換点：責任範囲を明確化したら何が変わったか変更内容 Before：管理OS割り≒プロジェクト割り（全チームが全サービス） After：コンテキスト割り（各チームが担当領域を明確に持つ）各チームにコードリポジトリ単位で割り振りまで実施狙い各チームが「自分たちの領域」として継続的に責任を持つ 6

実施にあたって上層部への説明：数値で効果を示した説明内容製品責任者・本部長に対して：定量的効果：Four Keysなどの指標で「2年後にはコストをペイできる改善効果」定性的効果：「属人化解消（強い人依存→チーム依存）の重要性」 7

効果：半年で見えてきた変化（2025年上期）主体性の変化以前：上から指示されない限り改善しない現在：各チームが自主的に改善計画を立てて実行技術的改善の活性化ライブラリアップデート：各チームが積極的に実施パフォーマンス改善：応答時間・コスト削減を自主的に変更容易性向上：保守しやすいコード構造への改善構造的リファクタリング（進行中）リポジトリの統廃合：分割されすぎたものの統合・巨大すぎるものの適切な分割
アーキテクチャ改善：レイヤード構造への整理 8

効果：知識共有文化の醸成教育・知識委譲の成果ドキュメント整備：各チームが責任範囲を明文化継続的学習：チーム主導での改善活動スキル向上：チーム内での技術力底上げ「やらされ感」から「やりたい感」への変化コンテキストの改善活動が個人の目標にも組み込まれるように 9

具体的にやったこと 1. 責任範囲の可視化担当コンテキストの明確化：どのサービス・機能を担当するかコードリポジトリ単位でしっかり割り振りまで実施課題の見える化：既に見えている一部の技術負債や改善点を各チームに共有 2. 改善活動の習慣化時間の確保：20％の時間を改善活動に使えるように小さな改善から：大きなリファクタではなく継続可能な範囲で
10

具体的にやったこと 3. 権限委譲判断権をチームに：改善の優先順位はチームが決める緊急の脆弱性対応等を除いて、改善活動の優先順位はチームで相談して決めてもらう 4. 知識共有とサポート体制ペアプログラミング：有識者と若手での知識委譲輪読会：AWSベストプラクティスなどの学習
成功体験の共有：月1回のLT会で成果を発表し合う相談体制：各チームのテックリードが集まる会を週次で開催 11

仕組み化のポイントまとめ 1. 改善時間の確保：スプリントに改善タスクを組み込む 2. 進捗の可視化：改善活動の進捗をチーム全体で共有 3. 評価への反映：改善活動を正当に評価する仕組み継続のコツ無理をしない：持続可能な範囲で優先順位を決めて進める成果を実感：改善による効果を定期的に確認
12

困った時の対処法よくある抵抗とその対応 1. 「時間がない」組織として時間を確保できるようにするそのために改善による時間短縮効果を具体的に示す 2. 「やり方がわからない」ペアプログラミングでサポート勉強会を開催
チーム間の温度差への対応積極的なチームの事例を横展開改善活動の成果を全体で共有 13

成功要因：なぜこのアプローチが成功したのか仮説の検証仮説：責任を持たせることで改善が進む仮説の根拠：コンテキストを育てるという意識がないため放置されていると感じた結果：思った以上の成果が出た個人的な変化：製品全体が良くなっていく様子が見えることでモチベーション向上効果：少人数での細かい改善 →
チーム全体での目に見える改善　　　負債も溜まりづらくなった 14

成功を支えた要因 1. 継続的な問題提起：諦めずに声を上げ続けた 2. 丁寧な合意形成：上層部・チームリーダー・メンバー全てとの合意 3. 現実的な解決策：理想より実現可能性を重視 15

変革の影響：プロジェクト推進への影響新しい推進方法 1プロジェクトでも複数チームの協力が必須コミュニケーションコストの増加進捗の見えづらさ現状責任範囲を明確にしてこの体制に変更する時点で、この懸念は見えていたので、プロジェクトにかかる工数を一旦多めに取らせていただくことに合意をもらった上で進めている今後
製品の方針も守りつつ、各チームが独立して開発・リリースできるように検討中 16

学んだこと：チームでリファクタリングを進めるコツ技術的解決より仕組み作り完璧な技術的アプローチより、チームが動きやすい仕組み作りが重要責任とオーナーシップの力「自分たちの領域」という意識が主体的な改善を生む理想と現実のバランス理想の追求：イベントストーミング、PoCで完璧な解決を目指した現実的な選択：責任の明確化で実際に成果が出た重要な学び：技術的な完璧さより実現可能なアプローチが効果的 17

まとめチームでリファクタリングを進めるために 1. 責任範囲の明確化：各チームが「自分たちの領域」を持つ 2. 主体性の尊重：チームが自分で判断できる環境作り 3. 継続可能な仕組み：無理のない範囲での改善活動 4. 成果の共有：改善による効果をチーム全体で実感
最も大切なこと技術的な完璧さより、チームが継続的に改善できる仕組み作りチームの責任範囲を明確にした現実的なアプローチで小さくスタートできました 18

ご清聴ありがとうございました 19

チームでリファクタリングを進めるために

チームでリファクタリングを進めるために

Sho

More Decks by Sho

Other Decks in Programming

Featured

Transcript