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

チームと個人のリファクタリング実践談 / 関ジャバ'25 9月度
https://kanjava.connpass.com/event/368939/
発表資料

Transcript

1. チームでリファクタリングを進めるために チームと個人のリファクタリング実践談 / 関ジャバ'25 9月度 1
2. 今日お話しすること 感じていた課題：なぜチームでリファクタリングが進まないのか 試行錯誤の経緯：技術的アプローチから責任範囲明確化へ 転換点：責任範囲を明確化したら何が変わったか 実践方法：やったことと各チームへの働きかけ 学んだこと：チームでリファクタリングを進めるコツ 2
3. 感じていた課題：なぜチームでリファクタリング含めた改善活動 が進まないのか みんな改善が必要であるという認識しているが、実際には後回し 「誰かがやるだろう」の心理で主体性が欠如 既に複雑化したコード：積み重ねで複雑化していて触りづらい 責任の曖昧さ：全チームが全サービスを触る体制 継続性の欠如：プロジェクト毎に触るコンテキストが変わるので、習熟しづらい 調整の複雑さ：他チームとのコンフリクトで改善が発生しやすく調整が面倒 3
4. 試行錯誤の経緯：技術的アプローチから責任範囲明確化へ 最初は技術的なアプローチを試した（約1年間） 1. 危機感の共有：責任者への継続的な問題提起（2023年下期） 2. 専門チーム立ち上げ：若手中心の技術負債返済チーム（2023年下期） 3. 限定的な成果：少しの改善はできたが根本解決に至らず（2023年下期） 4. 専門家参加：イベントストーミングでコンテキスト再整理（2024年上期） 4
5. 試行錯誤の経緯：理想と現実のギャップ 理想的な設計の限界（2024年下期） イベントストーミングで完璧なコンテキスト分割を設計しましたが、既存システムや製 品開発プロセスとの整合性が取れませんでした。 製品責任者・本部長への説明： 「このレベルでのリファクタ/リアーキテクトは費用対効果が合わない」 原点回帰： 「何がしたかったのか」を再考 問い直し：完璧な技術的解決が本当の目的だったか？ 本来の目的：技術負債解決、主体的改善文化の醸成 気づき：責任範囲の明確化だけでも効果があるのでは？ 5
6. 転換点：責任範囲を明確化したら何が変わったか 変更内容 Before：管理OS割り≒プロジェクト割り（全チームが全サービス） After：コンテキスト割り（各チームが担当領域を明確に持つ） 各チームにコードリポジトリ単位で割り振りまで実施 狙い 各チームが「自分たちの領域」として継続的に責任を持つ 6
7. 実施にあたって上層部への説明：数値で効果を示した 説明内容 製品責任者・本部長に対して： 定量的効果：Four Keysなどの指標で「2年後にはコストをペイできる改善効果」 定性的効果： 「属人化解消（強い人依存→チーム依存）の重要性」 7
8. 効果：半年で見えてきた変化（2025年上期） 主体性の変化 以前：上から指示されない限り改善しない 現在：各チームが自主的に改善計画を立てて実行 技術的改善の活性化 ライブラリアップデート：各チームが積極的に実施 パフォーマンス改善：応答時間・コスト削減を自主的に 変更容易性向上：保守しやすいコード構造への改善 構造的リファクタリング（進行中） リポジトリの統廃合：分割されすぎたものの統合・巨大すぎるものの適切な分割 アーキテクチャ改善：レイヤード構造への整理 8
9. 効果：知識共有文化の醸成 教育・知識委譲の成果 ドキュメント整備：各チームが責任範囲を明文化 継続的学習：チーム主導での改善活動 スキル向上：チーム内での技術力底上げ 「やらされ感」から「やりたい感」への変化 コンテキストの改善活動が個人の目標にも組み込まれるように 9
10. 具体的にやったこと 1. 責任範囲の可視化 担当コンテキストの明確化：どのサービス・機能を担当するか コードリポジトリ単位でしっかり割り振りまで実施 課題の見える化：既に見えている一部の技術負債や改善点を各チームに共有 2. 改善活動の習慣化 時間の確保：20％の時間を改善活動に使えるように 小さな改善から：大きなリファクタではなく継続可能な範囲で 10
11. 具体的にやったこと 3. 権限委譲 判断権をチームに：改善の優先順位はチームが決める 緊急の脆弱性対応等を除いて、改善活動の優先順位はチームで相談して決め てもらう 4. 知識共有とサポート体制 ペアプログラミング：有識者と若手での知識委譲 輪読会：AWSベストプラクティスなどの学習 成功体験の共有：月1回のLT会で成果を発表し合う 相談体制：各チームのテックリードが集まる会を週次で開催 11
12. 仕組み化のポイントまとめ 1. 改善時間の確保：スプリントに改善タスクを組み込む 2. 進捗の可視化：改善活動の進捗をチーム全体で共有 3. 評価への反映：改善活動を正当に評価する仕組み 継続のコツ 無理をしない：持続可能な範囲で優先順位を決めて進める 成果を実感：改善による効果を定期的に確認 12
13. 困った時の対処法 よくある抵抗とその対応 1. 「時間がない」 組織として時間を確保できるようにする そのために改善による時間短縮効果を具体的に示す 2. 「やり方がわからない」 ペアプログラミングでサポート 勉強会を開催 チーム間の温度差への対応 積極的なチームの事例を横展開 改善活動の成果を全体で共有 13
14. 成功要因：なぜこのアプローチが成功したのか 仮説の検証 仮説：責任を持たせることで改善が進む 仮説の根拠：コンテキストを育てるという意識がないため放置されていると感じ た 結果：思った以上の成果が出た 個人的な変化：製品全体が良くなっていく様子が見えることでモチベーション向 上 効果：少人数での細かい改善 → チーム全体での目に見える改善 　　　負債も溜まりづらくなった 14
15. 成功を支えた要因 1. 継続的な問題提起：諦めずに声を上げ続けた 2. 丁寧な合意形成：上層部・チームリーダー・メンバー全てとの合意 3. 現実的な解決策：理想より実現可能性を重視 15
16. 変革の影響：プロジェクト推進への影響 新しい推進方法 1プロジェクトでも複数チームの協力が必須 コミュニケーションコストの増加 進捗の見えづらさ 現状 責任範囲を明確にしてこの体制に変更する時点で、この懸念は見えていたので、 プロジェクトにかかる工数を一旦多めに取らせていただくことに合意をもらった 上で進めている 今後 製品の方針も守りつつ、各チームが独立して開発・リリースできるように検討中 16
17. 学んだこと：チームでリファクタリングを進めるコツ 技術的解決より仕組み作り 完璧な技術的アプローチより、チームが動きやすい仕組み作りが重要 責任とオーナーシップの力 「自分たちの領域」という意識が主体的な改善を生む 理想と現実のバランス 理想の追求：イベントストーミング、PoCで完璧な解決を目指した 現実的な選択：責任の明確化で実際に成果が出た 重要な学び：技術的な完璧さより実現可能なアプローチが効果的 17
18. まとめ チームでリファクタリングを進めるために 1. 責任範囲の明確化：各チームが「自分たちの領域」を持つ 2. 主体性の尊重：チームが自分で判断できる環境作り 3. 継続可能な仕組み：無理のない範囲での改善活動 4. 成果の共有：改善による効果をチーム全体で実感 最も大切なこと 技術的な完璧さより、チームが継続的に改善できる仕組み作り チームの責任範囲を明確にした現実的なアプローチで小さくスタートできました 18
19. ご清聴ありがとうございました 19