www.youtube.com 本動画では、令和5年度春期システムアーキテクト試験の午後Ⅰ問2「セミナー管理システムの開発」を、問題文・解答例・採点講評の観点に沿って解説します。題材はWeb上でセミナー申込みと受講を管理する業務をシステム化する事例で、要件に基づくデータモデル設計としての主キー選定、Web特有の同時実行による不整合の理解と排他制御、そして追加要望を受けたテーブル設計の見直しが中核テーマです。午後Ⅰらしく、与件に書かれた業務ルールがそのままデータの一意性や整合性条件として現れ、画面遷移と更新タイミングのずれが競合状態を生むという構造になっているため、静的なER設計と動的な処理フローを行き来しながら、根拠を置く場所を間違えずに答えられるかが得点を左右します。 まず設問1では、データモデルと整合性チェックの基本が問われています。セミナー担当の主キーは、担当者を一意に定めるのが目的ではなく、セミナーごとの担当体制を業務ルール通りに表現できるかが焦点です。与件では担当役割が企画・講師・運営の三つに分かれ、各役割に複数名を設定でき、さらに一人が複数役割を兼務できるとされています。この条件下では、セミナーIDだけでは同一セミナーに複数行が必要になるため一意にならず、担当者IDだけでも複数セミナーに出られるため一意になりませんし、役割も同様に単独では意味が不足します。したがって「あるセミナーについて、ある役割を、誰が担当するか」という最小単位で一意になるよう、セミナーID、担当役割、担当者IDの三属性を組み合わせた複合主キーが必要になります。午後Ⅰの読解ポイントは、主キーを“識別したい業務対象”から逆算することで、単にER図の形だけで決めず、兼務や複数名といった業務例外が入っても破綻しないキーになっているかを確認する姿勢です。 同じ設問1の重複申込み判定は、業務ルールの「同一人物」をシステム上でどう識別しているかを読み取る問題です。与件には、同一メールアドレスで申込みが重複していないことを確認するという条件が明確に書かれているため、重複確認の対象となるファイルは受講申込であり、個人識別子としてはメールアドレスを用いることになります。午後Ⅰでは、ここを会員IDなど架空の識別子で補ってしまう誤答が起きやすいのですが、本問はあえてメールアドレスをキーにしているため、与件に書かれた識別子をそのまま使うことが正解への最短経路になります。 設問2は、本問の山場である同時実行制御の理解を問うもので、Webシステムの画面遷移が持つタイムラグを前提に、競合状態がどう発生し、結果として何が起きるかまで説明できるかが採点講評上のポイントになります。処理フローでは、まず申込判定で定員未満かをチェックし、その後に申込確認画面を表示して利用者が内容を確認し、最後に確定ボタンで申込を確定してレコードを作成します。この流れの本質は、チェックした瞬間の状態と確定する瞬間の状態が一致する保証がないことです。申込確認画面が表示されている間に他の利用者が申込みを確定してしまえば、最初は定員未満だったとしても、当人が確定ボタンを押した時点では既に定員に達している可能性があります。採点講評が求めるのは「他者が申込みを確定する」という事実の列挙ではなく、その結果として「確定時に定員を超過する」という不整合が発生し得る点まで踏み込むことです。午後Ⅰでは、原因だけでなく影響までを一文でつなぎ、なぜ問題になるかを明確にして答えることで、同時実行制御の理解が採点者に伝わります。 設問3は、追加要望に伴う設計変更で、セッション的な状態管理、属性配置の見直し、そして統計指標の算出に必要なデータ対応付けが問われます。再接続処理では、通信断があっても元の状態で再開できるようにするという要件が、単なるログイン機能ではなく「多重ログイン禁止」の例外条件として現れます。受講ファイルに接続フラグを持たせ、通常は接続中を示す値で多重ログインを弾きつつ、切断状態であれば再接続を許容するという制御に落とすのが要点です。ここで重要なのは、再接続時にエラーとしない条件が「当該受講IDの接続フラグが0である場合」であり、再ログイン成功後には接続中を示すようフラグを1へ戻して更新するところまでが一連の要件だという点です。午後Ⅰでは、許可条件だけ答えて更新を落とす、あるいは更新だけ答えて例外条件を落とすという欠落が起きやすいので、状態遷移として読んで一連の動きを言語化できるかが差になります。 属性の移動は、正規化と粒度の見直しの典型で、アンケートURLがセミナー単位から受講者単位へ変わったことで、格納先のテーブルを変える必要が生じます。もともと全員が同じURLを使うならセミナーに置けますが、受講IDごとの個別URLが必要になった時点で、セミナーに置くと一つの属性で複数値を持つことになり破綻します。したがってアンケートURLは、セミナーではなく受講申込へ移すのが整合します。採点講評が触れる誤答の典型は、受講ファイルなど別テーブルへ移してしまうケースで、ここは「誰に送るURLなのか」「個別化の単位はどこか」という業務要件の粒度で判断するのが確実です。申込み単位で個別URLを持つという設計になっている以上、受講申込が最も自然な配置先になります。 統計項目の計算式では、KPIの定義をデータ項目にマッピングできるかが問われます。申込率の分母が定員であるなら、その定員はセミナーファイルの属性として一意に保持されているべきであり、受講率は申込数に対する実際受講者数の比なので、分母は受講申込の件数、分子は受講ファイルの件数として対応付けられます。平均評価点はアンケートの評価点合計を分子に取り、分母は問題文で指定される回答数として、受講有無が有のレコード件数など条件付き件数を用いることになります。午後Ⅰでは、数式そのものよりも、分子分母をどのファイルのどの属性・件数で具体化するかが評価対象で、定義語をデータに落とせないと誤答になりやすい構造です。 この問2の学習価値は、データ設計の一意性、画面遷移が生む競合、要件変更による正規化粒度の変更という、Web業務システムで頻出の三論点が一問に凝縮されている点にあります。とりわけ設問2のように、チェックした時点と確定する時点がズレることで整合性が破られる状況は、実務でも定員制予約、在庫引当、チケット販売などで繰り返し現れるため、原因と影響を因果で説明できるようにしておくことが重要です。採点講評が示唆する通り、単に「他者が先に確定する」だけでは不十分で、結果として定員超過が起きる、という不整合まで含めて答える姿勢が、午後Ⅰの得点を安定させます。 最後に、この動画を見る意義をまとめると、令和5年度春期システムアーキテクト午後Ⅰ問2を通じて、業務ルールから主キーを逆算する設計手順、Webの同時実行に起因する競合状態を処理フローで捉える視点、そして要件変更でデータの粒度が変わったときに属性の所属先を論理的に移し替える考え方を、根拠付きで身に付けられる点にあります。解答例の暗記ではなく、与件の条件語と処理順序を正確に拾い、採点講評が求める論点で言い切ることで、同種問題でも再現性の高い得点力を固めてください。
