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
110
モノリスの認知負荷に立ち向かう、コードの所有者という思想と現実
#コード品質_findy
Kazuki Maeda
March 25, 2025
Tweet
Share
More Decks by Kazuki Maeda
See All by Kazuki Maeda
エンジニアリング価値を黒字化する バリューベース戦略を用いた 技術戦略策定の道のり
kzkmaeda
9
4.6k
現場の種を事業の芽にする - エンジニア主導のイノベーションを事業戦略に装着する方法 -
kzkmaeda
2
3.5k
生成AIを用いた 新しい学びの体験を 提供するまでの道のり
kzkmaeda
0
240
生成AIによって変わる世界 -可能性とリスクについて考える-
kzkmaeda
2
250
新しいことを組織ではじめる、そしてつづける
kzkmaeda
5
900
20240824_JAWS_PANKRATION_2024
kzkmaeda
0
81
20240416_devopsdaystokyo
kzkmaeda
1
470
20240321_生成AI時代のDevOps
kzkmaeda
2
1.1k
20240222_LangChain_ver0.1.0_LCEL
kzkmaeda
4
420
Other Decks in Technology
See All in Technology
AWS のポリシー言語 Cedar を活用した高速かつスケーラブルな認可技術の探求 #phperkaigi / PHPerKaigi 2025
ytaka23
7
1.5k
DIってなんだか難しい? 依存という概念を「使う・使われる」 という言葉で整理しよう
akinoriakatsuka
1
770
DevOps文化を育むQA 〜カルチャーバブルを生み出す戦略〜 / 20250317 Atsushi Funahashi
shift_evolve
1
100
Javaの新しめの機能を知ったかぶれるようになる話 #kanjava
irof
3
4.8k
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
130
チームビルディング「脅威モデリング」ワークショップ
koheiyoshikawa
0
110
Go の analysis パッケージで自作するリファクタリングツール
kworkdev
PRO
1
360
BCMathを高速化した一部始終をC言語でガチ目に解説する / BCMath performance improvement explanation
sakitakamachi
2
1.2k
ソフトウェアプロジェクトの成功率が上がらない原因-「社会価値を考える」ということ-
ytanaka5569
0
120
一人QA時代が終わり、 QAチームが立ち上がった話
ma_cho29
0
270
ドメインイベントを活用したPHPコードのリファクタリング
kajitack
2
1.1k
Explainable Software Engineering in the Public Sector
avandeursen
0
340
Featured
See All Featured
Practical Orchestrator
shlominoach
186
10k
Automating Front-end Workflow
addyosmani
1369
200k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
129
19k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
22
2.6k
Making Projects Easy
brettharned
116
6.1k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
176
52k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
A Modern Web Designer's Workflow
chriscoyier
693
190k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
12
1.4k
GraphQLとの向き合い方2022年版
quramy
45
14k
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