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

模範解答

解説

解答の論理構成

1. 連携される具体的な入力内容を確認
   • 【問題文】「配達員は営業所出発前に、配達時に使用する配達車両に加えて配達員の氏名を配達端末で配達システムに入力し、あらかじめ決めておいた配達順序の順番に送付伝票のバーコードを読み取り…」
     ➔ 端末→システムへ送られるのは ①順序 ②車両 ③氏名。
2. 計算機能が利用する情報を特定
   • 【問題文】「(1) 配達予定時刻計算機能 配達員から配達端末を用いて連携された情報を基に、推奨移動経路で移動した場合の各受取場所への配達予定時刻を計算する。」
     ➔ “経路計算”には順序と車両が不可欠。氏名は関係しない。
3. 不要情報を除外し解答を確定
   • 氏名は到着時刻に影響しない＝除外
   • 残った2要素をそれぞれ15字以内で表現すると模範解答どおり。

誤りやすいポイント

• 「配達員の氏名」も連携されるため誤って選択しやすい
• “推奨移動経路”や“交通情報”はシステム内の既存データであり端末から送る情報ではない
• 15字以内に収める際に語尾を削り過ぎて原文表現を崩すミス

FAQ

模範解答

解説

解答の論理構成

1. 利害関係者の要望を確認
   ・依頼主の要望: 「依頼主が誰なのかを届け先顧客に通知してほしい。」
   ・届け先顧客の要望: 「配達員として誰が来るのかが分かるようにしてほしい。」
2. 新機能の仕様を確認
   「配達先の営業所を出発したタイミングで、配達予定時刻と①ある情報を配達予定情報として届け先顧客に通知する。」
3. 要望と機能のマッピング
   • 依頼主の要望 → 「依頼主名」を含めれば満たせる
   • 届け先顧客の要望 → 「配達員の氏名」を含めれば満たせる
4. 10字以内にまとめて解答
   ① 配達員の氏名
   ② 依頼主名

誤りやすいポイント

• 「配達員の担当区域」や「車両情報」を選んでしまう
• 「依頼主名」を「依頼主情報」など10字を超える表現で書く
• 配達完了通知用の情報と混同し、「配達完了日時」を挙げる

FAQ

模範解答

解説

解答の論理構成

1. 【問題文】配達条件変更機能
   「(a)の場合、かつ(b)の場合においては、配達条件の変更を受け付けない。」
   └ ここで (a)(b) が何を指すかを探す必要があります。
2. 同じ段落に対応する条件が掲載されていないため、関連する業務説明を確認します。
3. 【問題文】再配達受付業務
   「再配達希望日が当日で、かつ再配達希望時間帯の受付締切時刻経過後は、再配達希望は受け付けない。」
4. 論理式が完全に一致
   ・「再配達希望日が当日」→ (a)
   ・「再配達希望時間帯の受付締切時刻経過後」→ (b)
5. よって (b) の答えは「配達希望時間帯の受付締切時刻経過後」と決定します。

誤りやすいポイント

• 「再配達受付業務」の文章を「再配達だけの特例」と早合点して読み飛ばすミス。
• 「当日」だけを条件と思い込み、論理式の後半（受付締切時刻）を見落とすミス。
• 「受付締切時刻経過後」を「締切後」などと略して原文を改変するミス。

FAQ

模範解答

解説

解答の論理構成

1. 届け先顧客の要望
   • 【問題文】届け先顧客：(2)「帰宅して不在連絡票を確認しなくても再配達依頼できるようにしてほしい。」
2. 新たに追加された配達状況入力
   • 【問題文】配達システム改善後：「不在連絡票を投かんした場合は、配達員が、配達状況を“不在連絡済”にする。」
3. 不在連絡票通知機能
   • 【問題文】新機能(3)「配達員が不在連絡票を投かんし、配達状況を“不在連絡済”にしたタイミングで、不在連絡票の内容を届け先顧客に通知する。」
4. 推論
   • ステータス“「不在連絡済」”が入力された瞬間に通知が自動送付されるため、届け先顧客は自宅に戻る前でも内容を確認し、再配達依頼が可能になる。
5. 結論
   • よって追加した入力ケースで達成される改善要望は「不在連絡票を確認しなくとも再配達依頼ができること」となる。

誤りやすいポイント

• 「不在連絡票通知機能」自体が要望の答えと誤解し、要望ではなく機能名を書いてしまう。
• 依頼主の要望(配達完了通知など)と混同する。
• ステータス“「担当区域外」”の追加と取り違える。

FAQ

模範解答

解説

解答の論理構成

1. 配達員の担当区域の管理方法
   • 【問題文】「各配達員の担当区域は、営業所ごとに管理されており、配達システムには登録されていない。」
2. 配達システムが持たない情報
   • 登録がないため、システム側には担当区域と住所を突き合わせて自動判定する機能がない。
3. 判断できる唯一の人物
   • 自分の区域を把握している配達員のみが「区域外」を即時に判断可能。
4. したがって
   • 配達員が配達状況を “担当区域外” に直接変更する仕様とした。

誤りやすいポイント

• 「配達条件変更機能で区域外判定できる」と勘違いする
  → 配達条件変更機能は希望日・時間帯・受取場所の変更受付であり、区域判定とは無関係。
• 「営業所担当者が区域外を入力する」と考える
  → 現場で即時に判断・入力する必要があるため配達員が行う。
• 「区域情報は追加開発で登録された」と誤読する
  → 改善後も登録しない設計である。

FAQ

模範解答

解説

解答の論理構成

1. “これまでの配達業務”では
   「3便目の配達業務完了後に配達車両から荷物を降ろし、営業所倉庫に保管する。」
   → 1・2便終了時には荷物を降ろさないのが通常。
2. 改善後の仕様では配達条件変更機能が追加され、
   「変更後の受取場所として配達先の営業所が指定された場合は、配達状況を“営業所倉庫保管”として、営業所帰還時に荷物を降ろすことを配達員に指示する。」
   → 荷物を当日途中で降ろす新たな手順が発生。
3. 見出し部分の記述
   「配達システムが配達状況を“(c)”に変更していた場合には、営業所に帰還した際に、これまでの配達業務では行わなかった作業を実施する。」
   → “これまで行わなかった作業”＝途中便でも荷物を降ろして倉庫保管。
4. よって
   (c)＝“営業所倉庫保管”。
   追加作業＝「当日の配達業務完了前に荷物を降ろし，営業所倉庫に保管する作業」。

誤りやすいポイント

• “営業所戻り”は「当該便では荷物の配達を行わない」だけで、荷物を降ろす指示が無い点を見落としやすい。
• 「荷物を降ろす」工程が新しいかどうかを判断せず、ステータス名だけで選びがち。
• 35字以内で「作業内容」を求められていることを忘れ、冗長な説明を書いてしまう。

FAQ