Fit&GapとFit to Standardの進め方｜標準機能と業務の差を判断する
KXSfourthFit&Gapは、必要な業務とERPの標準機能の適合・差分を整理する活動です。Fit to Standardは、標準的な業務や機能を出発点に、業務の進め方を検討する考え方です。本記事では、差分をすべて開発へ回さず、業務の目的から対応を判断する方法を説明します。
この記事の要点
- 標準機能を理解してから差分を判断し、知らない機能をGapにしない
- 差分には業務上の理由と代替案を添える
- 対応方針は費用だけでなく、運用と更新への影響も含めて承認する
Agenda（この記事の内容）
- Fit&GapとFit to Standardの関係
- 標準業務を理解する準備
- 差分を分類し、業務上の理由を確認する
- 対応方針を比較する
- 判断を設計とテストへ引き継ぐ
- 標準化を決めた後の作業を確認する
- よくある質問
Fit&GapとFit to Standardの関係
Fit&Gapでは、要求する業務と製品の実現方法を比べ、適合する部分と差分を確認します。Fit to Standardでは、現行の画面や手順を再現する前提を置かず、標準の業務を理解して自社がどう使うかを考えます。両者は必ずしも対立する方法ではありません。
重要なのは、何を比較の基準にするかです。現行手順をすべて固定して比較すれば、操作順や帳票の違いまで差分になります。一方、標準へ合わせることだけを優先すると、本当に必要な管理や取引条件を見落とす場合があります。
業務上の目的と制約を基準にし、標準で成立するか、業務を変えられるかを検討します。用語の使い方や工程は製品・方法論で異なるため、プロジェクト内で意味と成果物を揃えます。
標準業務を理解する準備
ワークショップには、業務を説明できる担当者、変更を判断できる責任者、製品の標準機能を説明できる人を揃えます。情シスだけで全業務を代行したり、操作担当者だけに標準化の判断を求めたりしないことが大切です。
事前に、対象取引、重要な例外、必要なデータ、確認したい管理をまとめます。標準デモでは、一連の業務がどう流れるかを見ます。画面の違いに注目し過ぎず、同じ目的を別の方法で達成できるかを確認します。
機能を知らないために差分と判断していないかも確認します。設定や別の標準機能で対応できる場合があります。ただし、説明だけで解消とせず、重要な条件ではデモや検証の結果を記録します。
| 差分の確認 | 残す情報 |
|---|---|
| 目的 | 何を実現する必要があるか |
| 重要度 | 頻度・影響・代替の可否 |
| 対応案 | 設定・業務変更・外部連携・開発 |
| 判断 | 理由・承認者・確認方法 |
| 引継ぎ | 設定・手順・テストへの対応 |
差分を分類し、業務上の理由を確認する
差分には、操作の好み、帳票の形式、業務ルール、外部との取引条件、必要な統制などがあります。同じGapでも重要度は異なります。必要な理由、頻度、処理量、対応しない場合の影響を記録します。
例えば請求書の並び順の違いと、特定の条件で請求を分けられないことは、同じ問題ではありません。前者は運用変更で対応できるかもしれませんが、後者は取引条件に影響する場合があります。見た目から業務目的へ掘り下げます。
法令や社内統制を理由とする差分も、必要な状態を具体化します。現行と同じ画面であることが必要なのか、承認や証跡が残ることが必要なのかを分けます。判断には適切な社内担当者を参加させます。
対応方針を比較する
対応の選択肢は、標準機能の利用、設定変更、業務変更、外部サービスや周辺システム、追加開発などです。複数を組み合わせる場合もあります。費用だけでなく、手作業、教育、連携、保守、更新時の検証を含めて比較します。
架空の例として、月数件の例外帳票なら手作業の補助が現実的な場合があります。一方、毎日大量に発生し照合ミスが重大なら、自動化を検討する価値があります。同じ差分でも頻度と影響で対応が変わります。
採用案には、理由、影響、担当者、確認方法を付けます。標準化を選んだ場合も、業務手順と教育の変更が必要です。「開発しない」ことで作業がなくなるわけではないため、業務側の対応を計画します。
判断を設計とテストへ引き継ぐ
差分一覧は、番号、業務、目的、差分、選択肢、決定、理由、承認者、保留事項で管理します。設定、開発、業務手順、テストケースへ同じ番号をつなぐと、判断した内容が実装されたかを追えます。
保留事項には、期限と次の工程への影響を示します。対応方針が未決のまま開発を始めると、後の変更が大きくなります。判断を急げない場合は、影響しない部分と切り分けて進めます。
また、差分の件数だけを成果指標にしないことが重要です。件数を減らすために必要な例外を消したり、細分化で数字を増やしたりしても意味がありません。導入目的に必要な業務が成立し、維持できる方式が選ばれているかで確認します。
最後に業務責任者が新しい手順で取引を進められるかを確かめます。合意した標準化をテストで再び現行へ戻そうとしていないかも確認し、変更する場合は理由と影響を再評価します。
標準化を決めた後の作業を確認する
承認の順序を現行の三段階から標準の二段階へ見直す例を考えます。画面設定だけ変えれば完了ではありません。承認者の責任、代理、差戻し、金額などの条件、証拠の保存を確認し、社内のルールと整合させる必要があります。必要な統制を満たさないなら、そのまま標準へ合わせる判断はできません。
業務変更が可能なら、誰へ説明し、どの手順書を更新し、どのテストで確認するかを計画します。関係する帳票や連携への影響も調べます。「標準で対応」という一言の裏に、自社側の作業があることを明記します。
このように標準化と追加開発を比べる際には、開発側と業務側の負担を合わせて見ます。合意した方式が現場で成立するかを練習や受入試験で確認し、成立しなければ理由を整理して再判断します。方式の正しさを先に決めつけず、目的と制約に照らして検証することが大切です。
よくある質問
Gapが多い製品は不適切ですか？
件数だけでは決まりません。差分の重要度、影響、実現方法、保守負担を見ます。細かな操作差と重要な業務の不適合を同じ一件として扱わないことが大切です。
Fit to Standardなら開発は不要ですか？
必ずしも不要ではありません。標準を理解して業務変更を検討したうえで、残る必要な差分へ適切な対応を選びます。
次に確認すること
差分一覧に「業務上の理由」「代替案」「稼働後の負担」の三つを追加して、判断を見直しましょう。
- ERPの要件定義とは？選定時の要件を具体化する進め方
- ERPのカスタマイズはどこまで必要か｜業務変更・設定・追加開発の判断
- ERPのテストと受入判定｜業務シナリオ・合否基準・残る問題の扱い
- ERPのデモで何を確認するか｜業務シナリオと質問の作り方
参考情報・編集方針
本文の手順・評価例はERP選定ラボによる整理です。事例・数値例は説明用の仮定です。製品固有の機能・条件は各社の最新資料で確認してください。
参考情報の確認日：2026年10月28日。運営方針・プロフィール
