増員拒否から始まった非開発者の業務自動化事例 ====================== 人員と標準が不足する中で保守管理業務まで担うことになった事業管理担当者が、ボトルネックを解消し、Claude Codeで小さな自動化を始めた事例だ。重要なのは、仕事をより速く処理する技術よりも、不要な経由や繰り返しが生じる業務構造を先に変えることにある。 - 業務量の増加よりも大きな問題は、新しい手順と成果物の標準を既存の人員が同時に作らなければならなかった点だ。 - 短時間で済むファイルの持ち出し・持ち込み依頼でも、集中を繰り返し途切れさせれば、実際の処理時間を超える業務負担を生む。 - 最初に効果を上げた改善は自動化プログラムではなく、依頼が担当者を経由しないように経路を変えたことだった。 - 非開発者でも、生成AIとコーディングツールを使い、問題の説明、実行、エラー確認、修正のサイクルによって小さな自動化を作れる。 - 自動化の対象は、反復回数だけでなく、エラーのリスク、中断頻度、標準化の可能性、セキュリティ統制も併せて評価すべきだ。 繰り返し業務に追われる人は、往々にして、まずより速く処理する方法を探す。しかし、この事例が示す出発点は異なる。人員増強が難しい状況で、ある事業管理担当者は、自分に集中した業務をそのまま高速化するのではなく、なぜすべての依頼と確認が自分を経由しなければならないのかを改めて見直した。 本稿では、自動化技術の機能紹介ではなく、自動化を始めざるを得なかった業務環境、最初の構造改善、非開発者の学習過程、そしてその経験から一般化できる原則を分析する。 事例の出発点：仕事量よりも複雑性が増した そのチームはもともとインフラ運用事業を担当していた。システムを安定的に運用し、障害に対応し、月次実績をまとめる業務については、すでに慣れた流れがあった。問題は、既存の人員を維持したまま、新たな保守管理事業が加わったことで始まった。 これは、同じ仕事を2倍行う状況とは異なっていた。担当者は未経験の業務を処理すると同時に、次の要素まで新たに設計しなければならなかった。 どのような成果物を受け取るか 文書にどの項目を含めるか 業者と顧客の確認順序をどのように定めるか 作業ごとの番号と日程をどのように管理するか 署名済みの成果物をどのような方法で回収し、報告するか 区分 既存のインフラ運用 追加された保守管理業務 業務体系 慣れた運用手順が存在 手順と基準を新たに設計する必要がある 主な成果物 運用実績と障害対応記録 計画表、作業日誌、署名済み文書、検収資料など 管理対象 社内運用が中心 業者、作業者、担当部門、顧客がともに参加 主な負担 安定的な運用 標準策定、日程調整、確認、差し戻し、回収までを含む 業務が増えただけでなく、業務を処理する仕組みまで作らなければならなかったことが、過負荷の核心だった。 標準がなければ確認と差し戻しが繰り返される 保守管理の成果物には既存の標準が十分に整っていなかったため、担当者は様式を自ら作成し、業者に配布した。しかし現場では、前年度の書式を使用したり、作業者の署名を漏らしたり、特記事項を曖昧に記載したりする問題が繰り返された。 たとえば、結果欄に「後日対応予定」とだけ記載すると、管理者は完了時期を追跡できない。具体的な予定日を記載するよう差し戻し、修正版を再び確認しなければならない。点検自体よりも、成果物を確認して修正させる管理作業が増える構造である。 この事例は、文書自動化よりも標準化が先であることを示している。入力形式と必須項目が定められていない状態では、自動化ツールも曖昧で不完全なデータを速く移すだけである。自動化を検討するなら、まず次の事項を定める必要がある。 必ず入力すべき項目 許容される日付と氏名の表記方法 署名や添付が必要となる条件 差し戻し理由と修正責任者 完了と判断できる基準 数分の依頼が一日の流れを崩した理由 セキュリティ上、外部ファイルの持ち込みと持ち出しは、担当者1名を経由する単一窓口方式で運用されていた。依頼1件の処理時間は長くなかったが、依頼のタイミングが予告されないという問題があった。 本来の業務に集中している途中で依頼が入ると、作業を止めてファイルを処理しなければならなかった。その後は、中断した業務の文脈を再び思い出す必要があった。この事例で体感的な負担を増大させたのは、個々の依頼にかかる時間よりも、繰り返される業務の切り替えだった。 自動化の候補を探す際は、1件を処理する時間だけを計算するのでは不十分である。次のコストもあわせて検討する必要がある。 依頼を確認し、優先順位を判断する時間 進行中の仕事を止め、再開するための切り替えコスト 不足している情報を依頼者に再確認する時間 処理の有無を別途記録し、報告する時間 特定の担当者が不在の際に発生する待ち時間 短時間で済むものの、予測できずに繰り返される依頼は、全体の日程と集中力を大きく揺るがすボトルネックになり得る。 最初の解決策は自動化ではなく経路の削除だった ファイルの持ち出し・持ち込み問題に対する最初の改善は、プログラム開発ではなかった。社内プロジェクト管理システムの掲示板を利用し、依頼者と顧客が直接依頼をやり取りするように流れを変更した。 変更前 変更後 すべての依頼が事業管理担当者を経由 依頼者と顧客がシステム上で直接処理 担当者が受け渡しと記録をすべて実施 システムに処理記録が残る 依頼が来るたびに本来の業務を中断 担当者は必要なときに記録を確認 担当者の不在時に依頼が遅れる可能性がある 所定の参加者が同じフロー上で確認可能 ここから得られる原則は明確である。自分が担当する仕事をより速く行うより、その仕事が自分を経由する必要をなくすほうが、より良い解決策となる場合がある。 自動化を設計する前には、次の順序で検討することが有用である。 なくしてもよい工程か？ 依頼者が直接入力または確認できるか？ 既存システムの機能で経路を簡素化できるか？ 入力と判断基準を標準化できるか？ その後も残る繰り返し作業を自動化できるか？ 複数の単純業務が同時に集中し、過負荷が常態化した 保守管理の全体フローには、日程策定、業者・作業者情報の整理、番号付与、作業日誌の回収、顧客による確認と署名、スキャン、検収報告、業者別の成果物送付が含まれていた。各工程は個別には難しい業務ではなかったが、一度に重なると、人が記憶と手作業だけで統制することは難しい。 この状態は約3か月間続いた。日中は持ち出し・持ち込み依頼、業者からの問い合わせ、チームメンバーの確認、顧客からの依頼に対応し、連絡が減る退勤時間後になって初めて、滞留した中核業務を処理するパターンが繰り返された。問題を解決するというより、その日に発生した仕事を後から追いかける状態に近かった。 担当者は業務補助人員の増員を要請したが、受け入れられなかった。人員追加が不可能になると、従来の方式を変えるという選択肢が重要になった。自動化は関心から始まった趣味ではなく、現在の業務構造では翌月も同じ問題が繰り返されるという判断から生まれた対応だった。 Claude Codeの実演が小さな実験のきっかけになった 転機は、本社のイベントで見たClaudeを活用した自動化の実演だった。複雑な開発技術よりも、「このツールを自分たちの業務にも適用できそうだ」という可能性を確認できたことが重要だった。一緒に参加した同僚と、小さな試みを始めてみようと話したことが、その後の自動化作業の出発点となった。 開発者ではなかった担当者は、Claude Codeのインストール方法から、別の生成AIに質問した。オペレーティングシステムに合った案内とコマンドを確認して実行し、動画資料などを見ながら、ほかの利用者による初期設定の手順をたどった。最初からプログラミング理論を完全に習得してから始めたわけではなかった。 ただし、この方法は、出所の分からないコマンドをそのまま実行してよいという意味ではない。業務用端末では、組織のセキュリティポリシーとソフトウェアのインストール権限を確認し、可能であれば公式文書のインストール手順を使用すべきである。コマンドがファイル削除、権限変更、外部送信を実行するものかどうかも、実行前に確認しなければならない。 成果物より重要だった対話型の問題解決プロセス 最初の成果物は、「非開発者でも自動化を作れる」という自信をもたらした。しかし、この事例でより重要な学びは、完成したプログラムよりも制作過程にあった。 対話型の開発は、概ね次のような循環で進む。 解決すべき問題と現在の手順を説明する。 入力ファイル、出力形式、セキュリティ上の制約など、条件を伝える。 AIが提案した方法とコードを確認する。 コピーやテストデータで実行する。 エラーメッセージや予想と異なる結果を改めて説明する。 修正案を適用し、再検証する。 生成AIは、利用者が知らなかった技術やアプローチを提案でき、馴染みのない用語を再度説明するよう求めることもできる。一方で、提案が常に正確で、組織の環境に適しているとは限らない。したがって、AIは判断を代行する承認者ではなく、選択肢を広げ、試行錯誤を減らす補助手段として扱う必要がある。 事例から抽出した自動化対象の判断基準 繰り返されるという理由だけで、すべての業務を自動化する必要はない。次の基準をあわせて評価すると、優先順位を定めやすい。 判断基準 確認する質問 意味 反復頻度 同じ作業がどの程度頻繁に発生するか？ 頻繁に繰り返されるほど、累積的な削減効果が大きくなる 処理ルール 入力と結果を明確なルールで説明できるか？ ルールが明確なほど、実装と検証が容易になる 中断頻度 予告なく発生し、中核業務を中断させるか？ 短時間の業務でも優先順位が高くなり得る エラーの影響 漏れや誤判断が契約、セキュリティ、費用に影響するか？ 完全自動化ではなく、人による承認が必要な場合がある 入力品質 様式と必須項目が標準化されているか？ 不規則な入力は例外処理を増やす 追跡可能性 誰がいつ何を処理したかを記録できるか？ 監査と責任確認に必要 変更可能性 手順と様式が頻繁に変わるか？ 保守管理コストもあわせて考慮する必要がある 最初に自動化する業務は通常、ルールが明確で反復頻度が高く、結果を人が容易に照合できる小さな作業である。反対に、法的判断、セキュリティ承認、契約上の責任、または重要な金額の決定が含まれる業務は、人による確認工程を維持するほうが安全である。 自動化で見落としやすい統制と保守管理 業務が差し迫っているという理由で自動化を急ぐと、従来の手作業に伴うリスクがコードの中に移る可能性がある。特にこの事例のように、外部ファイル、署名済み文書、顧客資料を扱う環境では、処理速度とともに統制を設計する必要がある。 最低限確認すべき統制項目 権限： 自動化ツールがアクセスできるフォルダとアカウントを必要な範囲に制限する。 データ保護： 個人情報、契約資料、認証情報を、承認されていない外部AIサービスに入力しない。 テスト環境： 原本ではなく、コピーと匿名化したテストデータで先に実行する。 人による承認： ファイル送信、削除、最終報告のように元に戻すことが難しい工程には、確認手順を設ける。 記録： 入力、実行時刻、処理結果、エラーと修正履歴を残す。 復旧： 失敗した際に以前の状態へ戻れるよう、原本とバックアップを保存する。 担当者への依存： 作成者以外のチームメンバーも、実行方法と停止方法を把握できるよう文書化する。 自動化の成功基準も、「一度実行できた」であってはならない。様式が変わったり担当者が交代したりしても修正できるか、エラーを発見できるか、手動手順に戻せるかをあわせて評価する必要がある。これは、短期的な個人向け生産性ツールと持続可能な業務システムを区別する基準である。 経験から確認された事実と一般化する際の限界 この事例は、ある担当者の実体験に基づいているため、すべての組織で同じ結果を保証するものではない。事例から直接確認できる内容と、ほかの環境に適用する際に検証すべき内容を区別する必要がある。 事例で観察された内容 適用前に別途確認すべき内容 人員の変化なく、新たな保守管理業務が追加された 組織ごとの人員配置と業務調整の可能性 単一窓口が担当者の業務を繰り返し中断させた セキュリティ規定上、依頼者間の直接処理が許可されるかどうか 既存の管理システムの掲示板で経由工程を減らした 使用中のシステムの権限、記録保存、承認機能 生成AIの案内を活用し、非開発者がツールをインストールして学習した 会社端末のインストール権限と外部AIの利用ポリシー 小さな成果物が、さらなる自動化に取り組む自信につながった 自動化の正確性、削減時間、保守管理コスト したがって、この事例の核心的な価値は、特定のツールが誰にでも同じ成果をもたらすという主張にあるのではない。繰り返し業務を個人の努力不足と解釈せず、フロー、標準、権限、ボトルネックの問題として再定義した点にある。 結論：時間がないという事実が出発点になり得る 自動化は、余裕ができてから学ぶ別個のプロジェクトとしてのみ捉える必要はない。業務が増え続け、翌月も同じ問題が繰り返されるのであれば、現在の構造を変えるべきだというシグナルかもしれない。 出発点は、大がかりな開発計画である必要はない。最も頻繁に集中を途切れさせる依頼を1つ選び、その工程が本当に自分を経由しなければならないのかを確認することから始められる。削除したり既存システムに移したりできないのであれば、入力形式を標準化し、結果を容易に検証できる小さな部分から自動化するほうが安全である。 この事例が残す最も重要な問いは、「この仕事をどうすればもっと速くできるか」ではない。「なぜこの仕事は繰り返され、なぜ必ず自分を経由しなければならず、どの工程までシステムに任せられるのか」である。 FAQ Q. 開発者でなくても業務の自動化を始められますか？ A. 可能ですが、小さな範囲から始めるのが安全です。現在の手順と入出力条件を明確に説明し、生成AIが提案した方法をコピーまたはテストデータで実行したうえで、結果を自分で検証する必要があります。 Q. 反復業務はすべて自動化すべきですか？ A. いいえ。まず、その工程をなくすか、依頼者自身に処理してもらえるかを確認する必要があります。削除や経路の簡素化が難しく、ルールが明確な反復作業であれば、自動化を検討できます。 Q. 処理時間が短い業務も自動化する価値がありますか？ A. 予告なく頻繁に発生し、主要業務を中断させるのであれば、価値がある可能性があります。1件あたりの処理時間だけでなく、依頼の確認、業務の切り替え、不足情報の補完、記録、再集中にかかるコストも併せて評価する必要があります。 Q. 業務の自動化よりも標準化を先に行う必要があるのはなぜですか？ A. 必須項目や入力形式が一定でなければ、自動化で例外を安定して処理するのが難しいためです。完了基準、日付形式、署名条件、差し戻し理由を先に定めると、実装と検証が容易になります。 Q. 生成AIが作成したコードをそのまま実行してもよいですか？ A. そのまま実行してはいけません。ファイルの削除、権限の変更、外部への送信の有無を検討し、組織のセキュリティポリシーとインストール権限を確認する必要があります。原本ではなくコピーと匿名化したテストデータで先に検証するのが安全です。 Q. 自動化すれば、人による確認をすべてなくせますか？ A. 業務のリスクの程度によって異なります。ファイルの送信や削除、セキュリティ承認、契約上の判断、重要な金額の決定など、ミスによる影響が大きい工程には、人による確認と承認手続きを残す必要があります。 Q. 最初の自動化対象には、どのような業務を選ぶとよいですか？ A. 反復頻度が高く、ルールが明確で、結果を人が容易に照合できる小さな作業が適しています。エラーが発生しても原本から復元できることや、機密情報が漏えいするリスクが低いことも確認する必要があります。 Q. 自動化が成功したかどうかは、どのように判断しますか？ A. 実行が成功したかどうかだけでなく、中断回数、差し戻しや漏れ、処理待ち、エラー修正時間も併せて比較する必要があります。書式の変更や担当者の交代があっても維持できるか、失敗時に手動手順へ戻せるかも評価する必要があります。 Sources - 増員を拒否され、「これを一度やってみよう」から始まった自動化 | 요즘IT: https://yozm.wishket.com/magazine/detail/3912/ Images - 作業場の机でノートパソコンを使う従業員とタッチ画面を見る同僚: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI4NzUsInB1ciI6ImJsb2JfaWQifX0=--6ea22c48d8437db264e2c179ded939ce099f2a0b/ai-fcef29be.webp - 煩雑な書類や通知が自動化されたダッシュボードとワークフローへ変わる流れ: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTI4ODMsInB1ciI6ImJsb2JfaWQifX0=--8996698429ec4d415b74063aa44ca9f301aa486e/ai-cd6d8a57.webp --- Category: 事例研究 Source: https://injoys.com/ja/articles/project-manager-workflow-automation-case-study License: cc_by Translation-Status: reviewed