「最終アプリ設計」でやることの全体像
ここまでで、単発の画面やミニアプリは作れるところまで来ています。
ここから一歩進めて、
- 複数画面がある
- データを共通の前提で扱う
- 実装の順番まで見通す
という「小さいけれど一つのアプリ」を意識して設計してみます。
いきなり巨大プロダクトは要りません。
ここでは例として「講座管理ミニアプリ」を題材に、
仕様を言葉で決める
画面一覧を作る
データ構造を設計する
実装の順番（計画）を立てる
という流れを、一気に体験してもらいます。
仕様決定（何ができるアプリにするか）
まず「できること」を文章で決める
題材として、「Next.js × React 入門講座サイトのミニ管理アプリ」を考えます。
ユーザーは「学習者」、アプリの目的は「講座の一覧を見て、詳細を確認し、自分の進捗を管理する」です。
このアプリでできることをシンプルにまとめるとこうなります。
講座一覧を閲覧できる。
講座の詳細を閲覧できる。
自分が「完了」した講座にチェックを付けられる。
これに少し肉付けすると、次のようになります。
トップページでアプリの説明と「講座一覧を見る」リンクがある。
講座一覧ページで、講座カードがタイトル・レベル・概要付きで並ぶ。
各カードから「詳細」ページへ遷移できる。
詳細ページで、その講座の内容説明と「完了にする／未完了に戻す」ボタンがある。
完了した講座は一覧上で「完了済み」バッジが付く。
「誰が、何のために、何ができれば“完成”と言えるのか」を、ここまでハッキリ言語化しておくと、
実装中に迷子になりにくくなります。
画面一覧作成（URL とページの洗い出し）
必要な画面を全部出して、URL を割り当てる
仕様が見えたので、次は「何画面必要か」を洗い出します。
今回のアプリでは、次の 3 画面があれば十分です。
トップページ
講座一覧ページ
講座詳細ページ
Next.js 的に見ると、URL とファイルはおおよそこうなります。
トップページ
URL: /
ファイル: app/page.tsx
講座一覧ページ
URL: /lessons
ファイル: app/lessons/page.tsx
講座詳細ページ
URL: /lessons/[id]（例: /lessons/1）
ファイル: app/lessons/[id]/page.tsx
ここで「動的ルーティング（[id]）」も軽く使うことになりますが、
設計段階では「id ごとに詳細ページがある」と理解していればOKです。
各画面の中身をざっくり書き出す
画面ごとに、「何が載るか」を簡単に文章で書きます。
トップページ（/）
アプリのタイトル
アプリの簡単な説明
「講座一覧へ」ボタン
講座一覧（/lessons）
ページタイトル
講座カードの一覧（タイトル、レベル、概要、完了バッジ）
各カードから詳細ページへのリンク
講座詳細（/lessons/[id]）
選択された講座のタイトル
レベル
詳細説明
「完了にする／未完了に戻す」ボタン
「一覧に戻る」リンク
ここまで書けていると、
「ここからはコンポーネントに分割するだけだな」と見通しが立ちます。
データ構造設計（どんな形で持つか）
中心となる「講座」の型を設計する
アプリの中心は「講座」データです。
TypeScript で Lesson 型として設計してみます。
type LessonLevel = "初級" | "中級" | "上級";
type Lesson = {
id: number;
title: string;
level: LessonLevel;
summary: string;
description: string;
};
ここでのポイントは、
id … URL パラメータにも使う一意な番号
title … 一覧・詳細の両方で使うタイトル
level … 絞り込みや表示に使うレベル（文字列リテラルで限定）
summary … 一覧で使う短い概要
description … 詳細ページで使う長めの説明
と、「どの画面で何に使うか」を意識してフィールドを決めていることです。
進捗（完了状態）をどう持つか決める
「完了した講座」をどう管理するかも設計します。
選択肢はいくつかあります。
Lesson 型に isCompleted: boolean を足してしまう。
別に completedIds: number[] を持ち、「完了した id の配列」として管理する。
今回のような小さなアプリなら、Lesson に isCompleted を足す方法が素直です。
type Lesson = {
id: number;
title: string;
level: LessonLevel;
summary: string;
description: string;
isCompleted: boolean;
};
これで、
一覧画面では lesson.isCompleted を見てバッジ表示する
詳細画面ではこの値をトグル（true / false きりかえ）する
という動きがシンプルに書けます。
ここで一つ、実務っぽい視点も添えると、
将来的に「複数ユーザーで共有するサーバーサイドの講座データ」を想定すると、
講座の情報（title／level など）と「ユーザーごとの進捗」は分けたくなります。
が、今は「一人用のローカルなミニアプリ」なので、
まずはシンプルな isCompleted 方式で進めるほうが学習効率がいいです。
データをどこに置く前提にするか
今回は、API サーバーは用意せず、「フロント側にハードコードされたダミーデータ」で進める前提にします。
例えば app/lessons/data.ts のようなファイルを作り、そこに定義します。
// app/lessons/data.ts
export const initialLessons: Lesson[] = [
{
id: 1,
title: "React コンポーネント入門",
level: "初級",
summary: "コンポーネントと JSX の基本を学びます。",
description: "より詳しい説明…",
isCompleted: false,
},
// いくつか続ける…
];
これを一覧ページのクライアントコンポーネントの state の初期値として使うイメージです。
実装計画（どの順番で作るか）
一度に全部やらない。「段階」を決める
いきなり全部作ろうとすると、かなりの確率で途中でこんがらがります。
実務でも、「段階」を決めて小さく進めます。
ステップ1: データと一覧表示だけ
ステップ2: 詳細ページの表示
ステップ3: 完了状態の切り替え（一覧に反映）
ステップ4: 最低限のデザイン調整
こんな順番にすると、常に「動く状態」を保ちながら前に進めます。
ステップ1: データと一覧表示だけ
やることはシンプルです。
Lesson 型とダミーデータを定義する。/lessons ページで、その配列を map してカード表示する。
この段階では、「完了状態」「詳細ページ」はまだ考えません。
まずは「データ構造と画面がつながった」ことを確認します。
ステップ2: 詳細ページの表示
次に、
/lessons/[id] のページを作る
URL の id から、対応する Lesson を探して表示する
「一覧に戻る」リンクを付ける
ここでは一旦、完了状態のボタンは「見た目だけ」でも構いません。
目的は「動的ルーティングで、一覧→詳細の流れを作ること」です。
ステップ3: 完了状態の切り替え（状態管理）
ここが実務っぽいポイントです。
どこに state を持つか決める
isCompleted を切り替えるロジックを実装する
一覧と詳細の両方で同じ状態が反映されるようにする
最初は、「完了状態の管理は /lessons のページだけで完結させる」ようにします。
一覧ページをクライアントコンポーネントにして、
const [lessons, setLessons] = useState(initialLessons);
と持ち、
詳細ページには「現在の完了状態」をただ表示するだけにしてもよいです。
もう一歩攻めるなら、/lessons ページに完了トグルの処理を持たせつつ、
詳細ページは「URL の id に対応する Lesson を、親コンポーネントから props で受け取る」構成にするなど、
状態の“単一のソース”を考えてみるとかなり実務寄りの思考になります。
（ここはレベルが上がるので、今は「少なくとも isCompleted の state を一箇所にまとめる」くらいを意識すれば十分です）
ステップ4: デザインと UX の仕上げ
最後に、
完了済み講座のカードに「完了」バッジを表示する
完了済み講座のタイトルを薄くするなど、視覚的な差をつける
エラーやローディングは今回の範囲では最小限でよい
といった「見た目と体験」の調整をします。
ここまで来ると、
Next.js のページ／ルーティング
React の state／props／イベント
データ構造の設計
状態管理の設計
が一通り「一つのアプリ」という形でつながります。
まとめと、ここからの“本当の一歩”
この「最終アプリ設計」でやったことを整理すると、こうなります。
まず仕様を日本語で決め、「誰が何のために何ができれば完成か」を明確にした。
それをもとに、URL とページ構成（画面一覧）を洗い出し、Next.js のファイル構成に落とし込んだ。
中心となるデータ構造（Lesson 型）と進捗の持ち方（isCompleted）を設計し、どこに置くかの前提を決めた。
実装を「ステップ」に分け、常に動くものを保ちながら、機能を少しずつ足していく計画を立てた。
もしこの流れが少しでも「なるほど」と感じられたなら、
次にやってみてほしいのはこれです。
自分でアプリのテーマを一つ決める（メモアプリ、家計簿、読書ログなど何でもいい）。
同じ流れで「仕様 → 画面一覧 → データ構造 → 実装ステップ」を文章で書いてみる。
その文章を見せてもらえれば、
「ここは state をこっちに持つと楽になる」「ここは画面を分けたほうがいい」など、
完全に“実務レビュー”と同じ目線でフィードバックもできる。
そこから先は、もう「チュートリアルの世界」ではなく、
あなた自身のアプリを育てていくフェーズです。
設計の感覚は、そこで一気に本物になっていきます。