製品定義

開発の途中で要求が増え続ける場合、誰へ何を提供する製品なのかが共有されていないことがあります。
製品定義（Product definition）は、対象顧客、解く課題、提供する便益、競合との位置づけ、価格や要求条件などから、作る製品の範囲を明らかにすることです。
製品名と機能の一覧だけでは、選択の基準を示しきれません。

作るものと作らないもの

たとえば、小規模な宿泊施設向けに予約管理を提供するとします。
個人経営の施設か、複数拠点を管理する企業かで、必要な仕事と利用者は変わります。
今回は一施設の予約と変更を扱い、会計処理は既存の方法へ渡す、と範囲を定める方法があります。
対象外の機能を示せば、要望が出た際に、元の目的に照らして判断できます。

便益と実現条件をつなぐ

施設が得たい結果は、画面の数ではなく、転記や重複予約を減らすことかもしれません。
その便益へ必要なデータ、操作、外部との連携を検討します。
価格や導入支援の条件も、顧客が選べる提供かを判断する材料になります。
実現方法を詳しくする前に、なぜその条件が必要かを記録します。

仮説の確かさを示す

製品定義には、確認済みの情報と、まだ調べる必要のある前提が混ざります。
顧客が予約の変更に困っている証拠と、その解決策へ費用を払う証拠は別です。
利用者との対話、試作品、試行などで確かめ、結果から定義を更新します。
文章が具体的になったことを、需要が検証されたことと混同しないようにします。

変更の合意へ使う

新たな顧客や機能を加える場合は、便益、費用、技術、運用への影響を確認します。
誰が範囲の変更を決め、関係者へどう伝えるかを明確にします。
初期の定義を一切変えないことも、要望を無条件に足すことも目的ではありません。
コンセプトステートメントは案の簡潔な説明、製品設計仕様は設計へ必要な条件の具体化に使えます。
範囲が膨らむ問題はフィーチャークリープも参照してください。

参考資料