Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
新Teamで始めたDesignDoc運用と 定着化のためにやったこと
Search
takahiro ogasawara
March 05, 2024
1.4k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
新Teamで始めたDesignDoc運用と 定着化のためにやったこと
takahiro ogasawara
March 05, 2024
Transcript
10 slides
1 新Teamで始めたDesignDoc運用と 定着化のためにやったこと 2024-03-05 そのまま口伝で続ける?メルカリ、カオナビ、estieの試行錯誤から学ぶ設計ドキュメントの活用方法 株式会社メルカリ ogasawara takahiro(@ogataka50)
2 • Engineering Manager at Mercari • Mercari Ads事業を担当 •
Love 🏈🚴🏔🍺 @ogataka50
3 現Teamのドキュメント運用 Agenda Design Docの運用について Design Doc, Document関連の困りごと 02 03
01
4 • 最初期はランダムにドキュメント作成 • 最近カテゴリ分けするようにした 現Teamのドキュメント運用
5 • カテゴリ分けに困るケースも ◦ Labelを活用できないかお試し中 • 各カテゴリで運用ルールを明記 現Teamのドキュメント運用
6 Design Docは課題点の明確化・共有と議論の活性化が主目的 • Design Docを書く条件などは特に設けていない • フォーマットはあるが全項目を埋める必要はないし、足してもよい • 例外はあるが、AutherがAcceptedなどのStatusを判断してよい
◦ Acceptedでなくても開発開始してもOK • Accepted後はDesign Doc更新は不要 ◦ 情報が古くなってもよい。あくまでスナップショット • Appendix : https://engineering.mercari.com/blog/entry/20220225-design- docs-by-mercari-shops/ Design Docの運用について
7 Design Docの運用の定着化するためにやったこと Design Docを書いた方がお得という状態にする。作成の障壁を下げる • Design Docを書くことで解決策の精度が上がる • 抜けていた考慮点の発見
• 知らなかった技術や知見を知ることができる • 認識を一致させることでその後のcode reviewなどがスムーズになる
8 Design Docの運用の定着化するためにやったこと • Dailyで相談できるmeeting slotを用意する(WaiWai Sync meeting ◦ 作成途中でもreviewできる場所作り空気作り
▪ まだ3割ぐらいで途中なんですが〜 ▪ なんとなく2つの方針どっちかかと思っているんですが〜 • 議論をして合意形成するのを目的としている結果DeclineというStatusはある が、一回も使われたことはない
9 Design Doc, Document関連の困りごと • 不可逆な技術選定などは関係者も増え時間がかかりがち ◦ Approver, Approve条件の整理, 口頭での共有など地道な調整
• 大小様々なDesign Doc増えて進行中のものがよくわからない ◦ In reviewのもの、review済みのもの、Acceptedだが機能自体なく なったもの、過去施策のものなど ◦ 積極的にarchived dirに移動。必要だったらrevertするので、どんどん archivedにする(archived dirが肥大化してきているが… • Design Docは更新不要だが、System architectureなどは常に最新を維 持したい ◦ 過去にはDocumentation weekをやったことが、あったあまりworkし なかった印象 ◦ DocumentationもProject closeの条件にする
10 • Design Docを通じて議論の活性化を最大の目的においている • Design Docを作成することの障壁を下げている • Design Docを定期的にreviewをする場を設けて早期&頻度多くreviewで
きるようにしている • Documentの更新漏れに関しては試行錯誤中… まとめ
More Decks by takahiro ogasawara
See All by takahiro ogasawara
ソーシャルゲームの 高負荷とかじゃない 地味な方の話
ogataka50
0
2.1k
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
55
13k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
320
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
570
Scaling GitHub
holman
464
140k
Technical Leadership for Architectural Decision Making
baasie
4
640
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Bash Introduction
62gerente
615
220k
We Are The Robots
honzajavorek
0
440
Heart Work Chapter 1 - Part 1
lfama
PRO
11
37k
Balancing Empowerment & Direction
lara
6
1.4k
The Power of CSS Pseudo Elements
geoffreycrofte
82
6.6k