既存システムのサービス終了まで、残り2年。グループ会社共通の新システムへの移行と、業務の標準化を同時に進めるプロジェクトが動き出した。
Read the Story
ある大手情報通信会社のIT部門に、ひとつの通達が届いた。
「2027年末をもって、現行システムのサービスは終了する。」
システムベンダーからの公式通知だった。猶予は2年。その間に、グループ会社共通の新システムへ移行し、現行システムに依存していた業務プロセスを全面的に見直さなければならない。
問題は、規模だった。
このシステムは、グループ複数社の業務を横断して支えていた。営業・経理・人事・調達——各部門が独自のカスタマイズを重ね、10年以上運用してきた基幹システムだ。「誰が何のためにこの機能を使っているか」を完全に把握している人間は、もはや社内に存在しなかった。
「システムの機能一覧はあります。でも、実際に使われている機能と使われていない機能の区別が、誰にもわからない状態でした。」——プロジェクト関係者の証言（匿名）
移行プロジェクトの難しさは、技術的な問題だけではない。
各部門は「自分たちの業務を守りたい」という防衛本能を持つ。「新しいシステムになって、今の業務ができなくなったら困る」——この不安が、プロジェクトの前進を阻む最大の壁になる。
調整すべきステークホルダーは、数十名に上った。
経営層・IT部門・各事業部門・ベンダー・グループ会社——それぞれが異なる利害関係を持ち、異なる優先順位で動いている。誰かが「承認」しても、別の誰かが「待ってくれ」と言う。プロジェクトは進んでいるように見えて、実は止まっている。
この状況を打開するために、外部のPMが必要だとなった。条件はひとつ。「全員の言葉を聞きながら、プロジェクトを前に進められる人間」であること。
アサインされたのは、調整型のPMだった。
担当したエキスパートは、複数業界でのPM/PMO経験を持つ専門家だ。
彼のキャリアの特徴は、「対立する利害関係者を調整しながらプロジェクトを動かす能力」にある。製薬・行政・建設——異なる業界で繰り返し求められてきたのは、この一点だった。
大手コンサルファーム時代に最も鍛えられたスキルも、分析でも提案でもなく、「会議をリードする力」だったと彼は言う。
「会議は情報共有の場ではない。意思決定の場です。そこをファシリテートできないPMは、どれだけ優秀でも現場では機能しない。」
このプロジェクトで求められたのは、「正解を持ってくる人間」ではなく、「正解を全員で作れる場を設計できる人間」だった。
ExpertMatchのマッチングが「業界一致ではなく課題タイプ一致」を優先する理由が、ここに現れている。情報通信業界の専門知識より、「複数ステークホルダーを束ねてプロジェクトを動かす経験」の方が、はるかに重要なファクターだったのだ。
担当エキスパートがまず手をつけたのは、意外なことに「会議の再設計」だった。
プロジェクト開始時点では、週次の定例会議が複数存在していた。経営層向けの報告会、IT部門の技術検討会、各事業部との調整会——会議の数は多いのに、なぜかプロジェクトは前に進まない。
理由は明快だった。「情報共有の会議」と「意思決定の会議」が混在していたのだ。
情報共有と意思決定を同じ場で行おうとすると、何も決まらない。参加者は「自分の情報を伝えること」に集中し、「何を決めるか」が後回しになる。会議が終わっても、次のアクションが誰にも明確でない。
会議の目的が「共有」なのか「決定」なのかを明確にするだけで、プロジェクトのスピードは変わる。
彼は会議体を3層に再編した。
参加者: 経営層・PM
目的: Go/No-Goの判断のみ
時間: 60分以内
アジェンダ: 事前配布・事前確認必須
参加者: 各部門の責任者・PM
目的: 部門間の調整が必要な課題の解決
時間: 90分
ルール: 課題と選択肢をPMが事前整理して持ち込む
参加者: 実務担当者・PM
目的: タスクの進捗確認と障害の早期発見
時間: 45分
ルール: 課題は「Layer 2に上げるか/自分たちで解決するか」を即決
この3層構造が機能し始めると、プロジェクトは動き始めた。
プロジェクトは3つのフェーズで進んでいる。現在は第2フェーズの真っ只中だ。
最初の3ヶ月で、エキスパートは現行システムの全機能を棚卸しした。
「使われている機能」と「使われていない機能」を分類するために、各部門の実務担当者に個別ヒアリングを実施。30名以上に話を聞き、現行システムへの依存度をマッピングした。
同時に、移行プロジェクト全体のWBSを作成。2027年末という締め切りから逆算して、各フェーズの完了条件と担当者を明確にした。
「最初の3ヶ月で最も重要なのは、『誰が何を決める人間か』を全員が理解することです。これが曖昧なまま進むと、後で必ず混乱する。」
現在のフォーカスは、新システムへの要件定義と業務の標準化だ。
グループ会社ごとに異なる業務プロセスを、新システムに合わせて「共通化できる部分」と「個別対応が必要な部分」に分類する作業が続いている。
この作業が難しい理由は、「各社が自分たちのやり方に合理性があると信じている」からだ。長年の経験から生まれた業務プロセスには、それぞれ理由がある。それを「共通化するために変えてくれ」と言うのは、相手の仕事のやり方を否定することに近い。
新システムへの実際の移行と、移行後の定着支援が残っている。プロジェクトはまだ継続中だ。
プロジェクトはまだ完了していない。だが、中間時点での変化は明確だ。
変化の本質は「会議の質」だった。
会議体の再設計後、経営層からの最初のフィードバックはこうだった。「会議に出るのが苦痛じゃなくなった。」
これは小さな変化に見えて、プロジェクトの持続可能性に直結する変化だ。経営層が「この会議は意味がある」と思える状態を作れれば、プロジェクトへのコミットメントが維持される。コミットメントが維持されれば、予算と人員が守られる。
「以前は月次報告会が2時間かかっていました。今は1時間で終わり、しかも意思決定が会議中に完了します。」——プロジェクト関係者の証言（匿名）
リスク管理の早期化も進んだ。
3層の会議体制が機能したことで、「課題の発見から対応方針の決定まで」のサイクルが大幅に短縮された。以前は課題が発生してから経営層に報告されるまで数週間かかることもあった。現在は、週次の作業確認会議で発見された課題が、翌週の課題解決会議で方針決定まで到達する。
これは、情報通信業界だから成立した話ではない。システム移行・大規模変革を伴うプロジェクト全般に応用できる。
多くの企業で、会議は「慣習」として存在している。「毎週月曜に定例会議がある」——その会議がなぜ存在するのか、誰が何を決めるのかが明確でないまま、年単位で続いている。
会議体を「意図を持って設計する」だけで、プロジェクトのスピードと質は劇的に変わる。これは、コストゼロで実行できる最大の改善策のひとつだ。
「システム移行プロジェクト」と聞くと、技術的な問題に目が向きがちだ。だが、実際のボトルネックは「業務プロセスをどう変えるか」にある。
新システムの選定や技術設計は、専門家がいれば対応できる。難しいのは、長年の慣習として根付いた業務プロセスを変えること。そのためのファシリテーションができるPMが、最も不足している。
「2027年末のサービス終了」という外部から課せられた締め切りが、このプロジェクトを動かした。
変革は、内発的動機だけでは動きにくい。外部の締め切りや危機感を、プロジェクトの推進力として意図的に使うことが重要だ。
このストーリーを読んで、自社と重なる部分はありましたか？
ひとつでも当てはまる方へ
システム移行プロジェクトが「動いているようで動いていない」状態は、多くの企業が経験する。
原因はほぼ共通している。PMO機能の不在と、ステークホルダー調整の設計不足だ。
技術的な問題は、ベンダーが解決してくれる。だが、「誰が何を決めるか」「どう調整するか」という組織的な問題は、誰も解決してくれない。ここに外部PMの価値がある。
ExpertMatchを通じて、ステークホルダー調整を専門とするPM型エキスパートをアサインできる。初回相談は無料。「自社のプロジェクトをどう動かすべきか」の整理段階から、専門家と一緒に進められる。