第3回：非エンジニア経営者のための「大規模システム刷新」失敗回避術

　こんにちは。KYOSHINKA代表です。

　前回の講義では、生成ＡＩなどのＩＴ利活用において、「攻め」と「守り」の天秤をシステム部門任せにせず、営業や事業部門といった現場自らがそのバランスを認識しなければならないという教訓をお話ししました。

　第３回となる今回は、多くの企業が莫大な投資を投じながらも泥沼化させてしまう「大規模基幹システムの刷新開発プロジェクト」に焦点を当てます。

　ＩＴに詳しくない非エンジニアの経営層やＣｘＯが、なぜコンサルタントやベンダーへの期待と相違して、あるいは現場の抵抗に屈してプロジェクトを失敗させてしまうのか。
　大企業で２０年もののオンプレミス（自社専用システム）からSaaS（クラウド型共有サービス）への完全移行を主導した際に起こりがちな失敗と教訓を基に、その回避術を解説します。

１．「Fit＆Gap」の罠と、ベンダー・コンサルタントへの丸投げの始まり

　基幹システムを刷新する際、現在の主流は、自社専用にゼロからシステムを作るやり方を捨て、世の中の標準的な業務プロセスが最初から組み込まれている「SaaS（クラウド）」へ移行することです。

　クラウド移行を成功させる絶対の条件は、「現行の自社業務を、クラウド側の標準プロセスに合わせる」ことです。
　自社の独自のやり方を捨て、システムに自分たちを合わせる。これを専門用語で「Fit＆Gap（適合と乖離）の低減」と呼びます。

　基幹システム刷新プロジェクトを立ち上げた際は、この重要性を認識して、現行業務プロセスを強制的に変革するための専門チーム（BPRチーム）をプロジェクトチームに設置します。
　そして、クラウドの標準から外れる割合（乖離率）を「25％以内」に抑えるという明確な目標を掲げ、移行後の理想の業務像（ToBe像）を設計書（RFP）に描き出します。
　ここまでは、経営・システム開発の教科書通りの正しいスタートです。
　
　しかし、実際の「要件定義（具体的な中身を決める段階）」に入った途端、この構想は消失します。
　原因は、プロジェクトの自社メンバーの「自社業務への理解・認識不足」です。選抜されたメンバー自身が、現行システムがどう動いているのか、実際の業務プロセスがどうなっているのかを正確に詳細には把握できていません。
　自社の業務の詳細がわからないメンバーは、結果としてシステムの仕様策定をベンダーやコンサルタントに「委託（依存）」せざるを得なくなります。
　当然、外部のベンダーが他社の複雑な業務プロセスの詳細を完璧に掌握できるはずがありません。
　さらに、既存システムのソースコード（プログラム）は著作権の関係で旧ベンダーが非開示にするという問題も重なり、ブラックボックス化したまま開発が難航。Saas（クラウド）の標準から外れた部分が「6〜7割」にまで跳ね上がるという、致命的な事態に陥っていきます。

２．現場の「個別直訴」と、経営層のブレが招くアドオンの増加

　Saasの標準プロセスから6〜7割も外れるということは、現場（事業部門）が「今のやり方を変えたくない」とSaasの業務プロセスに合わせることにかなり反発したことを意味します。

　現場からは次のような声が上がりがちです。
　「業務プロセスをクラウドに合わせるには、長年続けてきた取引先との調整が必須になる。そんな要請をすれば営業現場が混乱し、売上が落ちる」
「一線の社員に変革の負担を強いるのは無理だ。納得を得られない。」
「プログラムを追加（アドオン、カスタマイズ）して、今の業務のまま動くようにシステム側を改造すれば済む話ではないか」

　そして、ここからプロジェクトの命運を分ける最悪の構造が動き出します。
　現場の営業事業責任者たちが、プロジェクトの正規のルートを通さず、経営層へ個別に「このままのシステム開発では事業が成り立たない」と直訴（政治的アプローチ）を始めます。
　非エンジニアの経営層は、技術的な本質や全体のROI（投資対効果）が見えていないため、個別に上がってくる「売上が落ちる」という営業トップの脅し文句に屈してしまいます。「そこまで言うなら、お前の部門だけは今のやり方を維持できるようにシステムを改造（アドオン）してやれ」と、部門個別の要望を認めてしまいます。

　結果は火を見るより明らかです。
　各部門の現行踏襲の意見を受け入れたことでアドオンは爆増し、開発工数とコストは天井知らずに跳ね上がります。
　せっかく導入したクラウドの標準機能はまったく活かされず、ROIは崩壊。さらに、無理に改造したアドオン領域では、システム稼働後に多数のインシデント（システム障害）が多発するという、最悪の稼働を迎えます。

３．経営層が果たすべきだった「決断」と徹底すべき精神

　この失敗から得られる教訓は、大規模システム刷新の成否は、ベンダーの技術力でもシステムの性能でもなく、「経営層の毅然とした態度と全社俯瞰の判断力」にかかっているという事実です。

　非エンジニアの経営層が、プロジェクトを泥沼化させないために絶対に実践すべき（そしてこれから刷新に挑む経営層が徹底すべき）アクションは以下の４点です。

• 業務プロセス改善を毅然と実施させる強い意志：
  　現場からの「売上が落ちる」「業務が変わると負担になる」という抵抗は、業務変革、組織変革における必然の摩擦です。経営層は現場の個別直訴に耳を貸さず、「今回はシステムに業務を合わせる。取引先との調整も経営としてバックアップする」と、一歩も引かない姿勢を示す必要があります。

• システムコストと事業のROIの徹底管理：
  　基幹系システムは全社システムですが、各部門が好き勝手にシステムを改造すれば、そのコストは全社に跳ね返ります。経営層は、各部門が使用するシステム領域のコストと、それによって得られる事業の投資対効果を冷徹に天秤にかけ、予算枠の範疇での開発を現場に徹底させなければなりません。

• RFP（提案依頼書）時点での精神の徹底：
  　プロジェクトが始まってからブレるのでは遅すぎます。発注前のRFPを作成する段階で、「アドオンは原則禁止、業務側を変革する」という精神を、経営層自らがプロジェクトメンバーと事業部門のトップに骨の髄まで叩き込み、実践しておくことが重要です。
  　そして、要件定義工程では、業務プロセスがシステムのToBeで変わることを理解し、その精神をもって臨むことが重要です。

• プロジェクトメンバー選定の注意：
  　基幹システム開発のプロジェクトには各部門から長年現場業務に精通したベテラン社員をアテンドすることが常です。しかしながら彼らが現行の業務プロセスを完全掌握している、また、新システムの業務のToBe像が掌握できている、というものでもありません。長年現場にいるベテラン社員ほど「現行踏襲」の傾向が強くなりがちです。
  　現行踏襲＝既得権の発想が業務プロセス改革の障害になることに気づきません。経営層も現場が正しい解答をもっているものと誤認します。
  　システム開発で正しいのは、RFPで完成させた業務プロセスのToBe像にあります。

　システム開発をプロジェクトやコンサルタントやベンダーに丸投げし、業務プロセス改革の社内調整から目を背けた経営層の「優しい妥協」が、数億～数十億円の投資をドブに捨てる結果を招きます。
　システム大規模刷新とは、ＩＴの買い替えではなく、経営そのものの「外科手術」であると心得て取り組みください。

読者の皆様へ：今回の振り返り問いかけ

貴社の大規模システムプロジェクトにおいて、現場のリーダーが「今のやり方を変えたくないからシステムを改造してくれ」と言ってきたとき、経営層として毅然と「NO」を突きつける基準を持っていますか？

（「ベンダー丸投げからの脱却」や、現場の抵抗を抑え込むBPR・刷新プロジェクトのセカンドオピニオンに関するご相談は、KYOSHINKA　https://www.kyoshinka.comまでお気軽にお問い合わせください。）

◆DX/AX推進講座
　第１回：絵に描いた餅で終わらせない「実行できるDX」の第一歩
　第２回：経営層が知るべき「攻めのAI活用」と「守りのガバナンス」の天秤

◆コラム
　「そこに“ＡＩ”はあるんかー映画とＤＸ」マガジン