令和6年度春期 システムアーキテクト 午後Ⅰ 問3

判断の基準となる前提をそろえる

整合性を検討するときは、判断の基準となる前提をそろえることに注目しましょう。記載されている条件と自分で補った想定を区別し、同じ前提に立って考えているかを、結論を急がずに確かめてください。

この問題で問われていること

着目するのは、考える過程で前提がすり替わっていないかという点です。ある内容を解釈する際に置いた前提を、別の内容を考える際にも保っているか振り返り、明示された条件の範囲で検討を進めましょう。

視点

前提とは、検討の土台として置く条件です。明示された条件と自分の想定を混ぜると、判断の基準が途中で変わることがあります。気になる箇所では、何を前提に考えたのかを言葉にして整理しましょう。

確認ポイント

• 判断の前提は、明示された条件に基づいているか
• 自分で補った想定を、記載された条件と混同していないか
• 検討の途中で、判断の前提を変えていないか

解説

複数端末での登下校判定、写真やメールアドレスの取得条件、一斉送信による遅延、別拠点への登下校に伴う検索条件の変更を検討する問題です。各機能が参照する情報を追い、要望と設計の不一致を具体的に説明することが要点です。

問題の全体像

全国約200拠点を持つ学習塾が、生徒カードのQRコードを読み取り、登下校履歴の登録と写真付きメールの送信を行うシステムを導入する事例です。管理サーバで情報を一元管理し、複数の登下校用端末や管理画面から機能を利用します。設問では、当初設計の不足を読み取り、一斉送信や別拠点への登下校という追加要望に対応するための変更を検討します。公式の出題趣旨では、業務要件と連携する情報を正しく理解して機能を設計する能力、既存機能への影響を考慮して指摘事項や追加要望に対応する能力を問うとされています。表2の各機能について、受け取る情報、参照するファイル、判定や抽出の条件を追うことが解答の基礎になります。

設問1

着目するのは、生徒数の多い拠点には複数の登下校用端末を設置することと、端末が管理サーバから受け取る情報は処理の成功又は失敗だけという記述です。登下校区分は、その生徒の当日の登録件数が偶数なら登校、奇数なら下校と判定します。登校時と下校時に異なる端末を使うと、下校時の端末は別端末で行われた登校登録を把握できず、正しく判定できません。そのため、全端末からの履歴を一元管理する管理サーバで判定します。公式解答例では「登校時と下校時で別の登下校用端末を使用した場合」としています。30字以内の答案では、登校時と下校時に使用する端末が異なるという条件を押さえます。

設問2(1)

表2で、登下校登録機能と登下校代理登録機能がメール送信機能へ渡す情報を比較します。通常の登録では、履歴情報と端末で撮影した写真を渡します。一方、代理登録では拠点長が生徒番号を入力して履歴を登録し、その履歴情報だけを渡すため、写真を添付するための情報がありません。メール送信機能も、呼出し元から写真が渡された場合に写真を添付する設計です。公式解答例では「登下校通知メールに写真を添付する要望」としています。25字以内では、実現できない要望として写真の添付を明示します。

設問2(2)

メール送信エラー通知機能は、エラーメッセージの宛先メールアドレスを生徒マスターの保護者メールアドレスと照合し、一致した生徒の所属拠点へ通知します。ここで、兄弟姉妹が別々の拠点に所属する場合があるという業務の記述が関係します。同じ保護者メールアドレスが異なる拠点の複数生徒に登録されていると、宛先メールアドレスだけでは、どの所属拠点に通知すべきか特定できません。公式解答例では「保護者メールアドレスが同一の複数の生徒が、別々の拠点に所属している場合」としています。40字以内では、メールアドレスが同一であることと、所属拠点が異なることの両方が必要です。採点講評では、臨時で別拠点の授業を受ける場合と誤って解答した例が多かったとされており、実際の登下校先ではなく、照合結果が複数拠点にまたがる点を読み取ります。

設問3(1)機能名

お知らせメールは、対象拠点に所属する全生徒の保護者へ送信する追加機能です。表2の生徒情報管理では、登下校通知メールの受信を希望しない保護者のメールアドレスは設定しない設計になっています。このままでは全生徒の保護者へお知らせを送るための宛先がそろいません。変更が必要なのは、メールアドレスを登録する条件を持つ機能です。公式解答例では「生徒情報管理」としています。採点講評でも、「登下校通知メール送信」と誤って解答した例が多かったとされており、追加機能に必要なデータをどの既存機能で用意するかを判断することが重要です。

設問3(1)変更内容

生徒情報管理の現行仕様では、登下校通知メールの受信希望がある場合だけ保護者メールアドレスを設定します。しかし、お知らせメールの対象は全生徒の保護者なので、登下校通知メールを希望しない保護者についても宛先を登録する必要があります。公式解答例では「全ての生徒の保護者メールアドレスを設定するように変更する。」としています。35字以内の答案では、登録対象を全生徒へ広げることと、登録する情報が保護者メールアドレスであることを明示します。

設問3(2)

表2の登下校通知メール送信には、メールサーバの仕様上、一度に大量に送信すると送信完了までに時間が掛かることがあると記載されています。当初は夕方のピーク時間帯に対応できる性能を確保していますが、追加のお知らせメールでは全拠点などを対象とした大量送信が発生します。同じメールサーバを利用すると、登下校通知メールの送信が遅れ、可能な限り早く通知したいという要望に影響します。公式解答例では「登下校通知メールの送信が遅延する。」としています。20字以内では、遅延する対象を登下校通知メールと具体的に示します。

設問3(3)①機能名

表2の登下校通知メール送信は、生徒マスターから取得した所属拠点の拠点コードで拠点名を取得し、メール本文へ記載する設計です。生徒が臨時に別拠点へ登下校すると、この方法では実際に到着又は退出した拠点と異なる拠点名を通知してしまいます。実際の登下校先をメール本文へ反映するため、この機能を変更します。公式解答例の一つ目の機能名は「登下校通知メール送信」です。

設問3(3)①変更内容

設計変更によって登下校履歴へ追加される拠点コードは、実際に登下校した拠点を示します。したがって、メール本文に使う拠点名は、生徒マスターの所属拠点コードではなく、通知対象の登下校履歴に記録された拠点コードを用いて取得します。公式解答例では、拠点名を登下校履歴ファイルの拠点コードから取得するように変更するとしています。40字以内の答案では「登下校履歴の拠点コードで拠点マスターを検索し、拠点名を取得する。」のように、参照する拠点コードの所在と取得する情報を明示します。

設問3(3)②機能名

表2の拠点在室人数表示は、当日の履歴から、自拠点に所属する生徒の履歴を抽出して人数を計算する設計です。別拠点への登下校を認めると、他拠点所属の生徒が自拠点に来る場合も、自拠点所属の生徒が他拠点に行く場合もあります。所属生徒を基準とする抽出では、実際に自拠点へ登下校した人数を正しく集計できなくなるため、この機能の変更が必要です。公式解答例の二つ目の機能名は「拠点在室人数表示」です。

設問3(3)②変更内容

変更の要点は、当日の履歴を抽出する条件に、登下校履歴の拠点コードが自拠点であるという条件を用いることです。これにより、所属先にかかわらず自拠点での登下校を集計でき、自拠点所属の生徒が別拠点へ登下校した履歴も集計対象から外せます。抽出した履歴の登校件数と下校件数の差が在室人数になります。公式解答例では、登下校日時が当日で、拠点コードが自拠点のものを抽出するように変更するとしています。40字以内の答案では「登下校日時が当日で、登下校履歴の拠点コードが自拠点の履歴を抽出する。」と条件を具体化します。採点講評では、「別拠点の生徒も抽出対象に加える」だけでは不十分とされており、登下校履歴の拠点コードを使うことが重要です。

学習のポイント

機能間で受け渡す情報と参照先を整理し、追加要望が登録条件・検索条件・処理性能へ及ぼす影響を読む力を養います。