「要件通りに作りました」と開発会社は言う。「でも、これは思っていたものと違う」と発注者は言う。双方が正直なのに、なぜすれ違いが起きるのか。
この問いへの答えを「開発会社が悪い」に求めると、次も同じ失敗を繰り返す。問題の根は、もっと構造的なところにある。システム開発というプロジェクトに内在する構造的な難しさを理解していないと、発注を繰り返すたびに「思っていたのと違う」を経験し続けることになる。
「要件定義」という手法の限界
システム開発では、開発前に「何を作るか」を文書にまとめる要件定義というプロセスがある。この文書が仕様書になり、開発会社はその通りに作る。
問題は、この文書に「書けないもの」が必ず存在することだ。書けないものとは、発注者自身が言語化できていないもの、あるいは「当たり前すぎて書こうと思わなかったもの」だ。どれだけ丁寧に要件定義を行っても、この種の情報を文書に全て盛り込むことは原理的に難しい。
原因① 言語化できていない「当たり前」が伝わっていない
10年、20年と積み上げてきた業務には、誰も言葉にしていない「当たり前のルール」が無数にある。「この取引先には必ず担当者名を2人入れる」「月末の締めは翌営業日扱いにする」「この商品コードだけ消費税の計算が違う」——こうした例外や慣習は、現場にいる人間には自明すぎて、誰も仕様書に書かない。
しかし開発会社から見れば、書いていないことは「そういう仕様ではない」を意味する。完成したシステムにその処理がなくても、仕様書通りに作ったという事実に変わりはない。
「当たり前」は発注者の頭の中にしかない。それを引き出すには、開発会社側の丁寧なヒアリングと、発注者側の「言語化する努力」の両方が必要だ。特に業務歴が長いスタッフに「この処理に例外はありますか」「この判断は誰がどんな条件でしますか」という問いを投げ続けることが、隠れた仕様を掘り起こす。
この作業を「開発会社がやってくれるはず」と思って任せっきりにすると、引き出せない情報が生まれる。発注者側が積極的に「自社の業務の当たり前を言語化する」という姿勢を持つことが不可欠だ。
原因② 発注側の要件が途中で変わる
要件定義を終えた後、実際に業務を動かしながら「やっぱりここを変えたい」が生まれる。これは避けられない。業務は生きているし、プロジェクトが進む中で視点が変わることも自然なことだ。経営判断が変わる、競合の動きが変わる、組織が変わる——外部の変化が要件に影響することも珍しくない。
問題は、この変更が「追加費用なし」で当然のように求められるケースだ。開発会社からすれば、確定した仕様に基づいて人と時間を割り当てている。変更は単純に工数の増加を意味する。
発注者側は「少し変えるだけ」と感じても、システムの内部では大きな影響を及ぼす変更が「小さな変更」に見えることがある。画面の項目を一つ追加するだけでも、データベースの設計変更・既存処理への影響確認・テストの追加が必要になる場合がある。
双方の認識のズレが、コスト交渉の場での感情的な対立を生む。「少し変えるだけなのになぜこんなに高いのか」という不満と、「また仕様が変わった」という疲弊が重なり、プロジェクト全体の信頼関係が損なわれる。
原因③ 完成まで動くものを見せない
多くのシステム開発プロジェクトでは、要件定義・設計・開発・テストという工程を順番に進める。この場合、発注者が実際に動くシステムを触れるのは、開発がほぼ完了した段階になる。
ここで「思っていたのと違う」が発覚しても、修正のコストは膨大だ。設計レベルで直すべき問題が、完成直前に浮上する。「これ以上の修正はできません」か「追加費用が発生します」という話になる。
発注者にとって「完成品を見てから判断したかった」という感覚は正当だ。しかし、完成してからの根本的な変更は、もう一度作り直すことと変わらない。画面のレイアウトが「思っていたのと違う」という場合でも、それに紐付く処理やデータ構造が変わるなら、前工程に遡っての修正になる。
この問題を防ぐ方法は、「完成前に動くものを確認する機会を作ること」だ。開発の早い段階でプロトタイプを作り、発注者に触らせる。この工程を設けることで、「思っていたのと違う」を安価に修正できる段階で発見できる。
「思っていたのと違う」を防ぐための発注側の準備
業務の例外を書き出す
要件定義の前に、自社の業務で「例外的な処理」を洗い出す作業を行う。「通常はこうだが、このときだけこうする」という条件を、できる限り言語化しておく。この作業は発注者にしかできない。
業務歴の長いスタッフに「これって普通と違う処理はある？」と聞くことが、漏れを防ぐ最善策になる。あるいは、実際に業務を観察しながらヒアリングする方法も効果的だ。言葉で説明できなくても、実際にやっている様子を見れば「そういうことか」と気づけることがある。
この「例外リスト」を開発会社に渡すことで、要件定義の精度が大幅に上がる。「書いていなかったから実装されていなかった」という状況を、事前に防ぐことができる。
変更管理のルールを最初に決める
要件が変わることを前提に、「変更が発生したときのルール」を契約前に取り決める。どの規模の変更から追加費用が発生するか、変更の申請から承認までのフローはどうするか、変更履歴をどこに記録するかを文書化しておく。
これにより、途中の変更をめぐるトラブルが大幅に減る。ルールが明確だと、発注者も「変えたいが言いにくい」という状況がなくなり、早い段階で相談できる。小さな変更を早く伝えることが、修正コストを最小化する。
プロトタイプを要求する
本開発の前に、画面デザインや操作フローを確認できるプロトタイプを作成する開発会社を選ぶ。または、プロトタイプ作成を要件として契約に盛り込む。
動くものを触ることで、「思っていたのと違う」を早期に発見できる。この段階での修正は安い。プロトタイプに費用がかかるとしても、完成後の修正費用と比べれば桁違いに安価だ。
開発会社の選び方を変える
要件通りに作ることを得意とする会社と、業務を一緒に整理することを得意とする会社では、アプローチが根本的に異なる。
小さな会社のシステム開発で重要なのは、「こちらの言葉を聞いて、その裏にある業務の実態を掘り下げてくれる」かどうかだ。提案の場で業務フローについての質問が多い会社は、こちらの「当たり前」を拾う意識が高い。
「何ができますか」と聞いたとき、機能リストだけを返す会社と、「今どんな課題がありますか」と問い返す会社では、プロジェクトの進み方が変わる。前者はオーダー通りに作ることを得意とし、後者は課題解決を目指す。どちらが「思っていたのと違う」を防ぎやすいかは、言うまでもない。
実績や技術力より、「話しながら業務が整理される感覚があるか」を選定の基準にすることで、「思っていたのと違う」を生む構造的リスクを下げることができる。提案段階でこの感覚を持てない会社と長期プロジェクトを進めることは、リスクが高い。
「思っていたのと違う」を経験した後に何をするか
すでに「思っていたのと違う」という経験をしてしまった場合、次に何をするかが重要だ。怒りや落胆で終わらせず、「何が原因でこうなったか」を整理することが、次の発注での改善につながる。
「要件定義の何が漏れていたか」「どの段階で確認の機会があれば防げたか」「変更が発生したとき、どう対処すればよかったか」——この振り返りが、次の発注者としての力になる。一度の失敗を学習に変えることができれば、その経験は高い授業料ではなく、価値のある投資になる。