30-100人規模で複数部署から集まる野良システムの棚卸し優先順位

社員が30人を超えたあたりから、会社の中には「誰かが良かれと思って個別に契約したツール」が着実に増えていきます。営業部門が使い始めたSaaS、経理部門が独自に運用しているExcel台帳、製造部門が現場判断で導入した管理システム。それぞれの部署にとっては合理的な選択だったはずが、情シス担当としてこれらを俯瞰する立場になると、「一体いくつのツールが動いているのか」「どれが本当に必要で、どれが野良化しているのか」が誰にも分からない状態になっていることに気づきます。

このガイドは、こうした野良システムをすべて洗い出そうとして途方に暮れる前に、「どこから手をつけるべきか」の優先順位を決めるための考え方を整理したものです。棚卸しの手順そのもの(仕様書がない場合の調べ方、台帳の作り方)は既存の記事に譲り、このガイドでは「複数部署にまたがる野良システムが同時多発的に見つかったとき、限られた時間の中でどれから着手するか」という判断軸に絞って解説します。

このテーマを扱う前提として、まず「野良システム」という言葉が指す範囲を明確にしておきます。ここでいう野良システムとは、情シス担当や会社としての正式な承認プロセスを経ずに、部署単位・個人単位で導入・契約されたITツール全般を指します。無料プランのSaaS、個人のクレジットカードで契約された有料ツール、あるいは特定の担当者が自作したExcelマクロや簡易的なWebアプリまで、形態は様々です。共通しているのは、「会社としての管理台帳に載っていない」「情シス担当が存在を把握していない、あるいは把握していても詳細を説明できない」という点です。

30〜100人という規模は、こうした野良システムが最も発生しやすいタイミングでもあります。10人未満の頃は目が届いていたものが、部署が分かれ、各部署がある程度の裁量を持って業務を進めるようになると、部署ごとの最適化が進む一方で、会社全体としての統制が追いつかなくなります。この構造的な理由を理解しておくと、野良システムが見つかったときに「なぜこんなことになっているんだ」と個人を責める方向ではなく、「規模拡大に伴う自然な現象であり、今この段階で整理するのが適切なタイミングだ」という前向きな捉え方ができるようになります。

なぜ「全部同時に」棚卸しできないのか

30〜100人規模の会社で棚卸しに着手すると、多くの場合、想定より多い数のシステム・ツールが見つかります。10個、20個、場合によっては部署ごとの細かいExcel管理シートまで含めると50個近くに達することも珍しくありません。この数を前にすると、「全部を同じペースで、同じ深さで調べよう」としてしまいがちですが、これは兼任情シスにとって現実的な進め方ではありません。

全てを同時並行で調べようとすると、1つ1つの調査が浅くなり、結局どのシステムも中途半端な理解のまま止まってしまいます。本業と兼任している以上、使える時間には限りがあり、「広く浅く」ではなく「重要なものから深く」調べていく戦略のほうが、限られた時間の中で実効性のある成果につながります。

もう一つ、優先順位づけが必要な理由があります。それは、棚卸しの対象となる野良システムの「発見ペース」と「調査ペース」に、大きな差があることです。ヒアリングを進めれば、数日のうちに10件、20件のシステムが次々と見つかることも珍しくありません。一方、1件を深掘りして契約状況やデータの所在まで正確に把握するには、相応の時間がかかります。この発見ペースと調査ペースの差を埋めるために、「見つかったものから手当たり次第に調べる」のではなく、「見つけたものをまず一覧化し、優先順位をつけてから調査に着手する」という2段階のプロセスが必要になります。

優先順位づけの2軸: 影響範囲とブラックボックス度

野良システムの優先順位を決める際、次の2つの軸で評価することをお勧めします。

• 影響範囲: そのシステムが止まった場合、あるいは問題が起きた場合に、どれだけの範囲の業務・データに影響が及ぶか
• ブラックボックス度: そのシステムについて、社内で説明できる人がどれだけいるか。誰も説明できない・仕様書がない状態であるほどブラックボックス度が高い

この2軸を掛け合わせると、次の4象限に整理できます。

最優先で調査すべきは「影響範囲が大きく、かつ誰も説明できない(ブラックボックス度が高い)」システムです。この組み合わせが最も危険な理由は、問題が起きたときの被害が大きい上に、原因究明や復旧に時間がかかるためです。逆に「影響範囲は大きいが、社内に説明できる人がいる」システムは、リスクの所在が明確になっているため、優先度としては次点に位置づけられます。

残る2つの象限、「影響範囲は小さいがブラックボックス度が高い」「影響範囲・ブラックボックス度ともに低い」は、いずれも緊急性は低い一方、扱い方には注意が必要です。前者は、今は影響が小さくても、そのシステムの利用範囲が今後拡大した場合に一気にリスクが高まる可能性があるため、半年に1回程度は状況を再確認することをお勧めします。後者はそのまま放置して構いませんが、「本当に小さい影響範囲のままか」を定期的に見直す視点だけは持っておくと安心です。

影響範囲を判定する具体的な基準

「影響範囲が大きい」かどうかを判断する際、感覚だけに頼ると人によって基準がぶれてしまいます。次のような具体的な問いを使って判定することをお勧めします。

1. 止まったら、何人の業務が影響を受けるか: 特定の1人だけが困るのか、部署全体、あるいは全社が困るのか
2. 止まったら、顧客対応に影響が出るか: 社内業務だけで完結するか、それとも顧客への納期・請求・サポートに影響するか
3. 止まったら、どのくらいの時間で業務が停止するか: 数時間であれば代替手段でしのげるが、半日以上止まると深刻な影響が出る、といった目安
4. 個人情報や機密情報を扱っているか: 顧客の個人情報、財務情報、人事情報等を扱っている場合は、単なる業務停止以上のリスク(情報漏えい)が加わる

これらの問いに対する答えが「大人数」「顧客対応に直結」「長時間の停止」「機密情報を扱う」のいずれかに該当する場合、そのシステムは影響範囲「大」に分類してください。逆にいずれにも該当しない、特定の担当者だけが使う補助的なツールであれば「小」に分類して構いません。

ブラックボックス度を判定する具体的な基準

もう一方の軸である「ブラックボックス度」は、次の質問に答えられるかどうかで判定します。

• そのシステムを導入した経緯・理由を説明できる人が社内にいるか
• 障害が起きたとき、誰に連絡すればよいか分かっているか(ベンダーの連絡先、社内の担当者)
• そのシステムのデータが、どこにどう保存されているか把握しているか
• 契約内容(料金、更新時期、解約条件)を確認できる資料があるか

これらの質問にほとんど答えられない、あるいは「導入した本人がすでに退職・異動していて誰も分からない」という状態であれば、ブラックボックス度は「高」と判定してください。逆に、担当者が明確で、契約内容も資料として残っている場合は「低」と判定できます。

判定に迷うケースとしてよくあるのが、「担当者はいるが、その担当者が非常に多忙で、実質的に他の人が触れない」という状態です。これは形式的には「説明できる人がいる」ためブラックボックス度は低いように見えますが、実質的にはその担当者1人に依存しているという点で、高いブラックボックス度と同じリスクを抱えています。判定の際は、「説明できる人がいるかどうか」だけでなく、「その人以外にも、ある程度対応できる人がいるか」まで踏み込んで確認することをお勧めします。1人しか対応できない状態であれば、たとえ現時点で担当者が健在であっても、実質的にはブラックボックス度「高」に近い扱いで優先順位を上げておくほうが安全です。

部署からのヒアリングで見つける: 質問リスト

野良システムの多くは、情シス担当が能動的に探しに行かないと見つかりません。各部署へのヒアリングを通じて発掘していく必要があります。ヒアリングの際は、次のような質問を投げかけると、部署側も答えやすくなります。

• 「日常業務で使っているツール・システムを、大小問わず全部教えてください」
• 「その中で、情シスや会社として契約手続きをしていないものはありますか」(個人のクレジットカードで契約した、無料プランで使い始めた等)
• 「もしそのツールが急に使えなくなったら、業務にどれくらい影響が出ますか」
• 「そのツールについて、あなた以外に詳しい人はいますか」

特に3つ目と4つ目の質問は、そのままこのガイドで示した「影響範囲」「ブラックボックス度」の判定に直結する情報を引き出せるため、優先的に聞いておくとよいでしょう。ヒアリングの結果は、そのままシステム一覧表の元データとして活用できます。

ヒアリングの実施形式についても触れておきます。全部署に一斉にアンケートを送る方法と、部署ごとに個別に短時間のヒアリングを行う方法がありますが、30〜100人規模であれば、部署の代表者(部長・マネージャークラス)に個別にヒアリングする方法をお勧めします。アンケート形式は回答率が低くなりがちで、かつ「業務で使っているツール」という質問に対して、回答者が無意識に主要なツールしか書かず、周辺的に使っている小さなツールが漏れやすいという弱点があります。個別ヒアリングであれば、その場で「他には何かありませんか」と深掘りする質問を重ねられるため、抜け漏れを減らせます。

ヒアリングの所要時間は、1部署あたり15〜20分程度を目安にすると、聞く側・答える側双方の負担を抑えられます。長時間のヒアリングを設定すると、部署側の協力を得にくくなるだけでなく、聞く側の時間的な負担も本業を圧迫する要因になります。

ヒアリングだけでは見つからない野良システムの探し方

部署へのヒアリングだけでは、担当者本人が「これは業務システムだ」と自覚していないツールや、意図的に隠されているツールが漏れることがあります。ヒアリングを補完する方法として、次のようなアプローチも併用することをお勧めします。

• 経費精算データの確認: SaaSの月額利用料が経費として計上されている場合、経理部門の経費データを確認することで、ヒアリングでは出てこなかった契約が見つかることがあります
• メールの検索: 会社のメールシステムで「請求書」「ご利用ありがとうございます」といったキーワードを検索すると、契約済みのSaaSからの通知メールが見つかることがあります
• ネットワーク機器のログ確認: 技術的な知見が必要になりますが、社内ネットワークから外部への通信ログを確認することで、社内で使われているクラウドサービスの利用実態を把握できる場合もあります

これらの方法は、いずれもヒアリングだけでは拾いきれない「隠れた野良システム」を発見するための補完策です。全ての会社で技術的な手段が使えるとは限らないため、まずは経費精算データの確認から始めることをお勧めします。比較的手軽に着手でき、費用が発生しているツールを網羅的に洗い出せるためです。

経費精算データを確認する際は、勘定科目の「通信費」「消耗品費」「支払手数料」といった項目に紛れ込んでいるSaaS利用料を見落とさないよう注意してください。多くの会社では、SaaSの利用料が「システム費」のような明確な科目で計上されるとは限らず、少額のサブスクリプション費用は雑多な科目にまとめて処理されていることがあります。過去1年分の経費データをキーワード(「月額」「サブスクリプション」「利用料」等)で検索し、心当たりのない支出がないかを確認する作業は、地道ですが野良システムの発見に効果的です。

無料プランで使われているツールについては、経費データにも痕跡が残らないため、発見がさらに難しくなります。この場合は、部署へのヒアリングに加えて、「会社のドメインのメールアドレスで登録されているサービス」を推測する手がかりとして、迷惑メールフォルダや過去のメール履歴を確認する方法も有効です。無料プランのSaaSであっても、利用規約の変更通知やアップデート情報のメールは定期的に送られてくることが多く、こうした通知メールの存在から利用実態を推測できます。

優先順位をつけた後の進め方: 上位2〜3件から着手する

影響範囲とブラックボックス度で洗い出した野良システムの一覧ができたら、最優先の象限に該当するものから、上位2〜3件だけをまず深掘り調査することをお勧めします。一度に全ての最優先案件に手をつけようとすると、結局どれも中途半端になってしまうためです。

深掘り調査で確認すべき内容は、次の項目に整理できます。

これらの項目を1件ずつ埋めていく作業は、時間がかかります。1件あたり数時間〜半日程度を見込み、優先度の高いものから着実に潰していく進め方が現実的です。全件を調べ終えるまで公開・共有を待つのではなく、調べ終わった案件から順に社内の管理台帳に反映していくことで、少しずつでも会社全体の見通しが良くなっていきます。管理台帳そのものの作り方は属人化を防ぐ社内システム管理台帳の作り方で詳しく解説しているので、あわせて参照してください。

深掘り調査を進める中で、仕様書や説明資料が一切残っていないシステムに出会うことも珍しくありません。特にブラックボックス度が高いと判定されたシステムほど、この傾向は強くなります。仕様書がない状態からどう調査を進めればよいかについては、仕様書がないシステムを引き継いだときの調査手順で6段階の具体的な手順を解説しているので、深掘り調査が難航した場合の参考にしてください。

深掘り調査の結果、想定より深刻な状態(例えば、契約が自動更新されたまま誰も内容を把握していない、退職者のアカウントで管理者権限が残っている等)が見つかることもあります。このような場合は、優先順位リストの他の案件を後回しにしてでも、その場でリスクの高い箇所への応急対応を優先してください。優先順位づけはあくまで「限られた時間をどこに配分するか」の指針であり、調査の過程で見つかった明確なリスクへの対応より優先されるべきものではありません。

「今すぐ止める」べきシステムの見分け方

棚卸しを進める中で、稀に「今すぐにでも利用を停止すべき」レベルのリスクを抱えたシステムが見つかることがあります。次のいずれかに該当する場合は、優先順位づけを待たず、即座に対応を検討してください。

• 退職済みの社員の個人アカウントで契約されたままになっているサービス
• サポートが終了しており、セキュリティアップデートが提供されていないシステムに、顧客の個人情報が保存されている
• 誰もパスワードを管理しておらず、アクセスできる人が実質的にいない状態のシステム(にもかかわらず稼働している)

これらは、通常の優先順位づけのプロセス(影響範囲×ブラックボックス度で順位をつけて、上位から調査する)を経る前に、緊急対応が必要なケースです。棚卸しの過程でこうした事例を見つけたら、その場で経営層に報告し、対応方針を相談してください。

部署間の温度差にどう向き合うか

棚卸しを進めていくと、部署によって協力度合いに大きな差が出ることがあります。あるチームは業務ツールの一覧をすぐに教えてくれる一方、別のチームは「うちには特に野良システムはないと思う」と回答しつつ、後から調べると実は複数のツールを個別契約していた、というケースも少なくありません。

この温度差の背景には、「情シスに指摘されると、勝手に契約したことを咎められるのではないか」という警戒心があることが多くあります。ヒアリングの際は、あくまで目的が「リスクの把握」であり、「勝手に契約したことを責めるためではない」ことを明確に伝えることが重要です。責める姿勢で臨むと、次第に部署側が情報を隠すようになり、かえって野良システムの発見が難しくなります。

協力度合いの低い部署に対しては、いきなり詳細なヒアリングを求めるのではなく、まず信頼関係のある部署から着手し、そこでの成功体験(「協力したら実際に業務が楽になった」「トラブル対応が早くなった」)を社内に共有することも効果的です。他部署の好事例が伝わることで、当初は消極的だった部署も徐々に協力的になっていくケースは少なくありません。棚卸しは1回のヒアリングで完結させようとせず、部署ごとの温度差を踏まえて、段階的に協力を広げていく前提で計画を立てることをお勧めします。

協力を得やすくするための言い方の工夫としては、次のような伝え方が有効です。

「今使っているツールを教えてもらうのは、それをやめさせるためではありません。もし障害が起きたときに、皆さんの業務が止まらないように、会社としてバックアップ体制を整えるための情報収集です」

この伝え方であれば、部署側にとっても「自分たちの業務継続性を守るための協力」という前向きな文脈で受け止めやすくなります。

棚卸しの結果を、次の判断にどうつなげるか

棚卸しは、それ自体が目的ではなく、その後の判断のための材料集めです。優先度の高いシステムから順に深掘り調査を終えたら、それぞれについて「このまま使い続けるか」「契約を正式なものに切り替えるか」「代替システムへの移行を検討するか」といった次のアクションを決めていく必要があります。

特に、部署ごとに乱立したSaaSが複数見つかった場合、機能が重複しているものを1つに統合できないかという観点も重要です。似た機能を持つツールが3つの部署でそれぞれ個別に契約されている状態は、コストの無駄であると同時に、それぞれが別々にブラックボックス化するリスクの温床にもなります。統合の検討は棚卸しの直後に急いで進める必要はありませんが、優先度の高いシステムの調査が一段落した段階で、まとめて検討する時間を確保することをお勧めします。

統合を検討する際は、機能が似ているからといって安易に一本化を急がないことも重要です。それぞれのツールには、その部署の業務フローに合わせた微妙なカスタマイズや使い方の癖が根付いていることが多く、いきなり1つに統合しようとすると、現場からの反発や、移行に伴う一時的な業務混乱を招きます。統合を進める場合は、まず各部署の利用実態と要望を丁寧にヒアリングした上で、影響の小さいツールから段階的に統合していくアプローチが安全です。

もう一つ、棚卸しの結果を踏まえて検討すべきなのが、「今後、新しいツールを部署が個別に導入する際のルール」です。棚卸しをして終わりにすると、時間が経てばまた同じように野良システムが増えていきます。「新しいSaaSを契約する前には、必ず情シス担当に一声かける」という簡単なルールを設けるだけでも、今後の野良システムの発生を大きく抑制できます。このルールは、複雑な承認フローである必要はなく、チャットツールで一言相談してもらうだけの軽い運用で十分機能します。重要なのは、ルールの厳格さよりも「情シスを経由する」という習慣そのものを社内に定着させることです。

棚卸しにかかる期間の目安

30〜100人規模の会社で、部署をまたいだ野良システムの棚卸しにどれくらいの期間がかかるかは、会社の規模や複雑さによって幅がありますが、目安としては次のような段階を踏むイメージを持つとよいでしょう。

1. 1〜2週間目: 各部署へのヒアリングを実施し、システム一覧の初版を作成する
2. 3〜4週間目: 経費データやメール検索等で、ヒアリングだけでは見つからなかったシステムを補完する
3. 1〜2ヶ月目: 影響範囲×ブラックボックス度で優先順位をつけ、上位2〜3件の深掘り調査を実施する
4. 2〜3ヶ月目以降: 深掘り調査を残りの案件にも順次拡大し、並行して管理台帳への反映を進める

この期間はあくまで目安であり、本業との兼ね合いで前後することは十分にあり得ます。重要なのは、期限を区切って「いつまでに、どこまでやるか」を最初に決めておくことです。目安がないまま進めると、棚卸しが際限なく続き、いつまでも「まだ途中です」という状態から抜け出せなくなります。

期限を区切る際は、経営層にも進捗の目安を共有しておくことをお勧めします。「今、棚卸しのどの段階にいて、いつ頃に主要なリスクの把握が完了する見込みか」を定期的に報告することで、経営層も状況を把握でき、必要に応じて外部リソースの活用など追加の判断を検討しやすくなります。棚卸しの進捗が見えないまま時間だけが過ぎていくと、経営層からは「情シス担当は一体何をしているのか」という不信感につながりかねません。小さな進捗でも定期的に共有する姿勢が、兼任情シスへの信頼を積み重ねる上でも重要です。

まとめ: 全部は無理でも、危険な2〜3件を見逃さない

複数部署から集まる野良システムを目の前にしたとき、最も避けるべきなのは、全てを均等に調べようとして疲弊し、結局どれも深く理解できないまま時間だけが過ぎていくことです。影響範囲とブラックボックス度の2軸で優先順位をつけ、最も危険な組み合わせに該当するシステムから、限られた時間を集中的に投下してください。

全てのシステムを完璧に把握することを目指すのではなく、「もし何か起きたら会社に深刻なダメージを与えかねない、危険な2〜3件」を確実に押さえることが、兼任情シスにとって現実的で効果的な棚卸しの進め方です。棚卸しが一段落したら、そこで得た情報を記録として蓄積し続ける仕組みも合わせて整えておくと、次に同じ作業を一からやり直す必要がなくなります。詳しくはこちら→兼任情シスが「自分しか分からない」状態を作らないための最低限の記録術

野良システムの棚卸しは、一度やって終わりの作業ではなく、会社が成長を続ける限り、形を変えて繰り返し発生する課題です。今回優先順位をつけて対応した2〜3件が片付いたら、次点だったシステムを新たに最優先候補として見直し、少しずつ範囲を広げていく。このサイクルを半年〜1年単位で回し続けることで、会社の規模がさらに拡大しても、野良システムが手に負えない規模にまで膨れ上がる事態を防げます。今日見つかった野良システムのうち、最も影響範囲が大きく、最も誰も説明できないものは何か。まずはその1件を思い浮かべるところから始めてください。