「ボタンをポチッとやったら処理が終わるようなマクロ、作ってくれないか?」


Excelマクロ開発において非常によくある発注時の光景であるが、こういう発注の仕方をされると、正直、悩んでしまう。

ボタンにマクロを仕込むのは何も難しいことではない。僕が抵抗を覚えるのはそこじゃない。


他人のためのマクロを作るとき僕が一番に考えるのは、「できたマクロを現場の人がどのように使うのか」である。

仮にぼくが「ボタンポチッ」マクロを組んだとしよう。

ぼくは発注者にマクロを渡す。

それを発注者は「実際に使う人」に渡す。「実際に使う人」は発注者とは別の人であるのが大半だ。実際に使うのは現場の人間であり、「指示を受ける」側である。

マクロの使い方を、発注者は現場の人間にこう説明するだろう、「このボタンを押せばいいから」と。


「ボタンを押せばいいから」。発注者はおそらく、というかほぼ間違いなく、こう説明する。そこには、「ボタンを押せば作業が完了します。ボタンひとつであんな作業やこんな作業が自動化されて、ラクになるでしょ?」という意味以上に、「それ以上のことをオレに聞いてくれるな」ということが含意されている。

それは、発注者がプログラムの内容をわかってないからかもしれないし、それ以上のコミュニケーションを現場の人間と取りたくないからかもしれないし、その両方かもしれない。

発注者がプログラムをわかっていないケースというのはもうたいていがそうなのであまり気にしないのだが(そもそも発注者が「わかってる」人なら、ぼくは何も心配しないだろう)、それ以上に、ていねいに教えたがらない人というのは意外に多い。細かい内容について質問すると露骨に嫌な顔をされることも多い。「わかってない」ことが露呈するのが嫌なのか、それとも現場の人間と話をするのを「時間の無駄」とでも考えているのだろうか。
いずれにせよ、現場の人間は言われるまま、ただボタンを押すだけだ。そこに創意や工夫はない。


「マクロを作ってくれ」と言われても、ぼくはそれだけでいいとは思ってない。
せっかくマクロを作っても、仕様変更があったらかんたんにマクロが動かなくなるからだ。例えば、ベースとなるExcelの列が追加されたり、項目名が変更されたり。Excelは定義がガチガチでない分、そういうことがかんたんにできてしまう。しかし、それをやられると、たいていのマクロはうまくいかなくなる。そうするとまたぼくが呼び出され、別にぼくが動く分には良いのだけどその分追加費用がかかっちゃうし(ちゃんと請求します)、何よりマクロが動かないあいだは現場が止まってしまう。

それはあなたの会社にとって困るでしょう、と。

だからぼくはまず最初に、手作業でなんとかする方法をマニュアルにして渡す。なんなら現場に行って教えるところまでやる。そのうえで、便利ツールとしてマクロ「も」渡す。もちろんマクロの使い方も教える。

手作業なら、多少の仕様変更があっても対応できる。アドリブが効くのが手作業最大の利点だ。一番悲惨なのは「マクロに完全に依存してる現場で、そのマクロが動かなくなった状況」で、現場はボタンポチッに慣れ切ってしまって知見がないから、もう詰み確定である。でも、もし現場が手作業でのやり方を知ってさえいれば、なんとかなる。
結局、一番大事なのは「人」だ。

だからぼくは、「手作業でなんとかする方法マニュアル」を作るし、積極的に教えるし、ついでにマクロも作る(現場の人にラクしてほしいから)。ここまでがぼくの提供する商品であり、基本的にワンセットである。

マクロをボタンに仕込むということも、積極的なオーダーがないかぎり、あまりやらない。「開発」タブから使ってもらうやり方で動かしてもらうことがほとんどである。手順さえ知っていればボタンを使うのとあまり手間は変わらないし、それは何より「ボタンを押すだけ」という手軽さの裏にある怠惰な精神へのせめてもの抵抗だったりする(オーダーがあればもちろんボタン作るけど)。もちろん「開発」タブを使ったことのない人には使い方を教える。「開発」が表示されていないなら表示の仕方も教えるし(そもそも初期状態では表示されてなかったりする)、何ならそこまでの手順だってパワポにまとめたってよい。

作るマクロも、あえて柔軟なもの、こっちがコントロールできる余地を残したものにすることが多い。
ぼくは「選択した列に対して処理をする」みたいな、ふつうに考えると現場作業者の手間が一つ増えるようなマクロを組むことが多いのだけれど、それは、現場でマクロを使っていて「(元々の仕様範囲を越えて)この範囲に対してだけでなく、あっちの列に対しても処理したい」といったよくある事態を吸収するためである。あるいは、エラー文字チェックみたいなマクロであれば、エラー文字がかんたんに追加できるようにあえてしておく。それは、仕事をしていくなかで、当初想定していたものからエラー文字の種類がどんどん増えていくことの方が多いからである(たいていのマクロ制作者は逆に、そこをいじれないようにするケースが多い)。もちろんソースコードにパスをかけるなんてケチなことはしない。もし「ソースコード勝手にいじってわけわかんなくなっちゃった」ってなっても、ぼくの手元に元データがあるんだから言ってくれればまた渡します。ぼくが作るマクロは、あえてちょっとアナログ要素を残してあるから人によっては不便に感じるかもしれないのだけど、おおむね好評。


こういうぼくの考え方を、「サービス」ととらえるか、「時間のムダ」ととらえるか。

人によっては、「言われたことだけさっさとやれよ、お願いしたマクロをさっさと作れよ」となるかもしれない。
そういう人とは「ああ、考え方がちがうんだな」と思う。
そして、ほんとうに失礼な言い方になるが、「別の人にお願いしたら?」と思う。マクロ組める人なんて他にいくらでもいるのだし。

ぼくは、自分の設計思想、というか、「仕事」に対する考え方に共感してくれる人と、仕事がしたい。
ぼくが一番に考えるのは「現場」だし、「現場からのボトムアップ」が仕事において一番大事だと信じてるし、現場の人間がもってる「無形の力」を信じてるし、「経験」を信じてるし、「人間」を信じてる。

オレたちは機械じゃない。自動処理するマシンでもない。大事なのはマクロじゃない。「人」だ。

「人」を育み、そして「仕事」を、未来に向けて、一日でも長くつづけていけるようお手伝いする。それがぼくの、森田表計算の仕事なのです。