令和7年度 春期 システムアーキテクト試験 午後Ⅰ 問2 営業支援システムの要件定義とデータ移行

問2 営業活動を支援するシステムに関する次の記述を読んで，設問に答えよ。

医療機関向けに医療機器の販売と導入支援サービスを提供するE社は，営業活動の拡大に追随するために，営業活動を支援する営業支援システム（以下，新システムという）を新規に構築することにした。

〔現行の業務とシステムの概要〕

E社では，表計算ソフトと共有のファイルサーバに配置した簡易データベースを組み合わせた簡易的なツール（以下，商談ツールという）で商談に関する情報（以下，商談情報という）を管理している。商談ツール作成以来約10年分の商談情報を蓄積しているが，主に利用するのは直近5年間の情報である。利用者の情報は人事システムから取得しているが，所属組織と役職は取得せず，全ての利用者に同一の権限を付与している。利用者は全ての商談情報を閲覧可能であり，機密性が高い情報は登録されていない。

商談に必須である顧客情報は顧客管理システムで管理している。商談ツールには，顧客管理システムから顧客情報を取り込む機能（以下，顧客情報取込機能という）があり，顧客情報取込機能をRPAによって毎日1回実行し，顧客情報を取り込んでいる。顧客情報取込機能は簡易データベースに大きな負荷を与えるので，他の処理との競合を避けるようにしている。処理時間は約30分掛かる。実行する端末やネットワークの状況，簡易データベースの負荷状況などによって，まれに顧客情報の取込みに失敗することがあり，失敗した場合には商談ツールの運用担当者（以下，運用担当者という）が手動で再実行する。再実行してもE社の業務時間内に完了するように，顧客情報取込機能の実行タイミングを調整している。

商談時に取り交わした名刺情報は外部の名刺管理SaaS（以下，名刺サービスという）を利用して管理しており，名刺サービスの利用権限を営業担当者に付与している。複数の営業担当者が同一の名刺情報を登録できるが，名刺サービスは名刺交換日を基に名刺情報の新旧を判断している。新しい名刺情報が登録されると，利用権限のある人に電子メール（以下，メールという）で周知し，共有する。名刺サービスは利用者が直接操作する画面のほかに，他システムから呼び出せるAPIを公開している。

E社の営業活動の主な流れは次のとおりである。

(1) 見込客の確認・新規登録・更新
既存顧客からの声掛け，協業先からの紹介などで新たな取引の可能性のある顧客（以下，見込客という）との商談の機会を得ると，営業担当者は商談ツールを利用し，見込客の会社情報，連絡先，過去の商談概要などを確認する。見込客が新規の場合はホームページなどから会社情報などを入手し，顧客情報を顧客管理システムに新規登録する。見込客が既存顧客で会社情報，連絡先などに更新がある場合には，顧客管理システムの顧客情報を更新する。

(2) 顧客訪問
営業担当者は見込客と訪問の日程を調整し，見込客を訪問して要望を確認する。見込客への訪問は複数回にわたることもあり，商材に詳しい商品担当者を同席させることもある。訪問内容を営業日報としてまとめ，上司にメールで報告する。

(3) 名刺情報の登録
営業担当者は顧客訪問時に入手した名刺をスキャンし，名刺交換日を指定し，名刺サービスに登録する。

(4) 商談概要の登録
顧客訪問を重ねて入手したE社に期待する商品やサービス内容，顧客の予算，プロジェクト期間などの商談概要を，営業担当者は登録済みの顧客情報にひも付けて商談ツールに登録し，商談状況を“商談登録”にする。

(5) 提案・見積りの作成
営業担当者は商品担当者とともに提案内容を検討し，見積りを作成する。作成した提案・見積りを基に，見積額，受注確度及びリスクレベルを商談ツールに追加登録し，商談状況を“提案書作成中”にする。営業担当者が所属する課の課長，副部長，部長など組織内で連なる役職者の中から，見積額とリスクレベルに応じて決裁規定に定められた承認者に承認を依頼する。承認はメールで取得する。本来の承認者が不在の場合は，承認者の上司が代行することがある。承認を得られず，提案を見送った場合には，商談状況を“辞退”にする。

(6) 商談結果登録
社内承認を取得した提案・見積りを営業担当者は見込客に提示し，商談状況を“提案書提出済”にする。受注に至らなかった場合には商談ツールの商談状況を“失注”にする。

内示をもらった場合には，商談状況を“契約交渉中”にする。契約審査部で提案内容と契約書を審査する。審査の結果，問題がなければ契約処理を行い，契約締結後に商談状況を“契約済”にする。審査の結果，問題があった場合には，契約に至らないことがある。その場合，商談状況を“取消”にする。

営業担当者は，他の営業担当者から商談内容の詳細についての問合せがあった際には，問い合わせてきた営業担当者の所属組織と役職によって商談内容の機密性を考慮して，メール及び口頭で共有する。

(7) 商談分析
営業担当者は，商談ツールが提供する商談状況を分析する帳票を利用し，商談を分析して営業活動に役立てている。例えば，商談の見積額によってどのくらいの割合で提案書提出に結び付けられたかを分析するために，終了した商談のうち①ある商談状況に該当する商談の割合を出力する帳票がある。

〔現行の業務とシステムにおける課題及び要望〕

E社情報システム部のF課長は，新システムの構築に向け，運用担当者，営業部及び契約審査部の代表からヒアリングを行い，次のような現行の業務とシステムにおける課題及び要望を収集した。

• 顧客訪問の内容を共有し，他の営業担当者の営業活動を参考にして営業活動の質を高めたい。
• 顧客管理システムの画面が複雑で使いづらい。
• 営業担当者と承認者とのメールでの承認証跡を基に契約審査部の審査担当者が承認状況を確認しており負担が大きい。また，メール上の承認者が営業担当者の所属組織に所属しているかどうかと，見積額とリスクレベルに応じて定められた役職者であるかどうかを確認するために，審査担当者は営業担当者の組織情報を商談ごとに逐一参照しており，大きな負担となっている。
• 商談ツールでは，専門知識を有する情報システム部で事前に作成した定型分析帳票でしかデータを分析できない。商談情報を多角的に分析するために，営業担当者が，新しい分析帳票を作成できるようにしてほしい。
• 新規顧客の場合，見込客の顧客情報を顧客管理システムに新規登録した時間帯によっては，当日中に商談概要を商談ツールに登録できないので，利用者から運用担当者への問合せが多くなる。
• 顧客情報の入力をミスすることがある。名刺サービスの情報から自動的に顧客情報を反映してほしい。
• 顧客の担当者と名刺を交換した日を正しく思い出せないときがある。
• 所属組織と役職で権限を管理し，機密性が高い情報でも商談内容を登録できるようにしてほしい。

〔新システムの開発方針〕

情報システム部のG部長は，新システムの効果を早期に確認して改良を続けていけるようにするために，ローコード開発機能を有する営業支援プラットフォームを採用し，毎年改良を重ねていく方針とした。営業支援プラットフォームは主要なSaaSとの連携を強化しており，名刺サービスとの連携機能を標準装備する予定である。
また，新システムをフロントシステムとして位置付け，顧客管理システムへの登録を新システム経由に集約する方針とした。将来的には，社内の他システムのフロントシステムとしても活用することを想定している。
G部長はF課長に，〔現行の業務とシステムの概要〕と〔現行の業務とシステムにおける課題及び要望〕を踏まえ，1年目に実現する新システムの要件定義の着手を指示した。

〔新システムの要件〕

要件定義の結果，F課長は1年目に実現する新システムの主な機能を表1のとおりとし，商談ツールを廃止して表2のとおり新システムにデータを移行することを，G部長に報告した。

〔G部長のレビュー結果〕

G部長は要件定義の結果をレビューし，次の指摘をした。

• ③新システムに顧客情報を新規登録して顧客管理システムに連携する際に，顧客管理システムに当該顧客情報が存在している場合がある。その場合は登録しようとしている顧客情報と顧客管理システムの顧客情報とを比較できるようにするべきである。
• 名刺サービスのデータを活用する上で，④検索結果が最新のデータか否かは営業担当者の登録内容に依存するので，営業担当者の責任で確認することを営業部に申し入れる必要がある。
• 名刺サービスの検索結果を新システムの顧客管理画面に表示する機能については，新システムに関わる今後の変化を踏まえ検討するべきである。
• 商談ツールは参照専用のツールとして残しておくべきである。