一人情シスが「全部やらない」ためのIT判断フレームワーク：生存と説明責任を両立する羅針盤

これまで本サイトでは、SaaSの断捨離、セキュリティポリシーの引き算、資産管理の粒度、BI導入の拒否など、個別のトピックについて**「いかにしてやらないか」**を語ってきました。

なぜ「やらない」ことにこれほどこだわるのか。 それは、社員100人規模の「一人情シス」というリソースが、物理的にすべての要求を満たせないからです。 しかし、単に「忙しいから無理」と断るだけでは、それは「職務放棄」とみなされます。

必要なのは、**「戦略的にやらない」という判断軸と、それを周囲（経営層・監査・ユーザー）に納得させる「説明責任のプロトコル」**です。

本稿では、これまでの記事の根底に流れる、一人情シスのための「IT判断フレームワーク」を体系化し、貴方が明日から迷わずに意思決定できるための「羅針盤」を提示します。

1. コア・バリュー：「生存」と「信頼」

すべての判断の基準となるのは、以下の2つの価値観です。

1. 生存（Survival）: 情シス自身がパンクせず、かつ会社が致命的なリスク（倒産・法違反）で死なないこと。
2. 信頼（Trust）: 「できない」と言っても、「あいつが言うなら正しいのだろう」と周囲に信じてもらえること。

この2つを守るために、私たちは以下のフレームワークを使ってあらゆるタスクを篩（ふるい）にかけます。

2. IT判断フレームワーク：3つのフィルター

新しいツール導入、セキュリティ対策、業務改善の要望。 これらが飛んできた時、以下のフローチャートに従って「やる/やらない」を即座に判定します。

フィルター1：「死ぬ」リスクはあるか？（生存本能）

• 問い: 「これを放置したら、会社が倒産するか？ 法律違反で書類送検されるか？ 銀行取引が停止するか？」
• 具体例:
  • ランサムウェア対策（バックアップ）：データ全損＝倒産。これはYes。
  • 消費税法改正対応：不履行＝法違反。これはYes。
  • 「Wi-Fiが遅い」：不便だが死なない。これはNo。
• 判断: Yesなら、他の全てを捨ててでもやります。これが「コア業務」です。

フィルター2：「説明責任」を果たせるか？（知的防衛）

• 問い: 「『やらない』ことに対して、論理的な言い訳（ロジック）が立つか？」
• 具体例:
  • 監査指摘「MDMが入っていない」
    • ロジック：「コスト対効果が見合わないため、リスク受容します（経営承認済）」。
    • これで監査が通るなら、**Yes（やらない）**です。
  • 現場要望「ChatGPTを使いたい」
    • ロジック：「情報漏洩リスクがあるので、Azure OpenAIの環境が整うまで禁止」。
    • これで現場が納得するなら、**Yes（やらない/延期）**です。
• 判断: やらなくて済むためのロジック構築に全力を注ぎます。作業よりも「説明資料作成」の方がカロリーが低いなら、そちらを選びます。

フィルター3：「運用」が回るか？（持続可能性）

• 問い: 「導入した後、自分がいなくても勝手に回るか？ あるいは月1回以下のメンテで済むか？」
• 具体例:
  • SaaS導入：ベンダーがメンテしてくれる。Yes。
  • オンプレサーバー構築：自分でパッチ当てが必要。No。
  • 複雑なExcelマクロ作成：壊れたら自分しか直せない。No。
• 判断: Noなら、どれだけ便利そうでも導入してはいけません。それは「負債」です。

3. 優先順位付けのマトリクス

上記のフィルターを通しても、「やるべきこと」が複数残った場合、どう順序をつけるか。 ここでも「一人情シス特有」の軸を使います。

• 最重要ルール: **「手離れの良さ（Maintenance Free）」**を最優先評価指標にします。
• 効果が高くてもメンテナンスコストが高い（左下）ものは、外部ベンダーに丸投げできる予算がつかない限り、手を付けてはいけません。

4. 説明責任のアーキテクチャ

「やらない」と決めた時、それをどうドキュメント化するか。以前の記事でも触れた「リスク受容台帳」に加え、以下の構成要素を整備します。

① ITロードマップ（3年計画）

「今はやりません」という言葉に説得力を持たせるのは、**「いつかやるつもりはある（今はその時ではない）」**という文脈です。 A4一枚のロードマップに、以下のように書きます。

• 2026年（今年）: 基盤固め（ID統合、セキュリティ最低限）
• 2027年: 攻めのIT準備（CRM導入、BI検討）
• 2028年: データ活用（AI導入）

「BIは2027年のフェーズです」と言えば、前向きな延期になります。

② サービスカタログ（SLAの明文化）

情シスの提供業務をメニュー化し、**「メニューにないものは提供しない」**と宣言します。

• PCキッティング: 提供する（納期3日）
• アカウント発行: 提供する（納期1日）
• Excel操作指導: 提供しない（自助努力）
• 自宅Wi-Fiのサポート: 提供しない

これを「ITサービスカタログ」として全社公開します。これにより、「情シスは何でも屋」という認識を払拭します。

5. 将来、人員が増えた時の「拡張モデル」

これまでは「一人」を前提としてきましたが、もし部下が入ってきたり、外注費が増えたりした場合は、フィルターを緩めます。

• 拡張フェーズ1（アシスタント採用）:
  • **フィルター3（運用）**を緩和します。「手順書があれば他人が回せるルーチンワーク（PCキッティング、ログチェック）」を解禁し、アシスタントに任せます。
• 拡張フェーズ2（専任エンジニア採用）:
  • フィルター3をさらに緩和し、左下の「手離れ：悪」だが「影響度：高」な領域（独自開発、BIパイプライン構築）に手を出します。

重要なのは、**「人が増えるまでは、絶対にフィルターを緩めない」**ことです。 「人が増える前提」で先にシステムを入れてしまい、採用に失敗してパンクするケースがあまりに多いからです。

6. あとがき：一人情シスの誇り

このフレームワークは、一見すると「逃げ」や「妥協」の産物に見えるかもしれません。 しかし、資源の制約がある中で最適解を導き出し、組織を存続させることは、経営そのものです。

一人情シスは、IT担当者であると同時に、**「ITリソースの最高投資責任者」**でもあります。 「やらない」と決める勇気。 「今はその時ではない」と説明する知性。 それこそが、貴方がプロフェッショナルである証です。

このフレームワークが、日々の理不尽な要求の嵐の中で、貴方が正気を保ち、胸を張って仕事をするための「盾」となることを願っています。

参考文献・リンク

• 経済産業省：システム管理基準
  • システム監査の拠り所となる基準。リスク評価とコントロールの考え方がベースにあります。
• IPA：中小企業の情報セキュリティ対策ガイドライン
  • 中小企業における「身の丈に合った」対策の根拠となります。
  • 「Toil（トイル：労苦）」の削減という概念は、一人情シスの「手離れの良さ」に通じます。

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

本記事の「IT判断フレームワーク」を使って、降りかかってきた無理難題をさばくためのプロンプトです。

あなたは中小企業のITガバナンスとリソース管理の専門家です。
「一人情シス」である私のもとに、以下の要望が届きました。
記事にある「生存と信頼のための判断フロー」に基づき、この要望への対応方針（やるか、やらないか、どう断るか）を策定してください。

# 企業情報
*   社員数: [例: 120名]
*   情シス人数: [例: 専任1名]

# 届いた要望
*   依頼者: [例: マーケティング部長]
*   要望内容: [例: 海外製の新しいマーケティングオートメーションツールを導入したい]
*   期限: [例: 来月から使いたい]
*   現状の課題: [例: 英語サポートのみ。SSO非対応。個人情報の入力あり]

# 判断の指針（判断フロー）
1.  **死ぬリスクはあるか？**: これをやらないと会社が倒産したり法に触れるか？
2.  **説明責任は果たせるか？**: 「やらない」というロジック（セキュリティ、コスト、運用負荷など）は立つか？
3.  **運用は回るか？**: 導入後、情シスの手間をかけずに（または自動化して）維持できるか？

# 出力してほしい内容
1.  **判定結果**: 「やる（即対応）」「やる（条件付き）」「断る（延期含む）」のどれか。
2.  **意思決定のロジック**: 上記判断フローのどこで引っかかったかを解説してください。
3.  **回答メール案**: 依頼者に対する、角が立たず、かつ論理的な回答メールの文面を作成してください。