230 lines
8.7 KiB
Markdown
230 lines
8.7 KiB
Markdown
---
|
||
name: development-principles
|
||
description: 開発における基本原則（曖昧さ禁止、矛盾検出、推察禁止）を定義する。要件定義時、仕様確認時、設計レビュー時、またはユーザーが曖昧な要件、仕様の矛盾、不明点の確認、推測回避に言及した際に使用する。
|
||
---
|
||
|
||
# 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. **作業を継続**: 矛盾を解決した後、作業を継続する
|
||
|
||
## 推察による回答の禁止
|
||
|
||
### 推察禁止の原則
|
||
|
||
ユーザーの意図や要件を推察せず、明示された情報のみに基づいて回答する。ユーザーが明示的に述べていない要件、仕様、または期待される動作を推察して回答・実装しない。過去のやり取りから推測される内容であっても、現在の文脈で明示されていない限り、確認を求める。
|
||
|
||
### 推察による悪影響
|
||
|
||
不正確な情報は誤った意思決定を招き、プロジェクト全体に悪影響を与える。
|
||
|
||
### 不明点への対応方法
|
||
|
||
「わからない」「確認が必要」と明言し、適切な情報源を示す。
|
||
|
||
### 推察が必要な状況の検出
|
||
|
||
以下の場合は推察が必要であると判断する:
|
||
|
||
- ユーザーが明示的に述べていない要件や仕様が必要
|
||
- 過去のやり取りから推測される内容がある
|
||
- 暗黙の前提条件がある可能性がある
|
||
- 類似のケースから推測できる内容がある
|
||
- 一般的な慣習や標準があるが、明示されていない
|
||
|
||
良い例:
|
||
|
||
```text
|
||
ユーザー: 「データベースにユーザー情報を保存して」
|
||
|
||
応答: 「ユーザー情報の保存について、以下の点を確認させてください。
|
||
|
||
1. 保存するユーザー情報の項目はどれですか？
|
||
|
||
A. **基本情報のみ**: 名前、メールアドレス、パスワード
|
||
B. **基本情報 + プロフィール**: 基本情報に加えて、生年月日、住所、電話番号
|
||
C. **その他**
|
||
|
||
推奨: **A（基本情報のみ）**
|
||
最小限の情報から始めて、必要に応じて追加する方が安全なため。」
|
||
```
|
||
|
||
悪い例:
|
||
|
||
```text
|
||
ユーザー: 「データベースにユーザー情報を保存して」
|
||
|
||
応答: 「承知しました。ユーザー情報（名前、メールアドレス、パスワード、生年月日、住所、電話番号）を
|
||
データベースに保存します。」
|
||
（ユーザーが明示していない項目を推察して決定してしまう）
|
||
```
|
||
|
||
### 推察が必要な場合の対応
|
||
|
||
以下のプロセスで対応する:
|
||
|
||
1. **推察が必要な箇所を特定**: ユーザーが明示していない情報を特定する
|
||
2. **質問を作成**: 不明点を明確にするための質問を作成する
|
||
3. **選択肢を提示**: 想定される選択肢を提示し、ユーザーが選びやすくする
|
||
4. **確認を得る**: ユーザーからの回答を得て、情報を明確化する
|
||
5. **作業を開始**: 明確化された情報に基づいて作業を開始する
|
||
|
||
## チェックリスト
|
||
|
||
### 作業開始前
|
||
|
||
- [ ] 仕様や要件が明確に定義されている
|
||
- [ ] 期待される動作が明示されている
|
||
- [ ] 前提条件や制約事項が明確である
|
||
- [ ] 用語の定義が明確である
|
||
- [ ] データ形式や範囲が明示されている
|
||
- [ ] ドキュメント間、仕様間、実装間に矛盾がない
|
||
|
||
### 作業中
|
||
|
||
- [ ] 曖昧な部分を発見した場合、即座に質問している
|
||
- [ ] 矛盾を発見した場合、即座に報告している
|
||
- [ ] 推察が必要な箇所を特定し、確認を求めている
|
||
- [ ] ユーザーの意図や要件を推察せず、明示された情報のみに基づいて作業している
|
||
- [ ] 不明点があれば必ず質問し、明確化してから作業を進めている
|
||
|
||
### 作業完了後
|
||
|
||
- [ ] 実装が仕様や要件と一致している
|
||
- [ ] ドキュメントと実装に矛盾がない
|
||
- [ ] 曖昧な部分が残っていない
|
||
- [ ] すべての不明点が解決されている
|