見出し画像

中身の分からないEUCの山で生き延びるには

ああ、今日もまたエラーだ。メールの件名に【至急】と書いた対応依頼が来た。

今はあらゆる業務でIT化が進んでいるが、システム会社では高価過ぎて作れなかった、でも人手ではやってられないほど煩雑な業務があったりする。

そんな時にITに詳しい人が現れて、ボタン一つで簡単に業務ができる便利ツール(いわゆるEUC)を作ることが時々ある。

その時はみんなから拍手喝采を浴びるのだが、その人が辞めたり異動したら仕組みを分かる人が誰もいなくなって、エラーが出るたびに詳しそうな人に泣きつくことになるのだ。

そんな事例が積もり積もってしまうと、「初見のツールを2時間以内にエラー解消まで持っていかなくてはいけない」という鬼のような対応依頼が日常茶飯事になってゆく。

業務と密接に絡んでいるのに、スキルの伝承が出来ず、薄氷を踏むような運用になっているのに誰も本腰を入れて対策をしようとしないのだ。

ある程度歴史のある会社なら多かれ少なかれこのような課題を抱えているだろう。では、どうやって対策をすればよいのか。

保守できる人間が不足しているならば、育てていくしかない。とはいえいきなり身の丈に合わない難題を任せても学ぶ意欲が失われるだけだ。

まずは曖昧模糊とした"EUCの保守スキル"なるものを分解してみよう。以下はEUCで使われること多いACCESSに関するスキルを構成パーツごとにざっくり書き出してみたものだ。

①クエリが読める・作れる
②フォームが読める・作れる
③モジュールが読める・作れる
④VBAが読める・作れる

ここに加えて

⑤中身が分からないからツールを分からないままなんとかする方法
⑥その後の保守コストも踏まえて、「この業務をEUC化すべきか否か」をジャッジする能力

といったスキルも挙げられる。

先に結論から言うと、④を読む技術と⑤を集中的に教育することがスキル保有者の育成の肝だと思う。

ブラックボックスになっているEUCが大量にある組織において、EUC対応で一番多いのは他人の作ったツールのエラーを対処する業務だ。

これは①〜④を読むことができればかなりのパターンを対処できる。まずはざっくりとでもいいから処理の概要を掴むための"読む訓練"をすれば「エラーに対処できた」という成功体験を積むことができる。

中でも人々が苦手意識を持ちやすいのは④のVBAである。ここはスキル保有者が"ほどほどの難易度の階段"を用意してやって段階的に登らせる工夫が必要だろう。

ここで、違う角度から④をさらに細かく分解してみよう。EUCの処理は以下の3段階から捉えられる。

入力→演算→出力

では、「昨日まで動いてたツールが突然動かなくなっちゃったんです」となった時に最も多い原因はこの3要素のうちどれだろうか?

私の経験上では、入力に問題があるケースが一番多かった。したがって、④の中でも特に「入力データを読み解く」ところに注力して育成するのが良いと思う。(その他はテーブルのリンクを貼ったり、ツール内で人が手入力したり、人がインポートしたりしてる)

ここまで教える事項を絞り込めれば、教えるハードルはかなり下がる。

私の見た限りだと、VBAを用いたインポート制御はフォルダパスが書かれていることがほとんどなので、検索などしたら割と辿り着きやすい。(その他の制御方法/解読方法をご存知の方いらっしゃったらご教示ください)

なので、「ロジックの中でこうやって検索したら辿り着けます」というのを事例を交えながらいくつか紹介すれば、勘のいい人なら自分もVBAを読んでみようかなと動き出してくれたりする。

一方で、⑤で覚えることは二つだけだ。

・あらかじめバックアップを取っておいて、今のツールが動かなくなったら中身のテーブルだけ抜き出してバックアップツールを動かす

・ネットワークの不調など、タイミングが悪かっただけの可能性があるので、時間をおいてもう一度動かしてみる

中身が分からない状態でツールを壊さずに対応しようと思ったら、結局これぐらいしかやれることはないのだ。しかし、意外とこれをやれる人は少ない。

以上のような仮説のもと、私は自分でVBAを学びながらスキル保有者の育成にも取り組んでいる。最初は冷ややかな目で見ていた参加者も、半年ほど続けていくうちに徐々に私の考えに賛同して学ぶ姿勢を示してくれるようになってきた。(私にとっては至福の時間である)

未熟ながらもVBAを学んでみて思ったことがある。

技術伝承に悩んでいるならば、スキルを細かく分解して難易度別に分け、徐々に階段を登ってゆく制度づくりを行い、それを他の人にぶつけながらブラッシュアップしてゆくのがしんどいながらも一番の近道なのではないかと思う。

日本に多い職人肌のスキル保有者はそのような体系化が得意でない人が多い。その場合には体系化できる人間がスキルと向き合いながら地道に階段を形作ってゆくのが肝心ではないか。

IT化が進んでいない会社と比べれば、私の置かれている環境は恵まれていると思う。いなくなってしまったとはいえ、スキル豊富な人が残してくれたお手本となるEUCがたくさんある。

それを読み解いていくうちに優れたVBAの書き方が段々と染み込んでゆくし、スキル保有者が少ないからちょっとでも読み解いてエラー対処できれば英雄扱いだ。

モチベ維持の観点からもこれはかなり良い環境である。先に述べたように「ちょっと読めるようになってエラー対処するだけで大感謝される」のだから。

・・・さて、振り返りはこの辺にして、そろそろ次の階段作りを始めますかね。

続きはこちら


この記事が気に入ったらサポートをしてみませんか?