Requirements Definition

プロトタイプを使った要件定義

「合意する」ではなく、「検証して確定する」

多くのシステム開発プロジェクトで要件定義フェーズが実施されますが、その多くは文書ベースの合意に留まっています。
プロトタイプを活用することで、要件定義の精度を根本から変えることができます。

The Problem

Limits of document-based requirements

文書ベース要件定義の限界

従来の要件定義は、ヒアリング内容をもとに仕様書・画面遷移図・業務フロー図などを作成し、発注者とベンダーが文書上で合意するプロセスです。この手法には根本的な限界があります。

人間は「作られていないものがどう動くか」を正確にイメージすることが苦手です。仕様書を読み、「問題ない」と合意しても、実際に動くシステムを見て初めて「こういうイメージではなかった」と気づくケースが後を絶ちません。これは発注者の理解不足ではなく、文書から完成品を想像することの本質的な困難さです。

また、業務の細部——例外処理、稀な業務ケース、複数部門にまたがるフロー——は、ヒアリングの場では話題に上がりにくく、仕様書に反映されないことがあります。これらは完成後に発覚する仕様漏れの典型です。

The real cost

要件定義の「ずれ」が招くコスト

要件のずれが開発完了後に発覚した場合、修正のコストは開発初期と比べて大きく跳ね上がります。設計・実装・テストが完了した段階での仕様変更は、単純な修正ではなく、関連する機能への波及・テストのやり直し・スケジュール全体への影響を伴うためです。

PoCを実施することは追加コストではなく、より高い確率で開発を成功させるための先行投資です。税理士費用のように、適切なコストをかけることで、後の大きな損失を防ぐ性格の投資です。

Prototype-Based Approach

How it works

プロトタイプを使った要件定義の流れ

プロトタイプベースの要件定義では、文書合意の前に「動くもの」を作って検証するプロセスを取ります。Alcogyでは以下の流れで進めます。

01

ヒアリング・業務整理

現状の業務フロー・課題・目標をヒアリングします。この段階では詳細な仕様を決めるのではなく、「何のためにシステムを作るのか」「誰がどう使うのか」という本質的な部分を整理します。

02

完全型プロトタイプの構築

ヒアリング内容をもとに、実データを扱える完全型プロトタイプを構築します。画面のモックアップではなく、実際の業務フローを一通り試せる状態にします。SvelteKit + Cloudflareを中心とした技術基盤と、業務システム向けに整備したアーキテクチャを活用することで、短期間・低コストでの構築を実現しています。

03

PoC(概念実証)・検証セッション

発注担当者と現場担当者の両方に実際にプロトタイプを操作してもらい、フィードバックを収集します。「使いにくい点」「抜けている機能」「業務フローの不一致」がこの段階で具体的に出てきます。

04

改善・再検証のサイクル

フィードバックをもとにプロトタイプを改善し、再度検証します。このサイクルを繰り返すことで、「実際に使える」という確信を持てる状態まで要件を精緻化します。

05

仕様ドキュメントの確定

検証済みの状態をベースに仕様ドキュメントを作成します。文書から始めた要件定義ではなく、実際に動いて確認された内容を文書化するため、精度が根本的に異なります。このドキュメントは発注先フリーで利用できます。

What Changes

Before and after

要件定義の前後比較

文書ベースの要件定義プロトタイプベースの要件定義
確認方法仕様書・図面を読んでイメージする実際に操作して確認する
仕様漏れの発覚タイミング開発完了後PoC段階(開発前)
現場担当者の関与リリース後が多いPoC段階から参加
認識ずれの修正コスト高い(開発やり直し)低い(プロトタイプ修正)
完成後の定着度不確実高い(検証済みのため)

Important note

プロトタイプ要件定義が成立する条件

プロトタイプを使った要件定義が機能するためには、検証に使うプロトタイプが「完全型」である必要があります。画面だけのモックアップや、一部の機能しか動かないプロトタイプでは、業務フロー全体を検証することができません。

また、現場担当者が実際に手を動かして検証するセッションを十分に設けることが不可欠です。発注担当者の確認だけでは、現場の実態に即した要件定義にはなりません。

この条件を満たすプロトタイプを短期間・低コストで構築するために、Alcogyは自社の技術基盤を整備しています。