Lockiron/一人情シスの砦
||Philosophy

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

#情シス#キャリア論#ガバナンス#意思決定#フレームワーク

目次

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

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

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

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

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

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

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

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

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

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

graph TD
    Request[要望・課題の発生] --> Filter1{フィルター1：<br>「死ぬ」リスクはあるか？}
    
    Filter1 -- Yes --> DoNow[【最優先】<br>即座に対応<br>（リソースを全振り）]
    Filter1 -- No --> Filter2{フィルター2：<br>「説明責任」を果たせるか？<br>（代替案・論理武装）}
    
    Filter2 -- Yes --> Explain[【やらない】<br>リスク受容・代替統制を<br>経営に説明して終了]
    Filter2 -- No --> Filter3{フィルター3：<br>「運用」が回るか？<br>（自動化・放置可能）}
    
    Filter3 -- Yes --> DoAuto[【やる】<br>SaaS/自動化で実装]
    Filter3 -- No --> Reject[【断る】<br>運用リソース不足を理由に<br>却下・延期]
    
    DoNow --> Record[対応履歴を残す]
    Explain --> Register[リスク受容台帳に記録]
    DoAuto --> Doc[簡易マニュアル作成]
    Reject --> Backlog[将来の検討リストへ]

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

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

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

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

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

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

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

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

影響度：高 影響度：低
手離れ：良 ① 即実行（Win-Win）
例：SaaSのSSO化、Teams導入		 ③ 隙間時間（趣味）
例：便利ツールの配布
手離れ：悪 ② 覚悟の泥沼（Project）
例：基幹システム入替、Pマーク取得		 ④ 絶対にやるな（Waste）
例：OSS資産管理、独自アプリ開発
  • 最重要ルール: 「手離れの良さ（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リソースの最高投資責任者」でもあります。 「やらない」と決める勇気。 「今はその時ではない」と説明する知性。 それこそが、貴方がプロフェッショナルである証です。

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

参考文献・リンク

ホームに戻る