COLUMN

PythonやAIでExcelを自動化する前に|
VBAを禁止したら、
もっと直せなくなった話

「PythonでExcelを自動化します」「AIにExcelを作らせます」——こうした話をここ1〜2年でよく聞くようになりました。実際、その多くはうまくいきます。動くものがすぐにでき、手作業が確かに減ります。この記事は、それをやめたほうがいいという話ではありません。問題が出るのは、もう少し先です。作った人が、いなくなってから。

中川 知裕
中川 知裕RECOG 代表社員(元証券アナリスト・宅地建物取引士)

便利な仕組みができて、そして直せなくなった

これから書くのは私の体験談ですが、どこの会社でも起こりうる話だと思います。

ITに詳しい社員が、業務の根幹になる資料をExcelで作っていました。定期的に更新する必要があるため、効率化のためにVBAを活用した仕組みを完成させました。誰でもボタンを押せば、データ取得から難解な計算まで自動で行ってくれる。大幅な業務改善でした。これは評価されるべき仕事です。実際に効果が出たので、この手のExcelが社内で多く作られました。

問題はその後です。

その社員が、人事異動でいなくなりました。しばらくして、データの取得方法が変わりました。Excelのバージョンが上がって、VBAが動かなくなったものもありました。しかし、後任者は中身を理解していないので、直すことができません。

そこで、IT担当部署に直してもらおうとします。ところが今度は、IT担当部署のほうが業務内容に詳しくありません。

直せないのではなく、「何を直せばいいか」を聞き出すのに何ヶ月もかかる

ここが、外から見ていると見落とされるところです。技術的に難しくて直せないのではありません。1つのワークブックのヒアリングに、何ヶ月もかかってしまうのです。

この列の数字はどこから来るのか。なぜこの行だけ計算から外しているのか。この例外処理は、どの取引先のどんな事情に対応したものなのか。——作った本人がいれば一言で済むことです。それを業務の分からない人が、業務で手一杯の現場から少しずつ聞き出していくことになります。

そしてその間、業務は手計算に戻っています。ボタン1つで終わっていた作業が、毎月まるごと人の手に返ってきます。現場は何も悪いことをしていないのに、以前より苦しい状態で待たされます。

結局、個人が勝手に開発したアプリは会社全体で認知されないため、知の共有に繋がらず引き継ぎもできない——そういう結論に達しました。そして、その犯人とされたVBAの使用が禁止されました。

「その手前まで」を形にした見本があります

勤怠と有給の管理をExcelでどこまでやれるのか、関数だけで組んだ見本を置いています。ダウンロードにメールアドレスは要りません。
ただし、これは「Excelで十分です」という意味ではありません。最後のシートは「このシートが苦しくなるとき」です。どれだけ作り込んでも、その先で苦しくなります。その境目のほうこそ、実物で確かめていただくための見本です。

勤怠・有給管理表(Excel・約1MB) 見本としてお使いいただけるよう作っていますが、就業規則や法令の当てはまり方は会社ごとに違います。お使いになった結果について、RECOG は責任を負いかねます。

禁止したら、もっと直せなくなった

ここから先が、この記事でいちばんお伝えしたいところです。

取り上げられた現場は、人を増やして残業した

便利なツールを取り上げられた現場は、業務時間が爆増します。データ入力のために派遣社員を採用したところもあれば、残業時間が大幅に増えたところもあります。現場は疲弊します。

禁止を決めた側に、悪意はありません。引き継げないものをこれ以上増やさないための、筋の通った判断です。ただ、仕事の量は1つも減らないまま、やり方だけが昔に戻りました。

次に出てきたのは、関数の絡み合いだった

そこで、新たにITに詳しい社員が知恵を絞ります。VBAがダメなら、Excelの関数を駆使して計算すればいいじゃない——そういうことになります。

VLOOKUP、INDIRECT、配列数式などで計算した結果をピボットテーブルで表示する、そういうExcelが登場します。禁止には触れていません。誰もルールを破っていません。そして作った当初は、これで業務が楽になると思われました。

VBAには手順が残っていた。関数の絡み合いには、それすらない

ところが、です。

エクセルはVBAと違って、計算手順を記録しませんから、時間と共に作った本人さえ修正できなくなります。

この差は、思われているよりずっと大きいものです。VBAのコードは、読みにくくはあっても「何をどの順番でやっているか」が文字で、上から下へ残っています。読める人を連れてくれば、時間はかかっても追えます。

関数には、それがありません。セルに入っているのは結果を出すための式だけで、処理の順番はシートのあちこちに散らばり、どこから読み始めればいいのかが分かりません。INDIRECTで組み立てられた参照先は、開いて眺めても追えません。なぜその計算なのかは、どこにも書かれていないのです。

だから、半年後に自分が作ったものを開いた本人が、手を出せなくなります。属人化は解決していません。引き継げる相手が、一人から零人になっただけです。

そして、よく知られた問題があちこちで発生しました。開くだけで数分待つようになり、前任者しか分からないものが増え、同じファイルの違うバージョンがいくつもできる。どれも、この経過の先で起きたことです。

犯人とされたのは、道具のほうでした

振り返ると、診断が1つ間違っていました。

引き継げない原因はVBAだとされ、VBAが禁止されました。しかし道具を取り上げても、同じことが別の形で起きました。本当の原因は道具ではなく、一人で作って、一人で抱えた作り方のほうだったからです。

作った人が悪いのでもありません。目の前の苦痛から抜け出すために、自分の担当部分を自動化しただけです。それを一人の仕事のままにしておいた、という一点が残ります。

属人化そのものがどういう状態を指すのかは、Excel業務の「属人化」とは?放置するリスクと対策に書きました。

AIでも、同じことが起きます

いま起きているのは、AIの限界ではなく、頼んでいる範囲が小さすぎることです

今のAI活用も、ほとんどが使っているExcelの自動実行に留まっていると思われます。作業を書き出して渡せば、動くものが返ってきます。実際に手は速くなります。

ただ、形を見るとやっていることはVBAのときと同じです。現場の人が、自分の担当する範囲だけを自動化している。チーム全体で設計するならまだ良いのですが、多くは個人のレベルで作られます。

これは、AIにそれしかできないという話ではありません。頼んでいる範囲が、担当者一人の机の上に収まっているという話です。AIの側はもっと広い相談に応えられるのに、こちらが用意している問いが、月末の1つの表に閉じています。

ここははっきり書いておきます。問題にしているのは、AIを入れることではありません。属人化を助長する入れ方のほうです。一人が自分の手元を速くするためだけに使えば、読めないものが増えます。何を持っていて何を数えているのかを決めてから使えば、同じ道具が会社の資産になります。分かれ目は道具の側ではなく、入れ方の側にあります。

しかも、頼んだ本人も読めない

VBAのときは、少なくとも書いた本人には読めました。AIに作らせたものは、頼んだ本人が最初から読めません。動いているかどうかは結果を見れば分かりますが、どういう考えでその形になったのかは、頼んだ人の中にも残っていません。

関数の絡み合いで起きたことが、作り始めた初日から起きている、と言い換えてもいいと思います。

速く作れるぶん、増えるのも速い

VBAの仕組みが社内に広がるには、何年かかかりました。いまは数日です。便利なものが増える速さと、理由の分からないものが増える速さは、同じ速さです。片方だけを速くすることはできません。

AIは、人間が説明できることしか解決してくれません

問題の根幹は、現場の判断で会社全体のことを考えずに開発が進んだことだと考えています。現場としては、目の前の苦痛から抜け出したいので、自分の担当部分の自動化だけを考えます。それは当然のことで、責められることではありません。

組織全体の資源を有効に活用し、データベースと計算部分をしっかりと設計しないと、会社の資産とはなりません。そしてそこは、現場の業務を理解できるエンジニアがいないと解決できないことだと考えています。

RECOGの主張

ITに詳しくない人ほど、AIを使えば何でもできると考えています。しかし、AIは人間が説明できることしか解決してくれません。業務とITの知識の両方を備えていないと、期待する解決方法には到達できないのです。

これはAIの欠陥ではありません。こちら側の、設計の責任です。何を持っていて、どう数えていて、どこが例外なのか——それを人の外に出して説明できる形にするのは、道具ではなく人の仕事です。説明できる形になっていれば、AIはそこから先をとても速く運んでくれます。

ですので、AIを入れるかどうかで迷う必要はないと考えています。見ておきたいのは、入れる前に「何を持っていて、どう数えているか」が人の外に書き出せているかどうかです。そこさえ決まっていれば、載せる道具はあとから選べますし、入れ替えもできます。決まっていなければ、どの道具で作っても、作った人の頭の中がそのまま仕様になります。

企業のAI導入そのものについては、改めて書くつもりです。この記事は、その手前にある話として読んでいただければと思います。

よくある質問

PythonやAIでExcelを自動化するのは、やめたほうがいいですか?
やめたほうがいいという話ではありません。道具に問題はなく、どちらも実際に効果が出ます。この記事で書いたのは、担当者が一人で作って一人で抱えた結果、その人がいなくなった時点で直せなくなるという作り方の問題です。同じ作り方のまま道具だけ新しくすると、同じところで詰まります。逆に、何を持っていて何を計算しているのかが人の外に残る形なら、PythonでもAIでも構いません。
VBAは使わないほうがいいですか?
そうは考えていません。この記事で書いたのは、VBAを禁止した側がそのあと、もっと直せない状態になったという経過です。VBAには少なくとも、何をどの順番でやっているかが文字で残っていました。禁止したあとに出てきた関数とピボットテーブルの組み合わせには、それが残りません。動いていて、直せる人がいるなら、VBAで困ることはありません。
AIに作らせたものが、なぜ後から直せなくなるのですか?
AIの性能の問題ではありません。頼んだ側が、なぜその計算なのかを説明していないからです。できあがったものには結果だけが入っていて、その業務でなぜその順番なのか、なぜその例外を飛ばすのかという理由はどこにも残りません。しかも短時間で作れるので、理由の分からないものが増える速さが以前より上がります。
何から手をつければいいですか?
作る前に、何を持っているか(データ)と、どう数えているか(計算の定義)を人の外に書き出すところからです。これは道具を決める前の作業で、Excelのままでもできます。ここが決まっていれば、あとからPythonでもAIでも既製のツールでも載せ替えられます。決まっていないと、どの道具で作っても作った人の頭の中が仕様になります。

「うちのExcel、引き継げる形になっている?」

30分の無料オンライン相談で、いまお使いのExcelを見ながら、何を持っていてどう数えているかが人の外に残っているかを一緒に見ます。すでにAIで自動化を始めているところでも構いません。いまのままで十分なら、そうお伝えします。売り込みはしません。

無料オンライン相談を予約する
新しい記事をLINEで受け取る

月1〜2回、Mlog の4コマとガイド記事の更新をお知らせします。お送りするのは記事のお知らせだけです。

LINEで友だち追加