PADに移行したのに、結局JavaScriptを書いた話

GASをやめた理由は「保守」

これまで自動化はGAS（Google Apps Script）を中心に進めてきました。Google環境なら処理も速く、GASが悪かったわけではありません。

一番の理由は、**「この先、誰が直すのか」**です。

事務方にとってJavaScriptは難解です。取引先のシステムに仕様変更が入ったとき、コードを直せる人がいない職場に、JavaScriptの修正を前提にした仕組みを残すのは、少し怖いと感じました。

そこで、PAD（Power Automate for desktop）への移行を始めました。

ブラウザ操作をノーコードで組めるので、ドキュメントさえしっかり作れば、事務方でも多少の仕様変更には対応できるはずだと考えたのです。

順調だった前半

今回作っているのは、EDIからデータを抽出してExcelに転記する作業を繰り返すフローです。

EDIは取引先のシステムなので、仕様変更はこちらの都合とは関係なく起こり得ます。だからこそ、事務方が直せる形にしておく必要があります。

流れはこうです。

1. ログイン

2. 対象項目のリストを表示

3. リストを取得

4. 1件ずつ画面遷移

ここまでは順調でした。

壁：ヘッダーしか取れない

PADのWebページからデータを抽出する機能を使えば、目的の表も当然取れると思っていました。

ところが、取れたのはヘッダーだけ。何度やっても、肝心のデータ行が取れません。

しかも今回の表は、単純なExcelのような表ではありませんでした。

• 行数が固定ではない（可変長）

• 1件のデータが2行で一組になっている

Geminiに相談すると、いろいろな方法を提案してくれます。しかし、どれもうまくいきません。

モデルを上げて聞き直したところ、返ってきたのは、

「この表はPADのアクションでは抽出できない」

という答えでした。

少し、がっくりしました。

結局、JavaScriptで解決

そこでGeminiが提案してきたのが、PADのフローにJavaScriptを組み込む方法でした。

「もう、動けばいい」

そんな気持ちで、あれこれ試しました。

そして、ついに表を抽出できました。

動きました。これで先に進めます。

……と思ったのですが。

「PADにした意味は？」

やっと前に進んだと思った直後、葛藤が始まりました。

「JavaScriptを使わないために、PADにしたのではなかったのか」

とはいえ、動かなければ意味がありません。

今回はこれで行くしかない。そう腹をくくりました。

そこで考えた、ノーコードの意味

少し冷静になって考えてみると、これは「PADへの移行は失敗だった」という話ではないと思うようになりました。

むしろ、考え方を変える必要があるのかもしれません。

例えば、今回のフローならこうです。

事務方が変更できる部分
ログイン → 対象データ選択 → 対象期間の変更 → Excelへの保存 → エラー時の処理

技術者が変更する部分
Webページ内の特殊な表をJavaScriptで解析する処理

この構造にしておけば、事務方はJavaScriptを触らなくても日常の運用ができます。

私は、ノーコードの目的は「コードをゼロにすること」ではないのではないかと思います。

「コードを書けない人でも、日常の運用を回せる状態を作ること」

これが、今回PADを使ってみて考えるようになったことです。

JavaScript部分の引き継ぎ方針

そのうえで、埋め込んだJavaScriptは、**「事務方が編集するものではない技術部品」**として扱うことにします。

PAD側には、このような注意書きを残します。

JavaScript側にも、コメントで理由を残します。

// EDIの詳細画面にある「2行1組」のデータを取得する処理。
// EDI側の画面構造が変更された場合は、この処理の見直しが必要。

こうしておけば、少なくとも「何のために、このJavaScriptがあるのか分からない」という状態は避けられます。

完全に属人化をなくせるわけではありません。それでも、「管理すべき技術部品」として切り分けることはできます。

そしてEDIの画面が変わったときには、事務方が無理にJavaScriptを直すのではなく、

「ここは技術者に相談する部分だ」

と判断できるようにしておく。それも、保守しやすい仕組みの一つなのだと思います。

ノーコードの線引きはどこにあるのか

今回の経験で、最初に考えていた「ノーコードなら事務方でも保守できる」という考え方が、少し変わりました。

ノーコードにすること自体が目的ではない。

誰が、どこまで保守できればいいのか。そこから逆算して、ノーコードとコードの境界を決める。

そんな考え方も必要なのではないかと思っています。

ただ、まだ自分の中でも明確な答えが出ているわけではありません。

今回のフローを実際に運用しながら、どこまでを事務方に任せ、どこからを技術者に任せるのがよいのか、試していきたいと思います。

皆さんの現場では？

そこで気になっているのが、ノーコードの線引きです。

• 「ここまではノーコード、ここから先はコード」という判断を、どこでしていますか？

• コードを書けない人が保守することを前提にした場合、どのように引き継いでいますか？

PADに限らず、RPA、GAS、VBAなどをお使いの方の経験も聞いてみたいです。

同じような経験があれば、ぜひコメントで教えてください。

ここまで読んでいただき、ありがとうございます。

もし、この記事に出てきたような
「業務をもっと効率化したい」
「AIを使ってみたいけれど、どこから始めればいいかわからない」
「自動化したいけれど、自社の業務にどう当てはめればいいかわからない」
そんな悩みをお持ちでしたら、一度お話ししてみませんか。

初回相談は無料です。
「こんなことでも相談していいのかな？」という段階でも大丈夫です。
→ AI×業務改善、何をお手伝いできるか

もっと気軽に。
フォロー・スキ・コメントをいただけると、次の記事を書く励みになります。

カネミツ・ソリューションズ合同会社
代表社員 熊井光文
→ 会社HP：AI×コンサルティング事業

→ Im Mate両面ディスプレイ型 AI 自動翻訳機

#生成AI #業務改善 #DX #GoogleAppsScript #AI活用 #中小企業