便利なシステムが会社を弱くする｜「現場改善」と「経営設計」はなぜ違うのか
はじめに
「現場が使いやすいシステムを作りたい。」ITシステムの導入や刷新プロジェクトでは、ごく自然に語られる言葉です。
- 入力を減らしたい
- 画面を分かりやすくしたい
- 帳票を見やすくしたい
- 今の運用を変えたくない
これらはすべて現場にとって重要な要望です。システムは毎日使うものですから、使いにくければ定着しません。だから現場の声を聞くことは必要です。
しかし私は、20年近く企業のITプロジェクトを支援する中で、一つの疑問を持つようになりました。「便利なシステム」を目指したはずなのに、なぜ経営は以前より見えにくくなってしまう企業が少なくないのか。
その原因は、技術でもベンダーでもERPでもありません。もっと根本的な問題があります。それは、ITシステムを「何のために導入するのか」という目的そのものが、プロジェクトの途中ですり替わってしまうことです。
本来、ITシステムが最も得意とすることは何でしょうか。それは業務を便利にすることではありません。データを集約し、組織全体を可視化し、経営判断を迅速化し、会社全体を同じ方向へ動かすこと——つまり、ITシステムとは、会社の判断力を高めるための仕組みなのです。
今回は、「便利なシステム」が、なぜ会社を弱くすることがあるのか。その背景について考えてみたいと思います。
IT投資の目的は、なぜすり替わってしまうのか
システム導入を検討し始めた頃、経営者の頭の中には大きな目的があります。
- 会社全体の状況をリアルタイムに把握したい
- 事業ごとの利益を見えるようにしたい
- データを経営判断に活かしたい
- 部門ごとに分散している情報を統合したい
- 将来の事業拡大にも耐えられる仕組みにしたい
つまり、出発点は「経営」です。ところがプロジェクトが始まると、議論は少しずつ変化していきます。
- 「この画面は今のままがいい」
- 「入力項目を減らしたい」
- 「この帳票だけは残したい」
- 「今の運用は変えられない」
こうして議論の中心は、経営から業務へ、会社全体から部門へと移っていきます。気付けば「会社を強くするシステム」ではなく、「現場が困らないシステム」を作ることがプロジェクトの目的になっています。
これは決して誰かが悪いわけではありません。現場には現場の事情があります。ベンダーも顧客の要望に応えようとします。情報システム部門も現場との調整に追われます。しかし、その積み重ねが、本来の目的を少しずつ遠ざけてしまうのです。
私はこれを「目的のドリフト（目的の漂流）」と呼んでいます。プロジェクトが進むほど、本来目指していたゴールから少しずつ離れてしまう現象です。実は、多くのITプロジェクトが苦戦する理由は、技術的な難しさよりも、この「目的のドリフト」にあります。
「現場の要望を聞くこと」と「経営判断」は違う
誤解してほしくないのですが、私は現場の声を軽視しているわけではありません。むしろ現場を知らないシステムは必ず失敗します。しかし、現場の要望を集めることと、経営として判断することは、まったく別の行為です。
営業部は営業部として正しい。経理部は経理部として正しい。物流部は物流部として正しい。製造部も、人事部も、それぞれ合理的な理由があります。だから要望を聞けば聞くほど「全部正しい」という状況になります。しかし、会社全体として見ると、そのすべてを採用することが正解とは限りません。
例えば、営業部は自由な値引きを望みます。経理部は統制を強めたいと考えます。製造部は柔軟な個別対応を求めます。品質管理部は標準化を重視します。それぞれの要望をそのまま実現すると、システムは複雑になり、会社全体の統制は弱まります。
ここで必要なのが「経営判断」です。経営とは、全員の要望を実現することではありません。
- どこを標準化するのか
- どこを例外として認めるのか
- どこで将来性を優先するのか
- どこで現場の負担を受け入れるのか
その優先順位を決めることが経営の役割であり、システムはその判断を形にした結果であるべきです。しかし現実には、要望の積み上げがそのままシステムになってしまい、気づいた瞬間からシステムは経営のためではなく、各部門のためのものになってしまうのです。
なぜ日本企業は「便利さ」を追求してしまうのか
日本企業の現場改善文化を否定したいわけではありません。むしろその逆です。日本企業が世界で高い品質を実現してきた背景には、現場を大切にする文化があります。現場が改善点を見つけ、小さなムダを減らし、作業を少しずつ改善する——いわゆる「カイゼン」の積み重ねです。この文化は、日本企業の大きな競争力でした。
だからこそ、システム導入でも「現場の声を聞こう」という発想になるのは自然なことです。実際、それ自体は間違いではありません。問題は、ITシステムでは改善のルールが少し違うということです。
工場は「足し算」で強くなる
製造現場では、工具の配置を変える、作業台の高さを変える、動線を短くする——こうした改善は、他の工程を壊すことなく全体の効率も高められることが多いでしょう。改善を積み重ねるほど、工場全体も強くなります。
ITシステムは「引き算」で強くなる
しかしITシステムは違います。営業部の要望を追加すると経理部は複雑になります。物流の例外処理を追加すると在庫管理が難しくなります。製造の独自ルールを追加すると標準化が崩れます。ITでは一つの改善が、全体から見ると複雑性になることがあります。
だからITシステムでは、足し算だけでは強くなりません。むしろ、
- 何をやめるか
- 何を標準化するか
- 何を共通ルールにするか
という引き算の発想が必要になります。
現場改善の思想と経営設計の思想は違う
現場改善は現場を良くする活動です。一方、経営設計は会社全体を最適化する活動です。似ているようで、実は目的が違います。だから現場改善を積み重ねるだけでは、強いシステムにはなりません。
そしてここに、日本企業が陥りやすいもう一つの落とし穴があります。日本企業は「改善」は得意ですが、「捨てる」ことは苦手です。
現場から「この帳票は必要」と言われれば「では残しましょう」となります。別の部門から「この例外処理も」と言われれば「では追加しましょう」となります。しかし、誰も「それはやめましょう」とは言いません。なぜなら、現場の声を否定することになるからです。
しかし、経営とは全てを採用することではありません。何を残し、何を捨てるかを決めることです。その判断なくして、会社全体に機能する強いシステムは生まれません。どこかで「会社としてはこちらを選ぶ」という経営判断が必要になります。その判断を行うためにあるのが、構想策定です。
ITシステムは、民主主義で設計してはいけない
少し挑発的な言い方をします。ITシステムは、多数決で設計してはいけない。
現場全員の要望を集め、全員を満足させようとすると、システムは必ず複雑になります。なぜなら、それぞれの部門にとっての「最適」は異なるからです。全員の要望を並べれば並べるほど、互いに矛盾し、全体として機能しないシステムが出来上がります。
だから最後には、経営が「会社としてはこちらを選ぶ」と判断しなければなりません。これは現場を無視することではありません。会社全体の最適を、経営の責任として決断することです。現場の声を聞いた上で、それでも「やらない」と決める勇気——それこそが、システム導入における経営判断の本質です。
「要件定義」と「構想策定」は違う
ITプロジェクトでは「要件定義が最も重要だ」と言われることがあります。確かに要件定義は重要です。しかし私たちは、その前にもっと重要な工程があると考えています。それが構想策定です。
要件定義とは、「何を作るか」を決める工程です——必要な機能は何か、どのような画面・帳票・データが必要か。いわばシステムの仕様を定める工程です。
一方、構想策定で考えるのは、その前段階にある問いです。
- そもそも、何のためにそのシステムを作るのか
- 経営として、どのような会社を目指すのか
- そのために、どのような情報が必要なのか
- 何を標準化し、何を差別化するのか
- どこまで現場に合わせ、どこから会社全体のルールを優先するのか
これらは、システムの機能ではなく、経営の意思そのものです。つまり、要件定義は「HOW」を決める工程であり、構想策定は「WHY」と「WHAT」を決める工程なのです。
ところが、日本企業ではこの順序が逆転してしまうことがあります。「画面はどうするか」「帳票はどうするか」「今の運用をどう再現するか」という議論から始まり、「なぜそのシステムを導入するのか」という根本的な問いが置き去りになってしまうのです。その結果、システムは完成しても、経営課題は解決されないという状況が生まれます。
ケーススタディ──ERP導入で起きる「静かな失敗」
この問題が最も分かりやすく現れるのが、ERP導入プロジェクトです。ERPは、販売・購買・生産・在庫・会計などを一つのデータベースでつなぎ、会社全体を統合的に管理するための仕組みです。つまり「部分最適」ではなく「全体最適」を実現するためのシステムです。だからこそ、多くのERPベンダーは「標準機能を活用してください」と勧めます。標準機能には、多くの企業で培われた業務のベストプラクティスが組み込まれているからです。
ところが、実際のプロジェクトでは次のようなやり取りが始まります。
- 営業部：「この入力画面は今のままにしてほしい」
- 経理部：「この帳票だけは変えられない」
- 製造部：「この業務だけは特殊だから例外にしてほしい」
一つひとつの要望には、もっともな理由があります。そしてベンダーも、プロジェクトを成功させたいという思いから、それらに応えようとします。その結果、カスタマイズ、アドオン開発、独自マスタ、独自コード体系、独自帳票、独自ワークフローが少しずつ積み上がっていきます。
プロジェクトの途中では「現場の要望に応えられている」という安心感があります。しかし完成して振り返ると、ERPを導入したはずなのに、出来上がったのは「現行システムを最新技術で再現しただけ」のシステム——ということが起きます。
これはERPそのものの失敗ではありません。便利さを優先し、標準化を後回しにした結果です。もっと言えば、「要件定義」は丁寧に行われたものの、「構想策定」が十分に行われなかった結果とも言えるでしょう。
本当に失われたものは何か
こうしたプロジェクトでは「カスタマイズ費用が増えた」「導入期間が延びた」という点が問題視されます。もちろん、それも経営上の問題です。しかし私たちはそれ以上に大きなものを失っていると考えています。それは、会社全体を一つの視点で見るという思想です。
本来、ITシステムの価値はデータを集約し、経営判断を支えることにあります。営業・購買・生産・在庫・会計が一つにつながるからこそ、「売上は伸びているのに利益が下がっている理由」「在庫が増えた原因」「顧客ごとの収益性」といった情報をリアルタイムに把握できます。
ところが、個別最適を積み重ねると、部門ごとに異なるコード体系や管理方法が生まれ、再びデータは分断されます。システムは新しくなった。画面もきれいになった。入力もしやすくなった。しかし、経営者が見たい情報は以前と変わらず見えない。これは、本来得られるはずだったIT投資の価値を、自ら手放してしまっている状態です。
だからこそ私たちは「何を作るか」を議論する前に、「何を実現したいのか」を整理する構想策定が不可欠だと考えています。システムは、現場の要望を積み上げて完成するものではありません。経営として何を目指すのかという意思を形にした結果として、初めて価値あるシステムになるのです。
「便利なシステム」は評価される。「判断しやすいシステム」は評価されない。
では、なぜこのようなことが起こるのでしょうか。理由の一つは、「便利」は目に見えやすく、「判断」は目に見えにくいからです。
例えばシステムを刷新すると、「入力時間が30％短縮された」「クリック数が半分になった」「帳票作成が自動化された」といった成果は非常に分かりやすく評価できます。現場も実感しやすく、プロジェクトの成果として説明しやすいでしょう。
一方で、「経営判断が速くなった」「事業別の利益が毎日把握できるようになった」「問題の兆候を1週間早く発見できるようになった」という成果は、数値として表現しにくく、評価されにくい傾向があります。しかし本当に会社の競争力を高めるのは、どちらでしょうか。
IT投資のROIは「工数削減」だけでは測れない
IT投資の効果を説明する際、多くの企業ではROI（投資対効果）が用いられます。その計算式には、人件費削減・作業時間削減・紙や印刷コストの削減・保守費用の削減といった項目が並びます。もちろん、それらも重要です。しかしそれだけではIT投資の価値を十分に表しているとは言えません。
例えば、受注情報と在庫情報がリアルタイムに連携された結果、在庫過多の兆候を一か月後ではなく一週間後に把握できるようになったとしたらどうでしょうか。顧客別の利益率を月次ではなく日次で確認できるようになり、不採算案件への対応を早められたとしたらどうでしょうか。複数部門に散らばっていた情報が一元化され、経営会議で「数字が違う」という議論に時間を費やすことがなくなったとしたらどうでしょうか。
これらは人件費削減には換算しにくい効果ですが、企業価値への影響は決して小さくありません。むしろ経営という視点で見れば、こちらの方がはるかに大きな価値を持つ場合があります。私たちは、こうした「意思決定の質と速度」こそROIの中心に据えるべきだと考えています。
「判断速度」は競争力そのものである
市場環境の変化は、年々速くなっています。原材料価格の高騰、人手不足、法改正、顧客ニーズの変化、新たな競合の参入——こうした変化に対して、企業が持つ最大の武器は何でしょうか。
情報量でも、優れたシステムでもありません。最終的に会社の未来を決めるのは、「いつ判断できるか」です。同じ情報を持っていても、一週間早く判断できる会社と、一か月後にようやく気付く会社では、結果は大きく変わります。
ITシステムの役割は、情報を集めることではありません。経営者が「今、判断できる状態」をつくることです。だからこそ私たちは、IT投資の本質を「判断速度への投資」と考えています。
ITシステムは「経営の神経網」である
私は、ITシステムを「経営の神経網」だと考えています。人間は、目や耳、皮膚などから得た情報を神経が脳へ伝えます。脳はその情報を基に判断し、神経を通じて身体へ指示を出します。もし神経が途中で切れていたら、身体のどこかで異常が起きても脳はそれを知ることができず、脳が指示を出してもその指示は現場まで届きません。
企業も同じです。営業・製造・購買・物流・経理——それぞれの現場から集まる情報を経営へ届け、経営の判断を組織全体へ伝える。その役割を担うのがITシステムです。だから私は、ITシステムを単なる業務効率化ツールとは考えていません。企業の神経網であり、経営そのものを支える基盤だと考えています。
神経が途中で断ち切られた身体が正常に機能しないように、部門ごとにデータが分断されたままのシステムでは、経営の神経網としての役割を果たせません。統合されたデータ基盤こそが、会社全体を一つの生き物として動かす力になるのです。
システム構想とは「会社の判断基準」を設計することである
ここまで見てきたように、ITシステムの価値は機能の多さでも、現場の要望をどれだけ実現したかでもありません。本当に重要なのは、会社として何を見て、何を判断し、どのように行動するかを設計することです。
だからこそシステム構想では、最初に「画面」や「帳票」を議論するべきではありません。最初に整理すべきなのは経営そのものです。私たちは構想策定の場で、次のような問いを経営者と一緒に考えます。
- 会社として、最も重要な経営指標は何か
- どの数字を「唯一の真実」とするのか
- どの業務は標準化し、どこに競争力を残すのか
- 5年後・10年後の事業を支えるために、今どのようなデータを蓄積すべきか
- このシステムによって、経営者は何をより早く判断できるようになるのか
これらの問いに答えないまま要件定義へ進めば、システムは作れます。しかし、「会社を強くするシステム」は作れません。システム構想策定とは、画面設計ではありません。会社の判断基準を設計することなのです。
そしてもう一つ、重要な視点があります。多くの人は、構想策定とは「何を追加するか」を決める工程だと思っています。しかし違います。構想策定とは、「何を追加しないか」を決める工程です。
- この業務は標準化する
- この例外処理は廃止する
- この帳票はなくす
- このコード体系は統一する
- このデータだけを経営指標にする
つまり、会社としてどこで引き算をするかを決める工程なのです。引き算を決める覚悟があってはじめて、システムは経営の武器になります。
「便利なシステム」は作れます。しかし、それだけでは会社は強くなりません。本当に強い会社とは、変化を早く捉え、早く判断し、早く行動できる会社です。
IT投資の本当の目的は、現場の作業時間を数分短縮することではありません。会社全体の判断力を高めることです。システムとは単なる業務効率化ツールではなく、経営の神経網であり、経営判断を支える基盤です。そして構想策定とは、「何を作るか」を決める工程ではなく、「どのような会社をつくるのか」という経営の意思を、システムという形に落とし込むプロセスなのです。
何を作るかより、何を作らないか。何を追加するかより、何を捨てるか。その決断こそが、システム導入を「投資」にするか「コスト」にするかを分ける分岐点です。
システム導入の前に、「何を作るか」ではなく「何を判断したいか」を整理しませんか？
システム導入や基幹システム刷新では、多くの場合、要件定義からプロジェクトが始まります。しかし、その前に整理すべきことがあります。それは、経営として何を実現したいのかという構想です。
「現場の要望をどう整理すべきか分からない」「標準化とカスタマイズの判断基準に悩んでいる」「システム導入の目的が曖昧なまま要件定義が始まってしまった」——こうした状況では、システムそのものではなく、構想を見直すことが重要です。
オーシャン・アンド・パートナーズでは、特定の製品やベンダーに依存しない第三者の立場から、経営課題を整理し、「何を実現するためのシステムなのか」という構想策定を支援しています。機能の議論に入る前に、経営として何を判断し、どのような会社を目指すのか。その設計図から、一緒に整理してみませんか。
▶ 関連サービス：システム構想策定支援
▶ 関連コラム：「ITプロジェクトに正解はない」
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
