社員数が100〜300人規模まで拡大した会社の多くは、本社のほかに支店・営業所・工場・倉庫といった複数の拠点を持っています。そして、拠点が複数あるということは、それぞれの拠点が独自の歴史をたどってIT環境を育ててきた可能性が高いということでもあります。本社では標準化されたシステムを使っていても、支店では別のツールを個別に契約していた、営業所には誰が管理しているか分からないネットワーク機器が残っている、といった状態は、複数拠点を持つ会社では珍しくありません。ひとり情シスが本社に常駐している場合、拠点のシステムは「見えていないだけで存在する」というのが実情です。このガイドでは、拠点ごとに異なる管理状態を可視化し、統一的な把握へとつなげていくための棚卸し手順を解説します。

なぜ拠点のシステムは把握しづらいのか

拠点のシステムが本社から見えにくくなる背景には、いくつかの構造的な理由があります。

第一に、拠点の開設時期や経緯がそれぞれ異なることです。古くからある拠点は、本社の情シス部門が整備される以前から独自にシステムを導入してきた歴史を持つことが多く、逆に新しく開設された拠点は、開設を急ぐあまり、標準的な導入手順を踏まずにシステムが整備されているケースがあります。

第二に、物理的な距離が心理的な距離にもつながることです。本社にいる担当者は、目の前にあるシステムには自然と目が届きますが、離れた拠点のシステムには、意識的に確認しに行かない限り実態が見えません。台帳の運用設計そのものについては100人を超えたら属人化台帳をどう運用に乗せるかで扱っていますが、拠点をまたぐ場合、この台帳運用の難易度がさらに一段上がります。

第三に、拠点ごとに現地採用の担当者や、総務が兼任でIT管理を担っているケースが多く、その担当者と本社の情シス担当者との情報共有が定例化されていないことです。拠点の担当者にとっては「困ったときだけ本社に連絡する」という関係性であることが多く、平時の状態は本社側からは見えないままになりがちです。

拠点システムの散らばり方、3つの典型パターン

実際に拠点の棚卸しを進めると、次の3つのパターンに分類できることが多くあります。それぞれ対処のアプローチが異なるため、まずどのパターンに該当するかを見極めることが重要です。

パターン特徴主な原因
① 独自契約型拠点が本社とは別に、独自にSaaSやツールを契約している拠点の裁量で導入判断ができる権限体系、本社の標準ツールが拠点の業務に合わなかった
② 老朽インフラ型拠点に古いサーバーやネットワーク機器が残り、誰も詳細を把握していない拠点開設当初の担当者が既に異動・退職しており、引き継ぎが行われていない
③ 名義不明型契約者名義やアカウントの管理者が、現在誰なのか分からない拠点の担当者交代が繰り返される中で、契約情報の引き継ぎが漏れた

多くの拠点では、これら3つのパターンが単独ではなく複合的に存在しています。棚卸しを始める前に、この分類を念頭に置いておくと、実際に調査を進める際に「これはどのパターンの問題か」を意識しながら整理でき、対処の優先順位もつけやすくなります。

棚卸しの進め方: 本社主導だけでは限界がある

拠点の棚卸しを、本社の情シス担当者だけで進めようとすると、多くの場合うまくいきません。理由は単純で、本社の担当者は拠点の日常業務の実態を知らないため、何を聞けばよいかすら分からないからです。効果的な棚卸しには、拠点側の協力者を必ず巻き込む必要があります。

  1. 拠点ごとの連絡窓口を確定する: 各拠点で、日常的にIT関連の対応をしている人(総務担当、店舗責任者など)を洗い出し、棚卸しの協力者として正式に依頼する
  2. 共通の調査シートを用意する: 拠点ごとにバラバラな形式で報告を受けると集計が困難になるため、あらかじめ統一フォーマットの調査シートを準備し、全拠点に同じ形式で回答してもらう
  3. 現地訪問できる場合は優先的に訪問する: リモートでの聞き取りだけでは見落としが生じやすいシステム、特に物理的な機器(ネットワーク機器、複合機、防犯カメラのシステムなど)は、可能であれば現地で直接確認することをお勧めします
  4. 本社側でヒアリングを補完する: 拠点からの回答だけでは分からない部分について、経理の支払い記録やIT予算の申請履歴と突合し、報告に漏れているシステムがないか確認する

拠点の協力者に依頼する際は、「面倒な調査を押し付けられた」という印象を与えないよう配慮することも大切です。棚卸しの目的が、拠点の業務を制限することではなく、むしろ拠点のシステムトラブル発生時に本社からより早く適切な支援ができるようになるためであることを、丁寧に説明してください。

この説明を丁寧に行うかどうかで、その後の協力の得やすさが大きく変わります。特に、これまで本社からほとんど関与されてこなかった拠点ほど、突然の調査依頼に警戒感を持ちやすい傾向があります。「監視されるのではないか」という不安を払拭し、「サポートを受けやすくなる」というメリットを実感してもらえるよう、初回のコミュニケーションには特に時間をかける価値があります。

調査シートに含めるべき項目

拠点向けの調査シートは、本社の台帳フォーマットと基本構造を揃えつつ、拠点特有の事情を拾える項目を追加します。

  • システム・機器の名称: 何のシステムか、あるいは何の機器か
  • 導入時期と経緯: いつ、誰の判断で導入されたか(分かる範囲で)
  • 現在の管理者: 拠点内で実際に管理・利用している人
  • 契約者名義・支払い方法: 法人名義か、拠点独自の予算枠から支払われているか
  • 本社の標準システムとの重複有無: 同様の機能を持つ本社標準ツールが既にあるかどうか
  • 利用状況: 現在も活発に使われているか、ほとんど使われていないか

「本社の標準システムとの重複有無」は、拠点独自のツールを整理していく際に特に重要な項目です。重複が見つかった場合、本社標準への統一を検討する材料になりますが、拠点の業務に合わせてカスタマイズされている場合は、単純な統一が難しいこともあります。この判断は棚卸しの段階では保留にし、まず実態の可視化を優先してください。

調査シートは、可能であればオンラインフォームなど、回答したものがそのまま集計可能な形式で用意すると、後の作業が大きく楽になります。紙やメールでの自由記述形式は、拠点側にとっては書きやすい反面、本社側での集計・統合の手間が増えるという欠点があります。拠点数が多い会社ほど、この集計コストの差が実際の運用負荷に直結するため、フォームの形式選びにも一定の配慮を払うことをお勧めします。

棚卸し結果を統一台帳に集約する

各拠点から集まった調査結果は、本社が運用している統一台帳に集約します。この際、拠点のシステムであることが一目で分かるよう、台帳に「所在拠点」の列を追加しておくことをお勧めします。

台帳の項目(拠点対応版)内容
システム名対象システムの名称
所在拠点本社/支店A/営業所B など
システムオーナー拠点側の実質的な管理者
台帳更新担当本社の情シス担当者側の窓口
本社標準との関係重複あり/独自導入/代替不可の理由あり など

拠点のシステムをすべて本社標準に統一することが必ずしも正解とは限りません。拠点特有の業務要件によって独自ツールが必要な場合もあります。棚卸しの目的は統一を強制することではなく、まず「何が、どこに、誰の管理下で存在するか」を正確に把握することにあります。統一するかどうかの判断は、可視化された情報をもとに、その後改めて検討すればよいことです。

拠点担当者との継続的な連携体制を作る

一度きりの棚卸しで終わらせず、継続的に拠点の状況を把握し続けるためには、拠点担当者との定例的な連携の場を設けることが有効です。頻度は拠点の数や重要度に応じて調整しますが、四半期に1回程度、本社の情シス担当者と拠点の窓口担当者が状況を共有する機会を作ることをお勧めします。

この連携体制は、担当分担の設計とも関係します。100〜300人規模で情シスを担当するメンバーが2〜3人いる場合、拠点ごとの窓口を誰が担当するかを分担表に明記しておくと、拠点側から見ても「誰に相談すればよいか」が明確になります。担当分担の具体的な決め方については、兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で扱っています。拠点数が多い会社では、メンバーごとに担当する拠点群を割り振る「エリア担当制」のような形も選択肢になります。

「最初の棚卸しでは、正直、拠点からどこまで正確な情報が上がってくるか不安でした。ただ、四半期に1回の定例をカレンダーに組み込んでからは、拠点側も『次の定例までに確認しておこう』という意識を持ってくれるようになり、情報の精度が徐々に上がっていきました」

このような声からも分かる通り、拠点との連携は一朝一夕には確立しません。継続的な接点を粘り強く積み重ねることが、結果的に最も確実な精度向上の近道になります。

一度の棚卸しで完璧な精度を求めるのではなく、継続的な接点を持ち続けることで、少しずつ実態に近づけていくという姿勢が現実的です。

名義不明・老朽インフラの扱いは優先順位をつけて対処する

拠点の棚卸しでは、本社の棚卸し以上に、名義不明や老朽インフラの問題が頻出します。拠点の担当者が何度も交代してきた歴史がある場合、特にその傾向が強くなります。焦って一度にすべてを解明しようとせず、リスクの大きさに応じた優先順位づけを徹底することが、限られたリソースの中で成果を出す鍵になります。年季の入った拠点ほど、こうした未解決事項が積み重なっていることが多く、腰を据えて数ヶ月単位で解消していく心構えが必要です。

棚卸しの過程で、契約者名義が不明なシステムや、誰も詳細を把握していない老朽インフラが見つかることは珍しくありません。これらすべてを一度に解決しようとすると、通常業務を圧迫してしまいます。次のような優先順位で対処することをお勧めします。

  1. 業務への影響度が大きいもの: そのシステムが停止した場合、拠点の業務が止まってしまうものを最優先で調査・対処する
  2. セキュリティリスクが高いもの: 外部からアクセス可能な状態にあるにもかかわらず管理者が不明な機器など、放置がリスクに直結するものを次に優先する
  3. 利用実態が薄いもの: ほとんど使われていない、あるいは代替手段がすでにあるシステムは、無理に解明を急がず、廃止の検討を優先する

すべての謎を解明することよりも、リスクの大きいものから着実に潰していくという発想のほうが、限られたリソースの中では現実的です。特に、名義不明のドメインやサーバー契約については、放置しているとサービスの突然の停止や、退職者名義のまま契約が残り続けるといったリスクにつながるため、優先的に確認することをお勧めします。すでに退職した元担当者の個人名義で契約が続いているケースでは、本人への連絡が困難になる前に、できるだけ早く名義変更の手続きを進めることが望ましいです。

拠点の規模・業態による調査アプローチの違い

すべての拠点を同じ調査方法で棚卸しする必要はありません。拠点の規模や業態によって、システムの複雑さも、把握のしやすさも大きく異なります。次のように、拠点のタイプに応じて調査の深さを調整することをお勧めします。

拠点のタイプシステムの複雑さ推奨される調査の深さ
大規模拠点(数十人以上、専任の総務担当がいる)独自導入のツールが多く複雑になりがち詳細な調査シート+可能であれば現地訪問
小規模拠点(数名程度、専任担当なし)使用しているシステム自体が少ない簡易な聞き取りで十分な場合が多い
無人・少人数拠点(倉庫・工場など)人によるIT管理がほぼ行われていない設置されている機器の物理的な確認が中心になる

大規模拠点では、拠点内で独自に情報システムに近い役割を担っている人材がいることも多く、その人物との連携が調査の精度を大きく左右します。一方、小規模・無人拠点では、そもそも複雑なシステムが存在しないことが多いため、過度に詳細な調査を求めると、逆に協力者の負担になってしまいます。拠点ごとの実情に応じて、調査シートの詳細度を調整する柔軟さが求められます。この使い分けを最初に決めておくことで、拠点ごとの負担感の差を最小限に抑えながら、全体としての調査精度を底上げできます。

拠点システムの統一を急ぎすぎないための判断軸

棚卸しによって拠点ごとの実態が可視化されると、「これを機に全拠点で同じシステムに統一しよう」という発想が自然と生まれます。統一には運用コストの削減、管理の簡素化といった明確なメリットがありますが、拙速な統一は現場の反発や業務の混乱を招くこともあります。統一を検討する際は、次の判断軸を参考にしてください。

  1. 業務要件の差異はどの程度か: 拠点ごとの業務プロセスが大きく異なる場合、無理に同じシステムに統一すると、かえって現場の生産性が落ちることがある
  2. 移行にかかるコストと得られる効果のバランス: システムの移行には、データ移行やメンバーの再教育など、見えにくいコストが発生する。統一によるコスト削減効果が、これらの移行コストを上回るかを慎重に見積もる
  3. 拠点側の心理的な抵抗の大きさ: 長年使い慣れたシステムからの変更は、機能面の優劣とは別に、心理的な抵抗を招きやすい。統一を進める際は、十分な説明期間と移行サポートを用意する

統一を急ぐあまり、拠点側の理解を得ないまま進めると、表面上は統一されていても、裏で従来のシステムを使い続けているといった「隠れた二重運用」が発生することもあります。統一そのものを目的化せず、あくまで「業務がより円滑に回るための手段」として位置づけ、段階的に進めることをお勧めします。統一の判断を急がず保留にする場合でも、少なくとも「なぜ今は統一しないのか」という理由だけは台帳に書き添えておくと、後任者が同じ検討を一から繰り返さずに済みます。

海外拠点・グループ会社が絡む場合の追加の注意点

会社の規模が100〜300人にまで拡大していると、国内の複数拠点だけでなく、海外拠点やM&Aによって加わったグループ会社のシステムまで視野に入ってくることがあります。こうしたケースでは、国内拠点の棚卸しとは異なる注意点が加わります。

  • 言語・商習慣の壁: 海外拠点との調査シートのやり取りには、翻訳や現地の商習慣への配慮が必要になる。可能であれば現地のIT担当者や、間に立てる語学対応可能なメンバーを介して進める
  • 法規制の違い: データの保管場所や個人情報の扱いについて、国によって法規制が異なる場合がある。棚卸しの過程で、こうした法規制上の論点が見つかった場合は、必要に応じて専門家への確認を検討する
  • グループ会社の独立性: M&Aで加わったグループ会社は、独自の意思決定プロセスやIT予算を持っていることが多く、本社主導の統一を強制することが難しい場合がある。まずは情報共有の枠組みを作ることから始め、統合は段階的に進める

海外拠点やグループ会社を含めた棚卸しは、国内拠点だけの棚卸しに比べて格段に難易度が上がります。100〜300人規模の会社でこうした拠点を抱えている場合は、一度にすべてを網羅しようとせず、まずは影響度の大きい拠点や、リスクが高いと想定される拠点から着手し、段階的に対象を広げていくアプローチが現実的です。

拠点棚卸しの結果を予算計画に反映する

棚卸しによって拠点ごとのシステム利用状況やコストが可視化されると、次年度以降の予算計画にもその情報を活用できます。特に、拠点独自に契約されているSaaSの中には、本社が把握していないまま自動更新され続けている契約が見つかることも少なくありません。

棚卸し結果を予算計画へ反映する際は、次のような整理が有効です。

  1. 拠点ごとのIT関連支出を集計する: これまで個別に把握されていなかった拠点独自の契約費用を、全社のIT予算として統合的に把握できるようにする
  2. 重複契約によるコスト削減余地を洗い出す: 複数拠点で類似の機能を持つツールを別々に契約している場合、統一によるボリュームディスカウントなどのコスト削減余地がないか検討する
  3. 老朽インフラの更新計画に組み込む: 棚卸しで見つかった老朽化した機器やシステムについて、計画的な更新予算を次年度以降の予算に組み込む

拠点の実態が可視化されて初めて、全社的なIT予算の最適化が現実的な検討事項になります。棚卸しは単なる情報整理にとどまらず、経営判断の材料としても活用できる取り組みだと捉えてください。

拠点棚卸しにまつわるよくある質問

Q. 拠点の担当者が調査に非協力的な場合、どうすればよいですか。

まず、非協力的に見える背景には、単純に「日常業務が忙しく、調査に割く時間がない」という事情があることが多いです。調査シートの記入項目を最小限に絞り込む、記入例を丁寧に用意するなど、回答のハードルを下げる工夫がまず有効です。それでも進まない場合は、拠点の上長を通じて正式な業務として依頼する、あるいは本社側の担当者が電話やオンライン会議で直接ヒアリングする形に切り替えるといった対応を検討してください。

Q. 拠点によって回答の精度にばらつきがあります。どう扱えばよいですか。

精度の低い回答をそのまま台帳に反映するのではなく、「確度」を示すフラグを台帳に追加しておくことをお勧めします。例えば「確認済み」「拠点からの自己申告のみ」「未確認」といった区分を設け、確度が低い項目については優先的に追加確認を行う対象としてリスト化しておくと、限られたリソースの中でも精度向上に段階的に取り組めます。

Q. 拠点の棚卸しは誰が主導すべきですか。情シス担当者だけで進められますか。

情シス担当者が調査の設計と集計を主導することは適切ですが、拠点との実際のやり取りは、拠点の実情に詳しい総務担当や、拠点責任者の協力を得ながら進めるほうがスムーズです。100〜300人規模で情シスチームが2〜3人しかいない場合、すべての拠点を情シス担当者だけで訪問・確認することは現実的に難しいことが多いため、拠点側の協力者をいかに巻き込めるかが、棚卸しの成否を左右する大きな要素になります。本社の情シスチームは「実務を全部引き受ける役」ではなく、「拠点の協力者を束ね、情報を集約する役」だと捉え直すと、無理のない体制設計につながります。

拠点棚卸しの結果を「更新される台帳」に落とし込む

拠点の棚卸しを終えた後、その結果を一度きりの調査レポートとして保管するだけでは、時間の経過とともに再び実態と乖離していきます。棚卸しの成果を持続的な価値に変えるには、100人を超えたら属人化台帳をどう運用に乗せるかで解説している台帳運用の仕組みに、拠点分の情報をきちんと組み込むことが不可欠です。

拠点対応版の台帳を運用に乗せる際は、次の点を特に意識してください。

  • 拠点ごとの更新責任者を明確にする: 棚卸しで協力してもらった拠点の窓口担当者に、そのまま継続的な更新責任者になってもらうと、ゼロから関係を構築し直す手間を省ける
  • 本社側の集約担当を固定する: 拠点から上がってくる更新情報を、誰が台帳に反映するのかを本社側でも明確にしておく。拠点担当分の集約が特定の1人に偏りすぎないよう、担当分担表とも連動させる
  • 拠点間の棚卸しサイクルをずらす: すべての拠点を同時期に棚卸しすると、本社側の確認作業が一時期に集中してしまう。拠点ごとに棚卸しの時期を分散させることで、負担を平準化できる

拠点を含む台帳の運用は、単一拠点の会社に比べて明らかに複雑になります。しかし、この複雑さは「拠点が複数ある」という会社の実情そのものを反映したものであり、避けて通ることはできません。複雑さを受け入れた上で、継続可能な仕組みに落とし込んでいくことが、100〜300人規模で複数拠点を抱える会社にとっての現実的な到達点です。

拠点分の情報を台帳に統合した後は、拠点間の担当分担を明確にしておくことも重要です。誰がどの拠点のシステムオーナーとの窓口を担うのかを分担表に明記しておくことで、拠点側から見ても「本社の誰に相談すればよいか」が明確になります。担当分担の具体的な設計方法については、兼任が2〜3人に増えたときの担当分担、誰が何を持つかの決め方で詳しく解説しています。拠点棚卸し・台帳運用・担当分担は、いずれも単独では完結せず、互いに補完し合う関係にあることを意識しながら整備を進めてください。拠点との関係が一つずつ整理されていくたびに、本社側から見た会社全体の見通しも着実にクリアになっていきます。

まとめ: 拠点の棚卸しは「見えない前提」から始める

複数拠点を持つ会社の棚卸しで最も重要な心構えは、「本社から見えているものが全てではない」という前提に立つことです。拠点は、本社とは異なる歴史と事情を持ちながら、それぞれ独自にIT環境を育ててきています。この事実を受け入れた上で、拠点の協力者を巻き込み、統一フォーマットで情報を集約し、継続的な連携体制を築いていくことが、拠点のシステムを本社の管理下に統合していく最も現実的な道筋です。

一度の棚卸しで全ての拠点の状態を完璧に把握することは困難です。まずは影響度の大きい拠点、あるいは最も情報が不足している拠点から着手し、徐々に対象を広げていくことをお勧めします。拠点との継続的な接点さえ確保できれば、台帳の精度は時間とともに着実に向上していきます。

拠点が増えるほど、本社の情シス担当者が全てを直接把握することは物理的に難しくなっていきます。だからこそ、拠点の協力者を巻き込み、継続的に情報が流れてくる仕組みそのものを設計することが、100〜300人規模の会社にとって最も重要な取り組みになります。棚卸しは一度きりのプロジェクトではなく、拠点との関係性を育てていく継続的な活動だと捉えて取り組んでください。

拠点の存在は、複数人体制への移行を進める会社にとって、ある種の縮図でもあります。ひとりですべてを把握できていた時代から、複数の目と手を借りて全体を把握していく体制へ。本社と拠点という物理的な距離を越えて情報を共有し続ける仕組みは、まさにチーム化そのものが直面する課題の延長線上にあります。拠点棚卸しの取り組みを通じて培った「離れた場所の実態を可視化し、継続的に更新し続ける」という経験は、今後さらに組織が拡大していく局面でも、確実に生きてくるはずです。まずは最も気になる1つの拠点から、電話一本、あるいはオンライン会議一つで構いませんので、確認の一歩を踏み出してみてください。