情シスの仕事をAIで軽くする6工程｜まず何から外すか

日本情報システム・ユーザー協会が2026年4月に公表した「企業IT動向調査 報告書 2026」では、IT予算の配分が現行ビジネスの維持・運営に75.9、新しい施策の展開に24.1という結果になりました。新しいほうの比率は2021年度から24%前後で推移していて、大きな変動はありません。同じ調査で3年後の目標として挙がった比率は32.7%ですが、3年前にあたる2022年度の調査でも、3年後の目標は33.0%でした。目標だけが毎回同じ場所に立ち、実際の配分は4年間ほとんど動いていないということです。情報システム部門からは、この声が絶えません。「新しいことをやれと言われるが、いまの運用を止められない」「人は増えないのに、守るシステムと台数だけが増えていく」。——2つとも、余力が足りないという話に見えて、実際には手放す対象を誰も決めていないという話です。余力は、頑張った先に自然と生まれるものではありません。本当は、恒常業務のどれを外すかを工程の単位で決めない限り、比率はいつまでも動きません。この記事では、情シスの恒常業務を6つの工程に並べ直し、どこからAIに外すかを順番で決める方法を整理します。

情シスの予算は、4分の3が現状維持に消えている

冒頭の数字をもう少し細かく見ます。同じ調査では、IT予算が増加したと答えた企業が52.6%ありました。増加の理由の1位は「既存システム・基盤の刷新・更新・増強」で66.3%です。2位が円安や人件費の高騰、ベンダーの提供価格の値上げなどによる影響で46.6%、3位がクラウドサービスの増加で45.0%。増えた予算の使い道の上位は、新しいことではなく、いま動いているものを保つための費目です。AI関連の投資や利用料の増加は36.3%で、2026年度の予測では43.7%まで上がりますが、それでも刷新・更新・増強には届きません。

配分の比率はもっと動きません。維持・運営と新しい施策の比率は75.9対24.1。新しい施策の側は2021年度から24%前後で、4年間ほぼ同じ位置にあります。注目したいのは、この調査が3年後の目標も同時に聞いていることです。2025年度調査では32.7%、2022年度調査では33.0%。3年前に立てた3年後の目標は、達成されないまま、同じ数字でもう一度立て直されています。目標を掲げるという行為だけでは、比率は動かないことがはっきりと出ています。

予算の比率は、そのまま情シスの時間の比率に近い形をしています。守る対象が増えれば、守る作業も増えます。台数が増え、契約するサービスが増え、つなぐ先が増えるたびに、確認と申請と棚卸しの件数が増えていく。ところが手放す作業のほうは、誰の担当表にも載っていません。足す作業には期日と担当が付き、外す作業には付かない。この非対称が、比率が動かない一番の理由です。だから最初にやることは、外す対象を担当と期日のある仕事として置き直すことになります。

情シスとAIの関わり方が、いま「配る側」に寄っている

同じ調査は、生成AIの活用促進に向けたIT部門の役割も聞いています。「生成AI活用のための社内ルールを整備」について、IT部門が主体的に取り組んで成果が出ていると答えた企業は16.1%。成果は検証中という回答を合わせると42.2%になります。次いで「AI活用に対する企画・戦略の立案」が36.1%、「社内に専用の生成AI活用のための基盤整備」が34.9%。支援組織や専門組織の設置まで進んでいる企業の割合は低く、成果が出ているという回答はそれぞれ5.6%と3.1%にとどまります。

ここで見ておきたいのは、数字の高さより設問の並びです。挙がっている7項目は、ルールの整備、企画と戦略、基盤の整備、活用方法の発信、研修の展開、支援組織、専門組織。すべて、他の部門に使わせるための仕事です。情シス自身の恒常業務をAIで軽くする、という項目は設問に立っていません。調査の設計がそうなっているということは、実務でもそこが主な関心になっていないということです。情シスはAIを配る側として関わっていて、使う側としてはまだ数えられていません。

配る側に回ること自体は無駄ではありません。同じ調査は、IT部門が主体的に取り組んでいる企業のほうが、言語系の生成AIの導入効果で何らかの効果があったと答える割合が高いことを示しています。逆に、IT部門以外が対応している企業では、その差が見られないとも書かれています。つまり関与には意味がある。問題は、配る仕事が増えたぶん恒常業務が減ってはいないことです。参考までに、言語系の生成AIを導入済みまたは試験導入中と答えた企業は53.4%で前年度から12.3ポイント伸び、AIエージェントは21.0%でした。社内に配るものは着実に増えています。

• ここで扱うのは情シス自身の恒常業務です。社員からの問い合わせを一次で受ける仕組みは別記事の範囲なので、この記事では工程の一覧にも入れていません
• 調査は2025年9月6日から10月22日に実施され、東証上場企業とそれに準じる4,500社を対象に957社から有効回答を得たものです

恒常業務を6つの工程に分けて並べる

外す対象を決めるには、まず並べる必要があります。並べ方には注意点が1つあって、部署やシステムで区切ってはいけません。区切るのは、1件の依頼が発生してから終わるまでの流れ、つまり工程です。同じ「アカウント」という言葉でも、発行するときと止めるときでは、必要な判断も、間違えたときの影響も、まったく違います。ここを一括りにすると、外せる部分まで一緒に人の手元に残ります。

工程	1件の中身	起きる頻度	重さの正体
1 資産と台帳を合わせる	実物と記録の差分を出し、1行ずつ理由を書く	年に1回から数回、まとめて発生	差分を見つけることではなく、理由を書き分けること
2 アカウントを発行する	申請の文面から必要な範囲を読み取り、付ける	入社と異動のたび、月に数件から数十件	文面の書き方が部署ごとに違い、不足の確認に往復が出る
3 アカウントを棚卸しして止める	使われていない権限を洗い、確認して止める	四半期または半年ごとに一斉	確認を頼んだ相手が全部そのまま承認して返してくる
4 端末を初期設定して渡す	構成をそろえ、渡し、記録に残す	採用と更改の波に合わせて集中	設定そのものより、前回との違いの把握
5 申請を受け付けて捌く	内容を読み、種別を決め、不足を戻す	毎日、複数の経路から	同じ依頼が経路違いで重複し、緊急度の判断が属人化する
6 障害を一次で切り分ける	症状を確認手順の言葉に直し、範囲を絞る	不定期、ただし止まると全部が止まる	症状の言葉と原因の言葉が対応しておらず、確認が遠回りになる

この6つは、どれも「なくすことはできないが、毎回同じ形で繰り返している」仕事です。だから外す対象になります。逆に、新しいシステムの要件を決める、契約の条件を交渉する、事故のあとに再発の防止策を組み直すといった仕事は、繰り返しではないので外す対象には入れません。外すのは、繰り返している仕事の中の、材料をそろえる部分だけです。

並べたら、工程ごとに1件あたりの所要時間と月あたりの件数を書き添えます。数字は正確でなくても構いません。5分か30分か半日か、月に5件か50件か500件か、その程度の粒度で十分です。この2つを掛けると、外したときに戻ってくる時間の見当が付きます。見当が付かない工程は、外す判断も付きません。時間を測っていない工程が3つ以上ある場合は、外す前に1か月だけ記録を取るところから始めたほうが早く進みます。

外す順番は、繰り返しと判断と戻せるかで決まる

6つ並べたら、次は順番です。順番を決める軸は3つあります。1つ目は同じ形で繰り返しているか。文面や様式が毎回違う仕事は、外しても指示の作り込みに時間を取られます。2つ目は判断が要るか。材料をそろえるだけの部分と、決める部分を切り分け、そろえる部分から外します。3つ目は間違えたときに元へ戻せるか。ここが実務では一番効きます。

3つ目の軸は、感覚ではなく仕様で決まっています。たとえば利用者のアカウントを消す操作は、公開されている仕様では削除後30日間は中断状態として保たれ、その間なら属性ごと復元できます。一方、完全な削除を選ぶと、提供元の窓口を含めて誰も復元できないと明記されています。戻せる操作と戻せない操作が、同じ画面のすぐ隣に並んでいます。この線が引けていれば、どこまでを機械の側に置き、どこから人が手を下すかは自動的に決まります。

この3軸を当てると、外す順番はおおむね次の形になります。先頭は資産と台帳の突合と、申請の受け付け。どちらも繰り返しが多く、判断は後ろに寄せられ、間違えても書き直せば済みます。次が障害の一次切り分けと端末の記録。最後に来るのがアカウントの発行と棚卸しです。ここは繰り返しが多いにもかかわらず、止める操作が戻しにくいために最後になります。つらい仕事から外そうとすると、たいていこの順番と逆になります。棚卸しが一番つらいからといって最初に手を付けると、確認の往復が増えて前より重くなります。

工程1：資産と台帳を合わせる——差分の理由を書く作業から外す

台帳は、書き込んだ瞬間から古くなります。年に1回の棚卸しをすると、実物と記録の差分が数百行単位で出るのが普通です。ここで重いのは差分を見つける作業ではありません。それは表計算でも管理ツールでもできます。重いのは、1行ずつに「なぜ違うのか」を書き分ける作業です。持ち出し中なのか、返却されたのに登録が漏れているのか、機種名の書き方が違うだけなのか。この分類が終わるまで、差分は差分のまま残ります。

外せるのは、この分類の下書きです。差分の行をまとめて渡し、理由の型ごとに束ねさせます。特に効くのが表記の揺れの寄せ集めで、同じ機種が3通りの書き方で登録されている、購入年度の欄が和暦と西暦で混ざっている、といった行はまとめて片付きます。あわせて、束ねた根拠を1行で書かせておくと、人が見返すときに読む時間が減ります。ここまでを下書きとして受け取り、確定は人が行います。

落とし穴は、所在の分からない端末が「返却済み」の束に寄ってしまうことです。分類の候補には必ず「不明」を残し、不明のまま残った行数を毎回記録します。不明が減ったことを成果にすると、不明が消えるように分類が寄ります。測るのは不明の件数ではなく、不明の行がその後どうなったかです。翌月までに実物が見つかったのか、廃棄の記録が出てきたのか、何も分からないままなのか。この3つに分けて追うと、台帳の精度が本当に上がっているかが見えます。

工程2：アカウントを発行する——申請の読み取りと不足の指摘まで

入社と異動のたびに、どこまでの権限を付けるかを申請の文面から読み取ります。文面の書き方は部署ごとにばらばらで、実務でもっとも多いのは「前任者と同じでお願いします」の1行です。この1行を受け取った側は、前任者の権限を調べ、今回の職務で本当に要るのかを考え、足りない情報を聞き返すことになります。1件あたりの作業時間の大半は、付ける操作ではなく、この往復に消えています。

外せるのは3つです。1つ目は、申請の文面から必要な範囲を項目に起こす下書き。2つ目は、不足している情報の指摘で、開始日、所属、承認する上長、期限付きかどうかの4点が揃っているかを見ます。3つ目は、差し戻しの文面の下書きです。差し戻しは書くのが億劫で後回しになりやすく、後回しになった分だけ開始日に間に合わなくなるので、下書きがあるだけで効きます。

落とし穴は「前任者と同じ」をそのまま写すことです。これを機械的に繰り返すと、権限は代替わりのたびに増えていきます。頼み方を分けると防げます。前任者が持っている権限の一覧を出させるところまでを1つ目の依頼にし、そのうち今回の職務で使う見込みが立たないものを別に並べさせるところを2つ目の依頼にする。消す判断は人が行いますが、消す候補を並べる作業は外せます。なお、認証の入口をどう束ねるかという設計そのものは別の話なので、ここでは触れません。

工程3：アカウントを棚卸しして止める——外すのは依頼と抽出だけ

退職や異動の後に残った権限を洗い出し、要るか要らないかを確かめて止める。これが棚卸しです。周期を決めて回している組織は多いのですが、うまくいかない原因はほぼ1つに集約されます。確認を頼まれた側が、中身を見ずに全部そのまま承認して返してくることです。これが起きると、棚卸しは回っているのに権限は減りません。過剰な権限は監査での指摘につながる、と公開されている資料にも明記されています。

周期と頼み先には選択肢があります。公開されている仕様では、確認の周期は毎週、毎月、四半期ごと、毎年から選べ、頼む相手は指定した担当者、置き場所の所有者、本人、上長のいずれかを指定できます。ここで押さえておきたいのが社外の利用者の扱いで、同じ資料は、社員のアクセスは人事の名簿を元にした自動化に載せられるが、招待した社外の利用者は載せられないと書いています。社外の分は、置き場所の持ち主が必要性を確かめる責任を負う、と明記されています。

外せるのは、確認の依頼文の下書きと、返ってきた回答の絞り込みです。承認の理由が書かれていない行、前回と同じ理由が一字一句そのまま書かれている行、90日以上使われていない権限が承認されている行。この3つを抜き出して人に渡すだけで、読む対象が数分の1になります。止める操作そのものは外しません。理由は次の章で扱う復元の仕様にあります。

工程4：端末を初期設定して渡す——手順書の版の差分と受け入れの記録

台数が増えるほど重くなるのは、設定の作業そのものではありません。今回の構成が前回とどこで違うのかを把握する作業です。半年前の手順書を開いて、間に入った変更を思い出しながら読み直す。この読み直しに時間がかかり、しかも思い出し漏れが後の不具合になります。なお、配布前に決めておく設定項目そのものは別記事の範囲なので、ここでは扱いません。

外せるのは、手順書の版どうしの差分を文章にする作業と、受け入れ確認の項目表の下書き、それに返ってきた端末の状態記録の要約です。差分は箇条書きにさせ、変わった箇所ごとに「この変更で影響を受けるのは誰か」を1行添えさせると、そのまま作業前の読み合わせに使えます。受け入れ確認の項目表は、前回の項目表と今回の手順書の差分から作らせると、抜けが減ります。

落とし穴は、手順書そのものを書き直させることです。読みやすく整えてほしいと頼むと、現場が後から書き足した注記が消えます。「この機種だけ順番が逆」「この設定は再起動を2回」といった一文は、たいてい事故のあとに足されたもので、文章としては座りが悪い。整えるという頼み方は、事故の記録を消す頼み方になりがちです。差分を出させるのはよいが、書き直しはさせない。この線は工程4では特にはっきりさせておきます。

工程5：申請を受け付けて捌く——分類と重複の検出と、記入漏れの指摘

申請は、様式が決まっているようで決まっていません。専用の窓口があっても、実際にはメールでも、チャットでも、廊下でも来ます。同じ内容が3つの経路から別々に届くこともあります。1件あたりの処理は短いのに、日々の総量として重いのはこのためです。受け付けの重さは、1件の難しさではなく、経路の多さと重複から来ています。

外せるのは3つです。1つ目は、本文から種別の候補を付けること。2つ目は、記入漏れの指摘。3つ目が、同じ依頼の重複検出で、これは効果がはっきり出ます。届いた本文どうしを突き合わせ、同じ人からの、同じ対象への、直近の依頼を並べさせる。経路の違う重複はここでほぼ拾えます。拾ったあとの束ね方は人が決めますが、拾う作業を人がやる必要はありません。

落とし穴は、緊急度をAIに決めさせることです。文面の丁寧さと緊急度には関係がありません。「お手すきのときで構いませんので」と書かれた依頼が、実は決算処理を止めていることがあります。逆に、感情の強い言葉で書かれた依頼が翌週でも間に合うこともある。緊急度は申請者の言葉づかいではなく、業務が止まるかどうかで人が付けます。機械に付けさせるのは種別までにして、緊急度の欄は空欄で渡す。この形にしておくと、後から順番の付け方を見直すときにも記録が使えます。

工程6：障害を一次で切り分ける——候補を並べるところまで

一次切り分けが遠回りになるのは、症状を伝える言葉と、原因を確かめる言葉が対応していないからです。「重い」「つながらない」「昨日までできていた」。この3語からは、どこを見ればよいかが決まりません。担当者は経験でいくつかの候補に当たりを付け、順に潰していきます。経験のある人とない人で所要時間が何倍も変わるのは、この当たり付けの部分です。

外せるのは、症状の言葉を確認手順の言葉に言い換えることと、過去の対応記録から似た事象を並べること、それに確認済みと未確認を整理することです。障害が収束したあとの報告の下書きも外せます。ここで頼み方が肝心で、原因を1つ挙げさせるのではなく、候補と、その候補を確かめるための手順を対にして並べさせます。並べる根拠として過去の記録の番号を書かせ、番号が書けないものは候補から外す。この一手間で、それらしいだけの候補がかなり減ります。

落とし穴は、収束を急ぐ場面ほど断定を求めてしまうことです。原因を聞かれた機械は、必ず何かを答えます。答えの形が整っているほど、確かめずに次の行動に移りたくなる。だから頼み方の側で防ぎます。原因の欄を作らず、候補の欄と確認手順の欄だけを用意する。欄がなければ、断定は出てきません。影響範囲の周知文についても、確定した事実と、確認中の事項を別の段落に分けて書かせると、後から訂正する範囲が小さく済みます。

自動化には「いつ動くか」の仕様がある

外した仕事を仕組みに載せるとき、多くの人が見落とすのが実行の時刻です。自動化は「即座に」ではありません。公開されている仕様では、予定実行の仕組みは設定した間隔で評価され、その既定値は3時間と明記されています。つまり条件が整ってから実際に処理されるまでに、最大でその間隔ぶんの待ち時間が挟まります。入社日の朝に権限が付いていない、という事故の一部はここから来ます。

追いつきの動作もあります。同じ資料は、人事側の登録が遅れて意図した処理時刻を過ぎた場合でも、元の処理時刻から3日以内に必要な設定が済んでいれば処理を試みる、と書いています。逆に言えば3日を過ぎた分は自動では拾われません。実行の条件になる項目も4種類あり、属性の変更、所属する集まりの変更、時刻を基準にしたもの、一定期間の未使用のいずれかを選ぶ形になっています。手作業で今すぐ動かす方法もありますが、その場合は実行の条件を満たしているかどうかが考慮されない、という注意書きも付いています。

だから外す設計には、工程ごとの締切を必ず書き添えます。入社の何日前までに人事側の登録を締め切るのか、異動の情報はいつまでに届く必要があるのか。ここを決めずに前日の申請を受け付けていると、仕組みを入れても初日に使えない端末とアカウントが出続けます。自動化で減るのは作業の手数であって、必要な前倒しの日数ではありません。むしろ締切は、手作業のときより厳しくなることのほうが多いと考えておきます。

AIに実行させない範囲を、工程ごとに先に引く

線を引く基準は、繰り返しになりますが「元へ戻せるか」です。ここは仕様として公開されています。利用者のアカウントを削除すると、そのアカウントは30日間は中断された状態で保たれ、その期間中ならすべての属性を含めて復元できます。30日が過ぎると完全な削除の処理が自動的に始まり、止めることはできません。完全な削除を選んだ場合は、提供元の窓口を含めて誰も復元できないと書かれています。

さらに面倒なのは、逆向きの事故もあることです。社内の名簿から同期している利用者の場合、同期元に情報が残っていれば、次の同期の周期で戻ってくる可能性がある、と同じ資料が説明しています。つまり消したのに戻る状態と戻したくても戻らない状態が同居しています。もう1つ、復元すると割り当てられていた席も一緒に戻るため、購入した数を超えると契約上の不整合が一時的に生じる可能性がある、という注意も明記されています。

この3つを知ったうえで線を引けば、工程ごとの分担は自然に決まります。台帳の分類、申請の下書き、確認依頼の文面、障害の候補出しまでは外す。付ける、止める、消すという状態を変える操作は人が実行する。そして、実行した人と時刻を記録に残します。監査や上長から「なぜこの権限を残したのか」と聞かれたとき、機械が判断したから、では通りません。答えられる形にしておくところまでが設計です。

外したぶん、点検と説明の仕事が増える

外すと仕事が減る、とだけ考えていると計画を外します。実際には、外したぶんだけ3種類の仕事が増えます。1つ目が出力の点検。2つ目が記録の保管。3つ目が他部門への説明です。3つとも、外す前には存在しなかった仕事です。この増分を見積もりに入れずに始めると、3か月目に「前より忙しい」という感想だけが残ります。

点検は割合で決めないでください。全体の何%を見る、という決め方をすると、件数が増えた月に読み切れなくなります。順序は逆です。読める人数と時間から1週間あたりの上限件数を出し、その枠を優先順に埋めます。優先するのは、分類が「不明」になった件、前回と結論が変わった件、根拠の記録番号が書かれていない件の3つ。この3つで枠が埋まったら、無作為の抜き取りはその月は行いません。

説明の仕事は、担当表に載せておかないと消えます。他部門から見ると、情シスの手順が変わったことは分かりません。分かるのは、返事の文面が変わったこと、差し戻しが増えたこと、確認の依頼が定期的に届くようになったことだけです。先に説明していないと、この変化は品質が落ちた合図として受け取られます。工程を外す前に、変わる点と変わらない点を1枚にまとめて配っておくと、後の問い合わせがはっきり減ります。

最初の90日で、どこまで外すか

6工程を一度に外そうとすると、まず立ち上がりません。最初の3か月でやることは、2つの工程を外し、増える3種類の仕事の量を実測することだけです。広げるのは、この2つが安定してからです。以下は、最初の90日の並べ方です。日数は目安なので、件数の多い組織では後ろの工程を1週ずつ後ろにずらして構いません。

この並べ方で外せる工程は、90日で2つ、1年で5つか6つが現実的な速さです。速く見えないかもしれませんが、途中で止まった仕組みを作り直す時間を考えると、結果的にはこちらが早く着きます。止まる原因のほとんどは、点検の枠を決めないまま外す工程だけを増やしたことです。

情シスの仕事を外すときにやりがちな失敗

最後に、始めた時点では正しく見えるのに、決まった形で止まる進め方を並べます。どれも実際によく見かけるもので、共通しているのは外す判断を、工程ではなく気持ちの重さで決めていることです。自分の計画がどれかに当てはまっていないか、動かす前に照らし合わせてください。

• 一番つらい棚卸しから外そうとする——止める操作が戻しにくいため確認の往復が増え、外す前より重くなる
• 6工程を同時に外そうとする——頼み方の作り込みが並行し、どれも中途半端な下書きしか出てこない
• 外す前の所要時間を測っていない——効果を聞かれたときに、体感でしか答えられず、次の予算が付かない
• 手順書をきれいに書き直させる——事故のあとに現場が足した注記が消え、同じ事故が半年後に再発する
• 緊急度の判定まで任せる——丁寧な文面の依頼が後回しになり、止まっている業務が最後に回る
• 点検する割合を先に決める——件数の多い月に読み切れず、点検していない下書きがそのまま流れる
• 他部門に説明せずに切り替える——返事の文面と差し戻しの変化だけが伝わり、品質が落ちたと受け取られる
• 外した工程の担当を、そのまま同じ人が点検する——頼み方の弱点が最後まで見つからない

並べたうちの3つ目と6つ目は、特に後から効いてきます。測っていないと、続ける理由も、やめる理由も示せません。点検の割合を先に決めると、忙しい月ほど点検が飛びます。外す仕組みは、余裕のある月ではなく、忙しい月にどう振る舞うかで評価してください。忙しい月に最初に落ちるものが、その仕組みの本当の弱点です。

よくある質問

担当が1人しかいない情シスでも、外すところから始められますか

むしろ1人のときのほうが効きます。ただし順番は変わります。人数がいる組織では資産と台帳から始めますが、1人の場合は申請の受け付けから始めるほうが早く楽になります。理由は、台帳の突合が年に数回なのに対し、申請は毎日届くからです。毎日届くものから外したほうが、外した実感が早く出ます。ただし点検の枠は必ず決めてください。1人の場合、点検を飛ばした事実が誰の目にも触れないまま積み上がります。

台帳の突合は、表計算の関数でもできるのではないですか

できます。差分を出すところまでは、関数でも管理ツールでも構いません。外すべきなのは差分を出す作業ではなく、その差分の1行ずつに理由を書き分ける作業のほうです。表記の揺れ、返却の登録漏れ、持ち出し中、廃棄済みの記録漏れ。この分類は、関数では書けないが人が毎回同じように書いている作業なので、外す対象になります。

アカウントの発行そのものを、機械に実行させてよいですか

発行は、止める操作に比べれば戻しやすい操作です。それでも、実行まで任せるのは入社の初期構成のように範囲があらかじめ決まっている場合に限るほうが安全です。前任者と同じ、という依頼を機械が解釈して実行する形にすると、権限が代替わりのたびに増えます。範囲が決まっていない依頼については、候補を並べさせるところまでにしておきます。

障害の一次切り分けを任せると、誤った案内が現場に流れませんか

流れます。頼み方で防ぎます。出力の欄を、候補と確認手順の2つだけにして、原因の欄を作らないこと。候補には過去の記録の番号を根拠として書かせ、書けないものは候補から外すこと。そして周知の文面では、確定した事実と確認中の事項を段落ごと分けること。この3つを型として固定しておけば、現場に流れるのは確認手順であって断定ではなくなります。

外した効果は、どう測ればよいですか

3つの数字を並べます。減った作業時間、増えた点検の時間、そして差し戻しや訂正の件数です。1つ目だけを見ると必ず良い結果になり、3つ目を見ないと質が落ちたことに気づけません。比較の相手は、外す前の2週間で測った数字です。測っていないと、効果があったかどうかを体感でしか語れず、次に外す工程を決める根拠も残りません。

まとめ

情報システム部門の予算は、現行の維持・運営と新しい施策の比率が75.9対24.1で、新しい側は2021年度から24%前後で動いていません。3年後の目標は32.7%と掲げられていますが、3年前の調査でも目標は33.0%でした。目標を立てるだけでは比率は動きません。足す作業には期日と担当が付き、外す作業には付かない。この非対称を直すところから始めます。

生成AIとの関わり方も、いまは配る側に寄っています。調査で挙がっている7つの役割は、ルールの整備、企画と戦略、基盤の整備、発信、研修、支援組織、専門組織。すべて他部門に使わせるための仕事で、情シス自身の恒常業務を軽くする項目は設問に立っていません。関与そのものには効果があると同じ調査が示しているだけに、配る仕事が増えたぶん、自分の恒常業務が減っていないことが際立ちます。

外す単位は工程です。資産と台帳を合わせる、アカウントを発行する、棚卸しして止める、端末を初期設定して渡す、申請を受け付けて捌く、障害を一次で切り分ける。この6つに分け、繰り返しの多さ、判断の要否、元へ戻せるかの3軸で順番を決めます。先頭は台帳と申請、最後がアカウントの棚卸し。つらい順に外そうとすると、この順番と逆になり、前より重くなります。

外せるのは材料をそろえるところまでです。分類の下書き、不足の指摘、確認依頼の文面、候補と確認手順の並べ方。状態を変える操作は人が実行し、実行した人と時刻を残します。削除は30日間なら属性ごと復元できるが、完全な削除は誰にも戻せない。同期元に残っていれば消したはずの利用者が戻ってくる。復元すると席も一緒に戻り、購入数を超えることがある。この仕様を知らずに線を引くと、戻せないところで機械に手を下させることになります。

そして、外したぶん点検と記録と説明が増えます。点検は割合ではなく、読める件数から枠を決めて優先順に埋める。実行の時刻にも仕様があり、予定実行の評価は既定で3時間間隔、遅れた分の追いつきは元の処理時刻から3日までです。締切を工程ごとに書き添えないと、仕組みを入れても初日に使えないままになります。最初の90日で外すのは2工程だけで十分です。外して手に入るのは、空いた時間そのものではなく、次に何を外すかを数字で決められる状態です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。