新規事業の立ち上げ・事業化を支援するプロフェッショナルファーム

マネージドサービスとは?任せる範囲と7社の取り組み

マネージドサービスで、何を任せられるのか。
提供側として、どこから入れるのか。

マネージドサービスとは、クラウドや社内システムの監視・保守・運用を、外部の専門会社などに継続して任せる仕組みです。夜間の障害対応や設定変更を担ってもらい、社内の担当者が改善や企画に時間を使えるようにします。ただし、同じ名称でも、通知だけの契約と復旧まで含む契約があります。まず比べるべきなのは、障害が起きた後に誰が何をするかです。この記事では、国内外7社の取り組みから、任せられる仕事、費用の考え方、新規事業としての入り方を整理します。導入を考える方も、提供側に回りたい方も、サービス名ではなく仕事の分担で判断できるように解説します。

この記事の結論

監視・復旧・改善を分けると、任せる範囲と事業機会が見えてきます。

  • 国内外7社の提供物と、実証・運用の段階を整理
  • 対象・権限・完了条件から、契約の違いを理解
  • 三つの参入方法から、必要な資産と責任を考える

目次

マネージドサービスとは、ITの継続運用を任せる仕組み

まず、任せる「運用」が何を指すかをそろえましょう。ITシステムは、導入して終わりではありません。異常を見つけ、影響を調べ、設定を直し、同じ問題を防ぐ仕事が続きます。その一部または全体を、合意した範囲で担うのがマネージドサービスです。

たとえば、夜中に通販サイトが遅くなった場面を考えます。監視の仕組みが異常を見つけても、メールを送るだけなら、社内の担当者が起きて原因を調べます。契約に復旧作業まで含まれていれば、委託先が手順に沿って対応できます。

それでも、販売を止めるか、注文を受け付け続けるかは別の判断です。システムを操作する仕事と、事業上の損失を引き受ける判断を分ける必要があります。

「人を借りる」より「決めた仕事を継続して任せる」

マネージドサービスの提供者は、MSPと呼ばれます。マネージドサービスプロバイダー、つまり運用サービスを提供する事業者の略です。提供する会社の種類ではなく、担う役割を表す言葉と考えると理解しやすくなります。

契約では、対象のシステムや対応時間を定めます。サービス水準を約束する取り決めは、SLA(サービス品質に関する合意)と呼ばれます。ただし、SLAがあることと、事業の停止時間をすべて補償することは同じではありません。対象と条件を読む必要があります。

大切なのは、担当者の人数だけを買う発想から離れることです。何を任せ、どの状態を維持し、どこから先は自社へ戻すか。その組み合わせが商品の中身になります。NTTドコモビジネスの解説でも、運用の一部を担う形と、特定機能に絞る形が示されています。

監視・対応・改善は、別の仕事

任せる範囲は、次の三つに分けると整理できます。図は一般的な仕事の流れであり、どの契約にもすべて含まれるという意味ではありません。

監視で異常を知り、対応で元に戻し、改善で再発を減らす。三つの仕事は契約で個別に確認する
図1|AWS(アマゾン ウェブ サービス)およびサーバーワークスの公開サービス内容をもとに、イノベーション総研作成。監視・対応・改善の区分は理解のための整理です。

通知が速くても、対応する人が決まっていなければ停止は長引きます。復旧できても、同じ不具合を繰り返せば負担は減りません。導入効果を見る際は、委託した作業だけでなく、社内に残った作業まで追うことが重要です。

BPO・保守・クラウドサービスとの違い

任せる仕事が見えたら、似た言葉との違いを確認します。これらの言葉に、業界共通の厳密な境界があるわけではありません。名称を分けるより、契約の対象を見比べる方が実務では役立ちます。

BPO・保守・クラウド機能との比較
呼び方 中心となる対象 確認すること
BPO(業務プロセスの外部委託) 経理、受発注、顧客対応などの業務 どの業務工程を完成させるか
保守サービス 製品やシステムの維持、故障対応 問い合わせ、修理、復旧のどこまでか
マネージドサービス IT機能の継続運用 監視、作業、改善の分担と対応時間
クラウドのマネージド機能 データベースなど特定の技術機能 提供者が管理する部分と利用者の設定

たとえば、請求書の受付から会計処理までを任せるなら、中心はBPOです。その会計システムを夜間も動かし、障害を監視する仕事は、ITのマネージドサービスとして切り出せます。業務を外に出す全体像は、BPOの仕組みと企業事例で詳しく整理しています。

クラウドの「マネージド」と、運用代行は同じではない

クラウドでも「マネージドデータベース」のような名称を見かけます。この場合は、基盤の管理作業などをクラウド側が担う、製品機能の提供方式を指します。自社のIT運用を別会社へ委託する話とは、見る単位が違います。

機能を使うだけで、データの扱い方やアクセス権の設計まで自動的に適切になるわけではありません。AWSも、利用するサービスによって顧客側の責任が変わると説明しています。AWSの責任共有モデル

さらに運用会社を入れる場合は、クラウド提供者、運用会社、利用企業の三者になります。この三者の間に、誰も対応しない仕事を残さないことが要点です。

「フルマネージド」でも、対象外は確認する

フルマネージドという言葉は、広い範囲を任せられることを示します。ただし、あらゆるアプリケーションや業務判断まで含むとは限りません。

たとえば、サーバーの再起動は対象でも、自社開発のプログラム修正は対象外という契約は考えられます。バックアップは取得していても、戻したデータの整合性を確認する仕事は、自社が担うかもしれません。

名称だけで「全部任せられる」と判断しないことが大切です。復旧の完了条件を、業務が再開できる状態まで具体化して確認しましょう。

マネージドサービスを支える7社は何をしているか

ここからは、実際の企業の取り組みを見ます。クラウド基盤の運用、複数システムの統合、セキュリティ対応、自動化支援では、提供する価値が違います。以下は順位表ではなく、役割の違いをつかむための比較です。

マネージドサービスを支える7社の役割と段階
企業 取り組みの中心 公開情報で確認できる段階
AWS AWS環境の運用サービス「AMS」 サービス提供
サーバーワークス 監視と監視運用を分けたAWS支援 サービス提供
IIJ(インターネットイニシアティブ) 複数環境の監視・構成管理・自動化 サービス提供、自社運用で活用
NTTドコモビジネス 通信・クラウド・セキュリティの統合運用 サービス提供
CTCテクノロジー 運用会社のアラート対応を自動化 リコージャパンで実証後、本番への移行
キンドリル 運用知見をAIの実行手順として提供 検証サービスから提供方式を拡張
CrowdStrike(クラウドストライク) 脅威の検知・調査・対応を任せるサービス(MDR) サービス提供

表だけでは契約の違いが見えません。各社がどの困りごとを解き、どこまでを提供しているか、具体的に見ていきます。

AWS:クラウドを使った後の運用もサービスにする

AWSは、クラウド基盤そのものに加え、AWS Managed Services(AMS)を提供しています。AWS環境の監視、障害管理、セキュリティ、修正プログラムの適用、バックアップなどを支えるサービスです。AMSのサービス概要

注目したいのは、クラウドを提供する会社も「使い続けるための仕事」を商品にしている点です。基盤を借りるだけでは、運用の仕事が消えないことを示しています。

AMS Advancedの公開資料では、運用の状態やサービス水準、支出をまとめた月次報告も説明されています。AMS Advancedの機能

ただし、公開されている機能の列挙から、自社アプリの不具合まで一律に直してもらえるとは判断できません。利用するプラン、対象サービス、申請が必要な作業を確認します。基盤側が担える仕事と、自社の業務に詳しい会社へ依頼する仕事を分ける材料になります。

サーバーワークス:監視だけと、復旧を含む運用を分ける

サーバーワークスのAWS運用代行・監視サービスは、二つの基本プランを示しています。「監視プラン」と「監視運用プラン」です。後者には標準障害対応などを含み、特殊な復旧対応はカスタマイズとして区別しています。公式のプラン比較

この分け方は、見積もりの読み方として参考になります。同じ24時間365日でも、監視する時間の話なのか、実際に作業する体制の話なのかで、社内の負担は変わります。

同社は、AMSと自社の運用知見を組み合わせた「AMS統合MSP」も提供しています。既存の自動化基盤を使い、運用支援を重ねる方式です。AMS統合MSP

IRIが見る事業上のポイントは、すべての技術を自社開発する必要がないことです。一方、既存基盤を使う場合でも、顧客への窓口、例外対応、料金説明は残ります。販売代理だけで終わるのか、継続運用まで担うのかで必要な体制が違います。

IIJ:ばらばらの監視や台帳を一つにつなぐ

IIJの統合運用管理サービスは、クラウドと社内設置のシステムを横断して扱います。監視、構成情報の管理、定型作業の自動化などを組み合わせる、運用管理の基盤です。IIJ統合運用管理サービス

2023年には、サーバーだけでなく、ルーターなどのネットワーク機器から管理情報を集める機能も追加しました。機器ごとに異なる台帳を手作業で維持する負担に対応しています。IIJの機能追加発表

ここでは、運用ツールの提供と、人による作業の受託を区別して読む必要があります。ツールを使えば、情報は集めやすくなります。しかし、どの通知を優先し、誰が対応するかは、別に決める仕事です。

新規事業を考えるなら、異なる製品の情報をそろえる支援も候補になります。自社が詳しい業界の機器や古いシステムを、既存の運用基盤へつなぐ役割です。ただし、接続先ごとの個別開発が続くと利益を残しにくくなるため、共通化できる範囲を見極めます。

NTTドコモビジネス:複数の運用窓口をまとめる

NTTドコモビジネスのX Managedは、ネットワーク、クラウド、端末、セキュリティの運用を組み合わせて提供します。設計、導入、運用のメニューを選び、必要に応じてサービスマネージャーを置ける構成です。X Managedの提供内容

たとえば、拠点で業務が止まっても、原因が回線、端末、クラウドのどこかはすぐにはわかりません。窓口が分かれていると、社内の担当者が各社をつなぐ役割を負います。統合運用の価値は、その調整まで含めて考えると見えやすくなります。

ただし、窓口を一つにすることと、全機器の修理や全アプリの改修を含むことは別です。X Managedも、必要なサービス水準に応じてメニューを選ぶ方式です。

IRIは、複数社を束ねる際の価値を「責任者と連絡順が決まること」に見ます。提供側は、提携先の対応時間と自社が約束する時間をそろえる必要があります。受付だけを一本化しても、後ろの対応が途切れれば顧客の困りごとは残ります。

CTCテクノロジー:運用サービスを提供する会社の仕事を変える

リコージャパンは、顧客のシステムを監視・運用する側です。その現場でも、大量のアラートメールが負担になっていました。CTCテクノロジーは、障害対応を管理するPagerDutyを用いたITOXで、通知の整理と作業の自動化を支援しています。

CTCが2026年5月に公開した事例では、実証でサービスデスク全体の工数を約20%削減したと報告しています。ただし、2026年3月時点は手動対応との並行稼働で、完全な切り替えは未了です。本番運用全体で同じ削減率が確定した数字ではありません。リコージャパンの導入事例

この事例からわかるのは、運用会社も外部の技術や経験を必要とすることです。最終顧客を直接取りに行く以外に、運用会社の業務を改善する事業が考えられます。

また、実証で動いた仕組みを本番へ移すと、古いシステムとの接続や文字化けなどが課題になりました。ツールの機能より、既存環境との違いを埋める仕事が重要だった点に注目できます。成果値だけでなく、移行中に何が残ったかを読むべき事例です。

キンドリル:運用の経験を、AIが実行できる手順へ変える

キンドリルは、社内設置とクラウドが混在するIT環境の運用を担う企業です。2025年9月には、人の監督のもとでAIが業務を行う仕組みを国内提供し、専用クラウド上の検証サービスを発表しました。国内の検証サービス発表

2026年8月には、運用の知見をAIの実行手順として体系化し、Kyndryl Bridgeを通じて展開する提供モデルを発表しています。提供モデルの拡張

これは、ベテランが毎回考えていた作業を、再利用できる手順に変える動きとして読めます。人を減らす話だけでなく、同じ知見を複数の顧客へ届ける方法の変化です。

ただし、発表から、すべての顧客環境で無人運用が成立したとはいえません。どの操作をAIへ許すか、人がどこで監督するかは残ります。新規参入者にとっても、汎用AIの性能を競うより、特定業務の手順と修正履歴を蓄積する方が、自社の役割を定めやすくなります。

CrowdStrike:警報を出すだけでなく、脅威への対応を担う

CrowdStrikeのFalcon Completeは、MDRを提供します。MDRとは、攻撃の兆候を見つけ、調べ、対処する仕事を外部へ任せるサービスです。公式ページでは、自動化やAIエージェントと、24時間365日の専門家による監視を組み合わせています。Falcon Completeのサービス内容

セキュリティ製品を入れても、警報が本当の攻撃なのかを調べる仕事は残ります。さらに、端末を通信から切り離すと、攻撃を抑える一方で業務が止まる場合があります。機能の有無だけでなく、対応までを誰が担うかが重要です。

導入側は、守る端末やクラウドの範囲、許可する操作、連絡方法を確認します。セキュリティ対応が完了しても、事業データの復元や顧客への説明まで含むとは限りません。

提供側が専門会社と組むなら、自社は顧客の業務理解や初期設定を担い、専門対応を提携先へ任せる形も考えられます。ただし、具体的な販売・提携条件は別途確認が必要です。ここで示した役割分担は、各社の募集内容ではなく、IRIの事業分析です。

企業事例を並べると、共通する変化が見えてきます。異常を知らせるだけでなく、情報をまとめ、対応案を出し、決められた作業を実行する方向です。ただし、AIの利用と完全自動化を同じものとして扱わないことが大切です。

自動化しやすいのは、条件と戻し方が決まった作業

同じ原因で出る通知をまとめる。決めた条件で担当者へ連絡する。停止しても影響の小さい処理を再起動する。こうした仕事は、前提をそろえれば自動化を検討しやすくなります。

反対に、売上への影響が読めない停止や、大量の権限変更は慎重な判断が必要です。AIが原因らしい説明を作ったことと、実際の原因が確定したことも違います。

自動化率だけでは、サービスの価値は判断できません。誤った操作を防げたか、必要なときに人へ渡せたか、元の状態へ戻せたかまでを見る必要があります。AIに仕事を実行させる仕組みは、AIエージェントの事業機会でも解説しています。

運用会社の競争は「人数」から「繰り返せる手順」へ広がる

IRIは、マネージドサービスの競争力を、単に対応者を多く抱えることだけでは測れないと考えます。顧客の環境を把握し、同じ問題への対応を再利用できることが重要です。

理由は、個別対応ばかりでは、顧客が増えるたびに人員と調整が必要になるためです。共通の手順が増えれば、人は判断の難しい問題に時間を使えます。ただし、現場の差を無視して標準化すると、かえって障害を増やすおそれがあります。

事業機会を考えるなら、市場全体の金額だけでなく、何が繰り返し有料で依頼されるかを見ます。通知を整理する仕事なのか、複数社への連絡なのか、実際の復旧なのか。支払う理由を作業単位で把握すると、自社が担える範囲を絞れます。

自社の状況から、次に確認することを選ぶ

該当する項目を開くと、記事の読む場所がわかります。点数を付ける診断ではありません。

01 基本から知りたい

監視・対応・改善を分けます。

  • 何を任せるか
  • 通知だけか
  • 復旧までか

基本の仕組みを見る →

02 似た用語と比べたい

業務とIT運用の対象を分けます。

  • BPOと何が違うか
  • 保守と何が違うか
  • クラウド側が担う範囲は何か

呼び方の違いを見る →

03 企業事例を知りたい

提供物と運用の段階を比べます。

  • 誰に提供するか
  • どの仕事を担うか
  • 実証か運用か

国内外7社を見る →

04 契約を比較したい

対象・権限・完了をそろえます。

  • どこまで対象か
  • 操作を許可するか
  • 何を完了とするか

契約の確認点を見る →

05 参入方法を選びたい

自社資産と担当する仕事を重ねます。

  • 顧客接点があるか
  • 接続技術があるか
  • 運用知見があるか

三つの参入方法を見る →

06 事業案を相談したい

機密情報を出さずに整理します。

  • 誰が困っているか
  • どの負担を減らすか
  • 何を自社で担うか

相談前の情報をそろえる →

NEXT STEP

次のステップ

顧客の運用負担を、継続サービスの事業案へ

対象の顧客、任せてもらう仕事、自社が担える範囲をそろえます。機密情報や認証情報は不要です。

見積もりは、月額より先に対象と責任をそろえる

自動化が進んでも、契約の曖昧さは解消しません。各社の価格を比べる前に、同じ仕事を見積もっているかを確かめましょう。出発点になるのは、対象、権限、作業の完了条件の三つです。

対象・権限・完了の三つをそろえて運用を任せる。何を見るか、何をしてよいか、どこまでで完了かを合意する
図2|AWSの責任共有モデルと各社の公開サービス内容をもとに、イノベーション総研作成。三つの軸はIRIによる契約確認の整理です。

対象:台数だけでなく、接続関係を確認する

サーバー10台でも、同じ構成が10台ある場合と、別々の業務が動く10台では負担が違います。つながる機器、開発会社、使う時間帯まで整理します。

特に見落としやすいのが、委託先の担当外にある依存先です。たとえば、クラウド側を直しても、社内の通信設定が原因なら業務は戻りません。関連する会社の連絡先と、調整する責任者も必要になります。

権限:実行できる作業と、承認が必要な作業を分ける

操作の権限を渡さずに、すぐ直してほしいと求めても対応は進みません。一方、必要以上に強い権限を常時渡すと、事故時の影響が大きくなります。

通常の作業、緊急時の作業、人の承認を待つ作業を分けます。担当者が不在のときの連絡先も決めておきます。特定のネットワーク製品を買えばこの問題が解決するわけではありません。ゼロトラストの考え方も、アクセスを無条件に信用しない運用を考える材料です。

完了:連絡した時点か、業務が戻った時点か

見積書の「障害対応」という一語だけでは、完了条件がわかりません。受け付けた時点、作業に着手した時点、システムが動いた時点はそれぞれ違います。

たとえば、受注画面が開くようになっても、注文データの一部が欠けていれば、業務は通常状態に戻っていません。業務側の確認は誰が行い、いつ運用会社へ完了を伝えるかまで決めます。

契約前には、次の五つを一枚にまとめると話が進みやすくなります。

  • 対象のシステムと、対象外のシステム
  • 通知、調査、標準復旧、個別修正の担当
  • 作業を承認する人と、緊急時の連絡順
  • 作業記録の保存先と、顧客が見られる内容
  • 契約終了時に返してもらうデータと手順書

これらは契約書の代わりではありません。自社と委託先の認識の違いを見つけるための確認項目です。重要システムの契約では、担当部門に加え、法務やセキュリティの責任者と条件を詰めます。

マネージドサービスの費用は何で決まるか

責任の範囲がそろってから、費用を比較します。安い月額だけを見ても、社内に戻る作業や別料金が多ければ、総負担は下がりません。導入時と継続時を分けることが大切です。

運用を任せる際の費用項目
費用の区分 主な変動要因 見落としやすい項目
初期設計・移行 現状の整理、監視設定、手順の作成 古い台帳の修正、引き継ぎ、並行稼働
月額の運用 台数、利用者、拠点、対応時間、作業範囲 電話連絡、休日対応、定例報告
個別作業 特殊な復旧、設定変更、新しい接続 依頼のたびに発生する追加料金
技術基盤 クラウド利用、監視・管理ツール 保存期間に応じたログ費用、通信費
終了・切り替え データ出力、手順書の移管、後任への支援 契約終了後の閲覧や移行作業

契約によっては、これらが基本料に含まれます。別契約になる場合もあります。表の項目を単純に追加費用とみなさず、見積もりのどこに入っているかを確認してください。

導入側は、社内に残る確認時間も計算する

比較するのは「現在の総負担」と「導入後の総負担」です。導入後には、委託料、技術基盤の費用、残る社内作業、移行費用が含まれます。

たとえば、作業そのものは外へ出せても、依頼のたびに担当者が詳細な指示を書いていれば、別の負担が増えています。問い合わせ件数が減ったのか、処理の時間が減ったのか、夜間の呼び出しが減ったのかも分けて見ます。

さらに、時間が空いても、すぐに人件費が減るとは限りません。その時間を新しい開発や改善へ振り向けるなら、その価値を別に評価します。費用削減と、担当者が別の仕事をできることを混同しない方が、導入後の評価も安定します。

提供側は、例外対応が増えたときの採算を確認する

月額契約では、顧客が増えると売上の見通しを立てやすくなります。ただし、対応件数が増えるほど利益が増えるとは限りません。追加料金を取れない例外対応が増えれば、原価が先に膨らみます。

サービス別に見るべきなのは、通常作業、個別対応、待機体制、提携先への費用です。一人の熟練者しか直せない問題が多いなら、その人が休んだときも契約を守れるかを確認します。

自動化による原価低下は重要ですが、すべてを成果報酬にすればよいわけでもありません。障害を起こさない価値を、発生件数だけで課金するのは難しいためです。固定料、利用量、対象外作業の料金を組み合わせ、何を維持する対価なのかを説明できる設計が必要です。

新規事業としてマネージドサービスへ入る三つの方法

費用の構造が見えると、参入方法も絞れます。新しく総合運用会社を一からつくる方法だけではありません。業界の顧客を持つ会社、システムをつなげる会社、運用経験を持つ会社で、入り方は変わります。

顧客接点を持つ会社は運用窓口へ、接続技術を持つ会社は連携支援へ、運用知見を持つ会社は自動化支援へ。自社資産と参入役割の対応
図3|本記事の企業事例を参考に、イノベーション総研作成。企業の提携募集ではなく、自社資産から参入役割を選ぶための分析です。

1.特定業界の顧客接点から、運用の窓口をつくる

たとえば、地域の多店舗企業へIT機器を販売してきた会社なら、機器の販売後に残る運用をまとめる方法があります。最初の顧客は、すでに業務や拠点を理解している企業です。

提供するのは、問い合わせの受付、状況の整理、専門会社への引き継ぎ、対応の進み具合の管理などです。売上は初期整理と月額の窓口運用でつくります。故障修理や高度なセキュリティ対応は、専門会社との分担を検討できます。

必要な資産は、顧客との関係だけではありません。機器台帳と、業務への影響を判断できる知識が必要です。店舗が開いている時間に、誰が連絡を受け、どこまで動けるかも整えます。

懸念は、受け付けた後の責任が曖昧になることです。提携先が対応できない時間帯まで自社が約束するなら、その差を埋める体制が要ります。自社も提携先も復旧を担えない対象は、最初の契約へ含めるべきではありません。

2.接続技術を生かし、ばらばらの情報をそろえる

異なる製品やクラウドをつなぐ技術があるなら、運用に必要な情報を集める支援が候補になります。顧客は、監視や台帳が部門ごとに分かれている企業、または複数顧客を運用するサービス会社です。

最初の提供物は、接続設定、項目のそろえ方、運用台帳、引き継ぎ手順などです。初期構築費に加え、接続先の変更へ対応する保守料を設計できます。既存の監視製品や管理基盤を使えば、その基盤自体を開発する必要はありません。

ただし、機密情報や認証情報の扱いには十分な注意が必要です。どの情報を収集してよいか、どの場所へ保存するかを顧客と合意します。接続先の仕様変更を誰が追うかも契約に入れます。

毎社で一から開発するなら、継続サービスではなく個別受託に近づきます。共通部品を再利用できるか、更新費用を回収できるかが成立条件です。接続の許可や技術資料を得られない場合は、提案する範囲を狭めるか、製品会社との協力を先に進めます。

3.運用の知見を、他社が使える自動化手順へ変える

自社で多数の障害対応をしてきた会社なら、対応手順や判断の分岐を商品にする方法があります。最初の顧客は、同じ製品や似たシステムを運用する企業です。CTCテクノロジーの事例のように、運用会社を顧客とする余地もあります。

売るのは単なるAIの導入ではありません。対象作業の整理、通知の統合、自動実行できる手順、戻し方、継続的な更新です。初期設計料と、対象範囲に応じた継続支援料を組み合わせる形が考えられます。

必要な資産は、使ってよい対応履歴と、それを一般化できる経験です。他社の秘密や契約上使えない情報を、自社の学習材料に流用してはいけません。自動実行の基盤や専門分野の確認は、外部の技術会社と分担する方法もあります。

この方法の懸念は、例外を標準の手順へ押し込むことです。誤作動の影響を抑えられず、停止や元に戻す方法も決められない作業は、いきなり自動実行にしません。最初は通知の整理や対応案の提示など、人が判断できる範囲から役割を決めます。

運用を任せるときに残る四つの懸念

参入にも導入にも機会はありますが、任せたことで見えにくくなるものもあります。特に重要なのは、社内の判断力、委託先への依存、セキュリティ、評価の偏りです。

社内に、説明できる人がいなくなる

運用を任せると、社内が細かい手順を覚える必要は減ります。しかし、何のためのシステムか、どの停止を許容できるかまで外へ出すと、変更を判断できなくなります。

社内には、業務の責任者と委託先を管理する役割を残します。月次報告では、件数だけでなく、重要な変更、未解決の課題、次に決めることを確認します。丸投げを避けるために全部を内製する必要はありません。自社が判断する部分を明確にすることが重要です。

切り替え時に、必要な情報が戻らない

長く運用してもらうほど、委託先には手順や構成情報が蓄積されます。それが自社から見えず、契約終了時にも取り出せなければ、次の会社へ移しにくくなります。

だからこそ、開始時に終了時のことも決めます。構成図、作業履歴、監視条件、連絡先をどの形式で渡してもらうか。引き継ぎにかかる作業と費用は何か。これらは信頼していないから聞くのではなく、業務を継続するための準備です。

委託先の操作や接続が、新しいリスクになる

運用会社は、複数の重要システムへ接続できる場合があります。便利になる一方で、その権限が不正に使われたときの影響も考える必要があります。

担当者ごとの権限、操作記録、接続の許可、再委託の範囲を確認します。ログを残していても、誰も見ない状態では問題を見つけにくくなります。異常を確認する人と、記録を調べられる方法まで決めます。

ネットワークとセキュリティをまとめる技術は、SASEの構成と事例も参考になります。ただし、製品の選定と、日々の運用責任の決定は別の仕事です。

速さだけを評価して、必要な確認が省かれる

対応件数や平均時間だけを評価すると、早く閉じることが目的になる場合があります。ところが、同じ障害が翌日また起きれば、本当に改善したとはいえません。

評価には、再発、業務への影響、引き継ぎの不備も含めます。通知を減らした結果、重要な異常を見落としていないかも確認します。数値を一つに絞りすぎず、顧客が困っていた状態が変わったかを見ることが大切です。

自社の資産から、参入・提携・見送りを考える

最後に、どこから動くかを整理します。最初に集めるのは、競合の機能一覧ではありません。顧客が何に困り、自社がどこまで継続して担えるかを示す情報です。

まず、繰り返し起きている仕事を一つ選びます。夜間の通知、拠点からの問い合わせ、古いシステムとの接続など、担当者が具体的に説明できるものにします。

次に、その仕事を減らすために必要な情報、権限、体制を確認します。専門会社を組み合わせればできるのか、自社にしかない業務知識が役立つのかを見ます。事業案を文書へまとめる際は、新規事業企画書の構成も使えます。

参入:同じ仕事を、複数の顧客へ提供できる

顧客の困りごとが共通し、対応手順を再利用できるなら、継続サービスとして検討しやすくなります。条件は、範囲内の作業を約束した水準で続けられることです。

売上だけでなく、例外対応、担当者の交代、基盤の費用まで含めた採算を確認します。問題が起きない月も、必要な体制を維持できる価格であることが重要です。

提携:顧客の理解はあるが、専門対応が不足する

顧客接点や業務理解はあるものの、夜間の復旧や高度なセキュリティ対応を持たない場合は、提携が候補になります。自社が受付と調整を担い、専門会社が技術対応を担う形です。

ただし、提携先がいることだけでは十分ではありません。見積もり、作業依頼、緊急時の連絡、記録の引き渡しを一つの流れにする必要があります。顧客が複数社を自分で調整する状態のままなら、統合する価値は小さくなります。

待機・見送り:権限、復旧、価格のどれかが成り立たない

需要があっても、必要な接続を許可してもらえないなら、まず条件の整理が先です。待機中に、対象範囲を狭める、製品会社と協議するなどの対応が考えられます。

一方、守れない復旧水準や、採算を割る価格でしか契約できない場合は見送りも必要です。IT運用では、受注してから体制を考えると、顧客の事業を危険にさらします。

イノベーション総研では、顧客課題、自社の資産、提供範囲、収益の条件を整理し、新規事業の入り方を検討します。機密の構成情報や認証情報を送る必要はありません。「誰の、どの負担を減らしたいか」から、事業案の相談を進められます。

マネージドサービスに関するよくある質問

ここでは、初めて検討するときに混同しやすい点をまとめます。具体的な対象や責任は、各社の契約と利用条件で確認してください。

Q. マネージドサービスとBPOは何が違いますか?

A. BPOは経理や顧客対応などの業務プロセスを中心に見ます。マネージドサービスは、IT機能の継続運用を中心に使われる言葉です。重なる領域もあるため、名称よりも任せる対象と完了条件を確認することが大切です。

Q. 24時間365日なら、障害はすべて直してもらえますか?

A. いいえ。監視して通知する時間を指す場合と、作業する体制まで含む場合があります。標準の復旧、個別の修正、アプリケーションの不具合が、それぞれ契約に含まれるかを確認します。

Q. クラウドのマネージド機能を使えば、運用会社は不要ですか?

A. 自社の体制と必要な作業によります。クラウド側が管理する部分が増えても、自社のデータ、設定、接続、業務の確認は残ります。残る仕事を社内で担えるかを整理してから、外部へ任せる範囲を決めます。

Q. 新しく参入するなら、どこから始めるべきですか?

A. 顧客接点があれば運用窓口、接続技術があれば情報連携、運用経験があれば自動化支援が候補になります。いずれも、対象の仕事、必要な権限、復旧の責任、継続費用が明確にできることが前提です。

まとめ|マネージドサービスは「任せた後」で選ぶ

マネージドサービスは、ITを導入した後の仕事を継続して支える仕組みです。クラウド運用、複数システムの統合、セキュリティ、自動化支援では、各社の役割が異なります。

比較するときは、監視だけか、対応までか、改善までかを分けます。対象、権限、完了条件をそろえてから、社内に残る仕事を含めた費用を確認してください。

新規事業としては、自社の顧客接点、接続技術、運用知見が出発点になります。任せた後に顧客の負担がどう変わるか。それを具体的な仕事と責任で説明できることが、選ばれるサービスを考える第一歩です。

CONTACT

お問い合わせ

どの運用を、自社の事業にできるか

顧客、提供範囲、提携先、継続費用を整理します。運用の困りごとと自社の強みから、参入や提携の進め方をご相談ください。

ARTICLE INFORMATION

この記事の執筆・監修

執筆

イノベーション総合研究所 編集部

監修

長尾 浩平(株式会社イノベーション総合研究所 代表取締役)

外部出典

AWS、サーバーワークス、IIJ、NTTドコモビジネス、CTC、キンドリル、CrowdStrikeの公式資料。出典は該当箇所に記載。参入方法と三つの確認軸はイノベーション総研の分析。

この記事をシェアする