development-principles

# Development Principles

## 概要

このSkillは、開発を進める上での基本原則を定義する。曖昧さを排除し、矛盾を検出し、推察を避けることで、手戻りとバグを最小化し、開発効率を最大化することを目的とする。

## 責任範囲

このSkillは以下の範囲をカバーする:

- 曖昧な状態での開発禁止の原則
- 矛盾の検出と報告の方法
- 推察による回答禁止の原則
- 不明点の確認と明確化のプロセス

## 基本方針

- 仕様や要件が不明確な状態で開発を進めない
- ドキュメント間、仕様間、実装間の矛盾を発見した場合は即座に報告する
- ユーザーの意図や要件を推察せず、明示された情報のみに基づいて回答する
- 不明点があれば必ず質問し、明確化してから作業を開始する

## 曖昧な状態での開発禁止

### 原則

仕様、要件、期待される動作が不明確な場合、実装やドキュメント作成を進めず、必ずユーザーに質問する。

### 理由

曖昧さは手戻りとバグの温床となり、開発効率を著しく低下させる。

### 対応方法

不明点があれば必ず質問し、明確化してから作業を開始する。

### 曖昧さの検出

以下の場合は曖昧であると判断する:

- 仕様や要件が複数の解釈が可能
- 期待される動作が明示されていない
- 前提条件や制約事項が不明確
- 用語の定義が曖昧
- データ形式や範囲が明示されていない

良い例:

```text
ユーザー: 「ユーザー管理機能を実装して」

応答: 「ユーザー管理機能について、以下のどちらを想定されていますか？

A. **ユーザーの登録・編集・削除（CRUD）**: 基本的なユーザー管理機能
B. **ロールベースのアクセス制御（RBAC）**: 権限管理機能
C. **両方**: CRUD + RBAC
D. **その他**

推奨: **C（両方）**
一般的にユーザー管理機能には両方が含まれることが多いため。」
```

悪い例:

```text
ユーザー: 「ユーザー管理機能を実装して」

応答: 「承知しました。ユーザー管理機能を実装します。」
（曖昧な状態で実装を進めてしまう）
```

### 不明確な要件への対応

以下のプロセスで対応する:

1. **曖昧さを検出**: 要件や仕様に不明確な部分がないか確認する
2. **質問を作成**: 不明点を明確にするための質問を作成する
3. **選択肢を提示**: 想定される選択肢を提示し、ユーザーが選びやすくする
4. **確認を得る**: ユーザーからの回答を得て、要件を明確化する
5. **作業を開始**: 明確化された要件に基づいて作業を開始する

## 矛盾を無視しない

### 矛盾検出の原則

ドキュメント間、仕様間、実装間の矛盾を発見した場合、即座に報告し、解決方法をユーザーに確認する。

### 矛盾を放置する影響

矛盾を放置すると、後続の開発に悪影響を及ぼし、問題が拡大する。

### 矛盾発見時の対応

矛盾を発見した時点でユーザーに確認を求める。

### 矛盾の検出

以下の場合は矛盾があると判断する:

- ドキュメント間で記述が異なる
- 仕様と実装が一致しない
- 要件定義と設計書の内容が矛盾する
- 複数の制約条件が同時に満たせない
- 前提条件と実装方針が矛盾する

良い例:

```text
「要件定義書では『ユーザー登録時にメール認証を必須とする』と記載されていますが、
設計書では『メール認証はオプション』と記載されています。
どちらが正しいか確認させてください。

A. **メール認証を必須**: 要件定義書の記述が正しい
B. **メール認証はオプション**: 設計書の記述が正しい
C. **その他**

推奨: **A（メール認証を必須）**
セキュリティの観点から、メール認証を必須とする方が安全なため。」
```

悪い例:

```text
「要件定義書ではメール認証が必須と記載されていますが、設計書ではオプションと記載されています。
設計書の方が新しいので、オプションとして実装します。」
（矛盾を発見したが、確認せずに進めてしまう）
```

### 矛盾への対応

以下のプロセスで対応する:

1. **矛盾を検出**: ドキュメント、仕様、実装間の矛盾を発見する
2. **矛盾を報告**: どこに矛盾があるかを明確に報告する
3. **選択肢を提示**: 矛盾を解決するための選択肢を提示する
4. **確認を得る**: ユーザーからの回答を得て、矛盾を解決する
5. **作業を継続**: 矛盾を解決した後、作業を継続する

## 推察による回答の禁