逆に、コストを気にしすぎて高機能を犠牲にしてしまうと、差別化ができない中途半端な“帯に短し襷 に長し”という製品ができてしまうことになります。帯は帯としてしっかりした長さに、襷は襷として十分な長さにして、それぞれを開発すべきです。そのための「要件ばらし」です。

　ここまで説明してきたように、ユーザー側の視点で製品を「因数分解」し、プラットフォームとオプションに分けることができれば、限られた機能だけを求めるローエンドのユーザーを充足させながら、「もっと」を期待するハイエンドのユーザーに訴求することができるようになるのです。

[画像のクリックで拡大表示]

　ところが、これまで「もっと」ばかりで多機能化・高性能化のみを追求してきた開発チームにとっては、どこまでをプラットフォームの要件にするべきか難しい判断が迫られます。いろいろな意見を聞けば聞くほど、要件は膨らみ、“メタボ”に近づきます。決め切れず「間を取った」判断をすると魅力が低い“帯に短し襷に長し”になってしまいます。「要件ばらし」によってユーザー視点で製品を見ることができたら、どのように判断するのでしょう。次回はそれについて解説したいと思います。

※　本連載に関連するプロセス改革施策にご興味のある方はこちらも合わせてご覧ください。