Fit&Gap分析とは?
Fit&Gap分析とは、パッケージやSaaSの標準機能と自社の業務要件を突き合わせ、適合(Fit)と乖離(Gap)を洗い出す分析のこと。Gapを「カスタマイズで埋めるか、業務側を合わせるか」の判断材料になります。
実務での使い方
進め方は、要件一覧を縦軸、候補製品を横軸にしたマトリクスで「標準機能で可能/設定変更で可能/カスタマイズが必要/不可」を評価するのが基本形です。要件に優先度(必須/歓迎)を付けておくと、必須要件のFit率で候補を絞り込めます。
注意点は、Gapを全部カスタマイズで埋めないことです。改修費が膨らむだけでなく、バージョンアップのたびに追加費用が発生し、ベンダーロックインの原因にもなります。近年は業務側を標準機能に合わせる「Fit to Standard」が主流で、こだわるべきGapは自社の競争力に関わる業務だけに絞ります。
Fit&Gap分析の進め方(4ステップ)
実務の手順は、①自社の業務要件を一覧化する(業務フローと要件リスト)②パッケージ・SaaSの標準機能と突き合わせ、要件ごとにFit(標準で可能)/Gap(不可)を判定する③Gapごとに対応方針を決める(運用変更で吸収/設定・外部ツールで対応/カスタマイズ/諦める)④対応コストを見積もり、導入判断の材料にする、の4ステップです。
判定は営業デモの印象ではなく、実データを使った検証(トライアル)で行うのが鉄則です。「できます」の回答が、追加費用のかかるオプションやカスタマイズを前提にしていることは珍しくありません。
ギャップはカスタマイズで埋めない、が原則?
近年の定石は「Fit to Standard」=ギャップは原則カスタマイズではなく業務側の変更で埋める、です。カスタマイズは初期費用だけでなく、バージョンアップのたびに改修費が発生し、ベンダーロックインの原因にもなるためです。
ただし全業務を標準に合わせるのも誤りです。自社の競争力の源泉である業務(他社と違うからこそ勝てている部分)はギャップを埋める投資に値し、バックオフィスなど差別化に関係ない業務は標準に合わせる、という仕分けが本質です。Fit率(標準機能で満たせる要件の割合)は一般に8割程度が製品選定の目安と言われます。
Fit&Gap分析の表の作り方:記入例
表は1行に1要件を置き、列に「要件」「優先度(必須/歓迎)」「判定(標準で可能/設定で可能/カスタマイズ/不可)」「対応方針」「概算費用」を並べるのが基本形です。例えば営業管理ツールの選定なら、「商談ごとに見積書をPDFで出力できる」=必須・標準で可能、「自社独自の値引き承認ルートを組める」=必須・設定で可能、「旧システムの過去5年分の履歴を移せる」=必須・カスタマイズ(移行作業が別費用)、のように記入します。
判定が「カスタマイズ」「不可」の行には、対応方針として「業務を変えて標準に合わせる」「別ツールで補う」「費用をかけて改修する」のどれを選ぶかを書き、その理由も残しておきます。この表が、後から仕様変更を求められたときに「何を、なぜ諦めたか」を説明する記録になります。
要件定義とは?Fit&Gap分析との関係
要件定義とは、システム開発の最初の工程で、「システムで何を実現するか」を発注者と開発者が合意して文書化する作業のこと。ここでの認識ズレが後工程の手戻りの最大原因で、プロジェクトの成否を左右します。
Fit&Gap分析は、要件定義でまとめた要件一覧を、パッケージやSaaSの標準機能と突き合わせる工程です。要件定義の成果物がそのまま分析表の縦軸になるため、要件の抜けや優先度の付け忘れは、Fit&Gap分析の判定の誤りにつながります。
整理する内容は大きく3つで、①業務要件(業務フローがどう変わるか)②機能要件(システムが何をするか)③非機能要件(性能・セキュリティ・稼働率など)です。開発会社任せにせず、業務を知る現場担当者が参加することが品質の条件になります。RFPの段階で課題を明確にしておくと、要件定義がスムーズです。
よくある失敗は、要望をすべて「必須」にして予算とスケジュールが破綻することです。Must(必須)とWant(歓迎)を分け、初回リリースはMustに絞るのが定石です。また、性能や障害時対応などの非機能要件は漏れやすく、後から発覚すると高くつく代表例です。
要件定義で決めること:機能要件と非機能要件
要件定義で固めるものは大きく2種類です。機能要件=システムが「何をできるか」(画面・帳票・データ・外部連携など)。非機能要件=「どれくらいの品質で動くか」(性能・可用性・セキュリティ・保守性など)。見積もりと契約の土台になるため、発注側と開発側の認識合わせの中心です。
見落とされやすいのは非機能要件です。「何秒で表示されるか」「障害時に何時間で復旧するか」「誰がどこまで操作できるか」は、決めていないと完成後に揉める典型的な論点です。
要件定義の失敗パターンと対策
よくある失敗は3つです。①現場ヒアリング不足=経営層と情報システム部門だけで決め、実際に使う現場の業務と合わない②全部盛り=関係者の要望をすべて取り込み、予算・納期が膨らむ③丸投げ=「いい感じに提案してください」とベンダー任せにし、出来上がってから認識ずれが発覚する。
対策の基本は、要件に優先順位を付けることです。「必須(ないと業務が回らない)/重要(効果が大きい)/あれば良い」に仕分け、予算超過時は下から削る合意を最初に取っておきます。また、現行業務の再現を要件にせず、「この機会にやめる業務」を決めることが、コストと効果の両面で最も効きます。
要件・要求・仕様は何が違う?
システム開発では、①要求②要件③仕様の3語を段階として使い分けます。要求は利用部門が出す生の要望(「毎月の集計に3日かかっているので楽にしたい」)。要件は、その要求のうち実現すると合意した内容を、システムが満たすべき条件として整理したもの(「月次集計を自動生成し、10分以内に出力できること」)。仕様は、要件を満たすための具体的な作り方(どの画面に何の項目を置き、どのデータをどう処理するか)です。
順番が重要で、要求をそのまま仕様に落とすと失敗します。要求は矛盾していたり、実現手段まで指定していたり(「Excelのマクロで作ってほしい」)することが多く、そのまま作ると本来の目的を外すためです。要求を一度「何を実現できればよいか」という要件の形に翻訳し、手段の選択は仕様の段階に回すのが定石です。
発注側が責任を持つのは要求と要件、開発側が主導するのが仕様、という分担が一般的です。ただし要件の文書は双方の合意で確定させるものなので、「決めるのは開発会社」と考えると、後工程で「言った・言わない」が起きます。
要求→要件→仕様の順に翻訳する。要求をそのまま仕様に落とすと、手段が目的化して本来の課題が解けない。