システムが分からない現場からの切実な相談
「ITのことはさっぱり分からないのですが、会社から人事システムの導入を担当しろと言われてしまって……。とにかくRFP（提案依頼書）の書き方を教えてください！」
以前、ある企業の方から切迫した様子で相談を受けたことがあります。世の中の「システム導入マニュアル」のようなものを読み込み、立派なRFPを作らなければと意気込んでいらっしゃいました。
しかし、私は「まずはRFPのフォーマットを埋めることなんて考えなくていいですよ」とお話しし、本当に考えるべき「データ構造」と「機能」の話から始めました。
業務システムを新しく構築しようと決まった際、選択肢は「スクラッチ開発（完全オーダーメイド）」か「既存のパッケージ選定」の2つに分かれます。しかし、まずは自社の要求を満たすパッケージから探すのが鉄則です。
なぜなら、パッケージシステムは多数の企業で共通利用されることを前提とした仕組みだからです。一社専用で一から開発するスクラッチに比べ、すでに完成しているパッケージを採用する方が、開発費用も導入にかかる期間も圧倒的に抑えられます。コスト面で段違いのアドバンテージがある以上、まずはパッケージの選び方をマスターすることが先決です。
「機能要望」を集めた厚いRFPはゴミ箱へ捨てよ
システム選定を行う際、提案依頼書（RFP）を作成するのが一般的です。その際、世の中の解説書やコンサルタントは「現場から欲しい機能を徹底的に洗い出し、機能一覧表（Fit/Gap表）を作りましょう」とアドバイスします。
しかし、私はあえて言います。「機能」を中心にRFPを書いている時点で、そのプロジェクトは間違いなく失敗します。
システム選定において最も重要なのは「機能」ではなく「データ構造」です。RFPに書くべき本質とは、自社で管理したいデータとデータ同士のつながりを完璧に把握し、その構造がパッケージ側と一致しているかを確かめること（Fit/Gap）に他なりません。
自社のデータ構造と合致しないパッケージを選んでしまった場合、そのシステム導入は確実に失敗します。データ構造が合わないということは、自社のビジネスに必要なデータを正しく格納する「場所」が存在しないということです。
データを入れる場所がないのに無理やり別の場所に突っ込み、裏で複雑な処理をして呼び出すような運用を行えば、どこかで確実にデータが壊れます。拡張性も失われ、遠からずシステムは破綻するのです。
まずデータが入ること、料理する機能は二の次でいい
システムの本質はシンプルです。「まずデータが入る場所があること」。そして「入ったデータを料理（参照・集計・編集）する機能がどれだけ満たされているか」。 考える順番は、絶対にこの通りでなければなりません。
どれほど画面が見やすく、便利な機能が豊富に揃っていたとしても、自社が保持すべきデータを入れる箱（データ構造）がなければ、そのシステムは道具として一切役に立ちません。
逆に言えば、自社とパッケージのデータ構造さえ合致してデータが正しく納まるなら、機能面は最悪「二の次」で構わないのです。
どうしようもなく必要な機能が標準で足りない場合でも、データ構造さえ合っていれば、データベース（DB）へ直接アクセスしたり、APIを介してデータを引き出したりすることで、後から集計や参照の機能をカスタマイズ・補填することが技術的に可能だからです。
RFPで確認すべき優先順位は、徹底して「①データ構造の合致」「②標準機能がどれだけ要件を満たしているか」の順番でなければなりません。
機械的に抽出する「真に必要な機能」の出し方
では、データ構造を押さえた上で、最低限必要な「機能」はどのように抽出すればよいのでしょうか。現場に「どんな機能が欲しい？」と漠然とインタビューしても、収集がつかなくなります。機能の抽出は「機械的」に行うのが正解です。
既存システムがある場合は、それをベースにするのが最も手っ取り早い方法です。稼働している全ての画面を洗い出し、そこに存在する操作を抽出します。「新規作成できる」「編集できる」「一括ダウンロードできる」といった画面上の動作が、そのままRFPの機能要件になります。これに現場からの「こういう機能があったら良いな」という追加要望を添えれば完了です。
自社システムが無い場合は、業務で実際に使われている「紙の帳票」や「Excelシート」を観察してください。
帳票に記入欄があれば「新規作成機能」が必要です。紙の上での修正や追記は「編集機能」を意味します。Excel上で足し算や計算を行っていれば「集計機能」、データをCSV出力していれば「エクスポート機能」です。このように現行の業務アウトプットから逆算すれば、真に必要な機能は自ずと導き出されます。
本質を見抜くRFPが企業の投資価値を最大化する
費用や期間を抑えられるパッケージ選定は、中小企業にとって極めて強力な選択肢です。
しかし、その成功を握るRFP作成において、「見栄えの良い機能の多さ」に惑わされる必要はありません。世間の常識である「機能中心の選定」を捨て、自社ビジネスの根幹である「データ構造」の合致を最優先に評価する。これを私は、これまでの案件で徹底してきました。
データ構造という土台さえ正しく合致していれば、データを格納する場所が確保され、機能不足があってもAPI連携や外部集計でいくらでも補填が効きます。逆もまた然りで、データを入れる場所がないパッケージは、いくら機能が充実していても絶対に役に立ちません。
冒頭の人事システムの相談のように、難しいIT用語やRFPの形式にとらわれる必要はありません。「自社が管理すべきデータが入る場所があるか」を最優先にし、「機能はできるだけ満たされていれば良い」という強い軸を持ってRFPを作成する。それこそが、無駄な投資を防ぎ、現場で本当に使えるシステムを手に入れるための技術なのです。