「まずはFit&Gap分析をやってください」。基幹システムの刷新プロジェクトに任命された途端、ベンダーや上司からこう言われて戸惑っていませんか。社内資料に「Fit&Gap」と書かれているものの、その意味が分からず焦っている方も多いはずです。
システム選定は、一度決めれば数年間は使い続ける買い物です。やり直しがききにくく、現場の業務に直結するため「失敗が許されない」というプレッシャーもあります。そのうえ「カスタマイズ」「アドオン」「適合率」といった聞き慣れない言葉が飛び交うと、何をどう判断すればよいのか分からなくなってしまいます。
ですが、フィットギャップ分析は決して専門家だけの作業ではありません。むしろ自社の業務を一番よく知っているのは、情報システム部門ではなく業務部門の担当者です。フィットギャップ分析で本当に主役になるべきなのは、現場を知っているあなた自身です。
この記事では、IT用語に不慣れな発注者の方に向けて、「フィット」「ギャップ」の意味から、分析の手順、ギャップが見つかったときの解消方法、そして「どこまでカスタマイズすべきか」を自分なりに判断するための基準まで、順を追ってやさしく解説します。読み終えるころには、ベンダー任せにせず、自社の業務の優先順位を踏まえて選定の意思決定に参加できるようになっているはずです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
フィットギャップ分析とは？「フィット」と「ギャップ」をやさしく理解する
まずは言葉の意味から押さえていきましょう。ここが腹落ちすれば、この先の話はぐっと分かりやすくなります。
フィットギャップ分析の定義（「フィット」「ギャップ」の意味）
フィットギャップ分析とは、パッケージソフトやERPといった「すでに完成しているシステム」の機能が、自社の業務にどれだけ合っているかを調べる作業のことです。Fit&Gap分析（フィットアンドギャップ分析）とも呼ばれます。
言葉を分解すると、とてもシンプルです。
- フィット（Fit）：自社の業務に、パッケージの機能がそのまま「合っている」部分
- ギャップ（Gap）：自社の業務に、パッケージの機能が「合っていない」「足りていない」部分
たとえば、自社で使いたい請求書の発行機能がパッケージに最初から備わっていれば、それは「フィット」です。一方、自社独自の承認ルールに対応する機能がパッケージになければ、それは「ギャップ」になります。
つまりフィットギャップ分析とは、「合っている部分」と「合っていない部分」を一つひとつ洗い出し、ギャップにどう対応するかを決めるための作業です。「分析」という言葉が硬く聞こえるかもしれませんが、やっていることは「自社の業務とシステムの機能を見比べて、ズレを探す」というだけのことです。
既製スーツに例えて理解する
もう少し直感的にイメージするために、既製スーツの試着に例えてみましょう。
パッケージソフトやERPは、いわば「既製スーツ」です。多くの企業で使えるように、標準的なサイズで作られています。これを自社という「体」に当てはめてみたとき、
- 肩幅や着丈がぴったり合う部分 → フィット
- 袖が少し長い、ウエストがゆるい、といった合わない部分 → ギャップ
となります。
合わない部分が見つかったとき、選択肢はいくつかあります。「お直しに出して体に合わせる」「多少のゆるさは気にせず着る」「そもそも体型に近い別のスーツを選び直す」。フィットギャップ分析でも、これと同じように「ギャップへの向き合い方」を決めていきます。この点はのちほど詳しく解説します。
ここで大切なのは、ギャップが見つかること自体は失敗ではない、という点です。どんな既製スーツでも、すべてが完璧に合うことはまずありません。ギャップを早めに見つけ、どう対応するかを冷静に決めることこそが、フィットギャップ分析の目的です。
要件定義との違い
フィットギャップ分析と混同されやすいのが「要件定義」です。違いを整理しておきましょう。
要件定義とは、「自社がシステムに何を求めるか（やりたいこと）」を明確にする作業です。一方フィットギャップ分析は、その求めるものに対して「目の前のパッケージがどこまで応えられるか」を照らし合わせる作業です。
順番としては、自社の業務やニーズを整理する作業が先にあり、それを物差しにしてパッケージとのフィット・ギャップを見ていく、という流れになります。要件定義が「自社側の地図を描く作業」だとすれば、フィットギャップ分析は「その地図とパッケージを重ね合わせて、はみ出す部分を探す作業」だとイメージすると分かりやすいでしょう。
実務では、この2つは厳密に分けられず、並行して進むこともあります。ただ「自社が何をしたいか」がはっきりしていないと、何をもって『合っている／合っていない』を判断すればよいか分からなくなります。まずは自社の業務を整理することが出発点になる、と覚えておいてください。
なぜパッケージ・ERP選定でフィットギャップ分析が必要なのか
「分析なんてしないで、評判の良いパッケージをそのまま入れればいいのでは」と思うかもしれません。なぜフィットギャップ分析という手間をかける必要があるのか、その理由を見ていきます。
パッケージは「完成済みの業務の型」を買う買い物
システムの作り方には、大きく分けて2つあります。
一つは「スクラッチ開発」。自社の業務に合わせて、システムをゼロから作り上げる方法です。オーダーメイドのスーツに近いイメージです。
もう一つが「パッケージソフト・ERPの導入」。すでに完成しているシステムを購入して使う方法です。先ほどの既製スーツにあたります。
ここで知っておきたいのは、パッケージソフトやERPは「単なる機能の集まり」ではなく「完成済みの業務の型（やり方）」を買う買い物だ、ということです。たとえば会計パッケージには、その製品が想定する経理処理の進め方が組み込まれています。販売管理パッケージには、受注から出荷、請求までの標準的な流れが設計されています。
つまりパッケージを導入するということは、その製品が前提とする「業務のやり方」をある程度受け入れる、ということでもあります。だからこそ、自社の現在のやり方とパッケージの型がどれだけズレているのかを、買う前に把握しておく必要があるのです。それを可視化する作業が、フィットギャップ分析です。
分析を省くと起こる典型的なトラブル
フィットギャップ分析をしないまま、あるいは形だけ済ませて導入を進めると、どのようなことが起こるのでしょうか。よくあるトラブルを3つ挙げます。
1. 想定外の追加費用が発生する
導入を進める途中で「この業務がパッケージでは回らない」と判明し、急きょカスタマイズが必要になるケースです。後から見つかったギャップへの対応は、計画に織り込まれていないため追加費用となり、当初予算を大きく超える原因になります。
2. 現場が混乱し、システムが使われなくなる
ギャップを把握しないまま導入すると、現場の担当者が「今までできていた作業ができない」「操作が複雑すぎる」と感じ、システムが定着しません。最悪の場合、現場が独自にExcelで二重管理を始め、何のためにシステムを入れたのか分からなくなってしまいます。
3. 選定そのものをやり直すことになる
導入が進んでから「このパッケージでは自社の根幹業務がどうしても回せない」と判明すると、選定のやり直しになります。費やした時間と費用が無駄になり、プロジェクト全体が大きく後退します。
これらのトラブルに共通するのは、「本来なら選定の段階で気づけたはずのズレ」が、後工程で表面化している点です。フィットギャップ分析は、こうしたズレを早い段階で見つけ、対処の見通しを立てるための作業です。「言われたからやる作業」ではなく、自社のプロジェクトを失敗から守るための作業だと捉えると、取り組む意味が見えてくるはずです。
フィットギャップ分析の手順｜4ステップと発注者の関わり方
ここからは、フィットギャップ分析を実際にどう進めるのか、4つのステップに分けて見ていきます。各ステップで「発注者であるあなたが手を動かすこと」と「ベンダーに任せること」を分けて示すので、自分の持ち場を意識しながら読んでください。
なお、ステップに入る前にひとつ重要な準備があります。それは「どの業務範囲を分析の対象にするか（スコープ）」を、ベンダーと事前に合意しておくことです。全社のあらゆる業務を一度に分析しようとすると、作業が膨れ上がって収拾がつかなくなります。「今回の刷新は販売管理と在庫管理が対象。人事給与は対象外」というように、最初に範囲を線引きしておきましょう。
ステップ1：自社業務の棚卸し
最初のステップは、自社の業務を一覧として洗い出すことです。これは発注者であるあなたの主戦場です。自社の業務を一番よく知っているのは現場の担当者であり、ベンダーには代わりができません。
具体的には、現在行っている業務（AS-IS業務と呼びます）を一つずつ書き出していきます。Excelで一覧表を作るとよいでしょう。各業務について、最低限、次の情報を整理しておくと、後の照合作業がスムーズになります。
- 業務名：「受注入力」「請求書発行」など、何をする業務か
- 処理頻度：毎日／週次／月次／随時など、どのくらいの頻度で行うか
- 関与部門：その業務に誰（どの部署）が関わるか
- 必須か任意か：その業務のやり方が「絶対に変えられない」のか「変えても問題ない」のか
特に大切なのが、最後の「必須か任意か」の仕分けです。法律で定められた処理や、自社の競争力に直結する業務は「必須」です。一方、長年の慣習でそうしているだけで、実は変えても困らない業務も少なくありません。この仕分けが、後でギャップに対応する際の判断材料になります。
ベンダーに任せられるのは、この棚卸しの「進め方のアドバイス」や「一覧表のひな形の提供」までです。中身を埋めるのは現場にしかできません。
ステップ2：パッケージ機能の調査
次に、候補となるパッケージにどんな機能があるのかを調べます。このステップは、ベンダーによるデモンストレーションや機能説明会を通じて進むことが多くなります。
説明を受ける側として、発注者は「自社の業務がそのパッケージでどう実現されるか」という視点で見ることが大切です。デモを見るときは、次のような点を意識してください。
- ステップ1で洗い出した「必須」の業務が、そのパッケージで問題なく回せそうか
- 標準機能だけで対応できるのか、それとも追加の作り込みが必要そうか
- 操作の手順が、現場の担当者にとって無理のないものか
ベンダーのデモは、その製品が得意とする部分を中心に見せる傾向があります。「自社のこの業務はどうやるのですか」と、こちらから具体的に質問することで、フィットしない部分が見えてきます。気になった点はその場でメモを取り、後の照合作業に持ち込みましょう。
ステップ3：業務とパッケージ機能の照合・ギャップ特定
ステップ1で作った業務一覧と、ステップ2で調べたパッケージの機能を、一つずつ突き合わせていきます。ここで、各業務が「フィット」なのか「ギャップ」なのかを判定します。
判定は、おおまかに次のように分けると整理しやすくなります。
- フィット：標準機能でそのまま対応できる
- 一部ギャップ：標準機能で対応できるが、設定変更や運用の工夫が必要
- ギャップ：標準機能では対応できず、何らかの追加対応が必要
この照合作業の結果として「適合率」という数字が出てくることがあります。適合率とは、洗い出した業務のうち、どれだけがパッケージにフィットしているかを示す割合です。たとえば100の業務のうち80がフィットすれば「適合率80%」となります。
ただし、適合率の数字だけを鵜呑みにしないよう注意してください。仮に適合率が90%でも、残り10%の中に「自社にとって絶対に外せない基幹業務」が含まれていれば、その製品は適していないかもしれません。逆に適合率が70%でも、ギャップが軽微な業務ばかりなら十分使える可能性があります。数字の大きさよりも「どの業務がギャップになっているか」という中身が重要です。
ステップ4：ギャップへの対応方針の決定と最終選定
最後のステップは、特定したギャップに対して「どう対応するか」の方針を決め、製品を最終的に選ぶことです。
ギャップへの対応方法には、後ほど詳しく説明する「カスタマイズする」「業務を変える」「運用で回避する」という3つの選択肢があります。それぞれのギャップについて、どの方法で対応するのか、その場合の費用や手間はどれくらいか、を整理します。
この対応方針の検討は、ベンダーの見積もりや技術的なアドバイスを受けながら進めますが、最終的に「どこにお金と手間をかけるか」を決めるのは発注者です。なぜなら、それは「自社の業務のどこを大切にするか」という経営判断に近いものだからです。ベンダーは技術的な実現可能性は示せても、「その業務が自社にとってどれだけ重要か」までは判断できません。
複数の製品を比較している場合は、ギャップへの対応にかかる総コストも含めて、どの製品が最も自社に合っているかを判断し、選定を確定します。
ギャップの解消方法は3つ｜カスタマイズ・業務変更・運用で回避
ギャップが見つかったとき、「カスタマイズするしかない」と思い込んでいませんか。実は、ギャップへの対応方法は大きく3つあります。選択肢を知っておくことで、判断の幅が広がります。
解消方法①：カスタマイズ・アドオン
1つ目は、パッケージそのものに手を加えて、自社の業務に合わせる方法です。ここでよく出てくる「カスタマイズ」と「アドオン」という言葉を整理しておきましょう。
- カスタマイズ：パッケージの既存の機能や画面そのものを「直す（変更する）」こと
- アドオン：パッケージにない機能を「足す（追加する）」こと
スーツの例でいえば、カスタマイズは「既存の生地に手を入れて袖を詰める」、アドオンは「ポケットを新しく付け足す」というイメージです。どちらも自社にぴったり合わせられる一方で、共通する負担があります。
それは「お金がかかる」ことと「保守の負担が続く」ことです。手を加えた部分は、その製品の標準機能ではなくなるため、製品がバージョンアップするたびに、その部分が正しく動くかを確認したり、作り直したりする必要が出てきます。つまりカスタマイズ・アドオンは、初期費用だけでなく、その後ずっと続くコストを背負う選択だということです。
一般的には、既存機能を直す「カスタマイズ」よりも、機能を足す「アドオン」のほうがバージョンアップ時の影響が小さく、保守しやすいとされています。
解消方法②：業務をパッケージに合わせる（Fit to Standard）
2つ目は、パッケージに手を加えるのではなく、自社の業務のやり方をパッケージの標準機能に合わせて変える方法です。
近年、特にクラウド型のERPやSaaSの普及にともなって「Fit to Standard（フィット・トゥ・スタンダード）」という考え方が広がっています。これは「パッケージをいじって自社に合わせる」のではなく「自社の業務をパッケージの標準的なやり方に合わせていく」という進め方です。
意外に思えるかもしれませんが、これは有力な選択肢です。パッケージの標準機能は、多くの企業で使われてきた、いわば「業務のお手本」のような側面があります。自社の現在のやり方が、長年の慣習で複雑になっているだけなら、パッケージの標準的なやり方に合わせることで、かえって業務がシンプルになることもあります。
ただし、業務のやり方を変えるには現場の理解と協力が欠かせません。「なぜ変えるのか」を丁寧に説明し、現場の納得を得ながら進める必要があります。この、業務のやり方そのものを見直す取り組みは「BPR（業務改革）」とも呼ばれます。
解消方法③：運用・手作業で回避する
3つ目は、システムには手を加えず、運用のルールや一部の手作業でギャップを埋める方法です。
たとえば、月に一度しか発生しない特殊な集計作業について、わざわざ機能を追加せず「その作業だけは担当者がExcelで対応する」と決めるようなケースです。発生頻度が低い業務や、影響を受ける人数が少ない業務であれば、手作業で回避するほうがコストも手間もかからないことがあります。
注意点として、手作業に頼りすぎると、担当者の負担が増えたり、その人がいないと業務が回らない「属人化」を招いたりします。あくまで「頻度が低く、影響範囲が小さい業務」に限って使うのが現実的な判断です。
3つの解消方法の比較表
ここまでの3つの解消方法を、表で整理します。
解消方法 | 内容 | 初期コスト | 継続コスト・負担 | 向いているケース |
|---|---|---|---|---|
①カスタマイズ・アドオン | パッケージに手を加えて自社に合わせる | 高い | バージョンアップ時の追加対応が続く | 自社の競争力に直結し、他で代替できない業務 |
②業務をパッケージに合わせる | 自社の業務をパッケージの標準に合わせる | 低い（システム費用） | 現場の業務変更・定着の手間 | 慣習で複雑になっているだけの業務 |
③運用・手作業で回避 | システムに手を加えず運用や手作業で対応 | ほぼなし | 手作業の負担・属人化のリスク | 発生頻度が低く、影響範囲が小さい業務 |
大切なのは、すべてのギャップを同じ方法で解消しようとしないことです。ギャップごとに「このギャップはどの方法が最適か」を考え、組み合わせて対応していくのが現実的な進め方です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
カスタマイズすべきか迷ったときの判断基準
3つの解消方法が分かっても、「自社のこのギャップは、結局どれを選べばいいのか」と迷う場面は必ず出てきます。ここでは、発注者が現場で使える判断の物差しを示します。
判断の3つの軸
ギャップにどう対応するかを考えるとき、次の3つの軸でそのギャップを見てみてください。
軸1：それは「競争力の源泉」か、それとも「単なる慣習」か
そのギャップになっている業務は、自社が他社に勝つために欠かせない独自のやり方でしょうか。それとも「昔からそうしているから」という理由で続けているだけでしょうか。前者なら、お金をかけてでも守る価値があります。後者なら、パッケージの標準に合わせることを前向きに検討すべきです。
軸2：全社で何人が困るか（影響人数）
そのギャップを解消しなかった場合、困る人は何人いるでしょうか。全社の100人が毎日不便を感じる業務と、1人が月に1回だけ手間を感じる業務とでは、対応の優先度がまったく異なります。
軸3：年間でどれくらいの手間（業務量）になるか
そのギャップを手作業で回避した場合、年間でどれくらいの時間がかかるかを概算してみましょう。「1回30分の作業を月20回、年間で約120時間」のように数字にすると、カスタマイズ費用と手間を天秤にかけやすくなります。
カスタマイズに踏み切ってよいケース／踏みとどまるべきケース
この3つの軸を踏まえると、判断の方向性が見えてきます。
カスタマイズに踏み切ってよいケース
- そのギャップが「自社の競争力の源泉」にあたり、標準のやり方では競争力が損なわれる
- 影響を受ける人数が多く、業務量も大きいため、放置すると全社の生産性が大きく下がる
- 手作業での回避が現実的でなく、業務が回らなくなる
踏みとどまるべきケース
- ギャップの理由が「昔からの慣習」で、変えても実害がない
- 影響を受ける人数が少なく、発生頻度も低い
- 標準機能に合わせれば、むしろ業務がシンプルになる
ここで覚えておきたい原則があります。それは、対応方法を検討する順番です。まず「業務を変える・運用で回避できないか」を第一に検討し、それでもどうしても必要なら「アドオン（機能の追加）」、そして本当に最後の手段として「カスタマイズ（既存機能の変更）」を考える、という順序です。
なぜなら、カスタマイズはこの記事で繰り返し触れてきたとおり、初期費用と将来の保守負担が最も重いからです。「カスタマイズありき」で進めるのではなく、「カスタマイズしなくて済む方法はないか」から考えるクセをつけると、判断を誤りにくくなります。
適合率だけで選ばない
最後にもう一点。製品を選ぶときに「適合率の数字が一番高い製品」を選べばよい、と考えるのは早計です。
適合率はあくまで「業務がフィットする割合」を示すだけで、その製品が自社にとって最良かどうかは、それだけでは決まりません。実際の選定では、適合率に加えて次のような要素も総合的に見る必要があります。
- ギャップを解消するための総コスト（初期費用＋将来の保守費用）
- バージョンアップやサポートの体制が安定しているか
- ベンダーが自社の業界・業務を理解してくれそうか
- 現場の担当者にとって操作しやすいか
適合率は判断材料の一つにすぎません。「数字」ではなく「自社にとっての使いやすさと総コスト」で選ぶ、という姿勢を持ってください。
カスタマイズコストの見積もりの読み方
カスタマイズを検討する段階になると、ベンダーから見積もりが提示されます。「見積もりは難しそう」と苦手意識を持つ方は多いですが、いくつかのポイントを押さえれば、発注者でも見積もりを読み解けます。
カスタマイズコストは初期費用だけではない
見積もりを見るとき、最も陥りやすい誤解が「見積もりに書かれた金額が、カスタマイズにかかる費用のすべてだ」と思い込むことです。
実際には、カスタマイズには見積書に大きく書かれた初期費用のほかに、見えにくいコストが続きます。代表的なものが次の2つです。
保守費用の上昇
カスタマイズした部分は標準機能ではなくなるため、その部分を維持・管理するための保守の対象になります。結果として、毎年支払う保守費用が、カスタマイズをしない場合より高くなることがあります。
バージョンアップ時の再開発費
パッケージが新しいバージョンに切り替わるとき、カスタマイズした部分が新バージョンでそのまま動くとは限りません。動作確認や、場合によっては作り直しが必要になり、その都度費用が発生します。これは数年に一度、繰り返し発生するコストです。
カスタマイズの費用は「一度払えば終わり」ではなく「導入後もついて回るコスト」だと理解しておくことが、見積もりを正しく読む第一歩です。
ベンダー見積もりで確認すべきチェックポイント
ベンダーから見積もりを受け取ったら、次の項目を確認・質問してみてください。専門知識がなくても、これらを聞くだけで見積もりの解像度が大きく上がります。
- 人月単価と工数：「人月（にんげつ）」とは、技術者1人が1ヶ月作業する量を表す単位です。「人月単価がいくらで、何人月の工数を見込んでいるか」を確認すると、金額の根拠が分かります
- 対象範囲：その見積もりが「どこからどこまでのカスタマイズ」を含むのかを明確にしてもらいます。範囲があいまいだと、後から「それは見積もり対象外です」となりがちです
- 保守費用への影響：このカスタマイズによって、毎年の保守費用がいくら増えるのかを確認します
- バージョンアップ時の扱い：将来パッケージがバージョンアップしたとき、このカスタマイズ部分の対応にどれくらいの費用がかかる見込みかを聞いておきます
- 前提条件と除外事項：見積もりが「何を前提にしているか」「何が含まれていないか」を確認します
これらを確認したうえで、複数のベンダーから見積もりを取って比べると、金額が妥当かどうかを判断しやすくなります。「総額がいくらか」だけでなく「その金額に何が含まれ、何が含まれないか」まで踏み込んで確認することが、予算オーバーを防ぐコツです。
発注者がやりがちな判断ミスと回避のコツ
最後に、フィットギャップ分析やパッケージ選定の場面で、発注者がやりがちな判断ミスを4つ紹介します。あらかじめ落とし穴を知っておけば、避けることができます。
現行業務をすべて再現しようとする
最もよくあるのが「今のやり方をすべてそのまま、新しいシステムでも実現したい」と考えてしまうミスです。
現行業務をすべて再現しようとすると、ギャップのほとんどをカスタマイズで埋めることになり、費用は膨れ上がり、保守の負担も重くなります。これを「カスタマイズの膨張」と呼びます。
回避のコツ：「今のやり方」は必ずしも「最善のやり方」ではない、という前提に立ちましょう。ステップ1の棚卸しで仕分けた「必須か任意か」を思い出し、本当に守るべき業務だけを再現対象にします。「変えても困らない業務」は、むしろパッケージの標準に合わせる好機です。
適合率の数字だけで決める
「A製品は適合率85%、B製品は78%。だからAにしよう」と、数字の大小だけで製品を決めてしまうミスです。
すでに触れたとおり、適合率は「合っている業務の割合」を示すだけで、ギャップの中身までは語りません。適合率が高くても、肝心の基幹業務がギャップになっていれば、その製品は適していません。
回避のコツ：適合率の数字を見たら、必ず「ギャップになっている業務は具体的に何か」を確認します。中身を見ずに数字だけで判断しないことです。
ギャップの判断をベンダーに丸投げする
「専門的なことは分からないから、ギャップへの対応はベンダーに任せよう」と、判断そのものを委ねてしまうミスです。
ベンダーは技術的な実現可能性は判断できますが、「その業務が自社にとってどれだけ重要か」は分かりません。判断を丸投げすると、自社にとって重要でない業務に費用がかかったり、逆に大事な業務が軽視されたりするおそれがあります。
回避のコツ：ベンダーには「技術的にどう実現できるか」「いくらかかるか」を聞き、「自社にとってどれだけ重要か」は発注者である自社が判断する、と役割を分けます。この記事で紹介した3つの判断軸は、まさにそのための物差しです。
対象範囲（スコープ）を決めずに始める
分析の対象範囲をあいまいにしたまま始めてしまい、作業が膨らんで収拾がつかなくなるミスです。
範囲を決めずに進めると、「あの業務も見たほうがいいのでは」と次々に対象が広がり、いつまでも分析が終わりません。
回避のコツ：分析を始める前に、ベンダーと「今回の対象はどの業務範囲か」をはっきり合意します。対象外とする業務も明文化しておくと、途中で範囲がぶれにくくなります。
まとめ｜発注者としてフィットギャップ分析にどう向き合うか
フィットギャップ分析とは、パッケージソフトやERPの機能が自社の業務にどれだけ合っているか（フィット）、合っていないか（ギャップ）を洗い出し、ギャップへの対応を決めるための作業です。最後に、発注者として押さえておきたい行動指針を整理します。
- ギャップは悪ではない：ギャップが見つかること自体は失敗ではありません。早く見つけ、冷静に向き合い方を決めることが大切です
- 手順の中での自分の持ち場を意識する：特にステップ1の「自社業務の棚卸し」は、現場を知る発注者にしかできない主戦場です。Excelで業務一覧を作るところから始められます
- ギャップの解消には3つの選択肢がある：カスタマイズだけでなく「業務を変える」「運用で回避する」も有力な選択肢です
- カスタマイズは最後の手段：「運用回避・業務変更 → アドオン → カスタマイズ」の順で検討します。カスタマイズは初期費用も将来の保守負担も最も重い選択です
- 適合率の数字だけで選ばない：数字ではなく、ギャップの中身と総コストで判断します
- 判断をベンダーに丸投げしない：技術的な実現可能性はベンダーに、業務の重要度の判断は自社に。役割を分けます
そして、フィットギャップ分析を進めるうえで最大の武器になるのは、「自社の業務の優先順位」を自分の中に持っておくことです。何が競争力の源泉で、何が単なる慣習なのか。どの業務は絶対に守り、どの業務は変えてもよいのか。この優先順位がはっきりしていれば、ギャップを前にしても「これはカスタマイズすべき」「これは業務を変えるべき」と、自分の言葉で判断し、発言できるようになります。
フィットギャップ分析は、ベンダーのための作業ではなく、自社のための作業です。現場を一番よく知るあなたが主体的に関わることで、システム選定の成功率は大きく高まります。まずは自社の業務を一つずつ書き出すところから、着手してみてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
