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

模範解答

解説

解答の論理構成

1. 業務要件の確認
   • 【問題文】「(4) 新システムでは委託先と情報を共有することになるが，社内の手続の状況は委託先に開示されないようにする。」
2. 画面設計の仕様
   • 【問題文】「委託先トップ画面に表示するステータスは，委託先ステータスである。」
3. 整合性の検証
   • 社内進捗を表す「Ｄ社ステータス」を非表示にし、委託先側の行動だけを示す「委託先ステータス」を表示することで要件(4)を充足。
4. したがって目的は「社内の手続の状況が委託先に開示されないようにするため」となる。

誤りやすいポイント

• 「書類のやり取りを速くするため」と誤解し、要件(1)と混同する。
• 「転記ミスの削減」と答えて要件(2)に引きずられる。
• ステータスの二重管理の意味を読み落とし、D社ステータスも見せる前提で考えてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 通知案件一覧の定義を確認
   引用：
   “通知案件一覧：ある案件に対して，D社が処理を完了したことによって委託先が対応すべき作業が発生した場合，そのことを委託先に知らせるために…当該案件を通知案件一覧に表示する。”
2. 例示されている状態番号２を把握
   見積依頼入力完了（D社完了）→委託先が見積確認を行うため通知案件一覧に表示。
3. 同じ条件に当てはまる他の工程を探す
   注文工程について引用：
   “承認した場合は，注文書を発行し，委託先に注文する。委託先は注文書の内容を確認し，注文請書を発行…”
   ここでも「D社の処理完了（注文書発行）」直後に「委託先が確認」を行う必要がある。
4. 図２で該当する状態を特定
   D社：注文承認済みで注文書発行待ち状態
   委託先：注文確認待ち状態
   → 状態番号 10。
5. 以上より，通知案件一覧に表示されるもう一つの状態番号は 10 となる。

誤りやすいポイント

• 「委託先が作業中」の状態（例：見積入力中，委託開発中）を通知案件一覧と誤認する。
• 状態番号９（注文承認待ち）を選んでしまう。９はまだD社内部で承認処理中であり“処理完了”条件を満たさない。
• 図２の状態遷移を確認せず，文章説明だけで番号を推測する。

FAQ

模範解答

解説

解答の論理構成

1. 問題文の事実確認
   • 「D社が処理を完了したことによって委託先が対応すべき作業が発生した場合，そのことを委託先に知らせるために，委託先にメールを送信し，当該案件を通知案件一覧に表示する」
2. 前提となる課題
   • 業務要件(1)に「書類の再提出などがあると，案件の開始が遅れる」とある→早期着手が重要。
3. 想定リスクの抽出
   • 連絡手段が「メール」に依存すると，未読・見落としで対応が遅延する可能性。
4. 解決策の導出
   • 同じ案件を「通知案件一覧」にも掲示し，メール未読でも画面を開けば気付けるようにする。
5. 以上から，模範解答
   • 「委託先がメールを見落として，対応すべき作業の発生に気付かないケース」

誤りやすいポイント

• 「通知案件一覧」はメール通知の代替ではなく“補完”である点を読み落とす。
• リスクを「メールの未達」と誤解しがちだが，設問は「見落とし＝未読」に焦点。
• 「案件開始が遅れる」原因を“郵送”や“承認フロー”と錯覚し，メール見落としとの因果を示せなくなる。

FAQ

模範解答

解説

解答の論理構成

1. 未済案件一覧の要件確認
   • 【問題文】「未済案件一覧：委託先が作業を行うべき状態になっている案件で，通知案件一覧に表示されていない案件を，未済案件一覧に表示する。」
2. 通知案件一覧に載る状態を把握
   • 【問題文】「通知案件一覧：ある案件に対して，D社が処理を完了したことによって委託先が対応すべき作業が発生した場合…当該案件を通知案件一覧に表示する。」
   • 図2ではメール送信を伴う契機（見積依頼入力完了，注文入力完了，納品入力完了）の直後、状態番号「2」「10」「15」が該当する。
3. 「委託先が作業を行うべき状態」の抽出
   図2を上流から追うと、委託先が入力／開発などの作業主体となる状態番号は
   • 3：見積入力待ち
   • 4：見積入力中
   • 11：注文入力待ち
   • 12：委託開発中
   • 13：委託開発中（D社は納品待ち）
   • 14：納品入力中
4. 「通知案件一覧に表示されていない」条件の適用
   • 上記6状態はいずれも通知直後の「2」「10」「15」ではないため、メール通知済（あるいはメール不要）の段階で未済案件条件を満たす。
5. したがって答えは「3，4，11，12，13，14」となる。

誤りやすいポイント

• 状態番号「2」「10」「15」を未済に含めてしまう
  → これらは“通知直後”であり、未済ではなく通知案件一覧に載る。
• 「委託先が作業中」と「委託先の作業待ち」を混同
  → 状態番号「5」「6」「7」「9」では主導権がD社側にあるため未済ではない。
• 委託先ステータスだけを見て判断
  → D社側が入力中・承認中の場合は委託先の行動機会がない点に注意。

FAQ

模範解答

解説

解答の論理構成

1. 状態4 の D社ステータス (a)
   • 直前の状態3 は D社 “見積待ち”／委託先 “見積入力待ち”。
   • イベント【見積入力】後も，D社側は提出を“待っている”だけで何も処理していない。
   • よって (a) は「見積待ち」。
   • 根拠：【問題文】「委託先は，見積書を作成して提出する。委託責任者は…確認し…」
2. 状態4 の 委託先ステータス (b)
   • イベント【見積入力】を受けて入力作業に着手した状態。
   • “入力待ち”から“入力中”へ移るので (b) は「見積入力中」。
3. 状態9 → 状態10 を引き起こすイベント (c)(d)
   • 【問題文】「管理責任者が…承認又は否認を行う」
   • 承認時に進むルートが (c)＝「注文承認」，否認で戻るルートが (d)＝「注文否認」。
4. 状態12 の D社ステータス (e)
   • 委託先が“注文請書”を入力し終えた直後。
   • D社は内容確認待ちになるので (e) は「注文請確認待ち」。
   • 根拠：【問題文】「委託責任者は，注文請書を受け取ると…納品を待つ。」（確認プロセスが残っている）

誤りやすいポイント

• 「入力中」と「入力待ち」を混同し，(b) を誤って「見積入力待ち」とする。
• 承認／否認のイベント名を状態名で書いてしまう（例：「注文承認待ち」）。イベントとステータスは別概念。
• (e) を「納品待ち」と早合点し，D社がまだ注文請書を確認していない段階で次工程に飛ばしてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 図2の文言を確認
   • 状態

     15

     ：

     Ｄ社ステータス：納品物確認中 ／ 委託先ステータス：納品物確認待ち

   • 状態

     13

     ：

     Ｄ社ステータス：納品待ち     ／ 委託先ステータス：委託開発中

2. 問題文の指示
   • 「図2では、納品差戻しによるイベントとそれに伴う状態の遷移の矢印を省略している。」
3. 納品差戻しが起きるタイミング
   • 納品物を受領した後、内容不一致なら「差し戻す」と【問題文】“(4) 納品受領”で記述。
   • 差戻し後でも履歴を残し、委託先は再修正して再納品する流れになる。
4. したがって
   • 差戻しイベントの“発生源”は納品物を確認している状態

     15

     。
   • “戻り先”は再度納品を待つ状態

     13

     。
5. 以上より、始点

   15

   、終点

   13

   となる。

誤りやすいポイント

• 「一つ前」の

  14

  （納品入力中）へ戻ると誤解する
  • 差戻しは入力中ではなく“再開発”へ戻すため

    13

    。
• “委託先ステータス”だけを見て判断する
  • 両社ステータスが整合する状態同士で遷移を引く必要がある。
• 納品差戻し＝案件中止と混同する
  • 差戻しは再納品が前提。案件中止なら開始状態へは戻らない。

FAQ

14

13

14

13

14

15

模範解答

解説

解答の論理構成

1. 注文ファイルと見積ファイルの関係を確認
   • 【問題文】「委託責任者は，見積内容を承認すると，見積書に基づいて注文書を作成する。」
   • したがって「注文」は必ず一つの「見積」に従属する。
   • 注文ファイルの主キー「注文番号」の直後に外部キーを置くことで一意性を保ちつつ上流工程を参照する設計が一般的。
   • よって (f)＝「見積番号」。
2. 納品ファイルと注文ファイルの関係を確認
   • 【問題文】「委託先は注文書の内容を確認し，注文請書を発行して開発に着手する。」
   • 【問題文】「委託先は，開発作業が完了すると納品する。」
   • 納品は注文の履行結果であり、どの注文に対する納品かを識別する必要がある。
   • 表1の納品ファイルでは主キー「納品番号」の直後に欠落があり、この位置は注文を示す外部キーと考えるのが自然。
   • よって (g)＝「注文番号」。
3. 外部キーであることの整合性
   • 状態遷移図でも「見積承認」後に「注文入力」へ、「注文請確認」後に「納品入力」へ進むため、参照整合性を保つ属性が必要。
   • 「見積番号」「注文番号」を設定することで、データベース上でもフローと一致した階層構造となる。

誤りやすいポイント

• 注文ファイルの (f) を「案件番号」と誤認
  • 案件番号は既に案件管理ファイルで管理されており、注文と見積の1対1対応を表せない。
• 納品ファイルの (g) を「案件番号」や「見積番号」と混同
  • 納品は「注文」の結果であり、見積を直接参照しない点に注意。
• 主キー候補と外部キーの区別
  • 主キーはファイルのレコードを一意に識別、外部キーは上流レコードとの関連付けを行うという役割の違いを意識すること。

FAQ

模範解答

解説

解答の論理構成

1. 【問題文】引用
   • 「見積受領…見積内容を承認しない場合は差し戻し，再度見積書の提出を求める。見積書を差し戻した場合でも見積内容及び確認結果の履歴は残す。」
2. 差し戻されるたびに同一「見積依頼番号」で新たな見積書が発生する。
3. そこで「見積」ファイルに「見積履歴番号」を追加し、同一「見積依頼番号」に対して複数レコードを保持できる設計としている。
4. よって想定ケースは“差し戻しによる見積書の再提出”である。
5. 解答例（25字以内）
   • 「見積り差戻しによる再提出の場合」

誤りやすいポイント

• 複数社からの比較見積りと誤解し、発注先別管理と答えてしまう。
• 「見積依頼取消」に伴う履歴と勘違いしてしまう。
• 「見積番号」だけで一意管理できると考え、「見積履歴番号」の必要性を見落とす。

FAQ

模範解答

解説

解答の論理構成

1. 要件の抽出
   • 【問題文】の業務要件(3)
     「案件の開始から完了までの経緯について追跡調査…新システムで追跡できるようにする」
     ⇒ 追跡機能の実装が必須。
2. 追跡に必要な情報
   • 日付・担当者を残せば、誰が・いつ・何をしたかが分かる。
   • そこで各ファイルに「作成者コード」「作成日」を配置。
3. 表1の確認
   • 全ファイル共通で「承認者コード」「承認日」も存在。
   • これらも担当者・日時を保持し、同じ追跡目的を満たす。
4. したがって
   • 目的：追跡調査を行うため。
   • 同目的の属性：承認者コード、承認日。

誤りやすいポイント

• “監査証跡”や“ログ”とだけ書き、要件の表現「追跡調査」を落とす。
• 「更新日」や「状態区分」を同目的の属性と誤解する。更新日は最終更新のみで担当者が不明、状態区分は履歴ではない。
• 承認フローを見落とし、承認者関連の属性を答案に挙げない。

FAQ