LoginSignup
9
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@tequila0725

CursorでKiroライクなスペック駆動開発をやってみる

Last updated at Posted at 2025-07-23

はじめに

最近話題になっているAmazonのKiro IDE。
Kiroの核となる「スペック駆動開発」の考え方は非常に魅力的です。

少し前にSRE NEXT2025で「生成AIを用いた開発には、AIが暴走しないようにガードレールを敷くべきだ」と講演されている方がいました。
https://speakerdeck.com/lmi/sre-next-2025-link-and-motivation

上記の内容を業務で使用しているCursorにも適用できないか・・・と悩んでいたところ、Kiroがリリースされました。
その仕組みを確認し「これだ！」となったため、今回Cursorでもスペック駆動開発ができるようにチャレンジしてみました。
今回は簡単なTODOアプリを作成しようとしています。

また、すでにClaude Codeでは試されている方がいましたので、そちらを非常に参考にさせていただきました！ありがとうございます！

Kiroとは

KiroはAmazonが2025年1月に発表したAIエージェント機能を持つ統合開発環境（IDE）です。

主な特徴：

  • スペック駆動開発: プロンプトを明確な要件、システム設計、個別のタスクに変換
  • エージェントフック: ファイル保存などのイベントでトリガーされるAI処理
  • Claude Sonnet 4採用: 最新のAIモデルを活用 ※残念ながらOpusは未対応（2025/07/23現在）
  • VS Code互換: Code OSSベースで既存の環境から移行しやすい

Kiroの最大の特徴は「コーディング前に計画する」アプローチです。単純なコード生成ではなく、要件定義→設計→実装計画→実装という段階的な開発プロセスを重視しています。

参考にさせていただいた記事

本記事の作成にあたり、以下の記事を参考にさせていただきました：

これらの記事の内容を参考にし、CursorのProject Rulesを作成しました。

事前準備

Github Issueの作成、参照を行うため、CursorにGithubのMCPを設定します
注意

  • Fine-grained personal access tokensで作成すると適切な権限の付与が必要になります
  • Github MCPにProjectに関連する権限が存在しないため、ghコマンドをインストールする必要があります
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-github"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "[個人のGPAT]"
      }
    }
  }
}

入力したコンテキスト

TODOアプリを作成したい

これだけです。シンプルですね。

cursor project rulesの中身

以下が今回使用したCursor Project Rulesの全体です：

.cursor/rules/spec.mdc


---
alwaysApply: false
---

# タスク実行の5段階フロー

## 実行ルール 

### github認証情報
- owner: [Githubのオーナ名] # Github MCPを使用するのに必要。定義しないと毎回確認するようになります。

### ファイル操作
- 新規タスク開始時: 既存ファイル、既存issueの**内容を全て削除して白紙から書き直す** # 既存ファイルが存在する状態で再実行する場合に必要
- ファイル編集前に必ず現在の内容を確認

### フェーズ管理
- 各段階開始時: 「前段階のmdファイルを読み込みました」と報告
- 各段階の最後に、期待通りの結果になっているか確認
- `.cursor_workflow/requirements.md`が存在しない場合は必ず要件定義フェーズから始める

### 実行方針
- 段階的に進める: 一度に全てを変更せず、小さな変更を積み重ねること
- 複数のタスクを同時並行で進めないこと
- エラーが発生した場合は、報告すること
- エラーを解決してから次へ進むこと
- ユーザからの指示に無い機能を勝手に追加しないこと

## 1. 要件定義フェーズ
- ユーザからの指示に対して **「何を作るのか」を明確に定める。**
- 目的の明確化、現状分析、機能要件の定義、非機能要件の定義、制約条件の定義を実行する
- `.cursor_workflow/requirements.md`に文書化
- **必須確認**: 「要件定義フェーズが完了しました。設計フェーズに進んでよろしいですか？」

### 2. 設計フェーズ
- **必ず`.cursor_workflow/requirements.md`を読み込んでから開始すること**
- 要件定義フェーズで決定したことをもとに **「どのようにつくるか」「内部でどのように処理するか」を設計する**
- プログラマーが実際にコーディングできるレベルまで詳細化すること
- `.cursor_workflow/design.md`に文書化
- **必須確認**: 「設計フェーズが完了しました。実装計画フェーズに進んでよろしいですか？」

### 3. 実装計画フェーズ
- **必ず`.cursor_workflow/design.md`を読み込んでから開始すること**
- アジャイル・スクラム開発をすることを前提とする
- タスクを実行可能なユーザーストーリー単位に分解、優先順位を設定する
- `.cursor_workflow/implementations.md`に文書化
- **必須確認**: 「実装計画フェーズが完了しました。issue作成フェーズに進んでよろしいですか？」

### 4. issue作成フェーズ
- **必ず`.cursor_workflow/implementations.md`を読み込んでから開始すること**
- Github Projectを現在のリポジトリに紐づける形で新規作成する
- Github Issuesに各タスクの内容でIssueを作成する。Issueは先程作成したProjectに紐づける
- **必須確認**: 「issue作成フェーズが完了しました。実行フェーズに進んでよろしいですか？」

### 5. 実行フェーズ
- **必ずopenになっているissueの一覧を確認してから開始**
- **必ず対応するissueの詳細を確認してから開始**
- **issueの対応開始時に必ずローカル環境で作業ブランチを新規作成してチェックアウトする**
- 実装完了後に適切な単位でコミットメッセージを作成する
- 実装完了後にpull requestを作成する
- **必須対応** pull requestまで作成したら報告すること
- 次のissueに進む場合も実行フェーズを最初から繰り返すこと

このRuleは実行したいときだけ実行したいため、alwaysApply: falseとしています。
実行する場合は、Add Contextにspec.mdcを追加します。

このルールの特徴は以下の通りです：

5段階のフロー構成

  1. 要件定義フェーズ
  2. 設計フェーズ
  3. 実装計画フェーズ
  4. Issue作成フェーズ ← Github Issueにユーザーストーリーを作成します。
  5. 実行フェーズ

段階的な確認プロセス

  • 各フェーズの完了時に必ずユーザーの承認を求める
  • 前段階のファイルを必ず読み込んでから次に進む
  • エラーは必ず解決してから次のステップに進む

GitHub連携

  • GitHub IssuesとProjectsを自動作成
  • 各タスクをIssue単位で管理
    • 最終的にはimplementations.mdではなくIssueを正として開発を進行します
  • Pull Requestまで自動作成

要件定義書:requirements.mdの中身

要件定義書 
# TODOアプリ 要件定義書

## 1. 目的の明確化

### 目的
個人のタスク管理を効率化するためのWebベースTODOアプリケーションを開発する。

### 対象ユーザー
- 個人利用者
- 日常的なタスク管理を行いたい人
- シンプルで使いやすいTODOアプリを求めている人

## 2. 現状分析

### 課題
- 複雑すぎるタスク管理ツールが多い
- シンプルで直感的に使えるTODOアプリが必要
- 基本的なCRUD操作で十分な機能を提供したい

## 3. 機能要件

### 必須機能
1. **TODOの追加**
   - タスクのタイトルを入力して追加できる
   - 入力後はフォームがクリアされる

2. **TODOの表示**
   - 追加されたTODOをリスト形式で表示
   - 完了/未完了の状態を視覚的に区別

3. **TODOの完了/未完了切り替え**
   - チェックボックスまたはボタンで状態を切り替え
   - 完了したTODOは打ち消し線などで表示

4. **TODOの削除**
   - 不要になったTODOを削除できる
   - 削除ボタンまたはアイコンを提供

### 任意機能（今回は対象外）
- 編集機能
- カテゴリ分け
- 期限設定
- 優先度設定

## 4. 非機能要件

### パフォーマンス
- レスポンス時間: 操作後1秒以内に反映
- 同時利用者数: 単一ユーザー想定

### 可用性
- ブラウザ対応: Chrome, Firefox, Safari, Edge（最新版）
- レスポンシブデザイン: PC、タブレット、スマートフォン対応

### セキュリティ
- 今回はローカル環境での動作を想定
- 認証機能は不要

### 保守性
- コードの可読性を重視
- コンポーネント化による再利用性
- 適切なファイル構成

## 5. 技術的制約条件

### 開発環境
- Node.js環境
- モダンなJavaScriptフレームワーク使用
- ローカル開発環境での動作

### データ保存
- ローカルストレージまたはメモリ上での保存
- データベースは使用しない

### UI/UX
- シンプルで直感的なデザイン
- モダンなUI（Material DesignまたはBootstrap風）
- アクセシビリティを考慮

## 6. 成果物

### 最終成果物
- 動作するTODOアプリケーション
- ソースコード
- README.md（実行方法記載）

### 技術仕様書
- 設計書
- 実装計画書

## 7. 制約事項

- 開発期間: 短期間での完成を目指す
- 複雑な機能は実装しない
- 基本的なCRUD操作に特化
- 単一ページアプリケーション（SPA）として構築

設計書:design.mdの中身

設計書 
# TODOアプリ 設計書

## 1. 技術スタック選定

### フロントエンド
- **フレームワーク**: React 18.x
- **言語**: TypeScript
- **ビルドツール**: Vite
- **スタイリング**: CSS Modules + 基本CSS
- **状態管理**: React Hooks (useState, useEffect)

### 開発・ビルド環境
- **パッケージマネージャー**: npm
- **開発サーバー**: Vite dev server
- **型チェック**: TypeScript compiler

### データ永続化
- **ストレージ**: ブラウザのlocalStorage
- **データ形式**: JSON

## 2. システム構成

### アーキテクチャパターン
- **パターン**: コンポーネントベースアーキテクチャ
- **データフロー**: 単方向データフロー（React標準）
- **ファイル構成**: 機能別ディレクトリ構成

### ディレクトリ構成
```
src/
├── components/           # 再利用可能なコンポーネント
│   ├── TodoItem/        # 個別TODOアイテムコンポーネント
│   ├── TodoList/        # TODOリストコンポーネント
│   ├── TodoForm/        # TODO追加フォームコンポーネント
│   └── Header/          # ヘッダーコンポーネント
├── hooks/               # カスタムフック
│   └── useTodos.ts      # TODO操作のカスタムフック
├── types/               # TypeScript型定義
│   └── todo.ts          # TODO関連の型定義
├── utils/               # ユーティリティ関数
│   └── storage.ts       # ローカルストレージ操作
├── styles/              # グローバルスタイル
│   └── global.css       # グローバルCSS
├── App.tsx              # メインアプリケーションコンポーネント
└── main.tsx             # エントリーポイント
```

## 3. データモデル設計

### TODOアイテムの構造
```typescript
interface Todo {
  id: string;              // 一意識別子（UUID v4）
  title: string;           // TODOのタイトル
  completed: boolean;      // 完了状態
  createdAt: Date;         // 作成日時
}

interface TodoState {
  todos: Todo[];           // TODOアイテムの配列
}
```

### ローカルストレージ仕様
- **キー名**: `todos`
- **データ形式**: JSON文字列
- **初期値**: 空配列 `[]`

## 4. コンポーネント設計

### 4.1 App.tsx（メインコンポーネント）
**責務**: アプリケーション全体の統合・状態管理
**状態**:
- todos: Todo[] - 全TODOアイテムのリスト
**機能**:
- TODOの追加、削除、完了状態切り替え
- ローカルストレージとの同期

### 4.2 Header.tsx
**責務**: アプリケーションヘッダーの表示
**Props**: なし
**機能**:
- アプリタイトルの表示
- 簡単な統計情報（総数、完了数）の表示

### 4.3 TodoForm.tsx
**責務**: 新しいTODOの入力・追加
**Props**:
- onAddTodo: (title: string) => void
**状態**:
- inputValue: string - 入力フィールドの値
**機能**:
- テキスト入力
- Enterキーまたはボタンクリックでの追加
- 入力後のフィールドクリア
- 空文字入力の防止

### 4.4 TodoList.tsx
**責務**: TODOアイテム一覧の表示
**Props**:
- todos: Todo[]
- onToggleTodo: (id: string) => void
- onDeleteTodo: (id: string) => void
**機能**:
- TODOアイテムの一覧表示
- 空リスト時のメッセージ表示

### 4.5 TodoItem.tsx
**責務**: 個別TODOアイテムの表示・操作
**Props**:
- todo: Todo
- onToggle: () => void
- onDelete: () => void
**機能**:
- チェックボックスによる完了状態切り替え
- 削除ボタンによる削除
- 完了済みアイテムの視覚的表現（打ち消し線）

## 5. カスタムフック設計

### useTodos.ts
**責務**: TODO関連のビジネスロジックと状態管理
**戻り値**:
```typescript
{
  todos: Todo[];
  addTodo: (title: string) => void;
  toggleTodo: (id: string) => void;
  deleteTodo: (id: string) => void;
}
```
**内部処理**:
- ローカルストレージからの初期データ読み込み
- 状態変更時のローカルストレージ更新
- UUID生成による一意ID作成

## 6. ユーティリティ設計

### storage.ts
**責務**: ローカルストレージ操作の抽象化
**機能**:
```typescript
export const loadTodos = (): Todo[] => { /* 実装 */ };
export const saveTodos = (todos: Todo[]): void => { /* 実装 */ };
```

## 7. スタイリング設計

### デザインシステム
- **カラーパレット**:
  - Primary: #3b82f6 (青)
  - Success: #10b981 (緑)
  - Danger: #ef4444 (赤)
  - Gray: #6b7280 (グレー)
  - Background: #f9fafb (薄いグレー)

- **フォント**:
  - システムフォント使用
  - font-family: -apple-system, BlinkMacSystemFont, sans-serif

- **レスポンシブブレイクポイント**:
  - Mobile: ~768px
  - Tablet: 768px~1024px
  - Desktop: 1024px~

### コンポーネント別スタイル
- **App**: メインコンテナ、最大幅設定
- **Header**: 中央揃え、マージン設定
- **TodoForm**: フレックスレイアウト、入力フィールド+ボタン
- **TodoList**: 縦並びリスト、境界線
- **TodoItem**: フレックスレイアウト、ホバーエフェクト

## 8. 状態管理フロー

### データフロー図
```
User Input → TodoForm → App (addTodo) → useTodos → localStorage
                                      ↓
                                   TodoList → TodoItem
```

### 主要な処理フロー

#### TODO追加フロー
1. ユーザーがTodoFormで入力
2. フォーム送信でonAddTodo呼び出し
3. App.tsxでaddTodo実行
4. useTodosでUUID生成、状態更新
5. ローカルストレージに保存
6. 再レンダリングでリスト更新

#### TODO完了切り替えフロー
1. TodoItemでチェックボックスクリック
2. onToggle → App.tsx → useTodos
3. 該当TODOのcompleted状態反転
4. ローカルストレージ更新
5. 再レンダリングで表示更新

#### TODO削除フロー
1. TodoItemで削除ボタンクリック
2. onDelete → App.tsx → useTodos
3. 配列からfilterで該当TODO除去
4. ローカルストレージ更新
5. 再レンダリングでリスト更新

## 9. エラーハンドリング

### ローカルストレージエラー
- 容量不足時の処理
- パース エラー時のフォールバック
- 不正データ時の初期化

### 入力検証
- 空文字入力の防止
- 長すぎるタイトルの制限（最大200文字）
- 特殊文字のサニタイゼーション

## 10. パフォーマンス考慮事項

### 最適化手法
- React.memo使用によるコンポーネントの不要な再レンダリング防止
- useCallbackによるイベントハンドラーの最適化
- キー属性による効率的なリスト更新

### メモリ管理
- 大量データ時の仮想化は今回対象外
- ローカルストレージ容量制限の考慮

## 11. テスト戦略（参考）

### 単体テスト対象
- カスタムフック（useTodos）
- ユーティリティ関数（storage）
- 主要コンポーネントの動作

### E2Eテスト対象
- TODO追加→表示→完了→削除の一連フロー
- ページリロード後のデータ永続化確認

実行計画書:implementations.mdの中身

実行計画書 
# TODOアプリ 実装計画書

## 1. 開発方針

### アジャイル・スクラム開発アプローチ
- **スプリント期間**: 1週間想定
- **ユーザーストーリー単位**: 独立してテスト・デプロイ可能な単位
- **優先順位**: MVP（最小実用製品）から段階的に機能拡張
- **インクリメンタル開発**: 各ストーリー完了時点で動作するアプリケーション

### 完了の定義（DoD: Definition of Done）
- [ ] コードが書かれている
- [ ] TypeScript型チェックが通る
- [ ] ローカル環境で動作確認済み
- [ ] 基本的な手動テストが完了
- [ ] コードレビューが完了（セルフレビュー）

## 2. エピック分解

### エピック1: 基盤構築
**目的**: 開発環境とプロジェクト基盤の構築
**価値**: 開発を開始できる状態にする

### エピック2: 基本CRUD機能
**目的**: TODOの基本的な操作機能を提供
**価値**: ユーザーがTODOアプリとして最低限使用できる

### エピック3: UI/UX改善
**目的**: 使いやすく美しいインターフェースの提供
**価値**: ユーザーエクスペリエンスの向上

### エピック4: データ永続化
**目的**: ブラウザを閉じてもデータが保持される
**価値**: 実用的なアプリケーションとして機能

## 3. ユーザーストーリー一覧

### 優先度: High（必須機能）

#### US-001: プロジェクト初期化
**As a** 開発者  
**I want to** React + TypeScript + Viteプロジェクトを初期化したい  
**So that** 開発を開始できる

**受け入れ条件**:
- [ ] Vite + React + TypeScriptプロジェクトが作成される
- [ ] 必要な依存関係がインストールされる
- [ ] 開発サーバーが起動できる
- [ ] 基本的なディレクトリ構造が作成される

**見積もり**: 2ポイント  
**エピック**: 基盤構築

---

#### US-002: 型定義とユーティリティ作成
**As a** 開発者  
**I want to** TypeScript型定義とユーティリティ関数を作成したい  
**So that** 型安全な開発ができる

**受け入れ条件**:
- [ ] Todo型が定義される
- [ ] ローカルストレージ操作関数が作成される
- [ ] UUID生成関数が実装される

**見積もり**: 3ポイント  
**エピック**: 基盤構築

---

#### US-003: 基本レイアウト作成
**As a** ユーザー  
**I want to** アプリケーションの基本レイアウトを見たい  
**So that** TODOアプリだと認識できる

**受け入れ条件**:
- [ ] Headerコンポーネントが表示される
- [ ] アプリタイトル「TODO App」が表示される
- [ ] 基本的なスタイリングが適用される
- [ ] レスポンシブ対応される

**見積もり**: 3ポイント  
**エピック**: 基本CRUD機能

---

#### US-004: TODO追加機能
**As a** ユーザー  
**I want to** 新しいTODOを追加したい  
**So that** やるべきことを記録できる

**受け入れ条件**:
- [ ] 入力フォームが表示される
- [ ] テキストを入力してEnterキーで追加できる
- [ ] 「追加」ボタンをクリックして追加できる
- [ ] 空文字では追加できない
- [ ] 追加後に入力フィールドがクリアされる
- [ ] 追加されたTODOが画面に表示される

**見積もり**: 5ポイント  
**エピック**: 基本CRUD機能

---

#### US-005: TODO一覧表示機能
**As a** ユーザー  
**I want to** 追加したTODOの一覧を見たい  
**So that** 現在のタスクを把握できる

**受け入れ条件**:
- [ ] TODOアイテムがリスト形式で表示される
- [ ] 各TODOにタイトルが表示される
- [ ] 完了/未完了の状態が視覚的に区別される
- [ ] TODOが0件の時は適切なメッセージが表示される

**見積もり**: 3ポイント  
**エピック**: 基本CRUD機能

---

#### US-006: TODO完了切り替え機能
**As a** ユーザー  
**I want to** TODOの完了状態を切り替えたい  
**So that** 完了したタスクを管理できる

**受け入れ条件**:
- [ ] 各TODOにチェックボックスが表示される
- [ ] チェックボックスをクリックで完了/未完了を切り替えられる
- [ ] 完了したTODOは打ち消し線で表示される
- [ ] 完了したTODOは薄いグレーで表示される

**見積もり**: 4ポイント  
**エピック**: 基本CRUD機能

---

#### US-007: TODO削除機能
**As a** ユーザー  
**I want to** 不要になったTODOを削除したい  
**So that** リストを整理できる

**受け入れ条件**:
- [ ] 各TODOに削除ボタンが表示される
- [ ] 削除ボタンをクリックでTODOが削除される
- [ ] 削除されたTODOは一覧から消える
- [ ] 削除ボタンは×アイコンまたは「削除」テキスト

**見積もり**: 3ポイント  
**エピック**: 基本CRUD機能

---

#### US-008: ローカルストレージ連携
**As a** ユーザー  
**I want to** ブラウザを閉じても追加したTODOが保持されたい  
**So that** 継続的にTODOアプリを使用できる

**受け入れ条件**:
- [ ] TODOの追加時にローカルストレージに保存される
- [ ] TODOの完了切り替え時にローカルストレージが更新される
- [ ] TODOの削除時にローカルストレージが更新される
- [ ] ページリロード時にローカルストレージからデータが復元される
- [ ] 不正データ時は空配列で初期化される

**見積もり**: 5ポイント  
**エピック**: データ永続化

---

### 優先度: Medium（改善機能）

#### US-009: 統計情報表示
**As a** ユーザー  
**I want to** TODOの統計情報を見たい  
**So that** 進捗状況を把握できる

**受け入れ条件**:
- [ ] ヘッダーに総TODO数が表示される
- [ ] ヘッダーに完了済みTODO数が表示される
- [ ] 「X件中Y件完了」形式で表示される

**見積もり**: 2ポイント  
**エピック**: UI/UX改善

---

#### US-010: スタイリング強化
**As a** ユーザー  
**I want to** 美しく使いやすいUIを使いたい  
**So that** 快適にTODOアプリを使用できる

**受け入れ条件**:
- [ ] モダンなデザインが適用される
- [ ] ホバーエフェクトが実装される
- [ ] カラーパレットが統一される
- [ ] 適切な余白・レイアウトが設定される
- [ ] ボタンやフォームが美しくスタイリングされる

**見積もり**: 5ポイント  
**エピック**: UI/UX改善

---

#### US-011: 入力バリデーション強化
**As a** ユーザー  
**I want to** 適切な入力制限があるフォームを使いたい  
**So that** 誤った操作を防げる

**受け入れ条件**:
- [ ] 200文字を超える入力は制限される
- [ ] 入力中の文字数が表示される
- [ ] 空白のみの入力は無効とされる
- [ ] 長すぎる入力時は警告メッセージが表示される

**見積もり**: 3ポイント  
**エピック**: UI/UX改善

---

### 優先度: Low（将来機能）

#### US-012: パフォーマンス最適化
**As a** 開発者  
**I want to** アプリケーションのパフォーマンスを最適化したい  
**So that** 大量のTODOでも快適に動作する

**受け入れ条件**:
- [ ] React.memoによる不要な再レンダリング防止
- [ ] useCallbackによるイベントハンドラー最適化
- [ ] 適切なキー属性によるリスト更新最適化

**見積もり**: 3ポイント  
**エピック**: UI/UX改善

---

## 4. スプリント計画

### スプリント1: MVP開発（1週間）
**目標**: 基本的なTODOアプリとして機能する
**含まれるストーリー**:
- US-001: プロジェクト初期化 (2pt)
- US-002: 型定義とユーティリティ作成 (3pt)
- US-003: 基本レイアウト作成 (3pt)
- US-004: TODO追加機能 (5pt)
- US-005: TODO一覧表示機能 (3pt)
- US-006: TODO完了切り替え機能 (4pt)
- US-007: TODO削除機能 (3pt)

**合計**: 23ポイント

### スプリント2: データ永続化・改善（1週間）
**目標**: 実用的なアプリケーションとして完成
**含まれるストーリー**:
- US-008: ローカルストレージ連携 (5pt)
- US-009: 統計情報表示 (2pt)
- US-010: スタイリング強化 (5pt)
- US-011: 入力バリデーション強化 (3pt)

**合計**: 15ポイント

### スプリント3: 最適化・仕上げ（必要に応じて）
**目標**: パフォーマンス最適化と最終調整
**含まれるストーリー**:
- US-012: パフォーマンス最適化 (3pt)
- バグ修正・調整作業

**合計**: 3ポイント + α

## 5. 技術的負債・リスク管理

### 技術的負債
- CSS Modulesの導入は後回し（初期はグローバルCSS）
- テストコードは最小限（手動テストメイン）
- エラーハンドリングは基本的なもののみ

### リスク要因
- **リスク**: ローカルストレージの容量制限
  **対策**: 基本的なエラーハンドリングで対応
- **リスク**: ブラウザ互換性問題
  **対策**: モダンブラウザのみサポート明記

## 6. 完成基準

### MVP完成基準
- [ ] TODOの追加・表示・完了切り替え・削除ができる
- [ ] ローカルストレージでデータが永続化される
- [ ] レスポンシブデザインで各デバイスで使用可能
- [ ] 基本的なスタイリングが適用されている
- [ ] README.mdに実行方法が記載されている

### 最終完成基準
- [ ] 美しいUI/UXが実装されている
- [ ] 統計情報が表示されている
- [ ] 入力バリデーションが適切に機能している
- [ ] パフォーマンスが最適化されている
- [ ] エラーハンドリングが適切に実装されている

実際の開発中のチャットのやりとり

内容

次のissueを対応してください。

了解しました。次のissue [US-004] TODO追加機能に進みます。実行フェーズを最初から繰り返して対応します。

まず、現在のopenなissueを確認し、[US-004]の詳細を把握してから作業を開始します。
Ran tool
[US-004] TODO追加機能のissueを確認しました。まず、mainブランチに戻ってから新しい作業ブランチを作成します。

git checkout main

git pull origin main

mainブランチが最新の状態に更新されました。次に、[US-004]用の作業ブランチをローカルで作成します。

git checkout -b feature/us-004-todo-add

作業ブランチを作成しました。次に、[US-004]の実装詳細に従ってTODO追加機能を実装します。

実装内容：

  1. src/components/TodoForm/TodoForm.tsxコンポーネント作成
  2. 入力フォームとボタンのUI実装
  3. フォーム送信処理の実装
  4. 入力バリデーション（空文字チェック）
  5. useTodosカスタムフック作成

まず、useTodosカスタムフックを作成します：
次に、TodoFormコンポーネントを作成します：
TypeScriptの型のみのインポートエラーを修正します：
次に、TodoFormのCSSスタイリングを作成します：
次に、簡単なTODO表示用のコンポーネントを作成します（今回は追加されたTODOが画面に表示されることを確認するため）：
TodoListのCSSスタイリングを作成します：
次に、App.tsxを更新してTodoFormとTodoListを統合します：
Read file: src/App.tsx
App.tsxを更新してTodoFormとTodoListを統合します：
実装が完了したので、TypeScriptの型チェックを実行して問題がないことを確認します：

npx tsc --noEmit

TypeScriptの型チェックが正常に完了しました。実装が完了したので、受け入れ条件を確認し、コミットしてPull Requestを作成します。

受け入れ条件の確認：

✅ 入力フォームが表示される - TodoFormコンポーネントで実装
✅ テキストを入力してEnterキーで追加できる - handleKeyDown関数で実装
✅ 「追加」ボタンをクリックして追加できる - handleSubmit関数で実装
✅ 空文字では追加できない - バリデーションとdisabled属性で実装
✅ 追加後に入力フィールドがクリアされる - setTitle('')で実装
✅ 追加されたTODOが画面に表示される - TodoListコンポーネントで実装

変更をコミットしてPull Requestを作成します：

git add .

git commit -m "feat: [US-004] TODO追加機能

- useTodosカスタムフック作成
  - TODO状態管理とCRUD操作を実装
  - ローカルストレージとの連携機能
- TodoFormコンポーネント作成
  - 入力フォームとボタンのUI実装
  - Enterキー・ボタンクリックでの送信処理
  - 空文字バリデーション（disabled状態）
  - 送信後の入力フィールドクリア機能
- TodoListコンポーネント作成
  - TODO一覧表示機能
  - 空リスト時のメッセージ表示
- App.tsxにTodoForm・TodoListを統合
- レスポンシブデザイン対応
- TypeScript型チェック正常完了"

git push origin feature/us-004-todo-add

次に、Pull Requestを作成します：
Ran tool
[US-004] TODO追加機能の実行フェーズが完了しました！

実行内容

✅ 作業ブランチの作成: ローカルでfeature/us-004-todo-addブランチを作成してチェックアウト

✅ useTodosカスタムフック作成:

  • TODO状態管理とCRUD操作を実装
  • ローカルストレージとの自動連携機能
  • addTodo, toggleTodo, deleteTodo関数を提供

✅ TodoFormコンポーネント作成:

  • 入力フォームとボタンのUI実装
  • Enterキー・ボタンクリックでの送信処理
  • 空文字バリデーション（disabled状態）
  • 送信後の入力フィールド自動クリア

✅ TodoListコンポーネント作成:

  • TODO一覧表示機能
  • 空リスト時の案内メッセージ表示
  • カード型デザインとホバーエフェクト

✅ App.tsx統合: TodoFormとTodoListを統合し、useTodosフックでデータフロー管理

✅ レスポンシブデザイン対応: モバイル・タブレット対応のスタイリング

✅ 型チェック確認: TypeScript型チェック正常完了

✅ コミット: 適切なコミットメッセージで変更をコミット

✅ Pull Request作成: PR #24を作成し、Issue #14と関連付け

受け入れ条件の達成状況

  • 入力フォームが表示される
  • テキストを入力してEnterキーで追加できる
  • 「追加」ボタンをクリックして追加できる
  • 空文字では追加できない
  • 追加後に入力フィールドがクリアされる
  • 追加されたTODOが画面に表示される

技術的特徴

  • 型安全性: TypeScript型定義による厳密な型チェック
  • 状態管理: Reactカスタムフックによる状態の一元管理
  • データ永続化: ローカルストレージとの自動同期
  • UX配慮: 直感的な操作とフィードバック
  • アクセシビリティ: フォーカス状態とキーボード操作対応

[US-004] TODO追加機能のPull Requestまで作成が完了しました。TODOアプリの基本的な追加機能が実装され、ユーザーが新しいタスクを記録できるようになりました。

まとめ

CursorのProject Rulesを活用することで、Kiroライクなスペック駆動開発を実現できたと感じています。

メリット：

  • 要件が曖昧なままコーディングを始めることがなくなった
  • 設計書やドキュメントが自動生成される
  • GitHub Issuesで進捗管理ができる
  • 段階的な確認により品質が向上する

ぜひ試してみてください！

9
5
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
9
5

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?