フィット&ギャップ分析(Fit&Gap分析)とは、「自社の要件」と「パッケージやSaaS等の機能」を比較し、パッケージやSaaS等が自社の要件をどの程度網羅しているのかを確認する取り組みのこと。
フィット&ギャップ分析の概要と必要性
フィット&ギャップ分析とは、その言葉の通りパッケージやSaaSと自社要件の「適合度合い(fit)」と「乖離度合い(gap)」を測るものです。システムを導入する際には、自社の要件として「システムに求める機能」や「必要な画面」、「連携するシステム」などの要素を整理します。一方で、パッケージやSaaSなどのいわゆる「既製品」においては、各社の製品により備えている機能や画面はバラバラです。製品によっては自社の要件をほぼ網羅しているケースもあるでしょうし、一方で自社の要件に全く対応できない製品も存在するでしょう。フィット&ギャップ分析を行うことで、それぞれの製品が自社の要件をどの程度満たしているのか、把握することができます。
パッケージやSaaSを導入する以上、カスタマイズは最小限にしたいはずです。よって、できるだけ製品が備えている標準機能で自社の要件をカバーできる製品が自社にとっては良い選択となります。もちろん、製品の選定においては単純に適合度だけで判断するのではなく、コストやベンダーの力量などを含めた総合的な考慮が必要となります。よって、フィット&ギャップ分析の結果は、一つの参考情報として利用するのが適切です。
フィット&ギャップ分析の実施イメージ
フィット&ギャップ分析は一般的にパッケージやSaaSを選定する際に用いる手法です。自社の要件を縦軸に、各製品を横軸に並べ、製品ごとにどの要件をカバーできているか、もしくはできていないかを星取表で整理します。そして、製品ごとに自社の要件と機能との適合率を算出します。例えば、自社の要件が100あったとして、うち80の要件を実現できる製品であれば、適合率は80%となります。
具体的には、下表のようなイメージとなります。
自社要件 | 製品A | 製品B | 製品C | 製品D | ・・・ |
ログイン機能 | 〇 | 〇 | △ ※パスワードリセット機能なし | 〇 | ・・・ |
営業状況登録機能 | 〇 ※Salesforceとの連携可能 | 〇 | 〇 | 〇 | ・・・ |
見込み顧客管理機能 | 〇 | 〇 | 〇 | 〇 | ・・・ |
ステップメール管理機能 | × | 〇 ※開封率を考慮して送付内容を変更可能 | 〇 | 〇 | ・・・ |
SNSマーケ機能 | 〇 | × | × | × | ・・・ |
・・・ | ・・・ | ・・・ | ・・・ | ・・・ | 66% |
適合率 | 66% | 75% | 80% | 61% | 66% |
このように表で整理すると、各社の製品がどの要件に対応しているのか、また自社の要件をどの程度カバーできているのかを明瞭に判断できます。
フィット&ギャップ分析を通してカスタマイズの範囲を判断する
さらに、フィット&ギャップ分析はカスタマイズの範囲を検討するのにも有効です。フィット&ギャップ分析を実施すると、製品が対応できていない要件が明らかとなりますが、その際にとれる選択肢は「カスタマイズにより対応する」か「運用でカバーする」の2つとなります。フィット&ギャップ分析を実施する際には、あわせて標準機能で対応していない機能についてカスタマイズの可否や対応費用を確認することをおすすめします。あまりにも開発費用が高い場合、もしくは開発を実施すると運用やパッケージのアップデートなどで大きな影響が出る場合は、カスタマイズを実施せず業務の見直しや運用による対応を検討すべきです。
フィット&ギャップ分析の進め方
以下では、実際にどのようにフィット&ギャップ分析を進めるのか、製品の選定をイメージしたフローに沿って紹介します。
自社要件の整理
システム企画のフェーズとして、システム化の目的や必要な機能、連携するシステムなどを整理します。この際、「機能一覧」や「画面一覧」、「データ一覧」などとリスト形式で要件を整理するのがおすすめです。これらの情報がフィット&ギャップ分析の元情報となります。
製品の調査
次に、自社要件を満足できそうなパッケージ・SaaS製品を調査します。近年ではクラウドファーストの考え方も一般化しており、新規システム導入においてはSaaS等のクラウドサービスを利用することも一般的となりました。一般的にSaaSにはコスト削減や利用開始までの期間短縮、運用保守からの解放など様々なメリットがありますので、まずSaaSが利用できないかを確認することから始めるとよいでしょう。
また、PaaS、IaaS環境にパッケージを導入するケースも多いと思われます。一般的にSaaSはカスタマイズがかなり限定されますが、パッケージであればある程度のカスタマイズ余地があります。自社システムとの連携が必須であるケースなどでは、パッケージも有効な選択肢となるでしょう。
ベンダーから情報を集める
自社の要件と候補となる製品の選定ができたら、各ベンダーに自社の要件の充足度合いを情報提供してもらいます。この際、RFIとRFPという2つのスキームを利用するのが有効です。RFI(Request For Information:情提提供依頼)というスキームで、正式見積もりまでは実施しないものの、今後の発注を見越して情報を提供してもらうのか、RFP(Request for Proposal:提案依頼)のスキームでコンペとして見積と提案を提出してもらうのかは、プロジェクトの進め方によります。自社の要件がイマイチ整理しきれていないのであれば、一度RFIを実施して要件の精度を上げる取り組みが有効ですし、すでに要件が固まっているのであれば、すぐにRFPを実施するのがよいでしょう。
ベンダーから情報を集める際には、上述のとおりリスト形式で作成した自社の要件を共有し、各要件にパッケージやSaaSの標準機能で対応できるのか、対応できない場合はカスタマイズが可能なのか、カスタマイズできる場合はどの程度の費用となるのかについて記載をしてもらいます。このようにすることで、後続タスクとなる比較評価がやりやすくなります。
自社要件 | 標準機能の有無 | カスタマイズ可否 | カスタマイズ費用 | 備考 |
ログイン機能 | 〇 | パスワードリセット及び多要素認証に対応 | ||
営業状況登録機能 | 〇 | |||
見込み顧客管理機能 | 〇 | |||
ステップメール管理機能 | × | 〇 | 5,000千円 | 他社においてステップメール機能の開発実績あり |
SNSマーケ機能 | △ | × | Twitterにのみ対応 | |
・・・ | ・・・ | ・・・ | ・・・ | ・・・ |
各製品を横並びで比較する
情報を収集できたら、各社の回答をもとに横並びで比較します。この際、上述した通り適合度を算出し、各製品の対応状況を数字で比較できるようにするとよいでしょう。
一方で、単に数字だけで良し悪しを判断するのは危険です。自社の要件は一律同じ重要度ではなく、ものによって必須度合いが異なります。自社にとって重要な要件が充足できていない製品を選択するのはNGです。このような事態を避けるために、予め自社要件に「必須」か「任意」の区別をつけておき、必須機能が網羅できていない製品はその時点で落選とするような整理も有効です。
一方で、ERPなどカスタマイズ(アドオン)を最小化すべき製品であれば、自社の要件を標準機能でどれだけ網羅できているかは重要な判断基準となります。
製品を選定する
製品の比較を行ったら、最後に製品を選定します。あくまで、フィット&ギャップ分析は製品選定の一要素にすぎません。当然ながら初期コストやランニングコストなどの費用面は重要なポイントとなりますし、セキュリティや運用保守、サポート体制などの非機能要件も選定の要素となります。フィット&ギャップ分析の結果のみをもって製品選定を実施するのは避けるべきです。
一般的には、製品の選定前に評価基準を作成しておきます。評価基準では、「フィット&ギャップ分析による要件の充足度」のほか、「コスト」「ベンダーの実力や印象」「サポート体制」などの様々な観点を重要度に応じて点数化します。例えばコストが重要な案件であれば、コストを100点、その他を100点としてコストを重視して点数付けをするでしょうし、機能面が重要なのであればフィット&ギャップ分析の結果を高めに配点します。
評価基準をもとに関係者に各製品について採点をしてもらい、数値的な評価を取りまとめます。その結果をベースとしつつも、最終的には関係者間での合意をもって製品を選定します。数字だけで物事を判断するのは危険です。プロジェクトに関係するキーマンと認識を合わせ、会議の場などで協議し、合意に至るプロセスは「後腐れのない選択」をするために必須でしょう。
最後に:パッケージやSaaSの導入において必須となるフィット&ギャップ分析
パッケージやSaaSはコスト削減や開発期間の短縮につながる便利な仕組みですが、一方で一度選定した製品は長期間使われ続けることになり、ベンダーロックインのリスクもあります。製品選定は慎重になりすぎるぐらいでちょうどいいと思います。
フィット&ギャップ分析は、一律に各製品を比較することができる優れた手法です。パッケージやSaaSを選ぶ際には、後悔しない選択ができるように必ずフィット&ギャップ分析を実施するべきといえるでしょう。