【Access開発】属人化問題の解決策-６選-

職場でAccessの活用が進むほど、次第に顕在化してくるのが「属人化」問題です。
Accessに詳しい社員が在籍している間は問題ありませんが、その人が転勤や退職などでいなくなると、これまで使っていたツールを誰も手直しできず、業務に混乱が生じる──そんなケースは決して珍しくありません。

本記事では、こうした事態を防ぐために日頃から実践しておきたい６つの対策を、具体例を交えながら解説します。

属人化問題の概要

「属人化」とは

職場にシステム専門部署がなくても、Accessであればエンジニア以外の社員でも比較的手軽に業務用ツールを開発できます。
そして、そのツールを活用することで業務効率が向上すると、利用範囲は次第に広がり、やがて業務フロー自体がツールを前提とするようになり、なくてはならない存在となります。

具体的なツール活用事例は、以下記事でご紹介しています。

こうした取り組みは一見すると良いことに思えますが、問題は「この環境を整えているのが多くの場合、たまたまその職場にいたAccessに強い社員である」という点です。

しかし、その社員がずっと職場に居続ける保証はありません。転勤、体調不良による長期休暇、そしていずれは退職など、さまざまな理由で不在になる可能性があります。

そうなったとき、

• 必要不可欠な業務用ツールに不具合が発生したら、誰が対応するのか？
• 使い勝手の改善や法改正に伴う改修は、誰が担当できるのか？

業務フローの前提となっているツールを管理できる人が突然いなくなれば、当然混乱が生じます。
このように「特定の社員しか対応できない状況」を 属人化問題 と呼びます。

なお、これはAccessに限らず、あらゆるツールやシステムの活用に共通する課題です。

属人化が起きやすい要因

特定の社員が自発的に取り組んでいる

冒頭でも述べたとおり、属人化につながる最大の要因は「Accessが得意な社員が自発的に改善を進めてしまうこと」にあります。
たとえ上司から業務改善の指示を受けて着手した場合でも、Accessを活用する手段を自ら選んで進めているのであれば、やはり属人化のリスクは残ります。

つまり、組織的な仕組みがなく、個人を中心に進められていること自体が、属人化を招く根本的な原因なのです。

個人の取り組みは一見ありがたいものですが、裏を返せば属人化の温床にもなります。ここでは、そうした取り組みが具体的にどのような問題要因につながっているのかを整理してみましょう。

属人化を決定付ける具体的な要因

これらは本来、ツール開発において一般的に実施されている事項です。きちんと取り入れることで、特定の個人に依存することなく、ツールの保守・メンテナンスを持続的に行える可能性が高まります。

つまり、属人化を解消するための具体策とは、上記の項目を一つずつ整備していくことにほかなりません。

属人化の解消策

①　設計書を作成する

一般的なシステム開発では、「基本設計」や「詳細設計」といった工程があり、その中でさまざまな設計書が作成されます。これらはクライアントへの説明資料であったり、プログラマーへの指示書であったりと、用途に応じた重要な役割を担っています。

Accessを用いたツール開発でも、この考え方は非常に重要です。設計書を用意しておけば、開発中の情報共有が円滑になるだけでなく、作成者が不在になった場合でも後任者が設計内容や意図を理解できます。さらに、自分自身であっても時間が経つと記憶が薄れるものなので、その意味でも設計書は有効です。

こちらの記事では、テーブル設計書の具体例を解説しています。

②　命名規則を策定する

命名規則とは、Accessで作成する各種オブジェクトに対してあらかじめ決めておく名前の付け方のルールを指します。思いつきで名付けるのではなく、事前に定めたルールに従って一貫性を持たせることが大切です。

なぜなら、テーブルやクエリの名前は、クエリ内やフォーム・レポートのレコードソース、さらにはVBAコード内など、さまざまな場所で利用されます。統一されていない名前は非常に分かりにくくなり、特に後任者がAccess内部を解析する際には余計な時間と手間を要する原因となります。

おすすめの命名規則については、以下の記事で詳しく解説しています。

③　バージョン管理を行う

Accessで作成したツールは、職場で利用が広がるほど、ユーザーから機能追加や操作性向上の要望が寄せられるようになります。また、法律改正など外部要因によって改修を余儀なくされるケースもあるでしょう。その結果、同じツールでありながらバージョン違いが乱立し、職場に蔓延してしまうことがあります。

ツールの管理が適切に行われていないと、「どれが最新版なのか」が分からなくなり、利用者ごとに異なるバージョンを使ってしまう恐れがあります。特に多人数で共有するツールでは、全員が最新版を使っていないことで思わぬエラーが発生し、業務に大きな支障をきたすこともあります。

こうした状況を防ぐには、「バージョン管理」を徹底することが重要です。
バージョン管理とは、運用開始時の初代から順に世代を一覧化し、各世代ごとの改修内容を明記して管理する方法です。これにより、不具合が発生した場合でも対応すべき対象が明確になり、トラブルシューティングがスムーズになります。

④　開発ルールを策定する

前述の①〜③はいずれも属人化を防ぐために重要な取り組みですが、これらを継続的に実践するためには、開発ルールをまとめたマニュアルを作成することを強く推奨します。

マニュアルには大きく分けて2種類あります。

• 利用者向け操作マニュアル … ツールの操作方法など、ユーザーが使用するための説明資料
• 開発者向け開発マニュアル … 開発時のルールや決め事をまとめた資料

本記事で推奨しているのは、後者の 「開発者向けマニュアル」 です。これを整備しておけば、複数人での開発においても一定のルールに基づいた統制が取れ、担当者が入れ替わっても安定した品質を保ちやすくなります。

開発者向けマニュアルに記載すべき内容は、前述の①〜③（設計書、命名規則、改修履歴）に加えて、以下のような多岐にわたる項目が考えられます。

• 開発手順
• Accessの設定方針
• 関連ファイルの保存場所
• 使用するテンプレート
• VBAコーディングルール

これらをあらかじめ明文化しておくことで、属人化を防ぎ、長期的に安定した開発体制を維持できるようになります。

⑤　複数人体制を構築する

Access開発を担当していた社員が転勤や退職でいなくなった場合でも、前述の①〜④を整備しておけば、後任者が引き継ぎやすくなるのは事実です。

しかし、体調不良などで担当者が突然欠勤した場合はどうでしょうか。
その日だけとはいえ「ツールに関する対応が一切できない」という状況では、業務が滞ってしまいます。特に、不具合対応など緊急性の高いケースでは、深刻な問題となりかねません。

このような日常業務レベルでの属人化を回避するには、複数人で対応できる体制をあらかじめ作っておくことが重要です。
といっても、システム専門部署を新設するような大掛かりな話ではありません。規模に応じて2〜3名の小さな班やチームを作るのが理想ですし、人員確保が難しい場合でも、複数名にサブ業務として一部の役割を持ってもらうだけでも効果があります。

Accessによるツール開発や保守・メンテナンスを複数人で担える体制を構築できれば、属人化によるリスクの多くは大きく軽減されるでしょう。

⑥　スキル向上施策を実行する

前述の⑤で複数人体制を整えたら、次に取り組んでほしいのが担当者のスキル向上施策です。
Accessに詳しい社員のもとに未経験者が加わるケースは多く、知識やスキルの差が大きいままだと属人化は解消されません。チーム全体でスキルレベルを底上げし、均一化していくことが重要です。

具体的な施策としては、以下のようなものが考えられます。

• 研修マニュアルの整備
• 定期的な勉強会の開催
• 担当する業務レベルの段階的な調整（未経験者にいきなりVBAコード解析など高度な作業を任せない）

経験者が未経験者を計画的に育成していくことで、チーム全体の対応力が向上します。その結果、経験者自身も休暇を取りやすくなり、業務をより安定的に運用できるようになります。

Accessを段階的に学ぶための学習ロードマップについては、こちらの記事でも解説しています。

まとめ

Accessは個人でも手軽に開発できる点が大きな利点ですが、その裏返しとして属人化という問題が生じやすくなります。
本記事で紹介したように、属人化を防ぐためには、さまざまなルールや仕組みを整備する必要があります。これは「個人で自由に開発できる」というメリットに、ある程度の制限を設けることにもつながります。

そのバランスをどう取るかは、職場におけるAccess活用の度合いや、業務フロー上の位置づけ、人的リソースなどによって異なります。
ぜひ自社・自部署の状況に合わせて最適な方法を検討し、安定したAccess活用につなげてください。