基幹システム導入のRFP作成ガイド：失敗しない要件定義

失敗した基幹システムプロジェクトによくある光景があります。分厚い文書、何百行にも及ぶそれが、ベンダーの机に置かれます。社内のだれかがかつて望んだ機能がすべて書き連ねてあります。なぜシステムを入れ替えるのか、その本来の目的はひとことも書かれていません。ベンダーは姿を消すか、要点を外した曖昧な提案を返すかのいずれかです。半年後、プロジェクトは予算超過で、誰の役にも立っていません。

この文書がRFP、提案依頼書です。そしてほとんどのRFPは、間違っているからではなく、順序が逆だから失敗します。本記事は、本当に機能するRFPの書き方のガイドです。

要望の羅列ではなく、なぜ（Why）から始める

要件が一つでも紙に上がる前に、一文で答えてください。このプロジェクトが必ず直さなければならない、いま壊れているものは何か。月次決算に2週間かかる。システム全体を頭に入れているのが一人だけ。消費税が四半期ごとの慌ただしい作業になっている。本当の痛みを選び、名付け、その後のすべての決断をそれで駆動させてください。

要件定義が失敗する最大の原因は、日本のIT推進機関や、事後処理にあたるコンサルタントの経験からも、業務目的が共有されていなかったことです。チームは問題ではなく要望の羅列を書きます。良いRFPは、ありもしない機能の羅列ではなく、問題のうえに組み立てられます。

誰が同じ部屋にいなければならないか

一つの部門の一人物が書いた要件定義は、それが奉仕するはずの会社を見落とします。痛みを感じている人たちが、痛みを語る人たちでなければなりません。

それは、帳簿を締める経理担当、在庫を数える倉庫や業務の担当、受注を追う営業担当、そして決定できる権限を持つ誰かです。経営層と現場が要件を定める場に同じ部屋にいなければ、隙間は後になって、高価で遅い形で現れます。ベンダーは御社の業務に必要なことを推測できません。自社の人がそれを語る必要があります。

本当に重要なRFPの項目

百の項目は要りません。正しい項目を、ベンダーが動ける業務の言葉で書くことが必要です。少なくとも次は含めてください。

自社そのもの。 法人格の詳細、法人番号や税務登録番号、業務の基準となるタイムゾーン、決算月、日付や数値の書式。些末に聞こえますが、そうではありません。自社の基本情報を保持できないシステムは、最初のページから誤った文書や帳票を出力します。

会計を土台に。 複式簿記が後付けではなく土台であることを求めてください。消費税は、税率ごとに売上税と仕入税の別々の勘定を通り、取引先の適格請求書発行事業者登録番号はその取引先の記録に保持されなければなりません。税が手入力の項目として扱われているなら、インボイス制度は恒久的な頭痛になります。

業務の中核。 受注、購買、ロット追跡付きの在庫、そして承認を適切な担当者に回すワークフロー。何がつながるべきかを示し、売上が人の再入力なしに受注から請求書、仕訳へと流れるようにしてください。

アクセスと言語。 誰が、どこから、どの言語でシステムに届く必要があるか。チームが日本語と英語をまたぐなら、最初からそう書き、システムが表面上の翻訳ではなく、両方でネイティブに作られているかを問うてください。

データと成長。 各社のデータがどう分離されているか、どうバックアップするか、どう小さく始めて拡張するか。コミットする前に新旧を並行稼働させることをベンダーに見せるよう求めてください。

深さの試験：厚すぎず、薄すぎず

RFPは長すぎても短すぎても失敗します。何百行にも及び、考えうる機能をすべて要求する文書は、真摯なベンダーを遠ざけます。数行の内容の薄い文書は、役に立たないほどありきたりの提案しか返しません。

重要なものには深さを、そうでないものには簡潔さを狙ってください。それぞれの本当の痛みについて、ベンダーが業務問題を理解し、具体的な対応で返せるだけを書きます。それ以外は一行で十分です。基準は、御社を見たことのないベンダーがそれを読んで、成功がどんな姿か理解できるか、です。

実際の事例

横浜にある従業員約50名の商社を考えてみてください。最初のRFPは300行を超え、各部門の要望の羅列を一つのファイルに転送して組み立てたものでした。2社は入札を辞退しました。3社目は、年間利益を超えるシステムの提案を返し、それでも月次決算は直りませんでした。

同社は書き直しました。なぜ（Why）から始めました。決算に12日かかり、消費税が四半期ごとの火消しになっていた。経理、在庫、営業を同じ部屋に集めました。文書を40行未満に切り詰め、各行を本当の問題に結びつけ、重要ないくつかを明示しました。会計を土台に、消費税の別勘定、ロット追跡、承認ワークフロー、ネイティブな日本語と英語です。

新しいRFPは3つの的を絞った提案を返しました。同社はクラウドの基幹システムを選び、2か月間並行稼働させ、月次決算を12日から2日に短縮しました。機能した文書は、要望の羅列で作られた長いものではなく、本当の問題で作られた短いものでした。

プロジェクトを沈めるよくあるRFPの失敗

本当の痛みを直す少数ではなく、だれもが望んだ機能のすべてを要求すること。
一つの部門だけで要件を書くこと。
業務が後から検証できない専門用語で書くこと。
監査が迫るまで消費税とインボイス制度を忘れること。
並行稼働の要件を飛ばし、盲目的な切り替えに追い込まれること。
実際に何を届けるかを読まずに、最も安い提案を選ぶこと。

RFPはできていますか

このプロジェクトが必ず直すべき、最大の痛みを一つ名指ししている。
経理、業務、営業が同じ部屋で書かれている。
会計を土台に求め、消費税を手入力ではなく構造化している。
コミット前の並行稼働を明示している。
一度も会ったことのないベンダーが読んで、成功の姿がわかる。

よくある質問

ERPのRFPはどのくらいの長さがよいですか。

それぞれの本当の問題を業務の言葉で説明できる長さで、それ以上は不要です。中小企業の多くでは、何百行ではなく数十行です。ベンダーが一午後で読んで、パンフレットのような一般論ではなく具体的な対応を返せる長さが目安です。重要な痛みへの深さが、重要でない機能への広さに勝ります。

コンサルタントに書いてもらう必要はありますか。

常にではありません。痛みを感じている人が同じ部屋にいること、問題の明確な声明、そして要望の羅列を切り詰める規律が必要です。コンサルタントは構造化を手伝えますが、何が本当は壊れているかを自社のチームが名指すことを代えることはできません。

ほとんどのRFPが忘れることは何ですか。

並行稼働です。企業は機能を指定し、チームが新しい数字を信頼するまで新旧を並行稼働させることを忘れます。それなしでは盲目的にコミットし、あれば何も危険にさらす前に検証できます。より広い枠組みはクラウドERPの選び方ガイドをご覧ください。

ポイント： 良いRFPは名指しされた問題のうえに立ち、痛みを感じる人とともに書かれ、重要なものには深くそうでないものには簡潔で、コミット前に必ず並行稼働を求めます。

要件を実際のシステムで試してみませんか

何が可能かを知るために、完成したRFPは要りません。Kikan Systemなら、2ユーザーまで無料、カード不要で始められます。本当の月末の悩みを持ってきて、要件のうちシステムがすでに満たしているものを示してもらいましょう。

→ 無料で始める