React 学習ガイド

ダークモード

7.7 案件参加に向けたチェックリスト ​

ここまでの章で、React と周辺エコシステムの地図を眺めてきました。最後に、実際に案件に合流したときの「最初の 1 時間」を順序付けしておきます。コード読解の入り口を固めておくと、作業スピードが目に見えて上がります。

焦らず、上から順に見ていけば大丈夫です。すべて既存資料の読み取りなので、コードを書く必要はありません。

図 7.7.1 最初の 1 時間の 4 ステップ ​

1. 資料を読むREADMEpackage.json.env.example2. 動かす依存インストールdev server 起動test / lint を試す3. 入口を読むルーティング入口Provider 配置状態 / フェッチ4. 運用を知るGit ブランチCI / デプロイPR テンプレ最初の 1 時間（書かずに読むだけ）既存の選択の「理由」を読み取るのが目的ですこの 4 ステップを済ませると、最初のタスクにスムーズに入れます

最初の 1 時間でやること ​

以下は、リポジトリをクローンした直後に順番に確認していく項目です。

リポジトリ全体 ​

  • [ ] README.md を開いて、プロジェクトの目的・セットアップ手順・既知の注意点を読みます。
  • [ ] package.json を開き、次を確認します。
    • name / version
    • dependencies と devDependencies の主要ライブラリ（これが案件のエコシステム選択です）。
    • scripts（dev / build / test / lint 等）。
    • packageManager フィールド（pnpm / npm / yarn のどれを使うか）。
  • [ ] .node-version / .nvmrc / engines フィールドで必要な Node.js バージョンを確認。
  • [ ] .env.example がある場合、必要な環境変数の一覧を把握します。
  • [ ] .gitignore で、リポジトリに入っていないファイル（ローカル設定など）の存在を知ります。

ディレクトリ構造 ​

  • [ ] ルート直下のディレクトリを眺め、構成パターンを把握します。
    • app/ があるか → Next.js App Router の可能性が高いです。
    • src/ があるか → Vite + React や Pages Router の可能性。
    • public/ → 静的アセット。
    • components/ / features/ / lib/ / hooks/ など、コード分類のルールを読み取ります。
  • [ ] tsconfig.json の paths / baseUrl を見て、パスエイリアス（@/components など）を確認。
  • [ ] next.config.* / vite.config.* を開いて、ビルド設定とプラグインを確認。

動かしてみる ​

  • [ ] 依存をインストールします（pnpm install など、そのリポジトリが採用しているコマンドで）。
  • [ ] 開発サーバを起動します（pnpm run dev など）。エラーが出たらまずそのメッセージを読み、.env 不足や Node.js バージョン不整合をチェック。
  • [ ] localhost:3000 などを開き、トップ画面が表示されることを確認。
  • [ ] テストがあれば実行します（pnpm run test）。失敗しているテストがあるかを把握します（既知の failing テストかどうかはチームに要確認）。
  • [ ] Lint を動かします（pnpm run lint など）。

コードの入口を見つける ​

  • [ ] ルーティングの入口 を特定します。
    • Next.js App Router: app/layout.tsx と app/page.tsx。
    • Next.js Pages Router: pages/_app.tsx と pages/index.tsx。
    • Vite + React Router: src/main.tsx と src/App.tsx（あるいは router.tsx のような設定）。
  • [ ] グローバル Provider の配置を確認します。QueryClientProvider、Redux Provider、テーマ Provider などがここに並びます。
  • [ ] 認証フロー の入口を特定します（middleware.ts / auth 関連のフック / API ルート）。

主要な状態管理の場所 ​

  • [ ] どのライブラリが使われているか確認します（Context / Zustand / Redux Toolkit / Jotai など）。
  • [ ] ストアまたは Provider がどこで定義されているかを読みます。
  • [ ] どんなデータが載っているかざっと眺めます（ユーザー情報、カート、UI 状態など）。

データフェッチの配置 ​

  • [ ] サーバー状態をどう扱っているか確認します。
    • TanStack Query / SWR / RTK Query のいずれか。
    • Next.js App Router の fetch + Server Components を使っているか。
    • 7.3 データフェッチ の判断軸を参照。
  • [ ] API のエンドポイント定義がどこに集まっているか探します（lib/api.ts や services/ などが典型）。

スタイリングの方針 ​

  • [ ] どのライブラリか確認します（Tailwind / CSS Modules / styled-components / Emotion）。
  • [ ] テーマ（色・タイポ・スペーシング）が定義されているファイルを探します（tailwind.config.* や theme.ts 等）。
  • [ ] デザインシステムのコンポーネント（Button / Input 等）が集約されている場所を確認します。

テストと品質 ​

  • [ ] テストがあるか。どのツールか（Vitest / Jest / Playwright）。
  • [ ] どの粒度で書かれているか（ユニット / 統合 / E2E のいずれか）。
  • [ ] カバレッジ計測があるか（coverage/ や CI の出力）。

Git 運用 / CI / デプロイ ​

  • [ ] デフォルトブランチ名（main / develop）。
  • [ ] ブランチ戦略（feature/xxx, release/xxx, trunk-based のどれに近いか）。
  • [ ] .github/workflows/ を開き、CI で何が動くかを確認します（lint / test / build / deploy）。
  • [ ] デプロイ先を確認します（Vercel / AWS / 社内インフラ）。プレビュー URL の仕組み。
  • [ ] Pull Request テンプレート (.github/pull_request_template.md) があれば読みます。

チームのルール ​

  • [ ] CONTRIBUTING.md / CODE_OF_CONDUCT.md があれば読みます。
  • [ ] コミットメッセージの規約（Conventional Commits か、日本語で書くか）を既存履歴から観察します。
  • [ ] コードレビューのフロー（誰が Approve する、何人必要、など）をチームに確認します。

「本サイトのどこを復習すべきか」対応表 ​

新しい案件で遭遇した要素について、復習が役に立つ章を下表にまとめます。

案件で見つけた要素復習すべき章
JSX / コンポーネントの書き方を忘れた3.2 JSX の本質, 3.3 コンポーネント
useState / useEffect の挙動に迷う3.4 状態 (state), 3.6 副作用 (useEffect)
key で警告が出る3.7 リストと key
フォームが思ったように動かない3.8 フォーム, 4.2 Actions / use / useOptimistic / useActionState
<Suspense> や use(promise) を見かけた4.3 Suspense, 4.2 use
Context が絡んで再レンダーが謎4.4 Context, 4.6 パフォーマンス
forwardRef / useRef の書き方4.5 Refs
memo / useMemo / useCallback の判断4.6 パフォーマンス
use server / use client が出てきた5.2 Server vs Client Components, 5.4 Server Actions
Next.js App Router の構造を知りたい5.3 Next.js App Router 入門
「なぜ React は速いのか」を説明する必要6.1 Virtual DOM のアイデア, 6.2 Reconciliation と Fiber
フックの仕組みが気になる6.3 Hook はどう動いているか
状態管理ライブラリの選び方7.2 状態管理
データフェッチのライブラリの選び方7.3 データフェッチ
スタイリングの選び方7.4 スタイリング
テストの書き方7.5 テスト入門
挙動がおかしい / 何が起きているか分からない7.6 DevTools とデバッグ

図 7.7.2 参加初日の流れ ​

最後に ​

受託案件は「他人のコードに入る」ことから始まります。自分が書いたわけではない選択が並んでいるのが通常で、その選択には何らかの理由があります。Part 1 で見たように、React そのものが特定の問題意識から生まれたのと同じで、案件に入っている Zustand や Tailwind や Vitest も、何らかの制約の下で合理的に選ばれた結果です。

最初は違和感があっても、まずは既存の選択の 理由を読み取る ところから始めてみてください。そのうえで、改善できそうなところ（テストを足す、DevTools の使い方をチームで揃える、など）から貢献を始めるのが、摩擦の少ない合流の仕方です。

この Part 7 の 7 つの章は、そのための下敷きを提供しました。各ライブラリの使い方そのものは公式ドキュメントに譲り、本サイトは「選ぶ軸」と「読む順番」に集中しました。実務で出会う問題の多くは、ここで引いた地図の上に位置づけられるはずです。

急がなくて大丈夫です。分からないところは、その場面に出会ってから該当章に戻ってきてください。

参照ソース ​

この章はここまでの内容のまとめであり、一次資料は各章末に掲載しています。次を参照してください。