前回の記事では、なぜFigmaがよかったのか？を書いてきました。
前回の記事はこちら：プロジェクトに良い効果をもたらした、Figmaが持つ世界観
今回は、モックからMVP作成までに何が起きたのか？を書いていきたいと思います。
MVPとは？
MVPは「Minimum Viable Product（ミニマムバイアブルプロダクト）」の略称で、最小限の機能を持つ初期バージョンのプロダクトのことです。
簡単な言葉に置き換えると、MVPの主な目的は、「あまり工数をかけず、小さいゴールを設定して、フォードバックを得られるところまでより早く走り抜ける」といった感じでしょうか。
最初から大きなものを作ろうとすると、開発に時間がかかってしまい、フィードバックを得ても起動修正が難しい、既に多くの資金を投入してしまい損切りが出来ない、といった事態を引き起こす可能性があります。
そのため、MVPを利用した開発方法はアジャイル開発と相互に補完的な役割を果たしながら利用されることがあります。
つまり、MVPのメリットをまとめると、
- 開発にかかるコストと時間を節約できる
- より早くフィードバックを得られる
- 失敗しても最小限の損失に抑えられる
になります。
なぜモックからMVPに？
本来の開発方法であれば、MVPの要件定義をしてからモックの作成に移ることが多いと思います。
このプロジェクトで先にモックを作成しなければならなかった理由は初回の記事で記述した通りですが、実はモックの作成は2段階に別れていました。
最初に作成したモックは、考えうる全ての機能が画面内に収まった、いわば「全部載せ」の状態のものでした。ウォーターフォール型の開発であれば、もしかしたら最初からこの全部載せの状態のものを作ろうとしたかもしれません。
ですが、あらゆる機能が最初から載っているシステムは、一見便利に見えますが、初めて使う人にとってはどこに何があるか分からず使いづらいものになりがちです。（UIで解決すべきといわれればそうなのですが、なかなかそううまくいかないもので、やはりUXの観点からどんな体験を提供するか、を考えなければ、本質的な解決には至らなそうです）
今回も、最初から考えうる全部の機能を入れてしまうとユーザーにツールが浸透しなくなるのでは、という懸念から、MVPの開発に舵きりを行ったと記憶しています。
つまり、流れを整理すると
全部入りのモックでユーザーヒアリング
↓
全部入りを最初から使ってもらうのは難しいとフィードバック
↓
MVPの作成へシフト
↓
全部入りの機能一覧からMVPを定義
↓
MVPに向けた2ndモックを作成
↓
2ndモックで再度ユーザーヒアリング
↓
MVP開発へ
という感じでした。
MVPを定義する
今回は、まずアナログで行われている作業をデジタル化したい、というのが大前提にあったため、作業をデジタルに置き換える部分だけをMVPとして開発することにしました。
「全部入りの機能が先に想定されていた」「そもそもデジタル化がされてない状態だった」からこそ、じゃあ最小限の機能ってなんだろう、と考えるのはそこまで難しくなかったと思います。
ただ、限定的にデジタル化を進めていた部署もあったため、そことどう連携するのか？といった課題などは全て積み残しになっていました。
まずMVPを作ることを進めるのは必要なことだったと思いますが、どのタイミングで考えるべき課題か、解決するまで立ち止まらなければならないものか、といったことを一旦無視して、いけいけどんどんで作成してしまって後から問題になってしまった…というのは反省すべき点だったと思います。
次回は、このプロジェクトでの一番の難関「アナログがベースになっているものをデジタルに切り替える時に起きること」をテーマに書きたいと思います。
