システム開発の「思っていたのと違う」はなぜ必ず起きるのか｜提案書を捨てた私たちの結論

結論を先に。 システム開発で「思っていたのと違う」が起きるのは、あなたの伝え方が悪いからでも、開発会社の技術が低いからでもありません。「言葉で要件を伝え、書類で合意し、完成してから初めて動くものを見る」という進め方そのものが、認識のズレを構造的に生み続けるからです。この構造を放置したまま、伝え方を工夫したり、議事録を丁寧に取ったりしても、ズレは小さくなるだけでなくなりません。この記事では、受託開発の現場に15年関わってきた私たちがこの構造をどう捉え、なぜ提案書を書くのをやめたのかを書きます。

「思っていたのと違う」が生まれる3つの構造

翻訳が連鎖するほど、意図は薄まる

あなたの頭の中にある業務の実態は、まず言葉に翻訳され、次にヒアリングシートに翻訳され、要件定義書に翻訳され、設計書に翻訳され、最後にコードに翻訳されます。翻訳が1回はさまるたびに、情報は少しずつ欠けたり歪んだりします。5回翻訳された結果が、あなたの見た「思っていたのと違う」画面です。誰も嘘をついていないのに、伝言ゲームの終点は最初の言葉と違うものになる。これが1つ目の構造です。

「言う通りに作る」ことが、ズレを固定する

2つ目の構造は、もう少し根が深いところにあります。発注者が最初に語る要件は、その方なりに考え抜いた「仮の答え」です。しかしそれは多くの場合、本当の課題そのものではありません。私たちは「お客様の言う通りに作りました」という言葉を、プロの言葉だと思っていません。相手の言葉をそのまま受け取って作るのは、一見誠実に見えて、実は相手の言葉の奥にある痛みを見に行かない怠慢だからです。扇風機の性能をどれだけ上げても、エアコンは生まれません。「もっと風量を」という言葉の奥に「暑さを何とかしたい」があることを見抜くのが、本来の仕事です。

確認が遅いほど、修正の傷は深くなる

3つ目は時間の構造です。従来の進め方では、発注者が動くものを初めて見るのは開発の終盤です。その時点でズレが見つかっても、すでに設計もコードも積み上がっているため、直すには大きな手戻りが要ります。ズレは早く見つかれば軽傷で済み、遅く見つかるほど重傷になります。つまり「完成してから見せる」進め方は、ズレを最も高くつくタイミングで発見する仕組みだと言えます。

現場での実感。 ご相談の場で「困っていることはありますか」と伺っても、たいてい「特に、普通です」と返ってきます。でも業務の流れを順に聞かせていただくと、毎月3日かかっている請求書発行や、担当の方が休むと止まってしまう経理が次々に見えてきます。内側にいる人には見えず、外から見ると一瞬で分かる。要件を「言ってもらう」ことに頼る進め方は、この非対称を前提にできていないのだと、何度も感じてきました。

私たちが変えた3つのこと

この構造に気づいてから、私たちは進め方そのものを変えました。変えたことは3つあります。

1. 提案書を捨てた：15年やってきた提案書づくりをやめました。いまは一度お話を伺ったら、次の打ち合わせには提案書ではなく、そのお客様の業務に合わせて作った動くプロトタイプを持っていきます。紙の上の合意ではなく、実際に触れるものを前にした会話から始めるためです。
2. 契約前に、動くものを確認してもらうことにした：プロトタイプを触りながら「ここは違う」「ここはこうしたい」を出し尽くしてから、先に進むかどうかを決めていただきます。ズレを最も安いタイミング、つまり契約前に見つけるための順番です。
3. 「いつでも辞められる関係」を設計に組み込んだ：ソースコードは全てお渡しし、特定の会社にしか触れない独自技術は使いません。私たちと合わないと感じたら、いつでも他社へ引き継げる状態を保ちます。逃げ道のある関係のほうが、結果として長く続くことを経験から知っているからです。

これはAIによる効率化の話ではありません。AIによって提案フェーズと実装フェーズの境界が溶けたことで初めて成立するようになった、進め方そのものの再設計です。

「安心な会社」を選んでも、この構造からは逃げられない

「大手に頼めば安心だろう」という判断についても触れておきます。会社の規模は、ここまで書いた3つの構造を解消しません。翻訳の連鎖も、言う通りに作る誠実さの罠も、確認の遅さも、大きな会社ほど工程と関係者が増える分、むしろ強く働くことがあります。

私たちは、会社が安定していることと、システムが安定して使い続けられることは別の話だと考えています。問うべきなのは「この会社は潰れないか」ではなく、「この会社が消えたとき、自分は困らないか」です。困らない設計、つまり汎用的な技術で作られ、ソースコードが手元にあり、誰にでも引き継げる状態になっているなら、相手の規模は本質的な問題ではなくなります。

よくある質問

Q. プロトタイプを先に作ってもらって、契約しなかったら費用はかかりますか？
A. かかりません。プロトタイプを触った上で「合わない」と判断されたら、そこで終わりにしていただいて構いません。納得してから先に進む、という順番のための仕組みです。

Q. 要件がまだ固まっていないのですが、相談していいのでしょうか？
A. むしろ固まっていない段階のほうが適しています。この記事に書いた通り、最初に語られる要件は仮の答えです。業務の流れを伺いながら、一緒に本当の課題を見つけるところから始めます。

Q. すでに他社で開発中ですが、「思っていたのと違う」方向に進んでいます。どうすればいいですか？
A. まず、起きているズレが要件側・開発側・コミュニケーションのどこから来ているかを切り分けることをおすすめします。第三者として無料で切り分けをお手伝いするセカンドオピニオンの窓口を用意しています。

Q. この進め方の詳細はどこで確認できますか？
A. 並走型システム開発のアプローチのページで、進め方の全体像を説明しています。費用の考え方は費用相場 完全ガイドにまとめています。

発信：株式会社オルアナ（新規事業開発・システム開発・AIエージェント開発・バックオフィス業務支援）