要件定義とＦｉｔ＆Ｇａｐの作業内容

　　　　　パッケージ導入の最初の作業である「要件定義」と「Ｆｉｔ＆Ｇａｐ（フィットアンドギャップ）」の違い
　　　　　を説明します。ＥＲＰパッケージ導入も同様です。また、要求定義も要件定義と同様と考えます。
　　　　　ベンダにより最初の作業名称なり作業内容が多少異なります。しかし、基本的にはベンダ提示
　　　　　の要件定義なりＦｉｔ＆Ｇａｐの作業の目的と内容に大きな違いはないです。ただ、ベンダ提示の
　　　　　作業開始フェーズの成果物を正しく理解し、納得して作業を行うことが大事です。

　　　　　　　　　　　　　　　参考）導入作業から稼動・評価ページの「成果の上がる「作業」にするために」　

　　　　　　　　　　　パッケージのシステム機能のみに合わせて、自社の業務処理/管理内容/情報
                           活用を実現することは、業務系パッケージにおいてありえないです。
　　　　　　　　　　　ベンダ提示の作業内容と成果物を「次フェーズの成果物」との関係を理解し、作業
　　　　　　　　　　　　を始めることです。ベンダ任せは避けて下さい。
　　　　　　　　　　  上記の「作業目的と内容」を基に、ベンダ提示がどちらの内容に近いかを確認し、
　　　　　　　　　　　　上記の「注意すべき点」に留意して下さい。
　　　　　　　　　　　「目に見えないシステム機能」に関する検討も自社の要求内容に応じて必要です。
　　　　　　　　　　　　（参考）パッケージ商品の選択方法ページの「システム機能から見たパッケージ商品」

要件定義・Ｆｉｔ＆Ｇａｐの作業を行う前に、これからの「企業情報システムのあり 　　　方」「情報活用の活かし方」を知っておくと、あるべき姿の情報システム（パッケ 　　　ージ導入）の要件整理の参考になります。 　　　　　　　　　　　　　　　　　→　「企業情報システムのあり方」ページ 　　　　　　　　　　　　　　　　　→　「企業活動を支える情報活用の見方」ページ       　　　　　　　　　　　　　　  →　「業務改善への情報システムの活用」ページ

　作業開始に当たって

　　　　　作業開始に当たって、次のことを自社としてしっかり確認することが必要です。これらのことを
　　　　　曖昧にして作業を進めると非効率であり、良い成果に結びつきません。
           また、作業の効率/品質/進捗管理をしっかり行うことにより「要件定義、Ｆｉｔ＆Ｇａｐ」の成果物
　　　　　が満足するものになります。それを保証するのは自社とベンダのプロジェクトマネジメントです。
                        ●　予算管理の視点から、予算オーバーの発生した作業時点で相互に協議
　　　　　　　　　　　　　するルールを決めておくことも必要です。作業完了での大きな食い違い・
　　　　　　　　　　　　　齟齬の発生を防ぐ意味もあります。
　　　　　　　　　　　　　　　　　　　　　　　　　参考） 「成果をあげるプロジェクトマネジメント」ページ
                                                        参考） 「ベンダのためのプロジェクトマネジメント」ページ　

　　　　　　　　　　① この作業フェーズでの最終成果物の全てを見て、理解し、納得します。
　　　　　　　　　　　　　　　→ ベンダにサンプルなり事例の提示を依頼します。
　　　　　　　　　　　　　　　　　　　　　　　　　 （参考） 「価値ある要件定義の成果物」ページ 
　　　　　　　　　　② 作業の範囲・深さ（詳細機能・操作性・全レイアウト・・・まで）を確認します。
　　　　　　　　　　　　　　　→ 自社として、全ての深さまでの合意は不可能と理解すべきです。
  　　　　　　　　　　　　　　→ 現物（伝票、帳票、文書・・・）を基にした作業調査も必要です。
　　　　　　　　　　③ 作業に関する情報共有とともに作業環境/作業サイクルを把握し、自社とし
　　　　　　　　　　　  て合わせます。 
　　　　　　　　　　　　　　　→ 必要な時間・工数を含む自社の作業ボリュームをおさえます。
　　　　　　　　　　　　　　　→ ベンダとの情報共有とともに自社の情報共有・伝達をルール化します。

　　　　　　　　　　④ セッション/打合せの結果による中間成果物の確認方法と合意ルールを決めます。
　　　　　　　　　　　　　　　→ 疑問・課題などに関して、ベンダとの対応ルールを決めます。
                                             （参考） 「トラブルの早期発見と兆候・現象・原因」ページ 
　　　　　　　　　　　　　　　　　　　　（参考）  「トラブル（問題）の解決策と予防策」ページ   
　　　　　　　　　　　　　　　→ 作業を開始して、約１ヵ月ほど経ちましたら作業スケジュール・作業体制
　　　　　　　　　　　　　　　　　・作業方法などの点検を行い、必要な修正を行うことです。  　　　　　　　　　　　　　　　　

パッケージ導入の目的達成のためには、自社（ユーザ）としてのやるべきこと         を整理しやり遂げることが必要不可欠です。そのためには自社のプロジェクト         マネジメントの役割が大切です。その参考情報です。 　　　　　　　　　　　　　　　　→　「ユーザのためのプロジェクトマネジメント」ページ

 検討作業への姿勢と要点

　　　　　ベンダ提示の作業（要件定義・要求定義・Ｆｉｔ＆Ｇａｐ）に対して、自社として検討作業の意味を次
　　　　　のように理解して行うことです。
　　　　　この作業フェーズの最終成果物を念頭におき、ベンダとともに成果物を創り上げます。　

        
　　【参考】 ダウンロード資料＜150　「要件定義・Ｆｉｔ＆Ｇａｐ」の作業要領＞
 

　　　　　　　① 検討項目は独立でなく「全体と個」「相互関係」にある
　　　　　　　　　　・ 検討している項目（例：受注）は、その前提になる取引条件なり次作業（例：発注・出荷）
　　　　　　　　　　　 などを考慮して決められます。その項目（受注）のみでは全てを決められないです。
　　　　　　　　　　・ 検討項目は必ず「取引条件・業務効率・管理基準・サービス向上」などの視点から、他項
　　　　　　　　　　　目との関連性を含めた的確性・意味・価値の吟味が必要です。
　　　　　　　　　　・ パッケージ導入の目的達成、期待効果の実現（＝全体）に対する具体的根拠の点から、
                         検討項目（＝個）に対する必要性の精査も必要です。

             ② 検討は論理性（理解し納得し実現できる）が必須である
　　　　　　　　　　・ 検証項目に対して、机上の空論でなく実務レベルで理解でき納得できる内容である
　　　　　　　　　　　 ことが必要不可欠です。
　　　　　　　       ・ その検討内容が実現でき、その意味・効果が関係者から認められることです。
　　　　　　　　　  ・ 検証項目が他の検証項目と矛盾がなく、システム機能全体からも有意性・必要性が
　　　　　　　　　　　 あることです。
                      ・ 検証作業はこの論理性を維持しながら行うことが作業の効率と品質を高めます。
 

      　　　　　③ 検討内容は時間の経過とともに理解でき、合意できる
　　　　　　　　　　・ システム機能は大中小の検討項目の積み重ねであり、その集合体がシステム機能
　　　　　　　　　　　として働くときに意味があります。
　　　　　　　　　  ・ 検討作業も最初の頃は検討項目の部分であるため、理解できる面と理解できない面
　　　　　　　　　　　があります。検討を重ねるに従って、全体（例：業務効率・管理基準・サービス向上）か
　　　　　　　　　　　らの検討ができ、理解が深まります。その結果、ベンダと合意する条件が整います。
　　　　　　　　　　・ 「一次元→二次元→三次元」的に検討作業は進み、目的達成を果たすための見方と
　　　　　　　　　　　評価には一定の作業時間と期間が必要です。一朝一夕では無理があります。

　　　
              ④ 検討結果は仕組み（管理・作業・人）を創ることである　　　
　　　　　　　　　　　・ 検討項目の作業結果は自社としての実務レベルにおけるシステム機能の価値を創るこ
　　　　　　　　　　　　とにあります。
　　　　　　　　 　　 ・ 投資に対する効果（期待効果の実現）を実現するための仕組みを創ることです。
　　　　　　　　  　　・ 情報システムは道具であり、その目的達成のための条件を整え「管理・作業・人」の役
　　　　　　　　　　　　割を明らかにして、必要なシステム機能の内容を明らかにします。

 　集中と緊張

　　　　　多くの場合、ベンダと自社の初顔合わせでの作業になります。そのため、お互いの力量も未知
　　　　　でありコミュニケーションも慣れないスタートになります。このような面を早めに払拭するために、
　　　　　作業の集中と緊張が必要になります。また、このフェーズの最終成果物を完成させるためにも
　　　　　集中と軽い緊張を持続させることです。その理由は次のようなことです。

　　　　　　　　① ベンダと自社はともに、良いシステム機能にするための意見・アイデア・提案の
　　　　　　　　　　出し合いによる作業のやり方です。
　　　　　　　　② 自社とすれば、システム機能の最終形を掴みその中で個々のシステム機能の
　　　　　　　　　　是非なり判断を行います。
　　　　　　　　③ 早めにベンダの強み弱みを押さえることが大事です。そのためには、節度ある緊
　　　　　　　　　　張感を持ってベンダの作業・提案・意見をウォッチすることです。
　　　　　　　　④ 時間があるようでないのがこのフェーズでの作業実態です。このフェーズの成果
　　　　　　　　　　物が次フェーズ以降の作業に大きな影響を与えます。「内容のない形式的資料」
　　　　　　　　　　「理解しにくい成果物」は避けなければなりません。
　　　　　　　　⑤ プロジェクトの失敗はこのフェーズの作業結果（成果物の貧弱さ）によるところが
　　　　　　　　　　多いです。

　　　　　「集中と緊張」の中の楽しさ・気軽さは必要です。「集中と緊張」のない成果物は品質の悪いも
　　　　　のになります。要件定義の最終成果物を理解することが必要不可欠です。
　　　　　　　　　　　　　　　　 　　　　　　　（参考） 「価値ある要件定義の成果物」ページ