仕様が固まらないまま始めたシステム開発をプロトタイプで乗り越えた話
はじめに
「まず仕様を決めてきてください」
システム開発を検討してWeb制作会社や開発会社に相談したとき、こう言われて止まってしまった経験はないでしょうか。あるいは、何度打ち合わせを重ねても話がまとまらず、気づいたらプロジェクトが宙に浮いていた、という方もいるかもしれません。
私はWebエンジニアとして独立する前、大手化学メーカーで7年間、研究開発に携わっていました。その後Web業界に転身し、今は製造業や中小企業のシステム開発・Web制作を手がけています。その経験の中で、ある案件を通じて「仕様が固まらない問題」の本質と、その解決策に気づきました。今回はその話をそのまま書こうと思います。
この記事のまとめ
- 「仕様が固まらない」は発注側の問題ではなく、構造的に起きやすい現象
- 言葉や文書で仕様を確認しようとすること自体に限界がある
- 動くプロトタイプを先に見せることで、認識のズレが一気に解消される
- 化学メーカーでの「仮説検証」の思考回路が、この解決策の土台になっている
- 複雑な業務課題ほど、丁寧なヒアリングとプロトタイプの組み合わせが有効
なぜ仕様は固まらないのか
.pp-col { border-radius: 10px; margin-bottom: 1.2em; overflow: hidden; } .pp-col
{ margin-bottom: 0; }.pp-col-head { padding: 0.75em 1.1em; font-size: 0.82em; font-weight: 700 !important; letter-spacing: 0.04em; }
.pp-col-bad .pp-col-head { background: rgb(235 155 111 / 0.12); color: #EB9B6F; border: 1px solid rgb(235 155 111 / 0.3); border-bottom: none; border-radius: 10px 10px 0 0; } .pp-col-good .pp-col-head { background: rgb(58 40 4 / 0.08); color: #3A2804; border: 1px solid rgb(58 40 4 / 0.15); border-bottom: none; border-radius: 10px 10px 0 0; }
.pp-col-body { padding: 1em 1.1em 1.2em; } .pp-col-bad .pp-col-body { background: rgb(255 255 255 / 0.08); border: 1px solid rgb(235 155 111 / 0.2); border-top: none; border-radius: 0 0 10px 10px; box-shadow: inset 0 0 20px rgb(255 255 255 / 0.15); } .pp-col-good .pp-col-body { background: rgb(255 255 255 / 0.12); border: 1px solid rgb(58 40 4 / 0.12); border-top: none; border-radius: 0 0 10px 10px; box-shadow: inset 0 0 20px rgb(255 255 255 / 0.25); }
.pp-step { display: flex; align-items: flex-start; gap: 0.75em; padding: 0.55em 0; border-bottom: 1px solid transparent; } .pp-col-bad .pp-step { border-bottom-color: rgb(235 155 111 / 0.12); } .pp-col-good .pp-step { border-bottom-color: rgb(58 40 4 / 0.08); } .pp-step
{ border-bottom: none; padding-bottom: 0; }.pp-ico { font-size: 1.1em; flex-shrink: 0; margin-top: 0.1em; width: 1.4em; text-align: center; }
.pp-step-ttl { font-size: 0.82em; font-weight: 700 !important; margin-bottom: 0.15em; } .pp-col-bad .pp-step-ttl { color: #EB9B6F; } .pp-col-good .pp-step-ttl { color: #3A2804; }
.pp-step-desc { font-size: 0.82em; color: #766156; line-height: 1.55; }
.pp-arr { font-size: 0.85em; padding: 0.1em 0 0.1em 2.15em; } .pp-col-bad .pp-arr { color: rgb(235 155 111 / 0.3); } .pp-col-good .pp-arr { color: rgb(58 40 4 / 0.2); }
.pp-badge { margin-top: 0.9em; padding: 0.55em 0.9em; border-radius: 6px; font-size: 0.78em; font-weight: 700 !important; text-align: center; } .pp-col-bad .pp-badge { background: rgb(235 155 111 / 0.12); border: 1px solid rgb(235 155 111 / 0.3); color: #EB9B6F; } .pp-col-good .pp-badge { background: rgb(58 40 4 / 0.06); border: 1px solid rgb(58 40 4 / 0.15); color: #3A2804; }
.pp-result { display: flex; align-items: center; gap: 0.7em; margin-top: 0.7em; padding: 0.7em 0.9em; border-radius: 8px; } .pp-col-bad .pp-result { background: rgb(235 155 111 / 0.1); border: 1px solid rgb(235 155 111 / 0.25); } .pp-col-good .pp-result { background: rgb(58 40 4 / 0.06); border: 1px solid rgb(58 40 4 / 0.15); }
.pp-result-ico { font-size: 1.2em; flex-shrink: 0; } .pp-result-txt { font-size: 0.78em; font-weight: 700 !important; line-height: 1.45; } .pp-col-bad .pp-result-txt { color: #EB9B6F; } .pp-col-good .pp-result-txt { color: #3A2804; }
.pp-foot { margin-top: 1.6em; padding-top: 1em; border-top: 1px solid rgb(58 40 4 / 0.15); display: flex; justify-content: flex-end; } .pp-brand { font-size: 0.65em; color: rgb(58 40 4 / 0.3); letter-spacing: 0.2em; font-weight: 500 !important; }
@container (max-width: 600px) { .pp-inf-a { padding: 1.4em; font-size: 15px; } }
Specification Problem / Solution
なぜ「言葉だけ」では仕様が固まらないのか
❌ 言葉だけで進める場合
💬
言葉で説明する
「こういう感じで管理したい」——でも頭の中のイメージは伝わらない
↓
🤔
双方の認識がズレる
同じ言葉でも、聞いた側のイメージは全く違う
↓
📝
仕様書を修正する
何度直しても「なんか違う」が続く。確信が持てない
↓
💬
また言葉で説明する…
打ち合わせのたびに話が変わり、ループから抜け出せない
🔁 このループが延々と続く
😰
時間だけが過ぎ、プロジェクトが宙に浮く
✅ プロトタイプを使う場合
💬
言葉でざっくり聞く
「こういう感じ」で十分。完璧に固める必要はない
↓
🖥️
動くものを先に見せる
現時点の認識をそのままプロトタイプに落とし込む
↓
👁️
見ながら確認・修正
「ここが違う」「これはいい」が画面を見て初めて出てくる
↓
🎯
認識が一気に揃う
言葉では出なかった要望が、短いサイクルで次々と明確になる
⚡ 短いサイクルで確実に前進できる
🎉
「これです！これで勝てます！」——クライアントの確信につながる
PEAS PROJECT
最初に断言しておきたいのは、「仕様が固まらない」のは発注する側の能力の問題ではないということです。
自社の業務フローを言語化することに慣れている人は、ほとんどいません。毎日当たり前のようにやっている作業だからこそ、それを言葉にするのは意外と難しい。「こういう感じで」「なんとなくこういう流れで」という表現になってしまうのは、むしろ自然なことです。
加えて、言葉で説明できたとしても、受け取る側との認識がズレることは頻繁に起きます。「管理する」という言葉一つとっても、Aさんが想像するシステムとBさんが想像するシステムは全然違う。言葉は思っている以上に曖昧で、それがそのままシステムの仕様に持ち込まれると、後になって「こういうつもりじゃなかった」という事態が起きます。
つまり「仕様が固まらない」という問題は、発注側の準備不足ではなく、言葉だけで仕様を確認しようとする進め方そのものに無理があるのです。
ミーティングのたびに話が変わった、あの案件のこと
少し前の話になりますが、中国からアパレル商品を輸入して日本国内で販売したい人たちを支援する、輸入代行業者の方からシステム開発のご依頼をいただきました。
その方のビジネスは複雑な構造をしていました。中国現地のスタッフ、日本国内で輸入販売をしたいクライアント、そして加工・検品・梱包を担当する作業者。この三者の間に入って、商品ごとに異なる指示を出したり、タグの付け替えや値札の変更を管理したりしていたのです。それをExcelで管理していたのですが、クライアントが増えるにつれて煩雑さが限界に達していた。
初回の打ち合わせでは「こういうシステムが欲しい」というイメージを丁寧に話してくれました。ところが次の打ち合わせでは、別の機能が追加されていたり、前回と違う前提で話が進んでいたりする。
正直に言うと、最初は戸惑いました。「なぜ話がまとまらないのか」と。でも打ち合わせを重ねるうちに気づいたのです。この方は悪意があって話を変えているわけじゃない。自分のビジネスの全体像を言葉にしながら、頭の中を整理しているんだ、と。
化学メーカーで叩き込まれた「仮説検証」の思考
.pp-domain { border-radius: 10px; margin-bottom: 1em; overflow: hidden; } .pp-domain
{ margin-bottom: 0; }.pp-domain-head { display: flex; align-items: center; gap: 0.6em; padding: 0.75em 1.1em; border-radius: 10px 10px 0 0; } .pp-domain-chem .pp-domain-head { background: rgb(235 155 111 / 0.15); border: 1px solid rgb(235 155 111 / 0.35); border-bottom: none; } .pp-domain-web .pp-domain-head { background: rgb(58 40 4 / 0.07); border: 1px solid rgb(58 40 4 / 0.15); border-bottom: none; }
.pp-domain-ico { font-size: 1.1em; } .pp-domain-name { font-size: 0.82em; font-weight: 700 !important; letter-spacing: 0.04em; } .pp-domain-chem .pp-domain-name { color: #EB9B6F; } .pp-domain-web .pp-domain-name { color: #3A2804; }
.pp-domain-body { padding: 1em 1.1em 1.2em; } .pp-domain-chem .pp-domain-body { background: rgb(255 255 255 / 0.1); border: 1px solid rgb(235 155 111 / 0.2); border-top: none; border-radius: 0 0 10px 10px; box-shadow: inset 0 0 20px rgb(255 255 255 / 0.15); } .pp-domain-web .pp-domain-body { background: rgb(255 255 255 / 0.12); border: 1px solid rgb(58 40 4 / 0.12); border-top: none; border-radius: 0 0 10px 10px; box-shadow: inset 0 0 20px rgb(255 255 255 / 0.25); }
.pp-cycle-step { display: flex; align-items: flex-start; gap: 0.75em; padding: 0.55em 0; border-bottom: 1px solid transparent; } .pp-domain-chem .pp-cycle-step { border-bottom-color: rgb(235 155 111 / 0.12); } .pp-domain-web .pp-cycle-step { border-bottom-color: rgb(58 40 4 / 0.08); } .pp-cycle-step
{ border-bottom: none; padding-bottom: 0; }.pp-num { width: 1.7em; height: 1.7em; border-radius: 50%; display: flex; align-items: center; justify-content: center; font-size: 0.78em; font-weight: 700 !important; flex-shrink: 0; margin-top: 0.15em; } .pp-domain-chem .pp-num { background: rgb(235 155 111 / 0.15); border: 1px solid rgb(235 155 111 / 0.4); color: #EB9B6F; } .pp-domain-web .pp-num { background: rgb(58 40 4 / 0.08); border: 1px solid rgb(58 40 4 / 0.2); color: #3A2804; }
.pp-cs-ttl { font-size: 0.82em; font-weight: 700 !important; margin-bottom: 0.15em; } .pp-domain-chem .pp-cs-ttl { color: #EB9B6F; } .pp-domain-web .pp-cs-ttl { color: #3A2804; }
.pp-cs-desc { font-size: 0.78em; color: #766156; line-height: 1.55; }
.pp-bridge { background: rgb(235 155 111 / 0.1); border: 1px solid rgb(235 155 111 / 0.3); border-radius: 12px; padding: 1.4em 1.6em; text-align: center; margin: 1.2em 0; } .pp-bridge-label { font-size: 0.65em; color: #EB9B6F; letter-spacing: 0.2em; text-transform: uppercase; margin-bottom: 0.6em; font-weight: 700 !important; } .pp-bridge-txt { font-size: 1em; font-weight: 700 !important; color: #3A2804; line-height: 1.5; margin-bottom: 0.5em; } .pp-bridge-sub { font-size: 0.78em; color: #766156; line-height: 1.6; }
.pp-insight-row { display: flex; flex-direction: column; gap: 0.7em; } .pp-insight { display: flex; align-items: flex-start; gap: 0.9em; background: rgb(255 255 255 / 0.12); border: 1px solid rgb(255 255 255 / 0.55); border-radius: 8px; box-shadow: 0 4px 12px rgb(58 40 4 / 0.12), 0 1px 3px rgb(58 40 4 / 0.08), inset 0 0 20px rgb(255 255 255 / 0.25); padding: 0.9em 1em; } .pp-insight-ico { font-size: 1.2em; flex-shrink: 0; margin-top: 0.05em; } .pp-insight-ttl { font-size: 0.82em; font-weight: 700 !important; color: #EB9B6F; margin-bottom: 0.2em; } .pp-insight-desc { font-size: 0.78em; color: #766156; line-height: 1.5; }
.pp-foot-b { margin-top: 1.6em; padding-top: 1em; border-top: 1px solid rgb(58 40 4 / 0.15); display: flex; justify-content: flex-end; } .pp-brand-b { font-size: 0.65em; color: rgb(58 40 4 / 0.3); letter-spacing: 0.2em; font-weight: 500 !important; }
@container (max-width: 600px) { .pp-inf-b { padding: 1.4em; font-size: 15px; } }
Chemistry × Web Development
化学研究の「仮説検証」がシステム開発に活きる理由
化学メーカーで叩き込まれた思考回路は、開発現場でそのまま動く。
化学メーカー時代
仮説を立てる
「この条件なら反応が進むはずだ」
実験する
言葉でなく、実際に手を動かして確かめる
結果を見る
想定外の結果が出ることはむしろ当たり前
仮説を修正する
失敗ではなく「学び」。次の仮説に活かす
システム開発現場
ヒアリングする
「こういう業務がしたい」をざっくり聞く
プロトタイプを作る
言葉でなく、動くものを先に見せる
フィードバックを得る
「ここが違う」が画面を見て初めて出てくる
仕様を修正する
ズレを早期に発見し、短いサイクルで前進
Core Insight
「言葉より実物で確かめる」
——これは研究も開発も同じ
化学メーカーで当たり前だったこの思考が、仕様が固まらない問題をそのまま解決した。
🔬
再現性を重視する
実験ノートの習慣がドキュメント文化に活きる
⚡
早期に検証する
後で大きく直すより、早く小さく直す
🎯
失敗を学びにする
ズレが出ることを前提に設計する
PEAS PROJECT
行き詰まったとき、私は化学メーカー時代の感覚を思い出しました。
研究開発では、最初から正解を出そうとしません。まず仮説を立てて、実験して、結果を見て、仮説を修正する。この繰り返しです。重要なのは「言葉で考える」より「手を動かして確かめる」こと。どんなに精緻な計画を立てても、実際に実験してみると想定外のことが起きる。それが当たり前で、そこから学んでいくのが研究のプロセスでした。
「これはWebの仕事でも同じじゃないか」と思ったのです。言葉でいくら仕様を確認しようとしても限界がある。だったら、動くものを先に見せてしまえばいい。
「これです！これで勝てます！」
仕様がある程度見えてきた段階で、私はまだ完全には固まっていない状態のまま、簡単なプロトタイプを作りました。完成品ではなく、あくまでも「こういう認識で合っていますか？」を確認するためのものです。
それを見せたとき、クライアントの反応は今でも鮮明に覚えています。
「これです！これで勝てます！」
それまで言葉でうまく伝えられなかったものが、画面の前で一気につながった瞬間でした。「ここはこうしたい」「この部分はもう少しこう変えてほしい」という具体的なフィードバックも、プロトタイプがあることで初めてスムーズに出てきました。
言葉での説明が難しかったのではなく、見るべきものがなかっただけだったのです。
この経験が変えた、私のヒアリングへの向き合い方
この案件以来、私はシステム開発の打ち合わせにおいて、「仕様を言葉で固めてから動く」という順番にこだわらなくなりました。むしろ、ある程度の認識が揃ったら早めに手を動かして、動くものを見ながら一緒に考えるというプロセスを意識しています。
もちろん、プロトタイプを作るにはそれなりの時間と手間がかかります。でも、言葉だけで何度も打ち合わせを繰り返して後から大幅な修正が入るよりも、結果的にずっと効率がいい。何より、クライアントにとって「自分のビジネスがちゃんと形になっていく」実感を早い段階で持ってもらえることが、信頼関係の構築につながると感じています。
ただ、こうした打ち合わせには発注する側にも相応の負荷がかかります。その覚悟についてはシステム開発を依頼する前に知っておきたい「打ち合わせの覚悟」に書きました。
化学メーカー時代に染み込んだ「仮説→検証→修正」の思考は、研究室を離れた今も、私の仕事の核にあります。
複雑な業務課題を抱えている方へ
既製品のシステムやツールでは解決できない、自社独自の業務フローがある。でも、それをどう言語化して開発会社に伝えればいいか分からない。そういう悩みを持つ方は、思っている以上に多いです。
開発会社に相談する前に何を整理しておくとよいかは、システム開発を依頼する前に整理しておくと、話がスムーズに進むことにまとめました。
仕様が固まっていなくても大丈夫です。むしろ、固まっていない段階から一緒に考えることが、私の仕事だと思っています。
まずは現状をそのままお話しください。「こういう感じで」「なんとなくこういう流れで」という言葉で十分です。そこから一緒に整理していきましょう。