| | Columns

50-150人規模・一人情シスの生存戦略:「理想」を捨てて「説明責任」で守る

50人から150人。この規模の企業におけるIT環境は、独特の「歪み」の中にあります。

カオスな創業期(〜30人)を抜け、組織としての体をなし始める時期ですが、ITへの投資対効果は大企業ほど明確ではなく、専任の情シス(情報システム担当者)は「良くて1人」、場合によっては総務との兼務というケースも珍しくありません。

本稿では、ベストプラクティスが通用しないこの領域で、たった一人で業務アプリ・インフラ・セキュリティを支える担当者が、**「業務を止めず」「事故を起こさず」「説明責任を果たす」**ために、どのように課題を構造化し、何を「やらない」と決めるべきかについて考察します。

前提:あなたは「スーパーマン」ではない

まず、現状を冷静に定義します。

  • 社員数:50〜150名
  • 工数:実質1人月以下(兼務含む)
  • 範囲:PCキッティングからSaaS管理、社内NW、セキュリティ対策、監査対応まで全て
  • 環境:外資系や親会社の意向により、身の丈に合わないコンプライアンス要求(監査など)が降ってくる可能性がある

この状況下で、教科書的な「ITIL」や「ゼロトラストの完全実装」を目指すのは自殺行為です。リソースが絶対的に不足している以上、全ての課題に100点で対応することは不可能です。

3つの「絶対防衛ライン」

何をして、何をしないかを決めるための判断軸は、以下の3点に集約されます。

  1. Business Continuity(業務を止めない)
    • 明日、社員が仕事のできる環境があるか?
    • SaaSが契約切れで止まらないか、PCの在庫はあるか、ネットは繋がるか。
  2. Safety(致命傷を避ける)
    • 全データ消失や、顧客情報の流出など、企業の存続に関わる事故を防げているか。
    • 「軽微なウイルス感染」は許容できても、「ランサムウェアによる全暗号化」は防がねばなりません。
  3. Accountability(説明できる)
    • 「なぜそれをやったのか」、あるいは**「なぜそれをやらなかったのか」**を経営層や親会社に論理的に説明できるか。

特に重要なのが3点目の「説明可能性」です。完璧である必要はありません。「リソース不足のため、リスクを受容して今回は見送った」という決定自体が、立派なITマネジメントです。

「監査」は目的ではなく「制約条件」

親会社やIPO準備などで、ITGC(IT全般統制)やITAC(IT業務処理統制)への対応を求められることがあります。これらは往々にして現場の実情を無視した「べき論」で迫ってきます。

ここで重要なマインドセットは、**「監査対応を最上位目的にしない」**ことです。

監査はあくまで「クリアすべき制約条件(Constraint)」の一つに過ぎません。例えば「パスワードは90日ごとに変更せよ」等の(現代では非推奨とされる)ルールを押し付けられた場合、真正面から戦って疲弊するのは得策ではありません。

  • 回避:「MFAを導入しているため、NISTのガイドラインに基づき定期変更は不要」と説明し、ポリシー変更を勝ち取る。
  • 受容:戦う工数が惜しければ、形だけ従う(ただし、それがセキュリティ強度を下げていることは認識しておく)。

監査のために業務が止まっては本末転倒です。「指摘事項ゼロ」を目指すのではなく、「重要な指摘事項以外は『改善計画中』として来期に回す」といった政治的な判断も、一人情シスの重要なスキルです。

「やらない判断」と「割り切り」の構造化

リソースが限られる中では、意図的な「手抜き」が必要です。ただし、無自覚な手抜きは怠慢ですが、意図的な手抜きは戦略です。

1. 資産管理の解像度

150人規模であれば、高価なIT資産管理ツールの導入・維持運用コストがペイしない可能性があります。

  • 割り切り案:Excel(またはスプレッドシート)管理で十分。
  • 条件:入社・退社フローに確実に組み込み、台帳とのズレを月次程度の棚卸で補正できれば、リアルタイムな自動収集は不要かもしれません。

2. SaaSのアカウント管理

本来はSSO(シングルサインオン)ですべてのSaaSを統合管理すべきですが、IdP(OktaやEntra IDなど)のライセンスコストや導入工数が障壁になることもあります。

  • 割り切り案:主要な「Google Workspace/Microsoft 365」のみガチガチに固める。
  • 代替案:主要IdPと連携できないマイナーなSaaSは、パスワードマネージャーの利用を推奨し、情シス側での集中管理を諦める(退職時の削除フローだけ厳格化する)。

3. ヘルプデスクのSLA

「即レス」を自分に課していませんか? それがあなたの首を絞めています。

  • 割り切り案:「チャットでの問い合わせは受け付けるが、解決は非同期(数時間〜翌日)」と宣言する。
  • 理由:あなたは「インフラ整備」や「セキュリティ対策」といった、緊急度は低いが重要度の高いタスクに集中する時間が必要です。

50人の「性善説」と150人の「統制」の狭間で

50人規模までは、互いの顔が見え、性善説(Trust)ベースの運用が機能します。「怪しいメールは開かないでね」という口頭注意で回ることもあります。

しかし、150人に近づくと、必ず「ルールの網」をすり抜ける事象が発生します。ここでシステムによる統制(Enforcement)への切り替えが必要になりますが、一気に全てをシステム化するのは不可能です。

判断の軸: 「事故った時に、誰か一人の責任ではなく、仕組みの不備と言えるか?」

  • NG: 「Aさんが退職者のアカウントを消し忘れた」
  • OK: 「退職フローが未整備で、削除トリガーが発生しなかった」(これは仕組みの問題なので、フローを作れば解決)

結論:余白を残した運用を

一人情シスにおける最大の成果物は、完璧なシステムではなく、**「変化に耐えうる柔軟性」「経営への納得感の提供」**です。

100点を目指して50点で終わるより、最初から「この3つだけは80点、残りは20点で良しとする」とステークホルダーと合意形成しておくこと。それが、カオスな中小企業のITを、一人で、しかし確実に守り抜くための生存戦略です。

あなたの会社のフェーズにおいて、今「捨てていいもの」は何でしょうか? まずはそこを定義することから始めてみてください。


AIに相談するためのプロンプト(テンプレート)

本記事で解説した「3つの絶対防衛ライン」に基づき、現在のタスクの優先順位を整理するためのプロンプトです。 [ ] の部分を書き換えて、AIに指示してください。

あなたは中小企業の「一人情シス」の業務優先順位付けに詳しいコンサルタントです。
現在、私の手元には大量のタスクがあり、パンク寸前です。
記事にある「重要度の3分類(1.業務継続、2.安全性、3.説明責任)」に基づき、以下のタスクリストを分類し、
「今はやらない(捨てる)」タスクについては、上司への論理的な断り方を考案してください。

# 企業情報
*   社員数: [例: 100名]
*   情シス人数: [例: 1名(総務兼任)]

# 現在のタスクリスト
1.  [例: 全社員のPCへの資産管理ソフト導入]
2.  [例: Windows Updateの適用確認]
3.  [例: 営業部長から頼まれた「便利な顧客リスト」の作成]
4.  [例: 壊れたWi-Fiルーターの交換]
5.  [例: 来期のIT予算案の作成]
6.  [例: 社長から言われた「AI導入」の検討]

# 出力してほしい内容
1.  **タスクのトリアージ**: 各タスクを「即実行」「計画的実行」「やらない(リスク受容)」に分類してください。
2.  **断りのロジック**: 「やらない」または「後回し」にするタスクについて、経営層や依頼者が納得する説明文(言い訳)を作成してください。
    *   キーワード:「セキュリティリスク」「リソースの集中」「コスト対効果」

# 制約条件
*   私はスーパーマンではありません。現実的に1人で回せる範囲に絞ってください。
*   「説明責任(なぜやらないか)」が果たせるロジックを重視してください。