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

模範解答の核心となるキーワードや論点整理

• キーワード：
  「登校時と下校時で別の登下校用端末を使用」「正しく判定できない」「管理サーバに実装する」
• 論点：
  登下校の自動判定機能が端末側にあると正しく機能しない場合がある理由
  → 複数の登下校用端末が拠点に設置され、生徒が登校、下校で別々の端末を使うと、判定用の履歴カウントが端末単位で分断されるため判定がずれる可能性が高い。

解答の理由と論理的説明

「この自動判定は① 登下校用端末に実装すると正しく判定できないことがあるので,管理サーバ上に実装することにした。」

• 各端末は、それぞれ独立して登下校履歴のカウントなどを持つ場合があると推察されます。
• 例えば、登校時に端末Aで手続きをし、下校時に端末Bを使用した場合、端末Bのカウント情報を端末Aが持たないと「当日履歴の件数を偶数/奇数で判定」できません。
• その結果、端末Bは「当日履歴が0（偶数）」として登校と誤判定する可能性があります。

多くの受験者が誤りやすいポイント

• 誤解1：端末ごとに独立して状態管理できると考える
  → 複数端末で一元管理しないと、生徒1人の登下校回数を正確に把握できない。
• 誤解2：写真やカード番号からだけで判定できると思う
  → 登下校区分「登校」「下校」は回数の偶奇性で決めているため、履歴情報が端末で分断されると判定を誤る。
• ひっかけがちな選択肢例：
  「写真の認識に問題がある」「メール送信の遅延」など判定ロジック以外の点に原因を誤認する。

試験対策として覚えておくべきポイント

• 複数端末で利用する場合は、状態管理や判定ロジックは中央管理サーバに集約することが多い。
• ロックや一意管理が難しい分散環境では、履歴をもとにした偶奇判定などの業務ロジックは端末よりもサーバ側で行うのが正しい設計。
• 状態が端末ごとに異なると、業務ルールの自動判定ミスが発生しやすい。
• 情報処理技術者試験の設問では、問題文の業務要件・設計思想から整合性を取ることが重要。

1. 模範解答の核心キーワード・論点整理

• 核心キーワード：「登下校通知メールに写真を添付する要望」
• 論点：
  • 生徒が生徒カードを忘れた場合の「登下校代理登録機能」は、写真を添付できない。
  • 新システムでは登下校用端末が写真を撮影し、管理サーバに送る仕組みだが、代理登録は管理画面で手動登録のため写真が無い。
  • よって、写真添付の登下校通知メールが送れない点が制約となっている。

2. なぜその解答になるのか（問題文の記述引用）

・登下校用端末では常時フロントカメラが動作している。生徒が生徒カードをかざすと…写真を撮影し管理サーバに送信する…
・登下校代理登録機能は拠点長が管理画面にログインして手動で登下校履歴を登録する機能…写真は渡さず登下校通知メール送信を行う。

・生徒が生徒カードの持参を忘れた場合に,登下校代理登録機能を用いる方法では, 一部の要望を実現できない。

登下校代理登録機能の指摘に関しては、本システムでの要望の実現は難しいと判断して対応を見送ることにした。

3. 受験者が誤りやすいポイント

• 代理登録で写真添付できない理由を見落とす
  代理登録は管理画面からの手作業であり、写真撮影や管理サーバへの写真データ送信がないことに注意が必要です。
• 生徒カードを忘れた時の「使える」意味の解釈違い
  「使えるシステムにしてほしい」という要望に関し、代理登録で登下校記録は可能でもメールに写真添付はできないため不完全です。
• 設計変更の記述を見逃す
  解決が見送られている旨は問題文にあり、ここを正しく理解しないと「写真添付も可能」と誤解しがちです。

4. 試験対策としてのまとめポイント

• システムの業務フローと実装範囲を正確に把握すること
  特に代理登録のような手動処理と自動処理の違いを理解し、写真やデータ連携の有無に注目する。
• 要望と対応可能範囲の照合を明確に
  要望の内容（例：写真添付）とシステムがどう対応しているか（自動か手動か、写真送信あり/なし）を対比すること。
• 設計変更や上長の指摘など、追加情報を見逃さないこと
  「対応を見送った」等の記述は重要な鍵になる場合が多い。
• ファイル構成や機能一覧は理解しておく
  管理サーバの機能やファイルデータの役割を輪郭をつかんでおくと、大枠の理解が深まる。

模範解答の核心となるキーワードや論点

• 保護者メールアドレスが同じ複数の生徒
• 複数の生徒が別々の拠点に所属している
• メール送信エラー通知機能で拠点の特定ができない

なぜその解答になるのか【問題文引用と論理的説明】

登下校通知メール送信の結果、メールサーバからエラーメッセージが返った場合に、
登下校した生徒が所属する拠点の拠点長に、メールがエラーになった旨を通知する機能。
・エラーメッセージに含まれる宛先メールアドレスを生徒マスターに設定されている保護者メールアドレスと照合し、
一致した生徒が所属する拠点の拠点長にメール送信がエラーになった旨を通知する。

・メール送信エラー通知機能で, ある場合に通知すべき拠点を特定できない。

• 「生徒マスター」からは複数の生徒番号が該当する
• それぞれの生徒番号の拠点コードは異なるため
• どの拠点に通知すべきか判断ができなくなる

受験者が誤りやすいポイントやひっかけの選択肢

• 保護者メールアドレスがユニーク（一意）である前提で考える誤り
  受験者は「メールアドレスは一人の保護者に1つずつ割り当てられる」と考えることがありますが、問題文には「兄弟姉妹で入会する(... )それぞれが別の拠点に所属する場合もある」とあり、同一メールアドレスが複数生徒に登録されている可能性が高いです。
• 単に「メールアドレスが間違っている」「メールサーバの障害」といった理由で拠点特定不能と誤解する
  問題文はエラー通知機能の拠点特定の困難さに言及しており、技術的なメールアドレスの重複に絡む運用上の問題を問うています。

試験対策として覚えておくべきポイントや知識

1. マスター情報における一意性の理解
   • 生徒番号、生徒カード番号は一意だが、保護者メールアドレスは必ずしも一意でない場合があることに注意しましょう。
2. メール送信エラー通知の仕組みと課題
   • メールエラー発生時は送信先メールアドレスから対象を特定するが、メールアドレスが複数登録されている場合、どの拠点に通知すべきか特定できない問題が生じる。
3. 業務上の取扱いの注意点
   • 兄弟姉妹が別々の拠点所属でも同じ保護者メールアドレスを使うことは実際にあり得るため、システム設計や運用で考慮する必要がある。
4. 出題パターンの把握
   • システム設計の「例外ケース」に関する指摘は午後1試験でよく出題される。メール送信や通知機能に関する例外処理問題は類似問題も多く、しっかり理解しましょう。

まとめ

模範解答の核心となるキーワードや論点

• 変更する機能名: 生徒情報管理
• 変更の理由: 一斉送信機能の対応に伴い、「全ての生徒の保護者メールアドレスを設定するように変更する」
• 関連箇所: 追加された「お知らせメール送信機能」では、「拠点長及び本部担当者が対象生徒の保護者に一斉メール送信」するため対象のメールアドレスが必要

なぜその解答になるのか【論理的説明】

・各拠点から，所属する全ての生徒の保護者に対して臨時休校のお知らせなどを一斉送信する機能を追加したい。
・本部からも，全拠点又は特定拠点の生徒の保護者に対して各種お知らせを一斉送信できるようにしたい。

(2) お知らせメール送信機能の追加
・拠点長及び本部担当者の管理画面において，生徒の保護者に一斉にメール送信できるようにする。
・拠点長の場合は自拠点に所属する全生徒が，
・本部担当者の場合は全拠点又は選択した拠点の全生徒が対象となる。
・件名，本文を入力して送信ボタンを押すと対象メールアドレス全てに送信される。
・本機能の導入にあたり，②表2中のある機能を変更する。

・全ての生徒の保護者メールアドレスを設定するように変更する。

「全ての生徒の保護者メールアドレスを設定するように変更する」

受験者が誤りやすいポイント・ひっかけ

• 間違いやすい機能名の選択:
  「お知らせメール送信機能」を新設したことにより「その機能が対象では？」と誤解しやすい。
  しかし問題文で「②は表2中のある機能を変更」とあり、その中に「お知らせメール送信機能」は入っていません。
  表2に未記載なので「お知らせメール送信機能」は対象外。
• 変更内容の曖昧さ:
  「登下校通知メール受信有無」属性があるにもかかわらず、「全保護者メールアドレスを設定せよ」とは直接明記されていないので見落としやすいです。
  しかし一斉送信ではメールアドレス必須なので、「メール受信しない保護者にもメールアドレスを登録する」変更が必須であることを理解する必要があります。
• 本部と拠点長の違い:
  両者に一斉配信機能があるため、その対象範囲が異なる点に注意すべき。
  これを混同して、「生徒カード発行」など別の機能や改変対象機能を疑う点に注意。

まとめ：試験対策として覚えておくべきポイント

• 新機能追加時のマスター管理対応の重要性
  新たに「一斉メール送信」が追加される場合、メールアドレスが未登録の保護者に対してもきちんと情報を登録・管理することが必須。
• 属性設計と業務要件の整合性チェック
  既存の「登下校通知メール受信有無」属性を見て、それに依存した設計だとメール送信の新要件を満たせないことがある。
• 表中の機能と設問文の対応関係をきちんと把握する
  「表2にある機能か、追加機能か、その他か」を整理しておくと誤答を防げる。
• 要望と設計変更の因果関係を理解する訓練
  追加要望の実現が、どの機能のどの仕様変更に該当するか説明できることが重要。

模範解答の核心となるキーワードや論点の整理

• 悪影響の内容：メール送信の遅延
• 対象の機能：登下校通知メールの送信機能（表2の「登下校通知メール送信」機能）
• 懸念の背景：新たに追加される「お知らせメール送信機能」が同一メールサーバを使うことでリソースを圧迫し、既存の通知メール送信に影響を与える可能性
• 変更に伴う影響：ピーク時間帯の送信性能確保が難しくなる

なぜその解答になるのか【論理的説明】

・お知らせメール送信機能の追加
… 負荷増加に伴い、③他の機能へ悪影響を与える懸念があるので、本機能では専用のメールサーバを新たに導入することにした。

メールサーバの仕様上、一度に大量に送信すると送信完了までに時間が掛かることがあるが、夕方のピーク時間帯でも問題ない程度の性能を確保する。

• 「お知らせメール送信機能」は対象となる生徒の保護者全員に一斉送信するため、大量のメール送信が想定される。
• もし同じメールサーバでこのお知らせメールと、タイムリーに送る必要がある「登下校通知メール」を送信すると、
• 「お知らせメール送信」の大量処理がメールサーバの負荷となって「登下校通知メール送信」を遅延させてしまう恐れがある。
• これが悪影響として懸念されたため、専用のメールサーバを追加導入して負荷分散し、遅延防止を図った。

受験者が誤りやすいポイントやひっかけ

• 「遅延」ではなく「送信失敗」や「誤送信」と答えてしまうケース
  → 本文では「送信が遅延すると保護者に不安を与える」と明記されており、エラー（失敗）とは区別されています。
• 「メールの重複送信」や「誤った宛先送信」などの配送ミスと混同する
  → 追加要望で拠点や対象が増えることはありますが、悪影響としては負荷による遅延が焦点です。
• 「お知らせメールが届かないこと」と捉える誤解
  → ここで懸念されているのは、登下校通知メールの遅延です。お知らせメールの送信については専用のメールサーバ導入で対処されます。

試験対策として覚えておくべきポイント

1. 負荷分散の重要性
   大量メール送信とリアルタイム通知メールの混在は性能劣化の原因。専用サーバ導入などの分散処理が必要。
2. メール送信遅延が保護者の不安につながる点の理解
   即時通知を求められる業務システムで遅延は大きな問題となる。
3. 機能追加による既存機能への影響を検討する視点
   新機能拡張時は必ず既存システムへのパフォーマンスや運用影響を考慮すること。
4. 要件や指摘文から「悪影響」の具体的内容を読み取る能力
   設問では20字以内の簡潔回答が求められるため、核心を押さえた解答が重要。

模範解答の核心キーワード・論点整理

• 「登下校履歴ファイル」に拠点コード属性が新設され、これを活用する変更
• 拠点をまたぐ登下校に対応し、正確な拠点情報を元にメール通知・人数表示を行うことが目的
• 変更は登下校履歴ファイルの拠点コードを正しく利用するための修正

解答になる理由の論理的な説明

1. 設計変更に関する本文の記述（抜粋）

   (3) 別拠点への登下校への対応
   登下校履歴ファイルに, 実際に登下校した拠点を示す “拠点コード” 属性を追加する...
   また,これらの機能のほかにも④二つの機能を変更する。
   …
   登下校通知メール送信機能：メール本文中の拠点名取得元を、拠点コードから取得するよう修正が必要
   拠点在室人数表示機能：当日データ抽出時に拠点コード条件を加える必要あり

2. 登下校通知メール送信機能の変更理由
   • 登下校通知メール本文には「（生徒氏名）が（登下校日時）に（拠点名）に到着（又は退出）しました」と記述される。拠点名は従来「生徒マスターの拠点コード」から取得していたが、
   • 新設の拠点コードは「実際に登下校した拠点」を示すため、メール本文で誤った拠点名を通知しないよう、
   • 登下校履歴ファイルの拠点コードを基に拠点名を取得する必要がある。
3. 拠点在室人数表示機能の変更理由
   • 拠点長は自拠点にいる生徒数を管理画面で把握するが、
   • 生徒が別拠点で登下校するケースが増えたため、
   • 単に「生徒の拠点コード」ではなく「登下校履歴ファイルの拠点コード」と「当日のもの」のデータを条件に加えることで、
   • 現在在室している生徒を正確にカウントできるようにする必要がある。

受験者が誤りやすいポイント・ひっかけの注意点

• 「拠点名を取得する箇所」の混同
  生徒マスターの拠点コードから拠点名を取得していた関数を変更し、新設拠点コードから取得する点を区別する必要がある。
  誤って従来の生徒の所属拠点コードから取得すると、別拠点登下校時に誤った拠点名が通知されてしまう。
• 拠点単位の在室人数カウントの条件の見落とし
  従来は生徒マスターの拠点コードで判定していたが、改修後は履歴ファイルの拠点コードも条件に入れるため、
  拠点長が見たいのは「その拠点で登録された登下校履歴」だと理解すべきである。
• 登下校履歴ファイルの拠点コード追加の影響範囲の認識
  変更指示は二つの主要な機能のみであるが、他の機能での対応は記述されていない点に注意。
  問題文にある「④二つの機能」の具体的変更箇所を正しく特定しなければならない。
• 「②表2中のある機能を変更する」との別指示と混同しないこと
  同じく設計変更に関する指示が複数あり混同しやすいので、
  問題で問われている「④二つの機能」変更は何かを明確化して取り組む必要がある。

試験対策として覚えておくべきポイント・知識

• システム設計変更時の影響範囲把握
  追加属性の導入は、関連のDB検索やデータ処理に影響を及ぼすため、関連機能全てに展開されることを理解する。
  変更対象機能を正しく洗い出し、要望に沿った修正内容を明確に説明できる能力が重要。
• 拠点コード（ロケーションコード）活用に関する運用設計
  生徒が所属拠点と異なる場所で登下校するケースにどう対応するかは、
  登下校履歴に「実際の登下校場所」を示す拠点コードを設けるという典型的な設計変更である。
  これに伴うメール通知や人数カウントの仕様見直しも一連の流れとして覚える。
• メール送信機能の設計変更時の注意点
  ・メール送信の宛先選択や本文生成に関わるデータソースの変更はよく問われる。
  ・拠点関連の情報は複数データマスターから取ることがあるため、正しい参照先を見極める。
• 問題文を踏まえた丁寧な要件理解
  ・本文中の「～することにした」「○○である」といった文章から変更要求や理由を正確に読み取り、
  ・それを要件仕様や設計説明に反映できることが合格に不可欠。