【外注引き継ぎ】他社が作ったAccessの修正・機能追加はなぜ断られやすいのか?スムーズに保守を引き継ぐための条件
「以前、別の開発会社に作ってもらったAccess(アクセス)の調子が悪い」
「社内の業務が変わったので新しい機能を追加したいが、当時の開発会社と連絡が取れなくなってしまった」
長年Accessシステムを運用していると、このように「他社が構築したシステム」の修正やメンテナンスを、新しい別の専門業者へ依頼したいシチュエーションが出てくるものです。しかし、いざ相談してみると「他社が作ったシステムは対応できません」と断られてしまい、困り果ててしまうケースが少なくありません。
なぜ他社製のAccessシステムは引き継ぎを断られやすいのか、その理由をひも解くと同時に、別の会社へスムーズに保守を移行するための条件と準備のコツを解説します。
他社製のAccessが「お断り」されやすい2つの理由
開発会社が意地悪で断っているわけではありません。他社製のシステムを触るということには、プロだからこそ慎重にならざるを得ない特有の背景があります。
- 開発者の「独自の癖」を解読するのが難しい: Access開発は自由度が高いため、テーブルの繋ぎ方や処理(マクロやVBA)の書き方に、開発者個人の強いこだわりや「癖」が出ます。設計書がない場合、他人が作った複雑なパズルをイチから解読するような膨大な時間がかかってしまいます。
- 一部を直したことで別の場所が壊れるリスク: システムは全体が複雑に連動しています。一見、一つのボタンを修正するだけの簡単な作業に見えても、その変更が引き金となって、全く関係のない別の集計処理でエラーが発生してしまう二次災害のリスクがあるためです。
つまり、「中身がどうなっているか分からない状態」では責任を持った修正ができないため、断らざるを得ないというのが開発会社のリアルな本音です。
スムーズに保守を引き継ぐために「準備したいもの」
引き継ぎのハードルは高いものの、事前にいくつかの情報やファイルが揃っていれば、新しい開発会社もスムーズに調査を開始し、保守を引き受けることが可能になります。
条件1:Accessシステム全体の「ファイル(本体)」があること
まずは何よりも、現在動いているAccessのファイルそのものが必要です。画面だけを見せられても内部のプログラムを確認できないため、まずはファイル一式を手元に用意しましょう。
条件2:当時の「設計書」や「マニュアル」を探してみる
もし、開発当時に納品された仕様書や、画面の操作マニュアル、業務のフロー図などが残っていれば、非常に強力な手がかりになります。完璧なものでなくても構いません。当時の資料があるだけで、引き継ぎにかかる調査費用を大きく抑えることができます。
条件3:現在の「業務の流れ」と「変更したい点」を明確にする
「中身のプログラムがどうなっているか」は専門家が調査しますので、発注側としては**「このシステムを使って、今どんな実務を行っているか」**という業務側の情報を整理しておきましょう。その上で、「どこに不具合が出ているか」「どんな機能を追加したいか」を箇条書きでまとめるだけで、引き継ぎの可否判断が劇的にスムーズになります。
諦めずにまずは現状の共有から
他社製だからといって、全てのケースで引き継ぎが不可能なわけではありません。信頼できる開発会社であれば、まずは「どこまで中身が解析できるか」の現状調査(システム診断)から段階的にアプローチしてくれます。
「他社で作ったものだから……」と諦めてシステムを全て捨ててしまう前に、まずは現在のファイルや手元にある資料をプロに見せ、どのような引き継ぎや改修の手立てがあるか、一度じっくり相談してみてはいかがでしょうか。


