完全型プロトタイプ開発を始める前に、社内で整理しておくこと

ベンダーへの依頼前に、社内で整理しておくべきことがあります。詳細な仕様書は不要ですが、現状業務とゴールイメージは言語化できる状態にしておきましょう。

「説明できる自信がない」は普通のことです

システム開発の発注経験がない企業が最初に感じるのは、「ちゃんと説明できるか不安」という気持ちです。仕様書を作った経験もなく、IT用語にも不慣れな状態でベンダーに相談するのは、ハードルが高く感じます。

完全型プロトタイプ開発は、要件を言語化しなくても進められることが特徴の一つです。「何を作るか」が曖昧な状態でも、動くプロトタイプを触りながら要件を固めていけます。ただし、ゼロの状態から始めるよりも、社内で事前に整理しておくべきことはあります。

「今、どんな手順で業務が行われているか」を整理します。誰が何を、どのタイミングで行い、どこに記録しているか——これを一通り言語化しておくと、ヒアリングがスムーズになります。

フローチャートのような図が作れれば理想ですが、箇条書きや手書きのメモでも十分です。「説明しながら整理する」でも構いません。

現在の業務で何が問題なのかを整理します。「ミスが多い」「時間がかかっている」「属人化している」「紙でやり取りしていて追跡できない」など、具体的であるほど良いです。

「何を作りたいか」よりも「何に困っているか」の方が、ベンダーとのヒアリングで価値のある情報になります。

「いくらまでかけられるか」「いつまでに稼働させたいか」を社内で整理しておきます。完全型プロトタイプ開発はプロトタイプと本開発の2段階になるため、期間は一般的な開発より長くなります。予算・期間の制約が厳しい場合は、その前提でベンダーと相談する必要があります。

プロジェクトの社内窓口になる担当者と、プロトタイプの確認を行う現場担当者を決めておきます。

プロトタイプは「触って確認する」プロセスが核心なので、実際に業務を行っている担当者が確認に参加できる状態にしておくことが重要です。経営層だけで進めて現場に確認してもらえない、というケースでは効果が薄くなります。

これらはベンダーと一緒に作るものです。事前に作ろうとすることで、かえって方向性が固まってしまうこともあります。

完全型プロトタイプ開発は、すべてのベンダーが対応しているわけではありません。むしろ、対応できるベンダーは多くありません。

一般的なシステム開発では、要件定義→設計→開発→テストというウォーターフォール型の進め方が標準です。「プロトタイプを作って確認しながら進める」というアプローチは、技術的にも運用的にも別の体制が必要になります。

「プロトタイプ開発」という言葉を使っているベンダーであっても、画面のモックアップ程度を指している場合があります。完全型プロトタイプ開発を希望する場合は、「業務が実際に動くプロトタイプを先に作る」というアプローチを明示的に確認することをお勧めします。