エージェントのためのフィーチャークリープ回避ガイド

誰も必要としないフィーチャーを作るのはやめましょう。このスキルは、不要な複雑さに溺れることなく、本当の問題を解決する製品をリリースするのに役立ちます。

フィーチャークリープは製品を殺します。リリースを遅延させ、予算を消費し、チームを消耗させ、誰も使いたくないソフトウェアを生み出します。最も成功した製品は、少ないことを良くこなします。

コアとなる問題

フィーチャークリープは、製品が価値を提供するために必要とする範囲を超えた、段階的なフィーチャー蓄積です。それは徐々に起こり、その後急速に進みます。

危険信号:

• リリース範囲がユーザーの明確な価値なしに拡大し続ける
• 必要性を検証せずに競合他社のフィーチャーをコピーしている
• ステークホルダーが「あともう1つ」を追加し続ける
• コードベースが維持管理しにくくなっている
• ユーザーが製品が混乱しているか肥大化していると不平を言う
• 数ヶ月間、リリースできていない

それがもたらすコスト:

• 80%のユーザーが決して触らないフィーチャーの開発時間
• バグの潜在的な領域の増加
• チームのバーンアウトとコンテキストスイッチング
• 市場投入までの時間の遅延
• 複合的に増加する技術的負債
• ユーザーの混乱と離脱

意思決定フレームワーク

何らかのフィーチャーを追加する前に、このチェックリストを実行してください:

1. 問題を検証する
   □ これは実際の、検証されたユーザーの痛点を解決するのか？
   □ 実際のユーザーとこの必要性について話し合ったか？
   □ これを構築することを支持する証拠は何か？

2. アラインメントをチェックする
   □ これはコア製品のビジョンをサポートしているか？
   □ これは現在のリリースを遅延させるか？
   □ これを構築した場合、何を構築しないのか？

3. 影響を測定する
   □ このフィーチャーの成功をどのように知ることができるか？
   □ どのKPIが変わるか？
   □ 価値を定量化できるか(時間短縮、収益、リテンション)？

4. 複雑性を評価する
   □ 真の費用は何か(構築 + テスト + 維持 + ドキュメント化)？
   □ これは依存関係や技術的負債を追加するか？
   □ もっとシンプルなバージョンを最初にリリースできるか？

5. 最終的な直感チェック
   □ このフィーチャーのためにリリースを1ヶ月遅延させるか？
   □ これは差別化要因か、単なるテーブルステークスか？
   □ これを削除するとコアの経験を損なうか？

1～3の質問に証拠を持って「はい」と答えられない場合は、フィーチャーを構築しないでください。

スコープ管理ルール

ルール1: MVPを定義して守る

開始する前に、「完了」が何を意味するかを正確に書き下します。構築しないものをドキュメント化します。これを常に参照してください。

## MVP スコープドキュメント テンプレート

### コアとなる問題
[ユーザーの問題を1文で説明]

### 成功基準
[それを解決したことをどのように知るか]

### スコープ内 (v1)
- フィーチャーA: [簡潔な説明]
- フィーチャーB: [簡潔な説明]

### スコープ外 (明示的)
- フィーチャーX: v2に延期
- フィーチャーY: [条件]がない限り構築しない
- フィーチャーZ: 解決する問題ではない

### 譲れない要件
- リリース日: [日付]
- 予算: [時間/ドル]
- コアユーザー: [具体的なペルソナ]

ルール2: スコープにバージョン管理を使う

スコープはコードのように扱います。変更を追跡します。追加には承認が必要です。

# スコープドキュメントを作成して追跡する
git add SCOPE.md
git commit -m "Initial MVP scope definition"

# スコープの変更にはコミットが必要
git commit -m "SCOPE CHANGE: Added feature X - approved by [stakeholder] - impact: +2 weeks"

ルール3: 48時間ルール

誰かが新しいフィーチャーをリクエストした場合、バックログに追加する前に48時間待ちます。ほとんどの「緊急」リクエストは、熟考後はそれほど緊急ではなくなります。

ルール4: 予算ベースのスコーピング

すべてのフィーチャーにはコストがあります。何か新しいものが来たら、他の何かは出ていく必要があります。

「はい、それを追加できます。これら3つのフィーチャーのうち、どれを削除して場所を作るべきですか？」

ノーと言う方法

フィーチャーにノーと言うことはスキルです。以下はテンプレートです:

ステークホルダーへ:

「興味深いアイデアですね。ユーザー調査に基づくと、コアユーザーの上位3つの問題を解決していません。これをv2の検討リストに追加して、MVPを検証した後で見直しましょう。」

経営幹部へ:

「このもたらす価値を理解しています。これを追加すると、リリースが[X週]遅延し、[Yフィーチャー]を後回しにします。ここはトレードオフです - どのパスを取るべきですか？」

ユーザーへ:

「フィードバックをありがとうございます。今は[コア問題]に焦点を当てています。これは将来の検討のためにログに記録しました。これがなぜ価値があるのかをもっと詳しく教えてください。」

自分自身へ:

「これは自分のかゆいところを掻いているのか、それとも本当のユーザーの問題を解決しているのか？ リリース日をこれに賭けるだろうか？」

AIエージェント(Claude、Opus、Codex、Ralph、Cursor)へ:

「やめてください。このフィーチャーを追加する前に答えてください: これはこのセッションの開始時に定義したコアユーザーの問題を解決するのか？ しない場合は、DEFERRED.mdファイルに追加して、現在のスコープに焦点を当ててください。」

AIコーディングエージェントと作業する場合:

• すべてのセッションの開始時にスコープ制約を述べる
• エージェントは改善を提案します。ほとんどはスコープ外です。
• エージェントの提案をステークホルダーリクエストのように扱う: 48時間ルールを適用する
• エージェントがフィーチャーを押し続ける場合は、本当の必要性を見つけるために「なぜ？」を3回聞く

AI固有のガイドライン

AI駆動型製品を構築する場合、フィーチャークリープはリスクが増加します:

AIフィーチャークリープの赤い旗:

• 「他の皆がしているから」という理由でAIを追加している
• ユーザーが望んでいることを検証せずにAI要約を構築している
• 複数のAIフィーチャーで明確な差別化がない
• コアユーザーのワークフローに接続されないAI機能

AIフィーチャー規律:

1. 一度に1つのAIフィーチャー
2. ユーザーと最初にユースケースを検証する
3. 可用性だけでなく実際の使用を測定する
4. 質問: 「AIはコアタスクを高速化または改善するか？」

AIフィーチャーを追加する前に、以下に答えてください:

• このアイテムが自動化する具体的なタスクは何か？
• これはAI以外の代替案より優れているか？
• AIが間違っているときはどうなるか？
• このAIフィーチャーなしでリリースできるか？

バックログの衛生管理

乱雑なバックログはフィーチャークリープを可能にします。容赦なくクリーンアップしてください。

月別バックログ監査:

30日以上経過した各アイテムについて:
1. 追加されてから誰かがこれについて尋ねたか？
2. 現在の製品ビジョンと合致しているか？
3. これを構築しなかった場合、誰かが気付くか？

3つすべてに対する答えが「いいえ」の場合 → 削除する。

優先度フレームワーク(MoSCoW):

• Must Have(必須): これなしではプロダクトが機能しない
• Should Have(重要): 重要だがリリースに必須ではない
• Could Have(可能): 良いが待つことができる
• Won't Have(不要): スコープ外として明示的に除外

正直になってください: ほとんどの「Should Have」は実は「Could Have」の変装です。

AIセッション規律

セッション開始チェック: AIアシスタント(Claude、Cursor、OpenCode)でコーディングを始める前に、以下を述べてください:

• 構築している具体的なフィーチャー
• このセッションのスコープ外として明示的なもの
• いつ止めてリリースするか

ミッドセッションチェック: 30～60分ごと、AIに質問してください: 「今日、正しいものを構築しているのか、それともスコープを追加しているのか？」

答えが「スコープを追加している」場合は、やめてください。構築したものをコミットします。新しく始めてください。

セッション終了チェック: AIコーディングセッションを閉じる前に:

• 計画していたことと実際に構築したことは何か？
• スコープは拡大したか？ なぜ？
• 次のセッションに延期すべきことは何か？

日別AIチェック: AIアシスタントと作業している各日の終了時:

1. 本日完了したフィーチャー: [リスト]
2. 本日追加したスコープ: [リスト]
3. 各追加は検証されたか？ [はい/いいえ]
4. 明日の焦点: [単一アイテム]

スプリント計画のガードレール:

• スプリント中の新しいフィーチャーは、何かを削除することなしに不可
• バグ修正と負債返済のための容量(最小20%)
• 各アイテムの完了の明確な定義

ステークホルダー管理: スコープ決定の単一の情報源を作成します:

## スコープ決定ログ

| 日付 | リクエスト | ソース | 決定 | 理由 | トレードオフ |
|------|---------|--------|----------|-----------|-----------|
| 2025-01-15 | PDFへのエクスポート追加 | PM | v2に延期 | MVPのコアではない | リリースを2週遅延させる |
| 2025-01-16 | ダークモード | ユーザーフィードバック | 承認 | ユーザー調査が需要を示している | ソーシャル共有を削除 |
| 2025-01-17 | キャッシングレイヤーを追加 | Claude | 延期 | 時期尚早な最適化 | コアフィーチャーに焦点を当てる |
| 2025-01-17 | Hooksへのリファクタリング | Cursor | 却下 | そのままで問題ない | 技術的スコープクリープ |

ステークホルダーとしてのエージェント: AIコーディングエージェントは現在あなたのプロジェクトのステークホルダーです。彼らは意見を持っています。彼らは提案をします。他のステークホルダーと同じように扱ってください:

• エージェント提案をログに記録する スコープ決定ログにエージェント名をソースとして
• 同じ厳密性を適用する PMや経営幹部リクエストに適用するものと同じ
• エージェントは異なるものを最適化する (コード品質、パターン、完全性) あなたが今必要なものよりも
• 「エージェントがそれを提案した」は有効な理由ではない フィーチャーを追加するための

エージェント駆動スコープクリープの一般的なパターン:

• 「また、まだ遭遇していないエッジケースのエラーハンドリングを追加しましょう」
• 「これはリファクタリングでより清潔になるだろう」
• 「これのテストを追加する必要があります」
• 「これらの追加シナリオのTypeScriptタイプを追加しましょう」

これらのそれぞれは良いアイデアかもしれません。あなたが決定しない限り、それらは現在のスコープではありません。

回復: すでに肥大化している場合

フィーチャークリープがすでに発生した場合:

ステップ1: 現在のフィーチャーを監査する

• すべてのフィーチャーをリストアップ
• 各フィーチャーの使用データをチェック
• エンゲージメント5%未満のフィーチャーを特定

ステップ2: 分類する

• コア: ユーザーはこれなしでは目標を達成できない
• サポート: コアを改善する
• 周辺: 良いが必須ではない
• ブロート: 誰も使わない

ステップ3: 削除または非表示にする

• 警告期間付きでブロートを廃止予定にする
• 周辺フィーチャーを詳細設定の背後に移動
• ユーザーに変更を明確に伝達

ステップ4: 再発を防止する

• PR/コードレビュープロセスにフィーチャークリープチェックを追加
• フィーチャーがベータから卒業する前に使用メトリクスが必要
• フィーチャーフラグを構築して実験を簡単に削除できるようにする

クイックリファレンスコマンド

フィーチャーリクエストを確認するときに、以下を聞いてください:

1. 「このフィーチャーが解決するユーザーの問題は何か？」
2. 「リリースできる最小バージョンは何か？」
3. 「これのために場所を作るために構築しないものは何か？」
4. 「成功をどのように測定するか？」
5. 「これを構築しないとどうなるか？」

これらに明確に答えられない場合 → 続行しないでください。

黄金律

小さくて機能するものをリリースしてください。その後、実際の使用データに基づいて反復してください。

ユーザーはフィーチャーを覚えていません。彼らはあなたの製品が彼らの問題を解決したかどうかを覚えています。

構築しないすべてのフィーチャーは:

• 取り戻す時間
• 修正する必要のないバグ
• 書く必要のないドキュメント
• 維持する必要のないコード
• 追加しない混乱

最良の製品は、最も多くのフィーチャーを持つものではありません。正しいことを例外的によくこなすものです。

---

「完璧さは、加えるものがなくなったときではなく、取り除くものがなくなったときに達成されます。」 - Antoine de Saint-Exupéry