Kiroとおしゃべりしてみた-2.機能追加してみた-

Kiroで期限日機能を追加：品質担保プロセスの実践記録

はじめに

前回のブログでKiroを使ってタスク管理CLIアプリケーション「kirotask」を開発しました。今回は、そのアプリに期限日機能を追加する過程を記録します。

この記事では、以下の点に焦点を当てています：

• 🔄 機能追加のプロセス: 既存アプリへの新機能追加体験
• 📊 品質担保の実践: 開発ログシステムによる包括的な記録管理
• 🧪 テスト駆動開発: 71個のテストによる品質保証
• 🎯 実用性の向上: 自然言語での日付入力、視覚的インジケータ

結論を先に言うと: Kiroは既存プロジェクトへの機能追加でも優秀で、品質担保プロセスを体系化することで安心して開発を進められました。

---

🎯 今回のプロジェクト概要

ベースアプリ: kirotask（前回開発したタスク管理CLI）
追加機能: タスクの期限日管理
開発アプローチ: 品質担保を重視した段階的実装

追加する機能

• 📅 期限日設定: タスク作成時・後から期限日を設定
• 🎨 視覚的表示: 期限切れ🔴、期限間近🟡、通常📅のインジケータ
• 🔍 フィルタリング: 期限切れ・期限間近タスクの絞り込み
• 🗣️ 自然言語対応: "today", "tomorrow", "next week"などの日付入力
• 🧹 期限日管理: 期限日の変更・削除機能

---

📋 フェーズ1: 品質担保システムの構築

機能追加を始める前に、まず品質担保のための記録システムを整備しました。

記録システムの必要性

私

これからアプリに機能追加をします。それに伴う修正点や影響範囲、その判断根拠、テストの実行結果やエラーだった場合の記録、エラー修正の根拠など、アプリの品質を担保するために必要な情報を記録したい。ほかにどのような項目が必要ですか

Kiro

アプリの品質担保のために、以下の項目を記録することをお勧めします：

## 必要な記録項目

### 1. 機能追加・変更記録
- **変更概要** - 何を追加/変更したか
- **変更理由** - なぜその変更が必要だったか
- **影響範囲分析** - どのファイル・機能に影響するか
- **リスク評価** - 潜在的な問題点

### 2. 技術的決定事項
- **設計判断** - なぜその実装方法を選んだか
- **代替案検討** - 他にどんな選択肢があったか
- **パフォーマンス考慮** - 性能への影響
- **セキュリティ考慮** - セキュリティへの影響

### 3. テスト・品質管理
- **テスト戦略** - どのようなテストを実施したか
- **テスト結果** - 成功/失敗の詳細
- **エラー詳細** - エラーメッセージ、スタックトレース
- **修正履歴** - エラー修正の過程と根拠
- **回帰テスト** - 既存機能への影響確認

### 4. 依存関係・互換性
- **依存関係変更** - 新しいライブラリ追加や更新
- **バージョン互換性** - 既存バージョンとの互換性
- **環境依存** - 特定環境での動作要件

### 5. ドキュメント・コミュニケーション
- **API変更** - インターフェース変更の詳細
- **使用方法変更** - ユーザーへの影響
- **チーム共有事項** - 他の開発者が知るべき情報

### 6. 運用・保守性
- **デプロイ手順** - 本番環境への適用方法
- **ロールバック計画** - 問題発生時の対処法
- **監視ポイント** - 運用時に注意すべき点
- **保守性向上** - コードの可読性・保守性への配慮

開発ログシステムの構築

Kiroの提案を受けて、development-log.mdファイルを作成し、包括的な開発記録システムを構築しました。

作成したファイル:

• development-log.md - 機能追加・変更の詳細記録
• chat-log.md - 会話履歴の記録

記録テンプレート:

### [日付: YYYY-MM-DD] - [変更タイトル]

#### 1. 機能追加・変更記録
- **変更概要**: 
- **変更理由**: 
- **影響範囲分析**: 
- **リスク評価**: 

#### 2. 技術的決定事項
- **設計判断**: 
- **代替案検討**: 
- **パフォーマンス考慮**: 
- **セキュリティ考慮**: 

#### 3. テスト・品質管理
- **テスト戦略**: 
- **テスト結果**: 
- **エラー詳細**: 
- **修正履歴**: 
- **回帰テスト**: 

#### 4. 依存関係・互換性
- **依存関係変更**: 
- **バージョン互換性**: 
- **環境依存**: 

#### 5. ドキュメント・コミュニケーション
- **API変更**: 
- **使用方法変更**: 
- **チーム共有事項**: 

#### 6. 運用・保守性
- **デプロイ手順**: 
- **ロールバック計画**: 
- **監視ポイント**: 
- **保守性向上**: 

---

💻 フェーズ2: 期限日機能の実装

品質担保システムが整ったところで、期限日機能の実装を開始しました。

実装アプローチ

私

ではkirotaskに機能追加をします。タスクの完了期限日を登録できるようにしてください。

Kiroは既存のコードベースを分析し、影響範囲を特定してから実装を開始しました。

影響範囲分析

変更対象ファイル:

• src/models/Task.ts - TaskインターフェースにdueDateフィールド追加
• src/services/TaskService.ts - 期限日設定・更新機能追加
• src/cli/commands.ts - 期限日指定コマンド追加、表示形式変更
• src/repositories/TaskRepository.ts - 期限日の永続化対応
• テストファイル群 - 新機能のテスト追加

データ互換性: 既存データは期限日なしとして扱う（後方互換性維持）

段階的実装プロセス

1. データモデルの拡張

// src/models/Task.ts
export interface Task {
  id: number;
  description: string;
  completed: boolean;
  createdAt: Date;
  updatedAt: Date;
  dueDate?: Date; // 新規追加（オプショナル）
}

2. 日付ユーティリティの作成

自然言語での日付入力をサポートするため、専用のユーティリティを作成：

// src/utils/dateUtils.ts
export function parseDate(dateString: string): Date {
  const input = dateString.trim().toLowerCase();
  
  // 相対日付の処理
  switch (input) {
    case 'today':
    case '今日':
      return new Date(now.getFullYear(), now.getMonth(), now.getDate());
    case 'tomorrow':
    case '明日':
      return new Date(now.getFullYear(), now.getMonth(), now.getDate() + 1);
    case 'next week':
    case '来週':
      const nextWeek = new Date(now);
      nextWeek.setDate(now.getDate() + 7);
      return new Date(nextWeek.getFullYear(), nextWeek.getMonth(), nextWeek.getDate());
  }
  
  // ISO形式の日付処理
  const isoDate = new Date(dateString);
  if (!isNaN(isoDate.getTime())) {
    return isoDate;
  }
  
  throw new Error(`無効な日付形式です: ${dateString}`);
}

3. サービス層の拡張

// src/services/TaskService.ts
export interface ITaskService {
  addTask(description: string, dueDate?: string): Task;
  setDueDate(id: number, dueDate: string): Task | null;
  clearDueDate(id: number): Task | null;
  listTasks(filter?: 'all' | 'completed' | 'pending' | 'overdue' | 'due-soon'): Task[];
}

4. CLI機能の拡張

# 新しいコマンド例
kirotask add "レポートを書く" --due "2025-12-31"
kirotask add "会議準備" --due tomorrow
kirotask due 2 "next week"
kirotask clear-due 2
kirotask list overdue
kirotask list due-soon

5. 視覚的表示の実装

タスク一覧:
────────────────────────────────────────────────────────────────────────────────
[✓] 1. 買い物に行く
[ ] 2. レポートを書く 📅 期限: 2025/12/25
[ ] 4. 期限付きタスクのテスト 🟡 期限間近: 明日
[ ] 5. 期限切れタスクのテスト 🔴 期限切れ: 2025/1/1
────────────────────────────────────────────────────────────────────────────────
合計: 4件

---

🧪 フェーズ3: テスト駆動品質保証

テスト戦略

ユニットテスト:

• 日付解析機能のテスト
• 期限日設定・クリア機能のテスト
• フィルタリング機能のテスト

プロパティベーステスト:

• 期限日の一貫性テスト
• 表示フォーマットの一貫性テスト
• データ永続化の往復テスト

実装したテスト例

日付ユーティリティのテスト

// src/utils/dateUtils.test.ts
describe('parseDate', () => {
  it('ISO形式の日付を正しく解析する', () => {
    const result = parseDate('2025-12-31');
    expect(result).toEqual(new Date(2025, 11, 31));
  });

  it('相対日付（tomorrow）を正しく解析する', () => {
    const result = parseDate('tomorrow');
    expect(result).toEqual(new Date(2025, 11, 11));
  });

  it('無効な日付形式でエラーを投げる', () => {
    expect(() => parseDate('invalid-date')).toThrow('無効な日付形式です');
  });
});

プロパティベーステスト

// src/services/TaskService.test.ts
it('should preserve due date through task operations', () => {
  fc.assert(
    fc.property(
      fc.string({ minLength: 1, maxLength: 100 }).filter(s => s.trim().length > 0),
      fc.date({ min: new Date('2025-01-01'), max: new Date('2026-12-31') }),
      (description, dueDate) => {
        const dueDateString = dueDate.toISOString().split('T')[0];
        
        // 期限日付きタスクを追加
        const task = service.addTask(description, dueDateString);
        expect(task.dueDate).toBeDefined();

        // 説明を更新しても期限日は保持される
        const updated = service.updateTask(task.id, 'Updated description');
        expect(updated?.dueDate?.getTime()).toBe(task.dueDate?.getTime());

        // 完了状態を切り替えても期限日は保持される
        const toggled = service.toggleTask(task.id);
        expect(toggled?.dueDate?.getTime()).toBe(task.dueDate?.getTime());
      }
    ),
    { numRuns: 50 }
  );
});

テスト実行結果

npm test

> kirotask@1.0.0 test
> vitest run

✓ src/utils/dateUtils.test.ts (22)
✓ src/utils/validation.test.ts (3)
✓ src/repositories/TaskRepository.test.ts (5)
✓ src/services/TaskService.test.ts (28)
✓ src/cli/commands.test.ts (13)

Test Files  5 passed (5)
Tests       71 passed (71)

全71テストが成功！ 🎉

---

🎯 フェーズ4: 動作確認と品質検証

実際の動作確認

# 期限日付きタスクの作成
$ kirotask add "期限付きタスクのテスト" --due tomorrow
✓ タスクを追加しました (ID: 4) - 期限: 明日

$ kirotask add "期限切れタスクのテスト" --due "2025-01-01"
✓ タスクを追加しました (ID: 5) - 期限: 2025/1/1

# タスク一覧の表示
$ kirotask list

タスク一覧:
────────────────────────────────────────────────────────────────────────────────
[✓] 1. 買い物に行く
[ ] 2. レポートを書く
[ ] 4. 期限付きタスクのテスト 🟡 期限間近: 明日
[ ] 5. 期限切れタスクのテスト 🔴 期限切れ: 2025/1/1
────────────────────────────────────────────────────────────────────────────────
合計: 4件

# 期限切れタスクのフィルタリング
$ kirotask list overdue

タスク一覧:
────────────────────────────────────────────────────────────────────────────────
[ ] 5. 期限切れタスクのテスト 🔴 期限切れ: 2025/1/1
────────────────────────────────────────────────────────────────────────────────
合計: 1件

# 期限日の設定
$ kirotask due 2 "2025-12-25"
✓ タスク 2 の期限日を 2025/12/25 に設定しました

品質指標の確認

テスト結果: 71/71 成功
後方互換性: 100% 維持
データ永続化: 正常動作確認済み
新機能: 全て正常動作

---

📊 開発ログによる品質担保

記録された情報

技術的決定事項

• 設計判断: dueDateはオプショナル（Date | undefined）として実装
• 代替案検討: 文字列形式での保存 → Date型の方が操作しやすい
• パフォーマンス考慮: 日付比較処理が追加されるが、小規模データのため影響軽微

テスト・品質管理

• テスト戦略: 単体テスト、プロパティベーステスト、エッジケース
• テスト結果: ✅ 全テスト成功（22個の新規テスト追加）
• 回帰テスト: ✅ 既存機能の動作確認完了

運用・保守性

• デプロイ手順: 既存データのバックアップ → 新バージョンのデプロイ → データ移行の確認
• ロールバック計画: dueDateフィールドを除去してロールバック可能
• 保守性向上: 日付関連のユーティリティ関数を分離、エラーハンドリングの強化

品質担保の効果

1. 透明性の向上

• すべての変更理由と判断根拠が記録される
• 後から振り返って意思決定プロセスを確認できる

2. リスク管理

• 影響範囲の事前分析により予期しない問題を回避
• ロールバック計画により安全な機能追加が可能

3. 学習効果

• 実装プロセスが体系的に記録される
• 同様の機能追加時の参考資料として活用可能

---

🚀 実装完了サマリー

追加された機能

機能	説明	コマンド例
期限日設定	タスク作成時に期限日を設定	kirotask add "タスク" --due tomorrow
期限日管理	既存タスクの期限日を設定・変更	kirotask due 2 "2025-12-31"
期限日クリア	期限日を削除	kirotask clear-due 2
視覚的表示	期限切れ🔴、期限間近🟡、通常📅	kirotask list
フィルタリング	期限日によるタスク絞り込み	kirotask list overdue
自然言語対応	多様な日付形式をサポート	--due "next week"

追加されたファイル

• src/utils/dateUtils.ts - 日付解析・フォーマット・判定機能
• src/utils/dateUtils.test.ts - 日付ユーティリティのテスト（22テスト）

変更されたファイル

• src/models/Task.ts - dueDateフィールド追加
• src/services/TaskService.ts - 期限日関連メソッド追加
• src/repositories/TaskRepository.ts - 期限日の永続化対応
• src/cli/commands.ts - 期限日コマンドと表示機能追加
• テストファイル群 - 期限日機能のテスト追加（20テスト）
• README.md - 期限日機能の説明追加

品質指標

• テスト数: 44個 → 71個（27個追加）
• テスト成功率: 100%
• 後方互換性: 100% 維持
• 新機能カバレッジ: 100%

---

作業記録をファイルに残すことによりKiroの行動を把握しやすくなり、品膣確保しやすくなりました。

変更されたファイルの内容から、ソースコードの修正とテストを実行したが、要件定義書が修正されていないことがわかります。

私

アプリとrequirements.mdの内容が異なりますが、これらを一致させる必要はありますか

Kiro

はい、アプリと requirements.md の内容を一致させることは非常に重要です。これは仕様駆動開発の基本原則の一つです。

これって指示しないとダメなんでしょうか？

私

design.mdやtasts.mdの変更は不要ですか？

Kiro

はい、design.md と tasks.md の更新も必要です。仕様駆動開発では、requirements → design → tasks の一貫性を保つことが重要です。

これって指示しないとダメなんでしょうか？？

🎯 学んだこと・感想

品質担保プロセスの価値

1. 安心感の向上

開発ログシステムにより、「なぜその実装を選んだのか」「どんなリスクがあるのか」が明確になり、安心して機能追加を進められました。

2. 問題の早期発見

影響範囲分析により、事前に対応が必要な箇所を特定でき、後戻りを最小限に抑えられました。

3. 学習効果の最大化

実装プロセスが体系的に記録されるため、「なぜそうなったのか」を後から振り返って学習できます。

Kiroの機能追加における優秀さ

1. 既存コードの理解力

• 既存のアーキテクチャを正確に把握
• 影響範囲を適切に分析
• 一貫性のある実装を提案

2. 段階的な実装

• データモデル → ユーティリティ → サービス → CLI の順序で実装
• 各段階でテストを実行して品質を確認
• 既存機能への影響を最小限に抑制

3. 包括的なテスト

• 新機能のユニットテスト
• プロパティベーステスト
• 既存機能の回帰テスト
• 統合テスト

改善点・今後の課題

1. 実装速度と理解のバランス

問題: 大量のコードが短時間で生成される
対策: 重要な部分は実装前に設計を確認する

2. 品質担保の自動化

問題: 開発ログの記録が手動
対策: CI/CDパイプラインとの連携を検討

3. チーム開発での活用

問題: 個人開発での体験のみ
対策: 複数人でのレビュープロセスを確立

---

🚨 重要な発見：仕様駆動開発の課題

仕様書と実装の不一致問題

機能追加完了後、重要な問題が発覚しました：

私

アプリとrequirements.mdの内容が異なりますが、これらを一致させる必要はありますか

Kiro

はい、アプリと requirements.md の内容を一致させることは**非常に重要**です。これは仕様駆動開発の基本原則の一つです。

発覚した不一致:

• requirements.md に期限日機能の要件が含まれていない
• design.md のデータモデルが古い
• tasks.md に期限日関連のタスクが記録されていない

仕様書更新作業

Kiroと協力して、以下の仕様書を手動で更新しました：

requirements.md の更新:

• 要件7（期限日管理）を新規追加
• 要件1、5、8に期限日関連の受け入れ基準を追加
• 用語集に期限日関連の定義を追加

design.md の更新:

• Task インターフェースに dueDate フィールドを追加
• サービスインターフェースに期限日メソッドを追加
• 正確性プロパティ17-21を追加

tasks.md の更新:

• セクション8「期限日機能の実装」を追加
• 12個の実装タスクと6個のテストタスクを追加

根本的な問題の指摘

私

requirements.mdなどの修正は私が指示する必要がありましたか？Kiroがコード修正時に自動的にすべきことではありませんか？

この質問により、仕様駆動開発における重要な改善点が明らかになりました。

🔄 理想的なワークフローとの比較

現在の問題のあるフロー

機能追加指示 → 実装のみ → 仕様書との不一致 → 手動で仕様書更新

あるべき理想的なフロー

機能追加指示 → 実装 + 仕様書自動更新 → 常に一貫性維持

Kiroが自動更新すべき内容

機能追加時に同時更新すべきファイル:

1. requirements.md: 新機能の要件と受け入れ基準
2. design.md: データモデル、インターフェース、プロパティ
3. tasks.md: 実装タスクとテストタスク
4. README.md: 使用方法とコマンド例

自動更新のメリット:

• 仕様書と実装の一貫性を常に保持
• 開発者の手動更新負荷を削減
• 仕様駆動開発のベストプラクティスを自動化

🎯 まとめ

今回の成果

✅ 完全に動作する期限日機能の実装
✅ 71個のテストによる品質保証
✅ 100%の後方互換性維持
✅ 体系的な品質担保プロセスの確立
✅ 包括的な開発記録の作成
✅ 仕様書と実装の完全な一貫性確保

Kiroの機能追加における価値

今回の体験を通じて、Kiroは新規開発だけでなく既存プロジェクトへの機能追加でも非常に優秀であることが分かりました。

特に優れていた点:

• 既存コードベースの正確な理解
• 影響範囲の適切な分析
• 段階的で安全な実装アプローチ
• 包括的なテスト戦略

発見された改善点

仕様書の自動更新が最も重要な改善点として浮上しました：

現状の課題:

• 実装変更時に仕様書が自動更新されない
• 手動での一貫性維持が必要
• 仕様駆動開発のワークフローが不完全

期待される改善:

• 機能追加時の仕様書自動更新
• 実装と仕様の常時同期
• 完全自動化された仕様駆動開発

↑これは解決されていない課題なのでしょうか？普通にやってくれるものだと思っていたのですが。

Kiro における負債にならない Spec ファイルの扱い方

Vibe から Spec に適応する
Kiro の Vibe モードをまずは立ち上げ、その中で会話や実装を行います。その後、Kiroに「ここまでの変更を Spec に変換して」というと、これまでのVibe モードのコンテキストから Spec ファイルを構築することが可能となります。特に実装の初期フェーズでは、言語化が固まりきっていない段階の「思考の断片」を Spec に落とし込める点が非常に便利です。

本来はVibeモードを使ってSpecファイルに落とし込む方法をとるようですね。
壁打ちして変更内容を固め、動作確認をしてから、Specファイルに反映させる許可を出す。
requirements.mdの編集ではなく、Specファイルの編集と指示を出せばdesign.mdやtasts.mdも連動して編集できたのかもしれません。

品質担保の重要性

開発ログシステムの導入により、「よくわからんが動いている」状態から脱却し、根拠のある品質担保が可能になりました。

重要な学び:

• すべての変更には明確な理由と根拠が必要
• 影響範囲の事前分析がリスク軽減に効果的
• テストは品質の証明だけでなく、安心感の提供にも重要
• 記録は学習効果を最大化する
• 仕様書と実装の一貫性が品質の基盤

最終的な感想

Kiroは開発パートナーとして、新規開発から機能追加まで一貫してサポートしてくれます。特に：

• 品質を重視した開発プロセスを自然に実践できる
• 既存資産を活かした機能拡張が安全に行える
• 包括的なテスト戦略で品質を担保できる
• 体系的な記録で学習効果を最大化できる

一方で、今回の体験で明らかになった改善点もあります：

• 仕様書の自動更新機能の必要性
• 実装と設計の完全同期の重要性
• 仕様駆動開発ワークフローの自動化の価値

生成されたコードの理解と、品質担保プロセスの継続的な改善は、エンジニアの重要な責任です。同時に、AIツールには設計プロセス全体の自動化という次のステップが期待されます。

AIツールの進化により開発効率は大幅に向上しましたが、「なぜその実装を選ぶのか」「どうやって品質を担保するのか」「どうやって一貫性を保つのか」という本質的な問いに答える能力は、これからも人間とAIの協力によって実現されていくでしょう。

---

開発期間: 約1時間
追加コード行数: 約400行
追加テスト数: 27個（1,350回の反復テスト含む）
品質指標: 71/71 テスト成功、100% 後方互換性維持

---

この記事が、Kiroを使った継続的な開発や品質担保プロセスに興味を持つ方の参考になれば幸いです。品質を担保しながら、Kiroとの開発を楽しんでください！