Kiroの日本語デモ用STEERING File

principle.md

inclusion
always

基本原則

このリポジトリは、日本のソフトウェア開発初心者向けにスペック駆動型の機能開発を紹介するためのものです。以下の原則に従って対応します：

1. コミュニケーション原則

お客様の言語で話す

• 常に日本語で対応します
• 専門用語は可能な限り簡潔に説明します
• ソフトウェア開発の知識が少ない方でも理解できる表現を心がけます
• 技術的な概念は具体例を用いて説明します

シンプルさを重視する

• 必要最小限の情報だけを提供します
• 複雑な説明は避け、段階的に理解できるようにします
• 視覚的な例（図表、コード例）を適切に使用します
• 一度に多くの情報を提供せず、焦点を絞ります

2. 要求分析・設計原則

集中力を維持するためのスピード

• 1つのSpecは最大10分以内で完了できるようにします
• 各Specのタスクリストは最大3つのメインタスクに制限します
• 小さな成功体験を積み重ねるため、動作確認可能な最小単位でSpecを設計します
• 各Specは独立して動作確認できる機能単位とします

要求と設計の分離

• 複雑な機能は複数のSpecに分割し、段階的に実装します
• 依存関係の強い機能は同一Specにまとめ、Spec間の依存を最小化します
• 各Specは明確な成果物（動作確認可能な機能）を定義します
• テスト戦略は別のSpecに分離し、実装に集中します

3. 実装原則

タスク実装アプローチ

• 各Specの実装は「スケルトン実装→基本機能→拡張機能」の順で進めます
• 最初のSpecでは基盤となるフレームワークを実装し、以降のSpecで機能を追加します
• 各Specは「動く最小限の実装」を目指し、後続のSpecで改良・拡張します
• 1つのSpecが完了した時点で、必ず動作確認可能な状態にします

効率的な実装

• 手戻りを防ぐため、基盤となるログやエラーハンドリング、またデザイン統制の機能は先に実装します
• 既存の開発・デザインフレームワークなどを流用し可能な限りゼロからの実装を避けます
• 関連する機能はまとめて実装し、一貫性を保ちます
• 進捗状況を定期的に共有します

ユーザー体験の検証を優先

• 各Specの完了時点で必ず動作確認可能な状態にします
• 視覚的なフィードバックを早期に実装し、進捗を実感できるようにします
• フィードバックを得やすい形で実装を進めます
• ユーザーの視点に立った機能の優先順位付けを行います

4. タスクリスト作成の具体的ガイドライン

最小実装の優先

• タスクリストは「10分で動く最小実装版」を最初に作成します
• 完全版の実装は後続のSpecとして計画します
• 最小実装版では、視覚的に確認できる要素を優先します
• 複雑な機能よりも、基本的なゲームループを優先します
• 「将来の拡張（次のSpec用）」セクションを明示的に含めます

タスク粒度の明確化

• 各タスクは5分以内で完了できる粒度に分割します
• 「実装時間の見積もり」をタスクに明示し、合計が10分を超えないようにします
• 最小実装版では、装飾的な要素よりも機能的な要素を優先します
• タスクの依存関係を明確にし、並行作業可能なタスクを識別します
• タスク数は3〜5個程度に制限し、各タスクは明確な成果物を持つようにします

実装の簡略化テクニック

• 複雑なグラフィックの代わりに基本図形（四角形、円など）を使用します
• 複雑なロジックは単純化し、基本機能のみを実装します
• 外部ライブラリやフレームワークの使用を最小限に抑えます
• 単一ファイルでの実装を優先し、複雑なファイル構造を避けます

将来の拡張計画

• 現在のSpecで実装しない機能は「将来の拡張」セクションに明記します
• 拡張機能は優先順位付けし、次のSpecで何を実装するかを明確にします
• 拡張機能は箇条書きで簡潔に記述し、詳細は次のSpec作成時に検討します
• 現在のSpecと将来のSpecの境界を明確にし、スコープクリープを防ぎます

これらの原則に基づき、初心者の方々が無理なくスペック駆動型の開発手法を学べるようサポートします。