プロジェクトの成否を左右するRFP記載事項の肝とは？
細川 義洋氏
第一部の基調講演には、EnterpriseZineでもおなじみ、ITプロセスコンサルタント細川義洋氏が登壇。IT訴訟の事例を見ながら、揉めない、失敗しないためのRFPを書く時の留意点や、その時点から考慮しておくべきリスク等にについて解説が行なわれた。
冒頭、細川氏は「システム開発失敗の9割は要件定義に原因があると言われているが、実際にはそのうち何割かは、とっかかりであるRFPにある」と語り、プロジェクトの成否を左右する要素としてのRFPの重要性を説いた。
その上で、RFPに記載すべき事柄について、大手ITベンダで結果的に成功したプロジェクトのものを参考に例示。
細川氏が挙げる記載事項は下記の通りである。
基本情報(提案の前提となるユーザの情報や環境)
- ユーザの基本情報 (業種、業態、組織、提供する製品やサービス 等)
- ユーザのいる市場と競合状況
- ユーザを取り巻く環境とその変化
提案依頼の主旨・目的 (依頼の背景、目的及び前提・制約条件等)
- システムやサービス導入の背景 (経営方針及びシステム化方針 等)
- 開発/サービス導入 (プロジェクト) の目的 (期待される効果・メリット 等)
- 使用者に関する情報 (部門及び業務的な役割、人数 等)
- マスタスケジュールとマイルストーン
また、ERPをはじめとする、エンタープライズ系IT導入のRFP (提案依頼書) には、概ね以下のようなことが記述される。
提案を依頼したい事項 (提案してほしい、システムやサービスの具体的な内容、範囲等)
- サービス範囲や作業範囲 (対象システム/サブシステムや工程 等)
- 役割・責任分担(ユーザとベンダの作業分担)
- 想定するシステム開発手法、プロジェクト管理手法
- 想定する成果物
- 要件概要(機能要件/非機能要件)
- 新システム/サービスに関する社員教育の要望
- その他要検討事項および未決事項
- 提案書の目次、体裁、提出期限、提出方法、選考方針 等
細川氏によれば、多くの場合、裁判所にやってくるようなトラブルプロジェクトは、この記載すべき事項のどれかが抜け落ちているという。
「逆に、これらについて、本当にしっかりと書かれた提案書を基にしたシステムは、やはり成功率がぐんと上がる。提案者に正しい提案書を書いてもらうためにも、ユーザはぜひこのあたりをしっかりと理解してRFPを出す必要があるでしょう」（細川氏）
IT導入を巡る裁判の中には、RFPに記載する「プロジェクトの目的」に起因するものが数多く見られるという。これを受け、プロジェクトの目的を巡って行われた実際の裁判の事例が紹介された。
株式上場を目指すとある企業が基幹情報システムの刷新のため、SBOの初期導入、移行、アドオン開発をITベンダに依頼したが、多数の欠陥やシステムテストの難航のため、プロジェクトはとん挫した。原告は費用の支払いを求めて被告を提訴し、被告も、原告が債務を履行せず、プロジェクトの目的を達成しなかったと反訴したというケースだ。
この事件では、RFPに記載した「プロジェクトの目的」が、契約の内容であったか、つまり「それを達成しなければお金を貰えないものだったのか」 が大きな争点となったという。
この時にREPに記載された「プロジェクトの目的」とは以下の3点だった。
- 販売・購買業務の効率アップ
- CRMの基盤作り
- 社長・役員に会社の全ての業務が正確に見える。＝『見える経営』を行う
ユーザ側の言い分は「契約の内容である。システムは未完成であり、目的達成が阻害されたのだから、損害賠償の対象となる」というもの。これに対してベンダ側の反論は「契約の内容は、要件であり、目的を達成できなかったことによる損害の責任は負わない」というもの。
このように、プロジェクトの目的が不明確だと、問題が起こりやすい。
「プロジェクトの目的を正しく書いても、失敗時の責任をベンダだけに問えるかと言えば疑問ですが、少なくとも、ベンダが自分の持ちこんだパッケージに拘泥したがゆえに機能を満たさずプロジェクトを失敗しても、それを追及する論拠が弱いということになってしまいます」（細川氏）
では、判決ではどうなったのか。
裁判所は「抽象的で要件を導出しない目的は、単なる共通認識」とし、「要件を導出できないような抽象的な目的は、契約の性質を有しない」、つまり、それを達成しなかったからといってベンダに損害賠償はできないと結論づけたという。
「ユーザの方は裁判に勝つために仕事をしているわけではないが、この例の開発の失敗が、目的共有の不足によることは明らかである」と細川氏は指摘。そして、プロジェクトの目的をしっかりと固めるために「経営方針」から落とし込んでいくことを勧めた。
「RFPを記述する段階で大切なことは、具体的な実現方式やパッケージのことはいったん忘れて、経営方針から課題を明らかにして、それを解決する業務要件を導出できる『プロジェクトの目的』を明確にすることが重要です」（細川氏）
最後に細川氏はまとめとして、「プロジェクトの目的を無駄にしないベンダ選定」として「自分の担ぐパッケージに拘泥しないか？」「業務とプロジェクトの目的を理解する能力ができるか？」「業務自体の提案が可能か？」「目的に照らして、要件の優先順位を決められるか？」「当初の目的からずれたら是正できるか？」「代替提案ができるか？」などの着眼点を挙げ、セッションを締めくくった。
ERPは「既製品」であるという意識が重要
引き続き、第2部では「失敗しないためのERP導入プロジェクトの秘訣～国内外のERPシステム導入における成功・失敗～」と題して、株式会社日立システムズの田中啓喜氏による講演が行われた。
50年以上にわたるSIとしての実績から、大企業から中堅・中小企業の製造業からサービス業まで、さまざまなお客さまのERP導入を支援してきた日立システムズ。田中氏は、国内、海外問わず多くの企業の基幹システムの導入プロジェクトに従事してきた。現在は、西日本地区を中心に活動、SAPを中心に企業の経営基盤の構築に携わり、コンサルテーションからプロジェクト責任者として活躍している。
RFPの着眼点としては、以下の4つがあるという。
- プロジェクト目的と課題 / 顧客体制：経営層の関与、メンバー関与など
- ERPシステムへの理解（啓発など）
- 現行システム踏襲 or 業務・システム改善
- 年商規模、業種、データ量
「こうした着眼点の結果、パッケージを意識しないで、目標、ゴール、共有課題、ERPを知る、意識向上も含めた業務改善の事前フェーズを提案など、RFP通りの提案をしないケースもあります」（田中氏）。
1998年から積み重ねてきた経験から田中氏が挙げる『当たり前だけどやはり』重要なポイントは「トップダウンによるプロジェクト推進」「アドオン開発の削減」「ユーザ部門の参画」「マスタ整備」だ。トップダウンによるプロジェクト推進は、先に細川氏が述べた「経営方針からプロジェクトの目的を明確化する」ことにも通じるものがある。
また、これ以外の留意点として、準備フェーズにおける相互の理解、業務、製品知識の共有や、 顧客体制（専任 or 非専任/キーマン/参加度合など）、コミュニケーションプラン（キックオフ会議、ステコミ、定例会、レビューなど） 、 経験値（特に業界、テンプレート）、早期の機能確認などがあるという。
いずれにせよ、早め早めの対応を意識すること、そしてベンダとユーザが本音でコミュニケーションをとることが大事なことには変わりない。
田中氏は「ERPシステムは『既製品』であることの意識が重要。『ベンダ任せ』でなく『ユーザ』が作り上げるシステムである」としてセッションを閉じた。
