フィーチャークリープ

フィーチャークリープ（Feature Creep）は、開発の途中で機能が追加され続け、当初の想定より製品やプロジェクトの範囲と複雑さが膨らむことです。
個々の追加は小さく見えても、積み重なると開発期間、費用、使いやすさ、保守へ影響します。

追加や変更そのものが問題なのではありません。
調査や利用から重要な要求が分かり、計画を変える必要もあります。
問題は、追加の価値や影響を十分に判断せず、依頼を受けるたびに実装範囲へ入れてしまうことです。

小さな追加の影響を見積もる

仮に、予約サービスの初回提供を準備しているとします。
予約の変更に加え、複数人の予約、割引、会員ランク、外部カレンダーとの連携を少しずつ追加するとします。

一つずつの画面が増えるだけではありません。
人数変更と割引の関係、権限、取り消し、通知など、機能間の組み合わせも増えます。
試験や説明、問い合わせ対応の負担まで含めると、追加したコードの量だけでは影響を見積もれません。

さらに、利用者が必要な操作を見つけにくくなる場合があります。
開発側にとって小さな追加でも、利用者には判断する項目や学ぶ手順の増加になります。

追加の提案を受けたら、誰が、どの状況で、何に困っているかを確認します。
「競合にもある」「一社から要望があった」という事実だけでは、対象顧客全体に必要かは分かりません。
既存機能、運用の変更、より小さな対応で解決できるかも検討します。

予約の例なら、特定の顧客が複数人をまとめて申し込む必要があるのか、社内担当者の入力を減らしたいのかで、対応は変わります。
提案された画面をそのまま作る前に、目的と制約を整理します。

採用する変更には、期待する結果、追加の作業、検証方法、保守への影響を示します。
提供時期や人員を維持するなら、代わりに何を後へ回すかも判断します。
変更を承認した後で、元の範囲と日程も同時に守るよう求めると、負担が見えなくなります。

製品定義やロードマップには、対象とする顧客と目的を残します。
依頼の採否を、その目的に照らして説明できる状態にします。
後で提供する候補と、現在の開発で実装すると決めた機能は、区別して管理することが重要です。