システムアーキテクト 2023年 午後1 問02
セミナー管理システムに関する次の記述を読んで、設問に答えよ。
ソフトウェアパッケージの開発・販売を行っているC社では、全国主要都市で自社製品の説明会を開催していたが、新たに無料のオンラインセミナーを開催することになり、それをサポートするセミナー管理システム（以下、新システムという）をWebシステムとして開発することになった。
〔セミナー管理業務の概要〕
C社のセミナー管理業務の概要は次のとおりである。
（1）セミナー登録企画担当者がセミナーを企画し、企画書を作成する。セミナーは、企画担当者のほか、講演資料を作成して講演を行う講師担当者及びセミナーの運営を行う運営担当者で担当する。企画・講師・運営の三つの担当役割について、それぞれ複数名の担当者を設定でき、一人の担当者が複数の担当役割を兼務する場合もある。一つの担当役割に複数名を設定した場合は、その中でリーダーを一人設定する。セミナーには、リソースのひっ迫を避けるために受講する人数について定員を設定している。企画書には、セミナー名、セミナー内容、定員、開催日時、終了時刻及び企画・講師・運営の各担当者の担当者IDと担当者名が記載されている。企画担当者は、作成した企画書を上長に提出し、承認を受けた後、実施予定セミナーとして登録する。
（2）募集・申込み企画担当者はセミナーの概要を募集画面に掲載して受講申込みを受け付ける。受講を希望する者は申込入力画面からセミナーを選択し、氏名、会社名、部署名、役職名、メールアドレスなどの情報を入力して申込みを行う。セミナーについて同一メールアドレスで申込みが重複しておらず、セミナーの定員に達していない場合は申込みを確定し、受講確定メールを受講申込者へ送付する。申込みはセミナー開催の3日前に締め切る。
（3）開催準備、開催案内運営担当者はセミナー開催の2日前にオンラインルームを開設し、アクセスURLとアクセスキーを決定する。運営担当者は受講申込者に開催案内メールを送信する。開催案内メールには、受講確定メールに記載した内容に加えて、アクセスURL及びアクセスキーが記載されている。企画担当者は、受講申込者に回答してもらうアンケートを作成する。
（4）受講受講申込者はセミナー開催当日にWebブラウザからアクセスURLにアクセスし、オンラインルームにログインしてセミナーを受講する。なお、受講申込者は多重ログインできない。
（5）アンケートセミナー終了後、運営担当者から受講申込者にアンケートURLが記載されたアンケートメールを送信する。受講申込者はアンケートURLにアクセスし、受講ID、氏名及び受講の有無を入力し、個別の設問に回答する。また、受講した者（以下、受講者という）はセミナーの評価点を10点満点の数字で入力し、受講しなかった者は受講しなかった理由を入力する。入力したアンケートの回答は変更できない。
（6）集計・分析企画担当者はアンケートの回答について、集計・分析を行った結果を上長に報告する。また、担当者の業務負荷確認のために、1か月ごとに担当したセミナーの数と担当役割を集計して上長に報告する。
〔新システムの概要〕
情報システム部のD課長は、業務の概要を基に新システムの設計を行った。
（1）セミナー登録セミナーの企画書を登録する機能。企画担当者が企画書の内容を入力すると、セミナー、セミナー担当の各ファイルにレコードを作成する。この時、セミナーに一意のセミナーIDを付与する。セミナー担当に登録する担当者IDは別システムで事前に付与されている。
（2）募集・申込み受講を希望する者からの申込みを受け付け、申込みの重複及び定員超過を判定し、受講を確定させる機能。申込判定がOKのときは申込確認画面を表示し、確定ボタンが押されたら受講を確定する。申込確認画面で、取消ボタンが押されたら申込入力画面に戻る。受講確定時に受講IDを発行し、受講申込ファイルにレコードを作成する。受講IDは、英数字8桁から成る一意のIDである。受講確定後、受講ID、セミナーID、セミナー名、開催日時、終了時刻及びセミナー内容を記載した受講確定メールを受講申込者へ送付する。
（3）開催準備、開催案内開設したオンラインルームのアクセスURLとアクセスキーをオンラインルームフアイルに登録し、受講申込者に開催案内メールを送信する機能、及びセミナー終了後に回答してもらうアンケート画面を作成する機能。開催案内メールには、受講確定メールに記載した内容に加えて、アクセスURL及びアクセスキーを記載する。
（4）受講受講を受け付ける機能。受講申込者はアクセスURLにアクセスし、開催案内メールにある受講ID及びアクセスキーを転記してオンラインルームにログインし、セミナーを受講する。ログイン時に受講ID及びアクセスキーのチェックを行い、受講ファイルにレコードを作成する。この時、受講受付日時に現在日時を設定する。
（5）アンケート対象者にアンケートメールを送信する機能、及びアンケート画面から入力された回答を基にアンケートファイルにレコードを作成する機能。
（6）集計・分析アンケートの回答の集計・分析、及び担当者の担当役割とセミナー数を集計する機能。D課長は、上記の概要を基に新システムのデータ設計を行い、主要なファイルを表1のように設計した。
また、新システムにおける募集・申込みの処理について、表2のように設計した。
〔指摘及び追加要望〕 D課長が設計内容を上長に説明したところ、次のような指摘及び追加要望が出された。 ・申込確認処理について、今のままでは確定ボタンを押した際に定員を超過する可能性がある。定員超過の際は、エラーとするよう変更してほしい。 ・今のログイン方式では、通信障害などで接続が切れた場合に再接続ができなくなる。接続が切れたことを検知した場合には、当該受講IDで再ログインができるようにしてほしい。 ・アンケートURLにアクセスした際に、入力画面で受講ID及び氏名を入力させるのではなく、あらかじめ受講ID及び氏名を埋め込んだページを開いて回答させるようにしたいので、個別のアンケートURLを送してほしい。 ・開催したセミナーの申込率、受講率及び平均評価点の三つの項目を一覧表示する機能を追加してほしい。ここで、申込率は定員に対する受講申込者数の割合、受講率は受講申込者数に対する受講者数の割合、平均評価点はアンケートに回答した受講者の評価点の平均点を示す。
〔新システムの設計変更〕
D課長は指摘及び追加要望を受け、次のような設計変更を行った。
・申込確認画面で確定ボタンが押されたときに再度申込判定の処理を行うようにし、エラーになった場合はエラーメッセージを表示して処理を終了する。また、確定ボタンを押してもエラーとなることがある旨を申込確認画面に表示する。
・受講ファイルに、接続フラグという属性を追加し、初期値として”1”を設定する。別途、接続が切れたことを検知した際に接続フラグに“0”を設定するようにする。その上で、再接続する際の①ログイン時の受講IDに関するチェック及び受講ファイルの更新処理を新たに追加する。
・セミナー終了後に受講申込者に送信するアンケートURLを、受講IDごとの個別のURLに変更する。これに伴って、②表1中のある属性を別のファイルに移す。
・セミナーファイルに、申込率、受講率及び平均評価点の属性を追加する。申込率、受講率及び平均評価点は、セミナーID及びセミナーIDから検索した受講IDを用いて表1の各ファイルを検索し、その結果を用いて、それぞれ、表3に示す計算式で求める。ただし、各計算式の除数が0のときは項目の値を0とする。
設問1：〔新システムの概要〕について答えよ。
（1）セミナー担当ファイルに主キーを設定する場合、主キーとするものを表1中の属性を用いて全て答えよ。
模範解答
セミナーID，担当役割、担当者ID
解説
解答の論理構成
- ファイル構造を確認
引用：【問題文】表1「セミナー担当」の主な属性セミナーID, 担当役割、担当者ID, リーダーフラグ - 業務ルールを整理
引用：【問題文】“三つの担当役割について、それぞれ複数名の担当者を設定でき、一人の担当者が複数の担当役割を兼務する場合もある。”
“一つの担当役割に複数名を設定した場合は、その中でリーダーを一人設定する。”
① 同じセミナーで同じ担当役割に複数の担当者が入り得る。
② 同じ担当者が別の役割にも就き得る。
③ リーダーフラグは役割内の序列を示すだけで、組合せの一意性を保証しない。 - 一意性判定
① 「セミナーID」だけ → 同じセミナー内で複数役割・複数担当者が存在し重複。
② 「セミナーID，担当役割」 → 同一役割内で複数担当者が存在し重複。
③ 「セミナーID，担当役割、担当者ID」 → 業務ルール上同一組合せは1件だけ。
したがって、この3項目を複合したときに初めて一意性を確保できます。 - 結果
主キー：セミナーID，担当役割、担当者ID
誤りやすいポイント
- リーダーフラグを主キーに含めてしまう
“1”と“g”は単なる区分値であり、同じ担当者に対し値が変更される可能性があるため主キー不適。 - 担当者ID単独で一意だと勘違い
同じ担当者が複数セミナー・複数役割を担当できるので不十分。 - 「担当役割＋担当者ID」で済むと考える
セミナーが異なれば同じ役割・同じ担当者の組合せが再登場するため不足。
FAQ
Q: リーダーフラグを追加した複合キーでも一意性は保てませんか？
A: 一意性は保てますが、主キーは“最小集合”にすべきです。リーダーフラグを含めなくても既に一意なので冗長です。
A: 一意性は保てますが、主キーは“最小集合”にすべきです。リーダーフラグを含めなくても既に一意なので冗長です。
Q: サロゲートキー（連番ID）を別に設けてもよいですか？
A: 技術的には可能ですが、設問は「表1中の属性を用いて」と限定しているため、自然キーを答える必要があります。
A: 技術的には可能ですが、設問は「表1中の属性を用いて」と限定しているため、自然キーを答える必要があります。
Q: 主キーを複合にするとパフォーマンスが落ちませんか？
A: インデックス設計や正規化の原則上、業務上の一意性を担保することが優先です。必要に応じ副索引を追加することでパフォーマンスは確保できます。
A: インデックス設計や正規化の原則上、業務上の一意性を担保することが優先です。必要に応じ副索引を追加することでパフォーマンスは確保できます。
関連キーワード: 正規化、複合主キー、一意性制約、自然キー、ファイル設計
設問1：〔新システムの概要〕について答えよ。
（2）表2中の(a)、(b)に入れる適切な字句を答えよ
模範解答
a：受講申込
b；メールアドレス
解説
解答の論理構成
- 重複チェックの仕様確認
- 【問題文】“セミナーについて同一メールアドレスで申込みが重複しておらず”
⇒ 重複判定は「メールアドレス」をキーに行うと読み取れます。
- 【問題文】“セミナーについて同一メールアドレスで申込みが重複しておらず”
- 対象ファイルの特定
- 表1「受講申込」ファイルの主な属性に “メールアドレス” が含まれ、申込みデータを保持している。
- したがって重複確認時に検索すべきファイルは「受講申込」。
- 置換箇所への適用
- 表2「申込判定（重複）」の文脈
“当該セミナーIDで、(a)ファイルを検索し、入力された(b)と同じ(b)が存在すればエラー” - (a) は「受講申込」、(b) は「メールアドレス」として整合が取れる。
- 表2「申込判定（重複）」の文脈
- 結論
- (a)＝受講申込、(b)＝メールアドレス。
誤りやすいポイント
- 申込入力画面で入力する項目をそのままファイル名と誤解し、(a) に「セミナー」などを入れてしまう。
- メールアドレス以外の個人情報（氏名や受講ID）で重複チェックすると読み違える。
- 表1と表2の対応を確認せず、業務フローだけで推測してしまう。
FAQ
Q: 重複判定に受講IDを使わないのはなぜですか？
A: 受講IDは「受講確定時に発行」されるため、申込判定の段階ではまだ存在しません。既存データと比較できる唯一のキーがメールアドレスです。
A: 受講IDは「受講確定時に発行」されるため、申込判定の段階ではまだ存在しません。既存データと比較できる唯一のキーがメールアドレスです。
Q: セミナーIDも同じメールアドレスでなければ重複扱いですか？
A: はい。【問題文】にある通り「当該セミナーIDで」検索するので、セミナーが異なれば同じメールアドレスでも重複とはなりません。
A: はい。【問題文】にある通り「当該セミナーIDで」検索するので、セミナーが異なれば同じメールアドレスでも重複とはなりません。
Q: 氏名が同じ場合は重複エラーにならないのですか？
A: 氏名は判定条件に含まれていません。メールアドレスを重複キーにする理由は唯一性と入力ミスの少なさが背景にあります。
A: 氏名は判定条件に含まれていません。メールアドレスを重複キーにする理由は唯一性と入力ミスの少なさが背景にあります。
関連キーワード: データベース設計、主キー、排他制御、入力バリデーション、ファイル検索
設問2：
〔指摘及び追加要望〕について、申込確認処理で、確定ボタンを押した際に定員を超過するのはどのような場合か。40字以内で答えよ。
模範解答
申込確認画面が表示されている間に他者の申込みが確定されて定員に達した場合
解説
解答の論理構成
- まず【問題文】表2「申込判定（定員）」では、
「受講申込ファイルのレコード件数がセミナーファイルの定員以上のときは…処理を終了」
とし、OKなら「申込確認画面を表示」します。 - しかし確定ボタンを押す処理は、同じ表2の「申込確認」に記載された別ステップで実行されます。
- 【指摘及び追加要望】では、
「申込確認処理について、今のままでは確定ボタンを押した際に定員を超過する可能性がある」
と明示されており、申込判定後〜確定ボタン押下までの間に他者がレコードを登録すると、定員チェックをすり抜けることになります。 - したがって「申込確認画面が表示されている間に他者の申込みが確定されて定員に達した場合」が定員超過となる状況であり、模範解答につながります。
誤りやすいポイント
- 「申込判定（定員）」だけで完全に防げると考え、確定時の再チェックを忘れる。
- 申込確認画面表示直後の“保留”状態を意識せず、同時実行問題を見落とす。
- 定員超過の原因を「同一メールアドレス重複」と混同してしまう。
FAQ
Q: 申込判定を行った時点でロックを掛ければ良いのでは？
A: ロック時間が長くなると他利用者の待ち時間が増え、Webシステムでは実装・運用が難しいため、確定時に再チェックする設計に変更しました。
A: ロック時間が長くなると他利用者の待ち時間が増え、Webシステムでは実装・運用が難しいため、確定時に再チェックする設計に変更しました。
Q: 受講ID発行前に定員超過が分かったらどう処理される？
A: 追加設計では「確定ボタンが押されたときに再度申込判定…エラー」とし、エラーメッセージを返して申込みを完了させません。
A: 追加設計では「確定ボタンが押されたときに再度申込判定…エラー」とし、エラーメッセージを返して申込みを完了させません。
関連キーワード: 排他制御、同時実行制御、レースコンディション、トランザクション管理
設問3：〔新システムの設計変更〕について答えよ。
（1）本文中の下線①について、受講IDに関するチェックの内容を40字以内で、受講ファイルの更新処理の内容を30字以内で答えよ。
模範解答
チェック：当該受講IDの受講ファイルの接続フラグが “0” のときはエラーとしない。
更新処理：受講ファイルの接続フラグに “1” を設定して更新する。
解説
解答の論理構成
- 状態管理の前提を確認
- 「受講ファイルに、接続フラグという属性を追加し、初期値として”1”を設定」「接続が切れたことを検知した際に接続フラグに“0”を設定」とある。
- よって “1” は接続中、“0” は切断を示す。
- チェックの目的を抽出
- 「再接続する際の①ログイン時の受講IDに関するチェック」を新設。
- 目的は多重ログイン防止と切断後の再ログイン許可の両立。
- チェック内容を導出
- “1” のときは既に接続中なのでエラー扱い。
- “0” のときは切断済みなので再ログインを許可（エラーとしない）。
- 更新処理を導出
- 再ログインが成功したら状態を接続中に戻す必要があるため、「接続フラグに“1”を設定して更新」。
- これで再度切断されるまで多重ログインを防げる。
誤りやすいポイント
- “0” と “1” の意味を逆に覚え、許可・拒否を取り違える。
- 更新処理を忘れ、再ログイン後も “0” のままにしてしまう。
- 「エラーとしない」ではなく「エラーとする」と誤記して減点。
FAQ
Q: 多重ログインを完全に防げますか？
A: “1” 時にエラーとするため、正常系では防げます。ただし並行アクセス時はファイルロックなどの排他制御が別途必要です。
A: “1” 時にエラーとするため、正常系では防げます。ただし並行アクセス時はファイルロックなどの排他制御が別途必要です。
Q: 接続フラグの初期値はいつ “1” になりますか？
A: 【問題文】「ログイン時…受講ファイルにレコードを作成する。この時、受講受付日時に現在日時を設定」に加え、新設処理で “1” を設定します。
A: 【問題文】「ログイン時…受講ファイルにレコードを作成する。この時、受講受付日時に現在日時を設定」に加え、新設処理で “1” を設定します。
Q: 切断検知はどのように実装しますか？
A: WebSocket の切断イベントや一定時間応答がない場合のタイムアウト処理で検知し、“0” に更新します。
A: WebSocket の切断イベントや一定時間応答がない場合のタイムアウト処理で検知し、“0” に更新します。
関連キーワード: 状態フラグ、ログイン制御、排他制御、再接続設計、トランザクション管理
設問3：〔新システムの設計変更〕について答えよ。
（2）本文中の下線②について、どの属性をどのファイルに移すか。属性と移す先のファイルを表1中のファイル名と属性で答えよ。
模範解答
属性：アンケートURL
ファイル：受講申込
解説
解答の論理構成
- 変更要求を確認
- 【問題文】「セミナー終了後に受講申込者に送信するアンケートURLを、受講IDごとの個別のURLに変更する。」
⟹ URLの管理単位がセミナー（1対多の“1”側）から受講申込（1対1）側へ変わる。
- 【問題文】「セミナー終了後に受講申込者に送信するアンケートURLを、受講IDごとの個別のURLに変更する。」
- 現行設計を確認
- 【問題文】表1「セミナー」ファイルの主な属性に「アンケートURL」が存在。
⟹ 現行は“セミナー単位”に1つだけ保持。
- 【問題文】表1「セミナー」ファイルの主な属性に「アンケートURL」が存在。
- 個別URL運用との不整合
- 受講IDは「受講申込」ファイルの主キー 受講ID で管理。個別URLを生成・送信する対象は受講申込者であり、セミナーIDでは一意にならない。
- ファイル移動の妥当性
- 「受講申込」ファイルは受講IDをキーに持ち、申込み者単位でレコードを保持しているためURLを追加しても第3正規形を損なわない。
- よって「アンケートURL」を「受講申込」ファイルに移すのが最適。
誤りやすいポイント
- 「受講」ファイルに移すと誤解する
（受講ファイルはログイン受付時に作成されるため、未受講の申込者にURLが送れなくなる）。 - URLを追加ではなく複製だと考え、両方のファイルに残してしまう
（一意性・更新時異常の原因）。 - 「個別」を“セミナーごとに生成し直す”と解釈し、現行のままと判断する。
FAQ
Q: 受講申込ファイルの主キーが変わらないのに属性を追加して正規化に影響はありませんか？
A: ありません。主キー受講ID→アンケートURL の完全従属性となり、第3正規形を維持します。
A: ありません。主キー受講ID→アンケートURL の完全従属性となり、第3正規形を維持します。
Q: 「アンケート」ファイルへ移さないのはなぜですか？
A: アンケートファイルは回答データ作成時にレコードが生成されるため、未回答状態の受講申込者にURLを保持できません。
A: アンケートファイルは回答データ作成時にレコードが生成されるため、未回答状態の受講申込者にURLを保持できません。
関連キーワード: 正規化、主キー、属性移行、一意識別子、データ粒度
設問3：〔新システムの設計変更〕について答えよ。
（3）表3中の(c)~(f)に入れる適切な字句を、表1中のファイル名と属性を用いて20字以内で答えよ。ここで、レコード件数が該当する場合は、表3の記載にならい、“のレコード件数”という形式で答えよ。
模範解答
c：セミナーファイルの定員
d：受講ファイルのレコード件数
e：受講申込ファイルのレコード件数
f：アンケートファイルの評価点の合計
解説
解答の論理構成
- (c) の判定
- 表３「申込率（%）」は「受講申込ファイルのレコード件数 ÷ (c) × 100」と規定。
- 分母は定員そのものです。定員は【表1】「セミナー」ファイルの属性に「定員」が存在。
- よって「セミナーファイルの定員」。
- (d) の判定
- 表３「受講率（%）」の分子は受講者数。受講者は【表1】「受講」ファイルに１レコードずつ記録。
- したがって「受講ファイルのレコード件数」。
- (e) の判定
- 同じ式の分母は申込者数。申込者は【表1】「受講申込」ファイルに１レコードずつ記録。
- よって「受講申込ファイルのレコード件数」。
- (f) の判定
- 「平均評価点（点）」の分子は受講者が入力した「評価点」の総計。
- 評価点は【表1】「アンケート」ファイルの属性「評価点」で保持。
- 合計を求めるため「アンケートファイルの評価点の合計」。
誤りやすいポイント
- 「受講率」の分子・分母を逆にしてしまう。
- 「定員」をレコード件数と誤認し「セミナーファイルのレコード件数」と答えるミス。
- 「評価点」をレコード件数と勘違いし「アンケートファイルのレコード件数」としてしまう。
FAQ
Q: 「定員」は各レコードに１つずつありますが「レコード件数」を付けなくて良いのですか？
A: 定員は数値属性そのものを用いますので「のレコード件数」は不要です。
A: 定員は数値属性そのものを用いますので「のレコード件数」は不要です。
Q: 「評価点の合計」はどうやって計算するのですか？
A: 「アンケート」ファイルの同一セミナーIDに該当するレコードを抽出し、属性「評価点」を加算します。
A: 「アンケート」ファイルの同一セミナーIDに該当するレコードを抽出し、属性「評価点」を加算します。
Q: 空のセミナー（申込者が０人）の場合、計算式はどうなりますか？
A: 指示文に「除数が0のときは項目の値を0とする」とあるため、除算せず 0 を設定します。
A: 指示文に「除数が0のときは項目の値を0とする」とあるため、除算せず 0 を設定します。
関連キーワード: レコード件数、定員、分母分子、集計、平均値
