通信・エネルギー業界のシステム開発外注｜規制とレガシー刷新の壁

長年連れ添った大手 SIer から「メインフレームの更新には 3 年、数十億円」と提示され、経営から他社比較を突き返された——通信・エネルギー業界の発注担当者からよく伺うご相談です。他業界であれば「複数ベンダーに相見積」で片付く場面が、規制業界ではそう単純にいきません。通信の秘密や技術基準適合維持義務、電気事業法の保安規程、個人情報保護ガイドラインといった規制制約が、ベンダー選定の自由度に強い縛りをかけているからです。

一方で、既存の大手 SIer 1 社への依存を続けても、レガシー刷新は前に進みません。20〜30 年運用してきた基幹システムは、メインフレームの製造・保守終了時期、COBOL 技術者の退職、自由化以降の要件肥大化、頻繁な規制改正——といった複数の圧力を同時に受けています。ある地点を過ぎると、既存ベンダーの見積工数と工期は指数関数的に膨れ上がっていきます。

本記事では、通信・エネルギー業界の情報システム責任者・DX 推進責任者に向けて、「規制対応 × レガシー刷新」を両立するシステム開発外注の実務指針を解説します。①今回の刷新スコープに関わる規制フレームワークの整理、②レガシー刷新手法の規制業界特有の制約、③候補ベンダーを評価する 7 つのチェックポイント、④契約設計と発注側ガバナンス、⑤今週から着手すべき具体的なアクション、の順で整理します。

読み終えたときには、「どの法令・どのガイドラインが今回の刷新に関わるか」「候補ベンダーに何を質問し、どう評価するか」「監督責任を果たすための契約条項をどう設計するか」を自分の言葉で説明できる状態を目指します。既存の大手 SIer 一社依存から抜け出す道筋を、経営会議・稟議に持ち込める骨子として整理していきましょう。

通信・エネルギー業界のシステム開発外注が「規制」と「レガシー」で二重に難しい理由

通信・エネルギー業界のシステム開発外注が他業界と本質的に異なるのは、規制制約とレガシー制約が同時に、しかも構造的に絡み合っているからです。汎用の外注ノウハウ（RFP テンプレート、価格比較、開発体制評価）だけでは、どちらの制約にも十分に対処できません。まずこの二重の壁を言語化しておくことが、その後のベンダー選定・契約設計の土台になります。

通信・エネルギー業界のシステム外注実態

通信・エネルギー業界では、大手 SIer 1 社に基幹システムを長期委託し、そこから多重下請けで実装を行う体制が長年続いてきました。背景には次のような業界特有の事情があります。

• 免許・許認可事業に伴うベンダー選定の慣性: 電気通信事業者は総務省への届出・登録・認定、電気事業者は資源エネルギー庁への届出等が必要で、システムの届出内容変更にもリードタイムを要します。ベンダー変更に伴う影響を経営陣が把握しづらく、「変えないほうが安全」というバイアスが働きやすい構造です
• 重大事故・停止のインパクトの大きさ: 通信・電力・ガスは社会インフラであり、一度の障害が数十万〜数百万世帯に波及します。ベンダーを変更した直後の障害が、経営責任・行政報告義務に直結する懸念が意思決定を鈍らせます
• 既存ベンダーへのブラックボックス化: 20〜30 年の運用で仕様書・移行資料が形骸化し、既存ベンダーだけが実質的な仕様把握者になっている——という「特定 SIer への実質的なロックイン」が、多くの事業者で起きています

この構造のもとでは、「相見積を取ろう」と経営から言われても、そもそも他ベンダーに提案してもらう前提の情報（現行仕様・データモデル・非機能要件）が社内に整理されておらず、実質的な比較が成立しません。外注ノウハウ以前に「発注できる状態」を作るところから始める必要がある、というのが規制業界の出発点です。

「規制対応 × レガシー刷新」が同時に迫っている業界背景

停滞したままではいられない事情もあります。少なくとも次の 4 つの圧力が同時に、複数の企業に対して迫っています。

• メインフレームの製造・保守終了時期の到来: 富士通は 2022 年 2 月、メインフレーム製品の製造を 2030 年度末に終了し、保守サポートを 2035 年度末に終了することを公表しました（富士通がメインフレーム製造・販売から2030年度に完全撤退へ、66年の歴史に幕（日経クロステック））。通信・エネルギー業界には富士通メインフレームで基幹を運用してきた事業者が多数存在し、2035 年に向けた移行計画が待ったなしの状況です。
• COBOL 保守要員の高齢化: 経済産業省の「DX レポート」（2018 年）が指摘した「2025 年の崖」問題は、通信・エネルギー業界でとくに現実味を帯びています。COBOL・PL/I など旧世代言語で書かれた業務ロジックの保守要員が退職期を迎え、暗黙知の継承が追いつきません。
• 自由化以降の要件肥大化: 電力小売の全面自由化（2016 年）・都市ガス小売全面自由化（2017 年）以降、需給管理・卸電力取引所（JEPX）連携・託送料金計算・スイッチング支援システム連携など、既存の基幹システムに載せる要件が肥大化し続けています。
• 規制改正の頻度上昇: 電気通信事業法は、2022 年改正（外部送信規律等）、2023 年施行など、直近 3〜5 年でも複数の重要改正がありました。個人情報保護法・電気通信事業における個人情報等の保護に関するガイドラインも改正が続いています。ベンダー側にも常時のキャッチアップ体制が求められます。

これらの圧力は個別に対処できるものではなく、規制対応とレガシー刷新を「同時に」進めざるを得ない状況を作っています。だからこそ、汎用の外注ノウハウを持ち込んでも、規制業界固有の論点が抜け落ちてしまうのです。

発注前に押さえるべき規制フレームワークの全体像

発注実務の第一歩は、「今回の刷新スコープに、どの法令・どのガイドラインが関わるか」を機械的に棚卸しできる状態を作ることです。ここではベンダー選定より前の段階で押さえておくべき規制フレームワークを 4 つの領域に整理します。

電気通信事業法の技術基準適合維持義務・管理規程届出・重大事故報告

電気通信事業者の中核的な規制枠組みが電気通信事業法です。基幹システム刷新の発注にあたっては、少なくとも次の 3 条項をベンダー要件と紐付けて設計します。

• 第 41 条（技術基準適合維持義務）: 事業用電気通信設備が総務省令で定める技術基準に適合するよう維持しなければならないと定めています。ベンダー要件としては、設備更改・改修時に技術基準への影響を評価する体制、変更管理プロセス、リグレッションテストの実施能力が問われます
• 第 44 条（管理規程）: 一定規模以上の事業者は事業用電気通信設備の管理規程を届出する必要があり、実運用が届出内容に整合していなければなりません。刷新プロジェクトにおいては、管理規程の改訂と実装の同期を取れる体制がベンダー側にも必要です
• 第 28 条（重大な事故の報告義務）: 一定の障害・停止が発生した場合の総務省への報告義務です。ベンダーが運用の一部を担う場合、報告要件・報告期限・原因分析への協力を契約に明記する必要があります

法令原文は e-Gov 法令検索・電気通信事業法 で確認できます。発注時には、現行の管理規程・技術基準準拠状況を棚卸ししたうえで、刷新後の運用体制がどう変わるかをベンダーと共通言語で議論できるようにしておくのが実務ポイントです。

電気事業法・ガス事業法の技術基準適合維持・保安規程・供給約款

電力・ガス事業者にとっての中核規制は、電気事業法・ガス事業法です。システム刷新の観点では、次の 3 領域が発注実務に影響します。

• 技術基準適合維持義務: 送配電・供給設備の技術基準への適合を継続的に維持する義務です。SCADA・需給管理・保安関連システムの刷新は、この義務に直接影響します
• 保安規程: 事業者は保安規程を届出し、その内容に沿った運用が求められます。基幹システムの改修は保安規程の見直しを伴うことが多く、届出タイミングと開発マイルストーンを整合させる必要があります
• 供給約款・託送供給等約款: 小売事業者の料金計算・請求システムは供給約款に直結します。約款改定と料金計算ロジックの改修は、リリースサイクル全体を規定する制約になります

規制情報は資源エネルギー庁の 電力・ガス基本政策小委員会 等で最新動向を追えます。自由化以降、託送料金や需給調整市場の制度改定が続いており、システム改修と制度改定のスケジュール整合はベンダー選定時に必ず確認しておきたい観点です。

電気通信事業における個人情報等の保護に関するガイドライン

通信事業者にとってとくに重要なのが、電気通信事業における個人情報等の保護に関するガイドライン（総務省） です。個人情報保護法に加えて、通信の秘密（憲法第 21 条第 2 項・電気通信事業法第 4 条）が上乗せされる点が特徴です。

• 通信の秘密の取扱い: 通信内容・通信履歴・位置情報等を保守運用の目的で取り扱う場合の要件が定められています。ベンダーがこれらのデータに接触する場合、社内規程・アクセス制御・ログ管理を含めた技術・組織的措置が求められます
• 外部委託先の監督義務: ガイドラインは、外部委託先（＝発注先ベンダー）に対する監督義務を明確にしています。委託契約における守秘義務・再委託承認・監査権の設定、および実効的な運用状況の確認まで、発注側の責任として要求されます
• 漏えい等発生時の報告義務: 個人情報保護委員会および総務省への報告義務があり、ベンダーとの間で報告フロー・時限・協力範囲を事前に取り決めておく必要があります

「ベンダーに任せていた」だけでは、事故発生時に発注側の監督責任が問われます。外部委託先監督義務を契約と運用の両面でどう果たすかが、規制業界の発注で最も差が出るポイントの 1 つです。

電気通信分野におけるサイバーセキュリティ安全基準・情報セキュリティマネジメント要件

技術的な安全基準としては、電気通信事業者協会 安全・信頼性協議会が公表する 情報通信ネットワーク安全・信頼性基準 系文書、および総務省の サイバーセキュリティ対策 関連ガイドラインが実務の下敷きになります。

• 多層防御の設計要件: 境界防御・エンドポイント防御・監視・インシデント対応の各層で求められる要件を、システム刷新の非機能要件に落とし込みます
• ISMS・PCI DSS 等の第三者認証: 個別ベンダーの認証取得状況は、規制業界での実力を示す代替指標として有用です。ただし認証取得と実運用の実効性は別の話であり、認証範囲・審査項目まで確認するのが実務です
• 重要インフラ分野の指針: 内閣サイバーセキュリティセンター（NISC）の 重要インフラの情報セキュリティ対策に係る第 5 次行動計画 等、業界横断の政策文書もベンダー側にキャッチアップを求める必要があります

この 4 領域を「今回の刷新スコープ」の観点でマトリクス化しておくと、次章以降のベンダー評価・契約設計で使い回せる社内フレームになります。

レガシー刷新の 4 つの選択肢と規制業界特有の制約

レガシー刷新の手法は一般的に「リホスト・リプラットフォーム・リファクタリング・リビルド」の 4 分類で語られます。しかし、規制業界ではどの手法を選ぶかよりも「何を残し、何を捨てられないか」を規制制約の観点から先に定義することが重要です。ここでは 4 手法を規制業界の視点で再評価します。

4 手法の概要と規制業界での適用余地

競合の汎用刷新記事では「リビルドが理想」と書かれがちですが、規制業界ではリビルドの前に、まず期日制約のある基盤（メインフレーム）をリホストで期日担保するのが現実解になるケースが多くあります。

なぜフルクラウドへの一気通貫刷新は規制業界で成立しにくいか

「メインフレームからパブリッククラウドへ、まとめて刷新する」というシナリオは、規制業界では次の理由から成立しにくいのが実情です。

• 重大事故報告義務との整合: 障害発生時の原因分析・報告義務を果たすために、ログ・トレース・データフローの可観測性を確保する必要があります。クラウド事業者のマネージドサービスに依存すると、詳細分析に必要な情報の粒度・保持期間が制約される場合があります
• データ主権・所在地の要件: 通信の秘密・個人情報のうち、機微性の高いデータの物理所在地について、社内規程で国内限定としているケースが多くあります。マルチリージョン・グローバルサービスとの相性は事前確認が必要です
• 既存の運用体制との断絶: 24 時間 365 日の運用体制、SLA、保安規程等を一気にクラウド前提へ移行することは、運用組織の変革コストが極めて高くなります

結果として、規制業界ではハイブリッド運用（オンプレ／プライベートクラウド＋パブリッククラウド）の段階移行が事実上の標準解となっています。刷新の全体設計は、この現実を出発点にすると議論が具体化しやすくなります。

通信の秘密・個人情報保護制約下でのデータ移行・並行運用の設計論

刷新プロジェクトで見落とされがちなのが、移行期間中のデータ取扱いと並行運用の設計です。旧システムから新システムへの切替は瞬間的には行えず、通常は数か月〜1 年程度の並行運用期間を挟みます。この間の設計論としては次の 3 点が重要です。

• データ最小化の徹底: 移行対象のデータのうち、旧側・新側の両方で保持する必要のあるものと、片側のみで済むものを厳密に分類します。通信の秘密・個人情報の複製が二重管理される期間を最小化するのが基本方針です
• アクセス経路の分離: 旧側・新側でアクセス権限・監査ログを分離管理し、切替期間中も外部委託先監督義務を果たせる状態を維持します。ベンダー側の作業者アクセスも同様に分離管理します
• ロールバック要件の明確化: 障害発生時のロールバック手順・データ整合性の担保方法を事前に決めておきます。規制上の報告義務は「気付いた時点から○時間以内」というタイムラインが多く、切替判断のスピード感を体制に埋め込みます

このあたりの設計は、規制業界の刷新実績を持つベンダーとそうでないベンダーとで大きく差が出ます。RFP 段階で並行運用期間の設計方針をベンダー側に説明してもらうと、実力の判定材料になります。

手法選択の意思決定フロー

上記を踏まえた実務的な意思決定の順序は、次のとおりです。

1. 保守終了時期が確定している基盤（メインフレーム等）はまずリホストで期日担保
2. 規制要件変更が頻繁な領域はリプラットフォームまたはリファクタリングで保守性を確保
3. 業務プロセス自体を大きく変える必要がある領域だけをリビルド対象に限定
4. 全体は数年〜10 年スパンのハイブリッド段階移行として設計し、途中で意思決定できるフェーズゲートを組む

「一気通貫の刷新」を諦めることで、かえって全体最適が見えてきます。この考え方は、次章の外注先評価にも直接つながります。

外注先を見極める規制業界特化 7 チェックポイント

ここまでで整理した規制フレームワークと手法選択を踏まえて、候補ベンダーを「規制業界対応の実力」で評価するチェックポイントを 7 つに絞り込みます。汎用の選定基準（実績数・単価・体制規模）ではなく、規制業界の発注で本当に差が出る観点に絞り込むのがポイントです。

1. 電気通信事業法・電気事業法対応の実務経験

確認すべきこと: 過去 3〜5 年で、電気通信事業者・電気事業者・ガス事業者の基幹システム開発・改修に関わった実績があるか。管理規程届出・保安規程届出のタイミングと開発マイルストーンを整合させた経験があるか。

確認方法: 「直近の代表案件で、規制上の届出とリリーススケジュールをどう整合させたか」を具体案件（守秘義務の範囲内で）で語ってもらいます。「規制側は発注者責任なのでノータッチ」という回答は、実質的な規制業界対応力が弱いことを示唆します。

2. 通信の秘密・個人情報保護ガイドラインを踏まえた設計・運用体制

確認すべきこと: 通信の秘密・個人情報を扱うシステムでの設計原則（データ最小化、目的別分離、アクセス制御、監査ログ）を、実装レベルで説明できるか。ベンダー内の作業者がデータに触れる場合の管理体制が明文化されているか。

確認方法: 「通信履歴を扱うシステムの保守作業で、どのようなアクセス制御・ログ管理・監査手順を運用しているか」を尋ねます。回答が「NDA を締結している」レベルに留まる場合、規制業界の要求水準には不足します。

3. 監督責任を果たすための報告・監査対応フロー

確認すべきこと: 外部委託先監督義務を発注側が果たすために必要な情報（作業ログ、変更履歴、インシデント報告、監査対応）を、どのような形式・頻度で提供できるか。監査時の立入検査・記録閲覧に協力する運用実績があるか。

確認方法: 「発注側が監査で確認したい典型項目（例: 直近 3 か月の全変更履歴と承認者、特権アクセスのログ）を、どの程度の粒度・期間で提供できるか」を具体的に確認します。契約時にログ保持期間を明記しておくと、後の紛争予防にもなります。

4. セキュリティ認証・監査実績

確認すべきこと: ISMS（ISO/IEC 27001）、PCI DSS、電気通信分野安全基準等の認証取得状況。単に取得しているだけでなく、認証範囲が今回の受託対象を含んでいるか、審査で指摘された事項への対応状況、外部監査への協力実績があるか。

確認方法: 認証書の「適用範囲」欄をコピーで確認し、今回の刷新対象システムが含まれるかを検証します。適用範囲外の認証を根拠にしている提案には注意が必要です。

5. 規制改正への追随履歴

確認すべきこと: 過去 3〜5 年の主要な規制改正（電気通信事業法 2022 年改正の外部送信規律、個人情報保護法 2022 年施行、電力・ガス自由化以降の託送料金制度改定 等）に、どの案件でどのような対応を行ったか。

確認方法: 「直近で発生した規制改正のうち、御社の関与案件に影響した改正は何ですか。どのタイミングで、どのような追加改修を行いましたか」を具体的に語ってもらいます。回答が抽象的なベンダーは、規制動向のキャッチアップ体制が弱い可能性があります。

6. 多重委託（再委託・再々委託）の管理体制と可視性

確認すべきこと: ベンダーが自社で完結せず、二次・三次の再委託を行っている場合、その範囲・可視性・監督体制。発注側から見て「どこまで誰がやっているか」が把握可能な状態か。

確認方法: 「再委託・再々委託の一覧、各社の担当範囲、責任者、監査履歴」を書面で確認します。再委託先を含めた外部委託先監督義務を果たせない場合、規制業界の発注は成立しません。

7. レガシー刷新 × 規制対応の統合スキル

確認すべきこと: メインフレーム・COBOL の保守経験と、モダナイゼーション（クラウド・マイクロサービス・データ基盤）の実績を、同一組織内で統合的に提供できるか。両者を別会社の連携で埋める場合、規制業界の統率力が弱い可能性があります。

確認方法: 「メインフレーム脱却プロジェクトで、規制側の要件をどう吸収しながら段階移行を設計したか」を具体案件で語ってもらいます。「メインフレームの知見はパートナー企業と連携」という回答は、実質的なプロジェクト統率力が弱い可能性を示唆します。

以上の 7 項目を RFP の評価表に組み込むと、汎用ベンダーと規制業界対応ベンダーとの差が明確に見えてきます。

契約設計と発注側ガバナンス

ベンダーを選定した後の契約設計と発注側ガバナンスは、規制業界では「刷新の成否を分ける」といっても過言ではない領域です。ここでは、監督責任を果たしながら複数ベンダー体制を機能させるための、実務的な設計論を整理します。

契約形態の選択

規制業界のシステム開発では、請負契約と準委任契約（いわゆる SES 型を含む）の使い分けが重要です。

• 請負契約: 成果物完成責任・瑕疵担保責任がベンダーに帰属します。要件が明確な機能開発・改修は請負が適します。ただし、規制業界特有の「要件がベンダーには開示できない部分（通信の秘密に関わる詳細等）」がある場合、成果物定義に工夫が必要です
• 準委任契約: 作業遂行が契約対象で、成果物完成責任は発注側に残ります。要件が流動的な設計・アーキテクチャ検討・データ移行の並行運用は準委任のほうが柔軟です。ただし、発注側が指揮命令を行うと偽装請負の問題が発生する可能性があるため、作業指示の系統をベンダー側 PM に集約する運用が原則です
• フリーランス契約の活用: 一部の専門領域（規制対応、セキュリティ設計、レガシー保守）では、フリーランスの専門家をスポットで組み込むアプローチも有効です。この場合も、業務委託契約の設計と実運用の整合が問われます

「請負にすれば発注側の責任がなくなる」わけではなく、規制上の外部委託先監督義務は契約形態を問わず発注側に残る点が要注意です。

SLA・稼働率・障害復旧時間

規制業界の SLA 設計では、通常の商用サービス基準に加えて、重大事故報告義務と整合するタイムラインが必要です。

• 稼働率目標: 99.9% / 99.99% 等の目標値だけでなく、計画停止の扱い・カウント方法・除外事由を契約に明記します。曖昧なまま契約すると、事故時の解釈で紛争になります
• 障害復旧時間（RTO）: 重大事故報告義務に対応するため、原因把握・復旧・報告文書作成までのタイムラインを RTO と整合させます
• 復旧手順の可視化: 障害発生時の連絡経路・意思決定フロー・エスカレーション先を、発注側とベンダーで事前に合意し、机上訓練で検証します

「SLA を高めに設定したから安心」ではなく、SLA を守れなかったときにどうやって規制上の報告義務を果たすかまで含めた設計が実務水準です。

外部委託先監督義務を果たすための契約条項と運用

契約条項として押さえたい代表項目です。

• 守秘義務: 対象情報の範囲、保管期間、契約終了後の返却・破棄
• 再委託承認: 再委託の事前承認、再委託先リストの提出、再委託先の監査権
• 監査権: 発注側の立入検査権、書面・電子記録の閲覧権、外部第三者を伴う監査への協力
• 報告義務: 定期報告（月次・四半期）の内容と形式、インシデント発生時の即時報告義務・報告文書の様式
• 契約終了時の引継ぎ: 業務・データ・ドキュメント・アカウント等の引継ぎ範囲と期間、後継ベンダーへの協力義務

条項を並べるだけでは実効性が担保されません。四半期に 1 回、条項に沿った運用が実際に回っているかをレビューする定例会を契約書と併せて設計すると、監督義務が形骸化しないための現実的な仕組みになります。

再委託・再々委託の管理

再委託は禁止するのではなく、「発注側が把握・監督できる範囲」で許可するという設計が実務的です。

• 再委託先リスト（社名・担当範囲・作業者数・所在地）を書面で管理し、変更時は事前承認
• 再委託先に対する監査権を発注側に留保
• 再委託先のセキュリティ認証・作業環境（社内 or 在宅）を明示
• 重要業務は再委託を禁止し、直接受託の範囲を明確化

「再委託先の管理はベンダーに任せている」だけでは、事故時に発注側の監督責任が問われます。少なくとも重要業務については、再委託先まで発注側が把握している状態を作ります。

マルチベンダー統制の設計

大手 SIer 一社依存から抜け出す道筋として、複数ベンダーを組み合わせるマルチベンダー体制は有力な選択肢です。しかし、複数ベンダーに任せるだけでは統制が取れず、かえって障害・遅延・責任分界の紛争リスクが増します。マルチベンダー統制で押さえたい 3 点は次のとおりです。

• PMO 機能の設置: 発注側または独立系の PMO ベンダーが、複数ベンダーの進捗・品質・リスクを横断管理する体制。PMO の権限と責任範囲を契約で明確化します
• 責任分界点の明示: 各ベンダーの担当システム・機能・データ・インターフェースを図として文書化し、境界での責任を明示します。障害発生時の一次切り分け責任を PMO に集約する設計が一般的です
• データ受渡し設計: システム間のデータ受渡しは、フォーマット・タイミング・エラー処理・監査ログを標準化します。ここが曖昧だと、複数ベンダー間の紛争が発生しやすくなります

「大手 SIer 一社丸投げ vs マルチベンダー」の二項対立ではなく、発注側ガバナンスをどう設計するかが実務の焦点です。丸投げ体制の代替として、発注側の統率力を PMO 機能に集約する設計が現実的です。

発注担当者が今週着手すべき 3 つのアクション

ここまで整理してきた判断軸を、実際の意思決定に落とし込むための具体的な行動に翻訳します。すべてを一度にやる必要はありません。次の 3 つを、時間軸を分けて着手することをおすすめします。

今週やる: 刷新スコープと関連規制のマトリクス作成

先ほど整理した 4 領域の規制フレームワーク（電気通信事業法・電気事業法・個人情報保護ガイドライン・サイバーセキュリティ安全基準）を縦軸に、今回の刷新スコープ（対象システム、扱うデータ、変更対象の機能）を横軸に取ったマトリクスを作成します。

• 各セルに「該当あり／なし／要確認」を記入
• 「該当あり」のセルには、根拠となる条文・ガイドライン項番と、関連する社内規程を紐付け
• 「要確認」のセルは社内の法務・コンプライアンス担当と協議する優先事項として整理

このマトリクスは、そのままベンダー RFP の「規制対応要件」セクションに転用できます。作成に要する時間は半日〜1 日程度で、着手の心理的コストが低いのが利点です。

今月やる: 既存ベンダーへの規制対応力ヒアリング

先ほど示した 7 チェックポイントを、既存ベンダーへのヒアリング項目に変換します。ヒアリングの目的は「既存ベンダーが規制業界対応力を実際に持っているかどうか」を客観的に評価することです。

• 各項目について、具体案件・具体手順・具体数値のいずれかで回答してもらう
• 抽象的な回答しか得られない項目は、その場では追及せず「別途書面で回答依頼」として持ち帰る
• ヒアリング結果は 7 項目 × 5 段階（例: A/B/C/D/E）で評価表にまとめる

このヒアリング自体が、既存ベンダーに「発注側の要求水準が上がった」というシグナルを送る効果もあります。結果として、既存ベンダーの提案品質が改善する副次的効果も期待できます。

3 か月以内にやる: 新規候補ベンダー 2〜3 社への RFP・初回打診

既存ベンダーだけで完結しない領域が明確になったら、新規候補ベンダー 2〜3 社への初回打診を行います。

• 初回打診では「規制業界での実績」「7 チェックポイントの自己評価」「参考案件の紹介可否」の 3 点を確認
• 全面提案ではなく、まずは「規制業界対応力の見極めのための初期対話」として位置づける
• 打診先の選定は、通信・エネルギー業界での実績が公表されているベンダーに加え、規制業界横断（金融・保険・医療等）で監督責任の実務経験を持つベンダーも候補に含める

新規ベンダーとの初期対話は、そのまま採用に直結する必要はありません。むしろ「候補プールを持っている」状態を作ることで、既存ベンダーとの交渉力が高まる効果を狙います。

まとめ

通信・エネルギー業界のシステム開発外注は、規制対応とレガシー刷新の二重制約という他業界にはない構造的な難しさを抱えています。本記事では、その難しさを次の 3 つの軸で解きほぐしてきました。

• 規制対応: 電気通信事業法・電気事業法・個人情報保護ガイドライン・サイバーセキュリティ安全基準を「今回の刷新スコープ」と紐付けて棚卸しできる状態を作ることが出発点
• レガシー刷新: 4 つの手法を規制業界の現実（重大事故報告義務・データ主権・並行運用制約）から再評価し、ハイブリッドの段階移行を出発点に据える
• 発注実務: 汎用の選定基準ではなく規制業界特化 7 チェックポイントで候補ベンダーを評価し、契約と運用の両面で監督義務を果たす仕組みを作る

大手 SIer 一社丸投げからの脱却は、マルチベンダーへの単純な切替ではなく、発注側ガバナンスの再設計そのものです。PMO 機能を設計し、規制対応力の見極め基準を社内標準化し、契約条項を実効的な運用に落とし込む——このプロセスを、今週・今月・3 か月という時間軸に分けて着実に進めることで、規制違反リスク・レガシー停滞・ベンダー選定不安の三重苦に道筋をつけられます。経営会議・稟議に持ち込める発注方針の骨子は、本記事のマトリクスと 7 チェックポイントから組み立てられるはずです。