Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実
Search
Kazuki Maeda
March 25, 2025
Technology
0
190
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実
#コード品質_findy
Kazuki Maeda
March 25, 2025
Tweet
Share
More Decks by Kazuki Maeda
See All by Kazuki Maeda
エンジニアリング価値を黒字化する バリューベース戦略を用いた 技術戦略策定の道のり
kzkmaeda
9
5k
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 -
kzkmaeda
2
4.4k
生成AIを用いた 新しい学びの体験を 提供するまでの道のり
kzkmaeda
0
260
生成AIによって変わる世界 -可能性とリスクについて考える-
kzkmaeda
2
270
新しいことを組織ではじめる、そしてつづける
kzkmaeda
5
910
20240824_JAWS_PANKRATION_2024
kzkmaeda
0
89
20240416_devopsdaystokyo
kzkmaeda
1
480
20240321_生成AI時代のDevOps
kzkmaeda
2
1.2k
20240222_LangChain_ver0.1.0_LCEL
kzkmaeda
4
440
Other Decks in Technology
See All in Technology
AI Agentを「期待通り」に動かすために:設計アプローチの模索と現在地
kworkdev
PRO
2
440
Mastraに入門してみた ~AWS CDKを添えて~
tsukuboshi
0
150
AIと開発者の共創: エージェント時代におけるAIフレンドリーなDevOpsの実践
bicstone
1
300
Dynamic Reteaming And Self Organization
miholovesq
3
420
Goの組織でバックエンドTypeScriptを採用してどうだったか / How was adopting backend TypeScript in a Golang company
kaminashi
6
5.2k
Cross Data Platforms Meetup LT 20250422
tarotaro0129
1
370
Webアプリを Lambdaで動かすまでに考えること / How to implement monolithic Lambda Web Application
_kensh
7
1.3k
ElixirがHW化され、最新CPU/GPU/NWを過去のものとする数万倍、高速+超省電力化されたWeb/動画配信/AIが動く日
piacerex
0
140
バクラクの認証基盤の成長と現在地 / bakuraku-authn-platform
convto
1
310
プロダクト開発におけるAI時代の開発生産性
shnjtk
2
230
“パスワードレス認証への道" ユーザー認証の変遷とパスキーの関係
ritou
1
570
20250413_湘南kaggler会_音声認識で使うのってメルス・・・なんだっけ?
sugupoko
1
470
Featured
See All Featured
Typedesign – Prime Four
hannesfritz
41
2.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
23
2.6k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.4k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.1k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Code Review Best Practice
trishagee
67
18k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Done Done
chrislema
183
16k
Visualization
eitanlees
146
16k
The Power of CSS Pseudo Elements
geoffreycrofte
75
5.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
47
2.5k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
Transcript
コードの所有者という思想と現実 モノリスの認知負荷に立ち向かう モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 1
前田 和樹(kzk_maeda) atama plus株式会社 VPoE / 技術フェロー データや機械学習、生成AIに関する開 発 AWS
Community Builder / AWS Startup Community Core Member 自己紹介 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 2
事業成長に伴い直面した開発課題 「コードを所有する」という考え方と取り組み 「コードを所有する」状態と組織柔軟性の課題 所有者運用と組織柔軟性の最大公約数 まとめ アジェンダ モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 3
事業成長に伴い直面した開発課題 アジェンダ 「コードを所有する」という考え方と取り組み 「コードを所有する」状態と組織柔軟性の課題 所有者運用と組織柔軟性の最大公約数 まとめ モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 4
シンプルなプロダクト・小さなチームから スタート 背景:スタートアップ の成長 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 5
事業成長に伴い、機能・エンジニアが増加 一方、コードベースはモノリシックアーキ テクチャを維持 単純なモノリスではなく、モジュラー モノリスを志向した成長 分割するコストと時間の制約 ビジネス成長スピードの優先 背景:スタートアップ の成長 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実
6
事業の多角化戦略 同一のコードベースで複数の顧客・事 業への展開 短期での事業立ち上げを最小の痛みで実現 する必要性 2022年:事業の多角展 開 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 7
認知負荷の増大 「全部を全員で見切れない」 開発コンフリクトの頻発 新事業:高速な価値検証 既存事業:安定した価値提供 チーム間調整コストの爆発的増加 新事業での変更が既存事業で は不要 顧客コミュニケーションコス ト
直面した課題 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 8
開発負荷増大に対して、チーム間 で開発についてsyncする場を定期 的に設けて対応 一定の効果は得られたものの、中 長期的な知識の醸成やコンフリク ト防止の課題は依然残る 対話での回避 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 9
「コードを所有する」という考え方と取り組み アジェンダ 事業成長に伴い直面した開発課題 「コードを所有する」状態と組織柔軟性の課題 所有者運用と組織柔軟性の最大公約数 まとめ モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 10
コードの各部分に明確な「所有者」を設定 する 所有者はそのコードについての最終責任を 持つ Googleなどの大規模組織でも実践されてい る手法 「Code Ownership」の考え方 ファイルレベルでのオーナーシップ レビューやメンテナンスの責任の明確
化 「コードの所有」とは モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 11
コードの各部分に明確な「所有者」を設定する開発ルール src/ ├── module_a/ │ ├── feature_1/ # Product Team
A │ └── feature_2/ # Product Team B ├── module_b/ # Product Team C │ └── submodule/ # Product Team D └── shared/ # Platform Team 所有の単位はmoduleだったり、コードファイル単位だったり 実態に合わせて設計する必要がある コード所有者モデル モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 12
チームをストリームアラインドに 区切る 事業・サービス単位での機能 責任 ドメイン知識の集約 関連するコードの所有 ドメイン関連コードの明確な 割り当て チーム間の責任境界の設定 所有者モデルの設
計 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 13
1. コードベース分析と所有エリアのマッピング 2. クロスエリア開発のためのガイドライン策定 事前相談ルール レビュー依頼フロー 3. シームレスな所有者の管理・可視化 メタデータファイルの配置 エディタ拡張の開発
導入プロセス モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 14
コードベース分析と所有エリアのマッピング プロダクトの機能/module/APIの粒度で、どのエリアが所有するものかを整理 所有関係・依存関係を一覧にして可視化 導入プロセス モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 15
クロスエリア開発のためのガイドライン策定 所有をまたがる変更を他チームから行いたい場合、所有チームに相談する 何をトリガーに所有者に相談するかのガイドラインなど制定 導入プロセス モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 16
コード所有の可視化 エディタでコードファイルを開く と 所有エリアが表示される拡張の提 供 導入プロセス モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 17
コード所有の可視化 敬虔なVimmerが作成した拡張も 導入プロセス モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 18
認知負荷の軽減 自分のチームが所有するコードの変更に対する安全性が向上 所有していないコードに関しても「誰に聞けばいいか」の明確化 品質維持活動の効率化 トリアージしたバグのアサインを機械的に実施 特にDevOpsの中で、検知したエラーの担当アサインに迷わなくなった 初期の成果 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 19
「コードを所有する」状態と組織柔軟性の課題 アジェンダ 事業成長に伴い直面した開発課題 「コードを所有する」という考え方と取り組み 所有者運用と組織柔軟性の最大公約数 まとめ モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 20
負荷の偏り 活発な開発領域 vs. レガシー 領域 メンテナンス負荷の不均衡 技術的負債の責任 「継承した負債」に対する 抵抗感 クロスカッティングな変更の複
雑化 チームを跨る変更の調整コ 直面した課題 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現 実 21
事業戦略変更による組織再編 事業戦略に合わせ、チーム統合・分割、新規事業立ち上げなどが必要にな る 所有者移管の難しさ 組織変更と合わせて、コードの知識移転を行うコストが着いて回る 組織変更の影響で、事実上所有者が不在となるコードが現れる 組織変更とのコンフリクト モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 22
事業Aに注力し、事業Bから人 をアサインしたいという組織 変更 事業Bが所有しているコード には、事業Aに依存されてい るものも多数 人が少なくなるが、依存され るコードが多く存在するケー スに、どう立ち向かえばいい のか??
課題の事例 モノリスの認知負荷に立ち向かう、コードの所有者という思想 と現実 23
余談:マイクロサービス 化? この手の話でよく上がる解決策だ が・・ マイクロサービスは必ずしも答え ではない 分割コストの高さ 運用複雑性の増大 組織規模とのバランス サービス所有の問題は残る
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 24
所有者運用と組織柔軟性の最大公約数 アジェンダ 事業成長に伴い直面した開発課題 「コードを所有する」という考え方と取り組み 「コードを所有する」状態と組織柔軟性の課題 まとめ モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 25
以降は現在挑戦中の新しい所有運用についてです モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 26
領地と領主 従来の静的な所有権から動的な管理責 任へ 領地 (Territory) 事業ドメインに基づくコード領域 機能的なまとまりを優先 領主 (Lord) 変更管理の責任を持つチームまた
は個人 新しいアプローチ: モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 27
コードを事業ドメインでなく、被依存度と変更頻度、複雑度の軸で整理 1. 被依存度が低く、変更頻度も低い 2. 被依存度が高く、変更頻度は低い 3. 変更頻度が高い 4. 複雑性が高い 領主の整理
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 28
領主の整理 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 29
被依存度が低く、変更頻度も低い 保守Phaseに入った機能、コード 積極的に体制はつけないが、 知識承継と運用保守のガイドは決め る 被依存度が高く、変更頻度は低い Platform的に複数事業で利用される コード 所有コストを下げることを目的とし た
変更頻度が高い 注力事業で積極的に開発しているコ ード 事業チームのエンジニアで所有する 複雑性が高い Complicated Subsystemの要素が強 いコード 特殊な知識を要するケースが多いた め、 領主の整理 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 30
組織変更への適応性 領主の交代が容易 事業変化に合わせた柔軟な責任移管 明確な責任分担 コードの「住所=事業ドメインに紐づく領地」は変わらない 管理責任=領主だけを移行 オーナーシップの促進 単なる「担当」から「責任ある管理」へ 一時的な領主としての改善インセンティブにも寄与させたい 「領地と領主」モデルで狙う利点
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 31
まとめ アジェンダ 事業成長に伴い直面した開発課題 「コードを所有する」という考え方と取り組み 「コードを所有する」状態と組織柔軟性の課題 所有者運用と組織柔軟性の最大公約数 モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 32
1. 事業成長の中で認知負荷の軽減が重要課題に 2. コード所有権モデルで成果を得るも、組織変更との衝突に直面 3. 領域の状態に応じた領主の割り当てで柔軟性を確保 4. 領地(Territory)と領主(Lord)の分離がモノリス運用の新しい形 5. 変更頻度や被依存度に基づいた動的な所有構造へ
まとめ モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 33
コード所有は思想だけでなく運用の問題 単にルールを決めるだけでは不十分 組織変化に対応できる柔軟な仕組みが必要 マルチ事業展開への対応 事業ごとの変更速度とリスク許容度の違いを調整 共通部分と変動部分の境界線設計 技術と組織の共進化 コードの構造と所有者モデルを同時に進化させる 「領地と領主」という概念を文化として定着させる 学びと今後の展望
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 34
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実 35