システム統合プロジェクトの現場で何が起きていたか
システム統合という言葉を聞くと、多くのIT担当者は「大変そう」という漠然とした印象を持つと思います。しかし、実際に100名規模の体制で1年5ヶ月間、全系列局のCM管理システム統合プロジェクトのPLを務めた経験から言えるのは、「大変そう」という予想をはるかに超える困難が待っているということです。
2017年11月から2019年3月まで、私は民放営業放送システムのプロジェクトリーダーとして、各地の放送局が長年使ってきたシステムを統合する仕事に携わりました。表面的には「各局のCM管理システムを統一する」というシンプルな目標です。しかし、蓋を開けてみると、そこには想像以上の複雑さが潜んでいました。
最初のキックオフミーティングで各局の担当者が集まったとき、私は一つの事実に気づきました。同じ系列局であっても、CM枠の管理方法、契約書のフォーマット、売上計上のタイミング、さらには「CM」という言葉の定義すら微妙に異なっていたのです。
2017年11月から2019年3月にかけて、私はPLとして民放営業放送システムの統合プロジェクトに1年5ヶ月従事しました。体制は100名規模、全系列局のCM管理システムを統合するという大規模案件でした。最大の難所は、各局が30年以上かけて発展させてきた独自システムの違いです。同じ『CM放送』でも、料金体系、枠管理ルール、得意先との商慣習が局によって微妙に異なる。キー局と地方局の規模感も全く違いました。データ標準化の議論だけで4ヶ月かかり、各局担当者を集めた会議では『なぜウチのやり方を変えなきゃいけないんだ』という反発も。最終的には『共通機能と局別カスタマイズ』のバランス点を見つけて統合できましたが、システム統合は技術問題ではなく『組織と文化の統合』だと痛感した案件でした。
この経験談が示すように、システム統合の難しさは技術面だけではありません。むしろ、技術的な課題よりも、組織間の商慣習の違い、データに対する考え方の相違、そして何より「変化への抵抗」という人間的な要素の方が大きな壁となります。
100名という体制は一見すると十分な人員に思えます。しかし、実際には各局から派遣された担当者、ベンダー側の開発チーム、PMO、品質管理チーム、運用設計チームなど、様々な立場の人々が入り混じり、情報共有だけでも一苦労でした。毎週の進捗会議では、A局では当たり前のことがB局では「そんなやり方は聞いたことがない」という状況が頻発しました。
各局が育ててきたシステムの「個性」
システム統合で最初にぶつかる壁は、既存システムの「個性」です。各放送局は10年、20年とかけて自局のビジネスに最適化したシステムを育ててきました。それは単なるツールではなく、その局の営業スタイル、顧客との関係性、社内の業務フローそのものと言っても過言ではありません。
ある局では、CM枠を「秒数×本数」で管理していました。一方、別の局では「時間帯×金額」で管理していました。さらに別の局では「番組単位のパッケージ」で管理していました。同じ「CM管理」という言葉を使っていても、その実態は三者三様だったのです。
データベースの設計も各局で異なっていました。顧客コードの体系、商品コードの採番ルール、契約期間の定義方法など、基本的なマスタデータからして統一されていませんでした。これらを統合するということは、単にシステムを置き換えるだけでなく、各局のビジネスプロセス自体を見直すことを意味していました。
「うちの局では」という言葉の重み
要件定義のフェーズで最も頻繁に聞いた言葉が「うちの局では」でした。この言葉には、各局が積み重ねてきた歴史と誇りが込められています。単に「標準化しましょう」と言っても、簡単には受け入れてもらえません。
特に営業部門からの抵抗は強いものでした。彼らにとって既存のシステムは、長年の営業活動で培ってきたノウハウが詰まったツールです。「新しいシステムでは今までのやり方ができなくなる」という不安は、単なる技術的な問題ではなく、自分たちの仕事のやり方そのものが否定されるという感覚につながっていました。
私たちPMO側も、この気持ちを無視することはできませんでした。一方的に「これが新しい標準です」と押し付けるのではなく、なぜその標準が必要なのか、統合によってどんなメリットがあるのかを、何度も何度も説明する必要がありました。時には、各局の要望を可能な限り取り入れた「折衷案」を作ることもありました。
なぜシステム統合はこれほど難しいのか
30年のキャリアで様々なプロジェクトを見てきましたが、システム統合が失敗する理由にはいくつかの共通パターンがあります。民放のプロジェクトで経験したことも、このパターンから外れるものではありませんでした。
技術よりも「暗黙知」の統合が難しい
システム統合の本質的な難しさは、技術的な統合ではなく「暗黙知の統合」にあります。各組織には、長年の運用の中で蓄積された暗黙のルールや判断基準が存在します。これらは文書化されていないことが多く、当事者も意識していないことがあります。
民放プロジェクトでは、要件定義の段階で各局にヒアリングを行いましたが、最初は「特に変わったことはしていない」という回答が多かったのです。しかし、実際の業務を観察してみると、独自の運用ルールや例外処理が山のように存在しました。
例えば、ある局では長年の付き合いがある大口顧客に対しては、通常とは異なる請求サイクルで対応していました。しかし、これはシステムには記録されておらず、担当者の頭の中にしかない情報でした。こうした暗黙知を洗い出し、新システムでどう扱うかを決めることが、想定以上の時間を要しました。
データ標準化という名の文化統合
データの標準化は、単なる技術的な作業ではありません。それぞれのデータ項目には、その組織の考え方や文化が反映されています。
民放プロジェクトで苦労したのが、CM素材の分類方法でした。ある局は業種別、別の局は商品カテゴリ別、さらに別の局は広告主の規模別で分類していました。これらを統一するということは、「CMをどう捉えるか」という認識を統一することでもありました。
最終的には、最大公約数的な分類体系を作り、各局の既存分類との対応表を作成しました。しかし、この対応表は単純な1対1の変換ではなく、複雑な条件分岐を含む変換ロジックになりました。データ移行時にはこのロジックのバグが多発し、移行テストだけで3ヶ月を要しました。
統合のタイミングとリスク管理
システム統合で最も神経を使うのが、運用切り替えのタイミングです。特に放送業界のような24時間365日稼働が求められる業界では、「切り替えに失敗したので元に戻します」という選択肢は事実上ありません。
私たちは、各局を順次切り替える「段階移行」のアプローチを採用しました。しかし、これには別の問題がありました。移行済みの局と未移行の局が混在する期間が発生し、その間のデータ連携やレポート集計が複雑になったのです。
また、移行の順番を決めることも政治的な問題でした。「最初に移行する局はリスクが高いが、問題点を早く見つけられる」「後から移行する局は安全だが、それまで待たされる」という利害の対立があり、調整に多くの時間を費やしました。
現代のツールとアプローチで何が変わるか
2017年当時と比べて、2025年の今はシステム統合を支援するツールや手法が大きく進化しています。もし今、同じプロジェクトに取り組むなら、私は間違いなく以下のようなアプローチを採用します。
API連携による段階的統合
当時のプロジェクトでは、「一つの統合システムにすべてを集約する」というアプローチを取りました。しかし、現代であれば、まずAPI連携で各局のシステムを緩く統合し、段階的にコア機能を共通化していく方法を選びます。
MuleSoftやDell Boomiのような統合プラットフォームを使えば、各局の既存システムを残したまま、必要なデータだけを連携させることができます。これにより、各局のビジネスプロセスを無理に変更することなく、グループ全体でのデータ活用が可能になります。
私がこのアプローチを推奨する理由は、リスクの分散です。すべてを一気に変えようとすると、どこかで大きな問題が発生したときに全体が止まってしまいます。しかし、API連携であれば、ある局との連携で問題が起きても、他の局への影響を最小限に抑えられます。30年の経験から言えば、「小さく始めて徐々に広げる」アプローチの方が、結果的に成功率が高いのです。
データ標準化プラットフォームの活用
データの標準化には、Informatica MDMやTalend Data Fabricのようなマスタデータ管理ツールが有効です。これらのツールは、異なるシステム間でマスタデータの整合性を保ちながら、各システムが独自のデータ構造を持つことを許容します。
民放プロジェクトで最も時間がかかったのが、顧客マスタと商品マスタの統合でした。現代のMDMツールを使えば、「ゴールデンレコード」と呼ばれる標準マスタを定義しつつ、各局固有の属性情報も保持できます。これにより、「統一すべきところは統一し、各局の個性は残す」という理想的な状態を実現できます。
私が現場で使うなら、まず小さな範囲(例えば大口顧客だけ)でMDMツールを導入し、効果を確認してから徐々に対象を広げていきます。全マスタを一気に統合しようとすると、また同じ混乱を招く可能性があるからです。
プロジェクト管理とコミュニケーションツール
当時のプロジェクトでは、各局との調整にメールと定例会議を使っていました。100名規模の体制では、情報が正しく伝わっているかを確認するだけで膨大な時間がかかりました。
今であれば、SlackやMicrosoft Teamsのようなチャットツール、JiraやAsanaのようなプロジェクト管理ツールを組み合わせて使います。特に重要なのは、決定事項や課題の「見える化」です。各局の担当者が、今何が決まっていて、何が未決なのかをリアルタイムで確認できる環境を作ることが、混乱を防ぐ鍵になります。
また、Miroのようなオンラインホワイトボードツールを使えば、各局のシステム構成や業務フローを視覚的に共有できます。私が30年見てきた経験から、「言葉で説明するより図で見せる」方が、認識の齟齬を防げることが分かっています。特にシステム統合のような複雑なプロジェクトでは、視覚化の効果は絶大です。
30年現場にいた私が思うこと
民放のシステム統合プロジェクトを振り返ると、技術的な困難よりも、人と組織の問題の方が大きかったと感じます。各局の担当者は、決して統合に反対していたわけではありません。むしろ、統合の必要性は理解していました。しかし、長年慣れ親しんだシステムとやり方を変えることへの不安が、抵抗という形で表れていたのだと思います。
完璧な統合より「まずは動く統合」を
プロジェクトの最中、私は何度も「完璧なシステムを作ろう」という誘惑に駆られました。すべての局の要望を満たし、あらゆる例外ケースに対応し、将来の拡張性も考慮した、理想的なシステムです。
しかし、30年の経験が教えてくれたのは、「完璧を目指すと永遠に完成しない」という現実です。むしろ、8割程度の機能で早くリリースし、実際の運用の中で改善していく方が、結果的にユーザーの満足度が高くなることが多いのです。
特にシステム統合では、実際に使ってみないと分からない問題が必ず出てきます。要件定義の段階でどれだけ丁寧にヒアリングしても、運用開始後に「こんなケースがあるとは思わなかった」という状況は避けられません。だからこそ、早めに動くシステムを作り、フィードバックを受けながら改善していくアプローチが重要だと考えています。
中小企業が今日からできること
民放のような大規模プロジェクトと、中小企業のシステム統合では規模が違います。しかし、本質的な課題は同じです。複数の部門やグループ会社がそれぞれ独自のシステムを使っていて、データが分断されている状況は、規模に関わらず多くの企業が抱えています。
もしあなたの会社で複数システムの統合を検討しているなら、まず小さく始めてください。すべてのシステムを一気に統合しようとするのではなく、最も効果が大きい部分から着手するのです。
具体的には、まず「マスタデータの統一」から始めることをお勧めします。顧客情報や商品情報など、複数システムで共通して使われているマスタデータを、Excelでもいいので統一フォーマットで管理し始めてください。これだけでも、データの重複や不整合による問題は大幅に減ります。
次に、システム間のデータ連携を、API連携ツールやRPAを使って自動化していきます。最初は手作業でデータを移動させている部分を自動化するだけでも、大きな効果があります。そして、その過程で各システムの使われ方や課題が見えてきたら、本格的な統合を検討する段階です。
統合は手段であって目的ではない
最後に、システム統合プロジェクトに関わるすべての人に伝えたいことがあります。それは、「統合は手段であって目的ではない」ということです。
民放プロジェクトでも、途中から「システムを統合すること」自体が目的化してしまう瞬間がありました。しかし、本来の目的は「グループ全体での営業力強化」や「顧客サービスの向上」のはずです。統合はそのための手段に過ぎません。
だからこそ、「この統合によって、現場の仕事がどう楽になるのか」「お客様にどんな価値を提供できるのか」を常に考え続ける必要があります。技術的に優れたシステムでも、現場が使いこなせなければ意味がありません。逆に、多少不格好でも、現場の業務を確実に改善できるシステムの方が価値があります。
私が1年5ヶ月のプロジェクトで学んだ最も重要なことは、システム統合は技術プロジェクトではなく「変革プロジェクト」だということです。技術は、人と組織の変革を支えるツールでしかありません。そして、その変革を成功させるには、現場の声に耳を傾け、小さな成功を積み重ね、信頼関係を築いていくしかないのです。
あなたの会社でシステム統合を進めるなら、まず関係者全員で「何のための統合なのか」を話し合う時間を作ってください。そして、完璧なゴールを目指すのではなく、小さな一歩から始めてください。私の経験では、その小さな一歩こそが、最終的に大きな成果につながる確実な道なのです。
コメント