名刺管理システムのRFP/要件定義書/提案依頼書について

名刺管理システムの開発や導入を発注しようとするとき、最初の関門になるのが要件定義とRFP（提案依頼書）の作成です。「何を作りたいか」を自社の言葉で整理し、ベンダーに正確に伝えられなければ、提案の比較もできず、完成したシステムが現場に合わないという失敗に直結します。名刺管理は一見シンプルに見えますが、データ化精度の要件、既存システムとの連携要件、名寄せ・移行の要件など、詰めるべき論点は意外と多いのが実情です。

本記事は、名刺管理システムのRFP・要件定義書・提案依頼書の作り方を、発注側が押さえるべき論点に沿って体系的に解説する「要件定義特化」の記事です。SaaS導入かスクラッチ開発かの判断、業務要件と機能要件の整理、データ移行・名寄せ要件、連携・非機能要件まで、RFPに盛り込むべき項目を具体的に示します。なお、名刺管理システムの全体像をまだ把握していない方は、まず名刺管理システムの完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・名刺管理システムの完全ガイド

SaaS導入かスクラッチ開発かの要件整理

RFPを書き始める前に決めるべき最初の分岐が、既製のSaaS型名刺管理サービスを導入するのか、自社業務に合わせてスクラッチ開発するのか、という方針です。この判断を曖昧にしたままベンダーに丸投げすると、提案の土俵がそろわず比較できません。まずは自社の要件がSaaSの標準機能で満たせるのか、独自の連携や業務ルールが必要なのかを見極めることが、要件定義の出発点になります。

判断の軸は、「自社業務がどれだけ標準的か」と「既存システムとの連携をどこまで作り込むか」です。名刺のデータ化と検索・共有だけで足りるなら、SaaSが手早く安価です。一方、独自の顧客マスタや基幹システムとの密な連携、業界特有の顧客分類、特殊な権限ルールなどが必要なら、SaaSの標準機能では収まらず、スクラッチやカスタム開発が選択肢になります。要件定義では、この「標準で済む範囲」と「作り込みが必要な範囲」を切り分けて整理します。

コストの観点も重要です。SaaSはユーザー単位の月額課金が中心で、利用人数が多く長期で使うほど累計コストが膨らみます。受託でのシステム開発費用は規模により小規模で300万〜800万円程度が一つの目安となり、多人数・長期利用ではスクラッチが有利になることもあります。RFPには、想定ユーザー数と利用年数を明記し、ベンダーに総保有コストの観点での提案を求めるとよいでしょう。初期費用だけでなくランニングを含めた比較ができるよう、判断軸を要件として言語化しておくことが大切です。

RFPの冒頭には、必ず「現状どう名刺を管理しているか」と「何に困っているか」を具体的に書きます。個人が紙で抱えている、Excelに一部だけ転記している、退職で人脈が失われている、といった現状（AsIs）を率直に記すことで、ベンダーは課題に即した提案ができます。逆に課題が曖昧だと、機能カタログの羅列のような提案しか返ってきません。

あわせて、「導入で実現したい状態（ToBe）」も言語化します。属人化を解消したいのか、展示会名刺をMA連携で活用したいのか、退職時の引き継ぎを標準化したいのか。目的が明確であれば、ベンダーは優先すべき機能を判断でき、提案の精度が上がります。要件定義は機能の列挙ではなく、現状の課題からあるべき姿を逆算する作業です。riplaはこの現状ヒアリングとToBe設計を重視しており、課題起点で要件を整理する進め方を一貫して支援しています。

業務要件・機能要件の整理

方針が固まったら、具体的な機能要件を整理します。ここで重要なのは、必須要件（MUST）とあると望ましい要件（WANT）を分けて記述することです。すべてを必須にすると見積りが膨らみ、優先順位も伝わりません。自社の課題解決に直結する機能から要件化していくのが定石です。

名刺管理の中核は、紙の名刺を正確にデータ化することです。RFPには、OCRの認識精度の水準、AI補正やオペレーター入力の有無、どの項目をどの精度でデータ化するかを要件として明記します。同時に重要なのが、現場の入力負荷を抑える項目設計です。入力項目が多すぎると現場が入力をやめ、データベースが形骸化します。必須入力は最小限にとどめ、後から段階的に情報を足せる設計を要件化しましょう。

入力負荷の高さは、名刺管理が定着しない最大の原因です。「撮影するだけで取り込みが完了する」「不正確な箇所は自動補完される」といった、現場が無理なく続けられる条件を要件に盛り込むことが、形骸化を防ぐ鍵になります。CRM/SFA導入の失敗要因として入力負荷の増大が繰り返し指摘されており、名刺管理でも同じ落とし穴があります。RFPの段階で「入力をいかに楽にするか」を明文化しておくことが、運用の成否を左右します。

OCR精度の要件を定める際は、「どのレベルの誤認識まで許容するか」という基準も明確にしましょう。100%の精度は現実的ではなく、AI補正やオペレーターによる目視確認との組み合わせで運用品質を担保するのが一般的です。RFPには「OCR後の修正率の上限」「AI補正の対象項目」「オペレーター確認の範囲と納期」を要件として明記し、ベンダーにその実現方法の提案を求めると、精度に関する認識のずれが防げます。日本語名刺は縦書き・横書き混在やデザインの多様性から、認識の難易度が高い点も念頭に置いた要件設定が必要です。

検索・抽出機能は、どんな条件で絞り込みたいかを具体的に要件化します。業種・役職・地域での複合検索、タグやメモでの分類、抽出結果のCSV出力や配信リスト化など、現場が日々行いたい操作を列挙しましょう。あわせて、人脈の共有範囲をどう制御するかも重要な要件です。全社共有か部署内共有か、閲覧と編集の権限をどう分けるかを明記します。

権限管理の要件は、現場の合意形成にも関わります。「自分の人脈を勝手に使われたくない」という心理に配慮し、段階的な公開設定ができることを要件に盛り込むと、導入後の反発を抑えられます。要件定義の段階で、誰が何を見られて何を編集できるかを役割ごとに表で整理しておくと、ベンダーとの認識のずれが防げます。検索・共有・権限の三点は、名刺管理を組織で使うための要件の核であり、丁寧に詰めるほど後の手戻りが減ります。

データ移行・名寄せ要件の整理

名刺管理システムの要件定義で見落とされがちなのが、既存データの移行と名寄せの要件です。新しいシステムの機能ばかりに目が行き、過去の名刺やExcelの連絡先をどう移すかが後回しになると、導入後に「データが汚くて使えない」という事態に陥ります。移行要件は、RFPに必ず独立した項目として盛り込むべきものです。

名寄せ（クレンジング）の要件では、「株式会社A」と「（株）A」「A社」のような表記揺れをどう統一するか、複数社員が持つ同一人物の名刺の重複をどう束ねるかを定義します。会社名・部署名の表記ルールを決め、機械的にマッチングできるものは自動で、判定が難しいものは人が確認する、という二段構えの手順を要件として書くとよいでしょう。名寄せの精度が、後の検索や集計の正確さを決めます。

名寄せを軽視すると、顧客マスタが汚れたままSFA/CRMに連携され、「この企業との接点が何件あるか」を正しく数えられなくなります。RFPには、移行対象のデータ件数、現状の管理形式（紙・Excel・他システム）、名寄せの完了基準を明記し、ベンダーに移行プロセスの提案を求めましょう。名寄せは地味な作業ですが、ここを丁寧にやるかどうかで、システムが資産になるかゴミになるかが分かれます。

名寄せの完了基準を決める際は、「自動マッチングで統一できる範囲」と「人が目視で確認が必要な範囲」を明確に分けることが重要です。会社名の表記揺れは機械的なルールで大半を処理できますが、人名の「山田一郎」と「ヤマダイチロウ」のような読み方の違いは、人が判断しなければ統合できません。RFPには、名寄せのアプローチ（機械処理の範囲・人手確認のルール・統合後の検証方法）を求める設問を入れると、ベンダーの提案の質が上がります。

移行要件のもう一つの論点が、社員個人が抱えている「眠れる名刺」をどう集めるかです。手帳やローカルPC、引き出しのファイルに分散した連絡先を全社で吸い上げる手順を、要件として設計します。スキャンキャンペーンの実施方法、提出を促す仕組み、取り込みの分担などを決めておくと、移行プロジェクトが滞りません。眠れる名刺の収集は、システムの初期データ量を左右する重要な工程です。

この収集手順をRFPに含めておくと、ベンダーは初期データ投入の支援体制まで提案に織り込めます。大量の名刺を短期間でデータ化するには、スキャナでの一括読み取りやオペレーター入力の活用が現実的です。移行は「機能」ではなく「プロジェクト」として捉え、収集・データ化・名寄せ・流し込みという一連の工程を要件として明文化することが、スムーズな立ち上げの条件になります。導入初日にデータが空では、現場は使い始めてくれません。

連携要件・非機能要件の定義

名刺管理システムを単独で終わらせず、営業のデータ基盤として活かすには、連携要件と非機能要件をしっかり定義する必要があります。これらは機能要件より見えにくいぶん、抜けると後で大きな問題になります。RFPの後半で、連携先・性能・セキュリティ・保守の観点を整理しましょう。

連携要件では、名刺データを既存のSFA/CRM、MA、会計システムなどとどうつなぐかを定義します。名刺の登録・更新をCRMの顧客マスタに自動反映する、展示会名刺をMAの配信対象に流す、といった連携の方向と頻度を明記しましょう。連携が自動化されれば二重入力がなくなり、顧客マスタが常に最新に保たれます。SFAとMAの連携で受注率が約1.75倍に向上した一次データもあり、連携の投資効果は大きいと言えます。

連携要件を書くときは、対象システムの名称・バージョン、連携方式（API・CSV）、連携するデータ項目を具体的に示します。自社の既存システムが独自仕様の場合は、標準SaaSの連携機能では対応しきれず、スクラッチやカスタム開発での作り込みが必要になることもあります。riplaはフルスクラッチ受託の立場から、既存基幹システムや独自マスタとの密な連携設計を支援しており、SaaSでは難しい連携要件にも対応します。連携の要件化は、名刺管理を孤立させないための重要な作業です。

非機能要件では、名刺という個人情報を扱う以上、セキュリティを最優先で定義します。通信の暗号化、アクセス権限の制御、操作ログの記録、データ出力の制限などを要件化しましょう。あわせて、想定ユーザー数や名刺件数に対する性能（検索のレスポンス速度）、障害時の復旧やデータバックアップの方針、導入後の保守・サポート体制も明記します。これらが曖昧だと、運用開始後に「遅い」「サポートが弱い」といった不満につながります。

非機能要件は、RFPで提案を比較する重要な軸でもあります。同じ機能でも、セキュリティ水準や保守体制はベンダーによって大きく異なります。自社が遵守すべき個人情報保護のルールや、可用性の要求水準を要件として示すことで、提案の質を見極められます。要件定義の総仕上げとして、機能・移行・連携・非機能の四領域を漏れなく整理することが、名刺管理システム発注の成否を分けるのです。

セキュリティ・個人情報保護の非機能要件

名刺データは氏名・所属・役職・連絡先という個人情報の塊であるため、セキュリティと個人情報保護の非機能要件は、RFPの中でも特別な位置づけで整理する必要があります。機能要件に比べて見えにくいぶん、後回しにされがちですが、ここを曖昧にしたまま開発・導入を進めると、情報漏えいや法令違反のリスクを抱えたシステムが完成してしまいます。要件定義の段階でセキュリティ水準を明確に言語化することが、安心して長期運用できる名刺管理システムの前提条件です。

セキュリティの非機能要件では、まず通信経路と保存データの暗号化水準を明記します。TLS1.2以上の通信暗号化、ストレージの暗号化といった技術仕様を要件として示すことで、ベンダーは対応コストを適切に見積もれます。次にアクセス制御として、誰がどのデータを閲覧・編集・出力できるかをロール（役割）ごとに定義し、RFPに役割×権限の対応表を付けると認識のずれが防げます。名刺のCSV一括出力は持ち出しリスクに直結するため、出力権限の制限と申請フローを要件化することが特に重要です。

操作ログ（監査ログ）の要件では、誰がいつどのデータを閲覧・ダウンロード・削除したかを記録し、一定期間保存することを明文化します。ログは情報漏えい発生後の追跡にも使えますが、何より抑止効果として機能します。「記録が残っている」という認識が、内部からの不正操作を減らします。ExcelやローカルPCで管理していた頃と比べ、名刺管理システムへの移行はこの点でもセキュリティの底上げになりますが、それはセキュリティ要件を正しく定義した場合に限られます。

名刺に含まれる氏名・メールアドレス・電話番号は個人情報保護法の対象であるため、取得目的の特定・利用目的の通知・安全管理措置の実施といった法令上の義務を満たす仕組みを要件として盛り込む必要があります。退職者が持ち帰った名刺データの扱いや、担当替えに伴う名刺データの移譲ルールなども、運用方針として要件化しておくと、導入後のトラブルを防げます。特に大量の顧客情報を扱う企業では、情報セキュリティマネジメントシステム（ISMS）の認証要件に沿った設計を求めるケースもあります。

業界によってはさらに厳格な規制が適用されることもあります。金融・医療・官公庁向けのシステムでは、セキュリティ要件の水準が一般の業種とは異なります。RFPにはこうした自社の業界規制や社内ポリシーを明記し、ベンダーにその準拠を問う設問を設けましょう。セキュリティ非機能要件は、機能要件の完成度を守る「器」の役割を果たします。どれだけ便利な機能を備えていても、器が脆ければ安心して使い続けられません。要件定義の段階で、機能要件と同等の重みをセキュリティ・個人情報保護に置くことが、長期運用に耐えるシステムを作る条件です。

まとめ

名刺管理システムのRFP・要件定義は、(1)SaaSかスクラッチかの方針と現状課題の整理、(2)データ化精度・入力負荷・検索共有・権限の機能要件、(3)表記揺れ統一と眠れる名刺収集を含む移行・名寄せ要件、(4)SFA/CRM連携とセキュリティ・性能・保守の非機能要件、(5)暗号化・アクセス制御・操作ログ・法令対応を含むセキュリティ・個人情報保護の非機能要件、という五つの領域で構成されます。入力負荷を抑える項目設計が形骸化を防ぎ、名寄せの精度が活用品質を決め、連携要件が受注率向上の土台になり、セキュリティ要件が長期運用の安全を担います。

要件定義で大切なのは、機能の列挙ではなく「現状の課題からあるべき姿を逆算し、優先順位をつけて言語化する」ことです。必須要件と望ましい要件を分け、移行・連携・セキュリティを漏らさず整理すれば、ベンダーから質の高い提案を引き出せます。riplaはフルスクラッチ受託と国内開発を組み合わせ、現状ヒアリングとToBe設計から、移行・連携・セキュリティを含む実装、導入後の定着までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。