なぜ一般的なシステム開発会社に頼むと「思っていたのと違う」が起きるのか

「思っていたのと違う」。

システム開発を経験した中小企業の経営者から、最もよく聞く感想がこれだ。費用も時間もかけたのに、届いたものを触ったとき、なんか違う、という感覚。そのギャップがどこから来るのかを、今日は正直に書きたい。

一般的なシステム開発会社の構造

多くのシステム開発会社は、「要件定義 → 設計 → 開発 → テスト → 納品」という流れで仕事をする。ウォーターフォールと呼ばれる手法だ。

この流れ自体は悪くない。大規模なシステムを複数のチームで作るときには理にかなっている。でも、従業員10〜30人規模の中小企業が、自社業務のシステムを作るときには、しばしばミスマッチが起きる。

最初に「要件定義」の打ち合わせが数回ある。「どんな機能が必要ですか」「どういう流れで業務を行いますか」と聞かれ、経営者や担当者が答える。それが文書化されて「仕様書」になる。

ここで最初のズレが生まれる。業務は言葉で説明しきれない部分がある。頭の中では「これくらいわかるだろう」と思いながら話したことが、受け取った側には違って伝わる。仕様書は言語の産物であり、業務の現実を完全には映せない。

「変更は追加費用」の構造が生むもの

仕様書が確定すると、開発が始まる。この時点から、変更はコストがかかる。

「やっぱりこの画面、こうしてほしい」「この項目、必要なかった」——開発途中でこういう気づきが出てきても、「仕様変更は追加費用が発生します」と言われる。当初の見積もりよりも高くなっていく。

これは開発会社が意地悪をしているわけではない。仕様書に基づいて人を動かし、スケジュールを組んでいるから、途中変更はコストが増えるという構造だ。ただ、依頼した側にとっては、「使ってみて気づいたことを反映できない」という体験をすることになる。

そして納品される。動いている。バグもない。でも、「なんか違う」という感覚は消えない。仕様書通りに作られているが、自分たちの業務の感覚とは微妙にずれている。その微妙なズレが積み重なって、「思っていたのと違う」になる。

インセンティブのずれという根本問題

もう少し根本的な話をすると、一般的なシステム開発会社のビジネスモデルは「プロジェクト単位で受注・納品する」形だ。

つまり、納品した後のことはインセンティブに含まれていない。「現場で本当に使われているか」「3ヶ月後に業務効率が上がっているか」は、基本的には関係ない。納品して検収を取れれば、プロジェクトは完了だ。

これはビジネスモデルの問題であり、担当者個人の問題ではない。ただ、依頼する側からすると、「使えるものを作りたい」という目的と、「作って納品する」という相手の目的は、完全には一致していない。

この構造的なずれが、「思っていたのと違う」という結果を何度も生んでいる。

必要なのは「仕様書の正確さ」ではなく「触りながら育てる」プロセス

では、何が違えばいいのか。

ひとつは、作る前に触れる機会を持つことだ。完成品を待つのではなく、動く仮のものを早い段階で触って、「ここが違う」を先に出してしまう。言葉で伝えるより、触って気づく方が早くて正確だ。

もうひとつは、納品後も一緒に育てられる関係を持つことだ。業務は変わる。スタッフが変わり、取引先の要望が変わり、やり方が変わる。システムがその変化に追いつけなければ、また「使われなくなる」が起きる。稼働後も改善を続けられる開発体制が、中小企業には特に必要だ。

オルアナが大切にしているのは、まさにこの二点だ。契約前に1〜2週間でプロトタイプを作り、触って「これだ」と思えてから正式に動き出す。そして稼働後も、業務の変化に合わせて機能を追加・改善し続ける。

「思っていたのと違う」という体験は、プロセスの設計で防げる。そのことを、もっと多くの経営者に知ってほしいと思っている。