実物を触ると、要件定義がこんなに楽になる

ベンダーへの依頼は多くの場合、ウォーターフォール開発という手法で進みます。この手法では「先に要件を決める」ことが前提ですが、動くものを見ていない状態で要件を決めるのは、想像以上に難しいことです。

ウォーターフォール開発とは

ウォーターフォール開発とは、「要件定義 → 設計 → 開発 → テスト → リリース」という工程を順番に進める開発手法です。水が上から下へ流れるように、前の工程が終わってから次の工程に進むことからこの名前がついています。

国内のシステム開発では長年の主流であり、ベンダーに依頼すると多くの場合この手法で進みます。工程が明確に分かれているため、スケジュールや費用の見積もりが立てやすいというメリットがあります。

ただし、要件定義の段階で「何を作るか」を正確に決める必要があります。後の工程で要件を変更すると、それまでの設計・開発をやり直すことになり、コストと期間に影響します。

要件定義では、「どんな機能が必要か」「どんな画面にするか」「どんなデータを扱うか」をこの段階で決めておきます。決めたことを文書化し、ベンダーと合意した上で開発が始まります。

ウォーターフォール開発においてこの工程は特に重要で、後戻りが難しい構造上、ここで正確に決めることが求められます。

これが難しいのは、動くものを見ていない状態で「最終的にどういうものが欲しいか」を正確に言語化しなければならないからです。

たとえば、「受注管理画面を作りたい」という要望があるとします。どんな入力項目が必要か、どんな一覧表示にするか、検索条件は何にするか——これらを文書で正確に決めるのは、実際の画面を一度も見ていない状態では簡単ではありません。

「よくある感じで」「使いやすくして」という指示が曖昧だと言われても、経験のない発注者にはそれ以上の表現が出てこないこともあります。

さらに、文書で合意した内容が、完成した画面を見て初めて「これは違う」と気づくことも多いです。言葉で思い描いていたものと、実際に動くシステムの間にはギャップが生まれます。

完全型プロトタイプを触ったとき、要件定義の場で起きることは大きく変わります。

「違う」がすぐに言える。文書を読んで「これで合っていますか？」と問われても答えにくいですが、実際に操作してみると「この順番は逆の方がいい」「この入力が面倒すぎる」「この画面に来る前に確認ステップが必要」という感覚がすぐに出てきます。

業務の例外が自然に出てくる。プロトタイプを使って実際の業務を通しで確認すると、「この場合はどうするんだっけ」「このパターンは想定していなかった」という声が自然と出てきます。文書ベースの要件定義では見落としがちな例外処理が、操作しながら発見できます。

複数の担当者が同じ画面を見て話し合える。要件定義の会議で「その機能はこういう意味ですよね」という解釈のズレが起きることがあります。実物を前にすれば、全員が同じものを見ながら議論できるため、認識のズレが起きにくくなります。

「要件定義が難しい」「要件が決まらないまま開発が始まってしまった」という悩みは多くの現場で起きています。

でも、これは発注側の能力の問題ではなく、進め方の問題です。動くものを見ていない状態で要件を固めようとするから難しいのであって、実物を触りながら進める方法に変えれば、要件定義のハードルは大きく下がります。

完全型プロトタイプ開発は、「先に決める」から「触りながら決める」へと進め方を変えるアプローチです。要件定義の負担を発注側だけに押し付けず、ベンダーが作ったプロトタイプを軸に、一緒に要件を作り上げていきます。