Day 80：中規模アプリ設計
Day 80では、最終制作に向けて、作りたいアプリを決め、必要な機能、データ構造、画面を設計します。すぐにコードを書き始めるのではなく、先に「誰が何のために使うのか」「どんな情報を扱うのか」「画面で何ができるのか」を整理するのが今回の目標です。
中規模アプリというと難しく聞こえるかもしれませんが、最初から大きなサービスを作る必要はありません。小さな機能をいくつか組み合わせ、データの保存や画面の切り替えも行うアプリを、無理のない範囲で設計します。今回は例として、学習内容や学習時間を記録する「学習記録アプリ」を設計します。別のアプリを作りたい場合も、同じ手順を応用できます。
設計してから作る理由
作りたいものを決めないままコードを書き始めると、途中で機能が増え続けたり、データの持ち方が決まらず何度も書き直したりしがちです。最初に設計をすると、作る範囲や必要なデータが見えるため、完成までの道筋を立てやすくなります。
今回の設計は、次の順番で進めます。
- どんな人の、どんな困りごとを解決するか決めます。
- アプリの最小限の機能を選びます。
- 扱うデータと、その関係を考えます。
- 画面に必要な部品と操作の流れを決めます。
- 機能を実装する順番と、完成条件を決めます。
ステップ1：作りたいアプリを決める
まず、アプリ名だけでなく「誰が、何をできるようになるアプリか」を一文にします。これを目的の説明として使います。
今回の例では、次のように決めます。
学習した内容と時間を記録し、あとから学習履歴を振り返れるアプリです。
目的が一文で説明できると、必要な機能と、今は作らなくてよい機能を分けやすくなります。たとえば、この目的に対して、学習記録の登録や一覧表示は必要ですが、ユーザー同士の交流機能や通知機能は、最初の版ではなくても成立します。
アプリを決めるときは、次の問いに答えてみましょう。
- 誰が使うアプリですか。
- どんな困りごとを解決しますか。
- 使ったあとに、何ができるようになりますか。
ステップ2：機能を洗い出し、優先順位をつける
思いついた機能をすべて最初から作ると、完成までに時間がかかります。まずはアプリの中心となる「最小限の機能」を選び、そのあとに追加機能を検討します。
学習記録アプリなら、次のように分けられます。
- 最初に作る機能：記録の追加、記録一覧の表示、記録の削除
- 余裕があれば追加する機能：記録の編集、日付やキーワードでの絞り込み、学習時間の合計表示
- あとで検討する機能：アカウント登録、複数端末との同期、通知、グラフ表示
最初の版で必須にする機能を絞ることが大切です。たとえば、記録を追加できても一覧で確認できなければ、アプリとして使いにくくなります。一方、グラフや通知は便利でも、基本の記録機能が完成する前に作る必要はありません。
ステップ3：機能をユーザーの操作に言い換える
機能名だけでは、実際に利用者が何をするのかが曖昧なことがあります。そこで、操作の流れとして書き出します。
- 利用者は、学習した内容と時間を入力します。
- 利用者は、「記録する」ボタンを押します。
- アプリは、入力内容を確認して記録を保存します。
- アプリは、保存した記録を一覧へ表示します。
- 利用者は、不要な記録を削除できます。
この流れが、画面設計や関数設計の土台になります。ボタンを置くだけでなく、押した後に何が起きるかまで決めておきましょう。
ステップ4：データ構造を考える
次に、アプリが保存する情報を決めます。学習記録には、たとえば次の情報が必要です。
- `id`：記録を区別するためのID
- `title`：学習した内容
- `minutes`：学習時間を分単位で保存した数値
- `date`：学習した日付
- `note`：補足メモ
- `createdAt`：記録を作成した日時
JavaScriptのオブジェクトで表すと、次のようになります。
// 学習記録1件分のデータ例
const studyRecord = {
id: "record-001", // 記録を区別するためのID
title: "JavaScriptの関数", // 学習した内容
minutes: 45, // 学習時間（分）
date: "2026-11-07", // 学習した日付
note: "引数と戻り値を復習", // 補足メモ
createdAt: "2026-11-07T10:30:00.000Z" // 作成日時
};ここで大切なのは、データをどんな型で持つかを決めることです。学習時間を"45分"という文字列で保存するより、45という数値で保存するほうが、合計時間を計算しやすくなります。画面に表示するときに「45分」と整えればよいのです。
また、削除や編集の対象を間違えないように、各記録には一意のIDを持たせます。配列の何番目かだけを識別に使うと、並び替えや削除のあとに対象が変わる可能性があるため、IDで管理するのが基本です。
データの入力ルールも決める
データ項目を決めたら、どんな値を受け付けるかも考えます。
- 学習内容は必須で、空文字を許可しません。
- 学習時間は0より大きい数値にします。
- 学習日は日付として扱える形式にします。
- 補足メモは任意にします。
こうしたルールがあると、入力チェックやエラーメッセージを設計しやすくなります。入力された値をそのまま保存するのではなく、形式や範囲を確認してから扱うことが大切です。
ステップ5：画面を設計する
次に、画面にどの部品を置くかを考えます。最初は色や装飾にこだわらず、何をどこに置くかを文字や簡単な図で表せば十分です。こうした簡易的な画面案をワイヤーフレームと呼びます。
┌─────────────────────────┐
│ 学習記録アプリ │
├─────────────────────────┤
│ 学習内容 [________________] │
│ 学習時間 [____] 分 │
│ 学習日 [__________] │
│ メモ [________________] │
│ [記録する] │
├─────────────────────────┤
│ 学習履歴 │
│ 合計：○分 │
│ ・JavaScriptの関数 45分 [削除] │
│ ・配列の復習 30分 [削除] │
└─────────────────────────┘画面を考えるときは、各部品の役割をはっきりさせます。
- 入力フォーム：新しい学習記録を入力します。
- 状態メッセージ：保存完了や入力エラーを知らせます。
- 合計表示：登録済みの学習時間を表示します。
- 記録一覧：保存済みの記録を確認します。
- 削除ボタン：選んだ記録を削除します。
ステップ6：画面の状態を設計する
画面は、記録があるときだけでなく、まだ何もないときやエラーが起きたときにも適切に表示できる必要があります。
- 初回表示：記録がないことと、最初の操作方法を案内します。
- 入力中：フォームに入力された値を保持します。
- 保存成功：記録を一覧へ追加し、成功メッセージを表示します。
- 入力エラー：何を直せばよいかを具体的に伝えます。
- 記録がある状態：一覧と合計時間を表示します。
「何も表示されない」状態を避けることも、画面設計の一部です。たとえば記録が0件なら、「記録がありません。最初の学習内容を入力してください」と案内できます。
ステップ7：機能を処理の役割に分ける
画面と機能が決まったら、Day 72で学んだ考え方を使って処理を分けます。たとえば、次の役割が考えられます。
- データ処理：入力値の確認、合計時間の計算、記録の検索
- 保存処理：記録の読み込みと保存
- UI処理：一覧やメッセージの表示
- アプリ全体の処理：ボタン操作を受け取り、必要な関数を呼び出す
ファイルに分ける場合は、たとえば次のような構成から始められます。
study-record-app/
├── index.html
├── styles.css
└── js/
├── app.js # 画面イベントと処理全体の流れ
├── storage.js # データの読み込み・保存
├── study.js # 入力確認や合計計算などのデータ処理
└── ui.js # フォームや一覧の表示初めから細かく分けすぎる必要はありません。役割が増えて、ファイルが探しにくくなってきたときに分割を検討すれば十分です。
データの保存方法を選ぶ
このアプリの初期版では、ブラウザーのlocalStorageを使って、同じブラウザー内に記録を保存する設計が考えられます。サーバーを用意せずに試せるため、学習用アプリに向いています。
ただし、localStorageに保存したデータは、基本的に同じブラウザーの同じ環境で利用するものです。別の端末との同期やユーザーアカウントによる共有には、サーバー側の仕組みが必要になります。これは最初の版に含めず、将来の追加機能として扱うと範囲を絞れます。
保存データはJSON文字列へ変換して扱います。
// 学習記録をJSON形式で保存する例
const records = [studyRecord];
// 配列をJSON文字列にしてブラウザーへ保存する
localStorage.setItem("studyRecords", JSON.stringify(records));
// 保存した文字列を読み取り、JavaScriptの配列へ戻す
const savedText = localStorage.getItem("studyRecords");
const savedRecords = savedText ? JSON.parse(savedText) : [];実際のアプリでは、保存データが壊れていたり、JSONとして読み込めなかったりする場合も考慮します。また、localStorageは秘密情報を安全に保管するための場所ではありません。パスワード、APIキー、重要な個人情報を保存しないでください。
完成条件を決める
作り始める前に、「ここまでできたら最初の版は完成」と言える条件を決めます。これを受け入れ条件として整理すると、作業の範囲を保ちやすくなります。
- 学習内容、学習時間、日付を入力して記録できます。
- 必須項目が空の場合、内容がわかる案内を表示します。
- 登録した記録が一覧に表示されます。
- ページを再読み込みしても、記録が残ります。
- 記録を削除できます。
- 登録された学習時間の合計を表示できます。
完成条件を満たす前に、機能を次々と追加しないようにしましょう。最初の版を完成させてから、編集機能や絞り込みなどを追加すると進めやすいです。
実装する順番を決める
設計ができたら、小さな作業に分けて順番を決めます。おすすめの順序は次の通りです。
- HTMLでフォームと一覧の枠を作ります。
- CSSで読みやすい配置に整えます。
- フォームから入力値を取得し、必須項目を確認します。
- 記録オブジェクトを作り、画面に一覧表示します。
- 削除機能を追加します。
- `localStorage`への保存と読み込みを追加します。
- 合計時間や検索など、追加機能に取り組みます。
まずは「入力して一覧に表示する」最小の流れを完成させ、そこへ保存や削除を足していくと、問題が起きたときに原因を追いやすくなります。
中規模アプリ設計テンプレート
別のアプリを作る場合にも使える、設計メモの例です。
アプリ名：
誰が使うか：
解決したい困りごと：
最初の版で作る機能：
・
・
・
後から追加する機能：
・
・
データ項目：
・項目名：
・データ型：
・必須か：
・入力ルール：
画面：
・画面名：
・表示する情報：
・利用者ができる操作：
保存方法：
・
完成条件：
・
・このメモは、作り始めてから変更して構いません。設計は一度決めたら固定するものではなく、試作や確認を通じて改善していくものです。
セキュリティと使いやすさの確認
最終制作では、機能が動くことだけでなく、入力値や保存データの扱いにも注意しましょう。ユーザーが入力した文字列を画面に表示するときは、HTMLとして解釈させず、textContentを使うのが基本です。入力値の確認は画面表示のためだけでなく、予期しないデータを保存しないためにも役立ちます。
- 名前やメモなどの入力値をそのままHTMLへ埋め込まないようにします。
- 学習時間は数値であることと、許可する範囲を確認します。
- `localStorage`には秘密情報を保存しません。
- 削除操作で、意図した記録だけが対象になるか確認します。
Day 80のゴール
Day 80では、次のことができるようになっていれば十分です。
- 作りたいアプリの目的を一文で説明できます。
- 最初に作る機能と、後から追加する機能を分けられます。
- 必要なデータ項目と型、入力ルールを考えられます。
- 画面の部品と利用者の操作の流れを書き出せます。
- 完成条件と実装する順番を決められます。
まとめ
Day 80では、最終制作に向けて、アプリの目的、機能、データ構造、画面、実装順序を設計しました。設計のポイントは、最初から機能を増やしすぎず、まず完成に必要な最小限の範囲を決めることです。データの項目や入力ルール、空の状態やエラー時の表示も先に考えておくと、実装中に迷いにくくなります。
今回の学習記録アプリは一例です。別のアプリを作る場合も、「誰の何を解決するか」を一文にし、必須機能、データ、画面、完成条件の順に書き出してみてください。設計メモができたら、最初の機能から小さく作り始めましょう。
