フィーチャー(Feature)は、製品やサービスが備える個別の特徴や機能です。
顧客の要求を満たすための、具体的な解決手段として考えられます。
防水の筐体、自動保存、取り外せる電池などが例になります。

フィーチャーを説明するときは、顧客が得る便益と区別すると、何を確かめるべきかが明確になります。
自動保存は製品側の仕組みであり、作業内容を失いにくくすることが顧客にとっての便益です。
フィーチャーを実装できても、その便益が実際に得られるかは別に確認する必要があります。

要求から複数の手段を考える

仮に、現場で使う端末について「長い作業の途中で電池切れになる」という問題があるとします。
電池の容量を増やす、電池を交換できるようにする、消費電力を下げるなど、異なるフィーチャーが候補になります。

どれも、作業を中断せずに続けたいという要求へ対応する案です。
ただし、重さ、充電の手間、持ち歩く部品、費用への影響は異なります。
顧客が欲しいと述べた一つの機能だけに固定せず、利用状況と制約を調べて比較します。

製品の説明でも、機能の一覧と、顧客が目的を達成する流れをつなぎます。
「交換式電池を搭載」という特徴だけでは、交換時にデータを失わないか、どの程度の作業を続けられるかまでは伝わりません。

完成と価値を別々に確認する

開発では、フィーチャーが満たす動作や条件を明確にします。
自動保存なら、保存のタイミング、対象となる情報、通信が切れた場合、以前の内容へ戻す方法などを決めます。
名称だけで認識を合わせると、担当者が想定する動作に違いが出ます。

一方、仕様どおりに動くことだけでは、顧客に役立つとは限りません。
保存されたか分からず何度も操作する、復旧方法が分からないといった問題は、使ってもらって初めて見つかる場合があります。
技術上の確認と、利用者が得る結果の確認を合わせます。

追加する費用を見積もる

フィーチャーには、実装後も説明、試験、保守、問い合わせ対応の負担が生じます。
既存の機能と組み合わせたときの動作も検討が必要です。
数を増やすことだけを、製品の充実度の指標にはしません。

フィーチャークリープを防ぐには、どの要求へ応える追加なのか、既存の手段では何が足りないのかを明らかにします。
機能を抽象的な働きとして整理すると、同じ目的へ対応するフィーチャーの重複も検討しやすくなります。

参考資料