基幹システム更新（入替）の進め方｜調達編 — RFP作成とベンダー選定を現役情シスが解説

システム調達を任された時、「どう進めるべきか」「何を基準に選ぶべきか」という悩みを抱えていませんか？

システム調達は、企画フェーズで固めた方針を、実際の発注につなげる工程です。
ここで躓くと、次のようなトラブルにつながります。

  • 高いだけのシステムをつかまされる
  • 契約後に「できません」を連発される

この記事では、私が会計システムの更新で実際に踏んだ調達の流れと、現場で工夫した点をお伝えします。
RFP作成からベンダー選定までの具体的な進め方をお伝えするので、ぜひ最後までご覧ください。
現役情シスのWebライターである私が、実体験ベースで解説します。

目次

1. システム調達とは？

システム調達の全体像

システム調達とは、企画で決めた方針をもとに、ベンダーを選定して契約するまでの工程です。
主な工程は、次のとおりです。

  • RFI（情報提供依頼）で相場観をつかむ
  • 仕様書の作成
  • RFP（提案依頼書）を作る
  • 公募して、仕様書説明会を開く
  • 質問に対応する
  • 提案を評価して、ベンダーを選ぶ
  • 契約前協議を経て、契約する

企画と違い、調達は実際に契約を決める工程であり、一度決めたら後戻りできないプレッシャーがあります。

1-1. 調達でよく使う3つの言葉

調達では、聞き慣れない用語が出てきますので、整理しておきます。

用語意味
RFI（情報提供依頼）ベンダーに製品情報や概算費用を依頼する文書
RFP（提案依頼書）ベンダーに「提案してください」とお願いする文書
プロポーザル価格だけでなく、提案の中身も見て選ぶ調達方法

RFPとプロポーザルは混同されがちですが、別物です。
RFPは「提案してください」とお願いする文書です。
一方でプロポーザルはRFPをもとに、ベンダーが提案するシステムを選定・調達するプロセスを指します。

2. システム調達の流れ

システム調達の流れ

ここからは、システム調達の各工程を順に解説します。

2-1. RFI（情報提供依頼）で相場観をつかむ

いきなりRFP（提案依頼書）を書くと、的外れな要求になりがちです。
まずRFI（情報提供依頼）で、各ベンダーから製品情報・導入実績・概算費用を集めます。
私の場合は以下のように、2段階に分けて実施しました。

  • 1回目：製品情報や相場観など大枠の情報収集
  • 2回目：システム企画をもとに具体的な仕様を盛り込んだうえでの情報収集

現場メモ

こちらの運用イメージを具体的に開示すると、ベンダーの回答精度が上がります。
「教えてください」と丸投げするより、想定している仕様を伝えたほうが、有益な情報が返ってきます。

2-2. 仕様書の作成

調達の山場が、この仕様書作成です。
仕様書は大きく「仕様書本編」と「機能要件」に分かれます。

仕様書本編

仕様書本編には、プロジェクトの土台となる条件を書きます。

  • 目的：なぜ更新するのか
  • 調達範囲：どこまでを発注対象にするか（端末は対象外、など）
  • 前提条件：年間処理件数・利用者数・同時接続数などの数値
  • 契約条件：運用実績・保証年数・運用保守体制
  • スケジュールと体制：工程・会議体・成果物

仕様書で大切なポイントは「何を解決したいか」を書くことです。
解決策まで指定すると、ベンダーの工夫が消え、提案がどれも似てきます。
一方で、契約・体制・実績の条件は、あえて具体的に記載してもらいます。
ここを曖昧にしたままだと、契約後に「言った・言わない」で揉めます。

機能要件

機能要件は、システムに実装してほしい機能を一覧化したものです。

実際の機能要件シートのイメージは、以下のとおりです。

大項目中項目要件内容重要度対応区分備考
予算管理予算登録部門別・科目別に予算を登録できること高◎
予算管理予算流用流用元・流用先を指定して予算流用ができること中□運用での代替を備考に記載
支払管理支払伝票振込データを所定フォーマットで出力できること高◎
契約管理契約台帳契約金額・期間・相手方を一覧で照会できること高△カスタマイズ費用は提案に含む
共通帳票出力帳票レイアウトを利用者側で軽微に変更できること中×対応不可

※実際は450項目。上の表は説明用に5項目を抜粋した架空のサンプルです。

仕様書本編が「契約・体制・前提」を扱うのに対し、機能要件は「個別の操作・処理・機能」を一行ずつ書き出します。

書き方の原則は3つあります。

  • 原則1：1項目に1要件だけ書く
  • 原則2：業界用語や社内用語は使わない
  • 原則3：機能ごとに優先度を設ける（高、中のように）

私のプロジェクトでは、機能要件は450項目になりました。

たたき台は情シスが作り、各プロジェクトメンバーにチェックと肉付けをしてもらう形にしました。

各ベンダーには、項目ごとの対応可否を所定の形式で回答してもらいます。

ここでの工夫は、4章でくわしく解説します。

現場メモ

仕様書の作成では、公的機関のテンプレートを参考にしました。
特に参考にしたのは、IPAの「非機能要求グレード」です。
非機能要件は要件定義での揉めごとの大半を占めるため、業界標準のシートを土台にする方が早く・抜けが少なく仕上がります。

2-3. RFP（提案依頼書）の作成

RFPは、ベンダーに「提案してください」とお願いするための文書です。

内容は仕様書がメインですが、その他にも手続き全体をまとめます。

「いつまでに、どんな様式で、どんな前提で提案してほしいか」をRFPで伝える必要があります。

RFPに書く要素は、大きく5つです。

  • 仕様書：2-2で記載
  • 提案依頼の目的：なぜ提案を募集しているか
  • 応募条件：参加できるベンダーの要件
  • 評価基準：どの観点で点数化するか
  • 提出ルール：締切・形式・提出先

2-4. 公募と仕様書説明会

RFPが固まったら、公募して参加ベンダーを募ります。
参加表明があったベンダーには、仕様書説明会を開きました。

説明会では、手続きの流れ・提出期限・質問ルール・評価基準を、ていねいに説明します。

現場メモ

私の場合、仕様書説明会はオンライン会議で行いました。
ベンダー同士で参加企業名が分からないよう、参加者名をA社・B社のように匿名化しています。
プレゼン当日の発表順も、その場のくじ引きで決めました。
RFPの公示から提案書の提出までは、できれば1ヶ月半（最低1ヶ月）は確保しましょう。

2-5. 提案受付とベンダーからの質問対応

提案の受付期間中、ベンダーからは多くの質問が来ます。

質問は所定の様式をメールで受け付け、電話での個別対応は受けませんでした。

現場メモ

質問への回答は、全ベンダーに一斉に共有しました。
特定の1社だけが有利な情報を得ることを防ぐためです。

2-6. 提案書提出とプロポーザル

次にシステム調達でもっとも重要な工程である、プロポーザルについてです。

提案書の提出と選定は以下の流れで行いました。

  1. 各ベンダーから提案書を事前にもらう
  2. 提案書をもとに情シスが①価格点と②機能点を算出する
  3. プロポーザル当日、ベンダーごとに別の時間枠を設け、順番にプレゼン
  4. 選定委員会（役員）が、提案書とプレゼンをもとに③総合点を採点する
  5. ①価格点②機能点③総合点を集計して、ベンダーを選定する

現場メモ

プロポーザルは基本的に①価格点②機能点③総合点に分けて評価します。
このうち「価格点」「機能点」は提案書提出時点で分かりますので、情シスで採点します。
残りの「総合点」はプレゼンを聞きながら、選定委員である役員に評価してもらいます。
詳しくは次章で説明します。

2-7. 契約前協議

ベンダー選定が終わっても、すぐに契約するわけではありません。
契約の前に、システム仕様や開発方針を確認するため、協議の場を設けました。

プロポーザルのプレゼンは、時間が限られています。
その場で聞けなかったことや、提案内容で気になった点を、ここで確認します。

現場メモ

私の場合、プレゼンで取引先データの連携が手動に見えた点が気になり協議しました。
話を聞くと「手動」の内容だったため、「自動化」を前提とした認識合わせを行いました。

2-8. 契約

協議で認識をそろえたら、契約します。

仕様書に書いた条件（保証・体制など）を、契約書に落とし込みます。

3. 私の会社でのベンダーの選定方法

ベンダーの選定方法

ここからは、3社の候補から1社を選ぶまでのプロセスを紹介します。

3-1. システム選定の判断材料は情シスが作る

ベンダーを正式に決めるのは役員ですが、その判断材料を作るのは情シスです。
役員は実際にシステムを利用しないため、選定の良し悪しが分からないからです。
そのため「情シスはどう思うか？」と必ず役員に聞かれます。

私の会社の場合、各ベンダーの提案書が揃った段階で、情シスが各社に点数をつけます。
その点数を役員に持っていき、

  • どの会社が良いと考えるか
  • その理由

をあわせて役員に説明します。

最終的に決めるのは役員ですが、システム選定には情シスが大きく関与することになります。

3-2. 採点の配点（価格3割・機能2割・総合評価5割）

採点の配点は、公募の前に決めました。
内訳は以下のとおりです。

項目割合内容
価格点3割提案金額（見積額）を評価
機能点2割機能要件への対応可否（◎、□、△、×）を点数化
総合点5割実績・セキュリティ対策・サポート体制・プレゼンなどの総合評価

価格だけで決めると、安いだけで使いにくいシステムを選びかねません。
使い勝手やサポートを重視するため、総合点に最も重い配点を置きました。

3-3. 最終候補3社は「価格」も「方向性」も違った

プロポーザルでは最終的に3社が残りました。
A社・B社・C社として、各社の特徴は以下のとおりでした。

A社B社C社
立ち位置既存・大手中堅（クラウド型）中堅（クラウド型）
価格最も高いA社より1,000万円／年ほど安い中間
強み安心感・既存資産の継続API連携・モダンなUI・研修も充実大きな欠点がない
弱み改修費が跳ね上がる実績はあるが当社では未知数B社と特徴が重なり、決め手に欠ける

A社は今まで使ってきたベンダーで、安心感がありました。
ただ、電子決裁機能をパッケージで持っておらず、個別開発で費用が膨らみました。

B社はクラウド型で、他機能との連携や画面の使いやすさが際立っていました。
C社も悪くありませんが、B社を上回る点は見つかりませんでした。

3-4. 最終的にB社を選んだ理由

最終的に、私はB社を推しました。
理由は5つです。

  • 年1,000万円安い
  • 他システムとの連携が標準で用意されている
  • 電子決裁機能が標準でついている
  • クラウド型であり制度改正などに伴う改修費が安い
  • 画面がモダンで、社員が使いやすい

組織内部でも、意見は割れました。
A社を推す側からは、ベンダーを変える負担の大きさや、社員の不満・リスクを心配する声が上がりました。

それでも私は、B社で行かせてほしいと推しました。
最大の理由は年1,000万円の差は大きく、その費用があれば他事業に回せるからです。
「開発の責任は自分が持つ」旨を伝え、B社で行くことを説得しました。

現場メモ

本来、選定の場で価格を理由に推すのは筋違いです。
価格点はすでに配点ずみで、議論すべきは総合点・機能点だけだからです。
ただ、機能点はともかく総合点は提案書だけでは見極めきれません。
最後は情シスがどちらかを推すしかありませんでした。
私は経営の視点で「A社はオーバースペック」と判断し、B社に踏み切りました。

4. システム調達で工夫したこと

システム調達で工夫したこと

ここからは、契約後に揉めずに済むよう、調達フェーズで意識した工夫を紹介します。

4-1. 機能要件はプロジェクトメンバーと共同で作成

機能要件は情シスだけで作成せず、業務に精通したプロジェクトメンバーと協力して作成しました。

  • 契約：契約担当者
  • 経理：経理担当者
  • 会計：会計担当者

作成は情シスがたたき台を作り、プロジェクトメンバーにチェック・肉付けしてもらう形にしました。
いきなり丸投げすると、現場は作成が困難だからです。

現場メモ

機能要件の作成で他社が入りやすいよう、「いらない機能・要件はなるべく落として」と伝えました。
実際はそれほど落ちませんでしたが、競争を意識する効果はありました。

4-2. 機能要件は対応可否を4段階で申告してもらった

（再掲：2-2「機能要件」の表）

大項目中項目要件内容重要度対応区分備考
予算管理予算登録部門別・科目別に予算を登録できること高◎
予算管理予算流用流用元・流用先を指定して予算流用ができること中□運用での代替を備考に記載
支払管理支払伝票振込データを所定フォーマットで出力できること高◎
契約管理契約台帳契約金額・期間・相手方を一覧で照会できること高△カスタマイズ費用は提案に含む
共通帳票出力帳票レイアウトを利用者側で軽微に変更できること中×対応不可

機能要件は、対応の可否を4段階で申告してもらいました。

  • ◎：標準機能で対応できる
  • □：運用の工夫で代替できる
  • △：カスタマイズが必要
  • ×：対応できない

あわせて、項目ごとに重要度（高・中）と備考も必須にし、機能の重要度に傾斜をつけて評価できる仕組みにしました。

4-3. 選定手続きは徹底的に公平にしてベンダーが参加しやすくした

選定の不公平をなくすために、手続きは誰が見ても公平な形に整えました。

  • 評価基準（採点ルール）は公募の前に開示する
  • 社名は匿名化して採点する
  • 質問は所定の様式に一本化し、電話は受けない
  • 回答は全社へ一斉に共有する
  • プレゼンの順番は、その場の抽選で決める

これらの工夫により既存ベンダーだけが有利にならないように気を付けました。

現場メモ

公平な手続きにこだわった理由は、なるべく多くのベンダーに参加してほしかったからです。
多くのベンダーが集まれば、価格競争が起きて、結果的に良い条件を引き出せます。

まとめ

まとめ

この記事では、私がシステム調達でたどった流れと工夫を紹介しました。

調達は選定基準が難しく、価格や実績だけでは決めきれません。
私の場合も組織内の意見が割れるなかで、将来性を重視してB社を推し、決めました。

ただし、この選択がこのあとの「開発フェーズ」「検証フェーズ」で、私を苦しめることになります。
カスタマイズは想定以上に膨らみ、スケジュールも度々遅れることになるからです。
このあたりは、次の「開発編」の記事で解説する予定です。