
192
8 章 既存顧客がいる場合の顧客開発
るのはせいぜい数千人なので、その数に対応できる性能があれば十分です。
顧客が購入しないかもしれない製品に過剰な機能を持たせるのはエンジニア
リングリソースの無駄遣いです。顧客需要があると検証したときに、製品の
性能を高めて、顧客基盤全体がアクセスできるようにすれば良いのです。
反論:機能が部分的にしか使えないなら顧客を満足させることはできない。
答え:MVP をもって開発完了というわけではありません。最小限の時間の
投資によって最大の価値を提供するにはどうすれば良いかという観点で考え
ています。「顧客に多く使われている機能はないか?」「他の機能が一週間に
1 回以下しか使われていない一方、毎日使われている機能はあるか?」。最
優先の機能から着手することで、学習とアイデアの検証を迅速に行なえま
す。顧客が不足している機能の実装を要求してきたら、その要求を以降に開
発する機能の優先順位付けに使えば良いのです。
反論:設計に一貫性を欠くことは許容できない。
答え:設計の一貫性を維持するのは、逆に高いリスクを生じさせます。製品
提供に時間がかかったり、使用感を損ないうる上に、お金もかかる製品全体
の再設計につながったりするからです。新機能よりも設計変更を優先させる
のは困難でもあります。小さな設計変更が、顧客の製品使用に役立つことを
はっきりと示している場合は、製品の他の部分の設計改善を主張しやすくな
ります。
わたしの経験では、反論に対してこのように答えていくことは、社内での