ソフトウェア開発で大きな費用がかかる問題の多くは、プログラミングの問題ではありません。誰のためのプロダクトなのか、最初のリリースで何が必要なのか、どの既存システムとつなぐのか。こうした判断が下されないまま、あるいは人によって違う前提のまま進んでしまうことが原因です。
ディスカバリーフェーズは、これらの判断を意図的に行うための工程です。本記事では、新規プロダクトの開発や大規模なリニューアルを控えた企業の方に向けて、ディスカバリーの内容、成果物、期間、そして省略・短縮してよいケースを解説します。
ディスカバリーフェーズとは何ですか？
ディスカバリーは、ソフトウェアプロジェクトの最初の工程です。本番のコードを書く前に、発注側と開発チームの少人数で、何を、誰のために、なぜ作るのかを整理します。成果は、プロダクトについての共通理解を文書にしたものと、現実的な開発計画です。
長期の調査プロジェクトでも、営業活動でもありません。良いディスカバリーは短く、実務的で、意思決定で終わります。始める前より未解決の論点が増えて終わるなら、進め方に問題があります。
日本の受託開発やオフショア開発でいう要件定義と重なる部分が多くあります。違いは重点の置き方です。ディスカバリーでは要件を書き出すだけでなく、ユーザー、画面フロー、簡単なプロトタイプを使って、その要件が本当に正しいかを確かめます。
ディスカバリーでは何を行いますか？
具体的な手順はプロダクトによって変わりますが、押さえるべき項目は毎回同じです。それぞれの項目は、議論だけでなく決定で終える必要があります。
- ビジネスの目的：プロダクトで何を変えたいのか、成功をどう測るのか。
- ユーザー：誰が使うのか、何をしたいのか、今どこで困っているのか。
- 画面フロー：会員登録、予約、決済、承認など主要な流れをステップごとに整理します。
- スコープ：最初のリリースに入れるもの、後回しにするもの、対象外とするもの。
- 技術方針：対応プラットフォーム、アーキテクチャ、既存システムとの連携、データとセキュリティの要件。
- リスク：費用やスケジュールに影響しうる不確定要素と、それを早めに減らす方法。
- ロードマップ：最初のリリースから次のフェーズまでの作業の順番。
- 見積もり：推測ではなく、合意したスコープに基づく工数、体制、期間。
最後に何が手に入り、期間はどのくらいですか？
対象が絞られたプロダクトであれば、ディスカバリーの期間はおおよそ1週間から数週間が一般的です。ユーザーが明確な小規模アプリなら短く、複数のユーザー権限、決済、外部連携、機密性の高いデータを扱うプラットフォームなら長くなります。中規模のプロダクトに何か月ものディスカバリーを提案された場合は、各週でどんな決定が得られるのかを確認するとよいでしょう。
最後には、プレゼン資料だけでなく、発注側が保有し、どの開発チームとも使える具体的な成果物が残るべきです。代表的な成果物は次のとおりです。
- 目的、ユーザー、成功指標、制約をまとめた簡潔なプロダクト概要。
- 画面フローと、主要画面のワイヤーフレームまたはクリックできるプロトタイプ。
- 優先順位付きの機能一覧と、明確な初回リリースの範囲。
- 技術スタック、アーキテクチャの概要、連携先、インフラを含む技術方針。
- リスク一覧と、それぞれへの対応方法。
- 段階的なロードマップと、工数・体制・期間の見積もり。
なぜディスカバリーでコストを抑えられるのですか？
変更にかかるコストは、工程が進むほど大きくなります。ワイヤーフレーム上でボタンを動かすのは数分で済みます。しかし、設計、実装、テスト、リリースを終えた決済フローを変えるには数週間かかることもあり、他の機能に影響が出ることも少なくありません。
ディスカバリーがコスト削減につながる理由は、主に4つあります。まず、誰も触れていなかった管理者権限や古いシステムとの連携など、抜けている要件を早く見つけられます。次に、作る前にスコープを絞れます。最初のリリースを明確にすると、当初の要望リストより小さくなることがほとんどです。さらに、見積もりの精度が上がり、予算の話し合いが毎月ではなく一度で済みます。そして、デザイナーとエンジニアが同じ画面フローから始めるため、手戻りが減ります。
目に見えにくい利点もあります。本格的な契約の前に、そのチームの働き方を確認できることです。どんな質問をするのか、意見の違いにどう対応するのか、どれだけわかりやすく文書を書くのか。パートナー選びを低いコストで試す方法にもなります。
ディスカバリーを省略・短縮できるのはどんなときですか？
ディスカバリーは、いつもフルで必要なわけではありません。次の条件の多くに当てはまる場合は、期間を短くするか、最初のスプリントに組み込むことができます。
- コーポレートサイトや単一の社内ツールなど、スコープが小さく明確である。
- 要件、画面フロー、デザインがすでに文書化され、社内で検証済みである。
- 既存の業務を行う自社の社員など、ユーザーがよくわかっている。
- 他システムとの連携がほとんどない。
- 同じチームがすでによく知っているプロダクトに機能を追加する。
ディスカバリーに向けて何を準備すればよいですか？
準備ができていると、ディスカバリーは短くなり、結果の質も上がります。詳細な仕様書は必要ありません。必要なのは、判断できる人と、すでにわかっている情報です。
- スコープと優先順位を決められる意思決定者を1名決めておく。
- ビジネスの目的を1〜2文で書き、その測り方も決めておく。
- 既存システム、Excelなどの管理表、競合の事例、ラフスケッチ、過去の調査など、手元の資料を集める。
- 連携が必要なシステムと、その担当者を洗い出す。
- リリース時期、予算の目安、法令やデータの取り扱いルールなど、動かせない条件を早めに共有する。
- 可能であれば、実際のユーザー数名に短いヒアリングの時間をもらう。
Devnoriはディスカバリーをどのように進めますか？
Devnoriは、インドを拠点に世界中のお客様とリモートで仕事をする、少人数でシニアなプロダクトデザインとエンジニアリングのスタジオです。Webプラットフォーム、モバイルアプリ、社内ツールなど60件以上のプロジェクトを手がけてきました。私たちにとってディスカバリーは形式ではなく、実務のための工程です。
まず最初の打ち合わせで、ビジネスの目的を伺います。プロジェクト型の契約では、次に実際に開発を担当するデザイナーとエンジニアが参加するディスカバリー・スコーピングワークショップを行います。デザイン会社と開発会社の間で受け渡しをするのではなく、デザインと技術的な実現性を同じチームで同時に確認します。その後、進め方、参加メンバー、必要な期間と体制をまとめた率直な提案書をお送りします。料金は公開しておらず、最初の打ち合わせの後に案件ごとにスコープを定めます。
進め方は文書中心です。決定事項、画面フロー、要件をすべて書面に残し、プロトタイプや注釈付きの画面を使うことで、日本語で仕事をするチームにも内容を確認しやすくしています。打ち合わせでは、AIによるリアルタイム翻訳と要約も活用します。
私たちが適任でない場合は、早い段階でそうお伝えします。たとえば、検証済みの詳細な仕様と強い社内プロダクトチームがすでにある場合は、開発リソースの追加だけで十分かもしれません。その場合は、ラボ型開発に近いエクステンデッドチーム型でのご支援が向いています。お問い合わせは hello@devnori.com まで。平日であれば24時間以内にご返信します。