LASSIC Media らしくメディア
名刺管理システムの開発を外注する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発を受託
この記事のポイント
- 名刺は組織的にデータベース化し検索できる状態にすると、個人情報保護法上の個人情報データベース等に該当し得ると個人情報保護委員会のQ&Aで示されています。
- 名刺管理システムはOCRによるデータ化だけでなく、組織内共有・名寄せ・人脈可視化・SFA/CRM連携までを一つの仕組みとして扱う点が個人向けアプリとの違いです。
- 既製の法人向けサービスとスクラッチ開発では、導入スピードと既存システムとの連携範囲の両立が判断の分かれ目になります。
目次
名刺管理システムとは——撮影・データ化・共有を一元化する仕組み
名刺管理システムとは、紙の名刺をスキャンやカメラで撮影しOCR(Optical Character Recognition。画像内の文字を認識してテキスト化する技術)でデータ化したうえで、氏名・会社名・部署・連絡先といった項目を組織内で共有し、営業活動や人脈の把握に活用する仕組みを指します。個人が使う名刺アプリと異なり、法人向けの名刺管理システムは、部門をまたいだ共有範囲の設定やアクセス権限の管理、利用状況の記録が前提になっている点が特徴です。
名刺交換そのものは日常的な営業活動の一部ですが、交換した名刺を個人のデスクや名刺入れに留めている状態では、組織としての資産にはなりません。名刺管理システムを導入する狙いは、個々の担当者が持つ人脈情報を組織で参照できる形にし、異動や退職があっても接点の履歴を引き継げるようにする点にあります。
名刺は個人情報——取得・共有・活用で押さえるべきポイント
名刺に記載された氏名や連絡先は個人情報保護法上の個人情報にあたりますが、規制の掛かり方は管理の仕方によって変わります。個人情報保護委員会のQ&Aでは、メールソフトのアドレス帳や一定の規則で整理された名刺について、従業者の私的な使用のみに用いられているのであれば企業の個人情報データベース等に該当しないものの、企業における業務の用に供するために使用しているのであれば該当し得ると説明されています*1。
つまり、名刺管理システムを使って部門横断で検索・共有できる状態にした時点で、個人情報データベース等としての取扱いが求められる可能性が高まります。名刺交換によって取得した連絡先に自社の広告宣伝のための冊子や電子メールを送る場合についても、個人情報保護委員会のQ&Aは、名刺交換の相手が個人情報取扱事業者であることを明らかにしていれば、そうした案内が届くことについて一定の予測可能性があると整理しています*2。ただし、この整理は利用目的の通知・公表に関する考え方を示したものであり、電子メールでの送信には別途、特定電子メールの送信の適正化等に関する法律などの遵守も必要になります*2。
個人情報保護委員会のガイドライン(通則編)では、個人データの漏えい・滅失・毀損を防ぐための安全管理措置として、組織的・人的・物理的・技術的の4分類にわたる措置を講じることが求められています*3。名刺管理システムの選定にあたっては、アクセス権限の設計、閲覧・出力履歴の記録、退職者データの取扱い、保存期間の設定といった実務が、この安全管理措置に対応する項目として問われます。
名刺管理システムの主要機能——データ化から人脈可視化・SFA/CRM連携まで
名刺管理システムに求められる機能は、単純なデータ化にとどまりません。開発や既製サービスの選定を検討する際は、次の機能がどこまで自社の運用に合っているかを確認する作業になります。
OCRによるデータ化と人による補正
撮影した名刺をOCRで読み取り、氏名・会社名・部署・役職・連絡先といった項目に自動で振り分けます。手書きの追記や特殊なレイアウトの名刺では読み取りの誤りが残りやすいため、OCRの出力を人の目で確認して補正する運用と組み合わせるシステムが一般的です。
組織内共有と名寄せ
複数の担当者が同じ相手と名刺交換していた場合、それぞれの記録を一人の人物として統合する名寄せの機能が欠かせません。名寄せの精度が低いと、同じ相手に別の担当者から重複してアプローチしてしまう事態につながります。
人脈の可視化
誰が、いつ、どの企業のどの部署の担当者と名刺交換したかを組織図のような形で見える化する機能です。新規の商談先に自社の別部門の担当者がすでに接点を持っていないかを確認する用途で使われます。
企業情報のエンリッチメントとSFA/CRM・MA連携
名刺から読み取った会社名は表記ゆれが生じやすいため、外部の企業情報データと突き合わせて補完するエンリッチメントの仕組みが使われます。国税庁の法人番号公表サイトでは、法人番号や名称、所在地といった基本3情報を検索できるほか、REST方式のWeb-APIを通じて法人番号を指定した検索や法人名からの検索ができるようになっています*4。こうした公的なデータやその他の企業データベースと連携し、名刺の情報をSFA(Sales Force Automation)・CRM(Customer Relationship Management)・MA(Marketing Automation)へ引き渡す設計は、名刺管理システムの機能の一部として組み込まれます。SFA/CRM側の詳しい連携開発の進め方は、別記事で個別に扱っています。
アクセス権限の管理
誰がどの範囲の名刺情報を閲覧・編集・出力できるかを役職や部門ごとに設定する機能です。前章で触れた安全管理措置のうち、技術的安全管理措置に対応する部分にあたります。
OCRの精度をどう担保するか——人力補正と運用体制の実務
OCRは撮影した画像から文字を認識する技術のため、名刺のデザインや紙質、手書きの書き込みによって読み取りの誤りが生じます。特に細かい文字が密集したレイアウトや、ロゴと重なった社名などは誤認識が起きやすい部分です。
この課題に対応するため、多くの名刺管理サービスではOCRの一次読み取りに続けて、オペレーターが目視で内容を確認し修正する工程を組み込んでいます。読み取り結果をそのままデータベースに反映するのではなく、人の確認を経てから登録する運用にすることで、誤ったデータが組織内で広がる事態を防ぎやすくなります。
外注や既製サービスの選定にあたっては、OCRの技術そのものよりも、この補正工程がどのような体制で回っているかを確認する視点が実務的です。補正にかかる時間(名刺を撮影してからデータとして反映されるまでの日数)や、誤りがあった場合の再確認の仕組みは、サービスや開発内容によって差が出やすい部分です。あわせて、名寄せの精度を保つための重複チェックのロジックも、運用開始後の使い勝手を左右します。
既製の法人向けサービスとスクラッチ開発——選び方の分かれ目
名刺管理システムを導入する方法は、既製の法人向けサービスを契約する方法と、自社の要件に合わせてスクラッチ(またはSaaSをベースにしたカスタム)で開発する方法に大別できます。両者の違いを整理すると次の通りです。
| 項目 | 既製の法人向けサービス | スクラッチ・カスタム開発 |
|---|---|---|
| 導入までの期間 | 契約後すぐに使い始めやすい | 要件定義・設計・開発の工程が必要 |
| OCR運用体制 | 提供元がすでに補正体制を持つ場合が多い | 自社または委託先で体制を新たに整える |
| 既存システムとの連携 | 用意された連携メニューの範囲に依存 | 自社のSFA/CRM・基幹システムに合わせて設計できる |
| 人脈可視化・権限設計の自由度 | サービスの機能・設定項目の範囲内 | 組織構造や業務フローに合わせて設計できる |
| 費用の構造 | 利用人数・枚数に応じた月額課金が中心 | 初期の開発費と運用保守費に分かれる |
OCRの補正体制やSFA/CRMとの標準連携がすでに整っている既製サービスは、早期の立ち上げを優先する場合に向いています。一方で、既存の基幹システムやSFA/CRMと深く連携させたい場合や、自社独自の人脈可視化・権限設計を組み込みたい場合は、スクラッチ開発やSaaSのカスタマイズを含めた開発の検討対象になります。
開発を外注する進め方——要件定義から運用開始まで
名刺管理システムの開発を外注する場合、進め方はおおむね次の流れになります。
まず要件定義の段階では、利用する部門の範囲、名刺情報を共有する範囲、連携させたいSFA/CRM・MAといった既存システムを洗い出します。次にOCRの読み取り精度を実際の名刺サンプルで検証するPoC(Proof of Concept。本格導入前の実証検証)を行い、想定する業務量に見合う補正体制が組めるかを確認します。設計・開発の工程では、名寄せのロジックやアクセス権限の設計、既存システムとのAPI連携部分の実装を進めます。
既存の名刺データや名刺入れに眠っている紙の名刺をまとめてデータ化する移行作業も、初期導入では発生しやすい工程です。運用開始後は、利用部門への操作教育や、データ品質を保つための重複チェック・棚卸しといった保守業務が続きます。
外注先を選定する際は、個人情報保護法に基づく安全管理措置への対応体制、SFA/CRM・MAとのAPI連携の実装実績、既存データの移行対応の可否を確認する視点が実務的です。自社の組織規模や連携したいシステムの構成によって必要な工数は変わってくるため、要件定義の段階から相談できる委託先を選ぶことが結果的に手戻りを抑えることにつながります。
まとめ：名刺管理システム外注で押さえる3つの判断軸
本稿では名刺管理システムの仕組みと外注の進め方を整理しました。要点は3つに集約できます。第一に、名刺を組織的にデータベース化し検索できる状態にすると、個人情報保護法上の個人情報データベース等に該当し得るため、安全管理措置への対応が前提になります*1*3。第二に、名刺管理システムはOCRによるデータ化に加え、組織内共有・名寄せ・人脈可視化・SFA/CRM連携までを含む仕組みであり、機能ごとに求める水準を洗い出す作業が欠かせません。第三に、既製の法人向けサービスとスクラッチ開発は、導入スピードと既存システムとの連携の自由度のどちらを優先するかで選び方が変わります。
よくある質問
名刺管理システムでは、社内の名刺をすべてデータ化する必要がありますか。
全社一斉にデータ化しなければならない決まりはありません。営業部門など共有の必要性が高い範囲から段階的に運用を広げ、効果を見ながら対象を拡大する進め方が実務では多く採られています。
名刺情報を組織で共有する際、個人情報保護法上の注意点はありますか。
名刺を組織的にデータベース化し検索できる状態にすると、個人情報保護委員会のQ&Aでは企業の個人情報データベース等に該当し得ると整理されています*1。該当する場合は、組織的・人的・物理的・技術的な安全管理措置への対応が求められます*3。
OCRによるデータ化の精度はどの程度まで高められますか。
OCR単体では手書きの追記や特殊なレイアウトで誤認識が生じる場合があります。そのため多くのサービスでは、OCRの読み取り結果を人が目視で確認・補正する工程を組み合わせています。精度を左右するのは技術そのものというより、補正にあたる運用体制です。
既製の名刺管理サービスとスクラッチ開発は、どちらを選べばよいですか。
早期の立ち上げを優先するのであれば、OCRの補正体制や標準的なSFA/CRM連携がすでに整った既製サービスが選択肢になります。既存の基幹システムと深く連携させたい場合や、自社独自の人脈可視化・権限設計を組み込みたい場合は、スクラッチ開発やカスタマイズを含めた検討対象になります。
開発を外注する際、委託先に確認すべき点は何ですか。
個人情報保護法に基づく安全管理措置への対応体制、SFA/CRM・MAとのAPI連携の実装実績、既存の名刺データの移行対応の可否をまず確認します。あわせて、OCRの補正工程をどのような体制で運用しているかを、契約前に具体的に確認しておくと導入後の認識違いを抑えやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：個人情報保護委員会「メールソフトのアドレス帳や一定の規則で整理された名刺について、従業者本人しか使用できない状態であれば、企業の個人情報データベース等には該当しないと考えてよいですか。」（FAQ Q1-37）（https://www.ppc.go.jp/all_faq_index/faq1-q1-37/）
- *2 出典：個人情報保護委員会「名刺交換により取得した連絡先に対して、自社の広告宣伝のための冊子や電子メールを送ることはできますか。」（FAQ Q4-16）（https://www.ppc.go.jp/all_faq_index/faq1-q4-16/）
- *3 出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/）
- *4 出典：国税庁「法人番号システムWeb-API」（国税庁法人番号公表サイト）（https://www.houjin-bangou.nta.go.jp/webapi/）
