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」を子供の頃のように自由に作って遊ぶことを目指してもらいます。

アイディアソン: 自分だけのWebを考える

ステップ1: まずは自由に発想する（10分）

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

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

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

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

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

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

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

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

視点3: 遊び心から

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

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

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

ステップ2: 受講者同士で共有する（15分）

自分のアイデアを他の人に話してみましょう。3〜4人のグループになって、順番に発表します。

話すこと:

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

聞く側の役割:

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

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

ステップ3: アイデアを1つに絞る（5分）

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

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

  • 誰が使う？: 自分だけ？友達と？一般公開？
  • 何ができる？: 一言で説明できる？
  • なぜ作る？: 自分がワクワクする理由は？
  • どこまで作る？: 最低限動くために必要な機能は何？

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

要件を整理する

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

機能を書き出す

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

# タスク管理アプリの機能アイデア

## 基本機能

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

## あると便利な機能

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

## 発展的な機能

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

優先順位をつける

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

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

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

画面を洗い出す

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

# タスク管理アプリの画面構成

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

シンプルに始めましょう。画面数は少ない方が開発しやすいです。

データ構造を考える

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

// タスクのデータ構造
interface Task {
  id: string; // 一意のID
  title: string; // タスク名（必須）
  completed: boolean; // 完了状態
  dueDate?: string; // 期限（任意）
  createdAt: string; // 作成日時
  updatedAt: string; // 更新日時
}

TypeScriptの型定義で表現すると、どんなフィールドが必要か、どれが必須でどれが任意かが明確になります。

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  # 完了状態の切り替え

開発アプローチを選ぶ

同じ機能でも、作り方には選択肢があります。自分の学習スタイルに合ったアプローチを選びましょう。

パターンA: 効率重視アプローチ

特徴:

  • UIライブラリを活用（shadcn/ui、Chakra UIなど）
  • 既存テンプレートやボイラープレートを活用
  • 素早く形にして、動くものを見ながら学ぶ

向いている人:

  • とにかく完成させたい
  • 動くものを見てモチベーションが上がる
  • 後から仕組みを理解したい

パターンB: 理解重視アプローチ

特徴:

  • 自分で一から実装
  • 外部ライブラリを最小限に抑える
  • じっくり仕組みを理解しながら進む

向いている人:

  • 基礎をしっかり固めたい
  • なぜそう動くのか理解したい
  • 応用力をつけたい

どちらのアプローチも正解です。大切なのは完成させること。途中で行き詰まったら、アプローチを切り替えても構いません。

効率重視で素早く作る → 動くものを見て理解が深まる
理解重視でじっくり作る → 基礎が身について応用できる

両方のアプローチを組み合わせることも可能です。例えば「UIはライブラリを使うが、APIロジックは自分で書く」など、部分ごとに使い分けるのも良い方法です。

アプリアイデア例

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

初級：タスク管理アプリ

概要: シンプルなToDoリスト
対象: 自分用

機能（Must）:
  - タスクの追加・削除
  - 完了/未完了の切り替え
  - 一覧表示

学べること:
  - CRUD操作の基本
  - 状態管理
  - フォームの扱い

初級：メモアプリ

概要: Markdownで書けるシンプルなメモ帳
対象: 自分用

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

学べること:
  - テキストエリアの扱い
  - 検索・フィルター処理
  - ローカルストレージ or データベース

中級：経費管理アプリ

概要: 経費の入力と月次集計
対象: 自分またはチーム用

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

機能（Should）:
  - CSV出力
  - カテゴリの追加・編集
  - レシート画像の添付

学べること:
  - 日付の扱い
  - 集計処理
  - ファイルのアップロード

中級：在庫管理アプリ

概要: 備品や商品の在庫を管理
対象: 小規模チーム用

機能（Must）:
  - 商品の登録・編集・削除
  - 在庫数の増減
  - 在庫一覧表示

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

学べること:
  - 数値の増減処理
  - 履歴管理
  - 条件付き表示

中級：予約管理システム

概要: 会議室や設備の予約を管理
対象: チーム用

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

機能（Should）:
  - 繰り返し予約
  - メール通知
  - 承認フロー

学べること:
  - 日時のバリデーション
  - 重複チェックのロジック
  - カレンダーUIの扱い

上級：申請ワークフロー

概要: 申請 → 承認 → 完了 のフローを管理
対象: 組織用

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

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

学べること:
  - ワークフローの状態管理
  - 権限管理
  - メール送信

やってみよう！

以下のテンプレートを使って、自分のプロジェクトの要件を整理してみましょう。

要件定義テンプレート

# プロジェクト名

## 概要

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

## 背景・目的

（なぜ作るのか、どんな課題を解決するのか）

## 対象ユーザー

（誰が使うのか）

## 機能一覧

### Must（必須）

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

### Should（重要）

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

### Could（あれば嬉しい）

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

### Won't（今回は見送り）

- 機能H
- 機能I

## 画面構成

1. 画面名：概要
2. 画面名：概要
3. 画面名：概要

## データ構造

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

## APIエンドポイント

（REST APIの設計）

## 技術選定

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

## 開発アプローチ

（効率重視 / 理解重視 / ハイブリッド）

## 備考

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

ポイント

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