職場で自作したExcelマクロやツールを、自分がいなくても使える状態にする
職場で作ったExcelマクロやツールは、置き場所、変わりやすい設定、止まったときの手作業の3つを残しておくと、作った本人がいなくても業務が止まりにくくなります。
便利なツールほど、使う人が増え、作った人しか直せない状態になりがちです。担当を外れた後に「前の人が作ったマクロが動かない」と言われるのは、作った側にとっても、残された側にとっても困る状況です。ここでは、職場で使う小さな自作ツールを想定して、残しておきたいものを整理します。
まず「誰が、何に使っているか」を書き出す
自分用に作ったツールが、いつの間にか部署全体で使われていることがあります。最初に、利用状況を把握します。
| ツール | 使っている人 | 使う時期 | 止まった場合の影響 |
|---|---|---|---|
| 請求データ整形マクロ | 経理2名 | 毎月月末 | 請求書発行が遅れる |
| 在庫一覧の集計スクリプト | 自分のみ | 毎週月曜 | 手作業で1時間程度 |
| 日報の転記マクロ | 営業5名 | 毎日 | 各自が手入力に戻る |
これは記入例です。影響が大きいものから順に、この記事の対策を当てていきます。自分しか使っていないものは、無理に整えるより、後で削除してよいか判断できるように書き残す程度でも十分です。
置き場所を個人のPCから移す
デスクトップや個人のフォルダに置いたツールは、PCの入れ替えや退職で消えてしまいます。
- 本体は部署の共有フォルダなど、決まった場所に1つだけ置く
- ファイル名に日付や「最新」を付けて複製を増やさない
- 変更前の版は、別の保管用フォルダにまとめる
「どれが最新か分からない」状態は、動かない以上に混乱を招きます。利用者には、本体を直接編集せず、コピーして使う、または決まった場所から開いてもらうよう伝えます。
変わりやすい値は、コードから外に出す
ツールが動かなくなる原因の多くは、プログラムの誤りより、周りの変化です。
- 読み込むファイルの場所や名前が変わった
- 取引先や担当者の一覧が増えた
- 税率や締め日などの条件が変わった
こうした値をコードの中に直接書いていると、直すたびにマクロを開く必要があります。Excelなら「設定」シートを作り、フォルダのパスや対象の一覧をセルに書いて、マクロはそこを読むようにしておきます。
| 設定項目 | 値 | 変更するとき |
|---|---|---|
| 入力ファイルの場所 | \\共有\経理\取込 | フォルダ移動時 |
| 対象部署 | 営業1課、営業2課 | 組織変更時 |
| 締め日 | 20 | 契約条件の変更時 |
設定を表にしておくと、コードを読めない人でも、どこを直せばよいか見当がつきます。
止まったときの「手作業の戻り方」を書いておく
ツールが動かないときに一番困るのは、利用者が元のやり方を知らないことです。自動化される前の手順を、簡単にでも残しておきます。
このツールが動かないとき:
1. エラー画面を撮影し、〇〇さん(または部署のチャット)へ連絡する
2. 急ぎの場合は、手順書「請求データの手作業整形」で処理する
3. 手作業の目安時間:30件で約1時間
手作業の手順があれば、修正を待つ間も業務は止まりません。修正できる人が見つからない場合に、外部へ依頼するか、手作業に戻すかを判断する材料にもなります。
利用者向けと、直す人向けの説明を分ける
説明書は、読む人によって必要なことが違います。
| 読む人 | 書くこと |
|---|---|
| 使う人 | 使う目的、操作の手順、よくあるエラーと対処、問い合わせ先 |
| 直す人 | 処理の流れ、設定の場所、読み書きするファイル、注意点、変更履歴 |
利用者向けは画面の画像を添えて1〜2枚に収めます。直す人向けには、処理の流れを箇条書きにするだけでも、初めてコードを開く人の助けになります。
処理の流れ:
1. 設定シートから入力フォルダを読む
2. フォルダ内のCSVを順に開く
3. 取引先コードで並べ替え、請求シートへ転記
4. 金額が0の行は「確認」シートへ移す
5. 完了後、処理件数をメッセージで表示
コードの中にも、各処理の意図を短くコメントで残しておきます。「何をしているか」はコードを読めば分かりますが、「なぜそうしているか」は書かないと伝わりません。
作った本人がいなくなる前に、誰かに一度直してもらう
説明書を書いても、実際に別の人が修正できるかは試すまで分かりません。可能なら、設定の変更や簡単な修正を一度、後任や同僚にやってもらいます。
直せる人が社内にいない場合は、上司と次のどれにするかを相談します。
- 使い続け、壊れたら手作業に戻す
- 外部の業者に保守を依頼する
- 部署で契約しているサービスや、既存システムの機能に置き換える
ツールを作って終わりにしない、という点は自動化の成果の伝え方で書いた保守の話ともつながります。維持にかかる手間も含めて、組織として使い続けるかを決めてもらうのが、作った人の負担を減らす近道です。
以前、業務ハックしたらクビになったという経験を書きました。自分しか分からない仕組みを作ることが、必ずしも自分の立場を守るわけではありません。誰でも扱える形で残すことも、改善の成果の一部として伝えておきたいところです。