応用情報技術者 2023年 秋期 午後 問04

解答の論理構成

1. a を求める
   • 表3（イ）では「D社の a －＞ C社の生産システム　連携する情報：受注情報　連携頻度：日次」とある。
   • 表2で日次で受注（売上）系の情報を扱い、他システムへ連携しているのは「販売システム」である。引用：
     「表2 合併前のD社の基幹システム（抜粋）　販売システム　主な機能：受注（手入力） … 連携先システム：会計システム　連携する情報：売上情報　連携頻度：日次」
   • よって a ＝ 「販売システム」。
2. b を求める
   • 表3（エ）では「D社の b －＞ C社の配送システム　連携する情報：出荷指示情報　連携頻度：週次」。
   • 表2で「出荷指示情報」を週次で配送システムへ渡しているのは「生産システム」。引用：
     「生産システム … 連携先システム：配送システム　連携する情報：出荷指示情報　連携頻度：週次」
   • さらに表3（オ）で b は原価情報をC社の c へ週次連携している。表2の「生産システム」は会計システムへ原価情報を週次で送る仕様と一致する。
   • よって b ＝ 「生産システム」。
3. c を求める
   • 表3（オ）（カ）（キ）の受け側はいずれも C社の c であり、原価情報・売上情報・買掛情報を受け取る。
   • C社側でこれらの情報をまとめて受領するのは「会計システム」である。引用：
     「合併後のシステムの方針　・汎用機を用いたホスト系システムは廃止する。」
     「②C社の会計システムがSaaSを用いていることから、インタフェースがD社の各システムからデータを受け取り得る仕様を備えていることをあらかじめ調査すること」
   • 図1でも C社側で太枠の中央に位置し、多数の入出力を持つ矩形が c として描かれている。
   • よって c ＝ 「会計システム」。
4. 以上より
   • a：販売システム
   • b：生産システム
   • c：会計システム

誤りやすいポイント

• 「受注情報＝販売システム」と結び付けず、D社の見積段階のイメージから購買システムを選択してしまう。
• 出荷指示を“配送システムから配送システムへ渡す”と誤解し、b を配送システムと勘違いする。
• C社の会計システムが SaaS である点を見落とし、c を在庫システムと誤答する。
• 連携頻度（日次／週次）が旧システム仕様と一致するかを確認せず判断してしまう。

FAQ

解答の論理構成

• 新アーキテクチャは「①廃止するシステムの固有の機能については、処理の仕様を変更せず、継続利用するシステムに移植する」と明言しており、データ種別と連携頻度は合併前と同じになります。
• まず a・b・c を決めておくと判定が容易です。
  • 表3（イ）が「D社の a → C社の生産システム（受注情報、日次）」であるため、受注機能をもつ「販売システム」が a。
  • 表3（エ）が「D社の b → C社の配送システム（出荷指示情報、週次）」であるため、出荷指示を出す「生産システム」が b。
  • 表3（オ）が「C社の c」と書かれており、レビュー指摘②で「C社の会計システムがSaaS」と述べられているので c は「会計システム」。
• 以降は、合併前（表2）の該当レコードをそのまま引用し、送信元が変わるだけと理解すれば空欄が決まります。

誤りやすいポイント

• 「新しい連携だから頻度を変えるのでは？」と考え、元の頻度を上書きしてしまう。
• a と b を混同し、販売システムと生産システムを逆に当てはめる。
• 表2の“連携元”と“連携先”を読み違え、データ種別を誤選択する。
• レビュー指摘②を読まずに c を「配送システム」と誤解する。

FAQ

解答の論理構成

1. まず、統合方針で重複システムについて次の指示があることを確認します。
   【問題文】
   ・「販売システム、購買システム、配送システム及び会計システムは、両社どちらかのシステムを廃止し、もう一方のシステムを継続利用する。」
2. 次に、どのシステムが廃止対象かを決める判断材料として、同じく方針に示された条件を確認します。
   【問題文】
   ・「今後の保守の容易性やコストを考慮し、汎用機を用いたホスト系システムは廃止する。」
3. C社‐D社のシステム種別を照合すると、 ・C社の請求機能はホスト系（汎用機）で稼働。
   ・D社の「販売システム」はオンプレミス（オープン系）で稼働し、主な機能に「見積」「受注（手入力）」「請求（請求書発行）」「売上計上」を備える（表2）。
   従って、重複する “請求” 機能は C社側を廃止し、D社側を継続利用すると判断できます。
4. 下線①には次の記述があります。
   【問題文】
   ・「①廃止するシステムの固有の機能については、処理の仕様を変更せず、継続利用するシステムに移植する」
   ここで “廃止するシステム” は C社の請求システム、“継続利用するシステム” は D社の販売システムとなります。
5. したがって、移植先を問う設問への解答は
   会社名：D社
   システム名：販売システム
   となります。

誤りやすいポイント

• 「C社は存続会社」とあるため C社側のシステムを残すと早合点しやすい。方針のホスト系廃止条件を見落とすと誤答になります。
• C社の“受注”とD社の“販売”を単純に 1 対 1 で対応付け、請求機能も C社側が残ると誤認しやすい。
• 「移植元」ではなく「移植先」を答える設問である点を取り違え、C社の請求システム名を書いてしまうミス。

FAQ

解答の論理構成

1. 下線①には「"廃止するシステムの固有の機能については、処理の仕様を変更せず、継続利用するシステムに移植する"」とあります。よって、まずどのシステムが廃止対象かを把握します。
2. 方針には「"汎用機を用いたホスト系システムは廃止する"」と明記されています。表1を見ると、C社の「販売システム」は「オンプレミス（ホスト系）」、一方、表2のD社「販売システム」は「オンプレミス（オープン系）」です。従って、C社の「販売システム」を廃止し、D社の「販売システム」を存続させると判断できます。
3. 移植すべき“固有の機能”とは、廃止する側（C社）の販売システムにはあるが、存続側（D社）の販売システムには無い機能です。
   • C社の販売システム（表1）:「"受注（EDI）"」「"販売実績管理（月次）"」「"請求（EDI）"」「売上計上」
   • D社の販売システム（表2）:「見積」「受注（手入力）」「請求（請求書発行）」「売上計上」
4. 共通して存在しない、すなわち C社にしかない機能は
   • 「"受注（EDI）"」
   • 「"販売実績管理（月次）"」
   • 「"請求（EDI）"」
   となります。
5. よって、移植対象の機能は「受注（EDI）、販売実績管理（月次）、請求（EDI）」です。

誤りやすいポイント

• 「売上計上」は両社の販売システムに共通して記載されているため移植対象ではありません。
• 「見積」はD社側に既に存在する機能のため、C社の販売システムには無い点を見落としてしまう受験者がいます。
• “固有の機能”を「他のシステムに全く無い機能」と誤解しがちですが、ここでは「同種システム間で片方にしか無い機能」を指しています。

FAQ

解答の論理構成

• 【問題文】には下線②として「C社の会計システムがSaaSを用いていることから、インタフェースがD社の各システムからデータを受け取り得る仕様を備えていることをあらかじめ調査すること」とあります。
• SaaSはクラウド事業者が提供する共通サービスであり、ユーザ企業がサーバやアプリケーションを保有する「オンプレミス（ホスト系）」や「オンプレミス（オープン系）」とは管理権限が大きく異なります。
• オンプレミスなら自社でプログラムを改修し、新しいデータ受け取り口やフォーマットを自由に追加できます。
• しかし、SaaSは「共通基盤」ゆえにベンダ側が定めた標準APIやデータ項目しか利用できず、「個別要件の改変」は難しいか、追加料金・納期が発生します。
• そのため「D社の各システムからデータを受け取り得る仕様」を事前に確認し、対応不可の場合は連携方式を再検討する必要があります。
• よって「個別の会社向けの仕様変更が困難」が理由となり、模範解答につながります。

誤りやすいポイント

• SaaS＝クラウドとだけ覚えており、カスタマイズ制約を想起できない。
• 「インタフェースは作れば良い」と考え、既存SaaSのAPI上限や項目追加不可を見落とす。
• オンプレミスなら自由度が高い事実を軽視し、両者の差を明記しない。
• 40字以内に収めるために固有表現「C社」「SaaS」を削ってしまい、原文引用条件を破る。

FAQ