アジャイル開発の文脈で語られるfeature。
機能と直訳するのは、多少厄介です。それはどんな機能ですか？と聞いてしまっては「投稿機能」というような答えになってしまうからです。
featureは主語と述語がはっきりとして、具体的な一文で書くべきです。
投稿機能ではなく、「ユーザがブログに対してコメントを投稿できること」のように。
作りたいものの、特徴を端的に書くため、featureを特徴と訳している人もいるようです。
受託開発の場合は顧客の要求をそのまま、一文に落とし込めば良いと思います。
そのときに顧客の言葉を使うと価値の共有が測りやすいです。
featureは誰にとってどんな価値があるのかを意識しなければいけません。
顧客にとってコメントを投稿するということが価値があることが、明確であれば問題ありません。
顧客の言葉に対するfeatureが完成されれば、その実装は受け入れられます。
ただ、サービス開発の場合は違います。
そもそもユーザがコメントできることに価値があるかがわかりません。
コメント機能を実装して、それが使われるかどうかまでを意識したfeature設定が必要になります。
サービス開発では、無駄なfeatureをなるべく削ぎ落として、純粋に価値があるものをユーザに届けるべきなのです。
この場合、コメント機能を実装して、ユーザの滞在時間を上げたかったり、コメント機能で通知を行いコメントのあったユーザに承認欲求を与えるということに価値があるはずです。
そうすると、featureはもう少し抽象度が上がる可能性があります。
「ユーザが他のユーザとコメント欄で交流できるようにする」といったところでしょうか。
もちろん受託開発の場合でも、サービス開発と同じように顧客に、そのfeatureの目的や価値を確認することは必要です。
しかし、あまりにも抽象度の高いfeatureを作ってしまうと納品ができません。
この辺りの落とし所は非常に難しく、トレーニングを積んで獲得すべきスキルのように思えます。
サービスの適性や機能の優先度を踏まえ、featureの受け入れ後もその機能の評価をし続けることが正攻法でしょう。