受託のfeatureとサービスのfeatureは違う

アジャイル開発の文脈で語られるfeature。

機能と直訳するのは、多少厄介です。それはどんな機能ですか?と聞いてしまっては「投稿機能」というような答えになってしまうからです。

featureは主語と述語がはっきりとして、具体的な一文で書くべきです。

投稿機能ではなく、「ユーザがブログに対してコメントを投稿できること」のように。

作りたいものの、特徴を端的に書くため、featureを特徴と訳している人もいるようです。

受託開発の場合は顧客の要求をそのまま、一文に落とし込めば良いと思います。

そのときに顧客の言葉を使うと価値の共有が測りやすいです。

featureは誰にとってどんな価値があるのかを意識しなければいけません。

顧客にとってコメントを投稿するということが価値があることが、明確であれば問題ありません。

顧客の言葉に対するfeatureが完成されれば、その実装は受け入れられます。

ただ、サービス開発の場合は違います。

そもそもユーザがコメントできることに価値があるかがわかりません。

コメント機能を実装して、それが使われるかどうかまでを意識したfeature設定が必要になります。

サービス開発では、無駄なfeatureをなるべく削ぎ落として、純粋に価値があるものをユーザに届けるべきなのです。

この場合、コメント機能を実装して、ユーザの滞在時間を上げたかったり、コメント機能で通知を行いコメントのあったユーザに承認欲求を与えるということに価値があるはずです。

そうすると、featureはもう少し抽象度が上がる可能性があります。

「ユーザが他のユーザとコメント欄で交流できるようにする」といったところでしょうか。

もちろん受託開発の場合でも、サービス開発と同じように顧客に、そのfeatureの目的や価値を確認することは必要です。

しかし、あまりにも抽象度の高いfeatureを作ってしまうと納品ができません。

この辺りの落とし所は非常に難しく、トレーニングを積んで獲得すべきスキルのように思えます。

サービスの適性や機能の優先度を踏まえ、featureの受け入れ後もその機能の評価をし続けることが正攻法でしょう。