Functional Prototype
完全型プロトタイプとは
「動く画面」と「動くシステム」は、まったく別物です。
プロトタイプという言葉は広く使われていますが、その内容はベンダーによって大きく異なります。
Alcogyが提供するのは「完全型プロトタイプ」です。
Definition
What it is
完全型プロトタイプの定義
完全型プロトタイプとは、実際にデータの入力・保存・閲覧・処理ができる本番相当の機能を持つプロトタイプのことです。画面のレイアウトや操作感を確認するための「モックアップ」や「ワイヤーフレーム」とは本質的に異なります。
モックアップは見た目を確認するものです。ボタンを押しても何も起きない、データを入力しても保存されない、画面遷移は固定で決まっている——そういったものがモックアップです。完全型プロトタイプはそれとは異なり、実際のデータを扱いながら業務フローを試すことができます。
| 画面プロトタイプ | 部分プロトタイプ | 完全型プロトタイプ | |
|---|---|---|---|
| 目的 | 画面・操作感の確認 | 特定機能の動作検証 | 業務フロー全体の検証 |
| データ | ダミーまたはなし | 一部実データ | 実データを扱える |
| 業務ロジック | なし | 一部実装 | 本番相当を実装 |
| 確認できること | 見た目・操作の流れ | 特定機能が動くか | 業務が実際に回るか |
| 本開発との関係 | 参考資料 | 部分的に流用可 | そのまま発展させられる |
| 向いている場面 | 初期の画面確認・提案 | 技術検証・PoC | 要件定義・仕様確定 |
Why Functional
なぜ「完全型」でなければならないのか
一般的な要件定義では、ドキュメントや口頭説明をもとに完成後のシステムを頭の中でイメージし、それが業務に合うかどうかを判断します。しかしこの判断は、誰にとっても本質的に難しい作業です。
実際に触れてみると、資料上では問題なく見えた仕様が違和感を持つことは珍しくありません。「この入力項目は毎回使わない」「この画面に来るまでの操作が多すぎる」「このボタンはここにあるべきではない」——こうした気づきは、動くシステムを操作して初めて得られます。
モックアップでは「何となく良さそう」という感覚しか生まれません。完全型プロトタイプであれば、実際のデータを入力しながら業務を試行できるため、「使えるか・業務に合うか」を具体的に判断できます。この差が、本開発後の手戻りの有無を大きく左右します。
Problem
Why Not Widespread
プロトタイプが普及しない理由
プロトタイプが業務IT化に有効なことは明らかです。では、なぜ普及していないのでしょうか。
最も多い原因は、プロトタイプの制作・検証が中途半端な状態で終わることです。十分な機能を実装しないまま「仮の画面」として終わる、検証の場を十分に設けないまま本開発に入る、フィードバックを要件に落とし込む前にプロジェクトが進む——こうした状況では、プロトタイプは形式的な工程にしかなりません。
また、ベンダーによっては「動く画面モックアップ」をプロトタイプと呼ぶことがあります。見た目が動いていても、データが保存されない・業務フローが試せないモックアップでは、要件定義の精度は上がりません。
こうした状況が積み重なり、「プロトタイプを使ったが効果がなかった」「プロトタイプは机上の空論だ」という誤った結論に至るケースが多く見られます。問題はプロトタイプという手法ではなく、完全型で実施されなかったことにあります。
Requirements
Requirement 01
技術基盤とテンプレートの整備
完全型プロトタイプを低コスト・短期間で構築するためには、それに適した技術選定と開発環境が必要です。本番開発と同じスタックで作ろうとすると、プロトタイプだけでも相当なコストがかかってしまいます。
Alcogyでは SvelteKit と Cloudflare のエコシステムをプロトタイプ専用の技術基盤として整備しています。さらに、業務システムに共通する機能（認証・データ一覧・フォーム・承認フローなど）をテンプレートとして用意することで、個別案件ごとのゼロからの実装を最小化し、完全型であってもコストを抑えた提供を可能にしています。
アーキテクチャには、軽量DDD（ドメイン駆動設計）を採用しています。DDDは本来、大規模開発において複雑なビジネスロジックを整理するために用いられる設計手法です。Alcogyではこれを中小企業向けの規模に合わせてカスタマイズし、コードの保守性を高めながら、仕様変更や機能追加に対して素早く安全に対応できる構造を実現しています。プロトタイプ段階での設計品質を保つことが、本開発への移行をスムーズにする基盤にもなっています。
Requirement 02
スコープクリープへの対処
完全型プロトタイプは実際に操作できるため、触れた担当者から「これも追加してほしい」「あの機能も入れたい」という声が出やすくなります。これはプロトタイプが機能している証拠でもありますが、適切に管理しなければ要件が際限なく膨らんでしまいます。
この「スコープクリープ（要件の肥大化）」はプロトタイピングの工程でよく起きる問題です。Alcogyでは、追加要件の受け付け方・優先順位の付け方・スコープ変更の判断基準を事前に整理し、プロトタイプ工程が予算・期間内に収まるようにマネジメントします。
Requirement 03
発注者と現場の協力体制
完全型プロトタイプは、発注ご担当者様と現場メンバーが共に前向きに関与することで価値を発揮します。プロトタイプを実際に使って意見を出してもらうことが、このプロセスの核心です。
どちらか一方でも非協力的な場合、十分なフィードバックが得られず、検証が成立しません。発注担当者だけで判断しても現場の実態が反映されず、現場だけに任せても全体最適の視点が抜けます。両者が揃って取り組む体制があるかどうかが、プロトタイプの成否を左右する最大の人的条件です。