はじめに
この1年、私は運用系組織の中で、自動化推進と開発を担当してきました。
DataSpiderやPower Automateをはじめとするローコードツール、
CI/CDや構成管理を目的としたAnsibleなどを活用しながら、
定常運用の効率化や業務負荷削減に取り組んできました。
当初は、「ツールの導入」「設計や開発をする」といった
“技術的な実装”が自動化推進の中心になると考えていましたが、
実際に現場へ入り、
サービス担当や運用担当と連携しながら活動を進めていく中で感じたのは、
「自動化は”技術”より、組織や業務構造が持つ課題をクリアしていく方がずっと難しい！！」
ということでした。
自動化という言葉は、どうしてもRPAやスクリプト開発、AI活用などの
“技術テーマ”として語られがちです。
もちろん技術力は必要です。
ただ、個人的には、実際に自動化を進める中で本当に難しかったは、
- 誰が業務全体を把握しているのか
- どこに改善余地があるのか
- 業務が標準化されているのか
- 誰と調整する必要があるのか
- 改善活動に使える時間を確保できるのか
といった、“組織と業務の構造”からくる課題を見定め、
一つずつ乗り越えていくことでした。
この記事では、現場の若手エンジニアとして1年間自動化推進に関わる中で見えてきた、
- 活動して良かったこと
- 1年活動して見えた課題
- これから自動化を進める上で、取り入れたいこと
を、できるだけ汎用化した形で整理してみたいと思います。
活動してよかったこと
１．自動化・効率化が「組織の重点テーマ」として認識され始めた
活動を通じて最も大きかったのは、自動化が「一部の改善好きな人がやる活動」ではなく、
「組織として必要な取り組み」 と認識され始めたことでした。
以前は、「手が空いたらやる」「得意な人・興味を持つ人が自主的にやる」
という空気感が強く、自動化はどうしても“通常業務の外側”に置かれがちでした。
しかし、継続的に活動を行い、改善事例を共有していく中で、
- 業務負荷の軽減
- 品質向上
- 属人化リスクの低減
- 運用コスト最適化
といった観点から、自動化が組織課題として扱われる場面が増えていきました。
特に印象的だったのは、「自動化＝単なる工数削減」ではなく、
「持続可能な運用体制を作るための手段」 として見られ始めたことです。
これは現場としてかなり大きな変化だったと思います。
２．成功事例を残せた
もう一つ良かったのは、小規模でも成功事例を残せたことでした。
実際に自動化を導入することで、
- 定常作業時間の削減
- 手動ミスの抑制
- 作業品質の均一化
など、目に見える効果が出始めました。
運用現場では、「理論上できる」よりも、「実際に楽になった」の方が圧倒的に説得力があります。
例えば、数十分かかっていた確認作業が数分で終わるようになるだけでも、現場の印象は大きく変わります。
そして一度成功事例ができると、
「他にも自動化できる業務があるのではないか」 という空気が生まれやすくなります。
自動化文化を作る上で、最初の成功体験はかなり重要だと感じました。
1年活動して見えてきた課題
1. 現業が重たすぎる
最初にぶつかったのは、運用現場特有の“現業の重さ”でした。
私は開発担当という立場でしたが、自動化を進めるためには
サービス担当あるいは実業務の担当者の方々との連携が不可欠でした。
サービス担当は、
- サービス仕様の理解
- 運用フローの管理
- 業務手順の把握
- 現場メンバーとの調整
などを担っており、実運用を最も理解している存在です。
つまり、自動化対象を正しく選定し、運用として成立させるためには、
サービス担当との擦り合わせが必須でした。
しかし、こういった人達の立場では、
- 障害対応
- 問い合わせ対応
- 顧客調整
- 定常運用
- エスカレーション対応
など、「今提供しているサービスを止めないこと」が最優先になります。
そのため、”自動化は重要である”と理解されていても、どうしても優先順位が下がりやすくなります。
これは、いわゆる 「樵のジレンマ」 にかなり近い状態でした。
木を切るのに忙しすぎて、斧を研ぐ時間が取れない。自動化も同じで、
- 業務整理
- ヒアリング
- 要件定義
- 開発
- テスト
- 運用設計
には一定の時間が必要です。
短期的にはむしろ追加作業になるため、余力の少ない現場ほど
こうした協力を得られにくく改善活動が進みにくくなります。
その中でも、限られた時間を調整しながら、
丁寧にヒアリングや業務整理へ協力してくださる方々が一定数いたことは、本当にありがたかったです！
実際、自動化がうまく進んだケースほど、現場担当者とのコミュニケーションが密に取れていた印象があります。
2. “手動が普通”になると、自動化対象が見えなくなる
次に大きかったのが、業務の属人化とブラックボックス化です。
長年運用されている業務ほど、
- なぜその作業をしているのか
- どの判断が属人的なのか
- どこに無駄があるのか
が整理されていないケースが多くありました。
特に印象的だったのは、「本人が非効率だと思っていない」 という状態です。
毎日当たり前に行っている作業は、次第に“業務そのもの”になっていきます。例えば、
- Excel転記
- 手動チェック
- ステータス更新
- メール送信
- 会議調整
なども、長年続くと改善対象として認識されなくなります。
結果として、
「自動化できる業務がない」のではなく、「自動化対象として見えていない」 状態になります。
さらに、業務自体が属人化していると、開発側から見ても、
「組織の中のどの業務を優先的に自動化すべきか」が非常に見えづらくなります。
実際、ヒアリングや業務棚卸にはかなり時間がかかりました。
また、時間をかけて業務分析を行っても、開発フェーズで技術的・環境的な制約にぶつかるケースも少なくありませんでした。
例えば、
- 検証環境で本番データを再現できない
- 外部システムとの接続制約がある
- APIが提供されていない
- 権限の都合で試験できない
- 業務ルール自体が標準化されていない
などです。
もちろん、技術力や経験で解決できた部分もあったかもしれません。
ただ実際には、「技術的には実現できそうでも、運用条件を満たせず断念する」というケースは珍しくありませんでした。
ここで初めて、自動化は単なる開発ではなく、“業務分析”そのものだと気付かされました。
3. 技術より“横断調整”の方が難しい
活動前は、技術に対する不安が大きかったです。
しかし、実際に一番苦労したことは、開発作業よりも“横断調整”でした。
私のいる組織の業務は、多くの場合、複数システムを跨いだ作業がありました。
例えば、
- 社内管理システム
- 顧客管理システム
- メール
- 社内のリソース
- ベンダー提供システム
など、異なる仕組みを組み合わせて運用しているケースがほとんどです。
すると、自動化を進めるだけでも、
- システム仕様確認
- 接続可否確認
- セキュリティ審査
- 権限調整
- ベンダー問い合わせ
- 他部署承認
など、開発以外の調整が大量に発生します。
さらに、
- 調整に時間がかかる
- 別部門の優先順位に依存する
- 追加費用が発生する
- ベンダー改修が必要になる
といったケースもありました。
その結果、
「小規模な改善は比較的進めやすいが、大規模な自動化ほど調整コストが急激に増える」 という状況になりやすいことを改めて実感させられました。
どうせ作るなら、「より効果が高いものを！」と欲張って
自動化の範囲を広げたくなるのですが
”技術”以外の理由で開発のコストがかかってしまい、
計画通りにいかなくなってしまうことも。
短期間で成果を出さないといけないプロジェクトだったため、
自動化を途中で断念するケースもあり、悔しい思いもしました。
これから自動化を進める上で、取り入れたいこと
1.「改善活動の時間」を組織として確保すること
1年間活動して最初に感じたのは、「自動化できるか」以前に、
「自動化を考える時間を確保できるか」が最大の壁になっているということでした。
運用現場では、障害対応や問い合わせ対応など、
“今の業務を止めないこと”が最優先になります。
そのため、自動化が重要だと理解されていても、改善活動に時間を割きづらい構造があります。
また、自動化は開発担当だけでは進みません。
実際には、
- 業務を理解している人
- 運用フローを把握している人
- 手順や判断基準を知っている人
の協力が不可欠です。
しかし、その現場担当者自身が日々の運用に追われているため、
「改善したいが時間が取れない」という状態になりやすい。
だからこそ今後は、現場の善意に依存するのではなく、
- 改善活動を業務として扱う
- 業務改善時間を確保する
- マネジメント側が優先順位を上げる
といった、“改善できる状態”を組織として作る必要があると感じました。
2.自動化業務の棚卸と標準化を進める
活動を通じて感じたのは、自動化が難しい理由の多くは、
「技術的に難しい」ではなく、「業務が整理されていない」 ことでした。
例えば、
- 手順が担当者ごとに違う
- 業務フローが整理されていない
- 判断基準が属人化している
といった状態では、開発側も「何を自動化すべきか」を判断しづらくなります。
また、現場任せで改善活動を進めると、チームごとの差も大きくなります。
そのため、
- 業務棚卸
- 手順整理
- 標準化
- 可視化
を、組織として進める必要があると感じました。
業務が整理されていれば、自動化候補の抽出や優先順位付けもしやすくなります。
自動化は、まず「業務を標準的な形で見える化すること」から始めたいところです。
3.“自動化前提”の考え方を組織へ広げる
もう一つ重要だと感じたのは、自動化を一部の専門担当だけのものにしないことでした。
Power AutomateやAIなどを扱える人が限定されていると、自動化は局所的な改善で終わりやすくなります。
本当に必要なのは、
- 「この作業は自動化できないか？」
- 「この運用は本当に必要か？」
と考えられる人を増やすことでした。
そのためには、
- ツールの使い方
- 自動化の考え方
- 業務整理の視点
を、組織全体へ広げていく必要があります。
また今後は 「後から自動化する」のではなく、「最初から自動化前提で設計する」 ことも重要です。
運用は自動化やAIで安定化し、人は改善や分析、開発へシフトしていく。
そうした方向へ、少しずつ変わっていけるよう、導くのが推進メンバーの役目です。
おわりに
この1年で最も変わったのは、「自動化 = 技術課題」という認識でした。
実際には、
- 業務構造
- 組織文化
- 標準化
- 横断調整
など、“組織側の課題”の影響が非常に大きかったです。
だからこそ、組織としての自動化推進には、技術力だけではなく、
- 業務理解
- 構造化
- 調整力
- 改善設計力
などのような、ソフトスキルを身に付けなくてはなりません。
もし今、「自動化を進めたいのに進まない」と感じている人がいたら、
それは技術や経験不足だけが原因ではないかもしれません。
まずは、「改善活動に参加できる構造になっているか」を見直すことが、
自動化推進の第一歩になるはずです。