Day 81：アプリ企画
Day 81では、最終制作で作るアプリを決め、何を作るのかを企画書にまとめます。ここでは、すぐにコードを書き始めるのではなく、「誰のどんな困りごとを解決するか」「最初の完成版にどの機能を入れるか」をはっきりさせます。
最終制作では、アプリの規模を大きくすることより、決めた範囲を最後まで完成させることが大切です。機能を増やしすぎると、完成前に作業が複雑になったり、動作確認が十分にできなくなったりします。小さく企画して、動くものを完成させてから、必要に応じて追加機能を考えましょう。
アプリ企画とは
アプリ企画とは、作るアプリの目的や使う人、機能、完成条件を決めることです。企画が具体的であれば、実装中に迷ったときも「このアプリの目的に必要か」を基準に判断できます。
今回の企画では、次の問いに答えます。
- 誰が使うアプリですか。
- どんな困りごとを解決しますか。
- 利用者は何を入力し、何を見られますか。
- 最初の完成版に必要な機能は何ですか。
- どんな状態になれば完成と言えますか。
ステップ1：作りたいアプリの候補を選ぶ
今回の候補は、家計簿アプリ、タスク管理アプリ、メモアプリ、学習管理アプリ、映画検索アプリ、レシピ検索アプリ、習慣トラッカーです。それぞれ練習できる内容や、必要な作業の量が少し異なります。
- 家計簿アプリ：金額や日付の入力、カテゴリ分け、合計計算を練習できます。
- タスク管理アプリ：追加、完了、編集、削除などの基本的なデータ操作に向いています。
- メモアプリ：入力、一覧表示、検索、保存の基本を練習できます。
- 学習管理アプリ：学習内容や時間を記録し、履歴や合計を表示できます。
- 映画検索アプリ：API通信、検索フォーム、読み込み中やエラーの表示を練習できます。
- レシピ検索アプリ：検索、カテゴリ表示、詳細画面などを考えられます。
- 習慣トラッカー：日付ごとの記録や、継続状況の表示を練習できます。
候補の中でどれが「一番すごいか」を考える必要はありません。自分が使ってみたいもの、身近な不便を解決できるもの、今の学習内容で完成まで進められそうなものを選びます。
ステップ2：企画するアプリを比べる
候補を絞るときは、次の観点で考えます。
- 自分や身近な人が使う場面を想像できますか。
- 最初の版に必要な機能を3〜5個程度に絞れますか。
- 必要なデータ項目を説明できますか。
- 外部APIやアカウント登録がなくても、最初の版を作れますか。
- 完成したかどうかを具体的に確認できますか。
初めての最終制作では、ログイン、決済、複数端末との同期などを必須にしないのがおすすめです。それらは追加の設計や安全対策が必要になるため、まずはブラウザー内で基本機能が動くアプリを完成させると、全体を組み立てやすくなります。
ステップ3：目的を一文にする
選んだアプリについて、「誰が」「何をできる」アプリなのかを一文にします。これをアプリの目的として、企画や実装の判断基準にします。
たとえば、学習管理アプリなら次のように書けます。
学習した内容と時間を記録し、あとから学習履歴や合計時間を振り返れるアプリです。
タスク管理アプリなら、次のようにできます。
日々のタスクを登録し、完了したものと未完了のものを整理できるアプリです。
目的が長くなりすぎる場合は、機能を詰め込みすぎている可能性があります。まずはアプリの中心となる価値を一つに絞りましょう。
ステップ4：使う人と利用場面を決める
次に、どんな人が、どのような場面でアプリを使うかを考えます。これは利用者の人物像を作り込むことが目的ではなく、必要な機能や表示を決めやすくするためです。
学習管理アプリなら、たとえば次のように整理できます。
- 使う人：毎日の学習を記録したい学習者
- 使う場面：学習を終えたあとに、学んだ内容と時間を入力する
- 知りたいこと：過去の記録や、今までの合計学習時間を確認する
利用場面が決まると、アプリを開いたときに最初に何を表示するかも考えやすくなります。
ステップ5：機能を必須と追加に分ける
思いついた機能を、すべて最初の版に入れる必要はありません。最初に完成させる機能と、あとで追加する機能を分けます。
学習管理アプリの例です。
- 最初の完成版に入れる機能：記録の追加、一覧表示、削除、合計時間の表示
- 余裕があれば追加する機能：記録の編集、日付による絞り込み、キーワード検索
- 将来の発展機能：グラフ表示、複数端末との同期、アカウント登録
最初の完成版をMVP（Minimum Viable Product、最小限の実用版）と呼ぶことがあります。ここでは、アプリの中心となる価値を確かめるのに必要な最小の機能を指します。機能を少なくするのは手抜きではありません。完成させて動作を確かめるための工夫です。
ステップ6：利用者の操作の流れを書く
機能を決めたら、利用者がどんな順番で操作するかを書きます。学習管理アプリでは、次のようになります。
- アプリを開くと、保存済みの学習記録が表示されます。
- 学習内容、時間、日付、メモを入力します。
- 「記録する」ボタンを押します。
- 入力内容が確認され、問題がなければ記録が追加されます。
- 一覧と合計時間が更新されます。
- 不要な記録があれば、対象の削除ボタンを押します。
操作の流れを書くと、必要な画面要素や処理が見えてきます。「ボタンを置く」だけで終わらず、押したあとに画面やデータがどう変わるかも決めましょう。
ステップ7：データを決める
アプリが保存するデータ項目を決めます。学習管理アプリの記録一件分なら、次のような形が考えられます。
- `id`：記録を区別するID
- `title`：学習した内容
- `minutes`：学習時間を分で表した数値
- `date`：学習した日付
- `note`：補足メモ
- `createdAt`：記録を作成した日時
JavaScriptのオブジェクトで表すと、次のようになります。
// 学習記録1件分のデータ例
const studyRecord = {
id: crypto.randomUUID(), // 記録を区別するための一意なID
title: "JavaScriptの配列", // 学習した内容
minutes: 40, // 学習時間（分）
date: "2026-11-08", // 学習した日付
note: "mapとfilterを復習", // 補足メモ
createdAt: new Date().toISOString() // 作成した日時
};crypto.randomUUID()が利用できる環境では、重複しにくいIDを作れます。学習用の設計例としては、IDの作り方よりも「記録を配列の何番目かだけで識別せず、各記録にIDを持たせる」という考え方が大切です。
金額や時間のように計算する値は、文字列ではなく数値で保存すると扱いやすくなります。たとえば、"40分"ではなく40を保存し、画面表示のときに「40分」と整えます。
ステップ8：入力ルールを決める
どんな値を入力として受け付けるかも決めておきます。
- 学習内容は必須で、空欄を許可しません。
- 学習時間は0より大きい数値にします。
- 日付は有効な日付として扱える値にします。
- メモは任意にします。
入力ルールを先に決めると、フォームの入力タイプ、エラーメッセージ、保存前の確認を設計しやすくなります。実際のコードでは、HTMLのrequiredだけに頼らず、JavaScript側でも数値や範囲を確認すると、データを一貫した形で扱えます。
ステップ9：画面の構成を考える
画面の見た目を作り込む前に、必要な部品と配置を簡単な図にします。このような下書きをワイヤーフレームと呼びます。
┌──────────────────────────┐
│ 学習管理アプリ │
├──────────────────────────┤
│ 学習内容 [____________________] │
│ 学習時間 [____] 分 │
│ 学習日 [__________] │
│ メモ [____________________] │
│ [記録する] │
├──────────────────────────┤
│ 合計学習時間：○分 │
│ 学習履歴 │
│ ・JavaScriptの配列 40分 [削除] │
│ ・関数の復習 30分 [削除] │
└──────────────────────────┘ここでは装飾よりも、利用者が必要な操作を見つけられることを優先します。
- 入力フォームは、何を入力する場所か明確にします。
- 操作ボタンは、何が起きるか分かる文言にします。
- 合計時間や一覧は、入力フォームと見分けやすくします。
- 記録がない場合の案内や、入力エラーの表示場所を決めます。
ステップ10：画面の状態を考える
アプリは、データが登録されているときだけでなく、何もないときやエラー時にも使いやすくする必要があります。
- 初回表示：記録がないことと、最初の操作を案内します。
- 入力エラー：直す必要がある項目を伝えます。
- 保存成功：記録が追加されたことを知らせます。
- 記録一覧：登録済みの記録と合計時間を表示します。
- 削除後：対象が消えたことを一覧と合計に反映します。
たとえば、記録が0件のときに空白の画面を表示するのではなく、「まだ記録がありません。最初の学習内容を入力してください」と表示すると、次に何をすればよいかが分かります。
ステップ11：保存方法を選ぶ
最初の版では、ブラウザーのlocalStorageを使う方法があります。サーバーを用意せずに試せるため、学習用アプリに向いています。
// 記録の配列をJSON文字列にして保存する
function saveRecords(records) {
localStorage.setItem("studyRecords", JSON.stringify(records));
}
// 保存したJSON文字列を読み込み、配列に戻す
function loadRecords() {
const savedText = localStorage.getItem("studyRecords");
// まだデータがない場合は、空の配列を返す
if (savedText === null) {
return [];
}
// JSON文字列をJavaScriptの値に変換して返す
return JSON.parse(savedText);
}実際に使うときは、保存データが壊れていてJSON.parse()に失敗する場合も考慮します。また、localStorageは秘密情報を安全に保存する場所ではありません。パスワードやAPIキーを保存しないでください。複数端末での同期が必要な場合は、サーバーなど別の仕組みが必要になるため、最初の完成版では対象外にするのが現実的です。
ステップ12：完成条件を決める
「どこまでできれば完成か」を、確認できる形で書きます。これを決めておくと、いつまでも機能を追加し続けるのを防げます。
学習管理アプリの最初の完成条件は、たとえば次のようにできます。
- 学習内容、時間、日付を入力して記録を追加できます。
- 必須項目が空の場合、保存されず、理由が表示されます。
- 追加した記録が一覧に表示されます。
- ページを再読み込みしても記録が残ります。
- 記録を削除できます。
- 登録された学習時間の合計が正しく表示されます。
完成条件は、「きれいなデザインにする」のような曖昧な表現だけでなく、実際に操作して確かめられる内容にします。デザインの目標も大切ですが、機能の完成条件とは分けて考えると確認しやすくなります。
アプリ企画書テンプレート
次のテンプレートを埋めると、最終制作の企画をまとめられます。
アプリ名：
アプリの目的：
誰が使うか：
解決したい困りごと：
利用者の操作の流れ：
1.
2.
3.
最初の完成版に入れる機能：
-
-
-
後から追加する機能：
-
-
保存するデータ：
- 項目名：
データ型：
必須か：
入力ルール：
画面に必要な要素：
-
-
-
保存方法：
完成条件：
-
-
-企画を広げすぎないための注意
最終制作では、作りたい機能が次々と増えることがあります。追加したい機能を思いついたら、すぐに実装するのではなく、「最初の目的を達成するために必須か」「基本機能が完成しているか」を確認しましょう。
- まず最初の完成版に必要な機能を完成させます。
- 追加機能は一覧に書き留め、優先順位をつけます。
- ログインや同期など大きな機能は、必要性と実装量を慎重に考えます。
- 使わない機能を増やすより、入力ミスやエラー時の案内を整えます。
安全性を企画に含める
安全性は、完成後に付け足すものだけではありません。企画の段階で、扱うデータや外部サービスを確認しておくと、実装時の判断がしやすくなります。
- 保存するデータは、アプリの目的に必要なものに絞ります。
- APIキーやパスワードなどの秘密情報を、公開するコードへ書きません。
- 利用者が入力した文字列を画面へ表示するときは、HTMLとして実行させない方法を使います。
- 削除や上書きなど、データを失う操作の動作を明確にします。
Day 81のゴール
Day 81では、次のことができるようになっていれば十分です。
- 最終制作で作るアプリを一つ決められます。
- アプリの目的と使う人を説明できます。
- 最初に作る機能と、後から追加する機能を分けられます。
- 必要なデータ項目と入力ルールを書き出せます。
- 画面の構成と利用者の操作の流れを説明できます。
- 具体的な完成条件を決められます。
まとめ
Day 81では、最終制作で作るアプリを決め、目的、利用者、機能、データ、画面、完成条件を整理しました。企画の中心は、作りたい機能を増やすことではなく、誰のどんな困りごとを解決するのかを明確にし、最初に完成させる範囲を決めることです。
最終制作では、企画した機能を一度にすべて作ろうとせず、まず最小限の完成版を動かし、その後に必要な機能を加えていきます。企画書を埋めたら、完成条件を確認しながら、次の制作ステップへ進みましょう。
