この記事は MoneyForward Advent Calendar 2018の16日目の記事です。

あれ？これって提供価値なんだっけ？全然わからない。そもそも提供価値あるの？

プロジェクトの途中から参加すると、こういう事はよくあると思います。

提供価値が理解できてないだけならいいんですが、本当に提供価値なかったら、プロダクトで何やっても上手くいかず、エンジニアやディレクターなどの開発から営業、さらにはそのプロダクトを使うユーザーなど、そのプロダクトに関わる全ての人が不幸になってしまいます。

この提供価値が無いまま進んでしまい、あとあと提供価値が無い（薄い）事に気づいても、根底にある提供価値が間違っていると、UIではどうにもできません。
かといって、提供価値つくるところからやり直しましょうとなった場合、そのコストは誰が出すのでしょう？さらに、上流工程になればなるほど、後戻りできなくなります。

10しか提供価値が無い場合、どんなに優れたUIデザイナーがデザインしてもMAXの10までしか価値を提供できません。100の提供価値があれば、優れたUIデザイナーはMAXの100まで提供できるかもしれません。同じUIデザイナーがデザインしても、提供できる価値に差が出ます。

できるだけ提供価値を高めるために、新規プロダクトをつくる時は上流からUXデザイナーが関わり提供価値を考えたほうがいいと思います。

その上で

最初からあった方がいい程度の価値が薄い機能をプロダクトに詰め込まない
基本的に機能を追加するより機能を削る方が難しいです。一回入れてしまった機能は削れなくなる場合もあります。それはいずれ負債となり本来提供したい価値が提供できなくなる場合もあります。

MVPを集中して磨く
早く安定した価値を提供できるようにしないといけないので、本来はあった方がいい程度の価値の薄い機能の開発に時間を費やすべきではありません。機能はMVPに関わるもののみに集中して開発したほうがいいと思います。

とはいえ、提供価値が無い（薄い）ままリリースしないといけない場合もあります。
そんな時は下記のようなことを留意しています。

・安定した価値が提供できるまで、装飾的なデザインは最低限に抑える
・安定した価値が提供できるまで、UIの細部にまで時間をかけない
・極力UIをシンプルにすることで改修しやすくする
・OSのガイドラインに沿うことで属人化したUIにしない
・現実形と理想形（提供価値がある状態）を分けて理想形を見据えた現実形をつくる

色々な状況や、やり方があるので一概に言えませんが。

機能が多いほうが価値があるという考えは企画段階ではよくあると思いますが、実際使うユーザーは自分が使う機能のみがあれば十分で、使わない機能が多ければ多いほど、使いにくくなってしまいます。さらに、使う機能がただついているだけでは不十分で、処理の速さや、より自分にあった情報が提供されるかなどの精度の高さが求められます。本来は機能の数を価値と捉えるのでなく、機能を提供する事でユーザーが得られる結果（状態）を価値と捉えたほうが感覚としては自然かなと思います。