パッケージ導入のフィット＆ギャップ分析：カスタマイズを減らす方法

フィット＆ギャップ分析は、パッケージソフトやSaaSの標準機能と自社の業務を突き合わせ、そのまま使える部分（フィット）と合わない部分（ギャップ）を洗い出し、ギャップをどう埋めるかを決める作業です。分析の目的は、ギャップをすべてカスタマイズで埋めることではありません。業務をパッケージに合わせるのか、設定や周辺の仕組みで補うのか、本当にカスタマイズが必要なのかを、一つずつ理由をもって判断することにあります。

この記事は、販売管理、生産管理、会計、人事給与、顧客管理などのパッケージやSaaSの導入を検討している企業の担当者に向けて書いています。フィット＆ギャップ分析の進め方、ギャップの分類と対応方針の決め方、カスタマイズを増やさないための工夫、分析でよく起きる失敗と避け方を、順を追って説明します。

結論を先に言うと、ギャップは「業務をパッケージに合わせる」「設定・帳票・運用で補う」「パッケージの外に周辺の仕組みを作る」「パッケージ本体をカスタマイズする」の順に検討し、後ろに行くほど慎重に判断することが基本です。本体のカスタマイズは、自社の競争力や法令上の要件に直結する場合に限るのが、導入後の負担を抑える近道です。

フィット＆ギャップ分析とは何か

フィット＆ギャップ分析は、パッケージ導入の要件定義の中心となる作業です。パッケージには、多くの企業の業務を想定した標準の業務の流れと機能が組み込まれています。その標準と自社の業務がどの程度合っているかを、業務の単位ごとに確認していきます。

フィットとは、パッケージの標準機能や設定で自社の業務がそのまま実現できる状態です。ギャップとは、標準のままでは自社の業務が実現できない状態です。ギャップには、機能そのものがないもの、機能はあるが業務の流れが違うもの、帳票やデータの形式が違うものなど、さまざまな種類があります。

対象となるパッケージの代表は、会計や販売・購買・在庫・生産などを統合して管理するERP（統合基幹業務システム）ですが、顧客管理や勤怠管理などのSaaSを導入する場合にも、同じ考え方が使えます。

なぜカスタマイズを減らすべきなのか

パッケージの導入でカスタマイズが増えると、次のような負担が生じます。

• 導入の費用と期間が増える：カスタマイズの開発とテストに費用と時間がかかります。
• バージョンアップが難しくなる：パッケージの新しい版が出るたびに、カスタマイズ部分が新しい版で動くかを確認し、必要に応じて改修しなければなりません。SaaSの場合は、提供元の更新に合わせて自社側の追加部分を確認し続ける必要があります。
• 保守の担い手が限られる：カスタマイズした部分を理解している人がいなくなると、障害や変更への対応が難しくなります。
• パッケージを選んだ利点が薄れる：多くの企業で使われている標準の流れや、継続的な機能改善の恩恵を受けにくくなります。

カスタマイズの多いパッケージ導入は、個別開発の負担とパッケージの制約の両方を抱えることになりかねません。だからこそ、ギャップを一つずつ丁寧に扱い、カスタマイズは本当に必要なものに絞る必要があります。

フィット＆ギャップ分析の手順

フィット＆ギャップ分析は、次の手順で進めます。

1. 対象業務を一覧にする：導入するパッケージで扱う業務を、受注登録、出荷指示、請求書発行、入金消し込みのように、業務の単位で一覧にします。業務の単位は、後で一つずつ判断できる程度の細かさにそろえます。
2. 業務ごとの要件を書き出す：各業務について、現在の手順、使っている帳票、判断のルール、扱う件数、例外のケースを書き出します。現状の業務の把握には、As-Is/To-Be分析で業務システムの要件を固める進め方と注意点で説明している方法が使えます。
3. パッケージの標準の流れを確認する：パッケージの提供元や導入支援の担当者から、標準の業務の流れと機能の説明を受けます。可能であれば、デモ環境や試用環境で、自社の代表的な業務を実際に操作してみます。
4. 業務ごとにフィットかギャップかを判定する：業務の一覧に沿って、標準のままで実現できるか、設定で実現できるか、実現できないかを判定し、ギャップの内容を具体的に記録します。
5. ギャップを分類し、対応方針を決める：ギャップごとに、後述する四つの対応方針のどれを取るかを、理由とともに決めます。
6. 対応方針を関係者と合意する：特に「業務をパッケージに合わせる」と決めたギャップは、業務の変更を伴うため、現場の責任者と合意しておきます。
7. 残ったカスタマイズを見積もる：本体のカスタマイズや周辺の開発が必要なギャップについて、費用、期間、保守の負担を見積もり、必要性を再確認します。

判定は実際の業務データで行う

手順4の判定は、パッケージの機能一覧を見て「この機能はある」と確認するだけでは不十分です。機能があっても、自社の業務の流れや件数、例外のケースで使えるとは限りません。代表的な取引のデータを用意し、デモ環境で受注から請求までを通しで操作してみると、機能一覧では分からないギャップが見つかります。特に、締め処理、取り消し・訂正、分割や合算といった例外の処理は、実際に試して確認することをおすすめします。

ギャップの分類と対応方針の決め方

ギャップには、次の四つの対応方針があります。上から順に検討し、下に行くほど慎重に判断します。

業務をパッケージに合わせる判断

最初に検討するのは、業務をパッケージに合わせることです。パッケージの標準の流れは、多くの企業の業務をもとに作られているため、自社の手順よりも合理的な場合があります。ギャップとなった自社の手順について、「なぜそうしているのか」を確認し、理由が「昔からそうしている」「前のシステムがそうだった」であれば、合わせる方向で検討します。業務のやり方をそろえる進め方は業務標準化の進め方：担当者ごとに違うやり方をそろえる手順でも扱っています。

ただし、合わせることで顧客や取引先に影響が出る場合は慎重に判断します。たとえば、取引先から指定された形式の請求書を出す必要がある場合、自社の都合だけで形式を変えることはできません。

周辺の仕組みで補う判断

本体をカスタマイズする前に、パッケージの外に小さな仕組みを作って補えないかを検討します。たとえば、取引先から届く独自形式の注文データを、パッケージが取り込める形式に変換する仕組みや、パッケージから出力したデータを使って独自の集計を行う仕組みなどです。周辺の仕組みは、パッケージのバージョンアップの影響を受けにくく、パッケージを入れ替える場合にも再利用しやすいという利点があります。そのためには、パッケージがどのようなデータ連携の手段（APIやファイル連携）を提供しているかを、選定の段階で確認しておく必要があります。

本体のカスタマイズを選ぶ条件

本体のカスタマイズは、次の条件をいずれも満たす場合に限るのが目安です。

• そのギャップが、自社の競争力の源泉や、法令・契約上の要件に直結している
• 業務をパッケージに合わせる、設定や運用で補う、周辺の仕組みで補う、のいずれでも埋められない
• カスタマイズによる導入時の費用だけでなく、将来のバージョンアップと保守の負担を許容できる

加えて、カスタマイズした部分の仕様と理由を文書に残し、保守を担う会社と共有しておくことも欠かせません。

この三つを満たさないカスタマイズの要望は、もう一度ほかの方針で対応できないかを検討します。

架空の例：販売管理パッケージの導入

食品の卸売を行う会社が、販売管理パッケージを導入する場面を考えます。フィット＆ギャップ分析の結果、次のようなギャップが見つかりました。

• 営業担当ごとに見積書の様式が違う：理由を確認すると、各担当が自分で作ったExcelの様式を使い続けていただけでした。パッケージの標準様式に統一することにしました（業務を合わせる）。
• 得意先ごとに請求書の締め日が異なる：パッケージの設定で得意先ごとの締め日を持てることが確認できました（設定で補う）。
• 大手取引先から独自形式の注文データが届く：パッケージの取り込み形式と違うため、変換して取り込む小さな仕組みを外に作ることにしました（周辺の仕組み）。
• 賞味期限の短い商品について、期限の近い順に出荷する独自の引当ルールがある：パッケージの標準の引当ルールでは対応できず、品質管理と顧客との約束に直結するため、カスタマイズの候補として費用と保守の負担を見積もることにしました。そのうえで、パッケージの別の設定の組み合わせで近い動きが実現できないかも並行して確認しました。

この会社では、分析の途中で営業部門から「得意先ごとの特別価格を画面上で自由に上書きできるようにしてほしい」という要望も出ました。理由を確認すると、価格の決め方が担当者ごとにばらばらで、価格表が整備されていないことが原因でした。そこで、カスタマイズではなく価格表の整備と、パッケージの得意先別単価の設定で対応する方針とし、例外的な値引きは承認を経て登録する運用にしました。

この例のように、最初は「全部カスタマイズが必要」に見えたギャップも、理由を確認し、方針を順番に検討すると、本体のカスタマイズが必要なものはごく一部に絞られることがよくあります。

カスタマイズを増やさないための工夫

フィット＆ギャップ分析の進め方そのものにも、カスタマイズを増やさない工夫があります。

• 現状の業務からではなく、パッケージの標準から説明を受ける：自社の業務を説明してから「それはできますか」と聞くと、ギャップばかりが目立ちます。先にパッケージの標準の流れを理解し、そのうえで自社の業務との違いを確認する方が、合わせられる部分を見つけやすくなります。
• ギャップごとに理由を記録する：「なぜその手順が必要なのか」を記録しておくと、後で方針を見直すときにも判断がぶれません。
• 要望を出した人ではなく、責任者が方針を決める：現場の担当者は、慣れた手順を残したいと考えるのが自然です。方針の最終判断は、業務全体に責任を持つ人が行います。
• カスタマイズの費用を、将来の分まで見せる：導入時の費用だけでなく、バージョンアップのたびにかかる確認と改修の負担を見積もりに含めると、本当に必要かどうかの判断がしやすくなります。
• 導入後に見直す前提で始める：導入時点では判断がつかないギャップは、まず運用で対応し、実際に使ってみてから周辺の仕組みやカスタマイズを検討する、という順番も有効です。

ギャップ管理表の作り方と運用

フィット＆ギャップ分析の結果は、一つの管理表にまとめて関係者で共有します。会議の議事録やメールに判断が散らばると、後から「なぜこの業務はカスタマイズしなかったのか」を説明できなくなります。管理表には、少なくとも次の列を用意します。

管理表は、分析の期間中だけでなく、導入の設計、テスト、運用開始後まで使い続けます。テストの段階では「設定で対応」とした項目が本当に設定で実現できたかを確認し、運用開始後には「業務を合わせる」とした項目が現場で守られているかを確認します。運用開始後に新たなギャップが見つかった場合も、同じ管理表に追記し、同じ順番で対応方針を検討します。こうして判断の記録が一か所に残っていれば、担当者が交代しても、次のバージョンアップやパッケージの入れ替えの際に、過去の判断の理由をたどることができます。

よくある失敗とその避け方

• 機能一覧だけで判定する：「機能あり」と判定したのに、実際の業務の流れでは使えなかった、という失敗です。代表的な業務データでデモ環境を操作し、例外の処理まで確認します。
• 現場の要望をすべてギャップとして扱う：要望の中には、慣れや好みに基づくものも含まれます。理由を確認し、業務上の必要性がないものはギャップとして扱わない判断をします。
• ギャップの記録が曖昧：「画面が使いにくい」のような記録では、対応方針を決められません。どの業務の、どの場面で、何ができないのかを具体的に書きます。
• 業務を合わせると決めたのに教育しない：方針として「合わせる」と決めても、現場に変更の理由と新しい手順が伝わっていなければ、導入後に元のやり方に戻ろうとする動きが出ます。変更の理由と手順を説明する場を設けます。
• 選定の前に分析をしない：パッケージを決めてから分析すると、大きなギャップが見つかっても後戻りできません。候補を二つか三つに絞った段階で、主要な業務について簡易的な分析を行い、選定の判断材料にします。

フィット＆ギャップ分析のチェックリスト

• 対象業務を、判断できる細かさの単位で一覧にしている
• 業務ごとに、手順、帳票、ルール、件数、例外を書き出している
• パッケージの標準の業務の流れを説明を受けて理解している
• 代表的な業務データで、デモ環境や試用環境を操作している
• 各ギャップについて、内容と「なぜ必要か」の理由を記録している
• 各ギャップの対応方針を、四つの方針の順番で検討している
• 本体のカスタマイズについて、将来の保守とバージョンアップの負担を見積もっている
• 業務を合わせると決めた項目について、現場の責任者と合意し、教育の計画がある

よくある質問

Q. フィット率がどのくらいなら導入してよいですか？

フィットの割合だけで判断することはおすすめしません。ギャップが少なくても、それが業務の中心にある重要な部分であれば影響は大きくなります。逆に、ギャップが多くても、運用や設定で補えるものばかりであれば問題は小さくなります。ギャップの数ではなく、重要度と対応方針の内容で判断します。

Q. 分析は導入支援の会社に任せてもよいですか？

パッケージの機能の説明や設定の可否の判断は、導入支援の会社の専門分野です。ただし、業務を合わせるかどうかの判断や、業務上の必要性の判断は、自社にしかできません。自社の業務を知る担当者が分析に参加し、方針の判断に責任を持つ体制にします。

Q. SaaSの場合もカスタマイズはできますか？

SaaSの多くは、提供元が全利用者に共通の機能を提供する形のため、本体の改変はできないか、限られた範囲に限られます。その代わり、設定の幅や、APIを使った周辺の仕組みとの連携が用意されていることが多くあります。SaaSでは、ギャップの対応方針は「業務を合わせる」「設定で補う」「周辺の仕組みを作る」の三つが中心になります。

Q. パッケージではなく個別開発にすべきか迷っています。

フィット＆ギャップ分析の結果、本体のカスタマイズが必要なギャップが業務の中心に多く残る場合は、個別開発や、共通業務はパッケージで独自業務は個別開発、という組み合わせも検討に値します。分析の結果を判断材料にして比較してください。

Otsumuに相談できること

導入しようとしているパッケージやSaaSが、会計や勤怠のように業務の共通性が高い領域のものであれば、提供元や導入支援の会社の説明を受けながら、社内で分析を進めれば十分なことが多くあります。この記事の手順とチェックリストを使い、ギャップの理由を記録しながら判断してみてください。

一方で、ギャップが多く方針の判断がつかない、周辺の仕組みで補う部分の設計や開発を誰に頼めばよいか分からない、パッケージと個別開発のどちらがよいか中立の立場で検討したい、という場合は、外部の力を借りることで判断が早くなります。

Otsumuは、特定のパッケージの販売を目的としない立場で、業務とパッケージの標準を突き合わせ、合わせる部分、設定で補う部分、周辺の仕組みとして作る部分を切り分けます。周辺の仕組みやデータ連携の開発も、目的に必要な範囲に絞って行います。業務システムの開発については業務システム開発をご覧ください。費用は範囲に応じて個別にお見積もりします。

パッケージ選定の途中でも、分析で行き詰まっている段階でもご相談いただけます。30分の無料相談からご連絡ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01