戦国IT - 情報処理技術者試験の過去問対策サイト
お知らせお問い合わせ料金プラン

応用情報技術者 2012年 春期 午後03


顧客情報管理システム及び販売情報管理システムの更改に関する次の記述を読んで、設問1〜4に答えよ。

 K社は、北欧の家具と家庭雑貨の販売会社であり、L県を中心に複数の販売店を展開している。また、インターネットによる販売も手掛けており、売上の増加と利益の拡大のために、新たなブランドの商品をインターネットで販売することを計画している。この計画を実現するために、本店に設置している顧客情報管理システム及び販売情報管理システムについて、将来の事業展開の見通し及び現行システムの問題点と改善要望を考慮した更改計画を策定する必要が生じている。   〔現行システムの概要〕  現行システムの概要は、次のとおりである。  ・販売店ごとに顧客情報(氏名、住所、電話番号、購入履歴)を、店内に設置したPCで管理している。  ・インターネット販売の顧客情報(氏名、住所、電話番号、メールアドレス、購入履歴)を顧客情報管理システムで管理している。  ・各販売店から販売情報管理システムに、商品ごとの販売数量が、每日1回、送信され、蓄積される。  ・Webサーバから販売情報管理システムに、インターネット販売の販売情報が、リアルタイムで、送信され、蓄積される。  ・現行システムは、現在のデータ処理量の1.5倍まで処理できる能力をもっている。  ・現行システムは、品質が安定せず、機能追加をしたときのシステム障害の発生件数が増加傾向にある。  ・現行システムが稼働しているハードウェアは、1年後に保守期限が到来する。  ・現行システムへの機能追加要望には応えきれていない。   〔更改計画の策定〕  情報システム部のX部長は、次の①〜③の手順で更改計画を策定するように、システム企画担当のY課長に指示した。  (1) 将来の事業展開の見通しを把握するとともに、現行システムの問題点と改善要望を抽出するために、関係各部へのヒアリングを実施し、内容を整理する。  (2) ヒアリング結果を踏まえて、システム化の方針を明確にする。  (3) システム化の方針に基づき、システムの実現方式を検討する。   〔ヒアリング結果の整理〕  Y課長は、経営企画部、営業部及び情報システム部の部長及び課長にヒアリングし、将来の事業展開の見通し及び現行システムの問題点と改善要望を次のように整理した。  (1) 経営に関する事項   ・今後6年間は、販売店の改装とWebサーバの増設を最優先で行うので、多額の投資を必要とする。年間の投資額には一定の度数があるので、顧客情報管理システム及び販売情報管理システムへの投資は、極力少なくする必要がある。   ・個人情報については、個人情報保護マネジメントシステム (PMS) を適用し、社で定めた個人情報管理規程に基づいて管理している。個人情報の処理を外部委託することについては、顧客から同意を得ている。ただし、今までは、外部委託していなかったので、外部委託先との個人情報の授受に関する手順は、個人情報管理規程に盛り込まれていない。  (2) 販売に関する事項   ・6か月後から、インターネットで新たなブランドの商品販売を開始するとともに、様々なメディアを使って、大規模なプロモーションを行う。最大で、インターネット販売の顧客数が現在の3倍、販売数量が現在の5倍になると見込んでいる。ただし、競合他社の品ぞろえやプロモーションの実施状況によって、顧客数、販売数量は、増減する。   ・プロモーションを効果的に実施できるようにするために、年齢別・家族構成別・月別・商品別の販売数量を集計し、分析する機能の利用を、6か月後までには開始できるようにしてほしい。   ・更改後のシステムでは、顧客情報管理及び販売情報管理の機能を、K社独自の販売業務プロセスに合うように、拡充してほしい。   ・現行システムでは、特定の販売店がセールをする場合、インターネット販売だけの顧客宛てには案内を発送できない。  (3) システムに関する事項   ・今までは、甚大な地殻災害の発生を想定していなかったので、現行システムは、本店のビル内に設置してある。   ・現行システムのシステム障害の増加に伴って、保守・運用作業の工数が増加している。   ・短期間にデータ処理量が増減しても、顧客情報管理システム及び販売情報管理システムのリソースに不足や余剰が生じないようにする必要がある。   ・顧客情報管理システム及び販売情報管理システムを自社で再開発する場合には、最低9か月の期間が必要になる。   〔システム化の方針〕  Y課長は、〔ヒアリング結果の整理〕に基づき、システム化の方針を次の(1)〜(7)のとおり明確化した。  (1) 商品、顧客、商談などの情報管理や売上予測などの機能を有し、営業活動を支援するツールであるCRMパッケージを利用する。  (2) CRMパッケージにとって、①販売店の顧客情報とインターネット販売の顧客情報を一元管理する。  (3) K社独自の販売業務プロセスに合わせた機能を提供する。  (4) システム更改に伴う投資額は、最小限にとどめる。  (5) 既存の個人情報管理規程を適用する。  (6) データ処理量に急激な変動があっても、システムのリソースに過不足が生じないようにする。  (7) システムの保守・運用作業は、極力アウトソースする。    〔システムの実現方式の検討〕  Y課長は、〔システム化の方針〕に基づき、必要なシステムを全て自社で構築して所有する方式と、SaaSを利用する方式とを比較した。その結果、②SaaSを利用する方式においても、個別の対応(カスタマイズなど)を必要とする項目があるものの、次の(1)〜(5)のメリットを享受できることから、詳細を検討を進めることにした。  (1) 導入初期の投資を大幅に軽減できる。  (2) a に応じて、システムリソースに過不足が生じることなく迅速に利用できる。  (3) サービスの利用を b に開始できる。  (4) 保守・運用作業の工数を削減できる。  (5) システムの資産管理作業の工数を軽減できる。  Y課長は、SaaS 事業者に詳細な利用条件の提示を依頼するために、X部長に SaaS の利用について説明したところ、③SaaS 事業者のデータセンタが、拠点が広域災害によって被災した場合を想定して、自社の事業継続計画(BCP)の観点から SaaS 事業者に確認すべき点があると指摘された。その上で、SaaS を利用する際には、K社の要求水準と SaaS 事業者の保証条件を明文化し、c を締結するよう指示された。

設問1

本文中の下線①によって、販売に関するどのような問題が解決されるか。45字以内で述べよ。

模範解答

インターネット販売だけの顧客宛てには、特定の販売店のセールの案内を送れない。

解説

解答の論理構成

  1. 下線部①の内容確認
    ― 「CRMパッケージにとって、①販売店の顧客情報とインターネット販売の顧客情報を一元管理する」とあります。一元管理は、両チャネルの顧客データを統合することを意味します。
  2. 販売上の課題を抽出
    ― 〔ヒアリング結果の整理〕(2) 販売に関する事項の最後に、
    現行システムでは、特定の販売店がセールをする場合、インターネット販売だけの顧客宛てには案内を発送できない。
    という問題点が明記されています。
  3. 因果関係の整理
    ・顧客データが販売店とインターネットで分かれている ➔ 販売店側で抽出できるのは店舗顧客のみ。
    ・下線部①により顧客データを統合すれば、チャネルを問わず顧客抽出が可能 ➔ インターネット販売だけの顧客にもセール案内を発送できる。
  4. したがって「店舗セールの案内をインターネット顧客へ送れない」という販売面の問題が解消されると結論付けます。

誤りやすいポイント

  • 「販売数量の急増対応」「分析機能の拡充」など他の要望と混同し、顧客データ統合の直接的な効果を取り違える。
  • 「メールアドレスが無い」などデータ項目の不足を理由にしてしまい、本来の“顧客情報の分断”という構造的課題を見落とす。
  • 単に「顧客情報の一元管理ができる」とだけ書き、どの販売上の課題が解決されるのかを明示しない。

FAQ

Q: なぜ販売店のセール案内がインターネット顧客に送れなかったのですか?
A: 顧客情報が店舗システムとインターネット販売システムで別管理だったため、店舗側からはインターネット顧客を抽出できなかったからです。
Q: 一元管理すると、他にどんなメリットがありますか?
A: 顧客の購買履歴をチャネル横断で参照できるので、クロスセル・アップセル施策や顧客分析の精度向上が期待できます。
Q: 新ブランド開始まで6か月という短期間でも導入可能でしょうか?
A: SaaS 型 CRM であれば「サービスの利用を b に開始できる」とあり、短期間で立ち上げやすい利点があります。

関連キーワード: 顧客データ統合, CRM, オムニチャネル, マスタ統合, ターゲティング

設問2

本文中の下線②について、SaaSにおいても個別の対応を必要とする項目を〔システム化の方針〕の(3)〜(7)から二つ選び、番号で答えよ。

模範解答

(3)、(5)

解説

解答の論理構成

  1. まず、下線②は「SaaSを利用する方式においても、個別の対応(カスタマイズなど)を必要とする項目がある」と述べています。
  2. どの項目が “個別対応” を要するかは、〔システム化の方針〕(3)〜(7) を比較し、次の観点で判断します。
    • SaaS が標準で備えていない、または自社固有の要件が強いもの
    • 追加設定・機能拡張・契約上の取り決めが別途必要なもの
  3. 〔システム化の方針〕(3) は「K社独自の販売業務プロセスに合わせた機能を提供する」。
    • SaaS は汎用 CRM を前提とするため、独自プロセスを完全に反映させるには画面・ワークフロー・帳票などのカスタマイズが不可欠です。
    • よって “個別対応” が必要になります。
  4. 〔システム化の方針〕(5) は「既存の個人情報管理規程を適用する」。
    • SaaS 提供側が準拠する標準規程と、K社独自の「個人情報管理規程」のギャップを埋めるために、
      ・暗号化方式やログ保管期間の設定変更
      ・委託先とのデータ授受手順の追加ルール
      ・契約書への特約事項の明記
      ― などが必要となり、これも “個別対応” に該当します。
  5. 一方、(4)「投資額を最小限に」や (7)「保守・運用作業をアウトソース」は SaaS の利用自体が満たすメリットで、個別カスタマイズを要する主題ではありません。
  6. (6)「データ処理量に急激な変動があっても…」もクラウドのスケール機能で標準的に満たされるため、特別な個別対応とは言いにくいです。
  7. 以上から、下線②に該当する番号は
    「(3)、(5)」
    となります。

誤りやすいポイント

  • (6) を選んでしまう
    • クラウド(SaaS) はスケールアウト・スケールアップを標準機能として提供することが多く、追加カスタマイズ不要なケースが一般的です。
  • (4) を個別対応と誤解する
    • 投資額削減は SaaS の“効果”であり“対応”ではありません。
  • 「個人情報規程」の適用を軽視する
    • SaaS でも契約・運用手順の整合を取らなければ規程違反になる点を見落としがちです。

FAQ

Q: SaaS の画面レイアウト変更も“カスタマイズ”に含まれますか?
A: 含まれます。独自ワークフローや帳票出力まで踏み込む場合、追加費用や開発作業が発生するため“個別対応”扱いです。
Q: 個人情報規程の適用は設定変更だけで済むこともありますか?
A: 場合によっては設定変更だけで済むこともありますが、契約書への取り決め追記や第三者認証の取得確認など、手続き面の対応も必要になることが多いです。
Q: (7) のアウトソースは個別対応に入らないのですか?
A: SaaS 事業者が保守・運用を標準サービスとして提供するため、追加開発や特別契約が不要な限り“個別対応”とはみなしません。

関連キーワード: SaaS, CRM, カスタマイズ, 個人情報保護, 業務プロセス

設問3〔システムの実現方式の検討〕について、(1)、(2)に答えよ。

(1)abに入れる適切な字句を、本文中の字句を用いて答えよ。

模範解答

a:データ処理量 b:6か月後まで

解説

解答の論理構成

  1. 空欄aについて
    • メリット(2)の原文は「a に応じて、システムリソースに過不足が生じることなく迅速に利用できる。」です。
    • これと対になる要求は〔システム化の方針〕(6)の「データ処理量に急激な変動があっても、システムのリソースに過不足が生じないようにする。」という記述です。
    • よって“システムリソース”の過不足を左右する要素は「データ処理量」であると判断できます。
      a=「データ処理量」
  2. 空欄bについて
    • メリット(3)の原文は「サービスの利用を b に開始できる。」です。
    • ヒアリング結果(2)には「年齢別・家族構成別・月別・商品別の販売数量を集計し、分析する機能の利用を、6か月後までには開始できるようにしてほしい。」とあります。
    • “いつまでに開始”という時期を示す具体的要求はこの「6か月後まで」です。SaaS の導入メリットとして“早期利用開始”を示すのに最も適切です。
      b=「6か月後まで」

誤りやすいポイント

  • “アクセス数”や“ユーザ数”をaに入れてしまう
    「リソース過不足」→「スケールアウト」が連想されやすいですが、本文では「データ処理量」の増減が直接言及されています。
  • “すぐに”や“速やかに”をbに入れてしまう
    空欄直前の「サービスの利用を」の後には具体的期限が求められており、ヒアリング結果の「6か月後まで」と一致させる必要があります。
  • ヒアリング結果ではなくシステム化の方針だけを参照してしまう
    実際の時期や数値はヒアリング結果にしか書かれていません。

FAQ

Q: aに「需要量」や「負荷変動」ではダメですか?
A: いずれも意味は近いですが、問題文に出てくる正確な字句「データ処理量」をそのまま用いることが指示されています。
Q: bは「半年後」でも正解になりますか?
A: 原文は「6か月後まで」です。“半年後”は言い換えになるため、本試験では不正解になる恐れがあります。
Q: SaaS 導入で“6か月後までに開始”が本当に可能なのですか?
A: SaaS は既に用意されたサービスを契約するだけで利用開始できるため、自社開発の「最低9か月」より短期間で導入可能、というストーリーになっています。

関連キーワード: SaaS, CRM, スケーラビリティ, BCP, 個人情報保護

設問3〔システムの実現方式の検討〕について、(1)、(2)に答えよ。

(2)cに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群  ア:NDA  イ:RFI  ウ:RFP  エ:SLA  オ:SOA

模範解答

c:エ

解説

解答の論理構成

  1. 【問題文】では、
    「SaaS を利用する際には、K 社の要求水準と SaaS 事業者の保証条件を明文化し、c を締結するよう指示された。」
    とあり、ここで求められている文書は「要求水準(利用者が求めるサービス条件)と保証条件(事業者が提供を約束するサービス条件)を明確にする契約」です。
  2. 要求水準と保証条件を取り決める契約は一般に「サービスレベルアグリーメント(SLA)」と呼ばれます。SLA では可用性、性能、復旧時間などを数値で合意し、違反時のペナルティも定めるのが通例です。
  3. 選択肢を照合します。
    ・ア: NDA(秘密保持契約)…情報漏えい対策には有効ですが、可用性や性能保証は扱いません。
    ・イ: RFI(情報提供依頼書)…選定初期に事業者へ広く情報を求める文書であり、契約ではありません。
    ・ウ: RFP(提案依頼書)…提案を募集する文書であり、合意内容を確定する契約ではありません。
    ・エ: SLA…上記の説明通り、サービスレベルの合意を文書化する契約です。
    ・オ: SOA(サービス指向アーキテクチャ)…システム設計思想であり契約文書ではありません。
  4. 【問題文】の前段には、
    「SaaS 事業者のデータセンタが、拠点が広域災害によって被災した場合を想定して、自社の事業継続計画(BCP)の観点から SaaS 事業者に確認すべき点がある」
    と書かれており、可用性や災害対応などのレベルを取り決めることが強調されています。これも SLA が必要である根拠になります。
  5. 以上より、c に入る適切な字句は「エ:SLA」と判断できます。

誤りやすいポイント

  • 「NDA は秘密保持=安全対策」と思い込み、可用性や性能までカバーすると誤解する。
  • 「RFP は要求をまとめる文書だから契約後も使う」と考えて混同する。RFP は提案依頼であって、要求と保証を法的に拘束する契約ではありません。
  • 「SOA は ‘サービス’ の字があるので SaaS 関連契約」と連想してしまう。SOA は設計アプローチであり、契約書ではありません。

FAQ

Q: SLA には必ず数値目標を入れる必要がありますか?
A: はい。可用性(例:99.95%)、応答時間、バックアップ頻度などを定量的に設定しないと、事業者の義務範囲が曖昧になり、BCP 対策として機能しません。
Q: 契約締結後にサービスレベルを変更したい場合はどうしますか?
A: 通常は SLA の改訂手続きを契約書内で規定します。事業拡大や法改正に応じて両者合意の上でバージョンアップを行います。
Q: RFP や RFI を用意していたら SLA は不要ですか?
A: 不要にはなりません。RFI/RFP は選定・提案段階の文書、SLA は選定後の運用・保証段階の契約と役割が異なります。

関連キーワード: サービスレベル合意, 可用性保証, 災害対策, 契約管理

設問4

本文中の下線③について、確認すべき点を40字以内で述べよ。

模範解答

遠隔地のバックアップセンタを利用して、K社の業務を継続できること

解説

解答の論理構成

  1. 問題文では、SaaS 方式を検討する際に「③SaaS 事業者のデータセンタが、拠点が広域災害によって被災した場合を想定して、自社の事業継続計画(BCP)の観点から SaaS 事業者に確認すべき点がある」と明記されています。
  2. 「広域災害によって被災」すると、単一拠点のデータセンタではサービスが停止し、K社の業務が継続できません。BCP の観点からは、代替拠点で迅速にサービスを再開できる体制が必要です。
  3. SaaS 事業者側に求めるべき事項は、(a)遠隔地に物理的に分離されたバックアップセンタまたは冗長サイトを保有しているか、(b)そこへデータを常時/定期的に複製しているか、(c)障害発生時に可用性を確保し業務を継続できるか、という点になります。
  4. 以上を踏まえ、模範解答は「遠隔地のバックアップセンタを利用して、K社の業務を継続できること」となります。

誤りやすいポイント

  • SLA の可用性数値(例:稼働率99.9%)だけを確認すれば良いと考え、実際の冗長構成やサイト間距離を問わない。
  • データのバックアップ有無だけに着目し、「切替時間」「運用手順」など業務継続に必要な要素を考慮しない。
  • 契約書(c)に盛り込むべき内容を後回しにし、サービス開始後に交渉しようとしてしまう。

FAQ

Q: バックアップとディザスタリカバリは同じ意味ですか?
A: バックアップはデータ複製そのもの、ディザスタリカバリは災害時に代替サイトへ切り替えて業務を継続する一連の仕組みを指します。BCP では両方を求めます。
Q: SaaS 事業者がクラウド上に複数リージョンを持っていれば十分ですか?
A: 物理的に分離されたリージョンを保有し、データ同期と切替手順が確立されていることを契約で確認する必要があります。
Q: 契約書にはどのような可用性指標を盛り込むべきですか?
A: 復旧時間目標(RTO)、復旧時点目標(RPO)、バックアップ保存期間、切替試験実施頻度などを具体的に定めると確実です。

関連キーワード: BCP, SaaS, データ冗長化, バックアップ, 可用性
戦国ITクイズ機能

\ せっかくなら /

応用情報技術者
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてプライバシーポリシー利用規約特商法表記開発者について