Excelマクロや日次のデータ集計をVBA・Python・GASで自動化するとき、外部の技術者や開発会社に依頼する企業は少なくありません。ところが「動いていたはずの処理が止まった」「作った人と連絡が取れない」「中身が分からず直せない」といったトラブルは、技術の問題というより発注時の決めごとが足りないことから起きます。この記事では、発注前に文書化しておく6項目と、案件情報の置き場所を分類して決める整理法を示します。
- 対象業務を書き出す 今やっている手順を工程単位で言語化する
- 6項目を文書化する 範囲・納品物・環境・改修・記録・終了条件を決める
- 見積と前提をすり合わせる 前提が崩れたときの扱いも書いておく
- 情報の置き場所を決める 6分類で保管場所を固定してから着手する
- 検収と版の固定 確認した仕様とコードの版を記録に残す
なぜ自動化の外注でもめるのか
自動化案件は、受注側が「言われた処理を動かすこと」を納品と考え、発注側が「業務が回ること」を納品と考える、という食い違いが起きやすい領域です。原因は大きく三つあります。
第一に、業務そのものが文書化されていないことです。担当者の頭の中にある例外処理や手作業の補正は、口頭説明では抜け落ちます。第二に、動作環境の前提が共有されていないことです。ExcelやOSのバージョン、社内ネットワークの制限、権限設定の違いで同じコードが動かないことがあります。第三に、やりとりが個人のメールやチャットに散らばり、後から「何をどう決めたか」をたどれなくなることです。
自動化外注のトラブルは技術力の差ではなく、業務の前提と決定の記録が共有されていないことから生じます。
発注前に決める6項目
見積依頼の前に、次の6項目を文書にしておきます。A4一枚でも構いません。
1. 依頼範囲
どの工程を自動化し、どの工程は人が行うのかを線引きします。「請求データの集計を自動化」ではなく、「基幹システムから出力したCSVを読み込み、指定様式のExcelに集計して保存するまで。出力ファイルの内容確認と送付は人が行う」と書きます。例外データが来たときの扱い（止める／ログに記録して次へ進む）も決めておきます。
2. 納品物
動くプログラムだけでは引継ぎができません。最低限、次を納品物として明記します。
| 納品物 | 目的 |
|---|---|
| ソースコード一式 | 改修と再配布のため |
| 仕様書（処理の流れ・入出力の定義） | 内容を第三者が理解するため |
| 操作手順書 | 現場担当者が運用するため |
| 設置・実行環境の手順 | 端末入替や再構築のため |
| テスト用データと結果 | 正しく動いているかの確認基準 |
3. 動作環境
OS、Office・Pythonなどのバージョン、実行する端末、ファイルの保存場所、必要な権限、ネットワーク制限を書き出します。「開発者の端末では動いたが社内端末では動かない」は、ここを書いていないと責任範囲の議論になります。
4. 改修条件
納品後の修正をどう扱うかを先に決めます。不具合（仕様どおりに動かない）の修正期間、仕様変更（新しい要望）の扱い、対応の依頼窓口と想定する応答時間です。不具合と仕様変更の境界は、2の仕様書があってはじめて判定できます。
5. 連絡と記録の方法
質問と回答をどこに残すかを決めます。個人のチャットで決めた内容は、担当者が変わると消えます。決定事項は案件の記録に残す、という運用を発注側から提示します。
6. 終了条件（検収）
何をもって完了とするかです。テストデータで指定の結果が出ること、本番データで一定期間並行運用して差異がないこと、など確認方法を具体的に書きます。
情報の置き場所を6分類で決める
6項目を決めても、情報がメール・チャット・共有フォルダ・個人PCに分散すれば、半年後には追えなくなります。着手前に、案件情報を次の6分類に整理し、どこに置くかを固定します。
| 分類 | 入れるもの |
|---|---|
| 基本情報 | 案件名、担当者、対象業務、期限、関係者 |
| 仕様 | 処理の流れ、入出力の定義、例外時の扱い |
| 資料 | 元になるExcel、CSVサンプル、画面キャプチャ |
| コード | ソース一式と版 |
| 会話 | 質問と回答、決定事項 |
| 改修履歴 | いつ何を直したか、依頼者、確認者 |
この分類は、どこに何を探しに行けばよいかを固定するためのものです。特に「会話」と「改修履歴」を分けて残すと、後から「この挙動はなぜこうなっているのか」をたどれます。
Poxiiは、VBA・Python・GASなどの自動化案件をこの6分類で整理し、案件URLで管理・引継ぎができるサービスです。仕様とコードの版を固定し、確認記録を残せるため、検収時点の内容と現在の内容を区別して扱えます。
情報の置き場所を6分類で先に決めておくと、担当者交代や外注先変更のときに探す作業が減ります。
版を固定して確認記録を残す意味
自動化ツールは納品後も現場の要望で少しずつ変わります。このとき「どの仕様のどのコードを誰が確認したか」が分からなくなると、不具合なのか仕様変更なのかを判定できません。
外注を進めるか、まず社内で整理するか
すべての自動化をすぐ外注すべきとは限りません。業務手順が固まっていない段階で発注すると、仕様変更が繰り返されて費用も期間も膨らみます。
発注を進めてよい状態
- 対象業務の手順が文書になっている
- 入力ファイルの形式と出力の完成形が決まっている
- 例外データの扱いを現場で決められる人がいる
先に社内整理が必要な状態
- 担当者ごとに手順が違う
- 「だいたいこんな感じ」以上に説明できない
- 判断基準が属人的で言語化されていない
社内整理が必要な状態なら、まず現行手順の棚卸しから始め、固まった部分だけを切り出して発注する進め方が現実的です。
よくある質問
Q: 小規模な自動化でも6項目すべてを書く必要がありますか
A: 分量は規模に合わせて構いませんが、項目自体は省かないことをおすすめします。小規模な依頼ほど口頭で進みがちで、担当者が変わった後に誰も中身を説明できなくなる例が起きます。A4一枚で、依頼範囲・納品物・動作環境・改修条件・記録方法・終了条件を一行ずつでも書き残すと判断の基準になります。
Q: ソースコードは納品物に含めてもらえるものですか
A: 契約によります。含まれない場合、後から別の相手に改修を頼むことが難しくなるため、発注前に必ず確認してください。納品物に含めるか、含めない場合に改修をどう依頼するかを、6項目のうち「納品物」と「改修条件」に明記しておきます。
Q: 外注先を変える場合、何を引き継げばよいですか
A: 仕様、コード、資料に加えて、決定の経緯が残る会話と改修履歴が重要です。経緯が分からないと、新しい担当者は現在の挙動が意図的なものか不具合かを判断できません。Poxiiのように6分類で整理し案件URLで引き継ぐ形にしておくと、受け渡しの範囲が明確になります。
まとめ
自動化の外注でもめる原因は、依頼範囲と納品物の定義、動作環境の前提、改修条件、記録の残し方が決まらないまま着手することにあります。発注前に6項目を文書化し、案件情報を基本情報・仕様・資料・コード・会話・改修履歴の6分類で置き場所を決めておけば、検収時の判断も、担当者交代時の引継ぎも進めやすくなります。まずは手元の1案件について、この6項目をA4一枚に書き出すところから始めてみてください。
