2025/10/16_人手不足でも回る情シスになる 内製ツールで実現する業務効率化のリアル事例

https://iij-cd.connpass.com/event/368777/

2024年秋に開催されたウェビナー「人手不足でも回る情シスになる～内製ツールで実現する業務効率化のリアル事例～」の登壇資料です。

ある日突然「一人情シス」になった担当者が、元開発エンジニアとしての経験を活かし、いかにして日々の業務を乗り越えていったか。Slackでの問い合わせ対応、頻繁な組織改編に伴うアカウント・権限管理、手作業でのレポーティングといった「守りの情シス」業務を、GAS (Google Apps Script) やkintone、Notionなどを駆使して自動化・仕組み化していったリアルな事例をご紹介します。

リソース不足を乗り越え、攻めの情シス活動へシフトしていくまでの具体的な道のりをまとめました。

■キーワード
情シス, コーポレートIT, 一人情シス, 業務効率化, 自動化, 内製化, GAS, Google Apps Script, kintone, Notion, Slack, ヘルプデスク, アカウント管理, 権限管理, 守りの情シス, 攻めの情シス

Transcript

1. 人手不足でも回る情シスになる ～内製ツールで実現する業務効率化のリアル事例～
2. 大学卒業後、SIerで保険系のwebサイトの開発 一気通貫してヒアリング〜アフターフォローまで携わりたいと思いコーポレー トエンジニアへ。 課題解決の選択肢として、プログラミングやSaaS導入(リプレイス含む)や 業務フロー変更など、あらゆる手段が取れるのが魅力だと思っています。 GASでツールを作成するのが得意で、GASのOSSライブラリや入門書を書い たりしています。 長峰 謙 自己紹介
3. ランサーズ株式会社 会社紹介 社員数：150名ほど(単体) グループ会社：2社
4. ランサーズのシステム構成 会社紹介 アカウント管理が必要なSaaS、システムが84(テナント別) GWS, Slack, kintone, Notion GitHub RPA(Autoro), iPaaS(make) salesforce LANSCOPE バクラク申請、バクラク債権 akerun, RECEPTIONIST ジョブカン勤怠
5. corp-IT チーム
6. corp-ITチーム 業務内容 ネットワーク管理 デバイス管理 アカウント管理 申請や入退社に合わせてアカウント作成や削除 毎月アカウント棚卸→内部監査チームに提出 社内ヘルプデスク GAS, RPA, ノーコードツールを用いての自動化
7. 内製状況 GAS, RPA, ノーコードツールを用いての自動化 GASは34トリガー kintoneのアプリ数は143 各メンバーの半年の目標を書くアプリ 共有パスワード管理アプリ アカウント一覧アプリ RPA ワークフロー数45件 実行回数 300/月
8. 内製しようと 思ったきっかけ
9. 2024年春、一人情シスへ 相談できる人がいない。悩みながら、情シスとしての意見は主張しなけれ ばならない。 活動が理解されにくい。業務内容を可視化して成果をアピールしなければ ならない。 問い合わせが多い、また問い合わせの管理がslackで行っていたため網羅し て状況把握できない。 データ移動などの作業が多く、その作業で月初に忙殺される。 内製しようと思ったきっかけ
10. 内製しようと思ったきっかけ 問い合わせが表で管理されていない タスク漏れが発生している 眼の前の火消しで精一杯 守りの情シスが仕組み化 されていない 攻めの情シスがまっっったく できていない
11. 内製しようと思ったきっかけ 問い合わせが表で管理されていない タスク漏れが発生している 眼の前の火消しで精一杯 守りの情シスが仕組み化 されていない 攻めの情シスがまっっったく できていない 情シス業務をまず内製化しよう！ 時間がかかり、システム化できそうな ところをやってみよう！
12. 課題1 社内ヘルプデスクが多い 眼の前の火消しで精一杯 問い合わせが表で管理されていない タスク漏れが発生している
13. 社内ヘルプデスク業務はslackで問い合わせをもらい、slackでそのまま回答していた。 問題点は... 問い合わせのステータス管理ができていない。 返信が遅く、slackで催促を受けることもあった。 「牛丼屋さんの食券のように、何人待ちという状況がわかれば少しは改善するのでは？今slackでそ のまま管理しているが、Notionに自動転記できれば...」 課題1 社内ヘルプデスクが多い
14. 課題1 社内ヘルプデスクが多い Slackでリアクションを押す Notionにページ自動作成 このQRコードを読み取ると、ソースコード付の 技術ブログにアクセスできます！ ぜひ御社でも試してみてください！
15. 課題1 社内ヘルプデスクが多い やってみて 対応漏れが激減した。 対応件数や各問い合わせが一覧化されたことで、成果や初歩的な分析ができるようになった(年 間800件来ていることがここでわかった)。 問い合わせした方からの「この件どうなってますか？」が激減した。 問い合わせしたslackにはこの問い合わせ対応カンバンのリンクが自動返信されるようにもしてい る。→みんなヘルプデスク業務の現況を見てもらったんだと思っている。 余談：issueという名前にしたけど、本当は「issueの前の種」だと思っている。
16. 課題2. 異動や組織改編が多い 守りの情シスが仕組み化 されていない
17. 異動や組織改編があるたびにslackやkintone、バクラクの権限や部署を変更しないといけない。 問題点は... 組織改編が多い(毎月異動あり、半年ごとに大規模組織改編あり) 適切な権限やグループの認識が人によってまちまち(全社イベント参加のGoogleグループは正社員& 契約社員のみが所属する？) 「人事情報から様々なSaaSの権限やグループを自動変更できないか？ ワークフローシステムによっては固定チーム(経理マネージャーチームなど)を設定する必要があるが、それも人事 情報から編み出せないか？」 課題2. 異動や組織改編が多い
18. SmartHR SmartHRデータ 課題2. 異動や組織改編が多い kintone(API) バクラク(CSV) GWS(別途ツール使用) bundle bundleデータ
19. やったことログ kintoneは最初組織というグループとは別の項目で権限管理していたが、APIで変更できないとこ ろは管理スコープから外した。各アプリの権限を確認して、組織を排除するのが大変だった。 bundleからアカウント情報を引っ張ってきて各権限やグループをチェックさせている。過大な権限を 持っていたり、適切なグループに入っていない場合にアラートが飛んでくるようにした。 「◯◯データ」というシートに一旦データを同期させ、そこから色々する方針を固めた。API都度 実行していたら制限食らうやつもあるし。 課題2. 異動や組織改編が多い
20. やったことログ googleグループはこの対応前にGoogleグループを変更するツールが別にあったので 1.SmartHR、bundleの情報をもとにおかしな情報があればslackに通知 2.通知内容が妥当か確認して、手動でツール実行 を行っている 課題2. 異動や組織改編が多い
21. 課題2. 異動や組織改編が多い やってみて 部署と権限の表を運用し始めて、全員の中で「権限の物差し」を持つことができたと思ってい る。「この表の通りに運用しているが、表を修正したほうがいいか？」が言える。 大規模異動のときは本当に大変だったが、一括して変更することができ、正確に素早く対応 することができている。 ただし、ツールが実態に合わなくなることもあり(暫定対応で承認者権限を持つときなど)、柔軟に 人を追加する機能を別に追加した。
22. 課題3. 出社率をレポートする 守りの情シスが仕組み化 されていない
23. 出社率を分析する必要が発生したが、仕組み上算出が難しかった。 今までは... 既存の仕組みはakerun(ドア解錠SaaS→RPAでCSVダウンロード→CSVをkintoneに格 納。日付は文字情報で保存していた) また、度々RPAが失敗することがあり、その都度データ復旧が大変だった。 「APIのほうが正確だし、GASでできるならばRPAはコストがかかるだけだ！ akerun→GAS→GoogleSpreadsheetにできないか...？」 課題3. 出社率をレポートする
24. 課題3. 出社率をレポートする
25. 課題3. 出社率をレポートする akerun akerunデータ kintone kintoneデータ
26. やってみて kintoneからGoogleSpreadsheetになったのでデメリットはあったが、失敗時に日付指定して 再実行できるようにもしたのでメンテナンス工数が激減した。 akerunのAPIを触ったことで、その後の機能拡張で「バッテリーが20%以下になったakerunを 通知する」といったこともできるようになった。 RPAを使わなくなったので、たまに発生していたエラーに悩まされる必要がなくなった。 課題3. 出社率をレポートする
27. 課題4. アカウント利用申請が複雑 守りの情シスが仕組み化 されていない
28. 今までは... 複数アカウントを一気に申請できるようになっていたが、仕様が複雑化してkintoneの標準機能では 対応が大変になってきた。大規模組織改編があった際に利用申請の承認フローの変更依頼が来 ることが多く、設定変更が大変だった。 このアプリは情シス承認が入る このアプリは経理マネージャーが承認する 「暗号のようなものを持たせて（例：情経）、その文字が入っていたら承認しなければならないようにで きないか...」 課題4. アカウント利用申請が複雑
29. 課題4. アカウント利用申請が複雑 flowText += addFlowText(event, '本', [ '営業部' ,'財務部' ]); flowText += addFlowText(event, '支', [ '大阪事業部' ]); flowText += addFlowText(event, '外', [ 'アメリカ事業部' ]);
30. 課題4. アカウント利用申請が複雑 やってみて 結局仕様が複雑なままなので、あまり設定項目は減少していないが、以前のようなパズルゲームの ように頭を悩ませる状況は低減した。一定のルールに沿って承認者追加ができるようになった。 固定メッセージを元にしたワークフローは自分でもできるか半信半疑で、できるとわかったときはとても嬉し かった。
31. 繁忙時期(月末月初)以外はリソースを割けるようになってき た!! 「今まで決まった業務を改善してきたが、システムやツールを利用して、今まで できていなかったことをできるのでは...???」 守りの情シスを効率化してみて
32. チャレンジ1. お知らせでmarkdownを使う
33. 今までは... 社内のお知らせ配信の仕組みはあったが、kintone→slackでmarkdown記法が効いていな い状態だった。 「Notion使ってるし、ドキュメントはNotionに寄せたほうがいいでしょ！NotionにはAPIがあるから、そ こからslackに文章ありで通知されれば...」 ※Notionの中身もslackに送信する必要があったために、APIを用いています チャレンジ1. お知らせでmarkdownを使う
34. kintone before after GAS RPA slack Notion slack チャレンジ1. お知らせでmarkdownが使えない
35. やってみて Notionのブロックを解釈して、slackの装飾に落とし込む処理も作成してOSSとして公開し た。 Notion側に「この通知読んだよ」ボタンを用意したことで、その通知を非表示にすることができ るようになった。 お知らせというドキュメントも、ドキュメントサービスであるNotionに集約できることができたのでよかった チャレンジ1. お知らせでmarkdownが使えない
36. チャレンジ2. アカウント需要を予測したい
37. 今までは... 採用予定者の連携が都度来ている状態だったので、端末やアカウントをどれくらい予備で持ってお けばいいか分かりづらかった。 「採用チームから採用予定表のようなものを貰えれば、それとアカウント一覧やPC一覧と照合し て、“この月に不足しますよ表”が作成できないか...?」 チャレンジ2. アカウント需要を予測したい
38. kintone kintoneデータ Bundle Bundleデータ チャレンジ2. アカウント需要を予測したい
39. やってみて 採用予定表をつくる過程で、採用チームさん側も「きっちり権限や共有を絞った採用進捗 表」に苦労されており、その部分の課題もkintoneにすることで解決できた。 いずれこういった表を作成しておけば、GeminiのカスタムGemなどで情シス業務を助けてくれると信じ ている。というか助けてほしい。 チャレンジ2. アカウント需要を予測したい
40. チャレンジ3. kintoneからレポートをslackへ
41. 今までは... kintoneには入退社のタスクや契約アプリなどがあるが、その通知は活用できていなかった。 というより標準機能では通知できないものもあった。 入退社のタスクは最終出社日以降に通知されるようにしたい 切れそうな契約を通知したい 退職者がPCを持っているエラーデータとかを通知 チャレンジ3. kintoneからレポートをslackへ
42. kintone kintoneデータ Slack Slackデータ Slack チャレンジ3. kintoneからレポートをslackへ
43. やってみて kintoneは複数アプリが重なると効果が発揮しにくくなるが、プログラムでその欠点を補うことができ た。 このツールを発展させて、入社予定者のページをNotionに作成することもできた。 チャレンジ3. kintoneからレポートをslackへ
44. チャレンジ4. slackでアカウントとか チャンネルをチェックしたい
45. 今までは... slackに対してニッチな需要を自動化したい 社員の場合、命名規則に遵守しているかチェック チャンネルの場合、命名規則の遵守しているかチェック 社員がいるべきチャンネルに全員入っているかチェック 社内クラブチャンネルをランダムに5つピックアップして、雑談チャンネルに自動投稿 チャレンジ4. slackでアカウントとかチャンネルをチェックしたい
46. slackデータ slack slack チャレンジ4. slackでアカウントとかチャンネルをチェックしたい
47. やってみて チェックが自動化されたが、slackのid、名前表を手に入れたことも大きい メール通知ではなくて、idによってメンションを当てることも可能になった チャレンジ4. slackでアカウントとかチャンネルをチェックしたい
48. 結果としてできたシステム群 - ◦◦データというspreadsheetが、それぞれ連結しながら自動化するように - kintoneデータ - akerunデータ - slackデータ - bundleデータ SaaSとともに成長して、補佐するシステム群ができた。
49. 結果としてできたシステム群 - ◦◦データというspreadsheetが、それぞれ連結しながら自動化するように - kintoneデータ - akerunデータ - slackデータ - bundleデータ SaaSとともに成長して、補佐するシステム群ができた。 自動化も進んで、 なんとか乗り切った〜!!!
50. 今後のcorp-ITの 方向性
51. 新会社設立、M&A... システム統合やグループにとって最適なシステム計画が大変 多拠点になったのでPC管理の委託を検討 理想でいえば、権限設定を全SaaSに広げていきたい！そうすればまるで会社がOSのように機能 するはず Googleグループへの追加申請などが残存しているため、適切なグループに自動変更ができるよ うになれば申請件数も減ると考えている。 今後のcorp-ITの方向性
52. 備考 zennとか書いてみて
53. zennとか書いてみて 最初はツールのソースコードの公開を目的にzennやqiitaを書き始めた。同じように困っているコーポレートエ ンジニアがいたら流用できるように。 →段々とコーポレートエンジニアとしてやったこととかを書くように。意見とかも載せるようにした。 →生成AIに読み込ませて、生成AIのパーソナライズをはじめた。 →取ったおいたほうがいい資格など、キャリアアドバイスも生成AIがするようになった。 ぜひ皆さんも技術ブログに実績、意見、やったことを書いてみてね！！
54. 伝えたいポイント 今時間がかかっていることを自動化してみた→攻めの情シスができるようになった！ APIがある製品はご紹介したように、プログラムと組み合わせができる！ 　　その可能性は無限大！ その組み合わせからぜひ社外発信を！withAIの時代で無形資産になるはず
55. Thank you zenn linkedin