基幹システム刷新は“新しくすれば解決”じゃない｜要件定義の勘所
「そろそろ基幹システムを刷新しないと」——そう考えるとき、頭の中にはたいてい「新しくすれば速くなる、楽になる」という期待があります。古いシステムは動きが重い、画面が古い、担当者しか触れません。だから入れ替えれば解決します。そう思っていませんか。
でも、製造業・物流業のDX支援に携わってきた立場から見ると、刷新プロジェクトがつまずく原因の大半は、システムの新旧ではありません。「何を、なぜ、どう変えるか」を決めないまま、ベンダー選びと機能一覧の比較に入ってしまうことにあります。
基幹システム刷新・要件定義とは ― まず1分だけ
基幹システムとは、受発注・生産管理・在庫・会計など、事業の根幹を支える業務システムの総称です。刷新とは、老朽化したそれを入れ替えるプロジェクトを指します。そして要件定義とは、「新しいシステムに何をさせるか」を、業務の目的に立ち返って言葉と図に落とす工程です。ここを曖昧にしたまま見積もり合わせに走ると、後工程がすべて狂います。
“新しくすれば解決”という思い込み
経済産業省は2018年の「DXレポート」で、老朽化した基幹システムを放置した企業が2025年以降に直面するリスクを「2025年の崖」と呼び、対応が遅れれば年間最大12兆円規模の経済損失が生じ得ると警鐘を鳴らしました。この言葉が広まってから、多くの経営者が「刷新は待ったなし」と動き出しました。それ自体は正しい判断です。
ただ、私が現場で繰り返し見てきたのは、刷新の「動機」は正しいのに、「進め方」でつまずく会社です。よくあるのは、こういう場面です。情報システム部門が現行システムの画面をそのまま新システムのベンダーに見せて、「これと同じことができますか」と聞きます。ベンダーは「できます」と答え、話は前に進んだように見えます。ところが蓋を開けると、現場は10年かけて積み上げたExcelの手作業や、担当者の頭の中にしかない例外処理を、そっくりそのまま新システムに移植しようとしていました——。これは刷新ではなく、古い獣道をそのまま舗装し直しているだけです。道自体が非効率なら、舗装をいくら新しくしても速くは走れません。
私が見てきた、典型的な三つの失敗パターン
刷新プロジェクトの失敗は、突き詰めると次の三つに集約されます。どれも「システムが悪い」のではなく、「進め方の順番」が原因です。
- ①業務整理をせず「現行踏襲」で入れる：今の使い方をそのまま新システムに再現しようとします。担当者しか分からない手順や、実は不要になった承認ステップまで温存してしまい、刷新しても業務は何一つ軽くなりません。むしろアドオン開発（標準機能にない部分をつぎ足す追加開発）が膨らみ、保守費だけが増えます。
- ②ベンダー選定を機能一覧の比較だけで決める：提案書の「対応○×表」だけを見て決めてしまいます。実際の適合度を測るには、自社の主要業務を実データでシステムに当てはめるフィット&ギャップ分析（標準機能と自社業務の差分を洗い出す作業）が要りますが、これを省略した会社ほど、稼働直前になって「この処理ができない」と気づきます。
- ③要件定義を情報システム部門だけで進める：現場のキーマンを巻き込まず、システム部門と経営企画だけで仕様を固めます。現場は完成した仕様を「知らされる側」になり、稼働後に「これでは使えない」と反発が起きます。結局、現場の協力が得られず定着しないまま、旧システムに逆戻りする会社も珍しくありません。
三つとも共通しているのは、「システムを選ぶ」ことが先に来て、「業務をどう変えたいか」が後回しになっている点です。順番が逆なのです。
要件定義の勘所 ― 目的から設計しなおす
私はこれを、デザイン思考（今あるものを前提にせず、目的から設計しなおす姿勢）で捉え直しています。「今の業務をどう移植するか」ではなく、「この業務は、そもそも何のためにあるのか」を先に問い直します。物流センターで棚卸しの手順を一つひとつ棚卸ししたときも、生産管理の帳票を洗い出したときも、最初にやったのは同じことでした。目的を思い出せない作業は、たいてい削れます。
具体的な順番は次の通りです。
- 業務の目的から棚卸しする：現行の作業手順ではなく、「なぜその作業があるのか」から書き出します。目的が説明できない手順は、システム化せず廃止できないか検討します。
- フィット&ギャップ分析で差分を可視化する：候補システムの標準機能に自社の主要業務を実際に当てはめ、合わない部分（ギャップ）を洗い出します。ギャップは「アドオンで作る」か「業務を標準に合わせる」かを一つずつ判断します。ここを飛ばすベンダー選定は、稼働直前の手戻りに直結します。
- RFP（提案依頼書）に業務要件として落とす：機能一覧ではなく、「この業務がこう回ることを実現してほしい」という要件として提示します。ベンダーの提案力と実装力を、機能の有無ではなく業務理解の深さで比較できるようになります。
- 現場のキーマンを要件定義の初期段階から巻き込む：完成した仕様を説明するのではなく、目的の棚卸しから同席してもらいます。現場が「自分たちで決めた」と思えるかどうかが、稼働後の定着率を左右します。
私が大事にしているのは、「現場の1歩の動きから、経営システムまでの徹底的な全体最適」という視点です。立派なシステムは、整った業務の流れを速く正確にするための道具であって、乱れた流れをそのまま速く流す道具ではありません。順番を間違えると、高価な道具ほど、乱れを速く増幅してしまいます。
よくある質問
Q. 要件定義はいつから始めればいいですか？
A. ベンダーに声をかける前です。目的の棚卸しと業務の可視化を終えてから相見積もりに入らないと、比較の軸が「機能の多さ」にすり替わります。順番としては、業務整理→要件定義→ベンダー選定の相談、が崩れない形です。
Q. パッケージ導入とフルスクラッチ（一から開発）、どちらがいいですか？
A. 業界特有の強い個性がある業務でない限り、まずパッケージの標準機能に業務を合わせられないかを検討する方が、コストとスピードの両面で分があります。フィット&ギャップ分析でギャップが業務の根幹に関わる場合だけ、アドオンやフルスクラッチを検討する、という優先順位が現実的です。
まとめ
基幹システム刷新は、“新しくすれば解決”する話ではありません。本質は「業務の目的から設計しなおす」ことにあり、システム選定はその後に来る一手段です。全部を一度に完璧にしなくていいのです。まずは現行の作業手順を、目的から棚卸しするところから始めてみてください。属人化した業務の整理も、この棚卸しの延長線上にあります。
要件定義の設計やベンダー選定の伴走については、システム・DX支援のページ、またはお問い合わせから気軽にご相談ください。
あわせて読みたい
この記事を書いた人
小林悠真（こばやし・ゆうま）／LF&L株式会社 代表取締役。九州大学で音響設計・音楽マネジメントを学びデザイン思考を培った後、ヤマトシステム開発・バンテックで物流／生産管理、ラクスル等のITスタートアップで事業開発・SCM構築を経験。製造業・物流業のDXコンサルタントとして、現場の1歩から経営システムまでの全体最適を支援する。テューバ奏者・LFコンサート代表理事も兼務。