増員拒否から始まった非開発者の業務自動化事例

繰り返し業務に追われる人は、往々にして、まずより速く処理する方法を探す。しかし、この事例が示す出発点は異なる。人員増強が難しい状況で、ある事業管理担当者は、自分に集中した業務をそのまま高速化するのではなく、なぜすべての依頼と確認が自分を経由しなければならないのかを改めて見直した。

本稿では、自動化技術の機能紹介ではなく、自動化を始めざるを得なかった業務環境、最初の構造改善、非開発者の学習過程、そしてその経験から一般化できる原則を分析する。

事例の出発点：仕事量よりも複雑性が増した

そのチームはもともとインフラ運用事業を担当していた。システムを安定的に運用し、障害に対応し、月次実績をまとめる業務については、すでに慣れた流れがあった。問題は、既存の人員を維持したまま、新たな保守管理事業が加わったことで始まった。

これは、同じ仕事を2倍行う状況とは異なっていた。担当者は未経験の業務を処理すると同時に、次の要素まで新たに設計しなければならなかった。

• どのような成果物を受け取るか
• 文書にどの項目を含めるか
• 業者と顧客の確認順序をどのように定めるか
• 作業ごとの番号と日程をどのように管理するか
• 署名済みの成果物をどのような方法で回収し、報告するか

業務が増えただけでなく、業務を処理する仕組みまで作らなければならなかったことが、過負荷の核心だった。

標準がなければ確認と差し戻しが繰り返される

保守管理の成果物には既存の標準が十分に整っていなかったため、担当者は様式を自ら作成し、業者に配布した。しかし現場では、前年度の書式を使用したり、作業者の署名を漏らしたり、特記事項を曖昧に記載したりする問題が繰り返された。

たとえば、結果欄に「後日対応予定」とだけ記載すると、管理者は完了時期を追跡できない。具体的な予定日を記載するよう差し戻し、修正版を再び確認しなければならない。点検自体よりも、成果物を確認して修正させる管理作業が増える構造である。

この事例は、文書自動化よりも標準化が先であることを示している。入力形式と必須項目が定められていない状態では、自動化ツールも曖昧で不完全なデータを速く移すだけである。自動化を検討するなら、まず次の事項を定める必要がある。

1. 必ず入力すべき項目
2. 許容される日付と氏名の表記方法
3. 署名や添付が必要となる条件
4. 差し戻し理由と修正責任者
5. 完了と判断できる基準

数分の依頼が一日の流れを崩した理由

セキュリティ上、外部ファイルの持ち込みと持ち出しは、担当者1名を経由する単一窓口方式で運用されていた。依頼1件の処理時間は長くなかったが、依頼のタイミングが予告されないという問題があった。

本来の業務に集中している途中で依頼が入ると、作業を止めてファイルを処理しなければならなかった。その後は、中断した業務の文脈を再び思い出す必要があった。この事例で体感的な負担を増大させたのは、個々の依頼にかかる時間よりも、繰り返される業務の切り替えだった。

自動化の候補を探す際は、1件を処理する時間だけを計算するのでは不十分である。次のコストもあわせて検討する必要がある。

• 依頼を確認し、優先順位を判断する時間
• 進行中の仕事を止め、再開するための切り替えコスト
• 不足している情報を依頼者に再確認する時間
• 処理の有無を別途記録し、報告する時間
• 特定の担当者が不在の際に発生する待ち時間

短時間で済むものの、予測できずに繰り返される依頼は、全体の日程と集中力を大きく揺るがすボトルネックになり得る。

最初の解決策は自動化ではなく経路の削除だった

ファイルの持ち出し・持ち込み問題に対する最初の改善は、プログラム開発ではなかった。社内プロジェクト管理システムの掲示板を利用し、依頼者と顧客が直接依頼をやり取りするように流れを変更した。

ここから得られる原則は明確である。自分が担当する仕事をより速く行うより、その仕事が自分を経由する必要をなくすほうが、より良い解決策となる場合がある。

自動化を設計する前には、次の順序で検討することが有用である。

1. なくしてもよい工程か？
2. 依頼者が直接入力または確認できるか？
3. 既存システムの機能で経路を簡素化できるか？
4. 入力と判断基準を標準化できるか？
5. その後も残る繰り返し作業を自動化できるか？

複数の単純業務が同時に集中し、過負荷が常態化した

保守管理の全体フローには、日程策定、業者・作業者情報の整理、番号付与、作業日誌の回収、顧客による確認と署名、スキャン、検収報告、業者別の成果物送付が含まれていた。各工程は個別には難しい業務ではなかったが、一度に重なると、人が記憶と手作業だけで統制することは難しい。

この状態は約3か月間続いた。日中は持ち出し・持ち込み依頼、業者からの問い合わせ、チームメンバーの確認、顧客からの依頼に対応し、連絡が減る退勤時間後になって初めて、滞留した中核業務を処理するパターンが繰り返された。問題を解決するというより、その日に発生した仕事を後から追いかける状態に近かった。

担当者は業務補助人員の増員を要請したが、受け入れられなかった。人員追加が不可能になると、従来の方式を変えるという選択肢が重要になった。自動化は関心から始まった趣味ではなく、現在の業務構造では翌月も同じ問題が繰り返されるという判断から生まれた対応だった。

Claude Codeの実演が小さな実験のきっかけになった

転機は、本社のイベントで見たClaudeを活用した自動化の実演だった。複雑な開発技術よりも、「このツールを自分たちの業務にも適用できそうだ」という可能性を確認できたことが重要だった。一緒に参加した同僚と、小さな試みを始めてみようと話したことが、その後の自動化作業の出発点となった。

開発者ではなかった担当者は、Claude Codeのインストール方法から、別の生成AIに質問した。オペレーティングシステムに合った案内とコマンドを確認して実行し、動画資料などを見ながら、ほかの利用者による初期設定の手順をたどった。最初からプログラミング理論を完全に習得してから始めたわけではなかった。

ただし、この方法は、出所の分からないコマンドをそのまま実行してよいという意味ではない。業務用端末では、組織のセキュリティポリシーとソフトウェアのインストール権限を確認し、可能であれば公式文書のインストール手順を使用すべきである。コマンドがファイル削除、権限変更、外部送信を実行するものかどうかも、実行前に確認しなければならない。

成果物より重要だった対話型の問題解決プロセス

最初の成果物は、「非開発者でも自動化を作れる」という自信をもたらした。しかし、この事例でより重要な学びは、完成したプログラムよりも制作過程にあった。

対話型の開発は、概ね次のような循環で進む。

• 解決すべき問題と現在の手順を説明する。
• 入力ファイル、出力形式、セキュリティ上の制約など、条件を伝える。
• AIが提案した方法とコードを確認する。
• コピーやテストデータで実行する。
• エラーメッセージや予想と異なる結果を改めて説明する。
• 修正案を適用し、再検証する。

生成AIは、利用者が知らなかった技術やアプローチを提案でき、馴染みのない用語を再度説明するよう求めることもできる。一方で、提案が常に正確で、組織の環境に適しているとは限らない。したがって、AIは判断を代行する承認者ではなく、選択肢を広げ、試行錯誤を減らす補助手段として扱う必要がある。

事例から抽出した自動化対象の判断基準

繰り返されるという理由だけで、すべての業務を自動化する必要はない。次の基準をあわせて評価すると、優先順位を定めやすい。

最初に自動化する業務は通常、ルールが明確で反復頻度が高く、結果を人が容易に照合できる小さな作業である。反対に、法的判断、セキュリティ承認、契約上の責任、または重要な金額の決定が含まれる業務は、人による確認工程を維持するほうが安全である。

自動化で見落としやすい統制と保守管理

業務が差し迫っているという理由で自動化を急ぐと、従来の手作業に伴うリスクがコードの中に移る可能性がある。特にこの事例のように、外部ファイル、署名済み文書、顧客資料を扱う環境では、処理速度とともに統制を設計する必要がある。

最低限確認すべき統制項目

• 権限： 自動化ツールがアクセスできるフォルダとアカウントを必要な範囲に制限する。
• データ保護： 個人情報、契約資料、認証情報を、承認されていない外部AIサービスに入力しない。
• テスト環境： 原本ではなく、コピーと匿名化したテストデータで先に実行する。
• 人による承認： ファイル送信、削除、最終報告のように元に戻すことが難しい工程には、確認手順を設ける。
• 記録： 入力、実行時刻、処理結果、エラーと修正履歴を残す。
• 復旧： 失敗した際に以前の状態へ戻れるよう、原本とバックアップを保存する。
• 担当者への依存： 作成者以外のチームメンバーも、実行方法と停止方法を把握できるよう文書化する。

自動化の成功基準も、「一度実行できた」であってはならない。様式が変わったり担当者が交代したりしても修正できるか、エラーを発見できるか、手動手順に戻せるかをあわせて評価する必要がある。これは、短期的な個人向け生産性ツールと持続可能な業務システムを区別する基準である。

経験から確認された事実と一般化する際の限界

この事例は、ある担当者の実体験に基づいているため、すべての組織で同じ結果を保証するものではない。事例から直接確認できる内容と、ほかの環境に適用する際に検証すべき内容を区別する必要がある。

したがって、この事例の核心的な価値は、特定のツールが誰にでも同じ成果をもたらすという主張にあるのではない。繰り返し業務を個人の努力不足と解釈せず、フロー、標準、権限、ボトルネックの問題として再定義した点にある。

結論：時間がないという事実が出発点になり得る

自動化は、余裕ができてから学ぶ別個のプロジェクトとしてのみ捉える必要はない。業務が増え続け、翌月も同じ問題が繰り返されるのであれば、現在の構造を変えるべきだというシグナルかもしれない。

出発点は、大がかりな開発計画である必要はない。最も頻繁に集中を途切れさせる依頼を1つ選び、その工程が本当に自分を経由しなければならないのかを確認することから始められる。削除したり既存システムに移したりできないのであれば、入力形式を標準化し、結果を容易に検証できる小さな部分から自動化するほうが安全である。

この事例が残す最も重要な問いは、「この仕事をどうすればもっと速くできるか」ではない。「なぜこの仕事は繰り返され、なぜ必ず自分を経由しなければならず、どの工程までシステムに任せられるのか」である。