中堅企業の情シス不足をどう補うか - 設計・構築・運用の「どこまで任せるか」を決める判断軸

「人が足りない」の中身を、3つに分けて見る

保守終了の通知が、机の上に何通かたまっている。仮想基盤の更新見積もりは受け取ったが、金額を見て稟議の出し方を考えあぐねている。そのあいだにも、社内からの問い合わせは毎日入る。

こうした状況を上長に説明しようとすると、多くの場合「人が足りない」という言葉になります。事実としては正しいのですが、この説明では次の一手が決まりません。増員の話に流れて、採用は難しいという結論に戻り、また元の状態に戻る。この往復を何度か経験している方も多いのではないでしょうか。

一度、不足の中身を3つに分けてみると、話が具体的になります。

工数の不足

作業そのものの量が、確保できる時間を超えている状態です。キッティング、アカウント作成、パッチ適用の実施、定型的な問い合わせ対応。手順が決まっていて、人手さえあれば進む種類の仕事です。

判断できる人の不足

設定変更を実施してよいか、この障害で業務を止めるべきか、この見積もりは妥当か。判断そのものは短時間で終わるのに、判断できる人が1人しかいないために、その人の予定が全体の進行速度になっている状態です。

対応できる時間帯の不足

日中は回っているが、夜間と休日に穴がある。あるいは、担当者が休暇を取ると、その期間は実質的に止まる。人数の問題というより、カバーできる時間の問題です。

この3つは、打ち手が違います。工数の不足には作業の切り出しが効きますが、判断できる人の不足には効きません。作業を外に出しても、判断は戻ってくるためです。逆に、時間帯の不足に対して工数の話をしても噛み合いません。

自社がどれに当てはまるか。あるいは、3つとも少しずつ当てはまるのか。ここを言語化しないまま支援先を探し始めると、提案を比べる物差しが定まりません。

IT基盤の全体像の中で、外部支援はどの層に効くのか

ITインフラ支援やマネージドサービスの説明を読むと、「運用を任せることで、情シスは戦略業務に集中できる」という趣旨の記述によく出会います。方向性としてはその通りなのですが、実務では「どの部分が移って、どの部分が残るのか」が見えないと、判断できません。

IT基盤を層で見ると、外部支援の効き方には差があります。

上から3つの層は、比較的きれいに切り出せます。手順が定義でき、成果物が明確で、対応時間もSLAとして書けるためです。

問題は下の3つです。一次対応は、切り分けまでは任せられても、「このサービスを今止めてよいか」は社内の事情を知らないと決められません。判断と社内調整に至っては、そもそも委託先が持っていない情報 ( どの業務が繁忙期か、誰の承認が要るか、来週に大きな締めがあるか ) に依存しています。

ある企業では、監視と一次対応を委託した後も、担当者の帰宅時刻がほとんど変わりませんでした。アラートの受信は止まったのに、「この対応を実施してよいか」という確認の電話が、代わりに入るようになったためです。これは委託先の質の問題ではなく、層の性質による構造的なものです。

外部支援を検討する際は、この地図の上で「自社が減らしたいのはどの層か」を先に置いてみると、期待値のずれを小さくできます。

検討のきっかけは、たいてい「困ったとき」ではなく「期限」

外部支援の検討が実際に動き出すきっかけを聞くと、「負荷が限界だから」よりも「保守が切れるから」のほうが多いという印象があります。日々の負荷は徐々に上がるため、動く理由になりにくいのに対し、期限は日付として届くためです。

ここで実務的に効いてくるのが、時間の粒度の違いです。

• 保守期限は、年単位で来ます。
  メーカーの都合で決まるため、こちらの事情とは関係なく到来します。

• 予算は、年度単位です。
  決算期をまたぐ調整が必要で、期首に組んでいなければ、次の年度まで動けないこともあります。

• 検証と切り替えは、月単位です。
  テスト環境の準備、移行、並行稼働、切り戻し手順の確認。これらに数カ月かかります。

この3つが噛み合わないと、「期限は分かっていたが、予算を取る時期を逃した」「予算は付いたが、検証の時間が残っていない」という状態になります。期限の1年前に着手できていると、この3つを順番に処理する余裕が生まれます。

期限が迫ってから検討を始めた場合に何が起きるかというと、選択肢が消去法になります。更改、延命、構成の見直し、外部支援の活用という選択肢を並べて比較する時間がなく、提示された条件のなかから選ぶことになる。金額の交渉余地も小さくなります。

もっとも、1年前に必ず動けるとは限りません。その場合でも、「いつまでに何を決める必要があるか」を逆算して書き出しておくだけで、後の議論の進み方は変わってきます。

設計・構築・運用のどこを、どの粒度で任せるか

外部支援の議論は、「内製か外注か」という二択で語られることが多くあります。ただ、実際に契約を詰める段階になると、この二択では粒度が粗すぎて決まりません。

整理しやすいのは、フェーズと粒度の2軸で見る方法です。

粒度を4段階に分けてみます。

1. 相談のみ - 構成案や見積もりの妥当性について意見をもらう。判断も作業も自社

2. 作業の代行 - 手順が決まっているものを実施してもらう。判断は自社

3. 判断を含む代行 - あらかじめ定めた基準の範囲内で、委託先が判断して実施する

4. 一次判断まで委任 - 定義された条件下で、委託先が対応可否を判断する

これをフェーズと掛け合わせると、次のようになります。

すべてを右側に寄せる必要はありません。むしろ、フェーズごとに粒度が違うほうが自然です。設計は相談のみ、構築は作業の代行、運用は判断を含む代行、といった組み合わせが選ばれることもあります。

判断に迷いやすいのは、運用フェーズの粒度3と4の境目です。ここを曖昧にしたまま契約すると、障害時に「これは委託先が判断してよかったのか」という議論が後から起きます。逆に、粒度3の基準を細かく作り込みすぎると、想定外の事象で必ず止まります。

現実的なのは、最初は粒度2から始め、運用しながら「これは任せてよかった」という範囲を粒度3に移していく進め方でしょう。段階的に範囲を広げるアプローチは、比較的リスクを抑えやすいとされています。ただし、この移行を意識的に設計しておかないと、いつまでも粒度2のまま、確認の往復だけが続くことになります。

支援先を選ぶときに、見積書には現れない差

複数社から提案を受けると、金額に差が出ます。この差が何の差なのかを見極める段階が、選定の実質的な山場です。

比較サイトでは、業界実績、セキュリティー基準、サポート体制の迅速さといった軸が挙げられます。これらは重要ですが、提案書からは読み取りにくい項目でもあります。実務で効いてくる軸を5つに絞り、それぞれ提案時に確認するとよい質問を添えます。

1. 設計の段階から入れるか

構築だけを請ける会社と、要件整理から入れる会社では、後の手戻りが変わります。既存環境の制約を知らないまま設計された構成は、移行段階で調整が発生しがちです。

聞くとよいこと: 「現状の棚卸しから支援してもらえますか。その場合、どこまでが見積もりに含まれますか」

2. 機器の調達と検証を自社で持てるか

設計と運用は請けられても、機器調達は別会社という体制だと、納期の調整や不具合時の切り分けで窓口が増えます。検証環境を用意できるかどうかも、切り替えリスクに直結します。

聞くとよいこと: 「機器の手配と、切り替え前の検証環境の準備は、どちらが担いますか」

3. 運用引き継ぎ資料の納品条件が書かれているか

構築が終わった後に何が納品されるか。構成図、設定一覧、運用手順書、障害時の確認手順。これらが契約書に書かれていないと、口頭説明で終わることがあります。数年後の更新時に、この差が効いてきます。

聞くとよいこと: 「納品物として、構成図と運用手順書は含まれますか。更新は誰が行いますか」

4. 契約終了時の引き渡し条件

委託先を変更する、あるいは社内に巻き取る場面を、契約時に想定しているか。データの返却、アカウントの削除、引き継ぎ期間と費用。ここが曖昧だと、実質的に切り替えられない状態になります。

聞くとよいこと: 「契約を終了する場合、引き継ぎ期間と費用はどうなりますか」

5. 一次対応の範囲と、判断の所在

前章の粒度の話がここに戻ってきます。「24時間365日対応」と書かれていても、それが通知なのか、切り分けなのか、復旧作業までなのかで、自社に残る負荷は大きく変わります。

聞くとよいこと: 「深夜にアラートが出た場合、そちらの判断で実施できる作業はどこまでですか」

安い提案が悪いということではありません。含まれていない範囲は、必ずどこかに戻ってきます。それが自社の工数として戻るのか、別途費用として戻るのかを、契約前に見えるようにしておく。比較すべきなのは、金額そのものより、この戻り先です。

委託しても、社内に残るもの

ここは、検討段階で共有しておかないと、開始後に落差が出る部分です。

外部支援を使っても、次の業務は社内に残ります。

• 業務影響の判断
  このシステムが止まると、どの部門がどれだけ困るか。委託先は知りません

• 停止可否の承認
  作業のために業務を止めてよいか。社内の権限の問題です

• 優先順位付け
  複数の課題が同時に出たとき、どれから対処するか

• 費用の説明
  請求内容が妥当かを社内に説明する役割

• 監査や取引先への回答
  運用状況について外部に説明する責任は移りません

そして、運用開始後に新しく増えるものもあります。確認依頼です。

「この作業を実施してよいでしょうか」「業務影響はどの程度でしょうか」「優先度の判断をお願いします」。委託先は社内の事情を知らないため、判断を伴う場面では必ず確認が入ります。これは委託先の質の問題ではなく、構造的にそうなります。社内にノウハウが蓄積されにくいという指摘とあわせて、事前に織り込んでおきたい点です。

この確認の頻度を下げる方法は、一つしかありません。判断基準そのものを、契約時に渡しておくことです。どのシステムがどの業務を支えているか。止められる時間帯はいつか。緊急時に誰へ連絡すればよいか。これらが文書として渡っていれば、確認は減ります。渡っていなければ、毎回聞かれます。

ここで、多くの企業が最初の壁にぶつかります。渡せる文書が、社内にないのです。構成図は数年前のまま、手順は担当者の記憶のなか、保守契約の一覧は部門ごとにばらばら。委託の検討を始めたはずが、現状の棚卸しから始めることになります。

遠回りに見えますが、これは避けて通れない工程です。そして、この棚卸しをした時点で「思っていたより自社でやれる範囲が広かった」「逆に、この部分だけ任せれば十分だった」と分かることもあります。委託するかどうかにかかわらず、やっておく価値のある作業と言えます。

なお、運用が引き継げる状態にあるかを測る視点については、別記事「サーバー運用は引き継げる状態か - 続けられる体制を測るための視点」で整理しています。

任せない・見送るという判断と、そのとき積み上がるもの

「今回は見送る」という判断が、常に問題というわけではありません。予算の制約、他プロジェクトとの兼ね合い、体制が整っていないタイミング。無理に動かして中途半端な状態を作るより、見送るほうが合理的な場面はあります。

ただし、見送った場合に何が積み上がるかは、把握しておいたほうがよいでしょう。

いずれも、発生してから対処すると選択肢が限られます。特に4行目は見落とされやすい項目です。「困ったら外部に相談すればよい」と考えていても、相談するための情報が揃っていなければ、その段階から数週間かかります。

先送りは、それ自体が一つの意思決定です。意識的に選んでいるのか、判断を保留しているだけなのか。ここを区別しておくだけでも、社内の議論は変わります。見送る場合は、その根拠と、次に再検討する時期を記録に残しておくことをおすすめします。半年も経つと、当事者ですら経緯を思い出せなくなるためです。

相談の前に整理しておきたいこと

外部に相談する前、あるいは社内で稟議を出す前に整理しておくと、話が早く進む項目をまとめます。

現状

• □ サーバー、ネットワーク機器、端末の一覧と、それぞれの保守期限

• □ 各システムが支えている業務と、止まったときの影響範囲

• □ 現在の運用作業の一覧 ( 日次・週次・月次・年次 )

• □ 直近1年の障害履歴と、そのときの対応内容

• □ 構成図・手順書の最終更新日

目的

• □ 減らしたいのは、工数か、判断の集中か、対応時間帯か

• □ 今回の対象範囲 ( 全社の基盤か、特定システムか )

• □ 業務ごとに、どれくらいの停止までなら許容できるか

体制

• □ 運用に充てられる社内の人員と、その稼働割合

• □ 夜間・休日の対応について、社内で合意されている内容

• □ 自社に残したい判断と、外に出したい作業の想定

期限

• □ 直近の保守期限と、予算計上のタイミング

• □ 検証と切り替えに確保できる期間

• □ 見送る場合の、再検討時期

このリストは、埋めることが目的ではありません。実際に書き出してみると、たいてい3分の1ほどが「確認しないと分からない」で止まります。その止まった箇所こそが、社内だけでは判断できない領域です。どこで止まったかをメモしておくと、外部に相談する際、そのまま論点として渡せます。

よくある質問

Q1. 設計・構築・運用のうち、どこから外部に出すのが一般的ですか

一律の正解はありませんが、手順が定義しやすく成果物が明確な領域から始めるケースが多い印象です。具体的には、機器調達と初期構築、あるいは定型的な監視作業です。判断を伴う領域を最初から広く任せると、社内側の受け皿が追いつかず、確認の往復が増えることがあります。ただし、すでに構築は終わっていて運用だけが逼迫している場合は、この順序にこだわる必要はありません。自社の不足がどこにあるかから逆算するのが現実的です。

Q2. 丸投げしてしまうと、社内にノウハウが残らないのではないでしょうか

その懸念は妥当です。実際、外部委託のデメリットとして自社にノウハウが蓄積されにくい点は広く指摘されています。対策としては、契約時に納品物として構成図と運用手順書を明記すること、月次の報告を受ける場を設けること、そして「なぜその判断をしたか」を記録に残す運用を委託先と合意しておくことが挙げられます。すべてを把握し続ける必要はありませんが、見積もりや提案の妥当性を社内で検証できる程度の理解は残しておきたいところです。

Q3. マネージドサービスを使えば、夜間休日の対応はなくなりますか

通知を受けて一次切り分けを行うところまでは任せられるケースが多くありますが、「このサービスを今止めてよいか」という判断は、多くの場合、自社側に残ります。この判断を委託先に委ねるには、あらかじめ条件を定義しておく必要があり、その定義自体に相応の準備が要ります。夜間対応の負荷をどこまで下げられるかは、サービスの内容だけでなく、判断基準をどこまで文書にできているかで決まる、というのが実感に近いところです。

Q4. 費用対効果を稟議で説明するには、どう整理すればよいですか

現状の運用コストが数字になっていないことが多く、単純な金額比較では追加コストに見えてしまいます。実務的には、「委託するといくら下がるか」ではなく「今の体制を続けた場合に、いつ、何が起きるか」で説明したほうが通りやすい傾向があります。保守期限の到来時期、判断できる担当者が不在になった場合の影響、障害時の復旧見込み時間。これらを並べると、意思決定の材料になります。

Q5. 支援先を選ぶとき、実績はどこまで重視すべきですか

同業種の実績があるに越したことはありませんが、業種以上に確認しておきたいのは、自社と似た規模・体制での支援経験です。情報システム担当が数名の環境と、専任チームがある環境では、求められる支援の性質が異なります。「同じような体制のお客さまで、どこまでを任されていましたか」と聞いてみると、提案の解像度が上がることがあります。

Q6. まず何から着手すればよいですか

現状の棚卸しからです。機器の一覧、保守期限、各システムが支える業務、運用作業の一覧、構成図の更新状況。これらが揃っていないと、委託の範囲を決めることも、提案を比較することもできません。棚卸しには数週間かかることもありますが、この工程を飛ばすと、後の議論が必ず戻ってきます。

まとめ

情シス不足を外部のITインフラ支援で補うかどうかは、サービスの比較だけでは決まりません。本記事で整理した要点を、4点にまとめます。

不足の中身を3つに分ける

工数、判断できる人、対応できる時間帯。どれが足りていないかで、効く打ち手が変わります

フェーズと粒度の組み合わせで考える

設計・構築・運用のそれぞれで、任せる深さを変えて構いません

見積書に現れない差を見る

納品物、引き渡し条件、一次対応の判断範囲。含まれていない部分は、必ずどこかに戻ってきます

委託しても残るものを、先に共有する

業務影響の判断と社内調整は移せません。判断基準を渡せているかで、その後の負荷が変わります

唯一の正解はありません。同じ業種、同じ規模でも、既存資産の状況と運用に充てられる人員が違えば、適した組み合わせは変わります。まずは現状の棚卸しから始め、本記事のチェックリストで空欄になった箇所を確認してみてください。そこが、社内だけでは判断しきれない論点です。

自社だけで整理しきれない場合は、機器の選定に入る前の段階から相談できるパートナーを持っておくという選択肢もあります。横河レンタ・リースでは、IT基盤の現状整理から設計・構築、運用支援までのご相談を承っています。何を任せるかが決まっていない段階でも構いませんので、必要に応じてお声がけください。

横河レンタ・リース株式会社では、ITインフラの機器提供に加え、設計・構築、運用支援、セキュリティー対策の整理についてご相談を承っています。更改を検討する段階で、現行環境と運用課題の整理から一緒に確認したい場合は、お気軽にお問い合わせください。

お問い合わせ (総合) | 法人向けパソコン (パソコン) ・計測器レンタルなら横河レンタ・リース