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

模範解答

解説

解答の論理構成

1. 複数端末運用の前提
   「生徒数が多い拠点では、登下校用端末を複数設置してどの端末でも登下校の手続ができるようにする。」
2. 端末とサーバの役割分担
   「登下校用端末が管理サーバから受け取る情報は、依頼した処理の成功又は失敗だけ」とあり、端末は履歴を保持しません。
3. 自動判定の仕組み
   登下校登録機能では「当日の記録件数で“登校”または“下校”を判定」。
4. 端末実装の問題点
   端末に判定ロジックを置くと、端末Ａで“登校”した履歴を端末Ｂは知らないため、下校時に0件と判断し再度“登校”と誤判定します。
5. したがって
   「① 登下校用端末に実装すると正しく判定できない」のは「登校時と下校時で別の登下校用端末を使用した場合」と結論付けられます。

誤りやすいポイント

• 端末の再起動・通信断が原因だと早合点する
  実際は“端末間で履歴を共有しない”ことが本質です。
• 「複数拠点利用」と混同する
  問題は同一拠点内の複数端末でも発生します。
• サーバ参照で即解決と考えず、端末仕様（履歴非保持）を読み落とす

FAQ

模範解答

解説

解答の論理構成

1. 写真添付という要望の把握
   • 【問題文】拠点長要望
     「保護者が生徒の顔を見て安心できるように、登下校を通知するメール(以下、登下校通知メールという)には登下校時に撮影した写真を添付したい。」
2. 写真を撮影する条件
   • 【問題文】登下校用端末の仕様
     「生徒が生徒カードをかざすとフロントカメラがQRコードを認識し、その時点の映像を生徒の顔や QRコードを含む写真として撮影する。」
     ⇒ カード読み取りが撮影トリガ。
3. 代理登録機能の仕様確認
   • 【問題文】表2「登下校代理登録」機能
     「カードを持っていない場合、手動で履歴登録を行う機能。」「拠点長が手動で情報を入力し、履歴ファイルに登録。」
     ⇒ 撮影や写真送信の処理はなし。
4. 上長の指摘
   • 【問題文】上長指摘
     「生徒が生徒カードの持参を忘れた場合に、登下校代理登録機能を用いる方法では、一部の要望を実現できない。」
     ⇒ 実現できない要望＝写真添付。
5. 結論
   よって問われている「登下校代理登録機能を用いる方法では実現できない要望」は
   「登下校通知メールに写真を添付する要望」となる。

誤りやすいポイント

• 代理登録でもカメラが使えると勘違いし、要望を「手続をスムーズに」と答えてしまう。
• 問題文中の「メール送信遅延を防ぎたい」「在室人数を把握したい」と取り違える。
• 「25字以内」という制約に気を取られ、原文の語句を改変してしまう。

FAQ

模範解答

解説

解答の論理構成

1. 仕様の確認
   【問題文】表2「メール送信エラー通知」に“宛先メールアドレスが一致する生徒の情報をもとに、該当の拠点長へ通知する。”と明記。
2. 想定される処理フロー
   ・メール送信失敗
   ・失敗した宛先＝保護者メールアドレスで生徒マスター検索
   ・該当生徒の所属拠点コードを取得 → 拠点長へ通知
3. 矛盾の発生点
   同じ保護者メールアドレスが複数生徒に共有されていると、検索結果が複数行になる。さらに“兄弟姉妹で入会する生徒も多いが、それぞれが別の拠点に所属する場合もある。”との業務要件があり、拠点コードが複数返る。
4. 帰結
   拠点長を一意に決定できず、通知すべき拠点が特定不能。したがって、問題の問いに対する具体的状況は「保護者メールアドレスが同一の複数の生徒が，別々の拠点に所属している場合」となります。

誤りやすいポイント

• 「生徒番号」は主キーなので重複しないと誤認し、メールアドレスも一意と勘違いする。
• 兄弟で同拠点に通うケースだけを想定し、拠点特定問題が起きないと判断してしまう。
• 「メール送信エラー通知」仕様を読み飛ばし、エラー通知は常に本部が行うと誤解する。

FAQ

模範解答

解説

解答の論理構成

1. 追加要件の把握
   「拠点長及び本部担当者の管理画面において、生徒の保護者に一斉にメール送信できるようにする。」とある。対象は「全生徒」。
2. 現仕様の確認
   「保護者が登下校通知メールの受信を希望する場合は、登下校通知メール受信有無を “有” にし、保護者メールアドレスを設定する。」
   → “無” の場合はアドレスを登録しない仕様。
3. 矛盾点
   アドレス未登録の生徒がいれば一斉送信で漏れが発生。
4. 必要な修正
   アドレス登録を必須に変えるのはデータ入力を担う「生徒情報管理」機能。
5. したがって
   ②で変更する機能は「生徒情報管理」、変更内容は「全ての生徒の保護者メールアドレスを設定するように変更」となる。

誤りやすいポイント

• 「登下校通知メール送信」を変更すると判断しがちだが、メール送信機能は専用サーバ導入で新設されるため根本原因とずれる。
• 登下校通知の受信可否フラグを廃止すると考えると仕様衝突を招きやすい。フラグは存続し、データ登録ルールだけを緩和すると理解する。
• 「メール送信エラー通知」機能を修正対象に誤選択するケースも多い。

FAQ

模範解答

解説

解答の論理構成

1. 追加された機能
   「拠点長及び本部担当者の管理画面において、生徒の保護者に一斉にメール送信できるようにする。」
2. 負荷の発生
   一斉送信＝多数メールを短時間で処理するためサーバ・ネットワーク負荷が急上昇。
3. 既存機能の要求
   表2「登下校通知メール送信」には「性能を考慮し一括送信しても遅延なく対応可能。」とあり、“即時送信”が品質要件です。
4. 懸念の具体化
   同一サーバで一斉送信を行うと「登下校通知メール送信」のキューが詰まり、【遅延】が発生する。
5. 対処策
   だから本文は「専用のメールサーバを新たに導入」──遅延を防ぐための分離設計。
6. 以上より、「③」は「登下校通知メールの送信が遅延する。」となります。

誤りやすいポイント

• 「メール送信エラーが増加する」と解釈し遅延を見落とす。
• 「在室人数表示」などメール以外の機能と結び付けてしまう。
• 「メール送信サーバがダウンする」と詳細に踏み込み過ぎ、設問が求める20字以内の“悪影響”を超えてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 問題文の追加仕様
   「登下校履歴ファイルに、実際に登下校した拠点を示す “拠点コード” 属性を追加」
2. 影響分析
   a. メール本文に表示する拠点名は、これまで「生徒が所属する拠点」のみだった。
   b. 在室人数表示は「登校の件数 − 下校の件数」を自拠点に限定して計算していた。
3. 必要な修正
   a. 登下校通知メール送信
   「通知対象である場合のみ送信」の時点で本文生成を行うため、取得元を履歴の拠点コードへ切替える。
   b. 拠点在室人数表示
   抽出条件に自拠点コード＝履歴の拠点コードを追加しないと、別拠点の登下校が混入する。
4. 40字以内での変更内容
   • 登下校通知メール送信：
     「メール本文の拠点名を履歴の拠点コードから参照する。」
   • 拠点在室人数表示：
     「自拠点コードで当日登校‐下校件数を集計する。」

誤りやすいポイント

• 生徒マスターの拠点コードを使い続けてしまい、実際に登下校した拠点と食い違う。
• 在室人数表示機能を修正対象から漏らし、他拠点の人数が計上される。
• 40字以内指定を意識せず冗長に書いて減点される。

FAQ