当社のコンサルティングメニューの1つとして「計画策定」というものがあります。これは当社のフレームを用い経営・現場・IT・DXの視点から現行システムの現状や問題の可視化を行い、ITで解決すべき課題を明らかにした上でIT構想としてまとめ、システムベンダーに提案をお願いする提案依頼書（RFP）を作成するコンサルティングです。自社の課題・実現したいことや、開発に必要な要件、情報を漏れなく提供することでベンダー側から最適な提案を受けることに繋がります。また、お互いの認識が統一できていることで不必要なトラブルを避け、その後の開発をスムーズに進めることを目的にしています。
その際に、経営者、DX企画担当者・IT部門から様々な相談を受けます。

システム選定の失敗事例

当社の営業やコンサルタントが色々な企業に足を運んだ際に、お客様から聞いた「システム導入の失敗例」の一部をご紹介いたします。

• 新しいシステムになって、以前は出来ていたことが出来なくなった
• テスト不足による品質不良、カットオーバーするも数字が合わない
• 本番稼働が何度も延伸、半年、1年延伸も珍しくない
• 使いにくい、費用を掛けたが前と変わらない、など現場から不満だらけ
• データ連携ができず結局手作業だらけ、作業工数が減らない
• ベンダーとの不仲、訴訟寸前

決して1〜2社のお客様ではありません。何社からも伺う話です。「だから次のシステム更改は上手くやりたい」とお客様は言いますが、多分同じ結果になると想定されます。何故なら、失敗の理由を理解していないからです。

当社が考える失敗の大きな理由は以下の5つです。

【失敗1】目的が不明確
目的やゴール、意義やビジョンも検討せず、とりあえず技術適用の実証実験（PoC）を実施してしまうことです。

【失敗2】業務課題との乖離
華やかに見える内容、非現実的な変革を想定した内容、逆に何も効果が得られない内容にデジタルを導入しようとしてしまうことです。

【失敗3】合意の未形成
システム更改の推進には賛成するが、自身に対する影響を考え消極的になってしまう、特定部門だけ導入拒否を誇示してしまうなど、総論賛成・各論反対ではうまくいきません。

【失敗4】情シス部門に丸投げ
システムのことだからと、情シス部門に丸投げしてしまうことです。システムは専門的で難易度の高い技術だから、新しい技術についていけないから、また効果が想定できないからなどの理由で情シス部門に押し付けることです。

【失敗5】経営層の不関与
経営層が、システム更改を指示したにも関わらず、方針を示さない、責任を果たさない、成果ばかりを求めてしまうことです。

プロジェクトの開始前に目的やゴールを定めていないので、失敗も成功もわからない。だから後になってシステムが悪い、選定した人が悪い、ベンダーが悪いとなるのです。まずは導入前の計画を定めることが重要です。

計画を策定する際は以下の内容を定め、文書化することが重要です。

• 目的とビジョンの明確化
• 経営・業務課題の可視化
• 経営層の積極的な関与
• 検討の組織化
• 計画の文書化

当社ではシステム導入するお客様を支援して、システムベンダー、または社内合意のために、目的・要求・計画を示したRFP（提案依頼書）を作成してプロジェクト成功に向けて導いています。

RFP（Request for Proposal）とは

システム検討を行う工程に「RFP（提案依頼書）」という言葉があります。これは、発注する側の企業が、システムベンダーに対して自社の課題や実現したい要望などを示す書類です。つまり、自社の業務内容、システム内容をシステムベンダーに理解してもらい、より良い提案を受けるための資料です。

RFPの意義とは

システムベンダーから最適な提案を引き出すことです。そのため理想的な提案「To Beモデル」ではなく、現実的な要求「Can Beモデル」を描くことが重要です。「To Beモデル」とはあくまでも理想形であり、ある意味「絵に描いた餅」となるリスクがあります。要望を限りなく理想に近づけるために、膨大なカスタマイズ費用がかかってしまっては意味がありません。そこで実現に必要なカスタマイズに優先順位をつけ、必要最低範囲に限定することで、現状システムの効率性・迅速性は改善され、現実的な費用でシステム導入を成功させることができるのです。

RFP作成のメリット・デメリット

RFPを作成する場合、しない場合、どのような問題が起きるでしょうか。それぞれのメリット、デメリットを見てみましょう。

	RFPを作成する場合	RFPを作成しない場合
メリット	同じ土俵で各ベンダーから提案を受けることができ、客観的に評価することができる。 導入目的、課題、要件など明確化しやすい。 ベンダーを選定する時に、比較すべき項目が明確になる。 ベンダーとの誤解やトラブルが軽減できる。 経営層や関係部署との理解を得やすい。	ベンダー選定までの時間や人手が少なくて済む。
デメリット	RFP作成までの時間と労力がかかる。 社内の課題・問題をまとめるのに手間がかかり、社内の知見だけでは作成するのが難しい。	システム構築の目的を理解してもらえないまま、システム選定を進めてしまう恐れがある。 ベンダー側の提案を独自に解釈してしまい、相違した内容で受ける可能性がある。 要件・課題の伝え漏れが発生し、不足した提案を受ける場合がある。

RFPを作成する場合
メリット	同じ土俵で各ベンダーから提案を受けることができ、客観的に評価することができる。 導入目的、課題、要件など明確化しやすい。 ベンダーを選定する時に、比較すべき項目が明確になる。 ベンダーとの誤解やトラブルが軽減できる。 経営層や関係部署との理解を得やすい。
デメリット	RFP作成までの時間と労力がかかる。 社内の課題・問題をまとめるのに手間がかかり、社内の知見だけでは作成するのが難しい。
RFPを作成しない場合
メリット	ベンダー選定までの時間や人手が少なくて済む。
デメリット	システム構築の目的を理解してもらえないまま、システム選定を進めてしまう恐れがある。 ベンダー側の提案を独自に解釈してしまい、相違した内容で受ける可能性がある。 要件・課題の伝え漏れが発生し、不足した提案を受ける場合がある。

悪いRFPと良いRFP

提案依頼とはシステム導入ベンダーに「案」を提示させることです。「案」とは目的達成に向け課題を解決する手段（企画案）です。ベンダーから良い「案」を提示してもらう事が重要であり、RFPが悪いと、悪い提案となってしまうのです。

悪いRFP

ダメなRFPは、システムベンダーから質の低い「案」しか引き出せず、目的達成が困難になってしまいます。

実際に当社が確認した悪いRFP

• 現行システムの画面のハードコピーが1枚付いているだけ。明らかな手抜き
• 必要な要素が書かれていない。何について書かれているか分からない
• ERPで実現できそうにないことが記載されている。非現実的な要求
• 背景・目的・ゴール・狙いがない。何を求めているか分からない
• 質問責め、「〜が出来ますか」「〜機能がありますか」どうしてその機能が必要か分からない
• 見積の要求。費用だけが選定基準？

悪いRFPをもらったシステムベンダーの対応

• なんだこりゃ、訳の分からないRFPをもらってしまった。何度読んでもよくわからない
• 辞退もできないし、使いまわしの提案書を出しとけばいいや
• この要求じゃ絶対うまくいかないと思うけど気付かなかったことにしよう

システムベンダーからこのような提案書をもらったお客さまの感想

• とりあえず提案書をもらったけど、標準的機能の記載のみで当社の課題・要望が対応されているのだろうか
• どこの提案書も同じに見える。比較できないなぁ
• なんだか今のシステムと比べて良くなる気がしないなぁ
• どれも価格が高いなぁ。社長が決裁してくれなさそうだなぁ

良いRFP

では良いRFPとはどのようなものでしょうか？
当社が考える良いRFPとは以下の通りです。

• ベンダーが良質な提案をする為に必要な情報が記載されている
• 目的に対する手段検討や選定として「案」を求めている
• 背景・目的・ゴール・狙いが記載されている
• 前提条件や制約事項が正しく記載されている
• 経営・現場・ITそれぞれの問題や要望が記載されている
• 自社で合意形成がなされたRFPの内容になっている
• 受領した提案書の内容から経営がIT投資判断をできるような依頼となっている

基幹システム更改のプロジェクトにおいて、計画の策定は必要です。しかし、プランを立てれば良いわけではありません。まして、RFPを作れば終わりでもないのです。経営戦略やビジネス戦略を実現する、高度な情報基盤である基幹システム構築を通じ、経営者の理解、社内の合意など社内運営の改善が行われることで、積極的な事業戦略を展開することが可能となり．その結果，競争力のある企業となるのです。

今回は「システム更改に向けた提案依頼書（RFP）の注意すべき事柄」を記載しました。いかがでしたか、参考になりましたでしょうか。
第6回：システム更改に向けたプロダクト（ベンダー）選定の注意すべき事柄もご覧ください。

• 
• 
•