実現性の高いRFPの作成方法

RFPを作成する場合、ベンダー側に構築するための自社要求を過不足なく伝える必要がある。
以下がRFPに記載する内容例である。

• プロジェクトの目的・背景
• 業務･システムの目指す姿
• プロジェクトのスコープ
• 機能要求やそれ以外（システムなど）の要求
• マスタスケジュール　　　　　　　　　　　　など

大抵は、これらの内容を整理したうえで、依頼を出すベンダーを選定し、候補ベンダーに提案依頼をするという流れになる。
ここで少し考えることは、良い提案をベンダーから得るためには何をすべきか、ということである。良い提案とは、提案依頼事項が満たされ、ベンダーの能力を活かした提案となっており、その提案依頼内容通りにプロジェクトが進められるようになっていることである。
そのためには、作成したRFPについて、以下3点の確認が必要と考える。

• 実現性のある目的や依頼内容か?
• 実現性のあるスケジュールになっているか?
• そもそも依頼内容やスコープがERPの範疇のものか?

実現する根拠がない場合は、当然ほとんどのケースでプロジェクトは破たんする。例えば、ERP導入の代表的な目的のひとつとして「業務の標準化」がある。グループ会社を含めた業務の標準化プロジェクトの期間を1年半とした場合は、その期間でそれを実現できる可能性があるのかを、事前に確認する必要がある。
業務標準化の場合、各グループ会社の業務ユースケースや業務プロセスは同じようなものであること、各グループ会社の業績管理指標が統一できること、顧客特有要求がほとんどないこと、扱う商品が同じようなものであることが前もって確認できれば、標準化の実現可能性は高いと想定できる。また、業務標準化のための業務変更に関する合意形成が特定の業務責任者とのコミュニケーションだけで進められること、新規の業務アプリケーションの開発量（インターフェース、特定帳票、大量のデータ処理の有無）がある程度想定できれば、期間の妥当性を判断できる。
プロジェクトが破たんすれば、期間やコストは数倍膨らむことが常である。実現性のあるRFPにすることが重要だ。

ベンダーの提案評価と選定方法

各ベンダーに提案依頼をして、ベンダーから提案を受け、その後ベンダーの提案評価を実施する。
評価項目は、以下が考えられる。

• 提案要求の達成度や網羅性
• プロジェクト実行能力
• コスト　　　　　　　　　　など

通常、評価スコアが最も高いベンダーを選ぶことが多いだろう。仮にベンダー5社に提案依頼をし、1社だけ要求達成度の期待値が高く、その他4社が期待値に達しない場合、多くのケースで期待値の高い1社が選択される。ここに落とし穴がある。実は、難易度が高い提案依頼をしている場合、その要求に答えられない方が実現性の高い提案である可能性が高い。一方、要求達成度の高い提案のベンダーは、難易度の高さを理解していない、もしくは難易度を理解していて、実は達成できないがその達成度を高く見せて、受注優先の対応をしており、契約時にそのリスクヘッジ（ベンダーが難易度の高い前提条件を提示する、など）をする可能性も考えられる。この評価に失敗し、見かけ上要求達成度の高いベンダーを選択した場合、プロジェクト実施中に大きなトラブルを発生させ、期間やコストが数倍膨らむことになる。
そうしたことが起きないようにするためには、以下の対応が必要と考える。

• 多くのベンダーが達成できないと回答した要求について、達成できると回答したベンダーに対して、その根拠と実現性を確認する
• ERP導入プロジェクト有識者に選択候補のベンダー提案の実効性を確認する

どうしても要求達成度の高いベンダーがよく見えてしまいがちだが、冷静な見極めが必要である。また、依頼企業の中には、リスクがあるプロジェクトと理解し、そのリスクを依頼元の部門（経営企画部門やIT部門など）がそのリスクの責任を取りたくないという理由から、ベンダーに依頼するという企業もあった。しかし、ベンダーによっては、そのリスクを依頼企業側に目立たないよう戻すケースもある。たとえば、プレゼンテーションで強調されない前提条件や責任と役割の部分にリスク回避条項を盛り込む、などの方法が考えられる。
そのため、依頼企業はプロジェクトの成功を第一に考え、提案依頼内容についてリスクを最小化し、ベンダーの提案評価においても、要求達成度を最優先の指標とせず、プロジェクトの実効性を最優先とすべきである。

プロジェクト計画書遂行における落とし穴

ベンダー選定が完了したら、プロジェクト開始までに契約の手続きや、具体的なプロジェクト計画を確定させる。この時にベンダーに提案されたタスクや期間をそのまま実行すると、場合によっては、実際の進捗とは大きな乖離が発生し、プロジェクトのトラブルに繋がる。多くの場合、ベンダー知見は依頼企業の実情と乖離するケースが多い。これは、タスク内容・タスク期間・品質・前提条件などに多くのベンダー知見が含まれており、それが依頼企業に対してそのまま適用できる保証がないためである。特に経験豊富なベンダーが陥りやすい落とし穴である。
要求定義フェーズで乖離が発生しやすい部分は、以下の通りだ。

• プロジェクトに参加する業務側代表者の業務理解度の想定（＝対象業務を全て理解している人材がいるのか、適宜担当者ヒアリングを行うのか）
• 関係会社や関係事業部の巻き込み方の想定（＝関係者全員を集められるのか、個別検討が必要なのか）
• 既存システムの改修タスクの工数や期間の想定（＝想定根拠と現行保守している担当の認識が合っているか）
• 業務のユースケース数や難易度の想定（＝業務数は、業務側の認識と合っているのか）
• 業務変更を実施検討する要求定義期間の想定（＝期間内で結論付けできるのか）
• アドオン開発量の想定（＝現行システムの開発量と整合がとれるのか）

ベンダーに任せることなく、依頼企業が積極的に関与して必要なインプットを提供し、正しい認識のもと、主要なタスクやタスク内容・期間の実現性を高めることが必要である。ベンダーの豊富な実績や知見だけにもとづく判断は、プロジェクトの規模が大きければ大きいほど、実態との乖離していくことがほとんどであるという認識を持つべきだ。

おわりに

本稿では、プロジェクト立ち上げ時の3つのポイント、（1）実現性の高いRFPの作成方法、（2）ベンダーの提案評価と選定方法、（3）プロジェクト計画書遂行における落とし穴、について論じてきた。結局のところ、プロジェクトの実現性の判断に尽きる。実現性がはっきりしないものは必ずプロジェクトのリスクになり、プロジェクト実施後、どこかのフェーズでそれが表面化し、QCDに多大な影響を与える。そのようなプロジェクトは、残念ながら常に一定数発生している。ベンダーが言うのだから大丈夫という姿勢は、確実にトラブルを発生させることを肝に銘じ、依頼側から実現性に関して積極的に関与することが必要である。それができる人材がいないのなら、第三者にその実現性確認を実施してもらうことも有効だ。
これからERP導入プロジェクトの立ち上げを検討している企業は、プロジェクトを成功に導くためにも、ぜひこれらについて検討いただきたい。