名刺管理システムの発注は、現状の課題を整理し、要件を定め、移行・連携・安全性までRFPに記す順で進めると、現場に合う提案につながります。
RFP・要件定義書・提案依頼書の作り方は、発注側が押さえる論点ごとに整理できます。全体像は名刺管理システムの完全ガイドもご覧ください。
▼全体ガイドの記事
・名刺管理システムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
SaaS導入かスクラッチ開発かの要件整理
RFPを書く前に、SaaS導入かスクラッチ開発かを決めておく必要があります。判断をベンダーに任せると、提案の前提がそろわず、比べられなくなります。
SaaSの標準機能で足りるか、独自連携や業務ルールが必要かを見極めることが、要件定義の出発点になります。
SaaSとスクラッチを分ける判断基準
判断では、自社の業務がどれだけ標準的か、既存システムとの連携をどこまで作り込むかを見ます。要件定義の段階では、標準機能で済む範囲と独自開発が必要な範囲を分けておきます。
- SaaS：名刺のデータ化、検索、共有で足りる場合に選びやすい方式です。
- スクラッチ・カスタム開発：独自顧客マスタや密な連携、業界特有の分類、特殊な権限が必要な場合の選択肢です。
SaaSはユーザー単位の月額課金が中心で、人数が多く利用期間が長いほど累計費用が膨らみます。一方、受託開発の費用は規模によって変わり、小規模であれば300万〜800万円程度が一つの目安です。
多人数で長く使う場合は、スクラッチが有利になることもあります。そのため、RFPにユーザー数と利用年数を記し、初期費用と運用費を含む総保有コストの提案を求めます。
費用を比べられるよう、判断の基準も要件として言葉にしておきます。
RFP冒頭の現状業務と課題の記載
RFPには、現在の名刺管理の方法と困りごと（AsIs）、導入後に実現したい状態（ToBe）を具体的に書きます。課題が曖昧だと、機能の一覧のような提案になりがちです。
- 現状の例：紙を個人で保管する、Excelに一部だけ転記する、退職で人脈が失われる。
- 導入後の目的：属人化の解消、展示会名刺のMA連携活用、退職時の引き継ぎ標準化。
目的が明確であれば、ベンダーも優先する機能を判断しやすくなります。要件定義では、機能を並べるだけでなく、現状の課題からあるべき姿を逆算します。
riplaは、現状ヒアリングとToBe設計を重視し、課題を起点に要件を整理する進め方を支援しています。
業務要件・機能要件の整理
方針が固まったら、具体的な機能要件を整理していきます。課題解決に直結する機能から要件にし、必須要件（MUST）と、あると望ましい要件（WANT）に分けます。
すべてを必須にすると見積もりが膨らみ、優先順位も伝わりにくくなります。そのため、優先度を明確にしておくと、ベンダーは提案を組み立てやすくなります。
データ化精度と入力負荷を抑える項目設計
紙の名刺を正確にデータ化するには、OCRの認識精度、AI補正やオペレーター入力の有無、項目ごとの精度をRFPに明記しておきます。
現場の入力負荷を抑えるには、項目の設計も欠かせません。必須入力を最小限にし、後から段階的に情報を足せる設計を要件に盛り込みます。
- 取り込み：撮影だけで完了し、入力負荷を抑えられること。
- 補正：不正確な箇所を自動補完できること。
- 精度確認：OCR後の修正率上限、AI補正対象、目視確認の範囲と納期を定めること。
入力負荷の高さは、名刺管理が定着しない最大の原因です。項目が多すぎると、現場は入力をやめ、データベースが形骸化します。
CRM/SFAの導入でも、入力負荷の増大は失敗要因として繰り返し指摘されています。名刺管理でも、入力を楽にする要件が運用の成否を左右します。
OCRの精度については、どの程度の誤認識まで許容するかを明確にします。100%の精度は現実的ではないため、この線引きを先に決めておきます。
発注側は、AI補正やオペレーターの目視確認を組み合わせる方法を、ベンダーに提案してもらいます。
日本語の名刺は縦書きと横書きが混在し、デザインも多様なため、認識の難易度が高くなります。その点を踏まえて、要件を定めます。
検索・共有・権限管理の要件定義
検索・抽出では、どんな条件で絞り込むかを具体化します。人脈を誰とどこまで共有するか、閲覧と編集の権限をどう分けるかも、要件として決めておきます。
- 検索・抽出：業種・役職・地域での複合検索、タグやメモでの分類。
- 出力：検索結果のCSV出力や配信リスト化。
- 共有・権限：全社か部署内かの共有範囲、閲覧・編集の区分。
「自分の人脈を勝手に使われたくない」という気持ちに配慮し、段階的な公開設定を設けておくと、導入後の反発を抑えられます。
役割ごとの閲覧・編集範囲を表にしてRFPに添えると、ベンダーとの認識のずれを防げます。検索・共有・権限は組織利用の核になるため、丁寧に詰めるほど後の手戻りが減ります。また、権限管理の要件は、現場の合意形成にも関わります。
データ移行・名寄せ要件の整理
既存データの移行と名寄せは、要件定義で見落とされがちです。そのため、RFPに独立した項目として盛り込みます。過去の名刺やExcelの連絡先を後回しにすると、導入後にデータが乱れて使えなくなるおそれがあります。
表記揺れ・重複を整える名寄せ要件
名寄せ（クレンジング）では、会社名などの表記揺れと、社員が持つ同一人物の名刺の重複を、どう統一するかを定めます。会社名や部署名の表記ルールも決めておきます。
- 機械処理：ルールで照合できるデータを自動で統合する。
- 人手確認：判定が難しいデータを目視で確認し、統合後も検証する。
「株式会社A」「（株）A」「A社」の表記揺れは、機械的に処理できる場合があります。一方、「山田一郎」と「ヤマダイチロウ」のような読み方の違いは、人の判断が必要です。
名寄せが不十分なままだと、顧客マスタが汚れた状態でSFA/CRMに連携され、企業との接点数を正しく数えられなくなります。
RFPには、移行するデータの件数、現在の管理形式（紙・Excel・他システム）、名寄せの完了基準を記します。
RFPでは、どこまで機械処理に任せるかを定めたうえで、統合後の検証方法もベンダーに提案してもらいます。設問を具体的にすると、提案の質を見極められます。
名寄せの精度は、後の検索や集計の正確さを左右します。丁寧に整理するかどうかで、データを資産として活かせるかが分かれます。
眠れる名刺の収集・流し込み手順の要件
移行では、社員が個人で抱える「眠れる名刺」をどう集めるかも論点になります。手帳、ローカルPC、引き出しのファイルに分かれた連絡先を、全社で取り込みます。
- スキャンキャンペーンの実施方法と、提出を促す仕組み。
- 名刺の取り込みを誰が分担するか。
- 収集、データ化、名寄せ、システムへの流し込みの流れ。
大量の名刺を短期間でデータ化するには、スキャナでの一括読み取りやオペレーター入力が現実的です。収集の手順をRFPに含めると、ベンダーは初期データ投入の支援体制も提案できます。
眠れる名刺を集められるかどうかで、初期データ量が変わります。移行を機能の一部ではなく、プロジェクトとして捉え、工程を要件に明記しておくと、円滑な立ち上げにつながります。
連携要件・非機能要件の定義
名刺管理を営業のデータ基盤として使うには、連携要件と非機能要件の定義が欠かせません。抜けると後で問題になりやすいため、RFPの後半で連携先、性能、セキュリティ、保守を整理します。
SFA/CRM・MA・会計など連携要件
名刺データを既存のSFA/CRM、MA、会計システムなどとどうつなぐかを定めます。たとえば、登録・更新をCRMの顧客マスタに反映する、展示会名刺をMAの配信対象に流す、といった方向と頻度を示します。
- 対象：連携するシステムの名称とバージョン。
- 方式：APIまたはCSV。
- データ：連携する項目と連携の方向・頻度。
連携が自動化されると、二重入力がなくなり、顧客マスタを最新に保ちやすくなります。SFAとMAの連携で受注率が約1.75倍に向上したという一次データもあり、連携の投資効果は大きいとされています。
既存システムが独自仕様だと、標準のSaaSでは対応しきれず、スクラッチやカスタム開発が必要になることもあります。連携要件を定めておけば、名刺管理を孤立させずに済みます。
riplaはフルスクラッチ受託の立場から、基幹システムや独自マスタとの密な連携設計を支援します。
セキュリティ・性能・保守の非機能要件
名刺には個人情報が含まれるため、非機能要件ではセキュリティを最優先で扱います。通信の暗号化とアクセス権限を中心に、操作ログやデータ出力の制限も要件として定めます。加えて、想定ユーザー数や名刺件数に対する検索速度も定めます。
- 性能：想定ユーザー数・名刺件数と検索の応答速度。
- 障害対応：復旧とデータバックアップの方針。
- 保守：導入後の保守・サポート体制。
非機能要件は、RFPで提案を比べるうえで大事な観点になります。要件が曖昧だと、運用後に動作の遅さやサポートの弱さへの不満につながります。
自社の個人情報保護ルールや可用性の要求水準も示しておくと、ベンダーの提案を比べられます。
機能・移行・連携・非機能の四領域を漏れなく整理できるかが、発注の成否を分けます。セキュリティ水準や保守体制はベンダーによって異なるため、提案を見極める観点になります。
セキュリティ・個人情報保護の非機能要件
名刺データには氏名・所属・役職・連絡先が含まれるため、セキュリティと個人情報保護は、RFPで特別に整理します。水準を曖昧にしたまま導入すると、情報漏えいや法令違反のリスクを抱えたまま使い始めることになりかねません。
安心して長く使えるシステムにするには、要件定義の段階で安全性を明確にしておく必要があります。
暗号化・アクセス制御・操作ログの要件定義
通信経路と保存データについて、暗号化の水準を明記します。TLS1.2以上の通信暗号化やストレージ暗号化などの仕様を示すと、ベンダーは対応コストを見積もりやすくなります。
- アクセス制御：役割ごとの閲覧・編集・出力の権限。
- 出力制限：名刺CSVの出力権限と申請フロー。
- 操作ログ：閲覧・ダウンロード・削除の記録と保存期間。
RFPに役割と権限の対応表を添えると、認識のずれを防げます。CSVの一括出力は持ち出しリスクに直結するため、権限と申請手順を特に明確にします。
操作ログは漏えい後の追跡に使えますが、何より不正操作の抑止に役立ちます。記録が残るという認識も、不正を減らします。
ExcelやローカルPCでの管理に比べると、名刺管理システムへの移行はセキュリティを底上げします。ただし、その効果は要件を正しく定義した場合に限られます。
個人情報保護法・コンプライアンス対応の要件
氏名、メールアドレス、電話番号は、個人情報保護法の対象です。そのため、取得目的の特定、利用目的の通知、安全管理措置などの義務を満たす仕組みを、要件に含めます。
- データの扱い：退職者が持ち帰った名刺や担当替え時の移譲ルール。
- 認証・規制：必要に応じたISMS認証要件や業界規制への準拠。
- 社内方針：自社のセキュリティ規程と個人情報保護方針。
大量の顧客情報を扱う企業では、情報セキュリティマネジメントシステム（ISMS）の認証要件に沿った設計を求めるケースもあります。また、金融・医療・官公庁向けでは、一般の業種とは異なる水準の規制が適用されることもあります。
自社の業界規制や社内ポリシーはRFPに記し、準拠を確認する設問を設けます。便利な機能があっても、安全性が不十分であれば、安心して使い続けられません。
セキュリティの非機能要件は、機能要件を安心して使い続けるための前提です。個人情報保護と同じくらい重く見ることが、長期運用の条件になります。
まとめ
RFP・要件定義は五つの領域で構成し、まず方式と現状課題を整理します。残りは、機能、移行・名寄せ、連携・非機能、セキュリティ・個人情報保護の順に定めていきます。
機能の領域では、データ化精度と入力負荷、検索・共有、権限を扱います。移行の領域には、表記揺れの統一と眠れる名刺の収集も含めます。
連携・非機能の領域には、SFA/CRM連携、セキュリティ、性能、保守を含めます。セキュリティ・個人情報保護の領域には、暗号化、アクセス制御、操作ログ、法令対応を含めます。
入力負荷を抑える設計は形骸化を防ぎ、名寄せの精度は活用の質を左右します。連携は受注率の向上につながり、セキュリティは長期運用の安全を支えます。
要件定義では、機能を並べるだけでなく、現状の課題からあるべき姿を逆算します。そのうえで、優先順位を付けて言葉にしておくことが大切です。
必須要件と望ましい要件を分け、移行・連携・セキュリティも漏れなく整理すれば、ベンダーから提案を得やすくなります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、現状ヒアリングとToBe設計から移行・連携・セキュリティを含む実装、導入後の定着まで支援します。全体像は完全ガイドをご覧ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。