VBA・Excelマクロ開発者の参画初月にやること｜現場で信頼される進め方

VBA・Excelマクロ開発者の参画初月は、ツールの全体像と利用者の環境をつかみ、直す範囲と完成の形を合意し、小さな改修を一つ納めきるのが基本です。いきなり大きく作り直すより、「この人に任せると壊れない」と思ってもらうことが、2か月目以降の仕事の広がりにつながります。

この記事では、初月のゴール、週ごとの進め方、案件の型による重心の違い、初月に避けたい動き、月末の振り返りを整理します。参画前の準備の全般は参画前に準備すること、参画直後の一般的な動き方は参画初期の進め方で扱っているので、ここではVBAならではの点に絞ります。

初月のゴールを3つに分ける

初月に目指すことは、次の3つです。

3つ目が大切です。VBAの現場では、作業の進め方を見せる一番の材料は、実際に納めた一件です。

1週目：ツールと環境を知る

最初に確かめること

参画した初日から数日で、次の点を確かめます。

• 対象のツール：どのブック、アドイン、Accessのデータベースが対象か。置き場所はどこか
• 利用者と使う時期：誰が、どの業務で、いつ使うか。月末や決算の締めで使うものはどれか
• 利用者の環境：Officeの版、32ビット版か64ビット版か。Microsoft Learnでは、Office 2019とMicrosoft 365から64ビット版が既定と説明されています（2026年10月時点）
• つながる先：社内のファイルサーバー、データベース、ほかのブック、外部のサービス
• 作業の環境：開発用のブックとデータをどこで扱うか。本番のデータに触れてよいか

本番のファイルに個人情報や取引の情報が含まれる場合は、作業の場所とデータの扱いを最初に決めておきます。考え方は個人情報の取り扱いを委託されたときをご覧ください。

コードを読む前に、動かしてみる

利用者の画面を横で見せてもらうか、テスト用のデータで一度動かして、ツールが業務の中で何をしているかを確かめます。コードだけを読んでも、どの処理が大事で、どの例外がよく起きるかは分かりにくいからです。

利用者と短く話す

利用者の担当者に、困っていること、よく起きるエラー、手で直している作業を聞きます。依頼の文面に書かれていない不満が見つかることがよくあります。

2週目：読み解いて、範囲を合意する

処理の流れを書き出す

モジュールごとの役割、主な処理の流れ、触っているシートと外部のファイルを書き出します。Windows APIを呼んでいるDeclare文がある場合は、64ビット版でPtrSafeが付いているか、ポインターやハンドルにLongPtrを使っているかも確かめておきます（Microsoft Learn、2026年10月時点）。

書き出したものは、発注側にも共有できる形にしておきます。前任者からの引き継ぎが薄い現場ほど、この資料がそのまま価値になります。引き継ぎの考え方は引き継ぎの記事で整理しています。

依頼を一覧にし、範囲と完成の形を決める

聞き取った依頼を一覧にし、契約の範囲の内か外か、優先する順番、どうなれば完成かを発注側の窓口と合意します。完成の形は「どのデータで、どの結果が出れば確認済みとするか」まで決めておくと、後の食い違いを防げます。範囲が広がりそうなときは業務範囲が変わったときの記事をご覧ください。

配り方を確かめる

直したブックをどこに置き、利用者がどう開くかを確かめます。Windows版のOfficeでは、インターネットから取得したファイルのマクロが既定でブロックされます（Microsoft Learn、2026年10月時点）。信頼できる場所やデジタル署名など、組織でどの方法をとっているかを、情報システムの担当者に聞いておきます。

3〜4週目：小さく直して、最後まで納める

最初の改修は影響の小さいものを選ぶ

最初に手を付けるのは、業務への影響が小さく、確認がしやすい改修にします。締めの直前に使うツールの大きな変更は、初月には避けるのが無難です。

直す前に元を残す

直す前のブックを日付つきで残し、どこをなぜ直したかを記録します。不具合が出たときに、すぐ元に戻せる状態にしておきます。

利用者に近い環境で確かめる

自分の端末だけでなく、利用者と同じ版・ビット数の環境で動かして確かめます。可能であれば、利用者にテスト用のデータで一度操作してもらいます。

手順書と記録を更新して渡す

操作の手順が変わる場合は手順書を直し、よくあるエラーの対処も書き足します。進み具合はチャットや短い報告で共有します。書き方はチャットでの報告とドキュメントの書き方の記事も参考になります。

案件の型によって初月の重心は変わる

古いツールの引き継ぎ・改修

読み解きと書き出しに時間をかけ、直すのは合意した範囲だけにします。仕様書がない場合、初月の書き出しがそのまま仕様書の代わりになります。

版の入れ替え・64ビット版への対応

対象のツールを洗い出し、動かなくなる箇所の見立てと、確かめる順番を初月にまとめます。利用者の多いもの、締めに使うものから順番を決めると、発注側も判断しやすくなります。

新規のツール開発

入力・出力・扱う例外を早めに合意し、画面や出力の見本を短い周期で見せます。作り込む前に利用者に触ってもらうことで、手戻りを減らせます。

保守・問い合わせ対応

問い合わせの受け方と、対応の記録の残し方を最初に決めます。同じ質問が続くものは、手順書の改善として提案します。

初月に避けたい動き

• 全体をつかむ前に書き直しを提案する：前任者の作りには、見えていない業務の事情があることがあります
• 本番のブックを直接直す：元に戻せない変更は、締めの時期に大きな影響を与えます
• 利用者に設定の変更を勧める：マクロのセキュリティの設定は組織の管理に関わるため、情報システムの担当者を通します
• 口頭の依頼をそのまま受ける：小さな依頼ほど記録が残らず、範囲が広がる原因になります
• 自分の端末だけで確かめて納める：版やビット数の違いで、利用者の端末では動かないことがあります

つまずきやすい点の全体はVBA・Excelマクロ開発者のフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

月末には、次の点を発注側の窓口と確かめておくと、2か月目の進め方がそろいます。

1. ツールの一覧と処理の流れの資料に、抜けや誤りがないか
2. 依頼の一覧の優先順位は今のままでよいか
3. 納めた改修に、利用者から気になる点が出ていないか
4. 64ビット版への対応や配り方など、先に手を打つべき課題はないか
5. 2か月目に取り組む改修と、完成の形

よくある質問

前任者からの引き継ぎがほとんどありません。何から始めればよいですか？

利用者に実際の操作を見せてもらい、ツールが業務の中で何をしているかを確かめるところから始めます。そのうえで、モジュールの役割と処理の流れを書き出し、発注側と共有します。分からない処理は無理に推測せず、利用者に結果の正しさを確かめてもらいながら進めてください。

初月から大きな改修を求められたら、どうすればよいですか？

断る必要はありませんが、まずは全体像の書き出しと、直す範囲・完成の形の合意を先に済ませる段取りを提案するのが安全です。影響の大きい改修ほど、元に戻せる準備と、利用者に近い環境での確認の時間を見込んでおきます。

リモートの参画で、利用者の環境をどう確かめればよいですか？

画面共有で利用者の操作を見せてもらい、Officeの版とビット数をその場で確かめるのが近道です。発注側の環境で作業できる貸与端末やリモートの接続が用意されるかも、参画の前に確かめておきます。進め方はVBA・Excelマクロ開発者のリモート案件で整理しています。