Lockiron / The Fortress of a Solo IT Manager | 一人情シスの砦

情シス・社内SEのためのチケット管理システム構築・運用実践ガイド

目次

情シスの業務は、「入社対応」「PC故障」「パスワードリセット」といった定型業務と、「システム障害」「セキュリティインシデント」といった緊急対応が混在しています。これらを効率よく捌くために特化した、情シス向けチケット管理システムの運用設計について解説します。

情シスが抱えがちな課題

一般的なカスタマーサポートと異なり、情シスには以下のような特有の課題があります。

  • ユーザー数が社員数とイコール: 顧客が増減するのではなく、社員数がそのままサポート対象数となる。
  • 物理的作業の発生: PCのキッティングや修理手配など、オンラインで完結しないタスクが多い。
  • 承認フローの必要性: 権限付与やSaaSアカウント発行には、上長の承認エビデンスが必要になる。

情シスに必要な機能要件

これらの課題を解決するために、以下の機能が求められます。

  1. 承認ワークフロー: チケットのステータス遷移に「承認」プロセスを組み込めること。
  2. 資産管理連携: ‘PC-001’ の故障チケット起票時に、そのPCのスペックや購入日を即座に参照できること。
  3. ナレッジベース（FAQ）: ユーザーに自己解決を促すFAQ記事を簡単に作成・公開できること。

運用フロー例

1. 問い合わせ受付

メール、Slack、Webフォームからの依頼を全てチケット化します。

  • Slack連携: チャンネルでのメンションを自動でチケット起票し、Slackスレッドとチケットのコメントを同期させます。
  • メール取り込み: [email protected] へのメールを自動チケット化。

2. 一次切り分けとアサイン

情シスの当番担当者（ディスパッチャー）がチケットを確認し、「ネットワーク」「端末」「SaaS」などのカテゴリに分類し、適切な担当者に割り当てます。

3. 対応と承認

担当者は対応を実施します。権限付与が必要な場合、チケット上で上長に「承認依頼」を飛ばします。承認ログが残るため、後日の監査対応もスムーズです。

4. クローズとナレッジ化

解決後、チケットをクローズします。その際、特筆すべき解決策であれば「ナレッジベースに追加」ボタンを押し、FAQ記事として公開します。

よくある失敗と対策

失敗例：入力項目を増やしすぎて誰も使わなくなる

分析のためにと張り切って、「OSバージョン」「発生頻度」「ブラウザ種別」など必須入力項目を増やしすぎると、ユーザーは面倒がって電話をしてくるようになります。 対策: 必須項目は「件名」「内容」だけにし、入力ハードルを極限まで下げましょう。

失敗例：チケット放置による信頼低下

チケット化したことに満足して、対応がおろそかになるパターンです。 対策: 「24時間以内に一次返信がないチケット」をSlackに警告通知する自動化ルールを設定しましょう。

既存システムとの連携

Active Directory / Google Workspace 連携

ユーザー認証を統合（SSO）することで、利用者のログインの手間を省きます。また、ユーザー情報を同期しておけば、チケット起票時に「部署」「役職」が自動入力され、属性に応じた対応が可能になります。

Slack / Teams 連携

チャットツールとの連携は必須です。

  • 通知: チケットの更新をチャットに通知。
  • 操作: チャット上のボタン操作でチケットのステータスを変更したり、担当者を追加したりできます。

OSSツール（Redmine等）との住み分け

開発部門がRedmineやJiraを使っている場合、無理に統合する必要はありません。「社内問い合わせはZammad」「開発タスクはJira」と使い分け、相互にリンクを貼る運用が現実的です。

技術要件：OSS導入の実用例（Zammad × Docker）

情シス自身でサーバーを構築・運用する場合の選択肢として、モダンなUIを持つ Zammad の構築例を紹介します。実務運用ではデータベースの永続化が必要ですので、以下のような構成を用います。

ファイル名：compose.yaml

services:
  zammad-backup:
    command: ["zammad-backup"]
    entrypoint: /usr/local/bin/backup.sh
    environment:
      - BACKUP_TIME=03:00
      - HOLD_DAYS=10
      - POSTGRESQL_USER=zammad
      - POSTGRESQL_PASSWORD=zammad_db_pass
    image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-6.4.0-37}
    depends_on:
      - zammad-railsserver
      - zammad-postgresql
    links:
      - zammad-postgresql
    volumes:
      - zammad-backup:/var/tmp/zammad
      - zammad-data:/opt/zammad

  zammad-elasticsearch:
    environment:
      - discovery.type=single-node
    image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-6.4.0-37}
    restart: always
    volumes:
      - zammad-elasticsearch-data:/usr/share/elasticsearch/data

  zammad-init:
    command: ["zammad-init"]
    environment:
      - POSTGRESQL_USER=zammad
      - POSTGRESQL_PASSWORD=zammad_db_pass
    image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-6.4.0-37}
    depends_on:
      - zammad-postgresql
    links:
      - zammad-elasticsearch
      - zammad-postgresql
    volumes:
      - zammad-data:/opt/zammad

  zammad-memcached:
    command: memcached -m 256M
    image: memcached:1.6.29-alpine
    restart: always

  zammad-nginx:
    command: ["zammad-nginx"]
    expose:
      - "8080"
    image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-6.4.0-37}
    depends_on:
      - zammad-railsserver
    links:
      - zammad-railsserver
    ports:
      - "80:8080"
    volumes:
      - zammad-data:/opt/zammad

  zammad-postgresql:
    environment:
      - POSTGRESQL_USER=zammad
      - POSTGRESQL_PASSWORD=zammad_db_pass
      - POSTGRESQL_DB=zammad_production
    image: postgres:15.8-alpine
    restart: always
    volumes:
      - zammad-postgresql-data:/var/lib/postgresql/data

  zammad-railsserver:
    command: ["zammad-railsserver"]
    environment:
      - POSTGRESQL_USER=zammad
      - POSTGRESQL_PASSWORD=zammad_db_pass
    image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-6.4.0-37}
    depends_on:
      - zammad-memcached
      - zammad-postgresql
    links:
      - zammad-elasticsearch
      - zammad-memcached
      - zammad-postgresql
    restart: always
    volumes:
      - zammad-data:/opt/zammad

  zammad-scheduler:
    command: ["zammad-scheduler"]
    environment:
      - POSTGRESQL_USER=zammad
      - POSTGRESQL_PASSWORD=zammad_db_pass
    image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-6.4.0-37}
    depends_on:
      - zammad-memcached
      - zammad-postgresql
      - zammad-railsserver
    links:
      - zammad-elasticsearch
      - zammad-memcached
      - zammad-postgresql
    restart: always
    volumes:
      - zammad-data:/opt/zammad

  zammad-websocket:
    command: ["zammad-websocket"]
    environment:
      - POSTGRESQL_USER=zammad
      - POSTGRESQL_PASSWORD=zammad_db_pass
    image: ${IMAGE_REPO:-ghcr.io/zammad/zammad}:${VERSION:-6.4.0-37}
    depends_on:
      - zammad-memcached
      - zammad-postgresql
      - zammad-railsserver
    links:
      - zammad-memcached
      - zammad-postgresql
      - zammad-railsserver
    restart: always
    volumes:
      - zammad-data:/opt/zammad

volumes:
  zammad-backup:
    driver: local
  zammad-data:
    driver: local
  zammad-elasticsearch-data:
    driver: local
  zammad-postgresql-data:
    driver: local

起動・運用のポイント：

  1. docker compose up -d で起動。
  2. http://localhost でセットアップウィザードにアクセス。
  3. 必須: 本番運用では必ずリバースプロキシ（Nginx等）でSSL化し、.envファイルでパスワードを管理してください。

技術要件：Slack連携の自動化（概念コード）

OSSのチケットシステム（例：Zammad）などはWebhookに対応しています。これを利用して、独自の自動化スクリプトを組むことも可能です。

# 概念的な処理フロー
1. Slackでメンション受信
2. Webhookで中間サーバーへPOST
3. 中間サーバーがチケットシステムAPIを叩いてチケット作成
4. 作成されたチケットURLをSlackに返信

これにより、「チャットで気軽に依頼したいユーザー」と「チケットで管理したい情シス」の溝を埋めることができます。

FAQ（情シス向け）

Q. ひとり情シスでも導入すべきですか？

A. はい、ひとりだからこそ導入すべきです。自分が休んだ時の引き継ぎや、作業量の可視化（経営層へのアピール）にチケット履歴が最強の武器になります。

Q. スマホ対応は必要ですか？

A. 必須です。サーバールームでの作業中や、拠点移動中にスマホからチケットを確認・更新できることで、対応スピードが格段に上がります。

まとめ：守りのITから攻めのITへ

チケット管理システムで定型業務を効率化できれば、情シスはより付加価値の高い「攻めのIT」活動に時間を割けるようになります。まずは足元の問い合わせ管理から自動化を進めていきましょう。

次のステップとして、実際の企業の導入事例を見て、自社への適用イメージを膨らませてください。

チケット管理システム導入事例：情シス・ヘルプデスクの劇的改善

ホームに戻る