「見える化したのに、システム選びで止まる」のはなぜか
業務の流れを書き出し、現状と理想の差も見えてきた。次はシステムを選ぶだけ——そう思った矢先に、手が止まる経営者は少なくありません。
「どのベンダーに声をかければいいのか」「何を渡せば、まともな見積もりが返ってくるのか」「そもそも、社内の承認はどう取ればいいのか」。せっかく業務を見える化しても、その成果物を発注の場へどうつなぐかで、多くの会社がつまずきます。
見える化は、それ自体がゴールではありません。整理した業務を「選べる状態」に変えて、はじめて経営の判断につながります。
この記事では、見える化の成果物をシステム選定につなぐ3つの文書——RFI・RFP・稟議——を、発注する側の経営者の目線で整理します。書き方の細部より、「全体の流れの中で、それぞれが何のためにあるのか」を押さえることを目指します。
見える化の成果物が、そのまま発注の材料になる
システム選定の準備は、ゼロから始めるものではありません。各論で業務を見える化してきた会社なら、必要な材料はもう手元にあります。
現状業務分析でつくった業務概要、部署をまたぐ流れを描いた業務フロー、必要な機能をまとめた機能一覧、そして理想と現状の差から出てきた要求事項。これらはそのまま、ベンダーに「何をしてほしいか」を伝える材料になります。
なぜ、この成果物が効くのか。ベンダーは、渡された情報の精度でしか提案できないからです。業務の流れも、解決したい課題も書かれていなければ、各社はバラバラの前提で見積もりを出します。比較しようにも、土俵がそろいません。
逆に、業務の現状と目指す姿が整理されていれば、各社は同じ土俵で提案を競います。発注する側は、提案の良し悪しを正しく見極められるようになります。
見える化が活きるのは、まさにここです。整理してきた成果物の一つひとつが、より良い提案を引き出す「問いの質」を決めるのです。
（各論で何をつくるかは、現状業務分析のつくり方〔2-4〕、業務フローの書き方〔2-5〕、As-IsからTo-Beへ〔2-9〕で詳しく解説しています）
RFI・RFP・稟議——発注の3つの文書を経営者目線で整理する
システム選定では、3つの文書が登場します。RFI、RFP、稟議です。聞き慣れない言葉もありますが、役割で捉えれば難しくありません。
RFI（情報提供依頼書） は、候補となるベンダーに「どんな会社で、どんな実績があるか」を尋ねる文書です。本格的な提案を頼む前に、声をかける相手を見極めるために使います。
RFP（提案依頼書） は、絞り込んだ相手に「この課題を、どう解決してくれるか」を尋ねる文書です。見える化の成果物が、ここで生きてきます。
稟議 は、選んだ案を社内で承認にかけるための文書です。発注の意思決定を、正式に通す段階で使います。
3つの違いを、表で整理しておきます。
| 文書 | 誰に向けて | 何を尋ねる／伝えるか | いつ使うか |
|---|---|---|---|
| RFI | 候補のベンダー | どんな会社で、どんな実績があるか | 声をかける相手を見極める段階 |
| RFP | 絞り込んだベンダー | この課題を、どう解決してくれるか | 提案を求めて比べる段階 |
| 稟議 | 社内の決裁者 | なぜこの投資が必要で、何が良くなるか | 選んだ案の承認を取る段階 |
向ける相手が「社外 → 社外 → 社内」と移っていくのが分かります。この流れを、順番に見ていきましょう。
この3つは、選定の流れの中で順番に並びます。
図1：システム選定の流れ（RFI→RFP→稟議）
候補を広く集め、提案で絞り込み、最後に社内の承認を得る。「数社に声をかけ、3社ほどに提案を求め、1社に決める」という流れは、実際の選定でもよく見られる形です。
大切なのは、文書を立派に仕上げることではありません。3つの文書を通して、発注する側が主導権を握ることです。
ベンダーに言われるまま進めるのではなく、自社の課題を起点に、候補を比べ、社内を納得させて決める。この一連の流れを設計できる会社は、システム選定で失敗しにくくなります。
なお、RFPの細かな書き方や項目の埋め方は、それだけで一つの専門領域です。本記事では全体像の把握に絞り、書き方の詳細には立ち入りません。
稟議は「社内向けの企画提案書」である
3つの文書のうち、稟議だけは少し性格が違います。RFIとRFPが社外のベンダーに向けた文書なのに対し、稟議は社内に向けた文書だからです。
稟議と聞くと、印鑑を回すための事務手続きを思い浮かべるかもしれません。けれど、本当の役割はそこではありません。稟議とは、社内を動かすための「企画提案書」です。
考えてみれば、ベンダーに提案を求めたのと同じことを、今度は自社が社内に対して行うわけです。「なぜこの投資が必要か」「何が良くなるのか」「いくらかかり、何が返ってくるのか」。これらに答えられなければ、社外のベンダーも、社内の決裁者も動きません。
実際の稟議書では、こうした項目が並びます。
- 議題と内容：何を導入するのか
- 理由：なぜ必要か。どんな課題を解決するか
- 効果：導入すると、何がどう変わるか
- 金額の内訳：いくらかかるか
通る稟議とそうでない稟議の差は、この「理由」と「効果」の書き方に出ます。
たとえば「業務を効率化するため」と書くだけでは弱い。「いまレポート作成に1日かかっている作業を、短縮できる。空いた時間を顧客対応に回せる」というように、課題と効果を具体的につなげると、読み手は判断できます。
ここで効いてくるのが、やはり見える化の成果物です。現状の業務がどう流れ、どこに無駄があるかを整理してあれば、「何が、どれだけ良くなるか」を具体的な言葉で書けます。
稟議を「通すべき提案」として捉え直すと、見える化からシステム選定までが、一本の線でつながります。
発注側がつまずきやすい3つの落とし穴
見える化の成果物が手元にあっても、発注の進め方を誤ると、選定はうまくいきません。よくあるつまずきを3つ挙げておきます。
1つ目は、目的を書かずに機能だけを並べてしまうこと。 「あれもこれも」と必要な機能を列挙しても、なぜそれが要るのかが伝わらなければ、ベンダーは優先順位を読めません。結果、すべてを盛り込んだ過剰な見積もりが返ってきます。機能の前に、解決したい課題を書く。順番が大切です。
2つ目は、各社に違う前提で声をかけてしまうこと。 口頭での説明や、相手ごとに異なる資料で依頼すると、返ってくる提案もバラバラになります。比べる土俵がそろわず、判断できません。同じ材料を、同じように渡す。これが比較の前提です。
3つ目は、社内の合意を後回しにすること。 現場の意見を聞かないまま選定を進めると、稟議の段階で「うちの部署の事情が反映されていない」と反発が出ます。見える化の段階で関係者の認識をそろえておくことが、後の承認をスムーズにします。
どれも、特別な知識がないと避けられないものではありません。ただ、初めての選定では気づきにくいのも事実です。ベンチャーネットは、こうした発注側の準備から、伴走する形で支援しています。困ったときは、気軽に声をかけてください。
よくある疑問
Q. RFIは、必ず作らないといけませんか？
候補がすでに絞れているなら、省くこともあります。ただ、どのベンダーに声をかけるか迷う段階では、相手を見極める材料として役立ちます。
Q. 比較する会社は、何社くらいが適切ですか？
決まりはありませんが、提案を求める段階では3社前後がよく見られます。多すぎると比較に手が回らず、少なすぎると判断材料が足りません。
Q. 専門の担当者がいなくても、進められますか？
進められます。むしろ大切なのは、自社の業務を一番わかっている人が関わることです。足りない部分は、外部の伴走者を頼る選択肢もあります。
まとめ：見える化を「選べる状態」につなぐ
業務の見える化は、整理して終わりではありません。整理した成果物を、システムを「選べる状態」に変えてはじめて、経営の判断につながります。
その橋渡しをするのが、RFI・RFP・稟議という3つの文書でした。候補を広く集め、提案で絞り込み、社内の承認を得る。この流れを発注する側が設計できれば、システム選定は、ベンダー任せの不安なプロセスではなくなります。
そして、その土台になるのは、やはり日々の見える化です。業務の現状が整理されているほど、ベンダーへの問いも、社内への提案も、具体的な言葉で書けるようになります。
第2章では、見える化の各場面を一つずつ取り上げてきました。あらためて振り返るなら、次の記事が出発点になります。
- 現状業務分析のつくり方〔2-4〕——何を整理すればいいか
- 業務フローの書き方〔2-5〕——流れをどう1枚にするか
- 業務ヒアリングの進め方〔2-6〕——現場の本音をどう引き出すか
- As-IsからTo-Beへ〔2-9〕——理想と現状の差を、改善提案に変える
見える化からシステム選定まで、自社だけで進めるのが難しいと感じたら、その準備段階からご相談いただけます。ベンチャーネットは、発注する側の立場に立って、選定の設計から伴走します。
