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

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の導き方

1. 未済案件一覧の定義を確認する。問題文には「未済案件一覧：委託先が作業を行うべき状態になっている案件で、通知案件一覧に表示されていない案件を、未済案件一覧に表示する。」とあります。したがって（A）委託先に作業が発生している状態で、かつ（B）通知案件一覧に載っていない状態、の両方を満たす状態番号を選びます。
2. 図2で「委託先が作業を行うべき状態」を抽出する。委託先ステータスが、委託先の確認・入力・開発を待っている状態を選びます。

• 2：「見積待ち／見積依頼確認待ち」（委託先が見積依頼を確認する）
• 3：「見積待ち／見積入力待ち」
• 4：直前のイベントが【見積入力】で、委託先が見積を入力している状態（空欄 a・b の状態）
• 10：「注文請待ち／注文確認待ち」（委託先が注文を確認する）
• 11：「注文請待ち／注文請入力待ち」
• 12：「（空欄 e）／委託開発中」
• 13：「納品待ち／委託開発中」
• 14：「納品待ち／納品入力中」

1. 次に、（B）「通知案件一覧に表示されていない」ことを確認して除外する状態を決めます。通知案件一覧は「D社が処理を完了したことによって委託先が対応すべき作業が発生した場合、そのことを委託先に知らせるために、委託先に電子メールを送信し、当該案件を通知案件一覧に表示する。」という設計です。通知案件一覧に表示する状態は、設問1(2) のとおり二つで、状態2（【見積依頼入力完了】で委託先に見積依頼の確認が発生）と状態10（D社の注文承認で委託先に注文の確認が発生）です。
2. 手順2の「委託先が作業を行うべき状態」（2、3、4、10、11、12、13、14）から、手順3の通知対象（2、10）を除くと、残る状態番号は3、4、11、12、13、14の六つです。よって未済案件一覧に表示すべき状態番号は3、4、11、12、13、14です。

誤りやすいポイント

• 通知と未済を混同する：通知案件一覧に表示されたものは未済案件一覧に表示しないという定義を見落とし、状態2や10を未済に含めてしまう誤りが多いです。
• 状態15を委託先の作業と誤認する：状態15はD社が納品物を確認中で、委託先は待っているだけです。
• 注文関連の契機を読み違える：通知を発生させるのは「注文入力完了」ではなく「注文承認」による遷移（状態9→状態10）である点を取り違えやすいです。
• 「見積送信済」を未済と誤認する：状態5〜9の「見積送信済」は委託先が見積を送付済みで、D社側の処理待ちの状態なので未済一覧の対象ではありません。
• 図中の (a)/(b)/(e) のような省略表記を見て意味を勝手に埋める：状態の意味は周辺のイベント（直前・直後の遷移）で判断するのが確実です。

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

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の導き方

• 目的：案件の開始から完了に至るまでの経緯についてシステムで追跡調査を行うため
• 属性名：承認者コード、承認日

1. 新システムの業務要件に「案件の開始から完了までの経緯について追跡調査を行いたい場合、全ての書類の日付及び署名を確認しなければならないので、新システムで追跡できるようにする。」とあることから、各書類の「いつ」「誰が」作成・承認したかをシステム上で記録できることが求められています。
2. 表1を見ると、見積依頼、見積、注文、注文詳、納品の各ファイルに「作成者コード」と「作成日」が属性として含まれており、これにより各文書の作成者と作成日時を特定できます（表の項目名は作成者コード、作成日）。
3. 「いつ」「誰が」を満たすために作成者情報を記録するのが目的であること、したがって短くまとめると「案件の開始から完了に至るまでの経緯についてシステムで追跡調査を行うため」が妥当です。
4. 同様に、承認に関する「誰が」「いつ」を記録する属性として、表1の見積・注文・納品に「承認者コード」「承認日」が設定されているため、これら二つが「同様の目的で設定した属性」に該当します。

誤りやすいポイント

• 見積依頼ファイルに承認者属性があると誤認する。表1の見積依頼には「作成者コード、作成日、状態区分」しかなく、承認者関連属性は記載されていない点に注意する。
• 目的を「単に監査用」「単語一語」で書いてしまう。設問の趣旨は「開始から完了までの経緯を追跡できること」であるため、それを含めた表現が必要。
• 属性名を省略・短縮して書く（例：承認者、作成日 → 正確には 承認者コード、作成日）。表記を問題文のまま正確に答えること。
• 「状態区分」や「更新日」と混同する。状態区分は状態を示すが、誰がいつ作成／承認したかを特定するためには作成者コード／作成日、承認者コード／承認日が必要。

FAQ