情シスの仕事を減らすには、負担が気になる業務を工程に分け、必要性、進め方、処理方法、実行主体の順で見直します。
受付、実行、判断、記録へ分ける
廃止、標準化、自動化、外注の順で確認する
判断根拠、次の行動、見直し期限を記録する
最初から情シス業務のすべてを洗い出す必要はありません。問い合わせ対応や月次報告など、負担が気になる業務から始めます。
|
仕事が減らない状態 |
見落としていること |
確認する内容 |
|
終了条件がない |
不要になった業務が継続している |
目的、利用者、停止時の影響、終了を承認する担当者 |
|
例外対応が戻ってくる |
通常処理だけを自動化または外注している |
社内へ戻す条件、判断者、承認が必要な操作 |
|
旧運用が残っている |
新しい仕組みと手作業が併存している |
旧運用の終了条件、正式な受付窓口、正式な記録 |
情シス業務を減らすには、「ヘルプデスク」「サーバー運用」のような大分類ではなく、実際の工程まで分けて確認します。
開始条件
受付・入力
実行
判断・承認
例外対応
記録・報告
完了条件
担当者や改善方法が途中で変わる場合は、工程を分けて記録します。
例えば問い合わせ対応なら、受付、内容確認、定型回答、例外判断、完了記録に分けられます。受付方法を標準化し、定型回答を自動化し、例外判断を社内に残すといった切り分けが可能になります。
|
確認項目 |
記録する内容 |
|
必要性 |
目的、利用者、成果物 |
|
発生状況 |
開始条件、頻度、依頼元 |
|
実行体制 |
主担当、副担当、使用システム |
|
判断 |
判断が必要な工程、承認者 |
|
例外・リスク |
例外、停止時の影響、継続義務 |
|
改善 |
仮分類、判断根拠、確認先、次の行動 |
「誰が作業するか」と「誰が判断するか」は、分けて記録します。情報収集、入力、監視、一次切り分けなどの作業を自動化または外注しても、業務停止や変更を判断する役割は社内に残る場合があります。
障害時や夜間・休日だけ発生する作業
他部門やベンダーとの連絡・調整
証跡、報告書、台帳の作成・更新
特定担当者だけが行っている確認や代理対応
通常手順から外れる作業を含めると、標準化できる範囲と、社内に残すべき判断が見えやすくなります。
サーバー運用の手順や判断が特定の担当者に集中している場合は、サーバー運用は引き継げる状態かで、担当者が代わっても運用を続けられるかを確認してください。
棚卸しした業務は、業務の必要性から確認し、進め方、処理方法、実行主体の順で見直します。
業務の目的と利用者を確かめる
停止、縮小、統合、移管の可否を検討する
通常処理と例外対応を分ける
定型部分を自動化できるか見極める
外部へ任せられる作業を切り出す
社内に残す判断と承認を定める
|
4分類は排他的な選択肢ではありません 廃止は業務の必要性、標準化は進め方、自動化は処理方法、外注は実行主体を見直す観点です。一つの業務に、複数の方法を組み合わせることもできます。 |
受付を標準化し、定型処理を自動化し、一次対応を外注する一方で、例外時の判断と承認を社内に残す方法もあります。
4分類は業界共通の基準ではありません。自社の体制、契約、法令・規制、監査、社内規程、セキュリティー要件に合わせて使ってください。
|
分類 |
見直す対象 |
判断する問い |
主な次の行動 |
注意点 |
|
廃止 |
業務の必要性 |
目的、利用者、継続義務、停止時の影響を説明できるか |
停止、縮小、統合、簡素化、他部門への移管 |
利用頻度だけで決めない |
|
標準化 |
業務の進め方 |
担当者によって受付、手順、判断、結果が変わっていないか |
入力、手順、承認、記録、完了条件をそろえる |
手順書の作成だけで終わらせない |
|
自動化 |
処理方法 |
開始条件、処理、例外、失敗時の対応を明文化できるか |
定型部分を切り出し、検証範囲を定める |
現在の業務をそのまま自動化しない |
|
外注 |
実行主体 |
作業範囲、権限、品質、責任分界を定義できるか |
委託範囲、記録、連絡、承認方法を整理する |
判断や統制は社内に残る場合がある |
実施頻度を下げる
対象を限定する
重複業務と統合する
成果物を簡素化する
依頼元や適切な社内部門へ移管する
業務は必要でも、情シスが担当する必要がない場合があります。その場合は、依頼元や所管部門への移管も選択肢です。
ただし、「情シスの仕事ではない」という理由だけで一方的に戻すと、対応漏れや責任の空白が生じます。移管前に、所管、判断責任、引き継ぐ情報、開始時期、受付窓口を合意しておきます。
自動化に向いているのは、開始条件、入力、処理、完了条件を明文化できる工程です。
一方、業務影響の確認、責任者の承認、権限や機密情報に関わる判断は、人が担う工程として残すことがあります。すべてを自動化する必要はありません。情報収集や入力を自動化し、実行判断は人が行う方法もあります。
外部へ任せられるのは、範囲と手順を示せる作業です。業務影響の判断、実行承認、優先順位付けなどは、社内に残る場合があります。
監視や一次確認を外注しても、対応を実行してよい条件が不明確なら、委託先から社内への確認は減りません。外部だけで進められる作業と、社内承認が必要な作業を分けることが先です。
社内に残す仕事と外部へ任せる仕事の詳細は、中堅企業の情シス不足をどう補うかで解説しています。
4分類を日常業務へ当てはめる場合も、業務全体ではなく、受付、定型処理、例外判断、承認、記録に分けて考えます。
|
対象 |
廃止・縮小・移管 |
標準化 |
自動化 |
外注 |
|
問い合わせ |
重複依頼や不要な個別対応を減らす |
受付窓口、必要項目、回答根拠をそろえる |
定型案内、受付処理 |
一次受付、定型回答 |
|
障害・アラート |
不要・重複通知を見直す |
通知基準、一次確認、記録をそろえる |
情報収集、定型判定 |
監視、一次対応 |
|
パッチ対応 |
対象外機器や重複管理を整理する |
対象、承認、例外、記録をそろえる |
条件が明確な適用処理 |
情報収集、定型運用 |
|
ログ・定期報告 |
目的や要件を確認し、重複した収集・集計・報告を見直す |
形式、保存場所、更新手順をそろえる |
収集、集計、通知 |
継続的な定型運用 |
※この表は仮分類の例であり、すべての組織に一律に適用できる基準ではありません。
問い合わせ対応では、受付経路がメール、チャット、口頭、電話などに分散していないかを確かめます。窓口が複数ある場合は、正式な受付方法をそろえることから始めます。
定型的な案内や受付は、自動化や外注の候補です。一方、権限変更、例外申請、セキュリティーに関わる内容は、社内判断へ戻す条件を定めておきます。
障害・アラート対応は、「通知」「一次確認」「社内判断」の3工程に分けます。アラート件数を減らすだけでなく、何を検知する通知なのか、誰が一次確認するのか、どの条件で社内へ連絡するのかを整理します。
詳しい進め方は、夜間休日のアラート対応を減らすには?をご覧ください。
パッチ対応は、情報収集、適用作業、承認を分けて考えます。情報収集や定型的な適用処理を自動化しても、業務影響の確認、適用承認、業務部門との調整は残る場合があります。
詳しくは、脆弱性対応を自動化する前に情シスが整理すべきことで解説しています。
ログと定期報告は、同じ基準で廃止しないようにします。
ログは、監査、セキュリティー監視、障害調査などに必要な場合があります。定期報告は、報告先が現在も使っているか、同じ情報を別の方法で確認できないかを調べます。見直すのはログそのものではなく、目的が重複した収集、集計、転記、報告です。
分類後は、新しい仕組みを加えたことで、別の作業が増えていないかを確認します。
自動化後も同じ帳票を手作業で作成しているなら、旧運用の終了条件を見直します。自動処理と手作業のどちらを正式な記録とするかを定め、不要になった確認や転記を終了します。
担当者ごとに手順や入力形式が異なると、自動処理から外れる依頼が増えます。処理後に人が全件を再確認する状態では、負担軽減につながりません。
開始条件、入力項目、承認、例外、失敗時の戻し先をそろえます。判断基準を固定できない部分は、無理に自動化せず、人が確認する工程として残します。
承認者、障害時の優先順位、例外時の連絡先が未定なら、判断は社内の特定担当者へ戻ります。外部へ任せる作業と社内に残す判断を分け、委託先から社内へ連絡する条件を明文化します。対応結果を誰が確認するかも、責任分界に含めます。
「廃止」「自動化」と記載するだけでは、関係者へ判断理由を説明できません。前提が変わったときの再検討も難しくなります。
棚卸し表には、基本情報と改善判断を分けて記録します。次の記入内容は粒度を示す例であり、実際の顧客事例ではありません。
|
業務名 |
目的・利用者 |
頻度 |
判断・承認 |
例外 |
停止時の影響 |
|
月次利用状況報告 |
部門責任者が契約数を確認する |
月1回 |
情シス責任者が内容を確認する |
部門別集計の追加依頼 |
契約更新の判断が遅れる |
|
仮分類 |
判断根拠 |
確認先 |
次の行動 |
見直し期限 |
|
標準化・自動化 |
集計方法が担当者ごとに異なり、同じデータを転記している |
報告先の部門責任者 |
必要項目を確認し、集計方法をそろえる |
次回の契約更新前 |
必要に応じて、普段使用している業務管理表へ同じ項目を追加してください。
業務の発生頻度や所要時間だけで、着手順を決める必要はありません。次の4点も確認します。
割り込みの多さ
担当者への依存
例外と判断の多さ
停止時の業務・セキュリティー影響
短時間で終わる作業でも、割り込みが多ければ、まとまった業務時間を取りにくくなります。反対に、工数が大きくても、停止時の影響や例外判断が多い業務は、すぐに自動化や外注へ進めないことがあります。
固定の点数だけで機械的に決めず、自社の業務影響と、改善後に残る判断を基に着手順を定めます。
今回は継続と判断した業務も、永久に続けるとは限りません。利用者、組織体制、システム構成、契約条件が変われば、分類を見直します。
「廃止できないため継続」とした業務も、判断根拠が現在も有効か再確認できるよう、見直し期限を記録します。
□ 目的と利用者を説明できる
□ 停止時の影響を確認した
□ 通常処理と例外を分けた
□ 判断者と承認者を記録した
□ 次の行動と見直し期限を設定した
情シスの仕事を減らすには、自動化や外注を検討する前に、その業務を続ける必要があるかを確認します。
業務を工程に分け、担当者による違いを標準化したうえで、定型部分の自動化や外注を検討してください。
一つの業務を、廃止、標準化、自動化、外注のいずれか一つだけに分類する必要はありません。必要でも情シスが担う必要のない業務は、責任分界を確認したうえで、適切な社内部門への移管も検討します。
最後に、判断根拠、確認先、次の行動、見直し期限を記録します。分類して終わらせず、次に何を確認し、いつ再判断するかまで決めることが、業務改善につなげるポイントです。
業務を棚卸しした結果、構成管理、定型作業、ログ採取、一次切り分け、監視対応などに負担が集中している場合は、外部支援も選択肢になります。
横河レンタ・リースでは、現在の運用状況や作業手順を伺い、Yellow Dash Supportで対応可能な範囲をご案内します。
社内に残す判断や承認が整理できていない場合も、現在分かっている範囲からご相談ください。