提案書とスライドしか出てこない商談の問題
業務システムの発注を検討して、複数の開発会社から提案を受けた経験がある人には分かると思う。多くの会社が持ってくるのは、PowerPointのスライドと提案書だ。課題の整理、解決策の概要、システムのイメージ図、工程表、見積もり。そういった資料が並ぶ。
その内容を聞いて、「よく理解してもらえた」と感じることもある。でも、商談が終わった後で、「結局どんなものができるのか、まだよく分からない」という感覚が残ることも多い。
これは発注者の理解力の問題ではない。言語と図だけでシステムの操作感を伝えることには、構造的な限界がある。「受注情報を入力する画面があります」と言葉で説明されても、それが実際にどう動くのか、どれくらい使いやすいかは、触ってみるまで分からない。「承認フローは三段階です」と図で示されても、自分が実際にそのフローを使う時にどんな画面に向き合うのかはイメージできない。
一方で、最初の商談に「動くプロトタイプ」を持ってくる開発会社がある。その違いは、商談の体験を根本から変える。
なぜ初回からプロトタイプを出せるのか
「最初の商談で動くものを持ってくるのは、それだけ事前に作り込んでいるからでは？ コストがかかるのでは？」と思う人もいる。だが実際は違う。
初回商談の前に行われるのは、依頼者の業務への想像だ。「この会社は何をやっていて、どんな業務フローがありそうか」「同種の業界で過去に見てきた課題は何か」「おそらく解決したいのはこのあたりではないか」——こうした仮説を立てて、その仮説をもとにプロトタイプの骨格を作る。
完成品を作るのではない。あくまで「こういうことですか？」を確認するための素材だ。画面の流れ、主要な操作のイメージ、データがどう動くかの大枠。それを商談の場に持っていき、「これはご自身の業務に近いですか？」「違う部分はどこですか？」と聞きながら確認する。
今はツールの進化によってプロトタイプの制作スピードが大きく変わっている。以前は動くものを作るまでに数日かかっていた。今は、話を聞きながら同時進行でプロトタイプの構造を作ることができる。商談の場でその場で確認しながら調整することも、条件が揃えば可能になっている。この変化が、「初回からプロトタイプ」を現実的なアプローチにした。
発注者側の利点：言語化できない要件を視覚で確認できる
「うちの業務をシステム化したい」と考えている発注者にとって、最も難しいことの一つが要件の言語化だ。
毎日やっている業務を言葉にするのは、意外と難しい。「こうしています」と説明したつもりでも、当たり前すぎて言わなかったことがある。「ここはこうじゃないと困る」という前提が、説明の中に入っていないことがある。「この処理は月末だけ量が増える」「この確認は経理と営業の両方が絡む」といった業務の詳細は、問われなければ出てこないことも多い。
動く画面があると、この問題が解消しやすくなる。「この画面で受注を入力するとき、ここには得意先コードを入れますか、それとも社名を打ちますか？」「この一覧に並ぶ順番はどうしたいですか？」——具体的な画面を見ながら話すと、抽象的な言葉では出てこなかった要件が引き出せる。
「言葉では説明しにくかったけど、これを見たら分かった」という場面が生まれやすい。これは発注者にとって、自分たちが本当に必要なものを発見するプロセスでもある。プロトタイプを見ることで、発注者が「ああ、自分が欲しいのはこういうことだ」と気づく瞬間が生まれる。
認識ズレを最小化し、後戻りコストを下げる
システム開発における最大のリスクの一つは、「作り終わってから気づく認識のズレ」だ。開発会社と発注者の頭の中にあるイメージが違ったまま進んで、完成してから「これじゃなかった」となる。
この後戻りは、コストと時間の両方に大きく影響する。設計から戻る場合、開発フェーズからやり直す場合、場合によってはほぼ作り直しになることもある。後になればなるほど、修正のコストは指数関数的に増える。
初回からプロトタイプを使ったすり合わせをすると、認識のズレを早期に発見できる。「画面のイメージ図」ではなく「実際に操作できるもの」で確認するため、ズレが視覚的に明らかになる。「なんとなく分かった」ではなく「これは違う、ここはこうしたい」という具体的なフィードバックが出てくる。
早い段階でズレを見つけることは、後工程での手戻りを防ぐ。これは開発会社にとっても発注者にとっても、プロジェクト全体の品質とコスト効率を高める。プロトタイプへの投資は、後工程での修正コストの節約として回収される。
この手法が合う案件・合わない案件の見分け方
プロトタイプ先行のアプローチがよく機能する案件には特徴がある。
業務フローが比較的シンプルで、対象のユーザーが少人数の場合は相性がいい。画面の数が限られていて、主要な操作が絞れるからだ。また、発注者が「まだ何が欲しいか分かっていない」という段階の案件にも向いている。プロトタイプを見ることで、発注者自身が要件を整理していくプロセスになる。
スタートアップや新規事業のシステム開発も、プロトタイプ先行との相性が良い。業務フロー自体がまだ固まっていないため、動くものを見ながら「こういう流れにしよう」と決めていく進め方が、議論を前に進めやすい。
逆に、プロトタイプ先行が合わない案件もある。官公庁向けや大規模な基幹系システムの場合、関係するステークホルダーが多く、要件決定プロセスに組織的な承認が必要なことが多い。「動くものを見せながら確認」という柔軟な進め方が、決裁の仕組みと合わないことがある。また、複雑なデータ連携やセキュリティ要件が先に固まっていない場合も、プロトタイプより要件定義書の作成を優先すべき場面がある。
どちらのアプローチが自分たちのプロジェクトに合っているかは、発注の規模と、発注者側の要件整理の状況によって変わる。商談の場でそれを正直に確認できる開発会社かどうかも、判断の材料の一つになる。
商談の場が「要件を伝える場」から「要件を発見する場」に変わる
提案書だけの商談では、発注者は「自分が考えた要件を説明し、開発会社に伝える」という役割になりやすい。用意してきた言葉で説明して、相手が理解してくれたかどうかを確認する。これは発注者にとって、大きな認知的な負荷がかかる作業だ。
動くプロトタイプがある商談は、その構造が変わる。一緒に画面を操作しながら「こういうことですか？」「ここはどうしたいですか？」と確認するプロセスになる。発注者は要件を「説明」するのではなく、目の前のものを「評価」する立場になる。
評価の方が、人間には向いている。「良いか悪いか」「合っているか違うか」は、説明するよりも判断しやすい。「何が欲しいかを言葉にする」のは難しいが、「これは違う」「ここはこうしたい」は言いやすい。だから、プロトタイプがある商談では、発注者が本当に必要としているものが引き出しやすくなる。
私たちが初回商談にプロトタイプを持っていく理由は、そこにある。速さのためでも、技術力の誇示のためでもない。発注者と一緒に「本当に欲しいもの」を見つけていくための、最も確実な方法だからだ。商談は情報を伝える場ではなく、一緒に考える場であるべきだ。その考え方が、プロトタイプという形で現れている。