仕様書がないAccessを延命させるために最低限残すべきドキュメント

結論：完全な仕様書は要りません。4点が業務停止のリスクを下げる

当社に相談が来るAccessの現場では、引き継ぎ資料がないまま長年動いているケースが多く見られます。作った担当者が退職し、誰も構造を説明できない状態でも、なんとか動かし続けている。かといって今から数百ページの仕様書を書く時間も人手もない（当社実務）。

当社の実務では、そういった現場に対して「最低限4点を残す」ことを最初の目標に設定しています。テーブル一覧・処理の入出力・運用手順・緊急連絡先の4点です。これがあれば担当者が変わっても業務を止めずに対応できる場合が多く、将来の移行作業も進めやすくなります（当社実務基準）。

仕様書ゼロの状態から構造を読み取る手順はブラックボックス化したAccessの解析手順で解説しています。属人化の危険度が気になる方はAccess属人化の危険度と脱・属人化の進め方もご覧ください。

最低限残すべき4点

全部を完璧に文書化する必要はありません。次の4点を「社内の誰でも読める場所」に置いておくことが目標です（当社実務基準）。

4点のうち最も効果が高いのはテーブル一覧です。テーブルが分かれば、データがどこにあるか、何を直せばどこに影響するかの見当がつきます。テーブル構造が不明なまま修正や移行に進むと手探りになるため、ここだけは最初に確保する価値があります（当社実務）。

テーブル一覧の作り方

Accessには「Database Documenter（データベース ドキュメント作成ツール）」という標準機能があります。「データベース ツール」タブ→「分析」グループ内にあり、テーブル・クエリ・フォーム・レポートなどのオブジェクトの設計情報をレポートとして出力できます（Microsoft Support: Document and print your database design）。

テーブル一覧だけが目的なら、全オブジェクトを出力する必要はありません。ダイアログで「テーブル」タブを開き、対象テーブルをすべて選択してOKを押すと、フィールド名・データ型・インデックス情報を含むレポートが出力されます。ただしこのレポートはプロパティの羅列で読みにくく、そのまま渡しても後から読む人が理解できないことが多いです（当社実務）。出力をもとに次の書式で整理することをすすめています。

テーブル名だけでは意味が分からないケースが多いため、「業務上の呼び名」と「主な用途」の2列が特に重要です。この2列があるだけで、後から関わる担当者の解読時間が変わります（当社実務）。

処理の入出力の書き方

処理の入出力とは、「誰が何を操作して、何が生成・更新されるか」を一行でまとめたものです。フォームごとのVBA仕様を全部書く必要はなく、主な処理を列挙するだけで十分です（当社実務）。

「使う頻度」の列は、後から作業量を把握するときに役立ちます。日常的に使われる処理とイレギュラーな処理を区別できれば、トラブル時の影響範囲を判断しやすくなります（当社実務）。

運用手順の書き方

運用手順で押さえるべきは、定型作業の手順と「やってはいけないこと」の2点です。操作手順は担当者から聞き取ってその場で書いてしまうのが一番速い方法です（当社実務）。

書く粒度の目安は「3か月後の自分が読んで迷わない」レベルです。画面のキャプチャが撮れれば添付するとより分かりやすくなりますが、文字だけでも手順が追えれば十分機能します。

「やってはいけないこと」として特に記録しておくべき内容は次のとおりです（当社実務）。

• 特定のテーブルを直接編集しない（フォーム経由でのみ更新する）
• 特定のクエリを手動で実行してはいけない（実行すると全件削除等が走る）
• OneDriveやSharePointの同期フォルダから.accdbを直接開いて運用しない（複数コピーが生まれたり予期しない動作が生じる可能性がある）
• バックアップを取らずにフォームやクエリを変更しない

バックアップについては延命中のAccessを守るバックアップ設計でまとめています。OneDriveへの配置禁止については延命チェックリスト（項目6）も参照してください。

緊急連絡先の書き方

トラブル時に誰に電話するか、これが書いてあるだけで対応速度が変わります。情報システム部門がある会社はそちらの担当者名と連絡先、外注開発のケースは開発会社の担当者名・電話番号・サポート窓口URLを記載します。

あわせて書いておくと役立つのは「このAccessを止めると何の業務が止まるか」という業務影響の簡単なメモです。「受注入力が止まると出荷指示が止まる」「月次集計ができないと経理部の締め処理が遅れる」といった連鎖を一行で書いておくと、障害発生時の優先度判断が速くなります（当社実務）。

ドキュメント整備の進め方

4点を一度にそろえようとすると重く感じます。担当者が変わるタイミングか、何か変更を加える機会に合わせて少しずつ書いていくのが現実的です（当社実務）。

着手の順序は、テーブル一覧→緊急連絡先→運用手順→処理の入出力の順をすすめています。テーブル一覧はDatabase Documenterを使えば短時間で素材が揃い、緊急連絡先は数分で書けます。この2点だけでも揃えておくと、急なトラブル対応の質が変わります（当社実務）。

担当者から聞き取る時間が確保できない場合や、担当者がすでにいない場合は、Accessファイルの構造から設計情報を読み取る解析が必要になります。解析できるかどうかは無料の解析可否チェックからご確認いただけます。

よくある質問

Q. Database Documenterを使えば仕様書が完成しますか。

完成はしません。Database Documenterはフィールド名・データ型・プロパティ、さらにコードモジュールやユーザー権限といった設計情報を出力しますが、業務上の意味（何に使うテーブルか）や処理フロー（どのボタンを押すと何が走るか）を業務向けに整理して出力する機能ではありません。素材として使いつつ、業務の意味を人が書き加える必要があります（当社実務）。

Q. テーブルが30個以上あります。全部の一覧を作るべきですか。

全部書くのが理想ですが、まず日常業務で使われるテーブルから始めてください。参照系のマスタと日々データが増える実績系のテーブルを押さえれば、業務への影響は把握できます。一度に全部やろうとすると止まるので、使用頻度の高いもの優先で進めてください（当社実務）。

Q. ドキュメントはどこに置けばいいですか。

Accessファイルと同じフォルダに「doc」フォルダを作り、WordかExcelで置くのがシンプルです。OneDriveやSharePointに置く場合は、.accdbファイル本体は同期フォルダに置かず、ドキュメントだけ共有する形が無難です。社内wikiやNotionでも構いません。重要なのは「担当者しか知らない場所に置かない」ことです（当社実務）。

Q. 仕様書を作る前に移行を検討すべきですか。

担当者が退職して誰も構造を把握していない状態なら、移行の前にまず解析が必要です。解析で構造が分かってから、移行か延命かを判断する順序の方が、費用も時間も無駄になりにくいです。移行の費用感はAccess移行の費用相場で整理しています。