どーもばるすです。
アドベントカレンダー2025、6日目の記事です。
ﾖｼﾖｼ、間に合いましたね。
Cloudnative IRS Advent Calendar 2025 – Adventar
はじめに
「この業務、手間がかかるから自動化とかしてよ」
情シスや社内IT部門あるいはエンジニアとして働いていると、こうした相談を受けることは日常茶飯事かなと思います。
barusuはこれを「業務効率化クエスト」と呼んでいます。
だいたい偉い人から飛んでくる。
解決策を考える時、すぐにPythonやらでスクリプトを書き始めたり、便利なSaaSツールの導入検討を始めたりすると思うんですけど、いきなり手段に飛びついて大丈夫か？って不安、ありますよね。
そこそこ経験を積んできたbarusuが、実際に「業務効率化クエスト」と向き合うときに考えていることをなるべく整理してまとめてみたのが本稿です。
もちろん、これが唯一の正解だなんて言うつもりはありませんし、現場が変われば最適解も変わります。
業務改善の糸口が見つからず悩んでいる方にとって、一つの思考の補助線になれば良いなーって感じです。
ステップ1：まずは「目的」を定義する
何のために効率化するのか？
「自動化」「効率化」という言葉は非常に便利ですが、プロジェクトの指針にするには解像度が低すぎます。
まずは、今回の取り組みが以下のどのパターンの「効率化」を目指しているのか、言語化することから始めます。
目的によって、取るべき戦術や「どこにコストをかけるか」の判断基準が全く異なるからです。
今までの経験&観測範囲から、目的は以下の5つにだいたい分類できました。
- リソースの再配分（余剰工数の創出）
- 重要度は低いが、とにかく手数や時間がかかる現状業務を圧縮し浮いた時間を他の重要業務に充てたい
- アウトソーシングという別解もある
- スケーラビリティの確保（量的拡大）
- 現在の人員数のままで現在の10倍、100倍の量を捌けるようにしたい
- 事業拡大フェーズ、事業縮小による人員整理時と、会社全体で動きがあるときに要求されがち
- ミスの防止（品質担保）
- 人間ならではのケアレスミスをシステムで防ぎ、手戻りをなくしたい
- インシデント発生後の改善策とかで要求されがち
- 業務遂行ハードルの低減（属人化解消）
- スキルの高い特定の人しかできない業務を、誰でも（あるいは入社初日の人でも）できるようにしたい。
- 重要人物退職/異動の前後で発生しがち
- 新しい価値の創出（速度・冪等性）
- 人力では不可能な速度（即時応答）や、完全な再現性（冪等性）を実現したい。
- 事業変革やDXの号令がかかったときに発生しがち
この目的が明確になっていれば、自然と「どこまでやるか」「何を捨てるか」の判断基準が定まります。
もちろん複合ってパターンもあるんですけどね。そういうときはまた複雑に考えること増えるんですが、だいたい掛け合わせで考えればOKです。
ステップ2：現状を解像度高く把握する「4つの視点」（概要）
目的が定まったら、次は対象となる業務プロセスを分析します。
barusuが必ず用いるのが以下の4つの視点です。まずはざっと全体像を。
| 視点 | 概要 | 問い |
| ① 生ログによる 「手触り」の確認 | マニュアルではなく、実際のチケットやログから「現場の摩擦」を感じ取る。 | ・表記揺れはどれくらいあるか？ ・タイムスタンプに不自然な空白はないか？ ・確認ラリーは何回発生しているか？ ・例外的な依頼は何割混ざっているか？ ・実は「裏ルート（DM）」で来ていないか？ |
| ② 「作業」と 「判断」の分離 | ボトルネックが「手作業」なのか「迷い（判断）」なのかを特定する。 | ・if-then（もし〜なら〜する）で書き切れるか？ ・「空気を読む」要素が含まれていないか？ ・入社初日の新人でも100点を出せるか？ ・ミスをした時の責任の所在はどこか？ ・承認行為自体が形骸化していないか？ |
| ③ 自動化の 「維持コスト」と 「脆弱性」の評価 | 将来のメンテナンスコストと、停止時のリスク（不可逆性）を見積もる。 | ・システム全停止時、手動で業務を回せるか？ ・作成者不在でも誰かが直せるか？ ・仕様変更を検知して即日修正できるか？ ・エラーは非エンジニアでも理解できるか？ ・そもそも、その業務は「なくせない」か？ |
| ④ 既存エコシステム への「整地」可能性 | ツールを刷新せず、今の入力フローや文化を活かして裏側だけ改善する。 | ・ユーザーに新しいURLをブックマークさせるか？ ・自由記述欄を「選択肢」に変えられないか？ ・実はExcelで管理した方が幸せではないか？ ・今のツールの標準機能を使い倒しているか？ ・「見た目」と「中身」を切り離せるか？ |
分析のためのとっかかり
- 生ログによる「手触り」の確認
- マニュアルではなく、実際のチケットやチャットのログから「現場の摩擦」を感じ取る
- 「作業」と「判断」の分離
- プロセスを分解し、ボトルネックが「手作業」なのか「迷い（判断）」なのかを特定する
- 自動化の「維持コスト」と「脆弱性」の評価
- システム化によって生まれる将来のメンテナンスコストと、停止時のリスク（不可逆性）を見積もる
- 既存エコシステムへの「整地」可能性
- ツールを刷新せず、今の入力フローや文化を活かしたまま裏側だけを改善できないか探る
ステップ3：【詳細解説】視点をどう使いこなすか？
自問自答すべき「20のチェックリスト」
では、それぞれの視点について「具体的に何を見るべきか」「どう考えるべきか」を深掘りします。
barusuが現場で実際に自分自身に問いかけている内容をリストアップしました。対象業務を目の前に置いて、これらを自問してみてください。
① 生ログによる「手触り」の確認
綺麗なマニュアルやヒアリング結果には、嘘（あるいは理想）が混ざります。
真実は常に「生のログ」にあります。最低でも直近30〜50件のログを「斜め読み」し、以下の問いを投げかけます。
時間が許すのであれば直近1ヶ月分とかのチケット、対応ログ、システムログなどを確認して運用現場の理解度を高めます。
- Q1. 「表記揺れ」はどれくらいあるか？
- 意図：
ユーザーが入力フォーマットを守れていない場合、それはユーザーが悪いのではなく「UIが悪い（入力欄が自由すぎる）」のです。
ここが自動化の際のエラー源になります。
- 意図：
- Q2. タイムスタンプに「不自然な空白」はないか？
- 意図：
即答できずに数時間〜数日止まっている場合、担当者は裏で「何かを調べている」か「誰かの承認を待っている」可能性が高いです。
その「見えない時間」こそがボトルネックです。
- 意図：
- Q3. 「確認ラリー」は何回発生しているか？
- 意図：
1回の依頼で完結せず、「これってAですか？Bですか？」という質問が発生しているなら、依頼フォーマットの項目不足か、依頼動線の整備が不十分か、パターン整理が必要かのいずれかです。
自動化作るとか以前に動線整備する必要があるよねって話です。
- 意図：
- Q4. 「例外的な依頼」は何割混ざっているか？
- 意図：パレートの法則（80:20）を意識します。
イレギュラーが2割以下なら、それは自動化対象から外して「手動対応」に残すべきかもしれません。
効率化考えるときってイレギュラーどうすんねん？ってなりがちなんですが、「想定内のイレギュラー」にしておけば対応可能になります。
- 意図：パレートの法則（80:20）を意識します。
- Q5. その依頼、実は「裏ルート（DM）」で来ていないか？
- 意図：
チケットシステムの使い勝手が悪すぎたり、依頼してくるユーザーの業務とチケットシステムの相性が悪ければ、チャットなり内線なり口頭なり電話なりで直接依頼が来ます。
これが見えているログに含まれていないと、業務量の見積もりを大きく誤ります。でかい山は別にある状態。
- 意図：
② 「作業」と「判断」の分離
「時間がかかっている業務」を自動化しようとするとき、多くの人は「作業時間」を削ろうとします。
しかし、真のボトルネックは別にあることが多いです。
- Q1. その業務は「if-then（もし〜なら〜する）」で書き切れるか？
- 意図：
書き切れないなら、それは「判断」です。
AIを使わない限り、基本的にはロジックによる自動化は不可能です。でもAIを挟んだプロセスは確認したくなりますよね。
確認を不要にできる or AIの出力が間違っていても別の方法またはプロセスで担保できる と思います。
- 意図：
- Q2. 「空気を読む」「よしなにやる」要素が含まれていないか？
- 意図：
「過去の経緯を知っているからこうする」といった暗黙知が必要な場合、自動化すると必ず事故が起きます。
- 意図：
- Q3. 入社初日の新人でも、マニュアルを見れば100点を出せるか？
- 意図：
Yesなら「作業」なので自動化できます。
?Noなら、そこには熟練の「判断」が介在しており、まずはその言語化が必要です。
- 意図：
- Q4. 作業ミスをした時の責任の所在はどこにあるか？
- 意図：
機械がミスをした時、誰が腹を切るのか。
責任範囲が曖昧な業務を自動化すると、エラー時に誰も対処できなくなります。
- 意図：
- Q5. 「承認」という行為自体が形骸化していないか？
- 意図：
誰も中身を見ずにハンコを押しているだけなら、その「判断」プロセスごと削除できる可能性があります。
- 意図：
③ 自動化の「維持コスト」と「脆弱性」の評価
自動化は「魔法」ではなく「借金（維持コスト）を伴う投資」です。
そして、「今の10倍の量を捌ける」ということは、逆に言えば「システムが止まれば、今の1/10の処理能力になる」ということです。
- Q1. システムが全停止した時、手動で業務を回せるか？
- 意図：
駅の自動改札（Suica）が壊れても、もはや駅員がハサミで切符を切る運用には戻れません。駅員が対応できても、利用者が我慢できないでしょうね。
劇的な効率化はユーザーにとって「不可逆」です。
「戻れない」リスクを負ってでも進める覚悟（インフラ維持コスト）があるかを問います。
- 意図：
- Q2. これを作った自分がいなくなっても、誰かが直せるか？
- 意図：
属人化した複雑なスクリプトは、手作業よりもタチが悪いです。
ExcelVBAが悪く言われがちなのはこれ。
- 意図：
- Q3. 連携先の仕様が変わったら、検知して即日修正できるか？
- 意図：
SaaSのAPI変更などでシステムが止まった際、ビジネスへの影響度と復旧スピードが見合っているかを確認します。
- 意図：
- Q4. そのエラーメッセージは、非エンジニアでも理解できるか？
- 意図：
エラーが出るたびに開発者が呼ばれる仕組みは、業務改善ではなく「開発者の業務増」です。
- 意図：
- Q5. そもそも、その業務は「なくせない」のか？
- 意図：
最も効率的なのは「自動化」ではなく「廃止」です。
自動化することで、無駄な業務を延命させてしまうリスクがないか確認します。
- 意図：
④ 既存エコシステムへの「整地」可能性
「このツールは使いにくいから、最新のSaaSに入れ替えましょう」というのは簡単ですが、現場の混乱と導入コストがかかるので、簡単に使える手札ではありません。
最もスマートなのは「リノベーション」です。
- Q1. ユーザーに「新しいURL」をブックマークさせる必要があるか？
- 意図：
導線が変わるだけでユーザーの抵抗感は跳ね上がります。
既存のポータルやチャットツールから起動できるのが理想です。
- 意図：
- Q2. 入力フォームの「自由記述欄」を「選択肢」に変えられないか？
- 意図：
システムを入れ替えなくても、GoogleフォームやRedmineのカスタムフィールド設定を変えるだけで、データの質は劇的に向上します。
- 意図：
- Q3. そのデータ、実はExcel/スプレッドシートで管理した方が幸せではないか？
- 意図：
現場がExcel/スプレッドシート慣れしているなら、無理にWebアプリ化せず、Excel自体を高度化（Power Query等）する方が定着率は高いです。
- 意図：
- Q4. 今のツールの「標準機能」を使い倒しているか？
- 意図：
スクリプトを書く前に、Redmineのプラグインや、SaaSの標準連携機能で実現できないか調べ尽くしたか。標準機能の方が圧倒的に保守コストが低いです。
- 意図：
- Q5. 「見た目（UI）」と「中身（処理）」を切り離せるか？
- 意図：
UIはそのままで、裏側の処理だけを自動化できれば、ユーザーの学習コストゼロで効率化を実現できます。
- 意図：
ステップ4：【目的別】重点思考ポイントのマッピング
——目的 × 4つの視点 ＝ 最適な解決策
ここが思考プロセスの核心です。
ステップ1で定義した「目的」を達成するために、ステップ2・3のどの視点を重視し、どういうアプローチを取るべきか。5つのパターンごとに解説します。
1. 目的が「リソース再配分」の場合
重点視点：②「作業」と「判断」の分離
- 思考のポイント：「工数を浮かせたい」とき、敵は「作業時間」だと思いがちですが、実は「確認・判断の時間」が最大の敵です。スクリプトで作業時間を0秒にしても、その前の確認で10分迷っていたら意味がありません。
- アプローチ：半自動化 高コストなシステム開発は避け、「判断の基準」を明確化・標準化することに注力するのをおすすめします。
例えば、判断フローチャートを作る、依頼フォームの選択肢を絞るなどして「迷い」を消します。作業自体は手動のままでも、判断コストがゼロになれば目的は達成できます。
2. 目的が「スケーラビリティの確保」の場合
重点視点：③ 自動化の「維持コスト」と「脆弱性」
- 思考のポイント：量がどれくらい増大するかの規模に応じて、手動オペレーションが許容される限度が変わります。自動化した範囲が広ければ広いほど、システム化した瞬間に「止まったら困る」リスクを背負います。
- アプローチ：完全自動化とインフラ投資 作ったシステムの規模に応じて保守体制への予算と人員確保の必要性が変わります。
規模が広い、重要度が高い、代替が利かない等の事情があれば覚悟を決めてコストを払う決断が必要になりますね。
3. 目的が「ミスの防止」の場合
重点視点：④ 既存エコシステムへの「整地」
- 思考のポイント：ミスは「人間の注意力」に依存している箇所で起きます。特に「自由入力」はミスの温床です。
- アプローチ：バリデーション（制約）の強化 新しいツールを入れるよりも、既存の入力フォームで「自由記述」を廃止し、プルダウンや選択式にするなど、システムが受け付ける値を物理的に制限します。「間違ったデータが入ってこない」状態を作れば、後工程のミスは消滅します。
4. 目的が「業務遂行ハードルの低減」の場合
重点視点：① 生ログによる「手触り」
- 思考のポイント：熟練者には見えない「初心者のつまずきポイント」を見つける必要があります。
生ログを見て、「初心者がどこで質問しているか」「どこで間違った依頼をしているか」を特定します。 - アプローチ：ナビゲーション化 業務を自動化するのではなく、ガイドレールを敷きます。Wikiの参照を必須にするフローや、チャットボットによる誘導など、「スキル不要で正解に辿り着ける道」を作ります。
5. 目的が「新しい価値の創出」の場合
重点視点：全視点（特に③脆弱性）
- 思考のポイント：「即時応答」や「完全な再現性」は、人間の延長線上にはありません。
既存プロセスの改善ではなく、根本的な作り変えかシステムへの移行が必要になります。 - アプローチ：アーキテクチャの刷新 API連携やFaaS等を駆使し、ゼロベースで設計します。開発コストも維持コストも高くなりますが、それに見合うリターン（競争優位性など）があるかどうかとかで判断しましょう。
ステップ5：実践ケーススタディ
イメージしやすいように、具体的な業務課題に当てはめて説明していきます。
ケースA：社内メーリングリスト(ML)作成依頼
- 現状： 依頼メールを元にIT担当が手動作成。件数が多く、工数を圧迫している。
- 今回の目的：1. リソース再配分（IT担当の手を空けたい）
【思考プロセス】 ログを確認すると、担当者が「このML名、既存と被ってないか？」「命名規則は合っているか？」を確認/修正するラリーで時間を食っていることが判明（視点①）。
つまりボトルネックは「コマンドを打つ作業」ではなく、「重複確認と命名規則の判断」にあります（視点②）。
【解決策：半自動化】 目的は「担当者の時間を空けること」なので、高コストな全自動システムは不要です。
- 依頼フォームに「既存ML検索」を付け、ユーザー自身に重複確認させる。
- 命名規則を選択式にし、担当者の確認を不要にする。 これだけで、作業は手動のままでも担当者は「無心でコピペして完了」となり、ストレスと工数は激減します。
ケースB：ロングテールSaaSのアカウント棚卸し
- 現状：社内で利用しているマイナーなSaaS（20〜30個）の利用状況を毎月確認したい。
- 今回の目的：3. ミス防止 ＆ 4. ハードル低減（誰でも正確にできるようにしたい）
【思考プロセス】 対象となるSaaSはAPIが提供されていないものや、仕様が頻繁に変わるものが多く含まれています。これら全てに対してスクレイピングやAPI連携を行うスクリプトを組むと、毎月どこかでエラーが発生し、修正コストが効果を上回る「負債」になることが予想されます（視点③）。
【解決策：道具の整備】
- 無理に全連携システムを作らない。
- 各SaaSからのCSVダウンロード手順だけを標準化（動画化・ブックマークレット化）する。
- Excelの目視チェックは廃止し、Power Query等で「突合・集計ロジック」だけを組んだファイルを配布する。 人間は「CSVを落として指定フォルダに入れるだけ」。不安定な「取得部分」はあえて人間が担い、ミスの起きやすい「集計部分」だけを自動化することで、堅牢性と効率のバランスを取ります。
おわりに
業務効率化において最も重要なのは、「何のためにやるか（目的）」と「どこが本当の課題か（ボトルネック）」の整合性が取れていることだと思います。
- リソースを空けたいだけなのに、重厚長大なシステムを作っていないか？
- スケールさせたいのに、手作業を残していないか？
- 判断が必要な業務なのに、ロジックだけで解決しようとしていないか？
この整合性が取れていれば、派手なAIや最新ツールを使わなくても（あるいは、あえて手作業を残したとしても）、そのプロジェクトは間違いなく良い方向に向かうはずです。
まずはチケットのログを読み、目的をセットすることから始めてみてください。それが最短ルートかはわかりませんけど、少なくともゴールの方角を見つける助けにはなるでしょう。
以上、barusuが考えることの共有でした。何かのご参考になれば幸いです。
ではでは。
