はじめに

コンピュータを使用した多くの操作は自動化することができます。
この技術は運用や試験工程で大きな力を発揮します。

自動化の技術は一般的なソフトウェア技術者が、ちょっと努力すれば普通に身につく能力であって、特別なものではありません。

ただ残念なことにこれらの技術はあまり知られておらず、活用されているとは言い難い現場も多いです。
ユーザー企業さんができないのはしょうがないですが、ITで飯を食べているはずの自称IT企業においても、自動化を拒否して手動で心をこめて作業をしてリソースを無駄にするケースを稀によく見かけます。

自動化の拒否が「余剰人員のための経済対策だよ！」という身もふたもない理由でないと信じて今回は、Windowsでの作業の自動化についてお話しようと思います。

自動化のテクニックの話をする前に

Windowsの自動化のテクニックの話をする前にちょっと重要なことを先に述べておきます

銀の弾丸はない

あらかじめ言っておくと、ある種のセオリー的なものは紹介できますが、全ての環境で最善の方法を紹介するのは無理ですし、おそらく、そんなものは存在しません。せいぜいこういう状況でこれが使えるという話になります。

たとえば...

…と思っている方も、一旦、その存在は忘れてください。

RPAツールはどう自動化すべきか知っている人が使った場合、大きな効果がありますが、そのお手軽操作感に惑わされてRPAツールを採用したり、予算関係の都合でRPAツールを使うためだけにRPAツールを採用した場合、おそらく、後悔することになります。

たとえばRPAツールはお手軽に画面操作を記録して自動化が容易にできたと錯覚をさせることができます。おそらく、そうやって作成した自動化スクリプトは、多くの場合、安定して動作しません。
また、何故動作するのかを理解せずに作成された自動化スクリプトが大量に作成されるため、Windowsアップデートやアプリケーションのバージョンアップで動かなくなり、その修正に大きなコストがかかるようになります。

自分が使う道具の特性をよく見極めて、必要に応じて別の道具と組み合わせて使用してください。

本当に自動化必要ですか？

自動化を行うまえに本当にその作業が自動化必要なのか…そもそもその作業自体必要なのかを考えてください。

自動化をスクリプトを作成する場合、一定のコストがかかります。
これは一時的なコストになると思われがちですが、実際は継続的なコストになります。

たとえば、Windowsアップデートやアプリケーションのバージョンアップ、ハードウェアの変更など、自動化スクリプトが動かなくなる要因は多くあり、その対応コストを考える必要があります。

それらのコストを上回るリターンがある場合のみ着手してください。

適切に作成された自動化スクリプトは大きな資産になりますが、よくわからず作成された自動化スクリプトは負債になるということを覚えておいてください。

どこまでやるかを考えよう

業務の自動化を行う場合、すべての環境ですべての作業を自動化しようと考えると実現が不可能になります。
自動化がやりやすい箇所で最も効果的なものからやっていった方がいいでしょう。

また、自動化を行う環境も制限するようにした方がいいです。
たとえばWindows7とWindows10の環境で動かすようにするより、Windows10の.NET 4.7のみとか、この端末でのみとか動作環境を絞った方が自動化しやすいです。

自動化をはじめよう

コマンドラインを利用しよう

もっとも楽な自動化の方法はコマンドラインから実行することです。
今はやりのRPAで動作が安定しないという話がよくでてきますが、それは画面操作だけで自動化をめざすからです。
コマンドラインから自動操作するように心がければすれば、かなり安定します。

つまり、自動化を行うならまず最初にやるべきことはコマンドラインと仲良くなることです。
自分の環境のコマンドラインから、なにができるかを調べて、よく考えることです。

たとえば、ファイル操作であればコマンドプロンプトから、ほとんどのことは実行できます。
Windowsの場合なら、バッチやWSH、PowerShellを使用することで分岐や繰り返しを記述できます。

アプリケーションをコマンドラインから操作しよう。

GUIで動くアプリケーションも起動時にコマンドラインから引数を与えることで望んだ操作を行わせることができます。
たとえば、Windowsに最初から入っているメモ帳はコマンドラインから以下のように実行すると任意のテキストファイルを起動時に開くことができます。

notepad.exe C:\doc\books\統計.txt

自動操作したいアプリケーションが、コマンドラインからどのようなパラメータを受け付けるかは、アプリケーションのヘルプを見てみましょう。マニュアルを読んでもいいですし、アプリケーションによっては/?や/helpといったオプションを付けて実行してみるとヘルプが出てくる場合があります。

SIerではよく、サクラエディタ、WinScp、TeraTerm、WinMergeといったアプリケーションが使われていますが、これらのアプリケーションも多くのことがコマンドラインにパラメータを与えることで自動操作が行えます。

サクラエディタ
コマンドラインからGrepやマクロの実行が可能です。
https://qiita.com/mima_ita/items/1ca8b41e29329bb980d0

WinSCP
コマンドラインからファイルのアップロード、ダウンロードが自動で可能です。また、提供されているdllを使用することでPowerShellを含めた.NETFrameworkでのプログラミングが可能です
https://qiita.com/mima_ita/items/35261ec39c3c587210d8

TeraTerm
コマンドラインからマクロを実行することでリモートコンピュータに接続後に任意のコマンドを実行することも可能です。
https://qiita.com/mima_ita/items/60c30a28ea64972008f2

WinMerge
コマンドラインから比較レポートの作成やマージの実行ができます。
https://qiita.com/mima_ita/items/ac21c0588080e73fc458

また、これらのアプリケーションをインストールするためのインストーラ自体、コマンドプロンプトで起動ができます。
Windowsのアプリケーションのインストールは自動でやりたい
https://qiita.com/mima_ita/items/414451b78062151e1595

このように、コマンドラインからパラメータを与えるだけで多くの自動操作を行うことが可能になっています。
まず、RPAツールとかプログラミング言語とか難しい技術を持ち出す前に、普段使用しているアプリケーションがコマンドラインからなにができるかを調べてみましょう。それだけで、かなりの自動操作が行えるようになります。

デフォルトの状態のWindowsでプログラムを行いたい

特別なプログラム言語をインストールしなくても、いくつかの方法でプログラミングが行えます。
主につかわれるのは以下の３つです。

バッチファイル
WSH
PowerShell

バッチファイル

ファイルの操作や、アプリケーションやコマンドの実行、エラー判定などの簡単な処理を記述できます。
COMや.NETのライブラリを使用した難しいことはできませんが、多くの場合、これで十分な場合があります。

ただ、複雑な処理を記述するには向いていないので、その場合、WSHかPowerShellを使用しましょう。

汝、コマンドプロンプトを愛せよ
https://qiita.com/mima_ita/items/90f709cad32ca4e7413d

WSH

WSHとはWindows Script Hostの略で、Windows2000やWindowsXP環境下ですら使用可能です。
Microsoft Visual Basic Scripting Edition (以下 VBScript) と, Microsoft JScriptの2種類※がサポートされています。JScriptはMS独自の規格で一般なJavaScriptとは規格が異なります。

※環境によってはEdgeのエンジンを使用することができる。コメント欄参照

バッチファイルより複雑な処理を実現することが可能です。
具体的には下記のようなことが可能になっています。

システム情報の取得と変更
ファイル・フォルダの作成、コピー、属性変更
レジストリの読み書き
プログラムの実行
COMコンポーネントの作成・利用
- InternetExploreの操作
- Office（ExcelやWord)の操作

弱みとしては以下の通りです。

.NET Frameworkのライブラリを利用できない（一部を除く）
UTF8に弱い
Win32 APIが使用できない
VBScriptだとTry-Catch的な実装ができないのでエラー処理が弱い
- JScriptは使えました。
デバッガーは存在するがVisualStudioを入れる必要がある

レガシー環境のためのWindows Script Host(WSH)の解説
https://qiita.com/mima_ita/items/127e171db67aaee6ef30

PowerShell

Windows7から使用可能です。WSHの上位互換といえるでしょう。
.NET Framework上で動作し、.NET Frameworkで作成されたライブラリをフルに使用できますし、Win32 APIも実行できます。
具体的な使用例は以下を参照ください。

Powershellによるファイル操作のまとめ
https://qiita.com/mima_ita/items/ae31f3a19389e69b307f

PowerShellによるレジストリの操作例
https://qiita.com/mima_ita/items/1e6c74c7fb641852edff

ただ、COMの操作だけは.NETを使用する都合上、WSHより解放処理が面倒になっています。

.NETを使ったOfficeの自動化が面倒なはずがない―そう考えていた時期が俺にもありました。
https://qiita.com/mima_ita/items/aa811423d8c4410eca71

##Officeアプリケーションの自動化をしよう
MicroSoftのOfficeアプリケーションは多くの現場で使用されています。
そして同時に多くの自動化が望まれているものでもあります。

幸いなことに、Excel,Word,PowerPoint…MsProjectにいたるまで、多くのOfficeアプリケーションはCOM経由での自動操作が可能になっており、また、マクロが実装できるようになっています。

Officeでマクロ開発しよう

ひと昔前のOfficeは既定のメニューから簡単にマクロの開発のメニューができましたが、最近のOfficeはひと手間必要になります。

(1)Word等のOfficeアプリケーションを開いたら、オプション画面を表示します。

(2)オプション画面を開いたら「リボンのユーザ設定」を選択します。

(3)その後、開発にチェックします。

(4)するとメニューに「開発」が表示されます。

これによりOfficeアプリケーションからマクロを記述して自動化することが可能になります。
おそらく、色々な書籍が売っているので学習には困らないと思います。
Excelなどが有名ですが、基本的にOfficeアプリケーションの多くがVBAによるマクロ開発のサポートをしています。

具体的なOfficeのVBAの開発の話は下記を参考にしてください。ExcelVBAとかいっていますが、その他製品のVBAに対する開発についての基本的な考えは同じです。

オプーナとゆっくりのExcelVBA講座
https://www.nicovideo.jp/mylist/36464404

Excel VBAコーディングガイドライン案
https://qiita.com/mima_ita/items/8b0eec3b5a81f168822d

OfficeアプリケーションのCOM経由での操作

先ほどいったとおり、Officeアプリケーションの自動化はCOM経由で別のプログラミング言語から操作が可能です。

RedmineをあきらめたオレたちのPowerShellでのOutlookの自動操作
https://qiita.com/mima_ita/items/37ab711a571f29346830

PowerPointで茜ちゃんに喋ってもらう
https://qiita.com/mima_ita/items/e5b982796fd4c14553a6

MSProjectをVBScriptまたはVBAで操作する
https://qiita.com/mima_ita/items/3020a025d5cb5858c4bc

ただし、PowerShellやC#などの.NET経由でのCOM操作を行う場合、解放処理が重要になります。

.NETを使ったOfficeの自動化が面倒なはずがない―そう考えていた時期が俺にもありました。
https://qiita.com/mima_ita/items/aa811423d8c4410eca71

上記の記事でも触れていますが、.NETでの解放処理が面倒な場合、NetOfficeというMIT Licenseのライブラリについての採用を検討してください。OfficeのCOMオブジェクトをラッパーしています。
https://github.com/NetOfficeFw/NetOffice

OfficeのCOM操作時のマルチスレッドについて

色々なプログラムからOfficeを操作可能となると、マルチスレッドで動かしたくなる場合があります。
しかし、無駄なのでやめましょう。
Officeのオブジェクトモデルはスレッドセーフでなく、同時呼び出しをシリアル化するためのメカニズムが動いています。つまり、２つのスレッドから同時にOfficeのオブジェクトを操作しても、どちらかの処理が動いているだけです。

スレッドの Office でのサポート
https://docs.microsoft.com/ja-jp/visualstudio/vsto/threading-support-in-office?redirectedfrom=MSDN&view=vs-2019

Webアプリケーションを自動化しよう

ホームページにアクセスにてなんや、かんや自動化したいという話ですが、最近以下にまとめましたので参照してください。

Webアプリケーションを自動で操作してみよう
https://qiita.com/mima_ita/items/4149a4cdb9a33084258b

Windowsの画面操作を自動化しよう

画面操作を自動化する前にコマンドラインでやりたいことが実現できないか、あるいはアプリケーションがプログラム可能なライブラリを提供していないか確認してください。たとえばWinSCPはWinSCPnet.dllを利用することでC#やPowerShellからWinSCPの操作が可能になっています。

これらを確認した上で初めて画面の自動操作のスクリプトについて考えましょう。

多くの場合、以下で紹介したいずれかのケースで上手くいきます。

RPA九人衆による「ｱｶﾈﾁｬﾝｶﾜｲｲﾔｯﾀ」の自動化
https://qiita.com/mima_ita/items/d4655de865f30bb51c65

操作したいコントロールの特定方法

画面の自動化を行う場合、なんらかの方法で画面上のコントロールを特定する必要があります。

たとえば電卓アプリで「÷」キーを特定する方法を考えてみましょう。

座標で特定する方法

もっとも簡単な方法はコントロールの座標で特定する方法です。

この方法は簡単に、そして多くのツールで行える方法ですが、安定しません。
たとえば、ウィンドウの位置が変更されたり、サイズが変更されたりしただけで容易に破綻します。

もし安定した画面操作の自動化スクリプトを記述する場合、座標で特定する方法はなるべく避けてください。

オブジェクトで特定する方法

Windowsアプリの多くはInspectなどで表示されるようなオブジェクトの構造をもっています。
たとえば電卓の例だと以下のようにNameとControlTypeを指定して特定のオブジェクトを検出が可能です。

この方法が最も安定した画面の自動操作を実現しますが、常に使用できるとは限りません。
アプリケーションの作り方と使用した技術しだいでは検出できないコントロールが存在したり、そもそもゲームのようにボタンとかを独自に描画している場合は検出不能です。

UiAutomation、WinAppDriver、Friendly、UWSC、UiPAthなどでサポートしている検出方法です。

なお、JavaのSwingアプリケーションでオブジェクトを特定したい場合は「Javaで作った画面をWindowsで自動操作する方法」をElectronでオブジェクトを特定したい場合は「Electronで作った画面の自動操作」をそれぞれ参照してください。

テンプレートの画像を指定して特定する方法

テンプレートの画像と一致する箇所をWindowsデスクトップ全体から検出します。
たとえ、オブジェクトが検出できない状況下でも画像でコントロールを見つけて検出が可能です。半面、画像でおこなっているため、色合いや画面のサイズなどによって影響を受けて安定して動作しなくなるケースも多いです。

UWSC、UiPAth、sikulix、PyAutoGuiでサポートしている機能です。

OpenCVのライブラリを使用することで、このあたりの機能は自作も可能です。

C#やPowerShellで画面上の特定の画像の位置をクリックする方法
https://qiita.com/mima_ita/items/f7d2c38767bda8b35cbd

どの技術を採用すべきか？

一番最初は「オブジェクトで特定する方法」が可能か検討してください。
そして、実現できないと判断した場合に「テンプレートの画像を指定して特定する方法」を使用しましょう。

オブジェクトで特定する方法の技術比較

UWSCは優れたツールですが、公式ページが消えたので今後は使用しない方がいいです。

WinAppDriverはSeleniumと同じインターフェイスで操作できるため、Seleniumになれている場合は採用を検討しましょう。ただし、Windows10でないと動作しません。

UiAutomationは、どの環境下でも画面の自動操作が行えます。多くの場合はこれで十分でしょう。

UiPAthはオブジェクトでの特定と画像認識での特定の両方が可能であるため、一つ覚えれば全て済むという強みがあります。ただし本格的に使う場合はかなりのお値段となります。

Friendlyは、この中では特殊です。自動操作のためにDLLをインジェクションするため、落としていいプロセスか、DLLをインジェクションしてかまわないかどうかで使用の判断がわかれます。逆にそのハードルを越えた場合、基本的にどんなオブジェクトでも特定したり、必要に応じて画面操作を無視して関数を実行したりできます。※ただし.NET Frameworkで動く画面に限ります。

画像で特定する方法の技術比較

UWSCは優れたツールですが、公式ページが消えたので今後は使用しない方がいいです。

Sikulix1.1.4を使って画面の自動操作をする方法はIDEも使い易く自動操作をサポートするための機能を多数有しておりおすすめです。

1.1.4時点の機能は下記にまとめています。

Sikulix1.1.4を使って画面の自動操作をする
https://qiita.com/mima_ita/items/8f653042ac9140e5023f

問題がでるとしたら、Java8SDKの64bitが必要であり環境を選ぶことと、使用しているPythonがJythonのため純粋なPythonではない点です。
純粋なPythonで自動操作をしたい場合はPyAutoGuiを採用するといいでしょう。

安定した画面操作の自動スクリプトを書くために

環境を特定する

OSやハードウェアの構成は無論のこと、ディスクトップの色や解像度の設定も指定した上で、他のアプケーションを動かさずに自動操作を行えるようにします。

並行して別の作業を行わないというのは結構重要になります。
たとえば、自動処理中にユーザーがうっかりマウスを移動させたりしただけで、後続の処理が動作しなかったり、裏で別のアプリケーションが動作していてそれが干渉しあって動作しなくなったりまします。
（たとえば一部の自動操作ツールはテキストの入力にクリップボードを使用するケースがあり、当然、この場合、コンピュータ上の別のアプリケーションまたは操作でクリップボードを使用すると正常に動作しなくなる場合がでてきます。）

安易なSleepを使用しない。

たとえば、ボタン押下で画面の切り替わりを待って、表示された新しいコントロールの内容を取得する例を考えてみましょう。

簡単にやろうとすると、ボタン押下後、2秒Sleepとかの処理をいれてしまします。
これを行うと安定しません。

安定したスクリプトを書くには定期的に新しいコントロールの取得を試みる処理をいれるようにすべきです。
UiPathやSikulixは要素が表示するまで待つとかの機能がありますが、もしUiAutomationを使用して自作する場合は以下のコードを参考にしてみてください。

    public static AutomationElement ChildWindowByTitle(AutomationElement parent , string title) {
        try {
            PropertyCondition cond = new PropertyCondition(AutomationElement.NameProperty, title);
            return parent.FindFirst(TreeScope.Children, cond);
        } catch {
            return null;
        }
    }

    public static AutomationElement WaitChildWindowByTitle(AutomationElement parent, string title, int timeout = 10) {
        DateTime start = DateTime.Now;
        while (true) {
            AutomationElement ret = ChildWindowByTitle(parent, title);
            if (ret != null) {
                return ret;
            }
            TimeSpan ts = DateTime.Now - start;
            if (ts.TotalSeconds > timeout) {
               return null;
            }
            System.Threading.Thread.Sleep(100);
        }
    }

この例ではボタン押下後に特定のタイトルのウィンドウが表示するまで待機して、タイムアウトがでたらエラー、それまでに取得できたら後続の処理をおこなっています。

決してユーザーの操作と同一でないことを忘れない

UiPathなどはドライバからイベントを発生させてユーザの操作に似せようとしていますが、多くの場合、完全にユーザの操作と同一になっているわけでなく無理やり通している面があります。
このため、アプリケーションの作り方次第では、手動操作と異なる挙動をするケースがあります。

たとえば、テキストの値をUiAutomationで設定した場合を考えてみましょう。
もし、そのコントロールでキーボード操作のイベントで何らかの処理していたり、フォーカスの移動で何らかの処理をしていたりする場合、結果が同じにならない場合があります。

この場合は、クリックしてからテキストを設定したり、オブジェクトの値を更新するのでなく、System.Windows.Forms.SendKeys.SendWaitを使用してキーボード操作を真似する必要があります。
もしかすると、手動入力のタイミングにあわせるためSleepを使用する必要がでてくるかもしれません。

その他自動操作の話

タスクスケジューラ―を使いこなそう。

タスクバーにてtaskschdと入力することでタスクスケジューラ―が起動します。

定期的に実行する処理を指定できます。
タスクスケジューラのもっとも強力な機能として管理者権限で動作が可能になることです。
これにより、管理者権限が必要な自動操作も可能になります。

たとえ途中で再起動と管理者権限が必要でも、自動化をあきらめたらそこで試合終了ですよ…？
https://qiita.com/mima_ita/items/71ee76ab6d14a726f9f4

なお、タスクスケジューラ―はコマンドプロンプトから操作することが可能になっています。

まくまくWindowsノート Windows で任意のコマンド（タスク）を自動実行する (schtasks)
https://maku77.github.io/windows/admin/schtasks.html

リモートコンピュータとの連携

リモートコンピュータと連携して実現する方法は以下のページにまとめがあります。

別端末(Windows)のプログラムを標準機能でリモート起動する方法まとめ
https://qiita.com/0829/items/5518256b348521ac358c

管理者権限が必要ならschtasks (タスクスケジューラ)、PowerShell等でそのまま操作したければPowerShellからWinRMを利用する方法が楽そうに見えます。

その他に、私が実際やった方法としてはHTTPサーバーを立ててクライアントからアクセスがあったらクエリパラメータで指定したコマンドを実行するというセキュリティがガバガバなことをやっていました。いまやるなら、Jenkinsなどを利用してスクリプトを動かすようにすると思います。

よくある問題

予算がおりて〇〇というRPAツール導入したから、今後はこれを使って自動化するように

自動操作の種類によって、向き不向きがあります。
たとえば、Excelの内容を抽出してファイルに保存するという処理はUiPathを使用するよりVBSなどで書いた方が早くて正確です。

適切な方法を選択するようにしましょう。

RPAツールを使わないと上司に怒られるので、どんな処理でもRPAツールを使わないとだめなんだよー

背景をちゃんとききましょう。
おそらく、RPAツールで行うことで、シナリオの配布やスケジュール実行の管理が楽になるために、RPAツール使えと言っているのだと思います。
たとえばUiPathの場合は以下のようなことができます。

Uipath　Orchestratorの6種類のできること

この場合、処理のメイン自体はVBSやPowerShellで書いちゃいましょう。そして、UiPathからPowerShellの実行等のアクティビティを利用して起動しましょう。

なお、特に理由がなく、上司がRPAツールに興奮を覚えるだけの紳士なだけだった場合の時は、我慢するか、できないなら辞めたほうがいいです。

このOSは出来損ないだ初期状態でPowerShellが使えないよ。

どういう状況かをいっているかわからないので認識があっているかわかりませんが、初期状態でPowershellのスクリプトが実行ポリシーの問題で実行できなくて、かつ管理者権限がなくて変更できない状態を指していると仮定します。

上記のページにあるようにExecutionPolicyを指定して実行してください。これには管理者権限は不要です。

powershell -ExecutionPolicy RemoteSigned .\test.ps1

なぜか自動化できる人材がいません

お野菜は勝手に生えてきませんし、人材は畑で採れません。自動化してくれる人材は勝手に生えてこないので、教育期間を確保するか、高い金払って外部から雇いましょう。

××ツールを使えば誰でも簡単に自動化ってできるものなの？

私は懐疑的です。
おそらく、「安定しない、保守コストの高い自動スクリプト」は「誰でも簡単」に作れる可能性はあります。

すくなくともWebアプリケーションを動かすならWebアプリケーションの開発経験者を、Windowsアプリケーションを動かすならWindowsアプリケーション開発経験者を一人は確保しておいたほうがいいでしょう。この場合、誰でも簡単にできる箇所とできない箇所を分けて仕事を割り当てた方がいいでしょう。

〇〇ツールがなくて自動化できません。

今までで説明した通り、初期状態のWindowsの環境でも色々自動化が可能です。
その実績や信頼をもって、〇〇ツール導入の交渉にあたりましょう。

実績や信頼もないのに、多くを望むのは無理です。できるところから頑張りましょう。

なにから自動化したらいいかわかりません。

費用対効果の高いところを選んでやりましょう。

費用が安く済むのは画面操作が不要で、コマンドラインから処理ができるものです。
たとえばファイルの拡張子を一律変更するとか、ExcelのC5セルに今日の日付を入れるとかになります。

ここで条件が入ると徐々に費用が高くなります。
たとえば、Aから始まるファイル名だけ変更するとか、Aから始まって日付が今日以降のExcelを開いてC5のセルを変更するとかの場合です。

効果があるというのはどういうものでしょうか？

まず作業量的な観点があります。
たとえば、先のファイル拡張子の変更が1ファイルだけなら自動化の効果は薄いですが、1000ファイルあったら効果は高くなったといえるでしょう。

次に質的な観点があります。
たとえば、ExcelのセルC5に今日の日付を入れるという作業があり、そのセルの周辺に似たような入力項目があるとします。
人が手でやる場合、まちがってB5に入れてしまうかもしれません。
自動でやればそのようなミスはなくなります。こういった作業の品質を高くしたい場合にも効果があると言えるでしょう。

そもそも〇〇使っているから悪い、全部変えちゃおう！

〇〇にOS名やアプリケーション名など好きなのをいれてくださって構いません。
その上で、一気に全部変えるという戦略はお勧めしません。

現状のシステムで動いているものがあり、そのシステムを使う関係者が大勢いる場合、調整するのに非常に力が要ります。
そもそも、どんな状況にせよ現状の状態は、それなりの理由があって現状の状態になっているわけで、抜本的な改革とかグレートリセットなどを、周りの合意が取れずにやるのは無謀です。
小さいところから始めていきましょう。

せっかく作った自動化スクリプトが動かなくなった

アプリケーションのバージョンアップやWindowsアップデートでよく発生します。
なので、作成した自動化スクリプトの管理方法については考えておきましょう。

１度動かせばすむスクリプトなのか、定期的に動かすスクリプトなのかによって、スクリプトの管理方法が変わります。
定期的に動かすスクリプトの場合、常にバージョンアップ等で動作しなくなるというリスクがあります。
このリスクをどう扱うか考えましょう。

たとえば、実際やってエラーとなった時点で修正する時間的余裕のあるものであれば、その時に考えればいいでしょう。
しかし、そういう時間的余裕が確保できないようなスクリプトの場合は、事前にそれを検出する必要があります。
定期的にスモークテストを行う計画を立てるか、アプリケーションのリリースノートをチェックする工数をとるか、いずれにせよなんらかの対策をとりましょう。

自動化自体は簡単なのですが、保守的な組織なため導入に消極的です

おそらく作業品質が問題になっていると思います。
こういった保守的な組織でよく利用した手法は手動と自動をしばらく並行で動かして、周りが納得がいったら自動に切り替えるという方法です。

たとえば面倒な操作を色々してExcelを作成するという業務があったとします。
しばらくは、「面倒な操作」を自動でも、手動でもやって、Excelを作成します。その結果を比較し続けて、周りの合意がとれたら手動をやらなくするという方法です。

自動化する時間がありません

管理者の場合は、ちゃんと確保するようにスケジュールを立てましょう。

ちゃんとした組織の作業者の場合は、管理者に自分の案を説明して相談しましょう。
ちゃんとしない組織でかつ通常作業が平均より早い自信のある方は、見積もりにコッソリのせてダマで作りましょう。
だいたい動くものを作ると黙らせることができます。

この辺の立ち回りとしてはJoel on softwareの以下の記事が参考になります。

下っ端でも何かを成し遂げる方法
http://web.archive.org/web/20170625093906/http://japanese.joelonsoftware.com/Articles/GettingThingsDoneWhenYour.html

あなたは管理する立場にいなくとも、ものごとを改善することはできる。しかしあなたはシーザーの妻である必要がある: 疑惑を招いてはならない。そうでなければあなたは敵を作るだけだろう。

ある業務が自動化できれば、時間的余裕ができて、別の業務を自動化するという好循環がつづきます。
完全で完璧な状況は作れませんが、あきらめなければ少しづつ改善していくことはできると思います

せっかく自動化して改善したのにあんまり喜ばれません

色々理由があります。

１つ目は自動化すべきでないときに自動化してしまった時です。
たとえば、緊急の障害票がたまっているときに、優先度の低い業務を自動化しましたとか言われてもうれしくないでしょう。

２つ目は自動化することで、他人の仕事を奪ってしまったケースです。
環境によっては、余剰人員対策のためにマクロで実行すればすぐ終わるような作業があったりします。そこを空気を読まずに自動化してしまうと、上の人は新しい仕事を考える必要がでてきてあんまりうれしくないです。

３つ目は改善前の苦労を誰もわかっていなかったので、それが改善されたところで興味がないケースです。
そして、このケースが多いです。
このケースの場合は、他人に評価されようとかいうの余分な感情…いわば贅肉を奥にしまって、プロジェクトやシステムに対してなすべきことをなすようにしましょう。