「どこから読む？」コードとカルチャーに最速で馴染むための実践ガイド

2025/09/12 12:20 ~ 13:00にDroidkaigi 2025の公募セッションで発表した登壇資料です。

https://2025.droidkaigi.jp/timetable/943982/
株式会社ZOZO
計測プラットフォーム開発本部
計測アプリ部 Androidブロック
加藤りさ子 (richako)

#DroidKaigi

Transcript

1. 「どこから読む？」コードとカルチャーに 最速で馴染むための実践ガイド 〜新メンバーを活躍に導くオンボーディング戦略〜 株式会社ZOZO
 計測プラットフォーム開発本部 計測アプリ部 Androidブロック
 
 加藤りさ子 (richako) Copyright © ZOZO, Inc. 1
2. © ZOZO, Inc. 株式会社ZOZO 計測プラットフォーム開発本部 計測アプリ部 Androidブロック 加藤りさ子 (richako) 2025年新卒入社。 アメリカなどで展開する計測フィットネスアプリ 『ZOZOFIT』のAndroidアプリ開発を担当。 / : @risako070310 2
3. © ZOZO, Inc. https://zozofit.com 3 • 自宅で手軽に高精度な3Dボディスキャンができる体型管理サービス • ZOZOSUITと専用スマートフォンアプリを活用し、自宅で手軽に高 精度な全身3Dスキャンが可能。 • 現在はZOZOSUITなしのアプリのみ計測も可能 • 30万ダウンロードを突破、累計200万回以上のスキャン実績 • 計測データに基づき、体の変化を3Dモデルと数値で可視化。身体の 変化を可視化し、モチベーション維持 • 栄養素を記録・分析するAI食事記録機能など計測以外の機能でも総 合的な健康管理をサポート • アメリカなどで展開
4. © ZOZO, Inc. GOAL ・「新メンバーが『迷子』にならずに主体的 に学べる環境」をどう作っていくか ・チームの受け入れ負担を減らし、生産性を 高める具体的なヒントについて 4
5. © ZOZO, Inc. 新メンバー箱猫マックスくん
6. © ZOZO, Inc. 新メンバー チーム スピーカーの実体験 スライドの見出しカラーについて
7. © ZOZO, Inc. 7 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ
8. © ZOZO, Inc. 8 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ
9. © ZOZO, Inc. 9 どこから読めば いいんだ…？ プロジェクトの 全体像がいまいち 掴めない… ファイル数が 多すぎる… ドメイン知識が 足りてなくて用語もわ からない…
10. © ZOZO, Inc. 10 新メンバーの課題 1.巨大・レガシーコードベースの読み解き方 • まず初めに読まなくてもいいコードを読んで時間を浪費してしまう • 全体像が掴めず、影響範囲を恐れる/修正方針が決まらない →結果、プロジェクトを知って最初のタスクに着手するまでの時間が長くなって しまう
11. © ZOZO, Inc. 11 コードを読む「型」を身につける ❌闇雲にプロジェクトを読む ↓ ◎3つのエントリーポイントからアプローチする 1.巨大・レガシーコードベースの読み解き方
12. © ZOZO, Inc. 12 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ
13. © ZOZO, Inc. 13 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 なぜこの3つのアプローチなのか • アプリを構成する主な要素である データ UI 機能 アプリが扱う情報の核 ユーザーが直接触れる部分 UIとデータを結びつける振る舞い
14. © ZOZO, Inc. 14 コードベースを読み解いた実体験 UIから追い始め、そこからデータと機能実装へ 1.巨大・レガシーコードベースの読み解き方
15. © ZOZO, Inc. 15 コードベースを読み解いた実体験 1.巨大・レガシーコードベースの読み解き方 • UIが得意分野だった • 視覚情報が紐づいた方が理解が速かった
16. © ZOZO, Inc. 16 コードベースを読み解いた実体験 1.巨大・レガシーコードベースの読み解き方 • UIが得意分野だった • 視覚情報が紐づいた方が理解が速かった →配属1週間でUI修正のPull Requestを出すことができた　
17. © ZOZO, Inc. 17 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ
18. © ZOZO, Inc. 18 データフローからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: アプリのコアなデータクラスを見つける • チームメンバーにプロジェクトの重要なデータモデルについて聞いてみる • APIドキュメントを読む ◦ データの構造はわかるが、クライアントサイドでデータモデルとしてどのように扱っている かが全てわかる地図ではない
19. © ZOZO, Inc. 19 データフローからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: Find Usagesで使われ方を追跡 • データがどこで生成され、どこで使われているかを把握する • アプリ上でのデータの流れが掴める
20. © ZOZO, Inc. 20 データフローからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: Find Usagesで使われ方を追跡 右クリック→Find Usages(⌥+F7) プロジェクトソース：https://github.com/android/nowinandroid
21. © ZOZO, Inc. 21 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ
22. © ZOZO, Inc. 22 UIからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: アプリを実行し、Layout Inspectorでコンポーネントを特定 • 実機やエミュレータでアプリを動かしながら確認 • 主要な画面から追うことができる
23. © ZOZO, Inc. 23 UIからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: アプリを実行し、Layout Inspectorでコンポーネントを特定 プロジェクトソース：https://github.com/android/nowinandroid
24. © ZOZO, Inc. 24 UIからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: Find in Filesで実装箇所を検索 • Composableの定義箇所を知り、そこからViewModelやActivity/Fragment 構造を追う
25. © ZOZO, Inc. 25 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ
26. © ZOZO, Inc. 26 機能(デバッグ)からコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: 気になる実装にブレークポイントを置く • ボタンのタップ時や画面の表示ポイントなど • デバッグモードで起動し、処理が止まったところから紐解く
27. © ZOZO, Inc. 27 機能(デバッグ)からコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: コールスタックを遡る • どういった経緯でメソッドが呼ばれているか一目瞭然 • 動作とコードが紐付くので流れが把握しやすい
28. © ZOZO, Inc. 28 機能(デバッグ)からコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: コールスタックを遡る プロジェクトソース：https://github.com/android/nowinandroid
29. © ZOZO, Inc. 29 番外編: AI活用 1.巨大・レガシーコードベースの読み解き方 • AIにプロジェクトの概要を要約してもらう ◦ GitHub Copilot ChatやClaude Codeなど • プロジェクトを読むための最初の一歩として非常に有効！
30. © ZOZO, Inc. 30 チームの課題 1.巨大・レガシーコードベースの読み解き方 • 新メンバーがプロジェクトの読み解きでつまずいてしまうことで、メンター などのOJTコストが増えてしまう • プロジェクトの設計思想やアーキテクチャ、歴史的経緯を理解しないまま実 装されたコードは技術負債となりがち ◦ 積み重なることでメンテナンス性の低いコードベースへと劣化してしまう ◦ レビューコストも爆増する
31. © ZOZO, Inc. 31 チームがやるべきこと 1.巨大・レガシーコードベースの読み解き方 新メンバーをプロジェクトの中で遭難させないための 「地図」を用意する
32. © ZOZO, Inc. 32 POINT1: README.mdの充実 1.巨大・レガシーコードベースの読み解き方 環境構築の説明だけでなく、プロジェクトの概要まで記載する • buildするまでの手順も大事。それと同じくらいプロジェクトの概要も大事。 • 主要な機能や、画面構成などが記載されているor記載されている場所がわか ることが望ましい。
33. © ZOZO, Inc. 33 POINT1: README.mdの充実 1.巨大・レガシーコードベースの読み解き方 [READMEのテンプレート例] • プロジェクト概要 • 動作環境 / ビルド方法 • 開発に関するドキュメント ◦ アーキテクチャガイドライン ◦ コーディングガイドライン ◦ デバッグ環境特有のルール ◦ APIドキュメント
34. © ZOZO, Inc. 34 POINT2: アーキテクチャ図 1.巨大・レガシーコードベースの読み解き方 • C4 Modelのレベル1/2程度の図を作り、データフローを可視化。 • 合わせて、モジュール構成やクラス図もあるとさらに解像度が上がる。
35. © ZOZO, Inc. 35 1.巨大・レガシーコードベースの読み解き方 のまとめ 闇雲に読まず、「データ」「UI」「機能」から実装を追う 新メンバー 新メンバーを遭難させない「プロジェクトの地図」を用意する チーム
36. © ZOZO, Inc. 36 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ
37. © ZOZO, Inc. 37 独自のSDKの実態が 全く見えない ViewModelの責務 実際どこまで？？ DIの仕組みが よくわからない…
38. © ZOZO, Inc. 38 新メンバーの課題 2.プロジェクト固有の技術/アーキテクチャの理解 • 設計思想とプロジェクト固有の実装ルールや歴史的経緯の間に乖離がある • DIなどのフレームワークが裏側で依存性を解決するため、オブジェクトが 「どこで・どのように」生成されているのかが非明示的 • 実践的ベストプラクティスの判断不能 →アーキテクチャ理解の壁が高い
39. © ZOZO, Inc. 39 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ①DIの仕組みを可視化する • Dagger/Hiltには依存関係をグラフで可視化するツールがある • 依存の注入を図で理解する
40. © ZOZO, Inc. 40 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ①DIの仕組みを可視化する • 一番小さな依存から追う • @Injectされている一番単純なクラスから追いかける
41. © ZOZO, Inc. 41 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ②変更差分の小さなPull Requestを読む • 機能追加よりも小さなリファクタリングやバグ修正のPRが狙い目 • プロジェクトの「作法」が凝縮されている
42. © ZOZO, Inc. 42 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ②変更差分の小さなPull Requestを読む • 具体的に何を見るか ◦ モジュール構成 ◦ クラスや関数の命名規則 ◦ テストコードの書き方 ◦ レビュアーのコメントの視点
43. © ZOZO, Inc. 43 チームの課題 • 暗黙知があり、チームメンバーの知見が属人化 • 技術選定の背景や設計の意図が言語化されていない ◦ 結果的にレビューでの手戻りやレビューコストの増加が発生する 2.プロジェクト固有の技術/アーキテクチャの理解
44. © ZOZO, Inc. 44 チームがやるべきこと アーキテクチャガイドラインなど、開発に特化した ドキュメントを充実させる ドキュメントなどの静的な成果物だけでなく チームの慣習によって実践の中で思想を伝えていく 2.プロジェクト固有の技術/アーキテクチャの理解
45. © ZOZO, Inc. 45 なぜドキュメントが必要か 2.プロジェクト固有の技術/アーキテクチャの理解 • 設計思想や歴史的経緯が共有されない • 「なぜこの技術/設計なのか」を言語化する ◦ 技術選定の背景を伝える ◦ 新メンバーがアーキテクチャの「軸」を理解し、自律的に判断できるようになる
46. © ZOZO, Inc. 46 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える
47. © ZOZO, Inc. 47 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える
48. © ZOZO, Inc. 48 ①意思決定の「なぜ」を記録する Architecture Decision Records (ADR) とは？ 「なぜこの技術を選んだのか」「なぜこの設計にしたのか」という、アーキテク チャに関する意思決定の経緯を記録するための軽量なドキュメント手法 2.プロジェクト固有の技術/アーキテクチャの理解
49. © ZOZO, Inc. 49 ①意思決定の「なぜ」を記録する [ADRのテンプレート例] • タイトル：決定したこと • ステータス：現在の実装状況(導入済/決定済/検討中など) • 背景：決定に至った背景や以前の課題 • 決定事項：具体的な決定事項 • 結果：この決定後にもたらされる良い結果と悪い結果 2.プロジェクト固有の技術/アーキテクチャの理解
50. © ZOZO, Inc. 50 ①意思決定の「なぜ」を記録する ADRがもたらす価値 • 議論の透明化 ◦ なぜこの選択肢を選んだかが明確になり、同じ議論の繰り返しを防ぐ • プロジェクトの将来の道筋 ◦ 現状の実装がなぜこうなっているかの答えになる • 新メンバーの理解促進 ◦ 技術選定の背景を知ることで、アーキテクチャの深い理解に繋がる 2.プロジェクト固有の技術/アーキテクチャの理解
51. © ZOZO, Inc. 51 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える
52. © ZOZO, Inc. 52 ②設計相談やペアプロなどで同期的に共有する 設計相談の場を作る • 複雑な機能を作る前やリファクタリングの方針を決める前にチームで議論を する場を設ける ◦ 手戻りを防ぐ：実装してからレビューで議論し方針が変わってしまうことを防ぐ ◦ 思考プロセスを学ぶ：新メンバーにとっては、チームのエンジニアがどのように課題を分析 し、設計に落とし込んでいくのかを理解することができる 2.プロジェクト固有の技術/アーキテクチャの理解
53. © ZOZO, Inc. 53 ②設計相談やペアプロなどで同期的に共有する ドキュメント化できない知識を伝える「ペアプロ」 • メンターと新メンバーが一緒にコーディングすることで、ドキュメントには 書ききれない暗黙知を効率的に伝達できる ◦ IDEのTipsやデバッグのコツ ◦ 「ここはこういう理由で、このクラスに書こう」といったリアルタイムの設計判断 ◦ コードレビューでは伝わらない細かなニュアンス 2.プロジェクト固有の技術/アーキテクチャの理解
54. © ZOZO, Inc. 54 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える
55. © ZOZO, Inc. 55 ③日々のレビューで思想を伝える コードレビューは「指摘」の場ではなく「対話」 • コードの品質を担保することにフォーカスが当たりがちだが、チームの設計 思想や文化を継承するための非常に重要なコミュニケーション機会です 2.プロジェクト固有の技術/アーキテクチャの理解
56. © ZOZO, Inc. 56 ③日々のレビューで思想を伝える レビューコメントのMore/Good 2.プロジェクト固有の技術/アーキテクチャの理解 More Good 「ここは〇〇クラスを使ってください。」 レビューコメントに対して、理由や背景が分か らず、今後の応用も効かない 「ここは〇〇クラスを使うと、ビジネスロジック を再利用できます。関連するドキュメントはこち らです [リンク]。この設計思想については、改 めて同期的に話しましょう！」 「なぜ」を伝え、議論を促し、次のアクションに 繋げている
57. © ZOZO, Inc. 57 コードレビューでの学び 2.プロジェクト固有の技術/アーキテクチャの理解 • 大規模な画面に新機能の実装を足した • 参考にするモジュールを間違えてしまったことで機能単位のファイル切り分 けにしたが、本来は統一したモジュール配下に置くべきだった
58. © ZOZO, Inc. 58 コードレビューでの学び 2.プロジェクト固有の技術/アーキテクチャの理解 • 大規模な画面に新機能の実装を足した • 参考にするモジュールを間違えてしまったことで機能単位のファイル切り分 けにしたが、本来は統一したモジュール配下に置くべきだった →コードレビューでプロジェクト全体の実装方針と現時点で改善の余地があると 思っている点を共有してもらった
59. © ZOZO, Inc. 59 コードレビューでの学び 2.プロジェクト固有の技術/アーキテクチャの理解 コードレビューによって 現在の実装の課題&プロジェクト全体の実装方針を 知るきっかけになった
60. © ZOZO, Inc. 60 2.プロジェクト固有の技術/アーキテクチャの理解 のまとめ DIやPRなど、小さなエントリーポイントからアーキテクチャを理解する 新メンバー 静的な知識(ドキュメント)と動的な知識(対話)の両輪で思想を伝える チーム
61. © ZOZO, Inc. 61 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ
62. © ZOZO, Inc. 62 ビルドエラーで 環境構築できない CIで謎のエラー出た！ よく分からない テストコードの書き方 これでいいのか？
63. © ZOZO, Inc. 63 新メンバーの課題 3. 開発に必要な周辺知識のキャッチアップ • テスト、CI/CD、難読化、セキュリティ、パフォーマンス…と学ぶべきこと の多さに圧倒されてしまう • ビルドエラーに詰まってプロジェクトの実行まで辿り着けない
64. © ZOZO, Inc. 64 問題解決のための戦略的な手順 3. 開発に必要な周辺知識のキャッチアップ 問題が発生した時に、「どの順番で情報を確認すれば 自己解決の可能性が高まるか」を知る
65. © ZOZO, Inc. 65 エラーログを恐れない 3. 開発に必要な周辺知識のキャッチアップ • エラーメッセージを読んでみる ◦ 解決へのヒントが必ず書いてある ◦ まずエラーログを読む->試行錯誤->分からなかったらチームに聞くの流れが癖付くとスピー ドが上がる ▪ 最初は特に試行錯誤の時間をなるべく短くして良い ▪ プロジェクト特有のルールの可能性があるため聞くことで無駄な時間を減らせる
66. © ZOZO, Inc. 66 テストコードは似ているテストから紐解く 3. 開発に必要な周辺知識のキャッチアップ • ゴールはプロジェクトの「型」を学ぶこと ◦ 最初から完璧なテストを実装する必要はない ① 探す: 最高の「お手本」を探す まずは、修正した機能と似ている、シンプルで分かりやすいテストコードを1つ見つける。 ② 真似る (Imitate): 構造をそっくり真似てみる 見つけたテストコードの構造（@Beforeでの準備、@Testでの実行、assertでの検証）を真似て、自分のテストクラスを作ります。 ③ 動かす (Run): まずは動くものを作る 細かい部分を自分の実装に合わせて修正し、まずはテストが成功することを目指します。
67. © ZOZO, Inc. 67 チームの課題 3. 開発に必要な周辺知識のキャッチアップ オンボーディングの度に同じ質問に何度も答えていませんか？
68. © ZOZO, Inc. 68 チームがやるべきこと 3. 開発に必要な周辺知識のキャッチアップ • つまずきやすいポイントを予め言語化しておく ◦ 環境構築やビルドエラーは新メンバーほぼ100％つまずくポイント ◦ 口頭やDMでのサポートはその場限りで知見が蓄積されない • Tips集などとしてオンボーディング資料に組み込む
69. © ZOZO, Inc. 69 例：環境構築Tips集 3. 開発に必要な周辺知識のキャッチアップ • 推奨するAndroid Studioのバージョン • JDKのインストールと設定方法 • 環境変数 • 頻出エラーの対処法
70. © ZOZO, Inc. 70 例：環境構築Tips集 3. 開発に必要な周辺知識のキャッチアップ • 推奨するAndroid Studioのバージョン • JDKのインストールと設定方法 • 環境変数 • 頻出エラーの対処法 オンボーディングに関するQ&Aやコミュニケーションの場所を チームで予め作成しておくのも効果的 (例) Slackのチャンネル #android-onboarding
71. © ZOZO, Inc. 71 あって助かったドキュメント • 部署の特徴として複数プロダクトを持っている ◦ →プロダクトごとに環境構築が必要 • 例に漏れずビルドエラーを複数引き起こした 3. 開発に必要な周辺知識のキャッチアップ
72. © ZOZO, Inc. 72 あって助かったドキュメント • 部署の特徴として複数プロダクトを持っている ◦ →プロダクトごとに環境構築が必要 • 例に漏れずビルドエラーを複数引き起こした 3. 開発に必要な周辺知識のキャッチアップ Tips集のおかげで、長い時間エラーに悩まされず 解決策をすぐに知ることができた
73. © ZOZO, Inc. 73 3. 開発に必要な周辺知識のキャッチアップ のまとめ 既存のドキュメントを最大限活用し、キャッチアップ速度をあげる 新メンバー 新メンバーがつまずく前に「転ばぬ先の杖」としてのTips集を用意する チーム
74. © ZOZO, Inc. 74 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ
75. © ZOZO, Inc. 75 チームの文化は どんな感じなんだろう ドキュメントが多くて どれを見ればいいの…？ コミュニケーションの場は どこが正解？
76. © ZOZO, Inc. 76 新メンバーの課題 4.「最低限これだけは必要」なドキュメントとは • 情報の海と人の壁 ◦ 技術情報やキャッチアップするべき資料が多すぎる ◦ チームの文化や人に関する情報が不足していると、誰を頼れば良いか分からず孤立してしま う
77. © ZOZO, Inc. 77 新メンバーのやるべきこと 4.「最低限これだけは必要」なドキュメントとは ドキュメントを活用し、いち早くチームに溶け込む
78. © ZOZO, Inc. 78 オンボーディングTODOを道標に 4.「最低限これだけは必要」なドキュメントとは • TODO形式でやるべきことをタスク化 ◦ 進捗がわかるように見える化しておく →チームメンバーが自分の現在地を把握し、適切なタイミングでサポートしやす くなる
79. © ZOZO, Inc. 79 メンバー紹介資料で「人」を知る 4.「最低限これだけは必要」なドキュメントとは • 自分の自己紹介資料を作成しながら、チームメンバーの資料を探り、チーム メンバーへの理解を深める →人となりを知ることで、技術的な質問をする心理的ハードルが下がる
80. © ZOZO, Inc. 80 コミュニケーションの「場所」を把握する 4.「最低限これだけは必要」なドキュメントとは • 「この話はどのチャンネルですればいいのか？」という迷いをなくす • 自分にとって重要なチャンネルをブックマークしておく ◦ 用途を理解するだけで、情報のキャッチアップ効率が劇的に上がる • 雑談チャンネルやtimes(分報)文化があれば見に行ってみる
81. © ZOZO, Inc. 81 チームの課題 コードは読めても、人は読めない • 技術的なキャッチアップが進んでも、チームに馴染めなければ新メンバーの パフォーマンスは上がらない • 暗黙のルールや、誰が何に詳しいのかというチームメンバーに関する情報不 足がコミュニケーションの壁となってしまう 4.「最低限これだけは必要」なドキュメントとは
82. © ZOZO, Inc. 82 チームがやるべきこと 技術だけでなく、「人」と「文化」のドキュメントで 心理的安全性を形成する 4.「最低限これだけは必要」なドキュメントとは
83. © ZOZO, Inc. 83 技術 + 人 + 文化を網羅するドキュメントとは 4.「最低限これだけは必要」なドキュメントとは • オンボーディングタスクリスト ◦ これさえ辿って進めれば環境構築ができる全知全能リストに！ • アーキテクチャガイドラインなどの開発に寄ったドキュメント • コミュニケーションガイド ◦ 使われているSlackのチャンネルなど、コミュニケーションの場所がわかるもの • チーム/自己紹介資料
84. © ZOZO, Inc. 84 (例)コミュニケーションガイド 4.「最低限これだけは必要」なドキュメントとは • #android-dev: 開発に関する質問全般 • #android-info: Android関連のニュース共有 • #android-雑談: ちょっとした雑談や情報共有 • 定例MTGのアジェンダと議事録の場所
85. © ZOZO, Inc. 85 (例)チーム/自己紹介資料 4.「最低限これだけは必要」なドキュメントとは 「誰が」「どこで」「何をしているか」を可視化する • 個人紹介: 顔写真、役割、得意なこと、趣味、16Personalitiesなど • チーム紹介: プロジェクトで関わる他チーム（サーバサイド、デザイナー、 QAなど）の紹介 ◦ 部署をまたいだ連携がスムーズになる
86. © ZOZO, Inc. 86 4. 「最低限これだけは必要」なドキュメントとは のまとめ ドキュメントを羅針盤に、積極的にチームと関わる 新メンバー 技術だけでなく、「人」と「文化」を伝えるドキュメントを整備する チーム
87. © ZOZO, Inc. 87 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ
88. © ZOZO, Inc. 88 このドキュメントが古くて、 この手順だとプロジェクトが動かないですね… 確かに環境構築の手順がちょっと変わってるかも （そしてそのまま誰もドキュメントを更新しない…）
89. © ZOZO, Inc. 89 ①レビュアーとして貢献する 5. ドキュメントを陳腐化させない運用方法 オンボーディング中に見つけた古い記述や情報の違いは、絶好の貢献チャンス • 新メンバーはオンボーディングドキュメントの「唯一の読者」であり「唯一 のレビュアー」 • 小さな修正でも、後にチームにjoinする人にドキュメントの価値を提供し続 けるために必要
90. © ZOZO, Inc. 90 ②「知見」のストック 5. ドキュメントを陳腐化させない運用方法 オンボーディング中の疑問は、未来の新メンバーのための貴重な情報 • やりとりをコピーして解決方法などをTipsに追記する癖をつける • その数分の作業が、将来の新メンバーが悩む数時間を節約する可能性がある
91. © ZOZO, Inc. 91 チームの課題 「いつかやる」は、永遠にやらない • ドキュメント更新は、緊急度が低いため常に後回しにされがち • 個人の善意や頑張りだけに頼った運用は、必ず破綻する 5. ドキュメントを陳腐化させない運用方法
92. © ZOZO, Inc. 92 チームがやるべきこと 5. ドキュメントを陳腐化させない運用方法 ドキュメント更新を「文化」と「仕組み」にする
93. © ZOZO, Inc. 93 新メンバー自身がメンテナーになる文化 • ドキュメントを一番必要として一番真剣に読むユーザー • 古い情報や分かりにくい記述に最も気づきやすい • 更新作業を通じて、プロジェクトへの理解がさらに深まる →オンボーディングの最終タスクとしてオンボーディングドキュメントの更新を 組み込む 5. ドキュメントを陳腐化させない運用方法
94. © ZOZO, Inc. 94 定期的なドキュメント更新の仕組み • 新メンバーが久しく入らないチームは特に放置されてしまう • ドキュメント作成文化はオンボーディングだけでなくチームの知識の属人化 を防ぐために重要 →ドキュメント更新&レビューの時間を取ることで、今まで属人化していた知見 をアウトプットとして残す 5. ドキュメントを陳腐化させない運用方法
95. © ZOZO, Inc. 95 5. ドキュメントを陳腐化させない運用方法 のまとめ ドキュメントの消費者から生産者へ。ドキュメント更新に貢献する 新メンバー 善意に頼らず、ドキュメント更新を開発プロセスに組み込む仕組みを作る チーム
96. © ZOZO, Inc. 96 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ
97. © ZOZO, Inc. 97 セッションのまとめ 1. 巨大・レガシーコードベースの読み解き方 ◦ 闇雲に読まず、地図を頼りに型を持って読む 2. プロジェクト固有の技術/アーキテクチャの理解 ◦ 暗黙知をなくし、設計の「なぜ」を共有する 3. 開発に必要な周辺知識のキャッチアップ ◦ 「転ばぬ先の杖」となるドキュメントを用意、それを活用してキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは ◦ 技術だけでなく、チームの人と文化を伝える・知る 5. ドキュメントを陳腐化させない運用方法 ◦ 個人の頑張りだけに頼らず、仕組みで更新し文化にする
98. © ZOZO, Inc. 98 セッションのまとめ オンボーディングは「単なるイベント」ではない
99. © ZOZO, Inc. 99 セッションのまとめ • 新メンバーが質問やドキュメント更新で主体的に貢献する • チームはそれを受け止め、仕組みを改善し、さらに貢献しやすい環境を作る このポジティブな循環が、チーム全体の成長を加速させることができる