AccScan
費用

Access移行の依頼先の選び方|失敗しない発注先チェックリスト

Access移行を外部に依頼する際、依頼先の種類より「Accessを解析できる体制があるか」が先決です。進め方の4パターンと選定の5ポイント、避けたい発注先の兆候チェックリスト6項目を解説します。

まずは、自社のAccessが「解析できるか」を無料で確認できます。

約2分・ファイル送信不要・発注義務なし

結論:依頼先の種類より「Access固有の実績」で選ぶ

当社の支援経験では、Access移行で躓く要因の一つとして、「Webシステム開発の実績は豊富だが、Accessの解析経験が薄い業者」への依頼が挙げられます。Accessには業務ロジックがVBAやマクロに埋もれていることが多く、現行動作を完全に把握しないまま設計に入ると、移行後に「帳票の計算が合わない」「あの処理が動かない」という問題が出ます。

依頼先の種類(個人開発者・受託開発会社・パッケージベンダー・クラウドSaaS導入支援)は後から確認すればよく、まず「Accessを解析できる体制があるか」を確かめることが先決です。

移行の進め方4パターンとそれぞれの向き不向き

当社では、Access移行の進め方を主に次の4パターンに整理しています。どれが正解というわけではなく、自社のシステム規模と社内体制によって向き不向きがあります。

パターン向くケース注意点
個人開発者(フリーランス)に依頼テーブル数が少なく、1人の担当者が全体を把握できる小規模システム。予算を抑えたい場合。当社の経験上、代替体制が取りにくいケースがある。途中で連絡が途切れた場合のリスクを事前に確認しておくことをおすすめします。
受託開発会社に依頼業務要件が複雑で、帳票・帳票ロジック・他システム連携まで含む中〜大規模システム。当社の支援経験では、会社によってAccess固有の経験に差がある。VBAを読んだことがない会社に渡すと分析工程が長引くことがある。
ローコード/ノーコード製品(kintone・Power Apps等)の導入支援会社に依頼業務が標準的で、製品の標準機能に業務を合わせられる場合。Accessの業務ロジックを製品の仕様に合わせて変える前提になる。当社の支援経験では、製品の標準機能では既存の帳票や計算ロジックをそのまま再現できず、設計変更が必要になるケースがある。
SaaSやノーコードツールを使って自社で移行社内にプログラミングできる担当者がいて、移行先のAPIやノーコードツールを自力で使える場合。現行Accessの解析はほぼ自力になる。複雑なVBAロジックが埋まっていると想定外の工数がかかる。

移行先ごとの特徴と費用感はAccessの移行先を比較に整理しています。

依頼先を選ぶ5つの確認ポイント

見積もりを依頼する前に、次の5点を確認しておくと選定の精度が上がります。当社が移行支援で実際に重視している観点です。

1. Accessの解析・現行踏襲の実績

「Accessを見せてもらったことがある」と「VBAロジックを読んで業務要件に戻せる」は別の話です。具体的には、「過去に移行した際、移行前後の動作差異はどのように検証しましたか」と聞いてみると、相手の経験の深さが分かります。動作比較の手順や差異管理の方法をすぐ答えられる会社は、実際にやってきている可能性が高い。

仕様書がないAccessや、VBAソースを確認できないaccde/mde形式、担当者不在のシステムを扱った経験があるかどうかも、確かめておく価値があります。詳しくはaccde/mdeで中身が見られないAccess|解析して移行する方法を参照してください。

2. 移行後の保守体制

当社の支援経験では、移行本番後の最初の1〜2か月に想定外の動作差異が判明するケースがあります。「移行後の不具合対応はどうなりますか」に対し、保証期間の範囲・対応窓口・費用の有無が明確に答えられるかを確認します。「なにかあれば相談してください」だけでは心もとない。

3. 見積もりの透明性

見積もりの中で「その費用は何の作業にいくらかかるか」が分かる内訳になっているかを見ます。「一式○○万円」だけでは、後から追加請求の根拠にもなりかねません。少なくとも解析・設計・開発・テスト・移行の工程別に分かれているかどうかが最低ラインです。

相見積もりを取る際は、総額だけでなく対象範囲(どのオブジェクトが移行対象か、データ移行・テスト・操作マニュアルは含むか)を同じ条件で比べてください。条件が違う見積もりを金額だけで並べても意味がありません。費用の見方についてはAccess移行の費用相場に詳しく書いています。

4. プロジェクト推進の担当者構成

「窓口担当」と「実際に作業する技術者」が別々の場合、窓口経由で伝わるまでに要件が変わることがあります。技術的な質問を窓口担当に投げたとき、即答できるかどうかが一つの目安です。小〜中規模のAccess移行では、要件ヒアリングから実装まで同じ担当者が見ている体制のほうが品質が安定しやすい。

5. 移行範囲の確認と「仕様凍結」の合意

移行中に「ついでにこの機能も追加したい」が続くと、スケジュールも費用も膨らみます。移行フェーズでは「現行動作の再現」に集中して、改善は移行後に別途対応する、という合意を最初に取れる業者のほうが進行管理の経験があると見ていいです。

発注側が丸投げできない準備

依頼先を決めたあと、業者に渡すべき情報は発注側でしか準備できません。以下が揃っていないと、解析の精度が落ちます。

  • Accessファイル本体(.mdb / .accdb / .mde / .accde)と、それが依存する外部ファイル(リンクテーブル先のExcelやCSV)
  • 業務の流れの概説(誰がいつ何のためにどの画面を使うか)
  • 印刷して使っている帳票の現物サンプル
  • 「ここだけは絶対に変えたくない」動作の箇条書き
  • 移行期限と、現行Accessを止められるタイムリミット

業務フローの整理方法はAccess移行前の業務フロー調査が参考になります。

現行Accessのファイルが解析できる状態かどうか分からない場合は、無料の解析可否チェックから確認できます。解析可否の判断だけなので、発注の義務はありません。

避けたい発注先の兆候チェックリスト

以下に1つでも当てはまる場合は慎重に判断することをおすすめします。当社の実務経験から見えてきたパターンです。

兆候なぜ問題か
「Accessは見たことない」と正直に言わず、提案書だけ立派解析フェーズで詰まり、スケジュール遅延につながりやすい
Accessを渡す前に「要件書を作ってください」と言う要件書が作れない(仕様書がない)ことを前提にした依頼ができない
見積もりが一式表示で内訳がない後から追加請求が来やすい。追加の根拠にされるリスクがある
移行後の保守を「別途ご相談」とだけ言う移行後の不具合対応が有償か無償か、誰が窓口か、不明なまま本番を迎える
「全部クラウドにすれば解決します」と最初から移行先を決め打ち現行Accessの業務要件を確認する前に答えを出している。帳票の複雑さを過小評価しがち
実績事例が「導入支援」ばかりで移行(既存システムの置き換え)がない新規構築と移行は要件の把握方法が異なる。現行踏襲の経験が薄い

よくある質問

Q. 相見積もりは何社取ればいいですか。

2〜3社が現実的です。依頼の準備(ファイル提供・業務説明)に時間がかかるため、5社以上に同時に声をかけると発注側の負担が増えます。まず1〜2社でヒアリングして、見積もりの粒度や質問の内容から信頼度を判断し、追加で比較する、という順序が無難です。

Q. 個人開発者と会社、どちらが安全ですか。

規模次第です。当社の経験上、テーブルが10本以下で業務が単純なケースは、個人開発者にも依頼しやすい傾向があります。ただしVBAや外部連携の複雑さも合わせて確認が必要です。一方、複数業務にまたがる中〜大規模システムでは、開発中に担当者が変わっても引き継げる体制があるかどうかが重要なので、組織としての受け皿がある会社のほうが安心できることが多い。ただし会社でも担当者が1人だけ、というケースはあるので確認が必要です。

Q. Access移行で失敗するのはどんなケースですか。

当社の支援経験では、現行Accessの解析が不十分なまま設計に入るケース、一括移行でユーザー検証の時間を確保しないケース、帳票の複雑さを後から発見するケースが見られます。移行失敗の典型パターンについてはAccess移行が失敗する5つの典型パターンと回避策に詳しくまとめています。

Q. 段階移行(部分移行)を前提に依頼できる会社はどう見つけますか。

「一括移行と段階移行のどちらが向きますか」と最初に聞いてみると分かります。自社の状況を確認する前から答えを出す会社は、判断の根拠を確かめてください。段階移行の設計経験の有無が答えから見えてきます。段階移行の考え方は全面移行しない選択肢も参考にしてください。

触れないAccessが「診断できるか」だけ、確かめませんか。

顧客データは送信不要。発注の義務もありません。

約2分・ファイル送信不要・発注義務なし/説明はオンライン・売り込みはしません