システムアーキテクト 2024年 午後1 問03
学習塾の通知システムに関する記述を読んで設問に答えよ
K 社は小中学生を主なターゲットにした個別指導学習塾チェーンであり、全国約200 の拠点とそれらを統括する本部で構成されている。 保護者の防犯意識の高まりを受けて、生徒が塾に到着したとき (以下、登校という)と帰宅のために塾を退出するとき(以下、下校という)に保護者に電子メール (以下、メールという)で登校・下校(以下、登下校という)を通知するシステム (以下、新システムという)を新たに導入することにした。
〔業務の概要と新システムへの要望〕
K社の拠点は駅前を中心に展開されており、各拠点には30~100名程度の生徒が所属している。 兄弟姉妹で入会する生徒も多いが、それぞれが別の拠点に所属する場合もある。通常の授業は14時から21時まで行われている。
新システムは、保護者からの“子供が無事に塾に到着したのかを知りたい”、“帰宅前に通知が欲しい ” といった要望を受けて導入が決まったものであり、拠点長からは次のような要望も寄せられている。
・保護者が生徒の顔を見て安心できるように、登下校を通知するメール (以下、登下校通知メールという)には登下校時に撮影した写真を添付したい。
・夕方のピーク時間帯の授業では、授業開始直前や終了直後に出入口が混雑するので、登下校の手続はスムーズにできるようにしてほしい。
・登下校通知メールの送信が遅延すると保護者に不安を与えるので、可能な限り早く送信したい。
・生徒は時々忘れ物をすることがあるが、その場合でも使えるようなシステムにしてほしい。
・登下校の履歴から拠点に在室している生徒数を把握したい。
〔新システムの設計〕
K 社情報システム部のL課長は、新システムを次のように設計した。
拠点の出入口に、生徒が登下校の手続を行うためのタブレット端末 (以下、登下校用端末という) を設置する。 登下校用端末には、拠点ごとに一意の拠点コードを設定しておく。 生徒数が多い拠点では、登下校用端末を複数設置してどの端末でも登下校の手続ができるようにする。
本部に管理サーバを設置し、各種マスターや登下校履歴のファイルは管理サーバ内で一元管理する。 拠点長及び本部の担当者は、管理サーバに実装する Web 管理画面(以下、管理画面という)にログインして各種管理業務を行う。 登下校用端末からは管理サーバ内のファイルにはアクセスしない。 登下校用端末が管理サーバから受け取る情報は、依頼した処理の成功又は失敗だけとする。
生徒には1人1枚ずつ生徒カードを配布する。 生徒カードには一意の生徒カード番号を割り当て、生徒カード番号のQRコードと生徒氏名を印刷する。
登下校用端末では常時フロントカメラが動作している。 生徒が生徒カードをかざすとフロントカメラがQRコードを認識し、その時点の映像を生徒の顔や QRコードを含む写真として撮影する。 その上で、QRコードから読み取った生徒カード番号と撮影した写真を管理サーバに送信し、管理サーバで登下校登録と保護者への登下校通知メール送信が行われる。 登下校の手続では、登下校用端末上での画面操作は求めず、その日1回目の登下校登録は登校、2回目は下校というように自動判定する。 この自動判定は① 登下校用端末に実装すると正しく判定できないことがあるので、管理サーバ上に実装することにした。
登下校通知メールの送信がエラーになった場合は、新システムから生徒が所属する拠点の拠点長に通知する。 通知を受け取った拠点長は保護者メールアドレスを確認し、必要な対応を行う。
新システムの主要なファイルを表1に示す。
管理サーバの主要な機能を表2に示す。
〔上長からの指摘及び追加要望 〕 L課長が設計内容を上長に説明したところ、次のような指摘及び追加要望が出された。 ・生徒が生徒カードの持参を忘れた場合に、登下校代理登録機能を用いる方法では、一部の要望を実現できない。 ・メール送信エラー通知機能で、ある場合に通知すべき拠点を特定できない。 ・各拠点から、所属する全ての生徒の保護者に対して臨時休校のお知らせなどを一斉送信する機能を追加したい。本部からも、全拠点又は特定拠点の生徒の保護者に対して各種お知らせを一斉送信できるようにしたい。 ・模試や夏期講習などで、臨時で別の拠点の授業を受けることがある。 この際も登下校を管理し、登下校通知のメール送信もできるようにしたい。 生徒カードは通常の授業と同じものを使いたい。
〔新システムの設計変更〕
L課長は上長からの指摘及び追加要望を受け、次のような設計変更を行った。 ただし、登下校代理登録機能の指摘に関しては、本システムでの要望の実現は難しいと判断して対応を見送ることにした。
(1) メール送信エラー通知機能の修正
(省略)
(2) お知らせメール送信機能の追加
拠点長及び本部担当者の管理画面において、生徒の保護者に一斉にメール送信できるようにする。 拠点長の場合は自拠点に所属する全生徒が、本部担当者の場合は全拠点又は選択した拠点の全生徒が対象となる。 件名、本文を入力して送信ボタンを押すことで、対象となるメールアドレス全てにメールが送信される。 本機能の導入に当たり、②表2中のある機能を変更する。
また、③他の機能へ悪影響を与える懸念があるので、本機能では専用のメールサーバを新たに導入することにした。
(3) 別拠点への登下校への対応
登下校履歴ファイルに、実際に登下校した拠点を示す “拠点コード” 属性を追加する。この属性には、登下校登録機能では登下校用端末から受け取った拠点コードを設定し、登下校代理登録機能では拠点長が自拠点の拠点コードを設定する。 また、これらの機能のほかにも④二つの機能を変更する。
登下校用端末は、生徒カード番号と撮影した写真に加えて、設定されている拠点コードを管理サーバに送信するように修正する。
設問1:
設計について、本文中の下線①はどのような場合に起こるか。30字以内で答えよ。
模範解答
登校時と下校時で別の登下校用端末を使用した場合
解説
解答の論理構成
- 複数端末運用の前提
「生徒数が多い拠点では、登下校用端末を複数設置してどの端末でも登下校の手続ができるようにする。」 - 端末とサーバの役割分担
「登下校用端末が管理サーバから受け取る情報は、依頼した処理の成功又は失敗だけ」とあり、端末は履歴を保持しません。 - 自動判定の仕組み
登下校登録機能では「当日の記録件数で“登校”または“下校”を判定」。 - 端末実装の問題点
端末に判定ロジックを置くと、端末Aで“登校”した履歴を端末Bは知らないため、下校時に0件と判断し再度“登校”と誤判定します。 - したがって
「① 登下校用端末に実装すると正しく判定できない」のは「登校時と下校時で別の登下校用端末を使用した場合」と結論付けられます。
誤りやすいポイント
- 端末の再起動・通信断が原因だと早合点する
実際は“端末間で履歴を共有しない”ことが本質です。 - 「複数拠点利用」と混同する
問題は同一拠点内の複数端末でも発生します。 - サーバ参照で即解決と考えず、端末仕様(履歴非保持)を読み落とす
FAQ
Q: 端末がサーバに毎回問い合わせれば誤判定は防げますか?
A: 可能ですが、要件として「端末からは管理サーバ内のファイルにはアクセスしない」とあるため採用されていません。
A: 可能ですが、要件として「端末からは管理サーバ内のファイルにはアクセスしない」とあるため採用されていません。
Q: 同じ端末を使っても誤判定するケースはありますか?
A: 原則ありません。ただし日付変更後に連続処理するなど、当日件数カウントの前提が崩れる場合は注意が必要です。
A: 原則ありません。ただし日付変更後に連続処理するなど、当日件数カウントの前提が崩れる場合は注意が必要です。
関連キーワード: 分散処理、一貫性、状態管理、ステートレス
設問2:〔上長からの指摘及び追加要望〕について答えよ。
(1)上長からの指摘及び追加要望について答えよ。登下校代理登録機能を用いる方法では実現できない要望を25字以内で答えよ。
模範解答
登下校通知メールに写真を添付する要望
解説
解答の論理構成
- 写真添付という要望の把握
- 【問題文】拠点長要望
「保護者が生徒の顔を見て安心できるように、登下校を通知するメール(以下、登下校通知メールという)には登下校時に撮影した写真を添付したい。」
- 【問題文】拠点長要望
- 写真を撮影する条件
- 【問題文】登下校用端末の仕様
「生徒が生徒カードをかざすとフロントカメラがQRコードを認識し、その時点の映像を生徒の顔や QRコードを含む写真として撮影する。」
⇒ カード読み取りが撮影トリガ。
- 【問題文】登下校用端末の仕様
- 代理登録機能の仕様確認
- 【問題文】表2「登下校代理登録」機能
「カードを持っていない場合、手動で履歴登録を行う機能。」「拠点長が手動で情報を入力し、履歴ファイルに登録。」
⇒ 撮影や写真送信の処理はなし。
- 【問題文】表2「登下校代理登録」機能
- 上長の指摘
- 【問題文】上長指摘
「生徒が生徒カードの持参を忘れた場合に、登下校代理登録機能を用いる方法では、一部の要望を実現できない。」
⇒ 実現できない要望=写真添付。
- 【問題文】上長指摘
- 結論
よって問われている「登下校代理登録機能を用いる方法では実現できない要望」は
「登下校通知メールに写真を添付する要望」となる。
誤りやすいポイント
- 代理登録でもカメラが使えると勘違いし、要望を「手続をスムーズに」と答えてしまう。
- 問題文中の「メール送信遅延を防ぎたい」「在室人数を把握したい」と取り違える。
- 「25字以内」という制約に気を取られ、原文の語句を改変してしまう。
FAQ
Q: 代理登録時に別途写真を撮れば要望は満たせるのでは?
A: 設計上、代理登録は「拠点長が手動で情報を入力」するだけで撮影処理が実装されておらず、追加開発がない限り実現不可です。
A: 設計上、代理登録は「拠点長が手動で情報を入力」するだけで撮影処理が実装されておらず、追加開発がない限り実現不可です。
Q: 「登下校通知メール受信有無」が“無”の場合は写真要望が関係ありますか?
A: ありません。“無”のときはメール自体送信されないため、写真添付も不要です。写真要望は“有”の場合の機能です。
A: ありません。“無”のときはメール自体送信されないため、写真添付も不要です。写真要望は“有”の場合の機能です。
関連キーワード: QRコード認識、フロントカメラ、一斉メール配信、主キー、ファイル設計
設問2:〔上長からの指摘及び追加要望〕について答えよ。
(2)メール送信エラー通知機能で通知すべき拠点を特定できないのはどのような場合か。40字以内で具体的に答えよ。
模範解答
保護者メールアドレスが同一の複数の生徒が、別々の拠点に所属している場合
解説
解答の論理構成
- 仕様の確認
【問題文】表2「メール送信エラー通知」に“宛先メールアドレスが一致する生徒の情報をもとに、該当の拠点長へ通知する。”と明記。 - 想定される処理フロー
・メール送信失敗
・失敗した宛先=保護者メールアドレスで生徒マスター検索
・該当生徒の所属拠点コードを取得 → 拠点長へ通知 - 矛盾の発生点
同じ保護者メールアドレスが複数生徒に共有されていると、検索結果が複数行になる。さらに“兄弟姉妹で入会する生徒も多いが、それぞれが別の拠点に所属する場合もある。”との業務要件があり、拠点コードが複数返る。 - 帰結
拠点長を一意に決定できず、通知すべき拠点が特定不能。したがって、問題の問いに対する具体的状況は「保護者メールアドレスが同一の複数の生徒が、別々の拠点に所属している場合」となります。
誤りやすいポイント
- 「生徒番号」は主キーなので重複しないと誤認し、メールアドレスも一意と勘違いする。
- 兄弟で同拠点に通うケースだけを想定し、拠点特定問題が起きないと判断してしまう。
- 「メール送信エラー通知」仕様を読み飛ばし、エラー通知は常に本部が行うと誤解する。
FAQ
Q: 生徒マスターにメールアドレスをユニーク制約で登録すれば問題は解決しますか?
A: 兄弟姉妹で同一アドレスを使う現実的ニーズがあるため、一意制約を課すと業務要件と衝突します。別の通知ロジック改善が必要です。
A: 兄弟姉妹で同一アドレスを使う現実的ニーズがあるため、一意制約を課すと業務要件と衝突します。別の通知ロジック改善が必要です。
Q: 拠点長を複数名宛で通知すればよいのでは?
A: セキュリティや責任所在の観点から適切な単一拠点長への通知が望ましく、無差別同報は運用混乱を招く恐れがあります。
A: セキュリティや責任所在の観点から適切な単一拠点長への通知が望ましく、無差別同報は運用混乱を招く恐れがあります。
関連キーワード: 主キー、一意制約、メール送信、検索条件、拠点コード
設問3:〔システムの設計変更〕について答えよ。
(1)システムの設計変更について答えよ。本文中の下線②について、変更する機能名を表2中から答えよ。また、どのような変更を行うのか。35字以内で答えよ。
模範解答
機能名:生徒情報管理
変更内容:全ての生徒の保護者メールアドレスを設定するように変更する。
解説
解答の論理構成
- 追加要件の把握
「拠点長及び本部担当者の管理画面において、生徒の保護者に一斉にメール送信できるようにする。」とある。対象は「全生徒」。 - 現仕様の確認
「保護者が登下校通知メールの受信を希望する場合は、登下校通知メール受信有無を “有” にし、保護者メールアドレスを設定する。」
→ “無” の場合はアドレスを登録しない仕様。 - 矛盾点
アドレス未登録の生徒がいれば一斉送信で漏れが発生。 - 必要な修正
アドレス登録を必須に変えるのはデータ入力を担う「生徒情報管理」機能。 - したがって
②で変更する機能は「生徒情報管理」、変更内容は「全ての生徒の保護者メールアドレスを設定するように変更」となる。
誤りやすいポイント
- 「登下校通知メール送信」を変更すると判断しがちだが、メール送信機能は専用サーバ導入で新設されるため根本原因とずれる。
- 登下校通知の受信可否フラグを廃止すると考えると仕様衝突を招きやすい。フラグは存続し、データ登録ルールだけを緩和すると理解する。
- 「メール送信エラー通知」機能を修正対象に誤選択するケースも多い。
FAQ
Q: フラグが “無” の場合でもメールを送るのですか?
A: いいえ。フラグは登下校通知メールの可否を示すまま残します。一斉配信は別機能なので、メールアドレスは必要でも配信可否は機能ごとに判定します。
A: いいえ。フラグは登下校通知メールの可否を示すまま残します。一斉配信は別機能なので、メールアドレスは必要でも配信可否は機能ごとに判定します。
Q: 既存データにアドレスが無い生徒はどうしますか?
A: 機能変更後にデータ補正を行い、保護者への確認を経てアドレスを登録します。運用手順も合わせて整備します。
A: 機能変更後にデータ補正を行い、保護者への確認を経てアドレスを登録します。運用手順も合わせて整備します。
Q: “保護者メールアドレス” を複数登録したい場合は?
A: 今回の設計変更では単一のアドレスを前提としています。複数対応はテーブル設計拡張や別テーブル追加が必要です。
A: 今回の設計変更では単一のアドレスを前提としています。複数対応はテーブル設計拡張や別テーブル追加が必要です。
関連キーワード: マスターデータ、一斉メール、データ入力制御、システム要件変更
設問3:〔システムの設計変更〕について答えよ。
(2)本文中の下線③で懸念したのはどのような悪影響か。20字以内で答えよ。
模範解答
登下校通知メールの送信が遅延する。
解説
解答の論理構成
- 追加された機能
「拠点長及び本部担当者の管理画面において、生徒の保護者に一斉にメール送信できるようにする。」 - 負荷の発生
一斉送信=多数メールを短時間で処理するためサーバ・ネットワーク負荷が急上昇。 - 既存機能の要求
表2「登下校通知メール送信」には「性能を考慮し一括送信しても遅延なく対応可能。」とあり、“即時送信”が品質要件です。 - 懸念の具体化
同一サーバで一斉送信を行うと「登下校通知メール送信」のキューが詰まり、【遅延】が発生する。 - 対処策
だから本文は「専用のメールサーバを新たに導入」──遅延を防ぐための分離設計。 - 以上より、「③」は「登下校通知メールの送信が遅延する。」となります。
誤りやすいポイント
- 「メール送信エラーが増加する」と解釈し遅延を見落とす。
- 「在室人数表示」などメール以外の機能と結び付けてしまう。
- 「メール送信サーバがダウンする」と詳細に踏み込み過ぎ、設問が求める20字以内の“悪影響”を超えてしまう。
FAQ
Q: 一斉送信で実際にどの程度遅延が起きるのですか?
A: 同報数や帯域に依存しますが、ピーク時に数百〜数千通を送るとキューが滞留し、秒単位で届くはずの通知が数分後になるケースもあります。
A: 同報数や帯域に依存しますが、ピーク時に数百〜数千通を送るとキューが滞留し、秒単位で届くはずの通知が数分後になるケースもあります。
Q: 専用メールサーバ以外の対策はありますか?
A: 優先度付きキューやスケジューラで「登下校通知メール」を最優先にし、「お知らせメール」は低優先度にする方法もありますが、実装複雑化と障害ポイント増加のデメリットがあります。
A: 優先度付きキューやスケジューラで「登下校通知メール」を最優先にし、「お知らせメール」は低優先度にする方法もありますが、実装複雑化と障害ポイント増加のデメリットがあります。
関連キーワード: SMTP, キューイング、スループット、同報送信
設問3:〔システムの設計変更〕について答えよ。
(3)本文中の下線④について、変更する機能名を表2中から二つ答えよ。また、それらの機能概要をどのように変更するのか。それぞれ40字以内で具体的に答えよ。
模範解答
①:機能名:登下校通知メール送信
変更内容:拠点名を登下校履歴ファイルの拠点コードから取得するように変更する。
②:機能名:拠点在室人数表示
変更内容:登下校日時が当日で、拠点コードが自拠点のものを抽出するように変更する。
解説
解答の論理構成
- 問題文の追加仕様
「登下校履歴ファイルに、実際に登下校した拠点を示す “拠点コード” 属性を追加」 - 影響分析
a. メール本文に表示する拠点名は、これまで「生徒が所属する拠点」のみだった。
b. 在室人数表示は「登校の件数 − 下校の件数」を自拠点に限定して計算していた。 - 必要な修正
a. 登下校通知メール送信
「通知対象である場合のみ送信」の時点で本文生成を行うため、取得元を履歴の拠点コードへ切替える。
b. 拠点在室人数表示
抽出条件に自拠点コード=履歴の拠点コードを追加しないと、別拠点の登下校が混入する。 - 40字以内での変更内容
- 登下校通知メール送信:
「メール本文の拠点名を履歴の拠点コードから参照する。」 - 拠点在室人数表示:
「自拠点コードで当日登校‐下校件数を集計する。」
- 登下校通知メール送信:
誤りやすいポイント
- 生徒マスターの拠点コードを使い続けてしまい、実際に登下校した拠点と食い違う。
- 在室人数表示機能を修正対象から漏らし、他拠点の人数が計上される。
- 40字以内指定を意識せず冗長に書いて減点される。
FAQ
Q: 生徒が所属拠点以外で登下校した場合、保護者メールはどの拠点名で届きますか?
A: 変更後は「登下校履歴」の拠点コードに基づく拠点名が表示されます。
A: 変更後は「登下校履歴」の拠点コードに基づく拠点名が表示されます。
Q: 在室人数表示機能のSQLはどう変わるイメージですか?
A: WHERE 句に「拠点コード = :自拠点」条件を追加して当日分を抽出し、SUM(CASE WHEN …) で集計します。
A: WHERE 句に「拠点コード = :自拠点」条件を追加して当日分を抽出し、SUM(CASE WHEN …) で集計します。
Q: 他機能への悪影響とは具体的に何ですか?
A: 一斉送信で大量メールが発生し登下校通知が遅延するリスクがあるため、専用メールサーバを導入しています。
A: 一斉送信で大量メールが発生し登下校通知が遅延するリスクがあるため、専用メールサーバを導入しています。
関連キーワード: QRコード、履歴管理、メール送信、集計処理


