CIO Loungeは、企業経営者の情報システムに関するリテラシーを高め、情報システム部門やベンダーと経営者との間の架け橋となることを目的に設立されたNPO法人だ。そしてその中で基幹システムの刷新に関する課題について検討しているのが、基幹システム分科会である。基幹システム再構築の目標設定、領域や部門ごとに採用すべきアプリケーション、推進体制や期間、投資を含む策定すべきプロジェクト計画について検討し、企業に情報を提供している。

5月19日に開催された「TECH+セミナー 製造業DX 2026 May. レガシー刷新、ROIを可視化し変革を加速へ」に、CIO Lounge 正会員の本木昌裕氏が登壇。同氏のコンサルタントとしての経験を基に、基幹システム刷新における課題や成功させるための考え方について説明した。

基幹システム刷新の成否を分けるのは起案段階

講演冒頭で本木氏は、「どんな組織でも、どのような設備や技術であっても、現行システムは未来永劫安泰ではない」と話した。システムにはサポートの終了やハードウェアの製造終了といった技術面の問題、長年使ったシステムがブラックボックス化してどこを触ればよいか分からないといった機能面の問題があるほか、現行の仕組みをつくった人材の退社や異動により、保守体制を維持できなくなることも考えられる。そのため、基幹システムの刷新は避けることのできない課題となる。

しかし、現行と同等の機能のシステムへの置き換えでは成果は見えにくい。場合によっては億単位のコストがかかるのに、それに見合うリターンがあるかと経営陣に問われれば納得させるのは難しい。そして実際に刷新に着手すれば、膨大なマンパワーとコストが必要になるうえ、QCD（品質、コスト、納期）は計画通りに進むとは限らない。さらに、大企業なら資金や人材を大量に投入できるかもしれないが、中堅/中小企業では経営の屋台骨を揺るがしかねない取り組みになる。

このように難しい面が多い基幹システム刷新だが、CIO Loungeの基幹システム分科会ではそのプロセスを起案のWhy、企画・構想のWhat、実装のHowという3つの段階に分けて検討している。そしてこの中でもっとも重要だと同氏が指摘するのは起案段階だ。

「起案段階のWhyでボタンをかけ違えると、その後のWhat、How段階ではかけ違いはますます大きくなり、そのままプロジェクト全体の失敗につながるため、起案段階が非常に重要なのです」（本木氏）

  • 基幹システム刷新における3つのプロセス

    基幹システム刷新における3つのプロセス

基幹システム刷新は「4つの起点」から始まる

本木氏によれば、基幹システムとは、基盤業務と周辺業務とを合わせた範囲のシステムのことを指す。基盤業務は、購買管理、在庫管理、生産管理、財務会計など、全社のモノとカネの情報を一元管理する基幹的な業務だ。周辺業務は需給や設計、マーケティングなど、基盤業務と密接に連携して業務を高度化する領域である。ただし両者の性格は大きく異なる。基盤業務は企業のベーシックな事業活動に不可欠である一方、周辺業務はより高度な業務管理を可能にするものであり、もしなかったとしても基盤業務が継続していれば事業は最低限継続できるといった違いがある。

では、基幹システムを刷新する起点となる動機や目的は何か。同氏はそれを、主導するのが経営陣か部門か、視点が業務視点かIT視点かという2つの軸で考え、起点を4つのパターンに分類して説明した。

  • 基幹システム刷新目的の4象限

    基幹システム刷新目的の4象限

例えば、ビジネスの海外展開が進んだことでグローバルの経営管理を実現したいというところが発端の場合は、主導は経営であり、業務視点で進めることになる。また、在庫削減やリードタイム短縮、調達コスト管理、調達マネジメントや管理水準の高度化など、特定の業務部門として実現したい姿が明確で、そのためにITの力を使いたいという場合なら、部門主導、業務視点だ。経営としてITの近代化に関心があり、AIの活用、DXやクラウドの推進といったところから着手するのは、経営主導、IT視点ということになる。そしてもっとも多いパターンが部門主導、IT視点だ。これは多くの場合その中身はITの老朽化対応で、技術的、機能的な老朽化や保守体制の老朽化への対応として、現在の仕組みを理解している人材がいるうちにシステム刷新をしようという場合だ。

目的の希薄化と範囲の肥大化が失敗を招く

これらの4つのパターンのどこが起点になってもよいし、目的が明確になっていれば問題はない。しかし本木氏は、1つのパターンからスタートしたプロジェクトが他のパターンの要素を取り込んでいくと問題が生じやすくなると指摘する。例えばITの老朽化対応でIT部門が主導しIT視点で始めたプロジェクトの場合、その効果を経営陣にうまく説明できないことも少なくない。そもそも老朽化による将来のリスクに対応するプロジェクトであるのに、投資承認を得ようと無理な業務改革目標を設定してしまうと、プロジェクトの領域は肥大化し、目的が希薄化してしまうのだ。

「そうなるとユーザー部門の納得感が得られず、供出されるマンパワーが不足してプロジェクトが難渋してしまいます。結果として作業品質が低下し、納期は遅延、追加予算が発生する。そんな事例は数多くあります」（本木氏）

部門主導、業務視点でスタートさせたプロジェクトの場合なら、その失敗の典型的なストーリーはこうだ。発端が調達や需給管理といった周辺業務の特定部門の業務改革である場合、そこに流すデータを清流化するために基盤業務の刷新を先行させようと考える。しかし基盤業務においては受発注や在庫管理などが一元化されているため、関係部分だけを更新することは難しい。そこで業務基盤全体の刷新へと舵が切られる。つまり特定部門を対象とした取り組みだったはずが、全社業務改革へと格上げされてしまうのだ。こうなると、もともとリーダーシップをとっていた部門とそれ以外の部門とで取り組みに対する熱量の差が生まれ、プロジェクトが難渋してしまう。

体制内の温度差解消が絶対条件

起案の過程で目的にブレが発生することや、プロジェクトを進めるために対象範囲がブレ、拡大してしまうことも問題だが、さらに大きな問題になるのは、ブレが生じているのにそのままプロジェクトを推進し、当事者の意識にブレが生じることである。起点となってリーダーシップをとる部門だけが高い熱量を持ち、それ以外の部門との差がある状態では、全体がうまくいくはずがない。とくにシステムの刷新においては、データの整備やシステムの稼働状態の確認、業務変革のためのマニュアル整備など、後工程においてユーザー部門に大きな負担がかかる。温度差があるまま進んでしまうと、後工程に人員が十分に補充されず、課題が先送りになってしまうのだ。

「目的や範囲のブレを許容するのであれば、推進体制内の温度差を解消してからプロジェクトを進める、これがプロジェクトを迷走させない絶対条件です。それができないならプロジェクトを中止する、あるいは納期を延ばす。そう考えておくことも必要です」（本木氏）

基幹システムの刷新は、企業にとって数十年に一度の大事業となるものだ。どうせ多大なコストをかけるのであれば大きな目標を立てようと考えがちだが、負荷の大きいプロジェクトになるため、同時に多くのことを求めてはいけない。ROI（投資収益率）もほどほどに設定すべきであり、システム刷新のための投資を回収できるほどのリターンを求めるのは行き過ぎた考え方である。さらに、関係部署の人間が当事者意識を持つことも重要で、イニシエーションが不十分であればプロジェクトを本格的にスタートさせない、それくらいの覚悟をもって取り組むべきであると本木氏は強調した。

「製造業のビジネスの根幹は製品やサービスです。ですから冒険的にITを刷新するという意思決定は間違いなのです。基幹システム刷新においても、製造業の最重要キーワードである“安全第一”の精神をもって、安定してから次の段階の改善や改革に取り組んでいく。日本の製造業の風土にあったやり方で進めていただきたいと考えています。そのうえで、どうしても並行して大きな改革を実施する必然性があるならば、全社一丸となった不退転の覚悟で取り組んでほしいと思います」（本木氏）