コストや人件費の高騰が止まらない今の世の中でとにかく安く物事を進めたい気持ちはどの会社でもお持ちでしょう。しかし、はっきり言います。「もう少し安くなりませんか？」という一言は、システム開発において最も危険な交渉に陥るかもしれません。
もちろん、予算内に収めようとすること自体は正しい判断です。問題は、「安くする」という行為がシステム開発においてどういう意味を持つかを、発注者側が理解していないケースがほとんどだということです。
値引き交渉をした結果、完成したシステムが使いものにならなかった——そういう事態が実際に起きています。この記事では、開発会社が「安くしてほしい」と言われたとき、具体的に何を削るのかを正直に解説します。
大前提：システム開発費用の正体
まず知っておいてほしいのは、システム開発の費用の大部分は「人件費」だという事実です。
材料費や製造コストが大半を占める製造業とは異なり、システム開発は人がコードを書き、設計し、テストする「知識労働」です。つまり、費用を削るということは、ほぼ必ず「人の作業時間を削る」ことを意味します。
開発会社が「値引きできました」と言うとき、その裏では必ず何かが削られています。魔法のように安くなることはありません。問題は、何が削られるかです。
削られるもの1：テストの工数
最も削られやすいのが、テストにかける時間です。
システム開発において、テストは地味ですが極めて重要な工程です。「このボタンを押したら正しく動くか」「大量のデータを処理したときに遅くならないか」「セキュリティ上の脆弱性はないか」——こうした確認作業に、本来は開発と同じかそれ以上の時間をかけるべきです。
しかしテストは、発注者の目に見えない工程です。「削っても完成品には影響しないだろう」と判断されやすく、コスト削減の標的になりがちです。
結果として何が起きるか。納品直後から不具合が頻発する、特定の条件下でシステムが止まる、データが正しく処理されないケースが発生する——こうした問題が、実際に使い始めてから次々に発覚します。テストを削ったシステムは、発注者が「人柱」になってバグを発見することになります。
削られるもの2：設計・要件定義の時間
「設計にそんなに時間をかける必要があるの？」と思う発注者は少なくありません。しかし、設計の手抜きは後から必ず大きなコストになって返ってきます。
システム開発における設計とは、建築で言えば「設計図を引く」作業です。設計図なしに家を建てれば、途中で「ここに柱を入れるべきだった」「この部屋が狭すぎた」という問題が発覚し、作り直しに多大なコストがかかります。システム開発も全く同じです。
コスト削減のために設計工数が削られると、開発中に「ここはどう作るべきか」という問題が頻発します。その都度判断しながら進めることになり、品質のばらつきが生まれます。また、後から機能を追加・変更しようとしたとき、設計が甘いシステムは改修コストが跳ね上がります。
削られるもの3：ドキュメント・仕様書の作成
地味ですが、長期的に最も影響が大きいのがドキュメントの省略です。
本来、システム開発では設計書・仕様書・操作マニュアルなどのドキュメントを整備することが重要です。しかしドキュメント作成は時間がかかる割に、完成品には直接反映されないため、コスト削減時に省かれやすい工程です。
ドキュメントがないシステムは、開発した会社しか中身を把握できない「ブラックボックス」になります。担当者が変わったとき、他の会社に保守を依頼したいとき、機能を追加したいとき——こうした場面になって初めて、ドキュメントがないことの深刻さに気づきます。「元の開発会社に頼み続けるしかない」という状況に陥り、その後の保守費用が割高になり続けるケースは非常に多いです。
削られるもの4：細部の作り込みとUI設計
「動けばいい」という方針のもと、操作性や画面設計の作り込みが省かれるケースもあります。
エラーメッセージが意味不明で何をすべきか分からない、入力フォームの使い勝手が悪くミスが起きやすい、画面の動きが直感的でなく毎回マニュアルを見ないと操作できない——こうした問題は、機能としては「動いている」ため、納品時には発覚しにくいです。
しかし、毎日使う社員にとっては深刻なストレスになります。使いにくいシステムは業務効率の向上どころか、かえって現場の負担を増やします。「せっかく導入したのに誰も使いたがらない」という状況は、UI設計への投資を省いた結果として起きることが多いです。
削られるもの5：コミュニケーションの時間
意外に思われるかもしれませんが、打ち合わせや確認の回数も削減対象になることがあります。
本来、システム開発は発注者と開発会社が密にコミュニケーションを取りながら進めるものです。「こちらの意図が正しく伝わっているか」「方向性がズレていないか」を定期的に確認することで、完成後の「思っていたものと違う」を防げます。
しかしコストを削ると、打ち合わせの回数が減り、確認のタイミングが少なくなります。発注者が気づいたときには、想定と大きく異なる方向で開発が進んでいた——こうした事態が起きやすくなります。
「安くする」ための正しい方法
ここまで読んで「では、予算を抑えることは諦めるしかないのか」と思った方もいるかもしれません。そうではありません。費用を抑えるための「正しい方法」は存在します。
方法1：機能を絞る
最初から全機能を作ろうとせず、「本当に必要な機能だけ」に絞って開発することです。機能が少なければ開発工数が減り、自然とコストが下がります。残りの機能は、運用しながら必要になった段階で追加するアプローチが理想的です。
方法2：パッケージやノーコードと組み合わせる
すべてをスクラッチで作らず、汎用的な部分はパッケージやノーコードツールで対応し、自社独自の部分だけをスクラッチで開発するという方法も有効です。全体のコストを抑えながら、必要な部分に予算を集中させられます。
方法3：優先順位を明確にして交渉する
「どの機能が絶対に必要で、どの機能は後回しにできるか」を明確にした上で、開発会社と一緒に優先順位を整理することです。「全体を安くしてほしい」ではなく「この機能はフェーズ2に回せないか」という交渉は、品質を落とさずにコストを調整できる正しいアプローチです。
まとめ：「安くしてほしい」の一言が、後から高くつく
システム開発の値引き交渉は、短期的にはコストが下がりますが、長期的には必ずどこかで代償を払うことになります。テストを省いたシステムはバグだらけになり、設計を省いたシステムは改修のたびに費用がかさみ、ドキュメントを省いたシステムは保守費用が高止まりします。
「安くする」ことと「コストパフォーマンスを上げる」ことは、全く別の話です。本当に賢いコスト管理とは、削ってはいけないものを守りながら、機能の優先順位を整理することです。
「予算内でどこまで実現できるか相談したい」という段階からでも、シスナビでは丁寧にヒアリングを行い、予算と品質のバランスを取った最適なご提案をします。まずはお気軽にご相談ください。