アーキテクチャ導入でチームが変わった学習文化と設計思考の浸透

アーキテクチャ導入でチームが変わった学習文化と設計思考の浸透アーキテクチャConference 2025 プレイベント

自己紹介所属：株式会社じげん名前：前川和也趣味：カメラ、漫画、コーヒー、洋服

運営サービス：リショップナビ効率的な集客を実現する反響数国内最多のリフォームポータルサイト

今日話すこと 📚 技術詳細ではなく、導入プロセスに焦点レイヤードアーキテクチャの実装方法ではなく、どう組織に浸透させたか 👥 チームの変化 : 属人化から自律的なチームへ特定メンバー依存 →
全員が設計議論できる組織に 👤 個人の変化 : 懐疑派から推進者、そして育成へ実体験ベースの2年間の成長ストーリー

2年前の状況 FatControllerによる認知負荷の増大特定メンバーしかメンテナンスできない機能が存在エラー対応も属人化誰かが退職したら終わる状態

2年間のタイムライン Phase 1: 模索期 Phase 2: 転換期 Phase 3: 自律期
2023/03以前リリース優先、アーキテクチャ不在 2023/03 Service層導入試みるもうまくいかない 2023/05 新メンバーがジョインしレイヤード提案 2023/09 実コードでの議論で理解深まる 2023/12 ユニットテスト導入で文化が根付く 2024/07 リーダー離脱 2025/01 2人目のリーダー離脱 2025/03 2年目メンバーへ知見継承

2023/03以前 - リリース優先、アーキテクチャ不在機能追加が最優先、設計改善の時間なしリリース優先で日々のタスクを消化統一されたアーキテクチャなし各自が設計して実装、人によってバラバラ課題は認識、でも手の打ちようがないどこから手をつけるべきか分からない ❓
混沌とした状態方向性が見えない

2023/03 - Service層導入試みるもうまくいかない設計に明るいメンバーが提案認知負荷低減のためアーキテクチャ導入を提案チーム全体に理解が不足レイヤー分離の概念が分からない、どう使うか不明今度はService層がカオスに再利用性など考慮できず似たような処理が乱立提案
↓ 実装 ↓ ❓❓❓ ↓ 失敗知識格差が解消されずリファクタリング工数確保も難しくService層のみ導入１ファイルあたりの行数が減ったので多少は改善

2023/05 - レイヤードアーキテクチャ提案チームの動き •新メンバーがレイヤード提案 ◦ Repositoryのみにするか、全て入れるか（Presenter、UseCase etc） •推進派 vs
慎重派で議論 ◦ 推進派：いつか首が回らなくなるので今のうちから対策を打つべき ◦ 慎重派：ビジネス優先。工数に見合う価値があるのか疑問 •長期的メンテナンス性を考慮し合意 •設計スキルにメンバー間格差個人の変化新入社員からの厳しい指摘 → 設計スキルの差を実感 → 通勤時間で勉強開始

Phase 1 の学びエンジニアとしてのベースラインをあげる「HRT」を意識する -Team Geek H:謙虚 R: 尊敬
T: 信頼外部からの指摘が学習のきっかけになる

2023/09 - 実コードでの議論で理解深まるチームの動き •勉強会とサンプルコードを使っての議論だけでは実際のロジックに当てはめた場合のイメージが湧かなかった ◦ サンプルコードはマスタデータの登録更新などがベース •ビジネス側と調整しリファクタリング工数確保 ◦
設計に明るいメンバーと議論しながら実際のロジックベースで実装しリリース •リリース後プルリクで議論 → メンバー全員がイメージできるように個人の変化ドメイン知識継承、ビジネスとの調整・リファクタリング推進役に

2023/12 - ユニットテスト導入で文化が根付く 🛡 ユニットテスト導入の効果仕様の明確化テストコードが仕様理解の手助けに設計への意識向上テスタブルなコードとは何かを考えるようにチーム全体が価値を実感
大規模な改修にもかかわらずエラー 0 💬 文化の変化実装前に考える習慣ドメイン知識の属人化解消プランニングポーカーを導入し実装前に議論するようにより深い設計力を求めて「Learning Domain-Driven Design」の輪読会開始全員がビジネスロジックを理解したい

Phase 2 の学びサンプルで議論より実践で学ぶ継続的な学習の場を作るビジネスとの調整が推進の鍵

2024/07, 2025/01 - リーダー離脱でも継続アーキテクチャの中心人物が 2回離脱レイヤードをリードしてきたメンバーが順次卒業でも設計議論は止まらない他のメンバーがレビューやリードを引き継ぎ特定個人への依存から脱却
チーム全体の能力に変わった証拠チームのベースライン向上文化の定着

2025/03 - 次世代への継承チームの動き •自分も別プロジェクトへアサイン •属人化した機能のナレッジ継承が急務 •特定の機能をモジュール化 ◦ 順次レイヤー化していたが、いつ終わるのかも不透明だったので、ビジネス側と調整し工数を確保して実施
個人の変化導入前にジュニアレベルだったメンバーにモジュール実装を任せサポートレイヤードアーキテクチャ導入時とは逆の立場に

Phase 3 の学び継続することで成果が見える変化が更なる成長のきっかけに委ねる勇気が変化を生む

Before / After Before チーム •課題を認識も手が出せない •リリース優先で設計後回し(場当たり的) •ベテラン頼み私個人 •個人の生産性重視
•設計スキル不足 •学習習慣なし After チーム •課題を見つけたら改善する •実装前に設計を議論(計画的) •初期のジュニアメンバーがチームをリード(成長を加速する環境) 私個人 •チームとしての成果をどうあげるか •新プロダクトでDDD挑戦 •継続的な学習習慣

何が効いたか実践から学ぶ - サンプルではなく実コード継続的な議論と学習の場 - 輪読会、プランニングポーカー変化を受け入れる - メンバーからの指摘、メンバーの離脱
諦めずに継続する - 状況にあったアーキテクチャの選択次世代に任せる勇気 - 属人化解消の継続

アーキテクチャ導入でチームが変わった学習文化と設計思考の浸透

アーキテクチャ導入でチームが変わった学習文化と設計思考の浸透

Kazuya Maekawa

More Decks by Kazuya Maekawa

Other Decks in Technology

Featured

Transcript