最近、ある情報系（技術等の情報共有）システムについて、ある種のパッケージソフトを選定候補に加えることを、
ある顧客に提案してみました。
実際のパッケージソフトをデモンストレーションで確認しながら、実業務における利用の可否を顧客のプロジェクトメンバーと評価・判断してきましたところ、そのメンバーによる評価は想像以上に良いものでした。
（課題実現策の提案に対し、良い事前評価がいただけたことは、コンサルタントとして嬉しい瞬間でした。）
詳細は記載しませんが、
このパッケージソフトは、今まで顧客が活用していたＩＣＴツールとは種類が異なるものでした。
しかし、新たな要求事項の実現や既存ＩＣＴツールの統合などが、今回のシステム化検討の目的です。
それらの実現策として、異なる分野のＩＣＴツールの方がフィットすると、私は感じていました。
ここで本題に入りますが、
ＥＲＰ導入プロジェクトが盛んだった？ころ、フィット＆ギャップ分析という言葉が良く使われました。
このフィット＆ギャップ分析とギャップに対する運用を含めた対応策の立案などが、当時ＥＲＰコンサルタント？などと呼ばれた方々の提供価値だったと認識しています。
このフィット＆ギャップ分析は、ＥＲＰのみではなく、実は他ＩＣＴツールで実施されていることと基本は同じあろうと、私は考えています。
ポイントの一つは、何に対して何をフィット＆ギャップ分析するか？（対照は何か？）です。
①：何に対して
Ａ．現状業務
Ｂ．新たな要求事項
Ｃ．上記ＡとＢをマージしたもの（要求定義書）
②：何を
ａ．新たな複数のソリューション候補
ｂ．新たな特定のソリューション
私は、顧客自身が独力（コンサルタントの支援有りを含む）で実施する「要求定義」フェーズにおいては、
上記Ｃ．要求定義書に対し、ａ．をフィット＆ギャップ分析することになると考えています。
（ちなみに、要求定義と要件定義に関する私の考え方は、過去の記事「要求定義と要件定義」をご参照願います。）
また候補ソリューションが決定した後、構築ベンダーを交えたプロジェクトが立ち上がった後においては、
上記Ｃ．要求定義書に対し、ｂ．をフィット＆ギャップ分析することになると考えています。
過去のＥＲＰプロジェクトにおいて、または一般的には、
Ａ．現状業務 と ｂ．新たな特定のソリューション（特定のＥＲＰパッケージ等） とのフィット＆ギャップが、所謂フィット＆ギャップ分析と呼ばれていると、私は感じています。
これは、あまり価値のあるプロセスではありません。
（ただし、Ｃ．要求定義書 と ｂ．新たな特定のソリューション との詳細なフィット＆ギャップ分析は、要件定義フェーズにおいては必須になります。）
私は、
Ｃ．要求定義書（新たな要求事項プラス現状を維持するための要求事項） と ａ．新たな複数のソリューション候補 とをフィット＆ギャップ分析の結果などを踏まえて評価すること、
これが、ＩＣＴ導入目的の達成に必要且つ重要な事項の一つであると考えています。
（この考え方は、ＢＡＢＯＫガイド「第７章 ソリューションのアセスメントと妥当性確認」の『7.1 提案ソリューションをアセスメントする』に記載の事項と類似であると考えています。）
要求定義書とフィット＆ギャップ分析などをしながらソリューションを（複数ソリューション候補から）選択し、
要求定義書とフィット＆ギャップ分析などをしながら特定ソリューションの要件定義や基本設計が実施される、
よって、要求定義書がフィット＆ギャップ分析の対象の一方になるものと整理できると思います。
先に記載しました最近の事例は、その考え方で事前評価した例に位置づけられるとフッと思い、今回の記事で記載してみました。
何かの参考になれば嬉しく思います。
＜関連記事＞
「超上流工程からシステム運用テストまでにおける考慮事項」
「超上流工程におけるＢＡＢＯＫの有効性（その1）」
「超上流工程におけるＢＡＢＯＫの有効性（その2）」
「超上流工程におけるＢＡＢＯＫの有効性（その3）」
「超上流工程におけるＢＡＢＯＫの有効性（その4）」
「超上流工程におけるＢＡＢＯＫの有効性（その5）」
ある顧客に提案してみました。
実際のパッケージソフトをデモンストレーションで確認しながら、実業務における利用の可否を顧客のプロジェクトメンバーと評価・判断してきましたところ、そのメンバーによる評価は想像以上に良いものでした。
（課題実現策の提案に対し、良い事前評価がいただけたことは、コンサルタントとして嬉しい瞬間でした。）
詳細は記載しませんが、
このパッケージソフトは、今まで顧客が活用していたＩＣＴツールとは種類が異なるものでした。
しかし、新たな要求事項の実現や既存ＩＣＴツールの統合などが、今回のシステム化検討の目的です。
それらの実現策として、異なる分野のＩＣＴツールの方がフィットすると、私は感じていました。
ここで本題に入りますが、
ＥＲＰ導入プロジェクトが盛んだった？ころ、フィット＆ギャップ分析という言葉が良く使われました。
このフィット＆ギャップ分析とギャップに対する運用を含めた対応策の立案などが、当時ＥＲＰコンサルタント？などと呼ばれた方々の提供価値だったと認識しています。
このフィット＆ギャップ分析は、ＥＲＰのみではなく、実は他ＩＣＴツールで実施されていることと基本は同じあろうと、私は考えています。
ポイントの一つは、何に対して何をフィット＆ギャップ分析するか？（対照は何か？）です。
①：何に対して
Ａ．現状業務
Ｂ．新たな要求事項
Ｃ．上記ＡとＢをマージしたもの（要求定義書）
②：何を
ａ．新たな複数のソリューション候補
ｂ．新たな特定のソリューション
私は、顧客自身が独力（コンサルタントの支援有りを含む）で実施する「要求定義」フェーズにおいては、
上記Ｃ．要求定義書に対し、ａ．をフィット＆ギャップ分析することになると考えています。
（ちなみに、要求定義と要件定義に関する私の考え方は、過去の記事「要求定義と要件定義」をご参照願います。）
また候補ソリューションが決定した後、構築ベンダーを交えたプロジェクトが立ち上がった後においては、
上記Ｃ．要求定義書に対し、ｂ．をフィット＆ギャップ分析することになると考えています。
過去のＥＲＰプロジェクトにおいて、または一般的には、
Ａ．現状業務 と ｂ．新たな特定のソリューション（特定のＥＲＰパッケージ等） とのフィット＆ギャップが、所謂フィット＆ギャップ分析と呼ばれていると、私は感じています。
これは、あまり価値のあるプロセスではありません。
（ただし、Ｃ．要求定義書 と ｂ．新たな特定のソリューション との詳細なフィット＆ギャップ分析は、要件定義フェーズにおいては必須になります。）
私は、
Ｃ．要求定義書（新たな要求事項プラス現状を維持するための要求事項） と ａ．新たな複数のソリューション候補 とをフィット＆ギャップ分析の結果などを踏まえて評価すること、
これが、ＩＣＴ導入目的の達成に必要且つ重要な事項の一つであると考えています。
（この考え方は、ＢＡＢＯＫガイド「第７章 ソリューションのアセスメントと妥当性確認」の『7.1 提案ソリューションをアセスメントする』に記載の事項と類似であると考えています。）
要求定義書とフィット＆ギャップ分析などをしながらソリューションを（複数ソリューション候補から）選択し、
要求定義書とフィット＆ギャップ分析などをしながら特定ソリューションの要件定義や基本設計が実施される、
よって、要求定義書がフィット＆ギャップ分析の対象の一方になるものと整理できると思います。
先に記載しました最近の事例は、その考え方で事前評価した例に位置づけられるとフッと思い、今回の記事で記載してみました。
何かの参考になれば嬉しく思います。
＜関連記事＞
「超上流工程からシステム運用テストまでにおける考慮事項」
「超上流工程におけるＢＡＢＯＫの有効性（その1）」
「超上流工程におけるＢＡＢＯＫの有効性（その2）」
「超上流工程におけるＢＡＢＯＫの有効性（その3）」
「超上流工程におけるＢＡＢＯＫの有効性（その4）」
「超上流工程におけるＢＡＢＯＫの有効性（その5）」