システムアーキテクト 2012年 午後1 問02
Webによる写真プリント注文システムに関する次の記述を読んで、設問1~3に答えよ。
B社は写真フィルム、印画紙及び DPE(フィルム現像・プリント・引き伸ばし)装置の開発、製造、販売を行っており、全国のDPEショップ(以下、ショップという)にこれらの商品を導入することで発展してきた。一方、B社は、インターネットやデジタルカメラの普及を踏まえて、顧客がB社にインターネットからデジタルデータの写真プリントを直接注文するためのB社固有のシステム(以下、B社注文システムという)を開発、運用している。顧客が注文した写真は、B社のプリント工場で一括してプリントし、宅配便で顧客に納品している。
近年、デジタルカメラの一層の普及によって、デジタルデータの写真プリントが主流になってきている。そこで、B社は、インターネットから写真プリント注文ができる販売サイトを提供して各ショップを支援することにした。既存のB社注文システムを各ショップで利用できるように汎用化したシステム(以下、汎用化システムという)を開発し、各ショップに提供することで、支援を行う。Cマネージャは汎用化システムの開発推進担当になった。
〔販売サイトの運営形態の検討〕
Cマネージャは、インターネット上の販売サイトの運営形態を調査し、汎用化システムによる運営形態を検討した。販売サイトの運営形態案を表1に示す。
〔汎用化システムへの要望や制約〕
Cマネージャは、各ショップへのヒアリングなどを通じ、汎用化システムへの要望や制約を次のようにまとめた。
(1) ショップの特色を出したいので、独自の商品を開発して販売するなどの工夫を行えるようにしたい。
(2) システムやサイト全体の運営、管理は、B社が行ってほしい。
(3) ショップの運営について、B社からアドバイスや情報提供を行ってほしい。
(4) 顧客ごとの完了した取引回数などに応じた優遇をB社で行ってほしい。
(5) システムの開発、改造やWebページの作成を独自に実施できないショップがある。
(6) どのショップでも、ブラウザと電子メール(以下、メールという)は利用できる。
(7) ショップでは、ブラウザを用いて大きなサイズのデータを受け取ることはできるが、メールで受信できるデータのサイズには制限がある。
(8) ショップでは、メールの受信を数分以内に知ることはできるが、Webページを毎日確実に確認することは難しい。
〔汎用化システムの運営形態と提供形態の検討〕
Cマネージャは、〔汎用化システムへの要望や制約〕を踏まえた運営形態の検討を行い、表1を検討した結果、電子商店街案を採用することにした。次に、ショップへのシステム提供形態を検討した。ショップへのシステム提供形態案を表2に示す。
Cマネージャは、表2を検討した結果、Saas案を採用することにした。
〔汎用化システムの利用イメージ〕
汎用化システムでは、Web店舗という概念を導入する。Web店舗は各ショップがWeb上に設ける電子商店であり、インターネットから写真プリント注文を受け付ける。汎用化システムの利用イメージは次のとおりである。
(1) 店舗開設
各ショップは、Web店舗の登録とその店舗のWebページ作成を行う。Webページでは、各ショップの特色や強みをアピールできる。Webページは、テンプレートを選択し、文章を入力したり、写真やイラストをアップロードしたりすることによって、独自のデザインを容易に作成できる。独自の商品として、各ショップがWeb店舗で提供する独自のプリントサイズ、フォトブック、カレンダなどの仕上げ、納期の組合せ(以下、プリント種別という)を登録する。
(2) 会員登録
顧客は、この電子商店街を利用するために会員登録を行い、会員IDを取得する。会員登録をすると、写真データをアップロードし、必要に応じて編集したり、写真データのプリントを任意のWeb店舗に注文したりすることができる。
(3) 写真プリント注文
顧客は、住所、最寄駅、プリント種別、受取方法、支払方法などを指定して、注文したいWeb店舗を検索する。顧客は、選択したWeb店舗に入店して、プリントしたい写真データと、プリント種別やそれぞれの枚数・部数を指定する。受取方法は、宅配便受取と店頭受取から選択でき、支払方法は、クレジットカード、銀行振込、代金引換、店頭支払が選択できる。プリント種別、対応できる受取方法、支払方法はWeb店舗ごとに異なる。
入力内容を確認して顧客が注文を確定すると、B社からショップに通知される。
顧客は、過去の注文履歴(注文日、注文したWeb店舗、プリント種別、価格、完了状況など)を一覧で確認できる。
(4) 写真プリント作成
ショップは、注文の通知を受け、注文内容を確認する。注文された写真データと注文内容をショップのPCにダウンロードし、DPE装置で写真プリントを作成する。宅配便受取の場合は、発送手続を行う。店頭受取の場合は、顧客宛てに来店依頼メールを送信し、店頭で保管する。
(5) 写真受渡し
顧客は、宅配便やショップで写真を受け取る。
(6) 決済管理
ショップは、注文の支払方法に応じたタイミングで顧客の支払状況を確認し、必要に応じて催促を行う。入金管理はショップの責任で行う。ショップは、写真の受渡しと決済の確認後、B社に取引の完了登録を行う。
(7) B社のショップ支援
顧客が同じ会員IDで複数のWeb店舗を利用できるようにするために、顧客管理は各ショップではなく、B社が行う。また、B社は、顧客ごとの完了した取引回数に応じて優遇を行ったり、電子商店街全体の売れ筋情報や特色あるWebページの作り方などをショップに定期的にアドバイスしたりすることで、ショップを支援する。
〔汎用化システムの開発方針〕
Cマネージャは、汎用化システムの開発方針を次のようにまとめた。
(1) B社注文システムを改造して汎用化システムをSaaSとして開発し、各ショップにサービスとして提供する。
(2) Web店舗ごとに異なる可能性がある選択肢は、汎用化システムでは全て選択できるように開発し、Web店舗ごとに表示できる選択肢を選べるようにする。
(3) B社と各ショップが連携する機能(以下、ショップ連携という)を設ける。ショップ連携には、注文があったことをB社からショップに伝達する“注文伝達”、B社からショップに顧客データ、写真データを受け渡す“データ受渡し”、ショップがB社に取引の完了を登録する“取引完了登録”の三つの機能をもたせる。
〔汎用化システムの概要〕
〔汎用化システムの開発方針〕に基づき、汎用化システムの概要を検討した。汎用化システムの機能一覧を表3に示す。

設問1:〔汎用化システムの運営形態と提供形態の検討〕について、(1)、(2)に答えよ。
(1)Cマネージャが、販売サイトの運営形態として電子商店街案を採用することにした理由を20字以内で述べよ。
模範解答
・各ショップの創意工夫が生かせるから
・各ショップの特色が出せるから
解説
解答の論理構成
- ショップ側要望の確認
- 【問題文】〔汎用化システムへの要望や制約〕(1)に「独自の商品を開発して販売するなどの工夫を行えるようにしたい。」と記載。
- 運営形態案の比較
- 表1の電子商店街案③「フォトブック、カレンダーなどの独自の商品、特色あるWebページなど、各ショップの創意工夫を生かせる。」
- 一方、B社単独通販サイト案④「B社主導の商品展開になりやすい。」
- 要望適合性の判定
- ショップが“創意工夫”を発揮できるのは電子商店街案のみ。
- 結論
- よって選定理由は「各ショップの創意工夫が生かせるから」となる。
誤りやすいポイント
- SaaS案採用理由と混同し、「B社が一括管理できるから」と書いてしまう。
- 表1ではなく表2の説明を引用してしまい、根拠がずれる。
- “独自の商品”ではなく“B社の商品”と誤記し、要望との対応が曖昧になる。
FAQ
Q: 「特色が出せる」と「創意工夫が生かせる」はどちらを使っても良いですか?
A: どちらも【問題文】の表現に合致しており正答とされます。
A: どちらも【問題文】の表現に合致しており正答とされます。
Q: 受験の際に根拠まで書く必要はありますか?
A: 設問が理由を求める場合でも、実際の回答欄は短文のみで構いません。本解説は理解を深めるために詳細を示しています。
A: 設問が理由を求める場合でも、実際の回答欄は短文のみで構いません。本解説は理解を深めるために詳細を示しています。
関連キーワード: 電子商店街、SaaS, 要件適合性、カスタマイズ、ECサイト
設問1:〔汎用化システムの運営形態と提供形態の検討〕について、(1)、(2)に答えよ。
(2)Cマネージャが、ショップへのシステム提供形態としてSaaS案を採用することにした理由を、B社のメリットと各ショップのメリットに分けて、それぞれ30字以内で述べよ。
模範解答
B社のメリット:サイトの運営、管理やショップの管理を一括して行えるから
各ショップのメリット:ショップでシステムの導入、開発及び運用をしないで済むから
解説
解答の論理構成
- SaaSの特徴は「インフラ・アプリをサービスとして集中提供し、利用者はブラウザ経由で機能を利用する」ことです。
- 表2「SaaS案」より
- 「② サーバやデータベースは全Web店舗で共有」→B社側が集中的に運用できる。
- 「④ B社が、各ショップの運営状況などを把握しやすく、一括した管理が可能」→B社のメリット。
- 要望(5)「システムの開発、改造やWebページの作成を独自に実施できないショップがある」→ショップ側は自前対応が難しい。
- SaaSであれば、ショップは「ユーザ」としてログインするだけで機能を使え、サーバ保守・改修は不要となる。
- 以上より、
- B社のメリット:集中運営・統合管理ができる。
- 各ショップのメリット:システム導入・運用が不要。
誤りやすいポイント
- 「SaaS=クラウド=無料」と決めつけ、コストだけを強調してしまう。問題は運営・管理体制を問うている。
- 「B社のメリット」と「各ショップのメリット」を混同し、一方にしか触れない。
- ソフトウェアパッケージ案と混同して「カスタマイズが柔軟」と書いてしまう。SaaS案では設定変更で対応する。
FAQ
Q: SaaS案だとショップ独自機能が制限されませんか?
A: 表2「③ 要求機能のうち、ショップごとに違う部分は、個々のWeb店舗の設定を変えることで実現」とあるため、テンプレート設定で個別性を確保できます。
A: 表2「③ 要求機能のうち、ショップごとに違う部分は、個々のWeb店舗の設定を変えることで実現」とあるため、テンプレート設定で個別性を確保できます。
Q: ショップ側でデータを直接バックアップできないのでは?
A: バックアップはB社の集中管理下で行われるため、ショップは業務に専念できます。必要に応じてダウンロード機能で自店舗データを取得できます。
A: バックアップはB社の集中管理下で行われるため、ショップは業務に専念できます。必要に応じてダウンロード機能で自店舗データを取得できます。
Q: 将来の機能追加はどうなりますか?
A: B社がシステムを改造し全店舗へ同時適用できます。ショップはアップデート対応を気にする必要がありません。
A: B社がシステムを改造し全店舗へ同時適用できます。ショップはアップデート対応を気にする必要がありません。
関連キーワード: SaaS, クラウドサービス、マルチテナント、システム運用、電子商取引
設問2:
〔汎用化システムの開発方針〕で、Cマネージャが“Web店舗ごとに異なる可能性がある選択肢は、汎用化システムでは全て選択できるように開発し、Web店舗ごとに表示できる選択肢を選べるようにする。”と考えた理由を35字以内で述べよ。
模範解答
Web店舗ごとの要望に設定変更で対応できるようにしたいから
解説
解答の論理構成
- ショップの多様なニーズ
- 【問題文】要望(1)「ショップの特色を出したいので、独自の商品を開発して販売するなどの工夫を行えるようにしたい。」
⇒ 店舗ごとに“プリント種別”“受取方法”“支払方法”などが違う可能性が高い。
- 【問題文】要望(1)「ショップの特色を出したいので、独自の商品を開発して販売するなどの工夫を行えるようにしたい。」
- 自力改造できないショップの存在
- 【問題文】要望(5)「システムの開発、改造やWebページの作成を独自に実施できないショップがある。」
⇒ コード改修を前提とするカスタマイズは不適切。
- 【問題文】要望(5)「システムの開発、改造やWebページの作成を独自に実施できないショップがある。」
- Cマネージャの設計方針
- 【問題文】開発方針「Web店舗ごとに異なる可能性がある選択肢は、汎用化システムでは全て選択できるように開発し、Web店舗ごとに表示できる選択肢を選べるようにする。」
⇒ あらかじめ網羅的な選択肢を用意し、各店舗は“設定を変えるだけ”で自店舗仕様にできる。
- 【問題文】開発方針「Web店舗ごとに異なる可能性がある選択肢は、汎用化システムでは全て選択できるように開発し、Web店舗ごとに表示できる選択肢を選べるようにする。」
- 以上より、設定変更だけで店舗ごとの差異に対応する狙いを35字以内で表現すると「Web店舗ごとの要望に設定変更で対応できるようにしたいから」となる。
誤りやすいポイント
- 「独自の商品を登録できるようにするため」とだけ書き、設定変更という手段を明示しない。
- 「機能追加しやすくするため」と抽象的にまとめ、ショップ側の改造・運用負担を減らす意図を欠落させる。
- 35字以内に収めるために固有名詞やキーワードを勝手に改変してしまう。
FAQ
Q: なぜ“全て選択できるように開発”が必要なのですか?
A: 各店舗で扱うプリント種別や決済方式が異なる一方、コード改修は困難です。【問題文】要望(5)が示すとおり、設定変更だけで差異を反映するために網羅的に実装しておく必要があります。
A: 各店舗で扱うプリント種別や決済方式が異なる一方、コード改修は困難です。【問題文】要望(5)が示すとおり、設定変更だけで差異を反映するために網羅的に実装しておく必要があります。
Q: ショップが独自機能を追加したい場合はどうするのですか?
A: 汎用化システムで用意したメニューから選び、オン/オフ設定やパラメータ入力で対応します。これによりプログラム改造なしで独自性を確保できます。
A: 汎用化システムで用意したメニューから選び、オン/オフ設定やパラメータ入力で対応します。これによりプログラム改造なしで独自性を確保できます。
Q: SaaSを選択した点と今回の方針は関係しますか?
A: はい。SaaSでは単一のコード基盤を多数店舗で共有するため、個別改修は避けるのが原則です。設定だけで店舗差を表現できる設計が不可欠です。
A: はい。SaaSでは単一のコード基盤を多数店舗で共有するため、個別改修は避けるのが原則です。設定だけで店舗差を表現できる設計が不可欠です。
関連キーワード: SaaS, 設定パラメータ、カスタマイズ、多店舗運営、プリント注文
設問3:〔汎用化システムの概要〕について、(1)、(2)に答えよ。
(1)“注文伝達”をメールで実装する理由と、“データ受渡し”をブラウザで実装する理由を、それぞれ20字以内で述べよ。
模範解答
“注文伝達”をメールで実装する理由:注文を速やかに通知できるから
“データ受渡し”をブラウザで実装する理由:大きなサイズのデータを受け取れるから
解説
解答の論理構成
- 制約条件の確認
- “ショップでは、メールの受信を数分以内に知ることはできるが、Webページを毎日確実に確認することは難しい。”
- “ショップでは、ブラウザを用いて大きなサイズのデータを受け取ることはできるが、メールで受信できるデータのサイズには制限がある。”
- “注文伝達”の目的
- 受注事実を速やかに知らせ、プリント作業を開始させる。
- 上記制約より、メールなら即時確認できる → 遅延リスク低減。
- “データ受渡し”の目的
- 写真データを安全・確実に転送する。
- メールは容量制限があるため不向き。ブラウザ経由なら大容量のアップ/ダウンロードが可能。
- よって
- “注文伝達”→メール
- “データ受渡し”→ブラウザ
誤りやすいポイント
- 「メールは容量制限があるから即時通知に向かない」と逆に考えてしまう。通知は小容量なので問題なし。
- “注文伝達”をブラウザにすると、ショップがWebを毎日見ないため見落としが起こる。
- “データ受渡し”をメールにすると、写真データがサイズ制限で拒否される可能性がある。
FAQ
Q: メール通知でも迷惑メールフィルタに掛かるリスクはありませんか?
A: ありますが、優先度は「即時性」にあります。迷惑メール対策はホワイトリスト登録や件名統一など運用で補います。
A: ありますが、優先度は「即時性」にあります。迷惑メール対策はホワイトリスト登録や件名統一など運用で補います。
Q: ブラウザ転送では途中で通信が切れた場合どうなりますか?
A: 再開機能(レジューム)やチェックサムを実装することで、途中中断時でも再送・整合性確認が可能です。
A: 再開機能(レジューム)やチェックサムを実装することで、途中中断時でも再送・整合性確認が可能です。
Q: API や FTP ではなくブラウザを選んだ理由は?
A: すべてのショップが「ブラウザと電子メール」は利用可能という前提があり、追加ツールなしで運用できるからです。
A: すべてのショップが「ブラウザと電子メール」は利用可能という前提があり、追加ツールなしで運用できるからです。
関連キーワード: SaaS, ブラウザ、メール、データ転送、通知
設問3:〔汎用化システムの概要〕について、(1)、(2)に答えよ。
(2)“取引完了登録”が必要な理由として、過去の注文履歴の完了状況を確認するという理由以外に、どのような理由が考えられるか。30字以内で述べよ
模範解答
顧客ごとの完了した取引回数に応じた優遇を行うから
解説
解答の論理構成
- 機能定義の確認
汎用化システムの開発方針では「ショップ連携には…ショップがB社に取引の完了を登録する“取引完了登録”」と記載されています。 - ビジネス要件の把握
汎用化システムへの要望(4)に「顧客ごとの完了した取引回数などに応じた優遇をB社で行ってほしい。」とあります。 - 論理的帰結
優遇判定には「完了した取引回数」の正確なカウントが必要 → 取引が完了した時点でB社へ確実に通知・登録する仕組みが欠かせない → よって“取引完了登録”が不可欠となります。
誤りやすいポイント
- 「決済が終わったことを確認するため」とのみ答えてしまい、優遇施策との関連を示さない。
- 「注文履歴を最新化するため」と履歴機能だけに着目してしまう。
- “取引完了登録”をショップ内部の処理だと誤解し、B社側での集計ニーズを見落とす。
FAQ
Q: 完了登録がなくても決済情報があれば優遇できるのでは?
A: ショップごとに入金管理を行うため、B社が直接決済状況を把握できません。“取引完了登録”によりB社側で確実に完了実績を集計できます。
A: ショップごとに入金管理を行うため、B社が直接決済状況を把握できません。“取引完了登録”によりB社側で確実に完了実績を集計できます。
Q: 取引回数ではなく売上金額で優遇する場合も同じ仕組みを使う?
A: はい。完了登録時に金額情報も送れば、回数・金額どちらの集計にも対応できます。
A: はい。完了登録時に金額情報も送れば、回数・金額どちらの集計にも対応できます。
Q: 自動登録にしてショップ操作を省けないの?
A: ショップは「宅配便発送」「店頭受取」など複数パターンがあり、実際の受渡し完了タイミングは現場でしか判断できません。誤登録を防ぐため手動確認が前提です。
A: ショップは「宅配便発送」「店頭受取」など複数パターンがあり、実際の受渡し完了タイミングは現場でしか判断できません。誤登録を防ぐため手動確認が前提です。
関連キーワード: 顧客管理、トランザクション、完了登録、インセンティブ、SaaS


