Week1～3を振り返る！Claude Codeで本格アプリ開発、ここまでの道のり【Week4予習付き】
こんにちは！YaroTechです。
出張中で実践作業はお休みです😊
でも、Week1から3まで駆け抜けてきた「note記事ダッシュボード」プロジェクト。
ここで一度立ち止まって、何を作ってきたのか振り返りたいと思います。
Week1で何をした？
Week2で何が変わった？
Week3で何を実現した？
そして、Week4で何をする？
この記事は「振り返り＋予習」の2本立てです！
Week1～3の道のりを確認して、Week4に向けて準備しましょう💪
さらに、Week2～3で登場した専門用語（Zustand、CRUD、テスト用語等）を初心者向けに丁寧に解説します。
※Week1の基礎用語（React、TypeScript、Vite等）は、Day86.5の保存版記事で詳しく解説しています。この記事では、Week2以降の新しい用語に焦点を当てます。
※見出し画像のプロンプトは一番下におまけで公開中！
📚 この記事とDay86.5の使い分け
この記事を読む前に、Day86.5との違いを理解しておきましょう。
Day86.5（既存記事）
役割: Week1の「用語辞典」
React、TypeScript、Vite、npm等
Week1基盤構築の技術用語に特化
辞書的・網羅的・詳細
「困ったらここを見る」リファレンス
関連記事: Day86.5: 【保存版】Week 1基盤構築で使う用語を初心者向けに完全解説！React、TypeScript、Vite...これだけ知っておけばOK
Day89（この記事）
役割: Week1～3の「地図」＋Week4の「下見」
Week1～3で何を作ったかの振り返り
Week2～3の新用語解説（Zustand、CRUD等）
Week4の予習（テスト関連用語）
「全体像を掴んで、次に進むための準備」ガイド
例えるなら:
Day86.5 = 辞書（困ったときに引く）
Day89 = ガイドブック（旅の全体像と次の目的地）
🎯 この記事で得られること
✅ Week1～3の開発の流れが分かる
✅ 「何を作ってきたか」全体像を掴める
✅ Week2～3の用語を初心者向けに理解
✅ Week4で何をするか予習できる
✅ テスト関連用語の基礎知識
✅ 次回の実践編へスムーズに進める準備
🏗️ Week1～3の振り返り：何を作ってきたか
Week1: 基盤構築（家の土台を作る）
やったこと:
PM Claudeが18週間264時間の開発計画を作成
React + TypeScript + Vite環境構築
ディレクトリ構造の設計
React Routerでルーティング設定
Tailwind CSSの導入
成果物:
動くけど地味な3ページ（Dashboard、Analytics、Settings）
例えるなら: 家の骨組みが完成した状態
構造はしっかりしている
でも、見た目は地味
住むにはまだ早い
PM Claudeの見積: 30時間 → 実測: 約2時間（93%短縮！）
関連記事: Day86: Imagine終了でも大丈夫！実践🚀Claude Codeでチーム開発 - Week 1基盤構築編では、Week1の実践過程を詳しく紹介しています。
Week2: UI実装（内装工事でリッチに）
やったこと:
統計カードコンポーネント作成（4種類）
Chart.jsでグラフ実装（投稿数推移、カテゴリ分布）
記事追加フォームコンポーネント
人気記事カード
レスポンシブデザイン調整
成果物:
見た目は完璧なリッチダッシュボード！
でも...すべて「モックデータ」（ダミーデータ）😅
例えるなら: 内装が豪華になった家
見た目は素晴らしい
でも、まだ「展示用」
実際には住めない（データがない）
PM Claudeの見積: 30時間 → 実測: 約2時間半（92%短縮！）
関連記事: Day87: 基礎から大変身！Claude Code Week 2でUI実装 - リッチダッシュボード完成編では、Week2のUI実装過程を詳しく紹介しています。
Week3: データ管理・永続化（魂を入れる）
やったこと:
Zustand Store本格実装
LocalStorageでデータ永続化
note_daily_log.txtからデータ読み込み
CRUD操作完全実装（Create, Read, Update, Delete）
エラーハンドリング強化
成果物:
実データが表示される、本物のアプリケーション！
ビフォーアフター:
| 項目 | Week2（モック） | Week3（実データ） |
|------|----------------|-------------------|
| 総投稿数 | 150記事 | 87記事 ✅ |
| 連続投稿日数 | 45日 | 87日 ✅ |
| 今月の投稿数 | 23記事 | 4記事 ✅ |
例えるなら: 家に電気・水道・ガスが通った状態
見た目も良い
データも動く
実際に住める！
PM Claudeの見積: 29時間 → 実測: 約2時間半（91%短縮！）
関連記事: Day88: Week3実践！データ管理・永続化でダッシュボードに命を吹き込むでは、Week3のデータ管理実装過程を詳しく紹介しています。
Week1～3の全体像
| Week | テーマ | 例え | 完成度 |
|------|--------|------|--------|
| Week1 | 基盤構築 | 家の骨組み | 20% |
| Week2 | UI実装 | 内装完成 | 50% |
| Week3 | データ管理 | 電気・水道開通 | 80% |
| Week4 | 品質向上 | 最終仕上げ | 100% |
驚異的な効率化:
PM Claudeの見積: 89時間
実際の所要時間: 約7時間
効率化率: 92%短縮！
📖 Week2～3で登場した用語解説（初心者向け）
Week1の基礎用語（React、TypeScript、Vite等）は、Day86.5で詳しく解説しています。
ここでは、Week2～3で新登場した用語を初心者向けに解説します！
Week2の用語
Chart.js（チャートジェイエス）
一言で: グラフを簡単に描けるツール
詳しく説明:
JavaScriptのライブラリ（便利な道具箱）
折れ線グラフ、棒グラフ、円グラフ等が作れる
プログラミング初心者でも使いやすい
HTMLに数行書くだけで美しいグラフが完成
具体例:
noteの投稿数推移グラフ
- 7月: 31記事
- 8月: 31記事
- 9月: 21記事
- 10月: 4記事
→ これを折れ線グラフで視覚化！なぜ便利？:
数字の羅列より直感的
トレンドが一目で分かる
インタラクティブ（マウスを乗せると詳細表示）
レスポンシブデザイン
一言で: 画面サイズに応じてレイアウトが変わる
詳しく説明:
PC、タブレット、スマホで最適表示
自動的にレイアウト調整
Tailwind CSSで簡単実装
具体例:
PCで見る場合:
[統計カード][統計カード][統計カード][統計カード]
→ 横に4つ並ぶ
スマホで見る場合:
[統計カード]
[統計カード]
[統計カード]
[統計カード]
→ 縦に4つ並ぶなぜ重要？:
スマホユーザーが多い（70%以上）
ユーザー体験の向上
SEO（検索順位）にも影響
モックデータ
一言で: 開発用の仮データ
詳しく説明:
ダミーデータ、テストデータとも呼ぶ
実際のデータの代わりに使う
開発中に「それっぽい」表示を確認できる
具体例:
モックデータ:
- 総投稿数: 150記事 ← 架空の数字
- 連続投稿日数: 45日 ← 架空の数字
実データ:
- 総投稿数: 87記事 ← 本物の数字
- 連続投稿日数: 87日 ← 本物の数字なぜ使う？:
UIを先に作れる（データを待たなくていい）
デザインの確認に便利
開発をスピードアップ
Week3の用語
Zustand（ズスタンド）
一言で: Reactのデータ管理ツール
詳しく説明:
React用の状態管理ライブラリ
アプリ全体でデータを共有できる
Reduxより簡単（学習コストが低い）
具体例:
Zustandなし:
Page A → データを持つ
Page B → データがない（使えない）
Zustandあり:
Zustand Store ← データを一元管理
↓ ↓
Page A Page B
どちらからでもデータにアクセス可能！なぜ便利？:
コンポーネント間でデータ共有が簡単
コード量が少ない
TypeScriptとの相性が良い
LocalStorage（ローカルストレージ）
一言で: ブラウザにデータを保存する仕組み
詳しく説明:
ブラウザの機能の1つ
ページを閉じてもデータが残る
5-10MBまで保存可能（テキストデータなら十分）
具体例:
LocalStorageなし:
1. 記事を追加
2. ブラウザを閉じる
3. 開き直す
4. データが消えてる😢
LocalStorageあり:
1. 記事を追加 → LocalStorageに保存
2. ブラウザを閉じる
3. 開き直す
4. データが残ってる！😊なぜ便利？:
サーバーが不要（シンプル）
オフラインでも使える
設定やユーザーデータの保存に最適
CRUD操作（クラッド操作）
一言で: データ操作の基本4つ
詳しく説明:
Create（作成）: 新しいデータを追加
Read（読み込み）: データを表示
Update（更新）: データを編集
Delete（削除）: データを削除
具体例:
note記事ダッシュボードでのCRUD:
- Create: 新しい記事を追加
- Read: 記事一覧を表示
- Update: 記事のいいね数を更新
- Delete: 不要な記事を削除なぜ重要？:
すべてのアプリの基本
データベース操作の基礎
CRUDができれば、ほとんどのアプリが作れる
データパース
一言で: テキストを読み込んで分解する
詳しく説明:
テキストデータをプログラムで扱える形式に変換
CSVやログファイルの処理によく使う
具体例:
元のテキスト（note_daily_log.txt）:
2025/07/07|記事タイトル|10|2|5|https://...|メモ
パース後（JavaScriptのオブジェクト）:
{
date: "2025/07/07",
title: "記事タイトル",
likes: 10,
comments: 2,
followers: 5,
url: "https://...",
memo: "メモ"
}なぜ必要？:
ファイルからデータを読み込む
プログラムで処理できる形式に変換
アプリで表示・編集できるようにする
データ永続化
一言で: データを保存して消えないようにする
詳しく説明:
アプリを閉じてもデータが残る仕組み
LocalStorage、データベース等に保存
具体例:
永続化なし:
1. 記事を追加
2. ページをリロード
3. データが消える😢
永続化あり:
1. 記事を追加 → 自動保存
2. ページをリロード
3. データが残ってる😊実装方法:
簡単: LocalStorage
中級: IndexedDB
上級: サーバーサイドDB（MySQL、PostgreSQL等）
エラーハンドリング
一言で: エラーが起きたときの対処
詳しく説明:
Try-Catchでエラーをキャッチ
ユーザーに分かりやすいメッセージを表示
アプリがクラッシュしないようにする
具体例:
エラーハンドリングなし:
ファイル読み込み失敗 → アプリが止まる😢
エラーハンドリングあり:
try {
ファイル読み込み
} catch (error) {
「ファイルが見つかりません」と表示
}
→ アプリは動き続ける😊なぜ重要？:
ユーザー体験の向上
デバッグが簡単
本番環境で必須
🚀 Week4の予習：品質向上・テスト
Week4では、アプリを「本番レベル」に仕上げます！
PM Claudeの計画では36時間相当の作業です。
Week4でやること
| ID | タスク | 時間 |
|----|--------|------|
| T301 | 単体テスト実装 | 10h |
| T302 | E2Eテスト実装 | 10h |
| T303 | アクセシビリティ対応 | 6h |
| T304 | パフォーマンス最適化 | 6h |
| T305 | コードレビュー | 4h |
合計: 36時間
実測予想: 約3-4時間（90%短縮！）
Week4の用語解説（テスト関連）
単体テスト（Unit Test）
一言で: 1つ1つの機能が正しく動くか確認
詳しく説明:
小さな機能単位でテスト
自動でテストを実行
バグを早期発見
具体例:
テストする機能: 「記事追加」
1. 新しい記事を追加
2. 記事数が1増えることを確認
3. 追加した記事のタイトルが正しいか確認
テストコード:
expect(記事数).toBe(88); // 87 + 1 = 88
expect(タイトル).toBe("Day89");なぜ重要？:
バグを早く見つける
コード変更時の安心感
ドキュメント代わりになる
Jest（ジェスト）
一言で: JavaScriptのテストツール
詳しく説明:
Facebook（Meta）製
JavaScriptとTypeScript両方使える
設定が簡単
具体例:
test('記事が追加される', () => {
const result = addArticle("Day89");
expect(result).toBe(true);
});なぜ人気？:
セットアップが簡単
高速に実行できる
React等と相性が良い
React Testing Library
一言で: React用のテストツール
詳しく説明:
ユーザー視点でテスト
「実際の使い方」に近い形でテスト
Jestと一緒に使う
具体例:
// ボタンをクリックして記事が追加されるかテスト
const button = screen.getByText("記事を追加");
fireEvent.click(button);
expect(screen.getByText("Day89")).toBeInTheDocument();なぜ良い？:
ユーザー視点のテスト
実装の詳細に依存しない
リファクタリングしやすい
E2Eテスト（End to End Test）
一言で: アプリ全体を通しでテスト
詳しく説明:
ユーザーの操作を再現
実際のブラウザで動作確認
「記事追加→保存→表示」の一連の流れをテスト
具体例:
E2Eテストのシナリオ:
1. ダッシュボードを開く
2. 「記事を追加」ボタンをクリック
3. タイトルに「Day89」と入力
4. 「保存」ボタンをクリック
5. 記事一覧に「Day89」が表示されることを確認なぜ重要？:
実際のユーザー操作を再現
統合的なバグを発見
リリース前の最終確認
Playwright（プレイライト）
一言で: E2Eテストツール
詳しく説明:
Microsoft製
Chrome、Firefox、Safari対応
ブラウザを自動操作
具体例:
await page.goto('http://localhost:5173');
await page.click('text=記事を追加');
await page.fill('input[name="title"]', 'Day89');
await page.click('text=保存');
expect(await page.textContent('.article-list')).toContain('Day89');なぜ人気？:
速い（他のツールより高速）
複数ブラウザ対応
スクリーンショット・動画撮影機能
アクセシビリティ（Accessibility）
一言で: 誰でも使いやすいデザイン
詳しく説明:
障害のある方も使える
キーボード操作対応
音声読み上げ対応
色のコントラスト
具体例:
悪い例:
<button>×</button> ← 何のボタンか分からない
良い例:
<button aria-label="記事を削除">×</button>
→ 音声読み上げで「記事を削除ボタン」と読まれるなぜ重要？:
すべての人が使える
法律で義務化されている国も
SEOにも良い影響
WCAG（Web Content Accessibility Guidelines）
一言で: Webアクセシビリティの国際基準
詳しく説明:
W3Cが策定
レベルA、AA、AAAの3段階
多くのサイトはAA準拠を目指す
基準例:
色のコントラスト比4.5:1以上
キーボードのみで操作可能
画像にalt属性（代替テキスト）
なぜ必要？:
グローバルスタンダード
官公庁サイトは準拠が義務
企業イメージ向上
Lighthouse（ライトハウス）
一言で: Webサイトの通信簿
詳しく説明:
Google製の評価ツール
パフォーマンス、アクセシビリティ等を採点
Chrome DevToolsに標準搭載
評価項目:
Performance（パフォーマンス）
Accessibility（アクセシビリティ）
Best Practices（ベストプラクティス）
SEO
目標スコア: 各項目90点以上
なぜ便利？:
改善点が明確
無料で使える
SEO対策にもなる
パフォーマンス最適化
一言で: アプリを高速化する
詳しく説明:
読み込み時間短縮
メモリ使用量削減
画像圧縮、コード分割等
具体例:
最適化前:
- 初期読み込み: 3.5秒
- 画像サイズ: 5MB
- JavaScriptファイル: 2MB
最適化後:
- 初期読み込み: 1.2秒（66%改善）
- 画像サイズ: 500KB（90%削減）
- JavaScriptファイル: 300KB（85%削減）なぜ重要？:
ユーザー体験の向上
SEOランキング向上
サーバーコスト削減
コードレビュー
一言で: コードを見直して改善
詳しく説明:
コードの品質チェック
バグ発見
読みやすさ改善
チェック項目:
変数名は分かりやすいか
コメントは適切か
重複コードはないか
エラーハンドリングは十分か
なぜ重要？:
バグを減らす
保守性向上
チーム開発で必須
✅ Week1～3で完成したもの・まだできてないこと
完成した機能 ✅
✅ note記事ダッシュボード
✅ 統計表示（総投稿数、連続日数、今月の投稿数、平均いいね数）
✅ グラフ表示（投稿数推移、カテゴリ分布）
✅ 記事一覧表示
✅ 記事追加・編集・削除（CRUD操作）
✅ データ永続化（LocalStorage）
✅ レスポンシブデザイン
まだできていないこと ❌
❌ 単体テスト
❌ E2Eテスト
❌ アクセシビリティ対応
❌ パフォーマンス最適化
❌ 本番環境デプロイ
Week4で完成する姿 🎯
Week4が終われば：
✅ テストカバレッジ80%以上
✅ アクセシビリティスコアA（WCAG AA準拠）
✅ Lighthouseスコア90点以上
✅ 本番環境にデプロイ可能
完成度:
Week3終了時: 80%
Week4終了後: 100% 🎉
💡 Week1～3で学んだこと
1. 基盤の重要性
Week1の基盤がしっかりしていたから、Week2～3がスムーズに進みました。
具体的に:
TypeScript型定義 → 型エラーゼロ
コンポーネント設計 → 拡張が容易
ディレクトリ構造 → 迷わず配置
教訓: 「急がば回れ」、基礎をしっかり作る
2. 段階的な開発の効率性
基盤→UI→データと順番に作るのが効率的でした。
理由:
各週で明確なゴールがある
成果が見えやすい（モチベーション維持）
問題の切り分けが簡単
教訓: 一気に作ろうとしない、段階的に進める
3. サブエージェントの威力
PM Claudeの計画、Dev Claudeの実装。
役割分担が明確で、効率的でした。
実際の効果:
PM Claude: 264時間の計画を30分で作成
Dev Claude: 各週の実装を2-3時間で完了
合計: 92%の時間短縮
教訓: 適切な役割分担で効率が劇的に向上
4. 見積との差
PM Claudeの見積: 89時間
実測: 約7時間
効率化率: 92%短縮！
なぜこんなに速い？:
Claude Codeの自動化能力
shift+tabの全編集自動承認
Week1の完璧な基盤
教訓: AI支援開発の可能性は無限大
🎯 Week4への心構え
テストは「後回し」にしない
Week4でテストを実装しますが、本来は：
Week1: 基盤＋テスト環境構築
Week2: UI＋単体テスト
Week3: データ＋統合テスト
理由: 後からテスト追加は大変
教訓: 次回のプロジェクトでは最初からテスト
アクセシビリティは最初から考える
Week4でアクセシビリティ対応しますが、本来は：
Week2のUI実装時に配慮すべき
aria-label、role等を最初から
理由: 後から追加は手間
教訓: デザイン段階から意識
パフォーマンスは定期的にチェック
Week4で最適化しますが、本来は：
各週でLighthouseスコア確認
問題があれば即座に改善
理由: 後からの最適化は複雑
教訓: 定期的な計測が重要
品質向上は地味だけど重要
Week1～3は「作る」フェーズで楽しい。
Week4は「磨く」フェーズで地味。
でも、本番リリースには必須です。
Week4の価値:
ユーザー体験の向上
バグの減少
保守性の向上
プロフェッショナルな仕上がり
🔗 関連記事
今回の内容に関連する過去記事もぜひご覧ください：
関連記事: Day88: Week3実践！データ管理・永続化でダッシュボードに命を吹き込むでは、Week3のデータ管理実装過程を詳しく紹介しています。
関連記事: Day87: 基礎から大変身！Claude Code Week 2でUI実装 - リッチダッシュボード完成編では、Week2のUI実装過程を詳しく紹介しています。
関連記事: Day86.5: 【保存版】Week 1基盤構築で使う用語を初心者向けに完全解説！React、TypeScript、Vite...これだけ知っておけばOKでは、Week1の重要用語を詳しく解説しています。
関連記事: Day86: Imagine終了でも大丈夫！実践🚀Claude Codeでチーム開発 - Week 1基盤構築編では、Week1の基盤構築過程を詳しく紹介しています。
📝 まとめ
✅ Week1～3で達成したこと
Week1: 基盤構築
React + TypeScript + Vite環境
PM Claudeの18週間計画
しっかりした土台
Week2: UI実装
リッチなダッシュボード
Chart.jsグラフ
レスポンシブデザイン
Week3: データ管理・永続化
Zustand Store
LocalStorage永続化
CRUD操作完成
完成度: 80%（本番レベルまであと一歩！）
🎯 Week4で目指すもの
品質向上・テスト（36時間相当）:
単体テスト実装
E2Eテスト（Playwright）
アクセシビリティ対応
パフォーマンス最適化
コードレビュー
完成度: 100%（本番リリース可能！）
💪 次のアクション
今週中に:
この記事を保存（振り返り用）
Week4の用語を予習
次回の実践編を楽しみに待つ
来週、Week4実践:
単体テスト実装
E2Eテスト実装
アクセシビリティ対応
パフォーマンス最適化
本番リリース準備完了！
Week1～3の道のりを振り返り、Week4への準備ができました💪
段階的な開発、適切な役割分担、AI支援の組み合わせが、驚異的な効率化を生み出しました。
次回、Week4実践編で完成させます！
🚀 次回予告
Day90: Week4実践！品質向上・テストでアプリを磨き上げる
出張から戻ったら、いよいよWeek4の実践です！
Jest + React Testing Libraryで単体テスト実装
Playwrightで E2Eテスト実装
WCAG AA準拠のアクセシビリティ対応
Lighthouseスコア90点以上を目指す
本番リリース準備、完了させます！
Week1～3で作り上げたアプリを、プロフェッショナルレベルに仕上げます💪
🎨 おまけ：見出し画像作成プロンプト
今日の見出し画像のベースはチャッピー（ChatGPT）に下記プロンプトで作成してもらいました！：
詳細なアニメの美意識の画像を作成してください。表情豊かな瞳、なめらかな網掛けセルの色使い、はっきりした線画を使用します。アニメのシーンに典型的な身ぶりと雰囲気で、心情と登場人物の存在を強調してください。
下記条件のnote見出し画像をサイズは横長で作成してください。サイズは必ず横長で作成してください。
## 🎨 見出し画像案
### デザインコンセプト
- **背景**: ダークブルーから鮮やかなパープルへの美しいグラデーション
- **メインビジュアル**: Week1→Week2→Week3の道のり（イラストベース）
- 左側: Week1（基盤・土台のアイコン、シンプルな構造イメージ）
- 中央: Week2（UI・内装のアイコン、華やかなデザイン要素）
- 右側: Week3（データ・魂のアイコン、データフローの視覚化）
- 各週を矢印（→）で繋いで「道のり」を表現
- **テーマ**: 振り返り、道のり、全体像、成長、ステップバイステップ
- **雰囲気**: 初心者向けの柔らかく親しみやすいトーン
### テキスト要素
- 上部: 「Claude Code実践シリーズ」（白色・太字・24pt）
- 中央上: 「Week1～3 振り返り」（黄色・48pt・太字）
- 中央中: 「ここまでの道のり」（白色・36pt）
- 下部: 「＋Week4予習」（白色・24pt）
### 装飾
- Week1アイコン: 基盤・土台（建物の構造、骨組み）
- Week2アイコン: UI要素（グラフ、カード、デザイン）
- Week3アイコン: データ（データベース、ストレージ）
- 矢印で各週を繋ぐ（進捗、成長を表現）
- パステルカラーのアクセント（初心者向けの柔らかさ）
- YaroTechロゴ（右下・12pt・控えめ）
### 作成手順
1. スライドサイズ（1536×1024px）
2. ダークブルー→パープルのグラデーション背景を設定
3. 左側にWeek1のアイコン配置（基盤・土台イメージ）
4. 中央にWeek2のアイコン配置（UI・デザインイメージ）
5. 右側にWeek3のアイコン配置（データイメージ）
6. 矢印（→）で3つの週を繋ぐ
7. 「Claude Code実践シリーズ」を上部に配置（白色・太字）
8. 「Week1～3 振り返り」を中央上部に大きく配置（黄色・48pt）
9. 「ここまでの道のり」を中央に配置（白色・36pt）
10. 「＋Week4予習」を下部に配置（白色・24pt）
11. 装飾要素を追加（アイコン、矢印、パステルカラーのアクセント）
12. YaroTechロゴを右下に12ptで控えめに配置#YaroTech #ClaudeCode #React #TypeScript #Zustand #テスト #アクセシビリティ #初心者向け #用語解説 #振り返り
いいなと思ったら応援しよう！
