費用をかけて開発を外注したのに、出来上がったものが「思っていたのと違う」。中小企業のシステム開発で、最もよく聞く失敗がこれです。多くの場合、原因は技術力やツール選びではなく、その手前にあります。
「何を作るか」を決める工程が、いちばん難しい
システム開発は、大きく「何を作るかを決める工程（要件定義）」と「実際に作る工程」に分かれます。世間では作る工程に注目が集まりがちですが、プロジェクトの成否は、ほとんど最初の「何を作るか」で決まります。
ここがずれていると、どれだけ腕のいいエンジニアが丁寧に作っても、出来上がるのは「頼んだ通りだけど、欲しかったものとは違うもの」になります。作り直しになれば、時間も費用も二重にかかります。
要件定義は「業務を言葉にする作業」
なぜ最初の工程が難しいのか。それは、要件定義が本質的に「自分たちの業務を言葉にする作業」だからです。
毎日当たり前にやっている仕事ほど、人は言葉にできません。「ここは状況によって判断が変わる」「この例外のときだけ手順が違う」——こうした暗黙のルールは、現場の頭の中にあって、書き出されていないことがほとんどです。これを知らない外部の会社が、要件定義まで巻き取ることは本来できません。
それでも要望をざっくり聞いただけで開発が進むと、何が起きるか。発注した側の「本当はこうしたい」という意図が、営業から設計、設計から実装へと人を渡るうちに、少しずつ削れていきます。最後に出てくるのは、最初の狙いが抜け落ちたシステムです。いわば、伝言ゲームの最後の一人が受け取った言葉のようなものです。
業務を知っている側が、最初に関わる
ではどうすればいいか。答えはシンプルで、「業務をいちばん知っている側（＝発注する自社）」が、最初の工程にしっかり関わることです。
とはいえ、経営者や現場の担当者が、自社の業務をいきなり整理された形で語れることは、まずありません。だからこそ、業務を引き出す側の力が問われます。実感として、要件定義は一度の打ち合わせで決めきろうとせず、段階的に質問を重ねていくほうが、早く、深いところまで着地します。「ここまで業務を理解してくれるのか」と思ってもらえたとき、プロジェクトはほぼうまくいきます。技術の話よりも、相手の業務をどれだけ理解できるかが、結果を分けます。
発注する側が持っておきたい一つの視点
専門の業者に任せるとしても、発注する側に一つだけ持っておいてほしい視点があります。「この開発で、最終的に何が楽になり、何が良くなるのか」を、自分の言葉で言えるようにしておくことです。
これさえ握れていれば、途中で細かい仕様の判断を迫られても、立ち返る軸ができます。逆にここが曖昧なまま発注すると、伝言ゲームを止める人が誰もいなくなります。
ウェイクラップの考え方
ウェイクラップは、この「何を作るか」を一緒に整理するところから関わることを大切にしています。作る前に業務を解きほぐし、経営の狙いと現場の運用を最後まで地続きにする。それが、作り直しを防ぎ、本当に使えるシステムにつながると考えているからです。
「外注したけれど思ったものにならなかった」「これから開発を頼みたいが、何をどう伝えればいいか分からない」——そんなときは、要件定義や業務の整理から、一緒に進めるところを始めてみませんか。