大規模基幹システム導入を炎上させないためには
──誰も全体像がわからないプロジェクトを救う「越境」と「当事者意識」

「関係者が多すぎて、誰が全体を把握しているのかわからない」「システム仕様と業務要件のすり合わせで手戻りばかりが発生している」──。大規模な業務基幹システムの刷新において、このような悲鳴にも似た声が多くの現場から上がります。基幹システム導入は、全社にまたがる複雑な要件を束ねるため、必然的に難易度が跳ね上がります。私たちが支援する中で見えてきた、プロジェクトが「カオス」に陥る根本原因と、それを突破するための「役割の越境」、そしてリーダーに求められる強烈な「オーナーシップ」について解説します。

必然の大規模ウォーターフォールと「カオス」の正体

基幹システムは、関係する部門や連携する周辺システムが膨大です。また、企業のビジネスの根幹を支えるため「ミスが許されない」という特性を持ちます。走りながら改善・増強していくアジャイル型のアプローチには不向きであり、必然的に大規模なウォーターフォール型プロジェクトとなります。

そこでは、膨大な量のドキュメント作成工数と、それを正確に読み解くレビュースキルが求められます。しかし、設計修正のたびに激しい手戻りが発生し、現場は疲弊していきます。なぜこのような事態に陥るのでしょうか。

最大の原因は、関与するプレイヤーの「視野の分断」です。

• コンサルティングファーム：プロジェクトの「推進（PMO）」しか見ていない
• ベンダー担当者：自分が担当する「部分的なシステム仕様」しか知らず、横連携が希薄
• 自社の業務担当者：自分の部署の「部分的な業務」しか知らない

それぞれが与えられた別個の役割だけを全うしようと動いた結果、見事なまでにサイロ化が発生します。誰も全体像を把握しておらず、システムと業務の間に落ちたボールを誰も拾わない「カオスなシステム導入」が出来上がるのです。

失敗を回避する「越境」とリソース確保

このカオスを抜け出すための絶対条件は、上記の誰もが「自分の領域」をはみ出すことです。

例えば、自社の業務担当者は「私は業務のプロだから、システム仕様はベンダーに任せる」という姿勢を捨て、システムの仕様や制約を積極的に理解しようと踏み込む必要があります。逆にベンダーやコンサルタントも、顧客の業務ドメインに深く入り込まなければなりません。

しかし、この「越境」には多大なエネルギーと時間がかかります。だからこそ、経営層やPMは「気合い」で解決するのではなく、工数とコストの調整を行わなければなりません。

「今の業務」を捨てる痛みを伴う要件カット

大規模導入においてもう一つ重要なのが、「どれだけシステム要求をカットできるか」です。

キックオフの場では、経営陣も含め「システムに合わせる標準化（Fit to Standard）を推進しよう」「どうしてもシステム化せざるを得ない部分以外は全部カットしよう」と合意します。しかし、いざ要件定義が始まると、必ず「総論賛成・各論反対」の壁にぶつかります。

現場の声は強力です。特に「今できていることが（新システムでは）できなくなる」ことに対する反対意見は、現場の切実な不安から来るため、非常に強い抵抗を生みます。ここで「現場がそう言うなら…」とシステム側にアドオン開発を追加していけば、予算とスケジュールはあっという間に破綻し、稼働後の保守費用も膨れ上がります。

「で、あなたはどう思う？」──問われるオーナーシップ

この強烈な現場の抵抗を押し切り、要件を削ぎ落とし、全体最適へと導くためには何が必要でしょうか。それは、各チーム・各社のリーダーが持つ「強力なリーダーシップと権限」、そして最終的なオーナーのバイイン（納得と支持）です。

カオスに陥るプロジェクトの会議では、重要な決断を迫られた際に「社内に持ち帰って確認します」という言葉が頻発します。これを許してはいけません。

私たちCANAL SQUAREがプロジェクトを支援する際も、安易に持ち帰ることなく、自らが当事者として意見を持ち、その場で答えることを心がけています。

バイネーム（個人名）でオーナーシップをことあるごとに求めるのです。この「当事者としてのスタンス」をプロジェクト全体に伝播させることができた時、はじめて分断された「カオス」は一つのベクトルを持ち、強靭な推進力を持ったプロジェクトへと生まれ変わります。

大規模基幹システムの刷新は、単なるITツールの入れ替えではなく、企業カルチャーと働き方そのもののアップデートです。妥協なき「越境」と「オーナーシップ」が、その変革を成功へと導きます。