みなさん、こんにちは。
Microsoft Accessを使ったシステム化の要望、よく耳にしますよね。特に「利用者は10名程度」「開発コストはかけられない」という条件下で、「2〜3人の開発者でメンテナンス性の良い開発」が求められると、どのように進めるべきか、頭を悩ませる方もいらっしゃるのではないでしょうか。
開発者としては、管理がしやすいWindows FormsやC#での実装を望む声も多いのですが、ユーザーからのAccess利用への強い要望があれば、それに応えざるを得ないのもまた事実です。
Microsoft Accessは、その手軽さから部署内のちょっとしたシステム化に非常に有効なツールです。しかし、複数人で開発・メンテナンスを行うとなると、いくつかの注意点があります。特に、Accessは単一のファイルにすべての要素(VBAコード、フォーム、レポート、テーブル定義など)を格納するため、一般的なソフトウェア開発とは異なる工夫が必要になります。
今回は、2〜3名の開発者でメンテナンス性を重視したAccessシステムを開発・運用するための管理方法についてご紹介します。
1. データベースの「分離」が開発の鍵
まず、最も重要かつ基本的なことが「フロントエンド/バックエンド分離 (FE/BE分離)」です。
- バックエンド(BE)
- データ(テーブル)のみを格納します。これは共有サーバーに配置し、複数ユーザーでアクセスできるようにします。
- フロントエンド(FE)
- アプリケーションの機能(フォーム、レポート、VBAモジュールなど)を格納します。各開発者は、このFEファイルのローカルコピーを自身のPCに持ち、BEファイルにリンクして作業します。
なぜ分離が必要なのか?
この分離によって、以下のメリットが得られます。
- データ保護と整合性の確保
- ユーザーはBEファイルに直接アクセスせず、FEファイルを通じてデータを操作するため、誤操作によるデータ破損のリスクが減ります。
- 開発時の競合回避
- 各開発者は自身のFEファイルでVBAコードやフォームデザインを自由に修正・テストできます。これにより、複数人での同時編集による「書き込み競合」のリスクを大幅に軽減できます。
- メンテナンス性の向上
- FEファイルのみを更新すればよいので、機能追加や修正時の展開が容易になります。
Accessの「データベース分割ウィザード」を使えば、簡単にFE/BE分離を実行できます。
2. VBAソースコードのバージョン管理を徹底する
Accessファイルのままではバージョン管理が難しいですが、VBAコードはテキストファイルとして管理できます。
VBAソースコードのエクスポートとGitでの管理
VBAモジュール、フォーム、レポートのコード部分をテキスト形式(.bas, .cls, .frmなど)でエクスポートし、これらのテキストファイルをGitなどのバージョン管理システムで管理することが可能です。これにより、コードの差分や履歴の確認が容易になり、以下のようなメリットが得られます。
- 変更履歴の追跡
- 誰が、いつ、どのようなコード変更を行ったか明確に把握できます。
- コードレビュー
- 他の開発者がコードの変更内容を確認し、問題点がないかチェックできます。
- 問題発生時の復旧
- バグや意図しない挙動が発生した場合でも、過去の安定したバージョンに戻すことが可能です。
エクスポートの自動化ツールを活用
コード部分のテキスト化がエクスポートで実現できるにしても、手動でのエクスポート/インポートは手間がかかり、ミスにつながる可能性があります。そのため、以下のツールや方法をとります。
- Ariawase
- オープンソースのVBAライブラリです。vbac.wsfというツールを使ってAccessファイルの中身をテキストファイルとして分解(decombine)してくれます。変更後には、テキストファイル群をAccessファイルに再度結合(combine)することも可能です。コードだけでなく、テーブル定義のエクスポートもできる点が優れています。
- VBAコードによるエクスポート自動化
Application.SaveAsText
メソッドを利用して、VBAコードで全てのモジュールやフォームを定期的にテキスト出力するマクロを作成することも有効です。例えば、以下のようなVBAコードを記述することで、カレントプロジェクトの全てのモジュールを特定のディレクトリに.basファイルとしてエクスポートできます。
Public Sub ExportAllModules()
Dim accObj As AccessObject
For Each accObj In CurrentProject.AllModules
DoCmd.Save acModule, accObj.Name
Application.SaveAsText acModule, accObj.Name, "Export\" & accObj.Name & ".bas"
Next
End Sub
フォーム・レポートデザインの「不要な差分」問題への対処
Accessのフォームやレポートは、デザイン部分が完全にテキスト化できない上、何も変更していないのに差分が生じるという特有の問題があります。これはGitのコミット履歴にノイズを発生させるため、チーム内で「デザインビューで開いて保存しただけの変更はコミットしない」といった明確な運用ルールを設けることが重要です。
3. シンプルな開発ワークフローを確立する
2〜3人の少人数チームであれば、複雑なワークフローは不要です。フィーチャーブランチ戦略が適しています。
- メインブランチ
- 常に安定稼働している最新のコードを保持します。
- フィーチャーブランチ
- 各開発者は、機能追加やバグ修正を行う際に、メインブランチから新しいフィーチャーブランチを作成します。
- ローカルでの作業
- 開発者は自身のフィーチャーブランチ上で、ローカルPCのFEファイルを使って作業を進めます。
- 頻繁なコミット
- コード変更を行ったら、VBAオブジェクトをテキスト形式でエクスポートし、頻繁にGitにコミットします。
- コードレビューとマージ
- 開発が完了したら、プルリクエストを作成し、他のメンバーにコードレビューを依頼します。レビューが承認されたら、メインブランチにマージします。
4. 競合解決のための運用ルール
FE/BE分離である程度の競合は防げますが、それでも発生する可能性はあります。
- VBAモジュールの競合
- テキストファイルとしてエクスポートされたVBAコードの競合は、Gitのマージツールを使って手動で解決します。VBAの構文を壊さないよう慎重に行いましょう。
- Access内部の「書き込み競合」
- 競合発生時の対応手順(例:誰が解決するか、変更の優先順位)をチーム内で明確に定めておきます。また、未完成な状態の変更を共有リポジトリに登録するのは避けるようにします。
- データの最新化
- フォームを開く際や特定の操作の前に
Me.Requery
などを利用し、データを最新の状態にリフレッシュすることも競合を減らすのに役立ちます。
- フォームを開く際や特定の操作の前に
5. 補助ツールで開発を効率化する
- Rubberduck VBA
- VBEに統合されるオープンソースのアドインです。コード検査(静的コード分析)、リファクタリング、ユニットテストフレームワークなどにより、VBAコードの品質と保守性を大幅に向上させます。特にユニットテストは、変更が既存機能に影響を与えないかを確認する上で非常に重要です。
- Accessファイル比較ツール (ColorfulRingなど)
- Accessファイル同士を比較し、フォームやレポートのデザイン部分の相違点を視覚的に表示するツールです。「不要な差分」問題が発生した場合でも、このツールで実際の変更内容を確認し、変更履歴の追跡を補完できます。
6. その他の工夫
- コーディング規約の確立と遵守
- 命名規則、インデント、コードの整形ルールなどをチーム全体で統一し、遵守することで、コードの可読性が向上し、他のメンバーがコードを理解しやすくなります。
- 適切なコメントの記述
- コードの目的、複雑なロジック、プロシージャや関数のヘッダーなどに、意味のあるコメントを記述することで、将来の保守や他の開発者による理解が容易になります。
- 外部ドキュメンテーションの維持
- プロジェクトの概要、データフロー図、テーブル定義、デザイン変更履歴などを、Gitリポジトリ内のMarkdownファイルなどで管理します。Accessファイル比較ツールで出力した差分レポートも活用できます。
まとめ – 少人数・低コスト開発を成功させるために
少人数で開発コストを抑えながらAccessシステムを長期的にメンテナンスしていくには、ご紹介した管理方法を組み合わせることが非常に効果的です。大企業のような厳格なCI/CD(継続的インテグレーション・継続的デリバリー)パイプラインを構築するのは、リソースやコストの観点から現実的ではないことがほとんどでしょう。しかし、今回お伝えした「VBAソースのテキスト化」「自動化ツールの活用」「FE/BE分離」「Gitブランチ戦略と運用ルール」といった基本をしっかりと取り入れるだけでも、開発の質と効率は格段に向上します。
手軽に始められるAccessだからこそ、きちんとした管理体制を築くことで、将来的なシステムの成長と安定稼働に繋がります。ぜひ今日からでも、これらのヒントをみなさんの開発現場に取り入れてみてください。
本日も最後までお読みいただきありがとうございました。
それでは、よいAccess開発ライフを!