Tweet
Tweet

Slide 1

Slide 1 text

「どこから読む？」コードとカルチャーに 最速で馴染むための実践ガイド 〜新メンバーを活躍に導くオンボーディング戦略〜 株式会社ZOZO
 計測プラットフォーム開発本部 計測アプリ部 Androidブロック
 
 加藤りさ子 (richako) Copyright © ZOZO, Inc. 1

Slide 2

Slide 2 text

© ZOZO, Inc. 株式会社ZOZO 計測プラットフォーム開発本部 計測アプリ部 Androidブロック 加藤りさ子 (richako) 2025年新卒入社。 アメリカなどで展開する計測フィットネスアプリ 『ZOZOFIT』のAndroidアプリ開発を担当。 / : @risako070310 2

Slide 3

Slide 3 text

© ZOZO, Inc. https://zozofit.com 3 ● 自宅で手軽に高精度な3Dボディスキャンができる体型管理サービス ● ZOZOSUITと専用スマートフォンアプリを活用し、自宅で手軽に高 精度な全身3Dスキャンが可能。 ● 現在はZOZOSUITなしのアプリのみ計測も可能 ● 30万ダウンロードを突破、累計200万回以上のスキャン実績 ● 計測データに基づき、体の変化を3Dモデルと数値で可視化。身体の 変化を可視化し、モチベーション維持 ● 栄養素を記録・分析するAI食事記録機能など計測以外の機能でも総 合的な健康管理をサポート ● アメリカなどで展開

Slide 4

Slide 4 text

© ZOZO, Inc. GOAL ・「新メンバーが『迷子』にならずに主体的 に学べる環境」をどう作っていくか ・チームの受け入れ負担を減らし、生産性を 高める具体的なヒントについて 4

Slide 5

Slide 5 text

© ZOZO, Inc. 新メンバー箱猫マックスくん

Slide 6

Slide 6 text

© ZOZO, Inc. 新メンバー チーム スピーカーの実体験 スライドの見出しカラーについて

Slide 7

Slide 7 text

© ZOZO, Inc. 7 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ

Slide 8

Slide 8 text

© ZOZO, Inc. 8 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ

Slide 9

Slide 9 text

© ZOZO, Inc. 9 どこから読めば いいんだ…？ プロジェクトの 全体像がいまいち 掴めない… ファイル数が 多すぎる… ドメイン知識が 足りてなくて用語もわ からない…

Slide 10

Slide 10 text

© ZOZO, Inc. 10 新メンバーの課題 1.巨大・レガシーコードベースの読み解き方 ● まず初めに読まなくてもいいコードを読んで時間を浪費してしまう ● 全体像が掴めず、影響範囲を恐れる/修正方針が決まらない →結果、プロジェクトを知って最初のタスクに着手するまでの時間が長くなって しまう

Slide 11

Slide 11 text

© ZOZO, Inc. 11 コードを読む「型」を身につける ❌闇雲にプロジェクトを読む ↓ ◎3つのエントリーポイントからアプローチする 1.巨大・レガシーコードベースの読み解き方

Slide 12

Slide 12 text

© ZOZO, Inc. 12 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ

Slide 13

Slide 13 text

© ZOZO, Inc. 13 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 なぜこの3つのアプローチなのか ● アプリを構成する主な要素である データ UI 機能 アプリが扱う情報の核 ユーザーが直接触れる部分 UIとデータを結びつける振る舞い

Slide 14

Slide 14 text

© ZOZO, Inc. 14 コードベースを読み解いた実体験 UIから追い始め、そこからデータと機能実装へ 1.巨大・レガシーコードベースの読み解き方

Slide 15

Slide 15 text

© ZOZO, Inc. 15 コードベースを読み解いた実体験 1.巨大・レガシーコードベースの読み解き方 ● UIが得意分野だった ● 視覚情報が紐づいた方が理解が速かった

Slide 16

Slide 16 text

© ZOZO, Inc. 16 コードベースを読み解いた実体験 1.巨大・レガシーコードベースの読み解き方 ● UIが得意分野だった ● 視覚情報が紐づいた方が理解が速かった →配属1週間でUI修正のPull Requestを出すことができた　

Slide 17

Slide 17 text

© ZOZO, Inc. 17 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ

Slide 18

Slide 18 text

© ZOZO, Inc. 18 データフローからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: アプリのコアなデータクラスを見つける ● チームメンバーにプロジェクトの重要なデータモデルについて聞いてみる ● APIドキュメントを読む ○ データの構造はわかるが、クライアントサイドでデータモデルとしてどのように扱っている かが全てわかる地図ではない

Slide 19

Slide 19 text

© ZOZO, Inc. 19 データフローからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: Find Usagesで使われ方を追跡 ● データがどこで生成され、どこで使われているかを把握する ● アプリ上でのデータの流れが掴める

Slide 20

Slide 20 text

© ZOZO, Inc. 20 データフローからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: Find Usagesで使われ方を追跡 右クリック→Find Usages(⌥+F7) プロジェクトソース：https://github.com/android/nowinandroid

Slide 21

Slide 21 text

© ZOZO, Inc. 21 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ

Slide 22

Slide 22 text

© ZOZO, Inc. 22 UIからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: アプリを実行し、Layout Inspectorでコンポーネントを特定 ● 実機やエミュレータでアプリを動かしながら確認 ● 主要な画面から追うことができる

Slide 23

Slide 23 text

© ZOZO, Inc. 23 UIからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: アプリを実行し、Layout Inspectorでコンポーネントを特定 プロジェクトソース：https://github.com/android/nowinandroid

Slide 24

Slide 24 text

© ZOZO, Inc. 24 UIからコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: Find in Filesで実装箇所を検索 ● Composableの定義箇所を知り、そこからViewModelやActivity/Fragment 構造を追う

Slide 25

Slide 25 text

© ZOZO, Inc. 25 コードを読む「型」を身につける 1.巨大・レガシーコードベースの読み解き方 ③機能 ②UI ①データ

Slide 26

Slide 26 text

© ZOZO, Inc. 26 機能(デバッグ)からコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP1: 気になる実装にブレークポイントを置く ● ボタンのタップ時や画面の表示ポイントなど ● デバッグモードで起動し、処理が止まったところから紐解く

Slide 27

Slide 27 text

© ZOZO, Inc. 27 機能(デバッグ)からコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: コールスタックを遡る ● どういった経緯でメソッドが呼ばれているか一目瞭然 ● 動作とコードが紐付くので流れが把握しやすい

Slide 28

Slide 28 text

© ZOZO, Inc. 28 機能(デバッグ)からコードを読む 1.巨大・レガシーコードベースの読み解き方 STEP2: コールスタックを遡る プロジェクトソース：https://github.com/android/nowinandroid

Slide 29

Slide 29 text

© ZOZO, Inc. 29 番外編: AI活用 1.巨大・レガシーコードベースの読み解き方 ● AIにプロジェクトの概要を要約してもらう ○ GitHub Copilot ChatやClaude Codeなど ● プロジェクトを読むための最初の一歩として非常に有効！

Slide 30

Slide 30 text

© ZOZO, Inc. 30 チームの課題 1.巨大・レガシーコードベースの読み解き方 ● 新メンバーがプロジェクトの読み解きでつまずいてしまうことで、メンター などのOJTコストが増えてしまう ● プロジェクトの設計思想やアーキテクチャ、歴史的経緯を理解しないまま実 装されたコードは技術負債となりがち ○ 積み重なることでメンテナンス性の低いコードベースへと劣化してしまう ○ レビューコストも爆増する

Slide 31

Slide 31 text

© ZOZO, Inc. 31 チームがやるべきこと 1.巨大・レガシーコードベースの読み解き方 新メンバーをプロジェクトの中で遭難させないための 「地図」を用意する

Slide 32

Slide 32 text

© ZOZO, Inc. 32 POINT1: README.mdの充実 1.巨大・レガシーコードベースの読み解き方 環境構築の説明だけでなく、プロジェクトの概要まで記載する ● buildするまでの手順も大事。それと同じくらいプロジェクトの概要も大事。 ● 主要な機能や、画面構成などが記載されているor記載されている場所がわか ることが望ましい。

Slide 33

Slide 33 text

© ZOZO, Inc. 33 POINT1: README.mdの充実 1.巨大・レガシーコードベースの読み解き方 [READMEのテンプレート例] ● プロジェクト概要 ● 動作環境 / ビルド方法 ● 開発に関するドキュメント ○ アーキテクチャガイドライン ○ コーディングガイドライン ○ デバッグ環境特有のルール ○ APIドキュメント

Slide 34

Slide 34 text

© ZOZO, Inc. 34 POINT2: アーキテクチャ図 1.巨大・レガシーコードベースの読み解き方 ● C4 Modelのレベル1/2程度の図を作り、データフローを可視化。 ● 合わせて、モジュール構成やクラス図もあるとさらに解像度が上がる。

Slide 35

Slide 35 text

© ZOZO, Inc. 35 1.巨大・レガシーコードベースの読み解き方 のまとめ 闇雲に読まず、「データ」「UI」「機能」から実装を追う 新メンバー 新メンバーを遭難させない「プロジェクトの地図」を用意する チーム

Slide 36

Slide 36 text

© ZOZO, Inc. 36 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ

Slide 37

Slide 37 text

© ZOZO, Inc. 37 独自のSDKの実態が 全く見えない ViewModelの責務 実際どこまで？？ DIの仕組みが よくわからない…

Slide 38

Slide 38 text

© ZOZO, Inc. 38 新メンバーの課題 2.プロジェクト固有の技術/アーキテクチャの理解 ● 設計思想とプロジェクト固有の実装ルールや歴史的経緯の間に乖離がある ● DIなどのフレームワークが裏側で依存性を解決するため、オブジェクトが 「どこで・どのように」生成されているのかが非明示的 ● 実践的ベストプラクティスの判断不能 →アーキテクチャ理解の壁が高い

Slide 39

Slide 39 text

© ZOZO, Inc. 39 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ①DIの仕組みを可視化する ● Dagger/Hiltには依存関係をグラフで可視化するツールがある ● 依存の注入を図で理解する

Slide 40

Slide 40 text

© ZOZO, Inc. 40 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ①DIの仕組みを可視化する ● 一番小さな依存から追う ● @Injectされている一番単純なクラスから追いかける

Slide 41

Slide 41 text

© ZOZO, Inc. 41 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ②変更差分の小さなPull Requestを読む ● 機能追加よりも小さなリファクタリングやバグ修正のPRが狙い目 ● プロジェクトの「作法」が凝縮されている

Slide 42

Slide 42 text

© ZOZO, Inc. 42 プロジェクトの仕組みを解き明かす 2.プロジェクト固有の技術/アーキテクチャの理解 ②変更差分の小さなPull Requestを読む ● 具体的に何を見るか ○ モジュール構成 ○ クラスや関数の命名規則 ○ テストコードの書き方 ○ レビュアーのコメントの視点

Slide 43

Slide 43 text

© ZOZO, Inc. 43 チームの課題 ● 暗黙知があり、チームメンバーの知見が属人化 ● 技術選定の背景や設計の意図が言語化されていない ○ 結果的にレビューでの手戻りやレビューコストの増加が発生する 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 44

Slide 44 text

© ZOZO, Inc. 44 チームがやるべきこと アーキテクチャガイドラインなど、開発に特化した ドキュメントを充実させる ドキュメントなどの静的な成果物だけでなく チームの慣習によって実践の中で思想を伝えていく 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 45

Slide 45 text

© ZOZO, Inc. 45 なぜドキュメントが必要か 2.プロジェクト固有の技術/アーキテクチャの理解 ● 設計思想や歴史的経緯が共有されない ● 「なぜこの技術/設計なのか」を言語化する ○ 技術選定の背景を伝える ○ 新メンバーがアーキテクチャの「軸」を理解し、自律的に判断できるようになる

Slide 46

Slide 46 text

© ZOZO, Inc. 46 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える

Slide 47

Slide 47 text

© ZOZO, Inc. 47 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える

Slide 48

Slide 48 text

© ZOZO, Inc. 48 ①意思決定の「なぜ」を記録する Architecture Decision Records (ADR) とは？ 「なぜこの技術を選んだのか」「なぜこの設計にしたのか」という、アーキテク チャに関する意思決定の経緯を記録するための軽量なドキュメント手法 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 49

Slide 49 text

© ZOZO, Inc. 49 ①意思決定の「なぜ」を記録する [ADRのテンプレート例] ● タイトル：決定したこと ● ステータス：現在の実装状況(導入済/決定済/検討中など) ● 背景：決定に至った背景や以前の課題 ● 決定事項：具体的な決定事項 ● 結果：この決定後にもたらされる良い結果と悪い結果 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 50

Slide 50 text

© ZOZO, Inc. 50 ①意思決定の「なぜ」を記録する ADRがもたらす価値 ● 議論の透明化 ○ なぜこの選択肢を選んだかが明確になり、同じ議論の繰り返しを防ぐ ● プロジェクトの将来の道筋 ○ 現状の実装がなぜこうなっているかの答えになる ● 新メンバーの理解促進 ○ 技術選定の背景を知ることで、アーキテクチャの深い理解に繋がる 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 51

Slide 51 text

© ZOZO, Inc. 51 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える

Slide 52

Slide 52 text

© ZOZO, Inc. 52 ②設計相談やペアプロなどで同期的に共有する 設計相談の場を作る ● 複雑な機能を作る前やリファクタリングの方針を決める前にチームで議論を する場を設ける ○ 手戻りを防ぐ：実装してからレビューで議論し方針が変わってしまうことを防ぐ ○ 思考プロセスを学ぶ：新メンバーにとっては、チームのエンジニアがどのように課題を分析 し、設計に落とし込んでいくのかを理解することができる 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 53

Slide 53 text

© ZOZO, Inc. 53 ②設計相談やペアプロなどで同期的に共有する ドキュメント化できない知識を伝える「ペアプロ」 ● メンターと新メンバーが一緒にコーディングすることで、ドキュメントには 書ききれない暗黙知を効率的に伝達できる ○ IDEのTipsやデバッグのコツ ○ 「ここはこういう理由で、このクラスに書こう」といったリアルタイムの設計判断 ○ コードレビューでは伝わらない細かなニュアンス 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 54

Slide 54 text

© ZOZO, Inc. 54 継続的に思想を共有する「場」と「文化」 2.プロジェクト固有の技術/アーキテクチャの理解 ① 意思決定の「なぜ」を記録する ② 設計相談やペアプロなどで同期的に共有する ③ 日々のレビューで思想を伝える

Slide 55

Slide 55 text

© ZOZO, Inc. 55 ③日々のレビューで思想を伝える コードレビューは「指摘」の場ではなく「対話」 ● コードの品質を担保することにフォーカスが当たりがちだが、チームの設計 思想や文化を継承するための非常に重要なコミュニケーション機会です 2.プロジェクト固有の技術/アーキテクチャの理解

Slide 56

Slide 56 text

© ZOZO, Inc. 56 ③日々のレビューで思想を伝える レビューコメントのMore/Good 2.プロジェクト固有の技術/アーキテクチャの理解 More Good 「ここは〇〇クラスを使ってください。」 レビューコメントに対して、理由や背景が分か らず、今後の応用も効かない 「ここは〇〇クラスを使うと、ビジネスロジック を再利用できます。関連するドキュメントはこち らです [リンク]。この設計思想については、改 めて同期的に話しましょう！」 「なぜ」を伝え、議論を促し、次のアクションに 繋げている

Slide 57

Slide 57 text

© ZOZO, Inc. 57 コードレビューでの学び 2.プロジェクト固有の技術/アーキテクチャの理解 ● 大規模な画面に新機能の実装を足した ● 参考にするモジュールを間違えてしまったことで機能単位のファイル切り分 けにしたが、本来は統一したモジュール配下に置くべきだった

Slide 58

Slide 58 text

© ZOZO, Inc. 58 コードレビューでの学び 2.プロジェクト固有の技術/アーキテクチャの理解 ● 大規模な画面に新機能の実装を足した ● 参考にするモジュールを間違えてしまったことで機能単位のファイル切り分 けにしたが、本来は統一したモジュール配下に置くべきだった →コードレビューでプロジェクト全体の実装方針と現時点で改善の余地があると 思っている点を共有してもらった

Slide 59

Slide 59 text

© ZOZO, Inc. 59 コードレビューでの学び 2.プロジェクト固有の技術/アーキテクチャの理解 コードレビューによって 現在の実装の課題&プロジェクト全体の実装方針を 知るきっかけになった

Slide 60

Slide 60 text

© ZOZO, Inc. 60 2.プロジェクト固有の技術/アーキテクチャの理解 のまとめ DIやPRなど、小さなエントリーポイントからアーキテクチャを理解する 新メンバー 静的な知識(ドキュメント)と動的な知識(対話)の両輪で思想を伝える チーム

Slide 61

Slide 61 text

© ZOZO, Inc. 61 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ

Slide 62

Slide 62 text

© ZOZO, Inc. 62 ビルドエラーで 環境構築できない CIで謎のエラー出た！ よく分からない テストコードの書き方 これでいいのか？

Slide 63

Slide 63 text

© ZOZO, Inc. 63 新メンバーの課題 3. 開発に必要な周辺知識のキャッチアップ ● テスト、CI/CD、難読化、セキュリティ、パフォーマンス…と学ぶべきこと の多さに圧倒されてしまう ● ビルドエラーに詰まってプロジェクトの実行まで辿り着けない

Slide 64

Slide 64 text

© ZOZO, Inc. 64 問題解決のための戦略的な手順 3. 開発に必要な周辺知識のキャッチアップ 問題が発生した時に、「どの順番で情報を確認すれば 自己解決の可能性が高まるか」を知る

Slide 65

Slide 65 text

© ZOZO, Inc. 65 エラーログを恐れない 3. 開発に必要な周辺知識のキャッチアップ ● エラーメッセージを読んでみる ○ 解決へのヒントが必ず書いてある ○ まずエラーログを読む->試行錯誤->分からなかったらチームに聞くの流れが癖付くとスピー ドが上がる ■ 最初は特に試行錯誤の時間をなるべく短くして良い ■ プロジェクト特有のルールの可能性があるため聞くことで無駄な時間を減らせる

Slide 66

Slide 66 text

© ZOZO, Inc. 66 テストコードは似ているテストから紐解く 3. 開発に必要な周辺知識のキャッチアップ ● ゴールはプロジェクトの「型」を学ぶこと ○ 最初から完璧なテストを実装する必要はない ① 探す: 最高の「お手本」を探す まずは、修正した機能と似ている、シンプルで分かりやすいテストコードを1つ見つける。 ② 真似る (Imitate): 構造をそっくり真似てみる 見つけたテストコードの構造（@Beforeでの準備、@Testでの実行、assertでの検証）を真似て、自分のテストクラスを作ります。 ③ 動かす (Run): まずは動くものを作る 細かい部分を自分の実装に合わせて修正し、まずはテストが成功することを目指します。

Slide 67

Slide 67 text

© ZOZO, Inc. 67 チームの課題 3. 開発に必要な周辺知識のキャッチアップ オンボーディングの度に同じ質問に何度も答えていませんか？

Slide 68

Slide 68 text

© ZOZO, Inc. 68 チームがやるべきこと 3. 開発に必要な周辺知識のキャッチアップ ● つまずきやすいポイントを予め言語化しておく ○ 環境構築やビルドエラーは新メンバーほぼ100％つまずくポイント ○ 口頭やDMでのサポートはその場限りで知見が蓄積されない ● Tips集などとしてオンボーディング資料に組み込む

Slide 69

Slide 69 text

© ZOZO, Inc. 69 例：環境構築Tips集 3. 開発に必要な周辺知識のキャッチアップ ● 推奨するAndroid Studioのバージョン ● JDKのインストールと設定方法 ● 環境変数 ● 頻出エラーの対処法

Slide 70

Slide 70 text

© ZOZO, Inc. 70 例：環境構築Tips集 3. 開発に必要な周辺知識のキャッチアップ ● 推奨するAndroid Studioのバージョン ● JDKのインストールと設定方法 ● 環境変数 ● 頻出エラーの対処法 オンボーディングに関するQ&Aやコミュニケーションの場所を チームで予め作成しておくのも効果的 (例) Slackのチャンネル #android-onboarding

Slide 71

Slide 71 text

© ZOZO, Inc. 71 あって助かったドキュメント ● 部署の特徴として複数プロダクトを持っている ○ →プロダクトごとに環境構築が必要 ● 例に漏れずビルドエラーを複数引き起こした 3. 開発に必要な周辺知識のキャッチアップ

Slide 72

Slide 72 text

© ZOZO, Inc. 72 あって助かったドキュメント ● 部署の特徴として複数プロダクトを持っている ○ →プロダクトごとに環境構築が必要 ● 例に漏れずビルドエラーを複数引き起こした 3. 開発に必要な周辺知識のキャッチアップ Tips集のおかげで、長い時間エラーに悩まされず 解決策をすぐに知ることができた

Slide 73

Slide 73 text

© ZOZO, Inc. 73 3. 開発に必要な周辺知識のキャッチアップ のまとめ 既存のドキュメントを最大限活用し、キャッチアップ速度をあげる 新メンバー 新メンバーがつまずく前に「転ばぬ先の杖」としてのTips集を用意する チーム

Slide 74

Slide 74 text

© ZOZO, Inc. 74 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ

Slide 75

Slide 75 text

© ZOZO, Inc. 75 チームの文化は どんな感じなんだろう ドキュメントが多くて どれを見ればいいの…？ コミュニケーションの場は どこが正解？

Slide 76

Slide 76 text

© ZOZO, Inc. 76 新メンバーの課題 4.「最低限これだけは必要」なドキュメントとは ● 情報の海と人の壁 ○ 技術情報やキャッチアップするべき資料が多すぎる ○ チームの文化や人に関する情報が不足していると、誰を頼れば良いか分からず孤立してしま う

Slide 77

Slide 77 text

© ZOZO, Inc. 77 新メンバーのやるべきこと 4.「最低限これだけは必要」なドキュメントとは ドキュメントを活用し、いち早くチームに溶け込む

Slide 78

Slide 78 text

© ZOZO, Inc. 78 オンボーディングTODOを道標に 4.「最低限これだけは必要」なドキュメントとは ● TODO形式でやるべきことをタスク化 ○ 進捗がわかるように見える化しておく →チームメンバーが自分の現在地を把握し、適切なタイミングでサポートしやす くなる

Slide 79

Slide 79 text

© ZOZO, Inc. 79 メンバー紹介資料で「人」を知る 4.「最低限これだけは必要」なドキュメントとは ● 自分の自己紹介資料を作成しながら、チームメンバーの資料を探り、チーム メンバーへの理解を深める →人となりを知ることで、技術的な質問をする心理的ハードルが下がる

Slide 80

Slide 80 text

© ZOZO, Inc. 80 コミュニケーションの「場所」を把握する 4.「最低限これだけは必要」なドキュメントとは ● 「この話はどのチャンネルですればいいのか？」という迷いをなくす ● 自分にとって重要なチャンネルをブックマークしておく ○ 用途を理解するだけで、情報のキャッチアップ効率が劇的に上がる ● 雑談チャンネルやtimes(分報)文化があれば見に行ってみる

Slide 81

Slide 81 text

© ZOZO, Inc. 81 チームの課題 コードは読めても、人は読めない ● 技術的なキャッチアップが進んでも、チームに馴染めなければ新メンバーの パフォーマンスは上がらない ● 暗黙のルールや、誰が何に詳しいのかというチームメンバーに関する情報不 足がコミュニケーションの壁となってしまう 4.「最低限これだけは必要」なドキュメントとは

Slide 82

Slide 82 text

© ZOZO, Inc. 82 チームがやるべきこと 技術だけでなく、「人」と「文化」のドキュメントで 心理的安全性を形成する 4.「最低限これだけは必要」なドキュメントとは

Slide 83

Slide 83 text

© ZOZO, Inc. 83 技術 + 人 + 文化を網羅するドキュメントとは 4.「最低限これだけは必要」なドキュメントとは ● オンボーディングタスクリスト ○ これさえ辿って進めれば環境構築ができる全知全能リストに！ ● アーキテクチャガイドラインなどの開発に寄ったドキュメント ● コミュニケーションガイド ○ 使われているSlackのチャンネルなど、コミュニケーションの場所がわかるもの ● チーム/自己紹介資料

Slide 84

Slide 84 text

© ZOZO, Inc. 84 (例)コミュニケーションガイド 4.「最低限これだけは必要」なドキュメントとは ● #android-dev: 開発に関する質問全般 ● #android-info: Android関連のニュース共有 ● #android-雑談: ちょっとした雑談や情報共有 ● 定例MTGのアジェンダと議事録の場所

Slide 85

Slide 85 text

© ZOZO, Inc. 85 (例)チーム/自己紹介資料 4.「最低限これだけは必要」なドキュメントとは 「誰が」「どこで」「何をしているか」を可視化する ● 個人紹介: 顔写真、役割、得意なこと、趣味、16Personalitiesなど ● チーム紹介: プロジェクトで関わる他チーム（サーバサイド、デザイナー、 QAなど）の紹介 ○ 部署をまたいだ連携がスムーズになる

Slide 86

Slide 86 text

© ZOZO, Inc. 86 4. 「最低限これだけは必要」なドキュメントとは のまとめ ドキュメントを羅針盤に、積極的にチームと関わる 新メンバー 技術だけでなく、「人」と「文化」を伝えるドキュメントを整備する チーム

Slide 87

Slide 87 text

© ZOZO, Inc. 87 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ

Slide 88

Slide 88 text

© ZOZO, Inc. 88 このドキュメントが古くて、 この手順だとプロジェクトが動かないですね… 確かに環境構築の手順がちょっと変わってるかも （そしてそのまま誰もドキュメントを更新しない…）

Slide 89

Slide 89 text

© ZOZO, Inc. 89 ①レビュアーとして貢献する 5. ドキュメントを陳腐化させない運用方法 オンボーディング中に見つけた古い記述や情報の違いは、絶好の貢献チャンス ● 新メンバーはオンボーディングドキュメントの「唯一の読者」であり「唯一 のレビュアー」 ● 小さな修正でも、後にチームにjoinする人にドキュメントの価値を提供し続 けるために必要

Slide 90

Slide 90 text

© ZOZO, Inc. 90 ②「知見」のストック 5. ドキュメントを陳腐化させない運用方法 オンボーディング中の疑問は、未来の新メンバーのための貴重な情報 ● やりとりをコピーして解決方法などをTipsに追記する癖をつける ● その数分の作業が、将来の新メンバーが悩む数時間を節約する可能性がある

Slide 91

Slide 91 text

© ZOZO, Inc. 91 チームの課題 「いつかやる」は、永遠にやらない ● ドキュメント更新は、緊急度が低いため常に後回しにされがち ● 個人の善意や頑張りだけに頼った運用は、必ず破綻する 5. ドキュメントを陳腐化させない運用方法

Slide 92

Slide 92 text

© ZOZO, Inc. 92 チームがやるべきこと 5. ドキュメントを陳腐化させない運用方法 ドキュメント更新を「文化」と「仕組み」にする

Slide 93

Slide 93 text

© ZOZO, Inc. 93 新メンバー自身がメンテナーになる文化 ● ドキュメントを一番必要として一番真剣に読むユーザー ● 古い情報や分かりにくい記述に最も気づきやすい ● 更新作業を通じて、プロジェクトへの理解がさらに深まる →オンボーディングの最終タスクとしてオンボーディングドキュメントの更新を 組み込む 5. ドキュメントを陳腐化させない運用方法

Slide 94

Slide 94 text

© ZOZO, Inc. 94 定期的なドキュメント更新の仕組み ● 新メンバーが久しく入らないチームは特に放置されてしまう ● ドキュメント作成文化はオンボーディングだけでなくチームの知識の属人化 を防ぐために重要 →ドキュメント更新&レビューの時間を取ることで、今まで属人化していた知見 をアウトプットとして残す 5. ドキュメントを陳腐化させない運用方法

Slide 95

Slide 95 text

© ZOZO, Inc. 95 5. ドキュメントを陳腐化させない運用方法 のまとめ ドキュメントの消費者から生産者へ。ドキュメント更新に貢献する 新メンバー 善意に頼らず、ドキュメント更新を開発プロセスに組み込む仕組みを作る チーム

Slide 96

Slide 96 text

© ZOZO, Inc. 96 目次 1. 巨大・レガシーコードベースの読み解き方 2. プロジェクト固有の技術/アーキテクチャの理解 3. 開発に必要な周辺知識のキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは 5. ドキュメントを陳腐化させない運用方法 6. まとめ

Slide 97

Slide 97 text

© ZOZO, Inc. 97 セッションのまとめ 1. 巨大・レガシーコードベースの読み解き方 ○ 闇雲に読まず、地図を頼りに型を持って読む 2. プロジェクト固有の技術/アーキテクチャの理解 ○ 暗黙知をなくし、設計の「なぜ」を共有する 3. 開発に必要な周辺知識のキャッチアップ ○ 「転ばぬ先の杖」となるドキュメントを用意、それを活用してキャッチアップ 4. 「最低限これだけは必要」なドキュメントとは ○ 技術だけでなく、チームの人と文化を伝える・知る 5. ドキュメントを陳腐化させない運用方法 ○ 個人の頑張りだけに頼らず、仕組みで更新し文化にする

Slide 98

Slide 98 text

© ZOZO, Inc. 98 セッションのまとめ オンボーディングは「単なるイベント」ではない

Slide 99

Slide 99 text

© ZOZO, Inc. 99 セッションのまとめ ● 新メンバーが質問やドキュメント更新で主体的に貢献する ● チームはそれを受け止め、仕組みを改善し、さらに貢献しやすい環境を作る このポジティブな循環が、チーム全体の成長を加速させることができる

Slide 100

Slide 100 text

No content