はじめに
プロジェクトに途中から参加することってあると思います。
途中参加だと「早く追いつかないと」と気持ちが先に立ってしまって、キャッチアップに時間がかかったり、ちょっと焦ったりすることがあるかなと思っています。
自分の場合、社内ドキュメントや設計書、要件などは一通り確認できるものの、「この資料の話って、実装だとどこに当たるんだ？」 がすぐには繋がらないことがありました。
また、コードもそれなりに大きくなっている。さらに言語もほぼ初めてで、読もうとしてもスピードが出ず、理解の手がかりが掴みにくい状態がありました。
前置きが長くなりましたが、そんなときに自分の中で効いたのが、理解した内容を自分用のドキュメントとして残しながらキャッチアップすることでした。
今回はそのドキュメント作りを進める手段のひとつとして、開発で使っている Claude Code（AI） を併用しながらキャッチアップを進めたので、その体験を書いてみます。
キャッチアップで困ったこと
1. 全体像が分からない
どの層（Controller / Service / Repository…）に何が置かれているのかが掴めず、読み始めの地点が定まりませんでした。
「機能追加に関連している処理はここかな」と思って追っても、途中で別の層を見ていたり、気づいたら迷子になっているような感覚です。
2. まとまっている資料から処理を把握できない
ドキュメントには画面仕様などの資料がまとまっているものの、そこから実装を辿るのが難しかったです。
「この資料の話、実装のどこ？」 を特定するまでに時間がかかり、理解よりも探索に体力を使っていました。
3. 初めての言語と大きめのコードで、読むスピードが出ない
コードが大きいのもありますが、言語がほぼ初めてだと「読む」だけでも時間を使ってしまいます。
結果として、理解の手がかりを掴む前に時間を使ったり、キャッチアップが進んでいる実感を持ちにくかったです。
実際の使い方
1. ディレクトリ構造の理解
最初にやったのは、プロジェクトの構成をざっくり整理することです。
途中参加直後は「どこに何があるのか」が分からず、読む順番も決めづらいので、まずはここを固めました。
Claude Code にはディレクトリ構成や主要ファイルを確認してもらい、このプロジェクトがどう成り立っているか を説明してもらい、その内容を自分用のMarkdownにまとめてもらいました。
例えば、バックエンド側でも API まわり / ドメイン / ビジネスロジック / OpenAPI などのように、役割が分かれているという整理ができ、各領域で 何を入口に読めばよさそうか が見えてきました。
この地図があるだけで、以降のキャッチアップがスムーズだったと思います。
「とりあえず手当たり次第に読む」状態から抜けられて、迷子になりにくくなった のが一番大きかったです。
2. 代表機能の流れ把握
次に、代表的な機能を1つ選んで、処理の流れを掴みました。
関連するファイル（Controller / Service / Repository など）を Claude Code に見てもらって、
- 処理の流れを箇条書きで整理してもらう
- 必要ならフロー図にして可視化してもらう
- 自分用の Markdown ドキュメントとしてまとめてもらう
という形で、理解しやすいように整理しました。
ここで作ったドキュメントは、あとから読み返して理解の再確認ができたので良かったです。
自分用のメモが残る のは助かりました。
3. 影響範囲の調査
実際に小さめの修正や機能追加に入る段階では、影響範囲の調査もしてもらいました。
Claude Code には変更内容を伝えた上で、
- 影響が出そうな観点の洗い出し
- 調査すべきファイルやキーワードの列挙
- 追加で確認すると良さそうなポイントの提案
をしてもらい、調査の起点 を作るのに使いました。
もちろん、ここで出てきた内容は、実際にファイルを見に行ったり、ログ確認を行ったりして再確認します。
ただ、「何から調べようか」が減った だけでも、調査に入るスピードが上がりました。
4. 用語・ドメイン知識をまとめてもらう
コードを追う以前に、そもそも プロジェクト固有の用語が分からない という問題もありました。
画面名や機能名、略語などが分からないと、設計書を読んでもピンと来ず、コード上の変数名やメソッド名を見ても意味が繋がりにくかったです。
そこで、用語の理解を進めるために 自分用の「用語・ドメイン辞書」Markdown を作ってもらいました。
- 用語（画面名 / 機能名 / 略語 など）
- 関連しそうな概念（似ている用語など）
- どの資料やどの画面で出てくるか
AIに整形してもらうことで読みやすくなりますし、あとから見返したときに「この用語、ここで出てきてたのか」と繋がることが増えました。
結果として、設計書や要件の文章を読んだときにも引っかかりが減り、コード上の命名も理解しやすくなりました。
まとめ
最後に、今回のキャッチアップで一番効いたのは、Claude Codeを使ったこと自体というより、整理した内容をMarkdownなど別ファイルとして“自分用に残していく”ことでした。
そのうえで、ドキュメント作成を進める手段のひとつとして AIツール（今回はClaude Code）を併用すると、キャッチアップがかなり楽になったと思います。
- まずはディレクトリ構造の全体像を整理する
- 次に代表機能を1つ選んで、処理の流れを通しで掴む
- 修正に入るときは、影響範囲調査の起点を作る
- 用語やドメイン知識を辞書化して、仕様と実装を繋げる
途中参加のキャッチアップは焦りやすいですが、最初のとっかかりを作る用途として利用できたかと思います。