Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

アイディアを形に

素人のように考え、玄人として実行する

金出武雄

「正しい設計」「ベストプラクティス」「効率的な方法」——そんな言葉に縛られていませんか？ 生産性とかタイパとか、正直うんざり。ここでは子供のようにあなただけのローカルでパーソナルな「小さなWeb」を作って遊ぶ楽しさを取り戻しましょう。

ステップ1: デザインスプリント「自分だけのWebを考える」

アイディア発散・自由に発想する (30分〜45分程度)

思いついたアイデアを書き出してみましょう。この段階では正しさや実現可能性は気にしません。子供の頃のように自由に考えてください。

例: https://excalidraw.com/#json=zHnSzp3PV18E2Wp9LrIbB,sfpPlgnCwzWfFsbY761Pgg

以下の3つの視点が助けになるかもしれません。

視点1: 自分の困りごとから

日常で「これ、自動化できたらな」「もっと楽にならないかな」と思うことはありませんか？

例：
- 毎月の経費精算が面倒 → 経費管理アプリ
- 読んだ本を忘れる → 読書記録アプリ
- どこに何をしまったか忘れる → 収納場所メモアプリ
- 友達との旅行の割り勘計算 → 精算管理アプリ

視点2: 既存ツールの不満から

普段使っているツールやサービスに「もっとこうだったらいいのに」と思うことはありませんか？

例：
- Excelでの管理が限界 → 専用の管理画面
- メモアプリが複雑すぎる → シンプルなメモ帳
- 入力項目が多すぎる → 最小限のフォーム
- アプリを行き来するのが面倒 → 統合ツール

視点3: 遊び心から!

実用性よりも「作ったら面白そう」「誰かを笑顔にできそう」という動機を大切に。

例：
- 今日の気分で色が変わる日記
- ランダムで今日の運勢を占うアプリ
- 家族だけの写真共有アルバム
- ペットの体重記録グラフ

とにかく自由に、たくさん書き出してみましょう。

アイディアの共有

自分のアイデアを他の人に話してみましょう。順番に発表します。

話すこと:

  • どんなアプリを作りたいか（1〜2分）
  • なぜそれを作りたいと思ったか

聞く側の役割:

  • 「それ面白いね！」「便利そう！」と感じたら絵文字でリアクション
  • 「こういう機能もあったら嬉しいかも」と提案
  • 批判や否定はしない（この段階では自由な発想が大事）

他の人の話を聞いて、「あ、それいいな」と思ったら、自分のアイデアを変えたり混ぜたりしてもOKです。

ステップ2: 機能を整理する

テーマが決まったら、具体的な機能を整理していきます。

事前準備 (任意)

  • Webブラウザ (Chrome、Firefox、Edgeなど最新版、Excalidraw アクセス用)
  • テキストエディタ (VS Code、メモ帳など)
  • Gitがインストールされていること (任意・Zipダウンロードでも可)

以下を済ませておくとスムーズです。

# テンプレートを事前にクローン
git clone -b template https://github.com/kou029w/todo-template my-app
cd my-app

またはGitHubからZipでダウンロードして展開してもOKです。

Zipでダウンロードする場合:

  1. https://github.com/kou029w/todo-template/tree/template にアクセス
  2. 「Code」→「Download ZIP」
  3. ダウンロードしたZIPファイルを展開
  4. フォルダを開く

VS Codeで開く場合:

  1. vscode://vscode.git/clone?url=https%3A%2F%2Fgithub.com%2Fkou029w%2Ftodo-template&ref=template にアクセス
  2. クローン先のフォルダを選択

アイデアを絞る

いくつかアイデアが出たら、今回作るものを1つに絞りましょう。

以下の質問に答えられるか確認してみてください。

  • 何ができる？: 一言で説明できる？(概要)
  • なぜ作る？: 自分がワクワクする理由は？(動機)
  • どこまで作る？: 最低限動くために必要な機能は何？(実現可能性)

迷ったら、一番ワクワクするものを選んでください。技術的に難しそうでも、気にしなくて大丈夫。作りながら学べます。

機能を書き出す

思いつく機能を全部書き出しましょう。この段階では取捨選択せず、自由に発想します。

優先順位をつける

書き出した機能に優先度をつけます。ここではMoSCoW分析での優先度付けの例を紹介します。

分類意味例（やることリスト）
Mustこれがないと成り立たない追加、一覧、完了切替
Shouldできれば実装したい編集、削除、期限設定
Could時間があれば検索、カテゴリ分け
Won’t今回は見送り複数ユーザー、通知

優先度の分析ができたら最初はMustだけに集中しましょう。動くものができてから機能を追加する方が、確実に前に進めます。

テンプレートのルートディレクトリに README.md を編集して、以下の内容を記入していきましょう。

# (プロジェクト名)

## 概要

（一言で何ができるアプリか）

## 機能

### Must (必須)

- [ ] 機能A
- [ ] 機能B
- [ ] 機能C

### Should (重要)

- [ ] 機能D
- [ ] 機能E

### Could (時間があれば)

- [ ] 機能F
- [ ] 機能G

### Won't (今回は見送る)

- 機能H
- 機能I

## 画面構成

- 画面名：概要
- 画面名：概要
- 画面名：概要

## データ構造

（主要なデータの型定義）

## APIエンドポイント

（REST APIの設計）

## 技術選定

- フレームワーク：Hono + React
- スタイリング：（選択）
- データベース：（選択）

## 備考

（その他、気になる点や挑戦したいこと）

自分の言葉で具体的に書くことが大切です。

具体例:

# やることリストアプリの機能アイデア

## Must (必須)

- タスクの追加
- タスクの一覧表示
- タスクの完了/未完了切り替え

## Should (重要)

- タスクの編集
- タスクの削除
- 期限の設定

## Could (時間があれば)

- 優先度の設定
- カテゴリ分け
- 検索・フィルター
- 並び替え

## Won't (今回は見送る)

- 複数ユーザー対応
- タスクの共有
- 通知機能
- 繰り返しタスク
- 統計・レポート

画面を洗い出す

機能が決まったら、必要な画面を整理します。

画面スケッチの例: https://excalidraw.com/#json=iuZN2WftiqLGgWk1J6p_K,w574mZehayx4VC1hku9CGQ

テキストで整理する例:

## やることリストアプリの画面構成

1. タスク一覧
   - タスクの一覧表示
   - 完了/未完了の切り替え
   - タイトル入力欄
   - 期限入力（任意）
   - 新規追加ボタン
2. タスク編集
   - 既存データの編集欄
   - 削除ボタン

シンプルに始めましょう。画面数は少ないほど簡単。

データ構造を考える

どんなデータを扱うか整理します。これが設計の基礎になります。

// タスクのデータ構造
interface Task {
  id: string; // 一意のID
  title: string; // タスク名
  completed: boolean; // 完了状態
  dueDate?: string; // 期限
  createdAt?: string; // 作成日時
  updatedAt?: string; // 更新日時
}
フィールド名データ型必須/任意説明
id文字列必須タスクを識別するための一意のID
title文字列必須タスクの名前
completed真偽値 (true/false)必須完了しているかどうか (true: 完了)
dueDate文字列任意タスクの期限 (設定しなくてもOK)
createdAt文字列任意タスクが作成された日時
updatedAt文字列任意タスクが最後に更新された日時

Note
データ型について

JavaScriptにはいくつかのデータ型があります。主なものは以下の通りです。

  • 文字列 (string): "こんにちは"のようなテキストデータ
  • 数値 (number): 42や3.14のような数字
  • 真偽値 (boolean): true(真)またはfalse(偽)の2つの値
  • オブジェクト (object): 複数のデータをまとめたもの
  • 配列 (array): 複数の値を順序付きで格納するもの

詳しくはデータ型とリテラルをご覧ください。

どんなフィールドが必要か、どんな構造か、どれが必須か、明確にしておくことがポイントです。

APIエンドポイントを設計する

REST APIの設計も機能の一部です。Honoで実装することを想定して設計しましょう。

GET    /api/tasks        # タスク一覧取得
POST   /api/tasks        # タスク作成
GET    /api/tasks/:id    # タスク詳細取得
PUT    /api/tasks/:id    # タスク更新
DELETE /api/tasks/:id    # タスク削除
PATCH  /api/tasks/:id/toggle  # 完了状態の切り替え
メソッドエンドポイント機能
GET/api/tasksすべてのタスクを取得
POST/api/tasks新しいタスクを作成
GET/api/tasks/:id特定のタスクの詳細を取得
PUT/api/tasks/:id特定のタスクを更新
DELETE/api/tasks/:id特定のタスクを削除
PATCH/api/tasks/:id/toggle特定のタスクの完了状態を切り替え

:idの部分は実際のタスクのID(例: 123)に置き換えられます。

アプリアイデア例

参考として、いくつかのアプリアイデアを紹介します。

シンプルなToDoリスト

概要: シンプルなToDoリスト

Must (必須):

- タスクの追加・削除
- 完了/未完了の切り替え
- 一覧表示

メモアプリ

概要: Markdownで書けるシンプルなメモ帳

Must (必須):

- メモの作成・編集・削除
- メモ一覧表示
- 検索機能

経費管理アプリ

概要: 経費の入力と月次集計

Must (必須):

- 経費の登録（日付、金額、カテゴリ、メモ）
- 月別一覧表示
- カテゴリ別集計

Should (重要):

- CSV出力
- カテゴリの追加・編集
- レシート画像の添付

在庫管理アプリ

概要: 備品や商品の在庫を管理

Must (必須):

- 商品の登録・編集・削除
- 在庫数の増減
- 在庫一覧表示

Should (重要):

- 在庫アラート（残り少ない商品を強調）
- 入出庫履歴
- バーコード読み取り

予約管理システム

概要: 会議室や設備の予約を管理

Must (必須):

- 予約の作成・編集・削除
- カレンダー形式での表示
- 重複チェック

Should (重要):

- 繰り返し予約
- メール通知
- 承認フロー

上級：申請ワークフロー

概要: 申請 → 承認 → 完了 のフローを管理

Must (必須):

- 申請フォーム
- 承認者への通知
- ステータス管理（申請中、承認済み、却下）

Should (重要):

- 複数段階の承認
- コメント機能
- 申請履歴

開発アプローチを選ぶ

「UIライブラリを活用 (shadcn/ui、Chakra UIなど)」「自分で1から実装」どちらのアプローチも正解です。大切なのは完成させること。途中で行き詰まったら、アプローチを切り替えても構いません。 例えば「UIはライブラリを使うが、APIロジックは自分で書く」など、部分ごとに使い分けるのも良い方法です。

ポイント

  1. 間違えよう: 完璧を目指さず、とりあえず書いてみる、修正は後回し
  2. プランB歓迎: 作り始めてから変わることも多い。最初の計画に縛られすぎない
  3. 自分の言葉で説明してみよう: 他の人に説明してみると理解が深まる