Upgrade to Pro — share decks privately, control downloads, hide ads and more …

改善しないと、タスクが回らない。 “てんこ盛りポジション” を引き継いだ情シスの、入社3ヶ月の...

改善しないと、タスクが回らない。 “てんこ盛りポジション” を引き継いだ情シスの、入社3ヶ月の業務改善録

2026/07/23 【日経×一休×MIXI】現場の声を聞く情シスのオペレーション改善〜運用改善と業務圧縮の進め方〜

Avatar for Kurumi Watabe

Kurumi Watabe

July 24, 2026

Other Decks in Programming

Transcript

  1. MY POSITION 引き継いだのは “てんこ盛りポジション ” もともと業務委託の方が担っていたポジションを、正社員として引き継ぎ 端末キッティング Mac / Windows

    / iPhone 支社対応 発送・リモート対応 入社オリエン 1回あたり 約1時間 物理対応 資産・貸出・棚卸し ヘルプデスク Slackで日々問い合わせ その他運用 アカウント・SaaS管理
  2. AGENDA 今日お話しすること 01 02 EX 運用を変える 仕組みを作り替える AI活用に伴走する 入退社対応の構造改善 ヘルプデスクの裏側刷新

    番外編:秘書向けAIアシスタント お金ゼロ・コードゼロ JSM → Slack × Notion 情シスならではの価値
  3. 改善 01 ─ 運用を変える 入退社対応、実はこれだけ重い 約1 時間 / 回 約2

    時間 / 名 月3〜5 回 入社オリエンテーション 貸与物準備・キッティング バラバラに発生する入社対応 入社のたびに、オリエン・キッティング・調達が “都度・個別” に発生していた
  4. 改善 01 ─ 運用を変える 入社日の固定化を、人事に提案した BEFORE AFTER • 誰も整理しようとしてこなかった領域 •

    人事は採用が決まりそうな都度、情シスに個別 確認 • 工数を定量化して人事へ共有・相談 • 入社日を月曜に固定して運用 情シスは急な入社にバタつき、毎日のようにオ リエンやキッティング • 都度の個別調整が消え、双方が楽に • 一番効いた改善は、ツールでもコードでもなく “相談” だった
  5. 改善 01 ─ 運用を変える 退職者への返却連絡は、介入ゼロに 退職のたびに手動で連絡していた → 退職日をトリガーに自動送信(GASで実装) 退職情報が集約 実際に自動送信される返却案内

    スプレッドシートに集まる ↓ 自動トリガー 退職日を起点に発火 ↓ 返却案内を自動送信 対象者へ自動で連絡 情シスの介入ゼロ。 入社は固定化で「まとめる」、退職は自動化で「なくす」
  6. 改善 02 ─ 仕組みを作り替える 問い合わせは “あえて” 全部Slackで受けている この設計は正しい ただし、受ける側は …

    • 自然言語でそのままやり取りできる • 問い合わせが全く型化されていない • 営業などPCを開けない場面でも、スマホから気軽 に相談できる • 分類・記録・追跡はすべて手作業 • 対応コストが情シス側に集中 • ユーザーにとっての入口は最高 → ユーザー体験は変えずに、裏側だけを作り替える
  7. 改善 02 ─ 仕組みを作り替える そのチケット管理ツール、見合ってる ? 利用目的は ポータル経由の依頼 それでもコストは チケット管理のみ

    0件 年数十万円 JiraServiceManagement (JSM)の 機能はほぼ未使用 社内で使っている人はゼロ 使い方に対して明らかに過剰 「Notionでチケット管理ができれば、解決するのでは ?」と課題提起
  8. 改善 02 ─ 仕組みを作り替える 裏側はこう作り替えている 自作連携アプリ (AWS Lambda) 社員 Slack

    ヘルプデスクchに いつも通り問い合わせ • 問い合わせを受信・整形 • Notionへ自動チケット化 • スレッドを双方向同期 Notion チケット DB • 種別の自動判定 • ステータス管理 • タスクと紐づけ ↑↓ スレッド双方向同期 カスタムエージェントで一次対応(検証中) トリアージch(情シス側) 従来できていたことはそのままに、裏側の仕組みだけ作り替える。 整備したドキュメントDBを知識として、 AIが最初の回答を返す
  9. 改善 02 ─ 仕組みを作り替える 実際の画面: Slack × Notion ① ヘルプデスク

    chの投稿 ② トリアージ ch(情シス側) ③ Notionチケット DB
  10. 改善 02 ─ リリース済みの実例 問い合わせを「なくした」話 ─ 社用携帯の番号管理 社用携帯の電話番号は、もともとスプレッドシートで手動管理していた ① 管理していた部署がなくなる

    スプレッドシートを誰もメンテナンスしなくなった ↓ ② 情報が古くなり、信頼できない いつから更新されていないかも分からない状態に ↓ ③ 問い合わせが情シスに集中 「◯◯さんの番号を知りたい」が情シスに集まる 情シスにしか分からない領域だからこそ、情シスが仕組みごと作り替えるしかない
  11. 改善 02 ─ リリース済みの実例 確定する瞬間に、自動で登録する YESODを従業員情報の置き場に。番号が「確定する瞬間」=貸与のタイミングで自動登録する 自作Lambdaで自動登録 Snipe-IT 社用携帯の貸与登録 (情シスの通常作業)

    GASで自動出力 YESOD 従業員情報の置き場に 電話番号もここに集約 共有シート 誰でも最新の番号を参照可能に メールアドレスも同様に: 既存のアカウント作成フロー内でYESODへの自動反映を追加実装 「問い合わせに答える」から「問い合わせが発生しない」へ。 通常フローに組み込んだから破綻しない