【5000万のドブ捨てを防ぐ】システム会社に発注する前に、経営者が絶対に紙に書くべき5つの決定事項

2026.08.10

「そろそろ基幹システムを入れ替えたい」

そう考えたとき、多くの企業が最初に始めるのが「システム会社探し」です。
付き合いのあるシステム会社へ相談する。何社かに声をかける。提案を受ける。見積もりを比較する。

一見、正しい進め方に見えます。しかし、私たちはむしろその前にやるべきことがあると考えています。
それは、経営として「5つのこと」を決めることです。

難しいITの話ではありません。この先に書いてある5項目を見れば、おそらく「そんなことは当たり前だ」と思われるでしょう。

その通りです。

問題は、当たり前なのに、実際のプロジェクトでは決まっていないことが驚くほど多いことです。
そして、いざ自社のこととして紙に書こうとすると、どこかでペンが止まります。

そこに、数千万円のシステム投資を失敗させる「芽」が隠れています。

5000万円を失うのは、「悪いシステム会社を選んだから」とは限らない

システム開発がうまくいかなくなると、次のような原因が挙げられます。

「ベンダの力量が足りなかった」
「要件定義が甘かった」
「プロジェクト管理が悪かった」

もちろん、それらが原因になることもあります。しかし、もう一つ見落とされやすい原因があります。

発注側が決めるべきことが、決まっていない。という問題です。

例えば、こんなことが起こります。

営業部門は「顧客ごとの例外対応は絶対に残したい」と言う。
管理部門は「例外を残したら、今回の標準化の意味がない」と言う。
プロジェクト責任者は「どちらにも一理ある」と考える。
システム会社は「どちらでも作れます。ただし、例外対応を残す場合は追加費用と開発期間が必要です」と答える。

さて、誰が決めるのでしょうか。

これは、システムの仕様に見えます。しかし本質は、顧客ごとの柔軟性を優先するのか、全社標準化を優先するのかという経営判断です。

ここが決まっていなければ、プロジェクト責任者にもシステム会社にも正解は出せません。誰も悪くありません。それでもプロジェクトは止まります。

そして、止められない場合は「とりあえず両方できるようにしましょう」となる。こうして機能が増えます。見積もりが増えます。開発期間が延びます。

5000万円のシステムが失敗するのは、5000万円分のプログラムが悪かったからとは限りません。

5000万円を使って何を変え、何を捨てるのかを決めないまま、作り始めてしまった。こちらの方が根深い問題であることがあります。

ただし、経営者が現場の仕様を決めるわけではない

ここは誤解していただきたくないところです。経営者が、

「この入力項目をなくそう」
「このExcelを廃止しよう」
「この画面はこうしよう」

と現場のオペレーションまで決める、という話ではありません。

中堅以上の企業になれば、経営者が現場業務の詳細まで把握していないのは当然です。仮に知っていたとしても、細かな業務判断は部門責任者やプロジェクト責任者へ委ねるべきでしょう。

むしろ経営者が細部まで口を出せば、責任者の権限を奪い、意思決定を遅くすることさえあります。

経営者が決めるべきなのは、個々の仕様ではありません。現場が迷ったときに戻ることのできる「判断の物差し」です。

その物差しを5つに整理してみます。

決定事項1 ― この投資で「会社として何を変えるのか」

最初に決めるべきなのは、「どんなシステムを作るのか」ではなく、「この投資によって会社として何を変えるのか」です。例えば、

各部門の個別最適から全社最適へ転換する
特定社員への業務依存を減らす
今後の事業拡大に耐えられる業務基盤へ変える
人を増やさなくても処理量を増やせる会社にする

といったことです。ここは経営者が示すべき領域です。

その方針を受けて、どの業務を変えるのか、どのExcelをなくすのか、どの処理を自動化するのかを部門責任者やプロジェクトチームが考えます。

順番を逆にしてはいけません。

【匿名事例】「古いから刷新する」で始まったプロジェクト

ある企業では、長年利用してきた基幹システムの老朽化を理由に刷新プロジェクトが始まりました。現行システムには使いにくいところも多く、現場からも改善要望が多数出ていました。そこで各部門から要望を集め、新システムの要件へ反映していきました。

ところが途中で、ある疑問が出てきました。

「ところで、この刷新によって会社は何を変えたいのでしょうか？」

すぐには答えが出ませんでした。システムが古い、保守が難しい、現場から不満が出ている――それらは確かに問題です。

しかし、「全社業務を標準化したいのか」「現行業務を維持したままシステムだけ新しくしたいのか」「将来の事業拡大を見据えて業務自体を作り直したいのか」によって、作るべきシステムはまったく違います。

目的が曖昧なまま現場要望を集めると、古いシステムで行っていた仕事を、新しいシステム上に忠実に再現することになりかねません。

システムは新しくなった。しかし会社の仕事は何も変わらない。数千万円を投じても、それでは「刷新」と呼べるのか。

最初に経営が決めるべきなのは、システムの機能ではなく、今回の投資で会社の何を変えるのかなのです。

決定事項2 ― 部門から例外要望が出たとき、「何を基準に却下（見送り）するのか」

２つ目は、「何をやらないか」ではなく、「何を基準にやらないと判断するのか」です。ここは非常に重要です。

大きなシステム開発では、各部門から必ず要望が出ます。

営業には営業の事情があります。
経理には経理の事情があります。
物流にも事情があります。
そして、一つ一つ聞けば合理的です。

だから、プロジェクト責任者は困ります。「この機能はいりません」と感覚で切るわけにはいかないからです。

そこで経営が決めておくべきなのが「判断原則」です。例えば、

「今回の刷新では部門最適より全社標準化を優先する」
「既存業務をそのまま残すためだけの個別開発は原則行わない」
「法令・顧客契約上必要な例外と、単なる慣習を区別する」
「追加開発する場合は、効果と費用を比較して判断する」

こうした原則です。これがあれば、プロジェクト責任者は個々の要望を判断できます。経営者が一件一件の仕様を裁く必要はありません。

【匿名事例】「せっかくだから」が積み重なったプロジェクト

あるプロジェクトでは、当初は業務標準化を大きな目的としていました。ところが要件整理を始めると、各部門から例外要望が次々と出てきました。

「この顧客だけ処理が違う」
「この拠点では昔からこの帳票を使っている」
「このExcelがなくなると困る」

どれも現場からすれば切実です。一つずつ見れば、追加する理由があります。

そして会議では、「せっかく新しくするのだから、対応しておきましょう」という判断が繰り返されました。結果として仕様が膨らみ、追加費用の話が出始めました。

ここで問題になったのは、「この機能にいくらかかるか」ではありませんでした。そもそも、どんな要望なら断るのかという基準がなかったことでした。

「全社標準化を優先する」という経営方針が明確なら、「今までそうしていたから」だけでは個別開発を認めないという判断ができます。逆に、重要顧客への競争力として例外対応が必要なら、そこには投資する。

仕様を決めるのは現場でも、仕様を決めるための物差しは、経営が用意する必要があります。

決定事項3 ― 300万円の追加仕様を「誰が決めるのか」

３つ目は、意思決定権限です。プロジェクトでは必ず予定外のことが起こります。

例えばベンダから、「この要望を実現する場合、追加で300万円、納期が3週間延びます」と言われたとします。
さて、誰が決めるのでしょうか。

プロジェクト責任者でしょうか。
担当役員でしょうか。
経営会議でしょうか。
社長でしょうか。

問題は金額そのものではありません。どのレベルの判断を、誰に委ねるのかです。

すべてを社長決裁にすればプロジェクトは止まります。
逆に、すべてを現場へ委ねれば、気づいたときには予算もスコープも大きく変わっているかもしれません。

例えば、

「予算内の仕様変更はプロジェクト責任者」
「一定額以上の追加費用は担当役員」
「総予算や経営方針に影響する変更は経営会議」

というように、判断の階層を決めておく。経営者が決めるべきなのは個々の仕様ではありません。
誰に、どこまで決める権限を渡すのかです。

【匿名事例】誰も決められず、3週間止まった

あるプロジェクトで、部門間の要望が衝突しました。どちらを採用してもシステムは作れます。
ただし、一方を採用すると追加開発が必要でした。

プロジェクト責任者は、「これは自分の権限で決めてよいのだろうか」と迷いました。
担当役員へ上げると、「現場の話だから、プロジェクトで決めてほしい」と言われました。

プロジェクトへ戻すと、「これは費用にも影響するので、経営判断ではないか」となりました。
再び役員へ上げる。そんなやり取りをしている間にも、ベンダは判断を待っています。

結果として、意思決定までに約3ヵ月を要しました。

開発能力の問題ではありません。技術問題でもありません。
誰が決めるかを決めていなかったために、プロジェクトが止まったのです。

この「意思決定待ち」は、大規模なプロジェクトほど見えにくいコストになります。

決定事項4 ― 自社とシステム会社の「責任の境界線」をどこに引くのか

４つ目は、システム会社へ何を任せ、自社が何を決めるのかです。

システム会社は専門家です。
技術方式、システム設計、開発方法、インフラ構成、セキュリティ対策。
こうした領域では専門家の知見を最大限活用すべきです。

一方で、
「営業と管理のどちらを優先するのか」
「この業務を残すのか変えるのか」
「追加費用を払ってまでこの要望を実現するのか」
といったことは、技術判断ではありません。
経営・業務判断です。

それでもプロジェクトでは、「システム会社さんとしては、どちらがいいと思いますか」と聞いてしまうことがあります。

もちろんベンダは答えてくれます。
しかし、それは技術的に合理的な答えであって、御社の経営として正しい答えとは限りません。

発注側が判断を委ねすぎると、後になって「そんなつもりではなかった」となる。
ベンダ側は「ご要望に基づいて作りました」となる。
どちらも間違ったことを言っていません。それでもプロジェクトは失敗します。

必要なのはベンダを厳しく管理することではありません。
ベンダに専門家としての力を最大限発揮してもらうために、責任境界を明確にすることです。

決定事項5 ― システム完成後、「経営として何が変われば成功なのか」

最後はゴールです。ただし、「予定通りシステムが稼働した」ではありません。
それはプロジェクトとしての完成であって、経営投資としての成功とは限りません。

例えば、

「売上が増えても管理部門の人数を比例して増やさなくてよい」
「月次の経営数字を従来より早く把握できる」
「特定社員が不在でも重要業務が止まらない」
「拠点ごとにバラバラだった業務を共通化する」
「新しい事業を始めても現在のシステムが制約にならない」

といった会社の変化です。
これを経営が示す。

そしてプロジェクト側が、
「では、その状態を実現するには業務をどう変えるべきか」
「システムとして何が必要なのか」
へ落とし込む。

この順番です。

5つとも「当たり前」です。それでも紙に書けない

ここまでの5つを整理します。

この投資で会社として何を変えるのか
何を優先し、何を捨てるのかという判断原則
誰にどこまで決める権限を与えるのか
自社とシステム会社の責任境界をどこに置くのか
完成後、経営として何が変われば成功なのか

特別な経営理論ではありません。
むしろ、「そんなの当たり前だ」と思われる内容ばかりでしょう。

では、一度A4の紙に書いてみてください。おそらく、どこかでペンが止まります。

「全社標準化と言っても、重要顧客の例外まで切っていいのか」
「プロジェクト責任者に、どこまで予算権限を与えるべきか」
「これはベンダに任せる判断なのか、こちらで決めることなのか」
「そもそも今回の投資で、経営として何を一番変えたいのか」

こうした問いが出てきます。
そのペンが止まった場所こそ、発注前に整理しておくべき場所です。

なぜ経営者一人では書けないのか

これは経営者が現場を知らないからではありません。
むしろ、知らなくて当然です。中堅以上の企業になれば、経営者が個々の業務オペレーションを把握している方が稀でしょう。

だから、現場から情報を上げてもらう必要があります。
ところが、ここで難しさが生まれます。

営業には営業の正義があります。
管理部門には管理部門の正義があります。
現場には現場の事情があります。
システム部門にはシステム部門の事情があります。
既存ベンダには既存システムを知っているからこその見方があります。
新しいベンダには新しい技術から見た提案があります。

誰か一人が間違っているわけではありません。立場によって見えている景色が違うのです。

経営者に必要なのは、それらすべての業務を理解することではありません。
情報を整理したうえで、「会社としてどちらへ進むのか」を判断することです。

そのためには、経営判断できる形まで論点を引き上げる役割が必要になります。

「この機能を入れますか？」では、経営者は判断できない

例えば経営会議へ「○○機能を追加するかどうか決めてください。費用は300万円です」と上げても、経営者は判断しにくいでしょう。その機能の詳細を知らないからです。

しかし、次のように整理されていればどうでしょう。

「現在、顧客ごとに異なる例外処理があります。これを残す場合は約300万円の追加開発が必要です。
廃止する場合は業務を標準化できますが、一部顧客について営業側で運用変更が必要になります。
今回掲げている『全社標準化』を優先するなら開発しない選択になります。
一方、この顧客対応を競争力として維持するのであれば、300万円を投資する意味があります」

これなら経営判断できます。
これこそが、技術の話を、経営が判断できる話へ翻訳するということです。

私たちが「発注前」から支援する理由

オーシャン・アンド・パートナーズでは、システム会社へ発注する前の段階からご相談を受けることがあります。
いきなり仕様書を書くわけではありません。まず、

「今回の投資で何を実現したいのか」
「現場では何が問題になっているのか」
「どこまでが業務の問題で、どこからがシステムの問題なのか」
「どの論点を現場へ委ね、どこから経営判断にするのか」

を整理します。
私たちが経営判断を代行するわけではありません。
また、現場に代わって業務を決めるわけでもありません。

経営、現場、システム部門、ベンダ。それぞれから情報を集め、論点を分け、選択肢を整理し、経営が判断すべきことを、経営が判断できる形にする。

それが発注側支援の重要な役割だと考えています。

5000万円のシステムより、最初のA4一枚が重要かもしれない

1000万円。3000万円。5000万円。基幹システムなら、それ以上。
システム投資には大きなお金が動きます。

しかし、数千万円の見積書が出ているにもかかわらず、
「この投資で何を変えるのか」
「何を優先するのか」
「誰にどこまで権限を与えるのか」が明文化されていないことがあります。

これは順番が逆です。

まずA4の紙に、今回の5つを書いてみてください。
全部きれいに書けなくても構いません。むしろ、ペンが止まって当然です。

問題なのは、止まることではありません。
止まったまま5000万円を発注することです。

システムを作る前に、経営としての判断軸を作る。
システム会社を探すのは、その後でも遅くありません。

システム会社へ発注する前の「判断整理」からご相談いただけます

「5つを書いてみたが、途中で止まった」
「部門ごとに主張が異なり、経営として何を判断すべきか整理できない」
「ベンダから提案を受けているが、このまま発注してよいのか判断に迷っている」
「数千万円規模の投資になるため、発注前に一度第三者の視点を入れたい」

こうした段階からでも、ご相談いただけます。

オーシャン・アンド・パートナーズでは、いきなりシステムを作ることから始めるのではなく、発注側が何を判断すべきなのかを整理し、経営・現場・ベンダそれぞれの役割を明確にするところからご支援しています。

システム構想、要件整理、RFP作成、ベンダ選定、プロジェクト推進まで、発注側の立場で伴走します。
数千万円を発注してから軌道修正するより、発注前に一度整理する。

「まだシステム会社へ相談するほど具体化していない」という段階でも構いません。
まずは現在のお悩みをお聞かせください。システム構想策定・発注前支援について詳しく見る

ご相談はお問い合わせフォームより承っております。

あわせて読みたい関連記事

DXが失敗する会社は、システム会社へ相談する順番を間違えている

「まずシステム会社へ相談する」という進め方そのものに潜む問題を、発注側の視点から解説しています。今回の記事で紹介した「発注前に経営判断を整理する」という考え方を、もう少し広い視点から知りたい方にこちらの記事もおすすめです。

システム内製化で最初に作るべきものはシステムではない｜3社に共通する成功法則

システム内製化に成功している企業に共通するのは、単にエンジニアを増やしたことではありません。経営、業務、ITの役割をどう整理し、自社で意思決定できる状態を作るのか、その考え方をこちらの記事で紹介しています。

システム内製化支援サービス

「ベンダへ丸投げする」のでも、「すべて自社で抱える」のでもなく、自社に必要な判断力と推進力を残していくための支援サービスです。発注側としてプロジェクトを主体的に進めたい企業様はシステム内製化支援サービスもご覧ください。

この記事を書いた人について

谷尾薫: オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。