システムアーキテクト試験 2019年 午後1 問02

模範解答

解説

解答の論理構成

1. 入庫可能条件を探す
   • 容器倉庫での入庫フローは【問題文】「化学品の充填が可能になった容器を容器倉庫に入庫する。」と記載。
2. 入庫前に取り得る容器状態を抽出
   • 購入時処理: 【問題文】「容器状態区分を“未使用”にする。」→まだ使用歴がなく入庫可能。
   • 洗浄・検査後処理: 【問題文】「検査に合格した容器は容器倉庫へ運び…容器状態区分を“合格”…にする。」→再利用OKで入庫可能。
3. 他の区分は候補外
   • 「容器倉庫入庫」は入庫後に付与されるため前提条件にならない。
   • 「回収」「廃棄」などは入庫対象外と明示的または業務的に判断できる。
4. よって回答は「未使用，合格」。

誤りやすいポイント

• 「容器倉庫入庫」を入庫可と勘違いする
• 「回収」後すぐ入庫できると思い込む（実際は洗浄・検査を経て“合格”になるまで不可）
• “検査に合格”＝“充填済”と混同して「充填済」を挙げてしまう

FAQ

模範解答

解説

解答の論理構成

1. 【問題文】の該当箇所

   製造計画で決定した化学品の当日分の生産総量と製品マスタに登録されている情報を用いて、①どの容器が何個必要かを計算し、出庫指示を出す。

2. 目的を分解
   • 「どの容器が？」→容器種を特定する情報が要る。
   • 「何個必要か？」→総量 ÷ 1本あたりの充填量で個数を算出。
3. 製品マスタ（表1）の属性確認

   製品マスタ：製品コード、化学品名、容器種コード、容器一個当たり標準充填量、製品使用可能日数

4. 上記②③を結びつけると、必要なのは
   • 容器種コード
   • 容器一個当たり標準充填量
     他の属性は容器数計算に直接関与しない。
5. よって答えは「容器種コード，容器一個当たり標準充填量」となる。

誤りやすいポイント

• 「製品コード」まで挙げてしまう
  ⇒ 容器種は一意に決まるため不要。
• 「製品使用可能日数」を含める
  ⇒ 使用期限管理には使うが容器数計算には関係なし。
• 「容器番号」と混同
  ⇒ 容器番号は個体識別用。マスタには存在せず、計算にも不要。

FAQ

模範解答

解説

解答の論理構成

1. 一括読込みの特性
   • 【問題文】「RFタグの一括読み書きでは、環境によって数%程度の漏れが発生」とあり、ゲートで全数を捉えられないことがある。
2. 一致となる流れ
   • 一括で不足→個別に読み直し→本来の返却数と“ピタリ”一致。
   • したがって「一致＝一括読込み漏れの補正が成功した状態」。
3. 不一致となる流れ
   • 【問題文】「個別読込み件数と容器返却書に記載された容器返却数が不一致の場合は、エラー処理」。
   • 返却書自体の記載誤り、積込ミスなどで物理数が違うと個別読込みでも合わず不一致に。
4. 30字以内のまとめ
   • 一致: 「ゲート一括読込みでRFタグを取りこぼした場合」
   • 不一致: 「返却書記載数と実容器数が食い違っている場合」

誤りやすいポイント

• 「個別読込み＝必ず不一致」と思い込む
  → 実際は漏れ補完なら一致になる。
• ゲート読込み漏れを“通信エラー”と表現し枚数を絡めずに書く
  → 原因は「数%程度の漏れ」という枚数不足。
• 不一致の原因を「HT読取りエラー」とする
  → 個別読込みはタグを一つずつ読むため漏れに強く、主因は数量誤記。

FAQ

模範解答

解説

解答の論理構成

1. 再利用の目的を確認
   • 【問題文】「廃棄した容器に貼付してあったRFタグは、容器からはがして、再利用できるように、HTを用いて、②ある処理を行う。」
     ここで言う“再利用”は次の容器に貼り替えることを意味します。
2. 容器情報領域はロックされている
   • 【問題文】「容器情報領域は、RFタグを容器に貼付する際に書き込み、書込みロックを掛ける。書込みロックが掛けられた領域は、ロックを外さない限り値を変更できない。」
3. クリアしないと新規書込みができない
   • 【問題文】「対象項目がクリアされていない場合は書き込みできないよう、プログラムでガードする。」
4. 従って必要な操作
   (1) 書込みロックを解除する
   (2) 容器情報領域をクリアする
   以上を HT で実行すれば，RF タグは新しい容器に使える状態になります。

誤りやすいポイント

• 「製品情報領域だけをクリア」と誤解しやすい
  → 再利用時は容器種コード・容器番号も書き直すため，容器情報領域の初期化が必須です。
• ロック解除を忘れる
  → ロックされたままでは書込みができません。
• RFタグ番号を書き換えると考えてしまう
  → RFタグ番号は「書換えはできない」ので対象外です。

FAQ

模範解答

解説

解答の論理構成

1. ピッキング処理での書込み内容を確認
   「ピッキング指示データとRFタグ情報をチェックし、製品コードが合っていれば RFタグへ受注伝票番号を書き込み」（本文引用）とあり、RF タグは以後「受注伝票番号」「製品コード」を保持します。
2. 積込・出荷処理でのチェック内容を確認
   「HTで、積込対象となる製品のRFタグを読み込み、積込指示データとRFタグ情報をチェックする。③データ内容及び数が合っていれば…」（本文引用）
3. ここで照合するのは、積込指示データ（＝受注単位）と RF タグ情報の一致確認です。受注単位を識別する「受注伝票番号」と、製品種別を識別する「製品コード」が双方に含まれるため、この二つが③の答えとなります。
4. 表1を見ると双方とも属性名としてそのまま記載されているため、表記は「受注伝票番号，製品コード」となります。

誤りやすいポイント

• 「製品コード」だけで良いと判断し、「受注伝票番号」を落とす。結果、同一製品の他の受注分と混載する危険を見落とす。
• 表1の属性名を正確に引用せず、「受注番号」「商品コード」など勝手に言い換えて減点。
• ピッキング処理と積込処理の役割を混同し、ピッキング時点でチェックが終わっているから積込では不要と勘違いする。

FAQ

模範解答

解説

解答の論理構成

1. 現行業務の確認
   【問題文】の〔現行業務の概要〕(3)積込・出荷には
   「出荷作業者は、出荷実績を計上するために、出荷場所の端末から、出荷した製品の情報を販売管理システムに入力する。」
   と記載されています。
2. 改修後の流れ
   〔販売管理システムの改修〕(2)積込・出荷処理 では
   「HTで…検品を完了して出荷する。この際、容器状態管理ファイルの容器状態区分を“出荷”にする。」
   とあり、続けて
   「HTの検品を完了した実績データを取り込んで、(a)。」
   と指示されています。
3. 目的の一致
   検品完了後にシステムへ登録すべき実績は、旧来の「出荷実績」に相当します。したがって (a) には「出荷実績を計上する」が入ります。

誤りやすいポイント

• 「検品実績を記録する」と誤記する
  検品自体は HT 内で完了しており、システムに登録するのは“出荷”の実績です。
• 「在庫を更新する」と答える
  在庫は別途〔製品在庫管理処理〕で管理されます。ここで求められているのは販売管理上の実績計上です。
• 「RFタグ情報を更新する」と混同する
  RFタグは直前の処理で“出荷”状態へ更新済みであり、(a) は販売管理システム側の処理です。

FAQ

模範解答

解説

解答の論理構成

1. 顧客に渡り使用中の製品を示す容器状態区分
   • 【問題文】「出荷場所では…検品を完了して出荷する。この際、容器状態管理ファイルの容器状態区分を“出荷”にする。」
   • よって、顧客の手元にある容器は状態区分 “出荷”。
2. 使用期限日付の導出ロジック
   • 使用期限は「充填日」が起点。
   • 表1「製品マスタ」の属性に「製品使用可能日数」が定義。
   • 【問題文】「顧客が誤って使用期限を過ぎた製品を使ってしまわないように…」とあり、充填日＋製品使用可能日数で算出した日付を比較する仕様。
3. 検索条件への落とし込み
   • 条件式は「充填日から製品使用可能日数後の日付 ＜ 本日日付＋7日」。
   • 属性名としては「充填日」と「製品使用可能日数」をそのまま用い、算出後の日付を (c) とする。
4. したがって
   • (b) = 「出荷」
   • (c) = 「充填日から製品使用可能日数後の日付」

誤りやすいポイント

• 「回収」や「製品倉庫出庫」を選んでしまう
  顧客に届く前後のフローを混同しやすいので、出荷タイミングを時系列で整理することが重要です。
• 充填日そのものを使用期限と勘違い
  使用可能日数を加算する計算を忘れると条件式がずれます。
• 属性名で記述する指示を見落とす
  「使用期限」など未定義フィールドを書くと減点対象になります。

FAQ