ExcelVBAを使った社内開発の心構え～未来の自分と後から来る誰かのために～

皆さん、4連休最終日はどうお過ごしですか？
TwitterやQiitaを見てると休日なのに熱心に学習されてる人がいて本当に感心です！

今日は社内で自動化ツールなどを開発しているワタシが、入社してからの失敗談をふまえながら
社内開発のやり方や大切にしていることを書きたいと思います。

VBAは誰もが勉強しやすくいろんなものを作れるだけに不都合も生まれやすいです。
善意で作ってあげたらそれが後々自分の首を締めることになるなんて事も…
VBAを勉強したての人や、これからVBAの開発の仕事につく方の参考になればいいなと思います。

#ワタシの仕事内容
社内の各部署から業務自動化の依頼を受けて、VBAでツール開発をするお仕事です。
社内の担当範囲となる部署は広範囲で、自分が所属する部署以外の部署の依頼も受けます。

#入社時の失敗談
###開発案件が話しかけられたベースで増えていく
「またマクロを作れる人が入社してくる」という噂が広がっていたのか入社してからすぐ、
「このマクロ直してください～」
「このマクロ作ってください～」
と知らないおじさんがどんどん話しかけてきます。
「まず順番にどこの誰か名乗ってください」状態。笑
仕事はどんどん溜まっていきました。

入社から2ヶ月後にVBA開発の同僚が入ってくるのですが
先にいたワタシの方が目についてしまうのかワタシの方に依頼が集中してしまってました。
同じ派遣社員に派遣社員が業務をふるのも忍びなくて、上司と相談する時間も取れないまま、
結局、ワタシの抱える案件の数は減りませんでした。

###あると思ってたらない！！
弊社はワタシが入社する前にも何人かVBA開発者がいたそうなんですが、入っては辞めを繰り返し、ワタシは何人目かのVBA開発者だったみたいです。
入社時は前任者からの引き継ぎ期間はなく、上司というポジションの方は居たものの一人で業務を始める感じでした。
そして面談で存在するかと確認した「引き継ぎ資料」は存在しませんでした！
（話が違うじゃないか！）
なにも過去の資料がない
ツールの利用者も仕様を理解してない
そんな状態から前任者の開発したツールのエラーをひたすら直す、というのが
初めてのお仕事になりました。

「うーん…まあ、あるあるだよね」

#開発業務を業務改善
流れに身をまかせるままに3ヶ月…
「このままでは五月雨式に仕事は降ってくるし、同僚との業務バランスも悪い。将来、開発したツールのメンテナンスもやりにくい。野良マクロがどんどん増えていく気がする！！」
当時の現状に危機感を感じて、自分たちの業務の交通整理をまず行うことにしました。

###上司を防波堤に！
まずは、話かけられたベースでなんとなく案件が増えていくという状況を変えるべく、
依頼を受けて整理し、担当を決めて割り振ってもらえるように上司に相談しました。
同僚B子さんも同じように危機感と不満を抱いていたらしく一緒に上司に相談しにいってくれました。
上司と__依頼発生から案件クローズまでの流れ__を相談して以下の図のようにしました。

上司も面倒くさそうにしてましたがワタシ達の意見を取り入れてくれてルール決め出来ました。
まあ、今も上司は防波堤の役割を完璧に出来てるわけではないのですが、防波堤がいるといないでは全く違います！
###全社員に告ぐ！まずは自分たちで考えたまえ！！
話しかけられたベースでの依頼では、
__「この作業さ、なんか時間かかってるからいい感じにして」__というようなざっくりした相談内容の人もいて
業務コンサル的なところから入らなければいけないこともありました。
そうするとそのチームの業務内容を把握することから始まり、一つの案件にかなり時間も要します。
開発者2人でこなしていくのは大変なので、
__大体の仕様は自分たちで考えてください。話はまずそこからです！__というスタンスにすることにしました。

上の図にもあるように、ざっくりしすぎたゆるゆる依頼は上司のとこで止まることになっているか、もしくは上司が相談にのってあげるということにしました。
そのおかげで私達開発者は__作ることに注力できる__ようになりました。

#社内開発でのワタシ流ルール
以下は開発をするときに絶対にやるようにしていることです。

###仕様書・設計書は必ず残す！
当たり前のことかもしれませんが、弊社では過去、これが全く出来ていないようでした。
作ったらそれで終わりという感じです。
自分だけで使うならなくても良いのですが、社内開発においては、__作り出すなら最後まで面倒みれるようにする__のが開発者の責任だと思います。
またワタシはどんな小さいマクロでも仕様書は開発者のためだけでなく、利用者本人にも仕様を理解してもらうために必要だと思います。

あと、すぐ「バグだ！」といい出す人に、「仕様です。仕様書に書いてます。」とちゃんと言えます。
仕様書・設計書は未来の自分を守ってくれます

###コードはパスワードで守れ！
自分が新規開発したツールのコードはVBEでパスワードを設定し、無断で転用、編集が出来ないようにしています。
以前、自分が開発したコードが他人によって色々付け加えられその後の改修が非常に大変でした。
たぶん良かれと思ってやったことなんでしょうがやはりワタシはコードをいじられるのがすごく嫌です。
依頼者には「改修はこちらですべて行いますのでコードは勝手に改修しないでください。」と伝えてます。

もちろん、自分がいつか辞めるときはパスワードを引き継ぎますし、非常時に備えて信頼できる人にだけ共有しています。
VBAはパスワードをかけても解除するコードなんかもネットで拾えてしまうので完全なガードではないのですが、大体の人はパスワードをかけることを理解してくれると思います。

###人のコードにはむやみに手を出すな！
始めの方にも書きましたが入社時の初仕事は前任者が作った何の資料もないツールのエラー修正でした。
他人が書いたコードを修正していくのはとても時間がかかってしまい、ワタシにとって普通に苦痛で
__新規で作成し直したほうが早い__と気づきました。

それからは、
むやみに他人のコードを修正せず、新規開発を相談する
ツールのメンテナンス対応を他人から引き継ぐときは仕様書、設定書を必ず作ってもらう
この2つを守るように上司に伝えました。

#最後に
今回書いた内容は上司や同僚に理解が得られないとできないかもしれません。
会社によっては「こうしてくれないと出来ません。」という意見さえ言えない会社もあると思います。

未来の自分と後から来る誰かが仕事しやすくできるようにするためにも改善することは必要だと思います。
業務改善のためのワタシたちだからこそどんどん良くしていきたいです。
上司への要望やもっとこうしたいという改善はまだまだたくさんあります。
ワタシの模索はつづきます。

もしよかったら社内開発で同じような経験やその他の改善策を行った方いらっしゃいましたら
教えて下さい

最後まで読んでいただきありがとうございました！！