FileMaker等レガシー業務システムの限界と移行判断　属人化と保守終了のリスク

FileMaker等で作った業務システムの限界は、この3つの兆候で見えてきます

作った担当者にしか触れない、バージョンアップのたびに動かなくなる、スクリプトが年々複雑になって誰も全体を把握していない。この3つが揃ったら、そのシステムは延命ではなく移行を検討する時期に入っています。

FileMakerやそれに類する脱Access系のデータベースツールは、専門知識がなくても業務システムを内製できる手軽さが強みです。中小企業では総務や営業の担当者が独学でテーブルを組み、必要に応じてスクリプトを足しながら10年、15年と使い続けているケースが珍しくありません。この手軽さこそが後になって重荷に変わります。作った本人は自分のやり方で組んでいるので、他の人が見ても構造が読み取れないのです。

兆候	具体的な状態	放置した場合のリスク
属人化	触れる人が社内に1人しかいない	退職・休職と同時に保守停止
バージョン対応の限界	OSやOffice更新のたびに不具合が出る	ある日突然全社の業務が止まる
スクリプトの複雑化	条件分岐が積み重なり誰も全体を追えない	小さな修正でも影響範囲が読めない

3つとも「今すぐ壊れる」わけではないので後回しにされがちですが、進行性の劣化です。次の章で、なぜここまで属人化が進んでしまうのかを構造的に見ていきます。

なぜ属人化するのか　現場でブラックボックスが育つ仕組み

属人化は担当者の能力不足ではなく、内製システムが育つ過程で必然的に起きる構造的な現象です。

内製の業務システムは、最初は小さな表計算の延長として始まります。顧客管理を1テーブルで作り、在庫管理を1つ足し、請求書出力のスクリプトを追加し……という具合に、業務の要望が出るたびに担当者がその場で継ぎ足していきます。設計書を書く工程は最初から存在しないので、「なぜこの条件分岐にしたか」「このスクリプトはどの画面から呼ばれているか」という判断の根拠は担当者の頭の中にしか残りません。私たちが受託開発の現場でFileMaker系システムの引き継ぎ相談を受けるとき、まず驚かれるのが「ドキュメントが1枚もない」ことの多さです。これは担当者が怠けていたわけではなく、日々の運用に追われながら独学で拡張してきた結果、書く余裕も書く習慣もなかったというのが実情です。

さらに厄介なのが、スクリプトの内部で複数の条件分岐が絡み合う「読めば読むほど分からなくなる」状態です。修正が入るたびに例外処理が1つ足され、その例外にまた例外が重なる。担当者本人は経緯を覚えているので迷わず触れますが、後任者は最初の1行から読み解く必要があり、下手に触ると別の画面の動作が壊れることもあります。この状態になると、修正依頼を受けても「触ると何が起きるか分からないので放置する」という判断が合理的になり、システムは事実上凍結します。

保守終了リスクが顕在化するタイミング　退職・OS更新・ハードウェア世代交代

属人化リスクは普段は表面化しません。表面化するのは決まって「担当者が抜ける」「動作環境が変わる」という外部要因が重なったタイミングです。

最も多いのが担当者の退職・異動です。長年触ってきた担当者が抜けると、その日から新しい要望への対応が止まります。軽微な不具合ですら「触れる人がいない」という理由で放置され、業務側が手作業や紙運用に逆戻りするケースも見られます。次に多いのがOSやハードウェアの更改です。PCの入れ替え、OSの大型アップデート、周辺機器やプリンタドライバの世代交代のタイミングで、長年安定稼働していたスクリプトが突然エラーを吐くようになる。開発環境がすでに古いバージョンのままアップデートされておらず、最新環境との互換性検証が一切行われていないためです。ソフトウェア自体のサポート方針変更も同様で、旧バージョンのサポートが終了し、最新版への移行が求められた瞬間に、古い設計のまま積み上げてきたスクリプトが軒並み非互換になることがあります。

共通しているのは、これらのタイミングは事前に予測できるという点です。担当者の年齢や勤続年数、社内のPC更改サイクルは把握できる情報です。壊れてから動くのではなく、これらの節目が見えている段階で現状把握を進めておくことが、選択肢を残したまま判断するための唯一の方法です。

データ移行で必ずつまずく3つの落とし穴　受託開発の現場知見

いざ移行を決めても、データ移行の工程で想定外の手戻りが発生するのがこの手のシステムの典型的なパターンです。

1つ目の落とし穴は「テーブル定義書が存在しない」ことです。長年の運用で追加されたフィールドの中には、当初の用途とは違う目的で流用されているものが混ざっています。例えば「備考」欄に本来は別の管理番号を手入力で運用していた、といった実態は、画面を触っている担当者以外には分かりません。移行前に全フィールドの実際の使われ方を洗い出さないと、新システムへの移行後に「あの情報がどこにも入力できない」という事態になります。2つ目は文字コードやデータ型の不整合です。長年の運用の中で日付を文字列で入れていたり、同じ意味の値が「済」「完了」「Done」のように表記ゆれを起こしていたりすることが多く、そのまま移行すると新システム側での検索・集計が正しく動きません。3つ目はスクリプトに埋め込まれた業務ロジックの取りこぼしです。承認フローの分岐条件や自動計算のルールがスクリプトの中にしか書かれておらず、画面の見た目だけを真似て作り直すと、実際に運用しているはずの例外処理が新システムから抜け落ちてしまいます。

これらはどれも「データを移せば終わり」という発想では防げません。移行の前に現行システムの構造とデータの実態を棚卸しする工程を独立させて置くことが、手戻りを減らす最も確実な方法です。

移行の選択肢と判断基準　Webアプリ化・クラウドDB化・パッケージ移行・延命

移行先の選択肢は大きく4つに分かれ、それぞれ向き不向きがあります。延命という選択肢も含めて、条件で機械的に判断するのが手戻りを減らすコツです。

選択肢	向いているケース	費用感の目安（要見積り）
Webアプリ化（スクラッチ開発）	業務が独自性の強い運用で、既製品に業務を合わせたくない	100万円台後半〜500万円超
クラウドDB・ノーコード基盤への移行	業務ロジックが比較的シンプルで、標準機能でも代替できる	数十万円〜100万円台
パッケージ・業務システムへの乗り換え	業界標準に近い業務で、既製品の機能で十分足りる	初期費用＋月額利用料
延命（現状維持）	直近の退職・環境更改リスクが低く、当面は運用継続できる	保守体制の整備費のみ

判断基準は「業務の独自性」と「担当者依存の深さ」の掛け合わせで決まります。業務ロジックが複雑で自社独自の運用が多いほどWebアプリ化に寄り、逆に一般的な業務であればあるほどパッケージやクラウド基盤への乗り換えが費用対効果に優れます。延命という選択も間違いではありませんが、それは「保守できる体制を別途整える」こととセットでなければ、単なる問題の先送りになります。属人化を解消せずに現状維持を選ぶと、次に担当者が抜けたときに同じ問題がより深刻な形で再発します。

移行を検討すべき最初の一歩

移行を決める前に、まず自社の現状を数字と事実で把握することから始めます。

具体的には次の3ステップです。1つ目は「触れる人は誰か」「その人がいなくなったら何が止まるか」を洗い出す属人化の棚卸し。2つ目はテーブル・スクリプトの構造を一覧化し、業務ロジックがどこに埋め込まれているかを可視化すること。3つ目は、社内のPC・OS更改サイクルや担当者の状況から「あと何年、今のまま運用できそうか」を見積もることです。この3つが揃えば、延命するにせよ移行するにせよ、根拠を持って判断できます。

どこから手をつければいいか自社だけでは判断がつきにくい場合は、初月無料の経営AI診断で現状のシステム構成と属人化リスクを可視化し、延命と再構築のどちらが自社に合うかを一緒に整理するところから始めるのも一つの方法です。診断は現状把握が目的なので、いきなり大きな開発を前提にする必要はありません。

まとめ

FileMaker等で作った業務システムの限界は、属人化・バージョン対応の限界・スクリプトの複雑化という3つの兆候で見えてきます。これは担当者の能力の問題ではなく、内製システムが年月をかけて育つ過程で必然的に起きる構造的なリスクです。保守終了リスクは担当者の退職やOS・ハードウェアの更改というタイミングで顕在化し、そのときにはもう選択の余裕がありません。動いているうちに現状を棚卸しし、延命と移行のどちらが自社に合うかを事実ベースで判断しておくことが、最も費用を抑えて次の一手を打つ方法です。判断に迷う場合は、初月無料の経営AI診断で現状の可視化から相談してみてください。

よくある質問

FileMakerの保守を担当者が辞める前にやっておくべきことは？

まずスクリプト一覧とテーブル構造の棚卸しです。誰も読めないスクリプトが1本でもあると引き継ぎは失敗します。次に、変更履歴とバージョン情報を1枚のドキュメントにまとめ、担当者の頭の中だけにある判断基準（なぜこの条件分岐にしたか）を言語化します。時間はかかりますが、退職後に緊急対応で数倍のコストを払うより安く済みます。

FileMakerからWebアプリに移行すると費用はどれくらいかかりますか？

現状の機能をそのまま置き換える程度の規模なら、要件整理からリリースまでで100万円台後半〜300万円台が目安です。帳票・外部連携・複雑な承認フローが多いと500万円を超えることもあります。金額は「今の機能を全部移す」か「本当に使っている機能だけ移す」かで大きく変わるため、まず現行システムの利用実態を棚卸しすることが費用を抑える近道です。

まだ動いているシステムなのに、今すぐ移行を検討する必要はありますか？

動いているうちに検討を始めるのが最も安全です。保守終了リスクが表面化するのは、たいてい担当者の退職やOS・ハードウェアの世代交代がきっかけで、そのときにはもう選択の余裕がありません。動いている今のうちに現状把握と移行の当たりをつけておけば、実際に問題が起きたときに慌てず判断できます。

FileMaker以外の脱Access系ツールでも同じ問題は起きますか？

はい。FileMakerに限らず、内製の担当者が一人でスクリプトを書き込みながら育てたシステム全般に共通する構造的なリスクです。ツールの種類よりも「誰か一人が全体像を把握している状態が何年も続いている」という運用の仕方そのものが原因なので、ツールを変えるだけでは解決しません。

関連記事

• Accessで作った業務システムの限界と移行判断　属人化とサポート終了のリスク — 関連: 脱Access系ツール全般の移行判断との比較
• 業務システムの属人化を放置すると起きること 引き継ぎ・保守体制の作り方 — 関連: 属人化リスクそのものの構造と保守体制の作り方
• ExcelマクロVBAの属人化リスクと引き継ぎ 可視化と移行判断の手順 — 関連: スクリプトのブラックボックス化という共通構造
• ノーコードツールのサービス終了・値上げリスクと乗り換え判断基準 — 関連: 保守終了リスクという観点での類似テーマ
• 中小企業のAI導入 費用相場と内訳 初期費用から運用コストまで実例で解説 — 関連: 移行後の投資判断を費用相場から検討する視点