「うちは大きなグループの一員なのに、なぜシステムがこんなに古いんだろう」——グループ子会社の経営者からよく聞く言葉です。親会社のIT部門は存在する。グループとしてのIT施策も動いている。にもかかわらず、子会社はその恩恵を受けられない。これは能力や意欲の問題ではなく、「構造的な分断」によるものです。大手グループ子会社の事例：セキュリティ対策が露わにした分断ある大手グループ傘下の子会社では、昨今のランサムウェア問題などをきっかけに、毎週、親会社主導の「緊急セキュリティ対策会議」が開かれています。グループ全社に対して、OS・ネットワーク機器・バックアップ・BCP対応など複数のセキュリティ対策項目への対応が求められています。その子会社では、該当箇所があるため、担当者が対策検討、推進、進捗報告を行っています。注目すべきは費用負担の構造です。このタスクフォースの原則は「コストはグループ子会社各社が工面する」こと。しかしそれが理由で単年度PLが赤字になっても、親会社からは了承されるとのこと。品質（Q）と納期（D）を優先し、コスト（C）は後回しでもいい——それほど緊急性が高いとされている。では、「品質（Q）の定義」は何か。答えは「親会社による脆弱性スキャンで通るかどうか」です。親会社が要件を定め、子会社が費用を負担して対応する。これがグループIT施策の実態です。なぜ「グループの中にいるのに、一人で対応しなければならない」のかこの構造を理解する鍵は、このグループの成り立ちにあります。このグループは元々、小売・スーパーが発祥です。グループ共通のシステム——MD（商品管理）、決済、会計など——は小売業態に最適化されて設計されています。しかし、グループには小売以外の事業会社も多く含まれます。小売以外のさまざまな業態の子会社。これらの業態は、小売向けに作られたグループ共通システムには乗れません。それぞれの業務フローに合ったシステムを、各社が独自に構築してきた歴史があります。その結果として何が起きるか。「このシステムは誰が作ったのか」という経緯の情報が揃わなくなり、だんだんブラックボックス化が進み、保守性の低いシステムになっていく。ある子会社の役員はこう話しています。「当該基幹システムはもともと大手ベンダーが作っていたものだが、システム担当者が内容を把握していたのでちょこちょこ改修していたら、今ではそのベンダーですらわからない状態になってしまった」。親会社IT部門が「助けられない」3つの理由ではなぜ、親会社のIT部門は子会社のこうした状況を解決できないのか。① グループ標準システムは「本体業態」向けに設計されている親会社のIT部門が運用・管理しているシステムは、親会社の業務に最適化されています。業態が異なる子会社のシステム課題を、グループ標準の延長で解決することはできません。「うちのシステムでは対応できません」は、冷たい拒絶ではなく事実です。② セキュリティ要件は親会社が定め、対応コストは子会社が負担するグループとしてのセキュリティ基準や施策は親会社が設定します。しかし対応の実務とコストは各社が担います。子会社は「何をすべきか」は分かる。しかし「どうやって、誰に頼んで、いくらで解決するか」は自分で考えなければならない。③ 子会社のシステムは「把握されていない」状態になっている親会社IT部門にとって、子会社の独自システムは管轄外であり、内容を把握していません。把握していないシステムに対して、具体的な支援をすることは不可能です。子会社の担当者が「相談しよう」と思っても、「内容が分からないから答えられない」という状態になります。「守りを固める」ことが、「攻めのDX」への入口になる前述のグループ子会社の役員はこう言います。「本来はもっと攻めのDXに着手したいが、今はまず守りを固めるしか無い。そこから一緒に取り組んでほしい」。これは多くのグループ子会社に共通する状況です。セキュリティ対応・ブラックボックス化の解消・保守性の改善——こうした「守り」を先に固めることなしに、新しいシステムへの投資や業務改善には踏み込めません。守りを固めるための第一歩は、「今のシステムの実態を把握すること」です。誰が作り、誰が保守し、どんな業務を支えているか。このシステムが止まったら何が止まるか——こうした情報が揃って初めて、優先順位を持った対応ができます。ライクバードでは、グループ子会社・中堅企業向けのシステム現行調査（AI仕様解析）を提供しています。「大手ベンダーが作ったが今は誰もわからない」「保守担当者が変わるたびにブラックボックスが深まっている」——そうした状況でも、AIを活用した仕様解析でシステムの実態を整理します。「まず守りを固めたい」という段階からご相談ください。→ システム現行調査（AI仕様解析）について詳しく見る