Slide 1

Slide 1 text

1 新Teamで始めたDesignDoc運用と 定着化のためにやったこと 2024-03-05 そのまま口伝で続ける?メルカリ、カオナビ、estieの試行錯誤から学ぶ設計ドキュメントの活用方法 株式会社メルカリ ogasawara takahiro(@ogataka50)

Slide 2

Slide 2 text

2 ● Engineering Manager at Mercari
 ● Mercari Ads事業を担当
 ● Love 🏈🚴🏔🍺 @ogataka50


Slide 3

Slide 3 text

3 現Teamのドキュメント運用 Agenda Design Docの運用について Design Doc, Document関連の困りごと 02 03 01

Slide 4

Slide 4 text

4 ● 最初期はランダムにドキュメント作成 ● 最近カテゴリ分けするようにした 現Teamのドキュメント運用

Slide 5

Slide 5 text

5 ● カテゴリ分けに困るケースも ○ Labelを活用できないかお試し中 ● 各カテゴリで運用ルールを明記 現Teamのドキュメント運用

Slide 6

Slide 6 text

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の運用について

Slide 7

Slide 7 text

7 Design Docの運用の定着化するためにやったこと Design Docを書いた方がお得という状態にする。作成の障壁を下げる ● Design Docを書くことで解決策の精度が上がる ● 抜けていた考慮点の発見 ● 知らなかった技術や知見を知ることができる ● 認識を一致させることでその後のcode reviewなどがスムーズになる

Slide 8

Slide 8 text

8 Design Docの運用の定着化するためにやったこと ● Dailyで相談できるmeeting slotを用意する(WaiWai Sync meeting ○ 作成途中でもreviewできる場所作り空気作り ■ まだ3割ぐらいで途中なんですが〜 ■ なんとなく2つの方針どっちかかと思っているんですが〜 ● 議論をして合意形成するのを目的としている結果DeclineというStatusはある が、一回も使われたことはない

Slide 9

Slide 9 text

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の条件にする

Slide 10

Slide 10 text

10 ● Design Docを通じて議論の活性化を最大の目的においている ● Design Docを作成することの障壁を下げている ● Design Docを定期的にreviewをする場を設けて早期&頻度多くreviewで きるようにしている ● Documentの更新漏れに関しては試行錯誤中… まとめ