仕様駆動開発ツールcc-sddを使ってみました(その２)
STEP4：設計書の作成
/kiro:spec-design health-forecast -y
今回はこのタイミングでコーディングルールなどの実装上の注意事項を投入しました。
> コーディングルールなど実装する上で気をつけて欲しい事柄は、このタイミング依頼すればOKかな？
>
⏺ はい、まさに今が最適なタイミングです！
コーディングルールや実装上の注意事項は、カスタムステアリングファイルとして追加するのがベストプラクティスです。
→今回はチャットで対応したので、別ファイルに保存されています。。。
推奨アプローチ
オプション1: カスタムステアリングとして追加（推奨）
/kiro:steering-custom
このコマンドで、例えば .kiro/steering/coding-rules.md を作成し：
– コーディング規約
– 命名規則
– エラーハンドリングのパターン
– テスト要件
– パフォーマンス考慮事項
などを記述します。
利点:
– タスク生成時に参照される（タスク記述に反映）
– 実装時にも参照される（すべてのフェーズで一貫性）
– プロジェクト全体のドキュメントとして残る
– 他の機能開発でも再利用可能
オプション2: 直接お伝えいただく
このまま会話で教えていただいても構いません。私が：
1. カスタムステアリングファイルを作成
2. 内容を記述
3. タスク生成・実装時に参照
というフローで対応できます。
タイミングについて
– 今（設計完了後）: ✅ ベストタイミング
– タスク生成前なので、タスク記述に反映される
– 実装時も当然参照される
– タスク生成後でも可能: ⚠️ 可能だが、タスクには反映されない
– 実装時には参照されるが、タスク内容は既に確定
どのような内容を含めるとよいか
一般的なコーディングルールの例：
– 型定義（TypeScriptならany禁止など）
– エラーハンドリング（必ずResult型を使うなど）
– 命名規則（変数名、関数名のパターン）
– コメント・ドキュメンテーション要件
– テストカバレッジ目標
– パフォーマンス制約（レスポンスタイム、メモリ使用量）
– セキュリティチェックリスト
– 使用禁止ライブラリや関数
どのような内容をステアリングに追加したいですか？ お伝えいただければ、カスタムステアリングファイルとして作成します。
ここでコーディングルールなどを依頼
⏺ 完璧なタイミングです！詳細な実装ルールをカスタムステアリングファイルとして作成します。
これらのルールをプロジェクト全体で参照できるように、.kiro/steering/implementation-rules.md として保存します。
STEP5：タスクリストの作成
/kiro:spec-tasks health-forecast -y
# 実装計画
– [ ] 1. データベース基盤とスキーマ設計を実装
– [ ] 1.1 予測データ保存用のテーブルを作成
– UUID主キーと管理用シーケンス列を定義
– ユーザーIDとの外部キー関係を設定
– 生成時刻、アルゴリズムタイプ、信頼度スコアのカラムを追加
– 予測配列をJSONB形式で保存するカラムを作成
– 作成・更新タイムスタンプをデフォルトNOW()で追加
– ユーザーIDと生成時刻の複合インデックスを作成
⏺ 要件と設計から実装タスクを生成し、tasks.mdを作成しました。最後のステップとして、spec.jsonを更新して、タスク生成フェーズの完了を記録します。
⏺ Serenaサーバーではソースコードファイルが必要なため、代わりに標準のReadツールとEditツールを使用してspec.jsonを更新します。
⏺ ✅ タスク生成フェーズが完了しました
以下のファイルを生成・更新しました：
1. .kiro/specs/health-forecast/tasks.md – 実装タスク一覧（18個の主要タスク、60以上のサブタスク）
2. .kiro/specs/health-forecast/spec.json – フェーズを tasks-generated に更新
📋 生成されたタスクの概要
実装タスクは以下の領域をカバーしています：
– データベース基盤 (タスク 1): UUID主キー、シーケンス列、タイムスタンプ、トリガー関数
– 予測アルゴリズム (タスク 2-4): 移動平均、線形回帰、パターンマッチング
– バックエンドAPI (タスク 5-7): 予測生成、履歴取得、信頼度計算
– フロントエンド (タスク 8-12): ForecastタブUI、グラフ表示、通知機能
– テスト (タスク 13-16): 単体テスト、統合テスト、E2Eテスト、パフォーマンステスト
– インフラ・デプロイ (タスク 17-18): Docker Compose、PM2設定
すべてのタスクは、ご指定いただいた実装ルール（PostgreSQL UUID設計、タブインデント、JSDocコメントなど）に準拠して記述されています。
🎯 次のステップ
1. タスクのレビュー: .kiro/specs/health-forecast/tasks.md を確認
2. 承認または修正: タスクに問題があれば修正リクエスト
3. 実装開始: /kiro:spec-impl health-forecast [task-numbers] で実装開始
tasks.mdをご確認いただき、内容に問題がなければ実装フェーズに進むことができます。
STEP6：実装
🚀 実装を開始する方法
以下のコマンドで実装を開始できます：
すべてのタスクを実装
/kiro:spec-impl health-forecast
特定のタスクのみ実装（例：タスク1,2,3）
/kiro:spec-impl health-forecast 1,2,3
特定のタスク範囲を実装（例：タスク1-5）
/kiro:spec-impl health-forecast 1-5
💡 推奨される実装順序
- 基盤から開始: タスク1（データベーススキーマ）
- バックエンド構築: タスク2-7（アルゴリズム、API）
- フロントエンド実装: タスク8-12（UI、グラフ、通知）
- テスト: タスク13-16
- デプロイ設定: タスク17-18
実装を開始されますか？それとも、タスクの内容を修正したい箇所がありますか？
このあとは。。
ということで実装が開始されます。
タスクリストをチェックしながら進めてくれるので、安心感はあります。
今回は途中でテストを行わず、フロントエンド実装までを一気に行いテストに入りました。
気になったのは、全体をdocker-compose.ymlで管理をするように指示をしたのですが、フロントエンドの軌道に
npm dev run
と別にされたことです。最初の指示に強調しておく必要があるかもしれないです。
今回は手順の確認をしたかったのでここまでですが、変更やバグ対応が指示の出し方が気を抜いてもOKになることを期待しています(^^)
