【ITニュース解説】Before building an MVP, give one workflow a clear purpose

システムエンジニアとして新たなソフトウェア開発に携わる際、まず最初にぶつかる壁の一つに「何を作るべきか」という問題がある。多くの機能アイデアが浮かび、すべてを盛り込みたくなってしまうものだが、それでは開発が膨大になり、本当にユーザーが必要とするものから遠ざかる可能性がある。この課題を解決するために「MVP（Minimum Viable Product、実用最小限の製品）」という考え方がある。これは、最小限の機能でユーザーに価値を提供する製品を素早く市場に出し、フィードバックを得ながら改善していくアプローチだ。

しかし、MVPを開発する前にも、さらに重要なステップがある。それは、たった一つの「ワークフロー」、つまり一連の作業の流れに、明確な目的を与えることだ。単に「こんな機能があるソフト」というリストを作るのではなく、「このソフトを使って、誰が、何を達成できるのか」という具体的な目的をはっきりさせる必要がある。

この目的を明確にするための効果的な方法として、次の一文を完成させるという考え方がある。

「[状況が発生したとき]、[人物]は[タスクを完了する]必要がある。そうすれば[有用な結果に到達できる]。」

これは一見シンプルだが、この一文を具体的に埋めることで、開発すべき機能の輪郭が驚くほど明確になる。例えば、架空の地域の修理店を考えてみよう。「顧客が修理について尋ねるとき、カウンターの担当者は現在の状況を見つける必要がある。そうすれば有用な回答ができる。」この一文が、最初のMVPで解決すべき核となる課題を示している。

この一文を深掘りすると、ソフトウェア開発に関する五つの重要な問いが浮かび上がる。

一つ目は、「誰がタスクを完了する必要があるか」という問いだ。「事業全体」という漠然とした答えではなく、具体的な担当者を特定することが重要だ。上記の例では、「カウンターの担当者」が迅速な修理状況の確認を必要とする一方で、「技術者」はより詳細な修理の記録を残す必要があるかもしれない。同じ修理に関する情報でも、見る人によって必要な情報の種類や深さが異なるため、それぞれのユーザーにとって最適な画面や機能を設計する必要がある。

二つ目は、「何がタスクを開始させるか」という問いだ。タスクが始まるきっかけ、つまり「トリガー」を具体的に考えることで、開発する機能の優先順位や操作の流れが見えてくる。顧客からの電話問い合わせ、来店した顧客からの直接の質問、あるいは担当者自身による日々の作業確認など、トリガーによって必要な操作は大きく変わる。例えば、電話での問い合わせなら、素早く顧客や修理の記録を開ける機能が重要になるだろう。一方で、日々の作業確認であれば、未完了の修理リストを一覧で表示する機能が役立つかもしれない。ナビゲーションや画面設計に入る前に、まずトリガーを明確にすることが肝心だ。

三つ目は、「何が有用な結果とみなされるか」という問いだ。「ダッシュボードを表示する」といったインターフェース（画面）に関する説明ではなく、「修理の状況を見つけて、顧客に次に何が起こるかを説明できる」といった、具体的な達成目標を定義する必要がある。この「有用な結果」が達成されたかどうかを確認するための、小さな「受け入れテスト」をイメージすると良い。修理店の例で言えば、架空の修理記録を一つ選んで、その状況を読み取り、顧客に次のステップを説明できるかどうか、というテストが考えられる。

四つ目は、「タスクはどこで発生するか」という問いだ。タスクが行われる場所や使用されるデバイスによって、ソフトウェアに求められる要件や制約は大きく異なる。カウンターに設置されたデスクトップPCと、作業場の横にあるスマートフォンでは、画面の大きさ、入力方法、ネットワーク環境などが違う。もし同じワークフローを異なるデバイスで共有する場合、情報がどのように同期され、ユーザーは同期中にどのような情報を見るべきかなど、明示的な設計が必要になる。どのプラットフォームに対応するかを選択することは、どの状況をサポートするかを選択することに等しい。

五つ目は、「何の情報が実際に必要か」という問いだ。まずは、そのタスクを完了するために最低限必要な情報に絞り込むことが重要だ。修理の例で言えば、修理の参照番号、現在のステータス、そして次のステップが、最初に必要な情報だろう。余計な顧客の詳細情報や過去の履歴などは、後から追加を検討するべきだ。それぞれの情報（フィールド）について、その目的、誰がアクセスできるべきか、そして将来的に不要になった場合にいつ削除すべきか、といったことを明確にすることで、情報設計の無駄を省き、システムをシンプルに保つことができる。

これらの問いに答えることで、最初のMVPの「境界線」を明確に引くことができる。修理店の例では、最初のバージョンは「修理状況の検索」と「その状況の更新」という、核となる機能に絞り込める。在庫の予測機能、顧客のポイントシステム、自動マーケティング機能なども将来的には有用かもしれないが、それらは今回定義した「一文」から直接導かれるものではない。そういった将来的なアイデアは別のリストにまとめ、今は核となるワークフローに集中する。

そして、この限定されたワークフローを、実際のデータに近いサンプルデータを使ってテストし、ユーザーがどこで戸惑うか、どこで立ち止まるかを観察することが重要だ。このプロセスを通じて、当初必要だと思われていた機能の中にも、核となるタスクに貢献しないため、最初のバージョンからは削除すべきものが見つかるだろう。明確な目的を持ち、そこに直結しない機能は思い切って削ぎ落とすことで、本当に価値のあるMVPを効率的に開発できるのだ。