かんたんDXコラム

情シスの採用を進めようとしても、思うようにいかない――そんなお悩みを抱える方も少なくないのではないでしょうか。

背景には、単に“人材が足りない”という話だけではなく、情シス（社内SE／コーポレートIT）という仕事が担う範囲の広さや、社内側での役割整理の難しさがあると考えられます。

たとえば、求人を出しても応募が集まらない・来てもミスマッチで早期離職につながる、という採用難航のケース。
あるいは、退職・休職で突然穴が空き、入退社対応やアカウント管理、問い合わせ窓口などの“止められない運用”が回らなくなる緊急事態。
小〜中規模の企業では、総務・人事など管理部門が情シスを兼任し続け、限界を感じて初めて情シス採用を検討し始めることもあるようです。

こうした状況で重要なのは、採用のノウハウ以前に、まず
「情シスに何を任せるのか」、「どこまでの業務を社内で持ち、どこからの業務を外部委託も含めて考えるのか」を整理することです。

情シスの採用が難航しているときほど、業務を分解して「採れるポジション」に組み替えたり、採用が決まるまでの間は一時的に外部の力を借りて眼の前にある問題に対して“止血”し、体制を立て直したりすることが、結果的に現場を守れるケースもあるでしょう。

この記事では、情シスの採用が難航する背景を紐解きながら、採用・外注（アウトソーシング）・併用（コソーシング）を含めて、無理なく“回る状態”を作るための考え方と手順を整理します。

情シスの採用で採るべき人材の役割は何か

情シスの採用を考え始めたときに、最初に直面しやすい問題の１つは「情シス」という言葉の中身、つまり「業務の性質」や「業務範囲」が会社によって異なることでしょう。

ある会社では「PCとアカウント管理などの管理業務が中心」、
別の会社では「DX推進などのIT企画が中心」、
また別の会社では「社内SE＝情シス＝何でも屋」　といった具合です。

この状態のまま採用活動を進めると求人内容が曖昧になり、求職者から見ると「結局、何をやる仕事なのだろう？」となりがちです。
結果として、応募が集まらない・面接しても噛み合わない・入社後にギャップが起きる……という流れが起きやすくなるようです。

これらの採用活動や採用後の問題を予防するために、まずは情シス（社内SE／コーポレートITを含む）が担う役割を分解して、全体像をつかむところから始めてみるのはいかがでしょうか。

本章では情シスの主な役割、社内SEや情シスといった呼び方のズレによって起こりやすいミスマッチの内容についてご紹介します。

情シスの主な役割とは

情シス（社内SE／コーポレートIT）の仕事は、「社内のIT運用を回す」こと、「社内のIT環境を良くする」ことの両方を抱えやすいのが特徴です。

運用（ITオペレーション）

会社のITが「日々ちゃんと動き続ける」ようにする仕事です。

主な業務：

• • 入退社・異動に伴うアカウント発行・停止
  • PCキッティング
  • アカウント・ライセンス管理
  • 社内ネットワークや機器の保守　など

ヘルプデスク（問い合わせ対応・一次切り分け）

社員からの「困った」を受け止める窓口です。

主な業務：

• • 社員からの問い合わせ対応
  • PCやシステムの障害対応
  • FAQ整備　など

IT企画（導入・改善・標準化）

「新しいツールを入れる」だけではなく、社内全体の「IT利用の形を整えていく」役割です。

主な業務：

• • グループウェアやSaaSの導入・入替
  • ワークフロー整備
  • 業務標準化　など

セキュリティ（統制・ガバナンス）

セキュリティは「守る」ことが役割ですが、実務はルール策定から運用・監査対応まで幅広く、整備と運用には想像以上に工数がかかります。

主な業務：

• • アカウント・権限の設計
  • ログ管理
  • 端末セキュリティ
  • セキュリティポリシー策定
  • 教育
  • 委託先管理
  • 監査対応　など

ベンダー管理（外部との折衝・契約・品質管理）

すべての情シスの仕事を内製で回している会社の方が少数派です。
SaaS利用、保守ベンダー、回線、システム会社など、外部と一緒に成り立っています。

参照：情シス業務の外部委託に関する実態調査 ― 株式会社バッファロー
https://www.buffalo.jp/press/detail/20240918-02.html

---

上記に挙げたものは情シス業務の一例になります。

情シスの役割の詳細についてはこちらの記事で具体的にご紹介しています。
合わせてご覧ください。

社内SE・コーポレートIT・情シスの違いによる採用のミスマッチ

社内SE・コーポレートIT・情シス――これらは似た言葉ですが、求職者が想像する仕事内容にズレが生じることがあり、それが採用のミスマッチを生むようです。
以下はよくある言葉のイメージ差です。

社内SE

求職者側：
業務システムや社内アプリ、基幹系のシステム運用に近いイメージを持つ人がいるようです

企業側：
PC管理・ID管理・社内ヘルプデスクも含めて社内SEと呼ぶ場合もあるようです

情シス（情報システム）

求職者側：
システム運用・社内ヘルプデスク・PCやID管理が主戦場という印象を持ちやすいようです

企業側：
導入企画・セキュリティ管理まで広く含める場合もあるようです

コーポレートIT

求職者側：
SaaS最適化、IT企画、ゼロトラストセキュリティなど“モダンな改善”寄りを期待しやすいようです

企業側：
実態は問い合わせとPCキッティングが中心、ということも起きるようです

ミスマッチを減らす「4つの確認ポイント」

大切なのは呼び方を揃えるより、求人票や面接で次の4点を揃えることではないでしょうか。

1. 1. 担当範囲（やること／やらないこと）
      例：「ヘルプデスク中心」「端末・ID管理中心」「IT企画も担当」など
   2. 責任範囲（決める／回す／提案する）
      実務担当なのか、リードして設計する役なのか
   3. 働き方の前提（対応時間・夜間対応・オンサイト比率）
      働き方が曖昧だと、入社後の不満になりやすいようです
   4. 体制（ひとり情シスか／チームか／外部支援があるか）
      同じ「社内SE」でも、体制が違うと求められるスキルが変わってくるので明確にする必要があるでしょう。

この4点が揃うと、求職者側も判断しやすくなり、結果としてお互いのミスマッチを減らすことに繋がるでしょう。

情シスの採用が難しい理由

情シスの採用が難航するとき、つい「給与を上げれば解決するのでは？」「求人媒体を変えれば…」と採用テクニックに目が向きがちです。

それらはもちろん大切ですが、情シス特有の問題は、もっと手前の役割の広さと期待値のズレで起きていることが少なくないようです。

ここでは、情シスの採用が難しくなる理由を「市場の現実」と「社内の設計」に分けて整理します。

市場の現実：守備範囲が広い／即戦力偏重／採用競争

「情シス」と言った瞬間に、守備範囲が広く見える

情シスの仕事は、会社によって範囲が大きく変わります。

PCやスマホの管理・ID運用が中心の会社もあれば、インフラ運用・セキュリティ・ベンダー管理・IT企画まで含む会社もあるようです。

求職者の側から見ると、「情シス募集」と書かれているだけで、

• • どこまでやるのか分からない
  • 「何でも屋」の可能性がある
  • 緊急対応や夜間対応があるかもしれない

といった不安が先に立ちやすくなります。
結果として、応募者が集まりにくいといったことがあるようです。

「入社してすぐ業務を回せる人」が求められやすい

情シスは止められない業務が多い分、現場ではどうしても即戦力を期待しがちです。

ただ、実際には社内の環境（ネットワーク、SaaS構成、端末管理、申請フロー、権限設計、ベンダー契約など）を把握しないと動けない領域も多く、完全な即戦力を最初から求めるほど採用の難易度が高くなる傾向があります。

• • 「幅広く対応できる方」＝人材要件、求めるスキルが青天井に見える
  •  「経験〇年以上」＝応募が絞られ過ぎる
  •  「一人で回せる方」＝リスクが重く見える

など、このギャップは募集の段階でよく表面化するようです。

採用競争はIT人材全体とバッティングしやすい

情シスは社内向けの役割である一方、スキルセットはIT市場全体と重なる部分が多いです。

そのため、同じ求職候補者を、開発職・インフラ職・SRE・セキュリティ職などの求人と取り合う構図になりやすく、「条件勝負」だけでは勝ちにくい局面が出てくることもあるようです。

市場要因に対する現実的な考え方は、採用テクニックを積むこと以上に、この会社の情シスは何を任され、何を任されないのかを明確にして、安心して応募できる状態を作ることです。

社内要因：仕事内容が曖昧・何でも屋化している

市場の難しさ以上に、社内側の要因が採用を詰まらせていることもあるでしょう。
特に多いのは、次の2つのようです。

仕事内容が「相手にイメージを委ねる言葉」でしか説明できていない

募集側が「情シス業務全般」「社内SEとして幅広く」などと書いてしまう背景として、自社の情シス業務が棚卸しされていないことが原因の場合があるようです。

• • 問い合わせは月に何件で、どんな内容が多いのか
  • 入退社・異動は月に何回あるのか
  • PCキッティングは何台で、標準化されているのか
  • SaaSはいくつあり、誰がオーナーで、更新はどうしているのか
  • 障害・トラブル対応はどれくらい起きているのか

こうした現物（＝仕事）が見えないまま募集を作ると、どうしても求人票が抽象的になり、求職者からすると判断材料が足りないといった状況を生み出してしまいがちです。

「全部やってほしい」が無意識に混ざる

情シスの現場が忙しいほど、「一人採用できたら、これもあれも解決したい」と期待が膨らみやすくなるようです。

その結果、「ヘルプデスクも」「端末・ID運用も」「ネットワークも」「セキュリティも」「SaaS導入・改善も」「ベンダー管理も」…が1つの求人に混ざり、求職者には「負荷が高そう」「入社しても回らなそう」に見えてしまいます。

採用側としては「幅広く経験できる魅力」と言いたくなるのですが、責任と割り込みが集中しやすい構造に見えやすく、敬遠される原因になることもあるようです。

社内要因の対策としては、仕事を棚卸しして、性質の違う業務を分け、任せ方（採用・外部・併用）を設計し直すことが効果的でしょう。こちらは次章で詳しく説明します。

年収・待遇だけが原因ではない

求人を出すうえで、年収や待遇は重要です。しかし、情シスの採用では待遇より前に「期待値が読めないこと」の不安が勝って応募が止まるケースがあるようです。

応募を止める期待値が読めない要素

求人や面接で、次の点が曖昧だと求職者は判断を保留しやすくなるようです。

• • 担当範囲：どこまでが自分の仕事か（やらないことは何か）
  • 権限　　：管理者権限は付与されるのか／最終判断は誰がするのか
  • 体制　　：一人なのか、チームなのか、相談相手はいるのか
  • 優先順位：問い合わせ対応と改善業務はどう両立するのか
  • 対応時間：夜間対応・休日対応・緊急呼び出しの有無
  • 引き継ぎ：何がドキュメント化されていて、何が属人化しているのか

これらが明確になるだけで、「この会社の社内SEは、無理なく成果を出せそうか」が判断できるようになり、結果的に応募・選考が進みやすくなる可能性があります。

待遇を上げても“曖昧さ”が残ると決まりにくい

年収を上げること自体は有効策の１つになり得ますが、仕事内容の曖昧さが残ったままだと、

• • 応募数が増えない
  • 面接でミスマッチが続く
  • 採用できても「聞いていた話と違う」が起きやすい

という形で、別の問題が残りやすくなります。

「採用できない」状況ほど、外部活用も視野に入れる

期待値を明確にするには、業務の棚卸しや整理が必要です。
しかし、現場担当の業務やリソースが逼迫していると、その整理に時間が割けないこともあるでしょう。

そのような場合は、採用が決まるまでの間、定常業務の一部を外注（アウトソーシング）することで、社内側が要件定義に集中できる状態を作るのも現実的な手法の1つでしょう。

「採用か外注（アウトソーシング）か」の二択ではなく、状況に応じて「併用（コソーシング）」も視野に入れておくと、採用活動そのものも落ち着いて進めやすくなるでしょう。

情シス採用の要件定義の進め方：業務棚卸し→役割分解→“採れるポジション”設計

情シスの採用を進める際、採用媒体選びや求人票の書き方より先に検討したいことは、要件定義（＝何を、誰に、どこまで任せるかの設計）ではないでしょうか。

採用の要件定義が曖昧なままだと、求人は「何でもできる社内SE」募集になり、応募が集まらない・面接で噛み合わない・採用できても現場が回らない……という形で失敗する可能性があるでしょう。
逆に言えば、要件定義ができるとミスマッチのない情シスの採用が一気に現実的になるでしょう。

本記事では、次の4ステップで“言葉”ではなく“仕事”から要件を組み立てる方法をご紹介します。

Step1：業務棚卸し（まず「やっていること」を全部出す）

要件定義の第一歩は、「情シスの仕事は何ですか？」を言語化することではなく、実際に発生している作業を、漏れなく書き出すことです。
情シス（社内SE）が担う仕事は例外対応・突発対応が多く、記憶だけでまとめると抜け漏れが発生する可能性が高いため、棚卸しは“現場の現物”を拾うのがよいでしょう。

棚卸しで集める情報の一例

まずは完璧を目指さず、2週間〜1か月分の実績で現実を可視化してみてはいかがでしょうか。
1か月分の棚卸しでも、多くの課題が見えてくる場合もあるでしょう。

Step2：役割分解（運用と企画と統制を混ぜない）

棚卸しで作業が出揃ったら、次は性質の違う仕事を混ぜないように分けてみるとよいでしょう。
情シスの採用が難航する会社ほど、「運用」も「改善（企画）」も「セキュリティ統制」もすべて1人に背負わせがちになるようです。

本記事では、まず大きく3つに分けて役割を分解する方法をご紹介します。

1) 運用（定常）

ルールがあり、繰り返し発生し、対応する件数が予測できる仕事です。
分業しやすい一方、属人化すると「その人がいないと回らない」状態になりやすい領域でしょう。

例：

• • 入退社対応（アカウント発行/停止、権限付与）
  • PCキッティング、端末交換、資産台帳更新
  • SaaSライセンス付与/棚卸し
  • 問い合わせ一次対応（切り分け・FAQ）

2) 運用（非定常・突発）

障害、例外対応、緊急案件など、発生頻度は低いが影響が大きい仕事です。
緊急を要する業務が属人化していると、退職・休職によりBCPが崩れやすい体制となってしまうでしょう。

例：

• • 障害対応、復旧、ベンダーエスカレーション
  • 重要アカウントのトラブル、権限事故の火消し
  • 監査・取引先要請の突発対応

3) 企画・改善 / 統制（セキュリティ・ガバナンス）

決める・整える・継続的に改善する仕事です。
運用業務で日々のリソースが埋まっていると永遠に進まない領域でもあります。

例：

• • SaaS乱立の整理、標準化
  • 認証基盤や端末管理の方針設計
  • ルール策定、委託先管理、監査対応の設計

---

役割分解のゴールは「分類すること」ではなく、

最終的に

• • 社内が責任を持つべきこと（決裁・例外承認・方針）
  • 情シスが主に実行すること（運用・改善）
  • 外部も選択肢にできること（定常運用の一部、一次対応、キッティング等）

を切り分けることではないでしょうか。

上記の責任を切り分けられていると、情シス採用のお悩み解決だけでなく、その後の予期せぬ欠員や繁忙期でも止まらない体制を設計しやすくなるでしょう。

Step3：ポジション設計（「採れる求人」に落とす分け方）

役割分解ができたら、いよいよ「採れる形」に組み替えます。

ポイントは、万能な情シス担当者を探すことではなく、任せたい仕事を整理し明確にしたポジションとして設計し直すことです。

以下は「切り出し方」の一例です。

例① ：ヘルプデスク中心（一次対応の安定化）

会社の悩み：

• • 問い合わせが多く、情シスが割り込みで疲弊している
  • まず現場の不満を減らしたい

期待される成果例：

• • 問い合わせ窓口の一本化
  • よくある質問のFAQ化
  • 一次切り分けの標準化（どこまで対応し、どこからエスカレーションするか）

採用要件の考え方：

• • 技術の深さより、対応品質・整理力・ドキュメント化に重点を置くことをおすすめします

例② ：端末・ID運用中心（入退社・キッティングのボトルネック解消）

会社の悩み：

• • 入退社や端末対応が多い
  • 情シスと管理部門が兼任で手が回らない

期待される成果例：

• • 入退社対応のリードタイム短縮
  • 資産台帳の整備と更新ルールの定着
  • MDM（Mobile Device Management：モバイルデバイス管理）や標準端末の運用

採用要件の考え方：

• • 実務量が読みやすく、「採れるポジション」にしやすい代表格でしょう

例③ ：インフラ運用中心（ネットワーク・クラウド・監視）

会社の悩み：

• • 拠点・VPN・回線トラブルが多い
  • 障害対応が属人化している

期待される成果例：

• • 障害時の一次切り分けと復旧フロー整備
  • ベンダー連携、監視、変更管理の整備

採用要件の考え方：

• • 求めるレベルが上がる分、「何を任せ、何を任せないか」をより明確に打ち出す必要があるでしょう

例④ ：IT企画・ベンダー管理中心（改善を進める役）

会社の悩み：

• • 運用を何とかして、改善を進めたい
  • 情シス責任者が意思決定はできるが手が足りない

期待される成果例：

• • SaaSの整理、運用ルール整備
  • 新規導入のプロジェクト推進
  • 外部ベンダーの品質管理（SLA、体制、運用定例）

採用要件の考え方：

• • 「できること」より、ミッション（何を変える役か）を打ち出した方が刺さりやすい可能性があります

採用だけに寄せない現実的な設計も入れておく

ポジション設計の段階で、採用が難しそうだと感じた場合は、採用以外の選択肢も検討するとよいでしょう。

たとえば「問い合わせ一次対応」「キッティング」「運用の定型作業」などは、体制とルールが揃えば外注（アウトソーシング）もしやすい領域でしょう。

Step4：成功条件を業務成果で定義する（採用後の評価とセット）

最後のステップでは、「採用できたら成功」ではなく、採用後に何がどう良くなれば成功かを定義するとよいでしょう。

成功条件が明確に定義されていると、求人票も面接も条件がブレにくくなり、採用者の入社後の不満を減らすことに繋がるようです。
以下は成功条件の一例です。

問い合わせ（ヘルプデスク）

• • 一次回答までの時間（例：当日中、2営業時間以内）
  • 解決までのリードタイム
  • 問い合わせの分類比率（FAQ化すべきテーマが見える）

入退社・ID/端末運用

• • 入社までの準備完了率（入社日にログインできる）
  • 権限付与の標準化率（例外対応が減る）
  • 資産台帳の更新率（棚卸しの精度）

セキュリティ・統制

• • 権限の棚卸し実施頻度と完了率
  • ログ・監査対応の「説明できる状態」の維持
  • 委託先管理（アクセス権、手順、契約）の整備状況

ベンダー管理

• • 障害時のエスカレーションが機能する（連絡先・手順がある）
  • 定例レビューが回り、課題が潰れていく

指標づくりの注意点として、最初からKPI(重要業績評価指標)を増やしすぎないほうがよいでしょう。まずは3つ程度から定義してみてはいかがでしょうか。

また、数値を追うことよりも、運用を整えることが目的になっているかを定期的に確認することをおすすめします。

ミスマッチを減らす「情シス 採用」の求人票設計：書くべき項目と例文

情シスの採用でつまずきやすいのは、求人票が「情シス業務全般」のように広くなりすぎて、読む側が 「結局どこまでやるのだろう」 と不安になってしまうことが挙げられます。

業務内容に対する不安は、待遇や会社の魅力よりも先に、応募の手を止める要因になることもあるでしょう。

ここでは、前章で整理した「業務棚卸し→役割分解→ポジション設計」を、実際に求職者へ伝わる形（求人票）に落とし込むための「型」の一例をご紹介します。

職種名より先に、ポジションのミッションを1〜2行で言い切る

情シスの求人は、職種名（社内SE／情シス／コーポレートIT）のラベルだけでは仕事内容が伝わらないことが多いようです。
このような場合、「このポジションで何を安定させたいのか」「何を前に進めたいのか」というミッションの言語化を行うと求職者に内容が伝わりやすくなるでしょう。

書き方のコツ

• • やることの羅列ではなく、何を良い状態にする役かを書く
  • 1〜2行で簡潔に言い切る

ミッションの言語化の一例

社内のIT運用（入退社対応・アカウント／端末管理・問い合わせ一次対応）を安定させ、社員が安心して働ける環境を整えるポジションです。
まずは運用の標準化と可視化（手順・台帳・問い合わせの整理）から着手いただきます。

ミッションが先にあると、求職者は「この会社の情シスは何を期待される役なのか」を掴みやすくなり、応募判断が進みやすくなるでしょう。

「やること」に加えて「やらないこと」も書く

担当範囲を明確にすることも情シス採用で効果的なミスマッチ対策の1つでしょう。
「幅広く対応」は魅力に見える反面、求職者には 青天井の負荷に映ることもあるようです。

業務範囲の見せ方の例

主担当（自分が中心で作業する）

• • 入退社・異動に伴うアカウント発行／停止、権限付与の運用
  • PCキッティング、端末交換、資産台帳の運用
  • 社内問い合わせ一次対応（窓口運用、簡易な切り分け、FAQ整備）

担当（チームで分担／一部担当する）

• • SaaSのライセンス棚卸し、運用ルール整備
  • ベンダーへの問い合わせ・エスカレーション（障害時の一次窓口）

対象外（基本やらない／別担当・別部署）

• • 基幹システムの開発・改修（情報システム部内の別担当／外部ベンダーが対応）
  • 全社IT戦略の意思決定（管理職／責任者が担当）

例外（条件付きで対応する）

• • 緊急度が高い障害時は一次対応を行い、復旧はベンダーと連携して進める

---

業務範囲が明確に見えていると、求職者側の「何でも屋にされるのでは」という疑念を下げやすくなるでしょう。

必須要件は絞り、入社後にキャッチアップする前提を置く

採用が難航しやすい求人ほど、必須要件が増えがちです。

また、情シス業務は会社ごとの環境差が大きいため、全てを入社前に経験済みである人材を求めると求人にマッチする求職者がかなり絞られてしまう傾向があるようです。

必須条件は絞り、入社後に何を覚えれば良いかが書いてあると、求職者は挑戦しやすくなるでしょう。

要件の一例

必須要件

• • 社内IT運用、ヘルプデスク、端末／アカウント管理のいずれかの実務経験
  • 社内の非エンジニアとやり取りしながら、依頼を整理して進めた経験
  • 手順書や台帳など、運用を見える化・標準化した経験（大小問わず）

歓迎要件

• • Microsoft 365 / Google Workspace / IdP / MDM いずれかの管理経験
  • ベンダー管理（障害エスカレーション、契約更新、SLAの調整など）
  • セキュリティ運用（権限設計、ログ、監査対応の補助など）

入社後にキャッチアップする領域

• • 自社固有のネットワーク構成、SaaS構成、申請フロー
  • 取引先要請・監査対応の流れ

体制・権限・対応時間を明記する

体制・権限・対応時間が求人票から読み取れないことも、情シスの求人で応募を止めやすい原因の1つのようです。

これらが明記されていると、「入社したら丸投げされるのでは」という不安の大部分を先回りして解消することに繋がるかもしれません。

体制・権限・対応時間に関する記載の一例

体制：
情報システム担当は現在〇名。
問い合わせ一次対応は総務とも連携し、定型業務は手順化を進めています。
必要に応じて外部ベンダーの保守・運用支援を利用しています。
権限：
業務上必要な管理者権限は付与しますが、例外承認やポリシー判断は責任者が行います。
対応時間：
原則として勤務時間内対応。
緊急障害時は一次対応を行い、復旧はベンダーと連携します（頻度目安：〇回／年）。

魅力は盛らずに、現場のリアルな良さを言語化する

魅力的な情シスの求人は、派手さよりも担当業務の遂行により「改善がちゃんと前に進む環境か」が記されているかではないでしょうか。

福利厚生の列挙より、仕事の進めやすさ（裁量・優先順位・予算・協力体制）を具体化した方が響く場合もあるでしょう。

改善業務が進む環境であることを伝える一例

• • 問い合わせ窓口の一本化、FAQ整備など、運用を整えるところから着手できる
  • ツール導入の前に、申請・権限付与の流れなど、業務プロセスから改善できる
  • 社内の依頼を受けるだけでなく、優先順位を合意して進める運用を作っている
  • 外部ベンダーと役割分担し、社内は“決める／整える”に寄せる方針がある

「できていないこと」を正直に書き、「だからこそやることがある」と言語化できている求人内容は、企業と求職者のミスマッチ防止に役立つはずです。

面接は「技術テスト」より“現場で起きる会話”を再現する

情シスは、知識量よりも「切り分け力」「優先順位付け」「説明力」が有効に働く場面が多い職種です。
面接もそれに合わせて、現場で起きる状況を軽く再現できるとミスマッチを減らすことに繋がるでしょう。

質問の一例

1. 1. 切り分け力（一次対応の質）
      ・「VPNにつながらない」と連絡が来たら、最初に何を確認しますか？
      ・原因がユーザー側・ネットワーク側・SaaS側のどれかを切り分けるとき、どう進めますか？
   2. 優先順位付け（割り込み耐性）
      ・「PC不調が5件」「入社対応が2件」「緊急っぽい問い合わせが1件」同時に来たら、どう順番を決めますか？
   3. 仕組み化（属人化を減らす習慣）
      ・過去に、手順化や台帳整備で運用を安定させた経験があれば教えてください
      ・手順書を作っても読まれない、といった問題が起きたら、どうしますか？
   4. ベンダーとの付き合い方
      ・障害時にベンダーへ連絡するとき、何を整理して伝えますか？
      ・「ベンダーの回答が遅い」と現場が焦っているとき、どう対処しますか？

採用 vs 外注（アウトソーシング） vs 併用（コソーシング）の判断基準

情シスの体制づくりは、つい「採用できるか・できないか」から考えがちですが、意思決定の本質は別にあるようです。

本当に決めるべきは、どの業務を、どのくらいの品質で、誰が責任を持ち、TCO（Total Cost of Ownership：総所有コスト）としていくらで回すかではないでしょうか。

この章では、採用・外注（アウトソーシング）・併用（コソーシング）を3つの判断軸で整理します。

判断軸1：コストは年収ではなくTCO（総コスト）で見る

採用について考える際、「年収◯◯万円なら採用できる・できない」という見方で議論されることは多いのではないでしょうか。

実際は、情シス業務は立ち上がり・教育・属人化・夜間対応・退職などの影響が大きく、年収以外のコストの方が実質的に重くのしかかりがちです。

採用（内製）のTCOに入れるべきもの

「年収＋社会保険」だけではなく、最低でも以下のコスト観点をTCOに含めると、現実的な数字での比較に役立つでしょう。

• • 採用費
    求人媒体費、紹介手数料、面接工数（現場の時間もコスト）
  • 立ち上がりロス（生産性が出ない期間）
    最初の1〜3ヶ月で「問い合わせは来るのに、全体が見えていない」期間が必ず発生
  • 教育・ドキュメント整備コスト
    過去の対応が属人化していると、教育が掘り起こし作業になりやすい
  • マネジメント／レビューのコスト
    ひとり情シスは特に「判断の壁打ち」が不足し、上長や管理部門に相談・調整負荷が発生しやすい
  • 退職リスク（再採用＋引き継ぎ不能）
    退職はゼロに戻るだけでなく、権限・契約・運用の穴が露呈して事故リスクが上がる可能性も
  • 不在時対応
    有休・病欠・繁忙期（入社集中、端末更新）に、代替不能コストが跳ね上がる可能性

採用TCOは「固定費」ではありますが、実態は属人化すると変動費化（事故対応・残業・引き継ぎ不能）する固定費になりがちなようです。

外注（アウトソーシング）のTCOに入れるべきもの

外注（アウトソーシング）は「月額いくら」に見えますが、契約の取り方で総額も成果も変化する場合があるようです。TCOとしては以下が考えられます。

• • 範囲（スコープ）
    どこまでやるか：ヘルプデスクだけ／端末運用まで／アカウント運用まで、などで変動
  • 時間帯（対応時間）
    平日9-18のみ／早朝・夜間含む／休日オンコール、で変動
  • 窓口（受付の形）
    受付を一本化するか（メール・チケット・電話）、社内の取り次ぎが必要かで工数が変わる
  • SLA（Service Level Agreement：サービスレベルアグリーメント）
    「何分で一次応答」「何時間で復旧」などの水準で価格は変動する
  • 移行・立ち上げコスト
    台帳の整備、手順化、権限整理が未整備だと、初期にコストが寄る可能性
  • ベンダーマネジメントコスト（社内側の残務）
    丸投げではなく、月次レビュー・改善要求・契約更新判断などの統制工数は残る

外注TCOは「変動費」ですが、SLAとスコープを曖昧にすると追加費用と条件交渉の摩擦という形で増えることが多いようです。逆に、スコープと受け渡しが明確なら、コストも品質も安定するでしょう。

併用（コソーシング）のTCOに入れるべきもの

完全に外注（アウトソーシング）をするのではなく、一部業務を肩代わりしてもらう併用（コソーシング）は「いいとこ取り」に見えますが、雑に混ぜることはおすすめしません。
TCO観点では次を意識してみてはいかがでしょうか。

• • 社内と外部の境界コスト
    チケット振り分け、一次・二次の切り分け、エスカレーション設計がないと手戻りが増える可能性
  • 成果物の共通化（台帳・手順・分類）
    社内と外部で手順書・台帳・運用カレンダー・問い合わせ分類等が統一されていると、無駄なコストの削減に繋がる

判断軸2：責任分界（社内に残す責任／外に出せる業務）

内製・外注判断の失敗は、コストよりも責任分界が曖昧なまま契約してしまうことで起こりやすいようです。

特に情シスは「作業」だけでなく「判断」が混ざるため、何を社内に残すかを決めるだけで、外注（アウトソーシング）・併用（コソーシング）の成功率が上がるでしょう。

社内に残すべき責任（社内で決める仕事）

以下は外注（アウトソーシング）には不向きな情シスの業務領域の一部です。

• • 最終決裁（投資判断・予算・優先順位）
  • 規程・ルール（セキュリティポリシー、例外の扱い）
  • リスク受容（どこまで許容するか）
  • 例外承認（特権付与、例外的な設定、特別対応）
  • 情報の機密区分と開示判断
  • ベンダー選定・契約の主体責任（更新・解約・SLAの合意）

外注先は実務と提案はできますが、「会社としてOKと言う責任」は企業側に残しましょう。

外に出しやすい業務（回す仕事）

外注（アウトソーシング）すると効果が出やすいのは、標準化しやすい運用実務です。
以下はその一例です。

• • 運用実務（手順化できるもの）
    アカウント発行・停止（申請／承認が社内で完結している前提）
    PCキッティング・交換・故障一次対応
    SaaSの定型設定、ライセンス棚卸し
  • 一次受付（ヘルプデスク）
    問い合わせの受付、分類、一次切り分け、既知対応（FAQ）
  • 監視・アラート一次対応（定義できる範囲）
    「何を異常とするか」は社内で決め、一次対応の運用を外注する

迷いやすい領域（業務を分解することで外注可能）

外注（アウトソーシング）ができるかどうか迷いやすい業務もあると思いますが、
業務内容を分解することで外注（アウトソーシング）を決断しやすくなることがあります。以下はその一例です。

• • 変更管理（どこまでが「作業」でどこからが「設計」か）
    外部に手順に沿った設定作業、影響範囲の整理を依頼
    社内で変更承認、例外判断、最終責任を実施
  • 障害対応（一次復旧と根本対策の切り分け）
    外部に一次切り分け、暫定復旧、ログ収集を依頼
    社内で業務影響の判断、恒久対策の優先順位付けを実施

情シス業務の内容を「判断」と「作業」に分解し、判断は社内、作業は外部に寄せると責任分界が安定するでしょう。

判断軸3：SLA/品質（問い合わせ、障害、変更管理をどう担保するか）

外注（アウトソーシング）の価値は人を増やすことだけではなく、品質を契約と運用で再現できることにあるでしょう。

一方、SLA（Service Level Agreement：サービスレベルアグリーメント）を決めずに外注すると「やってくれているのに不満」「やってくれないのに契約上はグレー」が起きやすいようです。

SLAは「応答速度」だけでなく、「どういう手続きで、どう安全に変えるか」まで含めると品質が安定します。
まずは下記の3つの観点で考えてみるのはいかがでしょうか。

1. 1. 問い合わせ（ヘルプデスク）
      ・受付チャネル（チケット／メール／電話）
      ・一次応答時間（例：営業時間内◯分以内）
      ・解決目標時間（重要度別：当日／◯営業日など）
      ・エスカレーション条件（社内承認が必要なケース、重大インシデント）
   2. 障害対応（インシデント）
      ・重大度定義（全社停止、部門影響、個人影響）
      ・初動（何分で着手、誰に連絡）
      ・暫定復旧の目標（例：◯時間以内に業務影響を縮小）
      ・報告（一次報告・復旧報告・再発防止の粒度）
   3. 変更管理（チェンジ）
      ・変更の分類（標準変更／通常変更／緊急変更）
      ・承認フロー（誰が、何を見て承認するか）
      ・変更可能な時間帯（業務時間外、メンテナンス枠）
      ・ロールバック（戻す手順の有無）
      ・記録（いつ、誰が、何を、なぜ変えたか）

SLAは上げれば上げるほどコストが増えがちです。

最初から完璧を狙わずに、
・本当に止めたくないもの（基幹、認証、ネットワーク等）だけSLAを厚くする
・それ以外は「翌営業日」「ベストエフォート」を許容する
のように、重要度で差をつけるのが現実的でしょう。

結局、何を選ぶべきか？よくある落としどころ

採用、外注（アウトソーシング）、併用（コソーシング）のうち、何を選ぶのが正解なのか？とお悩みの方は多いでしょう。

大切なのは、どれが正解かではなく、自社の制約（緊急度・人材市場・責任分界・SLA）に合う順番で選ぶことではないでしょうか。

現場で多い落としどころを、状況別に整理してみましょう。

パターンA：緊急度が高い（炎上・滞留・属人化が深刻）

• 対応：
  まずは外注（アウトソーシング）で止血 → 並行して採用（または育成）
• 理由：
  ・採用は時間がかかる（採用〜戦力化までの空白が埋まらない）ため
  ・先に運用を安定させないと、採用後の担当者の負荷が高いため
• 進め方（実務）：
  ・まず「一次受付」「定型運用」を外注（アウトソーシング）する
  ・社内は責任分界と台帳整備、優先順位付けに集中する

パターンB：企画を進めたい（刷新・セキュリティ強化・DXを進めたい）

• 対応：
  運用を外注（アウトソーシング）に寄せる → 社内は企画・統制へ
• 理由：
  社内のリソースを問い合わせ処理に充てると、企画が永遠に進まないため
• 進め方（実務）：
  ・SLAと変更管理を整え、「運用が回っている状態」を外部と共同で作る
  ・社内はロードマップ、投資判断、例外承認、標準化を握る

パターンC：兼任限界（総務・情シス兼任、1名体制で回らない）

• 対応：
  窓口一本化と標準化を優先 → 必要ならば後で採用
• 理由：
  体制の弱点は人数ではなく「入口が散らばっていること」「判断基準がないこと」な場合が多いため
• 進め方（実務）：
  ・問い合わせをチケットに集約し、分類・台帳・手順を整える
  ・外注先は業務を回すところを担当、社内は意思決定を担当

採用・外注（アウトソーシング）・併用（コソーシング）の判断としてTCO、責任分界、SLAの3点が整理できると、「採用できるかどうか」以前に、どこまで内製で実施し、どこから外部に任せると最も安定するかが見えてくるでしょう。

アウトソーシングを検討するうえで確認すべき評価軸

外注（アウトソーシング）は「人が増える」ことよりも、運用の再現性（誰がやっても同じ品質）と、緊急時の強さ（止血できるか）が価値を左右しやすいようです。
よって、会社名や実績の派手さより、体制・速度・範囲・セキュリティ・契約の明確さで委託先を選定することが重要になるでしょう。

ここでは比較検討の際に確認しておけばミスマッチを防ぎやすいと考えられる評価軸を整理します。

評価軸①：属人化しない体制が整っているか

アウトソーシングで一番避けたいのは、社内の属人化を解消するつもりが、委託先側で属人化することでしょう。
担当者が優秀でも、いなくなった瞬間に止まる体制は、実質外部に依存先を移しただけになります。

！　確認ポイント（評価観点）

• • 複数名で運用できる前提になっているか（バックアップ要員、引き継ぎ手順）
  • 手順・設定・判断基準が、個人メモではなく成果物として残る設計になっているか
  • 「担当固定」ではなく、チーム運用（窓口・チケット・ナレッジ）で回るか
  • 誰が何を知っているかが見えるナレッジ管理（FAQ、手順書、既知障害）があるか

？　評価に際しての質問例

• •  「担当者が休んだ場合、誰が代替し、どこを見て同じ対応ができますか？」
  • 「運用手順書・ナレッジは誰が、どの頻度で更新しますか？更新の“トリガー”は何ですか？」
  • 「問い合わせの履歴・対応ログ・判断理由は、どの粒度で残りますか？」

○　プラス評価となるポイント

• • チケットベースで運用し、ナレッジの蓄積と更新が契約/運用に組み込まれている
  • 役割が「一次受付」「二次対応」「変更管理」などに分かれており、個人頼みではない

△　要注意ポイント

• • 「基本は◯◯が担当します（代替は未定）」のように特定の個人前提
  • 記録がメール/チャット中心で、後から追えない（引き継げない）

評価軸②：立ち上がりスピード（緊急時に間に合うか）

アウトソーシングは、平常時よりも「緊急時に間に合うか」で体感価値が決まりやすいです。

採用は戦力化まで時間がかかりますが、アウトソーシングは「早い」ことが期待値になりやすい分、対応速度の温度感にミスマッチがあると失望が大きくなりやすいようです。

！　確認ポイント（評価観点）

• • 初動の速さ：問い合わせや障害に対する 一次応答・着手が早いか
  • 立ち上げの速さ：開始してから 実運用が回る状態になるまでの見立て
  • 緊急時の強さ：夜間・休日・重大障害時に、どこまで対応する前提か（ベストエフォートなのか、明確な枠があるのか）

？　評価に際しての質問例

• • 「“開始日”から“安定稼働”まで、何週間想定ですか？その間に何が揃えば良いですか？」
  • 「重大インシデントの定義は何ですか？発生時の連絡経路と初動はどうなりますか？」
  • 「繁忙期（入社集中・端末更改・年度末）に対応キャパシティは増やせますか？増やす場合の条件はありますか？」

○　プラス評価となるポイント

• • “立ち上げに必要な情報”が整理されており、質問が具体的（＝経験がある）
  • 受付～一次切り分け～エスカレーションの導線が明確

△　要注意ポイント

• • 「やってみないと分からない」といった回答が多い（特に初動と緊急時）
  • スピードの説明が精神論（頑張る/柔軟に）で、具体的な運用条件が出てこない

評価軸③：対応範囲（運用だけ／改善まで／企画まで）

アウトソーシングのミスマッチは、価格やスキル不足というより、「どこまで対応すると思っていたか」のズレで起こることも少なくないようです。

特に情シスは、問い合わせ対応のような運用だけでなく、改善（再発防止）や企画（導入選定）まで話が広がりやすいので、範囲の切り分けが重要になるでしょう。

！　確認ポイント（評価観点）

• • 運用：定型作業・問い合わせ対応・アカウント/端末運用
  • 改善：問い合わせ分析、手順・FAQ改善、再発防止、軽微な自動化
  • 企画：セキュリティ強化、ツール刷新、ロードマップ、要件定義、製品選定支援
  • 誰が何を知っているかが見えるナレッジ管理（FAQ、手順書、既知障害）があるか

委託先がどこまで対応できるかだけでなく、責任を持つ範囲がどこまでか（助言なのか実行までなのか）を確認するとよいでしょう。

？　評価に際しての質問例

• • 「問い合わせ削減や再発防止は、運用範囲に含まれますか？含む場合、何を成果物として出しますか？」
  • 「運用ルールや申請フローの改善提案はしますか？提案頻度（月次など）はどのくらいですか？」
  • 「企画（例：ゼロトラスト、MDM刷新等）は、実施主体としてやりますか？それとも助言のみですか？」

○　プラス評価となるポイント

• • 対応範囲が「作業」だけでなく、成果物（手順、台帳、FAQ、運用レポート）に落ちている
  • 「何でもできます」ではなく、できること/できないことの境界が明確

△　要注意ポイント

• • 範囲が広いのに、アウトプット（成果物）や意思決定の責任が曖昧
  • 改善・企画の話が出ても、運用の現実（権限、承認、変更管理）に触れない

評価軸④：セキュリティ・情報管理（権限、ログ、アクセス、委託先管理）

アウトソーシングでも、権限やログ設計の甘さによりセキュリティ事故が発生する可能性は否めません。
「安心です」ではなく、具体的に何をどう管理しているかで判断することが重要でしょう。

！　確認ポイント（評価観点）

• • 権限管理
    最小権限（必要最小限のAdmin付与）になっているか
    個人アカウントでアクセスするか（共有IDを使わないか）
  • ログ・証跡
    管理者操作ログ、チケット履歴、作業記録が残るか
    「誰が・いつ・何をしたか」が追えるか
  • アクセス経路
    どこからアクセスするのか（VPN、踏み台、端末制御）
    端末の管理（会社支給端末、EDR、暗号化）や持ち出しルール
  • 委託先管理（組織としての担保）
    体制変更・再委託（下請け）の扱い
    従業員教育・秘密保持・退職者のアクセス停止

？　評価に際しての質問例

• • 「委託先が使う管理者権限は、個人IDですか？共有IDはありますか？」
  • 「管理者操作ログは、貴社側と当社側のどちらで保持しますか？監査時に提出できますか？」
  • 「接続方式（VPN/踏み台/端末要件）と、作業端末のセキュリティ要件を教えてください」
  • 「再委託（下請け）が発生する可能性はありますか？あるなら事前承認・情報開示のルールは？」

○　プラス評価となるポイント

• • 権限・ログ・アクセス方式が、最初から“設計”として提示される
  • 事故が起きる前提で、証跡と抑止（牽制）が組み込まれている

△　要注意ポイント

• • 共有ID前提、ログが残らない/追えない、アクセス経路が整理されていない
  • 「うちは大丈夫です」で終わり、具体策が出てこない

評価軸⑤：契約・SLA・責任分界が明文化されているか

アウトソーシングは、アウトソーシング先との関係が良好であるほど期待値が膨らみやすいものです。
だからこそ、関係が良好なうちに文章で境界を固定しておくことをお勧めします。

境界が曖昧だと、トラブル時に「どっちの対応責任？」となり対応が止まったり、回復が遅れたりする恐れがあるでしょう。

！　確認ポイント（評価観点）

• • • 責任分界（誰が最終責任を負うか）
      社内に残す責任（最終決裁、例外承認、ポリシー決定）
      委託先の責任（運用実務、一次切り分け、報告、改善提案の有無）
    • SLA（品質の約束）
      一次応答、着手、解決目標、エスカレーション条件
      重大度定義（全社停止/部門/個人）と報告タイミング
    • 対象外（スコープ外）
      対象外を明確にして、追加対応時の扱い（別途見積等）も明文化
    • 成果物（運用が回るための納品物）
      台帳、手順書、運用レポート、チケットデータ、構成情報などの引き渡し可能性
    • 変更管理
      変更の承認者、作業可能時間、ロールバック、記録の取り方

？　評価に際しての質問例

• • 「当社側に残る責任と、御社が負う責任を、具体的に線引きしてください」
  • 「SLAは“応答”だけですか？解決や報告はどう定義しますか？」
  • 「契約終了時、運用情報（手順書・台帳・ログ・ナレッジ）はどの形式で返却されますか？」
  • 「緊急変更の扱い（誰が承認し、どこまで実施し、どう記録するか）はどうしますか？」

○　プラス評価となるポイント

• • 契約条文やSLA例がすぐ出てくる（テンプレートがある＝境界が曖昧になりやすい部分を理解している）
  • 「できる/できない」だけでなく、条件（時間帯・前提・情報提供）が明確

△　要注意ポイント

• • SLAが精神論の「頑張ります」寄り、責任分界が「協議」だらけ
  • 成果物の帰属や返却が曖昧（将来の切り替えができなくなる）

まとめ

情シス採用のゴールは採用そのものではなく、業務を止めずに回し、改善まで進められる状態を作ることです。

『情シス＝何でも屋』にせず、まずは守る運用（入退社・端末・ID/権限・主要SaaS）と、次に整える運用（手順化、台帳更新、問い合わせの分類）を分け、責任範囲と優先順位を言語化するとミスマッチが減らせるでしょう。

アウトソーシングは範囲・SLA・責任分界を明文化できるならば、採用に固執せず前進する現実的な選択肢になりえるでしょう。
採用が難しい局面では、外注（アウトソーシング）や併用（コソーシング）を活用し、落ち着いて採用や体制設計を進めてみてはいかがでしょうか。

クロス・ヘッドでもお客様の情シス部門の課題を解決する業務支援サービスである、「情シスSAMURAI」を提供しています。解決策の1つとしてご活用ください。

自社の状況に合わせて様々な方法を検討することで、情シス体制を整えていきましょう！

『情シスSAMURAI』サービスページはこちらから