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

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

• 社内の手続の状況
• 委託先に開示しない
• 委託先ステータスのみ表示
• 業務秘匿・情報制御

解説

1. 問題文の関連記述

(4) 新システムでは委託先と情報を共有することになるが，社内の手続の状況は委託先に開示されないようにする。

2. 理由の背景

• 本システムはD社（委託元）と委託先が情報共有を行いますが、社内の業務プロセスや意思決定状況などの内部情報の秘匿を兼ねています。
• D社では「D社ステータス」と「委託先ステータス」を別々に管理し、委託先には委託先ステータスのみを表示する設計としています（問題文より）。

3. なぜ委託先ステータスだけを表示するのか

• 委託先は自分たちの手続き・進捗状況だけを把握できれば十分です。
• D社の手続き状態（例えば承認待ち、差戻し理由など）を見られると、社内の業務フローが漏洩したり、誤解や不要な問い合わせが増えたりするリスクがあります。
• よって、「社内の手続の状況を開示しない」ために、委託先トップ画面では委託先ステータスのみに限定して表示するという設計方針です。

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

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

• 業務委託管理における内部情報（社内手続状況）と外部情報（委託先向け情報）を分離する設計が重要。
• 情報システムの画面設計は利用者ごとに表示範囲を制限することが多い。
• 「ステータス管理」は一つの業務の進捗・状況を表示する手段であるが、
  • 利用者によって異なる視点（社内担当者用・委託先用）がある。
  • 外部に社内情報を不用意に開示しないことが情報管理の基本である。
• 情報処理技術者試験では、「情報開示範囲の制御」や「秘匿すべき情報の区分管理」が頻出テーマの一つ。

「社内の手続の状況が委託先に開示されないようにするため」

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

• 通知案件一覧：D社が処理を完了して委託先が対応すべき案件の一覧
• 表示される案件の状態番号：問題文で例示されている状態番号2ともう一つの状態番号
• 状態番号2の内容：見積依頼完了後で委託先が「見積依頼確認待ち」の状態
• もう一つ該当する状態番号：委託先が対応すべき状態であり、D社が処理完了を通知済みの状態（状態番号10）
• 状態番号10の内容：注文請待ち（D社側は「注文確認待ち」）で、委託先が注文請書を作成対応すべき状態

解答の論理的説明

「D社が処理を完了したことによって委託先が対応すべき作業が発生した場合，当該案件を通知案件一覧に表示する」

「D社が見積依頼入力を完了すると，委託先にメールを送信し，同時に通知案件一覧に欄に当該案件を表示する」

「D社が処理を完了したことによって委託先が対応すべき作業が発生した場合」

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

• 状態番号の見た目で判断しやすいが、実際にはD社と委託先の両方のステータスを見なければ正解しづらいこと
  状態遷移図は「D社ステータス / 委託先ステータス」で表されており、単にD社側の処理完了を見誤ると正答を間違いやすい。
• 「未済案件一覧」と「通知案件一覧」の区別を見誤ること
  未済案件一覧は「通知案件一覧に表示されていないが、委託先が対応すべき案件」。通知はD社が処理完了して通知済みの案件のみ。
  この違いを曖昧にすると回答を誤る。
• 注文請書の役割や段階を理解していないケースがある
  注文請書はD社の注文書に対する委託先の同意を示し、委託先側の重要な作業発生日となるため通知案件一覧に入る点を認識していないと誤りやすい。

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

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

• 通知案件一覧に表示する理由
  → 「委託先が対応すべき作業が発生したことを知らせるため」
• 想定されているケース
  → 「委託先がメールを見落とすことによる対応遅滞」
• 業務効率化の観点
  → 書類や連絡のやり取り遅延を防ぎ、作業の遅れや抜け漏れを防止する

なぜこの解答になるのか（問題文の引用と論理的説明）

「新システムでは，委託先が遅滞なく手続を進められるように，次の一覧を表示する領域を設けた。」
(1) 通知案件一覧：…D社が処理を完了したことによって委託先が対応すべき作業が発生した場合，そのことを委託先に知らせるために，委託先に電子メールを送信し，同時に通知案件一覧の欄に当該案件を表示する。

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

• 単に「連絡の迅速化」だけでは不十分
  「書類やメールのやり取りを早める」という業務要件はありますが、通知案件一覧の設置意図は単なる迅速化より「見落とし防止」が中心です。
• 「未済案件一覧」との違い
  未済案件一覧は「まだ対応が完了していない案件」で、通知案件一覧は「新たに対応が必要であることを通知する案件」です。混同して「ただの未対応案件の一覧」と回答してしまう誤り。
• 通知が「メール送信」と「画面表示」の二重手段であることの理解不足
  メールは通知手段、画面表示は「気付き忘れを防ぐ第二の手段」である点の把握が必要です。

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

コアとなるキーワード・論点の整理

• **委託先トップ画面の「未済案件一覧」**には
  「委託先が作業を行うべき状態になっている案件で、通知案件一覧に表示されていない案件」を表示する。
• 新システムでは、案件の進捗を
  「D社ステータス」と「委託先ステータス」という別々のステータスで管理。
  「委託先トップ画面に表示するステータスは、委託先ステータスである」と明記されている。
• 状態遷移図（図2）より、各状態番号は「D社ステータス／委託先ステータス」の組合せを示し、
  委託先が対応すべき作業が発生しているステータス（＝委託先ステータスで対応作業中や待ちの状態）を抽出する。

解答の理由と問題文引用による論理的説明

1. 「未済案件一覧」の定義

(2) 未済案件一覧：
委託先が作業を行うべき状態になっている案件で，
通知案件一覧に表示されていない案件を，未済案件一覧に表示する。

2. 委託先ステータス別の解釈

3. なぜ他の状態番号ではないか

• 状態番号1、2（見積依頼の入力中）などは「D社ステータス／委託先ステータス」で、委託先はまだ直接関与していない段階。
• 状態番号5、6、7、8 は「見積確認待ち」「注文入力待ち」などで、D社側の処理待ちや入力完了待ち の場合があり、委託先の作業未開始や対応不要な箇所も含まれる。
• 状態番号9～10は「注文承認待ち」「注文請待ち（注文確認待ち）」で、基本的にD社側の承認待ち状態で委託先の作業は休止状態。
• 15は「納品物確認中」で、納品物の確認作業中などで、委託先は納品作業は終えている。

4. 通知案件一覧との違い

D社が処理を完了したことによって委託先が対応すべき作業が発生した案件を表示する。

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

• 状態番号の意味を曖昧に解釈すること
  状態はD社ステータス／委託先ステータスの組み合わせであるため、「委託先ステータス」の内容をしっかり見ることが重要。
  委託先の「入力待ち」「入力中」「発行中」などの状態が未済の条件。
• 通知案件一覧と未済案件一覧の違いの理解不足
  「通知案件一覧」＝新たに通知があった案件（目立つ）
  「未済案件一覧」＝通知されていないが処理が未済の案件
  これを取り違えると誤答になります。
• 「作業を行うべき状態」の定義の混同
  作業中すでにD社側の承認待ちなどで、委託先の作業が発生しない状態は表示されない。

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

1. システムの画面表示に関する設問では、「業務要件の定義」「画面設計の説明」「状態管理」の記述を正確に理解する
   → 表示条件は単なる状態遷移だけでなく、通知有無・作業発生の有無が関係する。
2. 状態管理は「当事者ごとに別のステータス」が付与されるケースが多いことを理解し、求められている主体のステータスを正しく把握する
3. 通知案件と未済案件の違い（画面設計で明示された条件）を整理し、どの状態がどのリストに入るかを判別できること
4. 問題文中の重要なキーワードを正確に読み取る力を養うこと（例：「委託先が作業を行うべき状態」「通知されていない」など）

参考表：新システムにおける主な状態番号と委託先ステータス

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

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

a：見積待ち

• 問題文より、委託先は「見積依頼書を提示」されてから「見積書を作成して提出する」とある。
• すなわち、委託先がまだ見積書を作成・提出していない状態を「見積待ち」と表現するのが適切である。

「(1) 見積依頼：・・・委託先は、見積依頼書の内容を確認し、見積書を作成して提出する。」

b：見積入力中

• 委託先が見積り情報を入力し提出準備をしている段階。
• 「見積書を作成して提出する」作業中であるから、「見積入力中」が的確。

c：注文承認

• 問題文の注文プロセスにて、

「その後、管理責任者が、見積り及び注文の内容を審査し、承認又は否認を行う。承認した場合は、注文書を発行し、委託先に注文する。」

• 承認済みの注文状態を指すため、「注文承認」が最も適切。

d：注文否認

• 同じく管理責任者が「否認した場合は...」とあり、

「否認した場合は、委託責任者に見積内容を再度確認させる。」

e：注文請確認待ち

• 委託先は注文書を受領後、「注文請書を発行して開発に着手する」。

「委託先は注文書の内容を確認し、注文請書を発行して開発に着手する。委託責任者は、注文請書を受け取ると、委託先が開発に着手したとして...」

• 注文請書発行後、D社が注文請書を確認するまでの待機状態を表す。

3. 受験者が誤りやすいポイントやひっかけ選択肢とその理由

• 「見積入力中」と「見積待ち」 の混同
  見積提出前で「まだ見積書入力作業に着手していない」状態は「見積待ち」。
  作業をしている最中は「見積入力中」。
  これを混同しやすいが、段階の違いをよく理解することが重要。
• 「注文承認」と「注文請確認待ち」の誤認
  「注文承認」はD社の管理責任者による承認で「注文請確認待ち」は委託先が注文請書を発行し、その確認待ち。
  同じ「注文」のキーワードだが、関係者と意味合いが異なる。
• 「注文否認」と似た否認系の言葉
  例えば「取下げ」や「見積差戻し」などの異なる否認系ステータスもあるため、文脈で正しい否認を選ぶ必要がある。

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

• 【業務フローとステータスは連動する】
  業務手順の各段階での社員・委託先の作業や承認状況を正確に把握する。
• 【D社ステータスと委託先ステータスは区別】
  図2では両者の状態遷移が分かれており、「委託先ステータス」は委託先画面表示用であることを意識する。
• 【業務要件からステータス設計を理解する】
  問題文にあるような業務上の課題や目的を満たすために、ステータス遷移やイベント名称が設計されている。
• 【用語の意味を具体的事象に紐づけて理解する】
  「見積待ち」は“待機”、「見積入力中」は“作業中”のように、状態の意味合いを具体的にイメージする。
• 【書類やイベントの流れを順に追う】
  見積依頼→見積書提出→見積承認→注文書発行→注文請書発行…の流れは定番で、問題文の詳細理解に直結。

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

• 納品差戻し：納品物の内容が注文書に一致しない場合に、委託責任者が納品物を差し戻すイベント。
• 状態番号 15（納品物確認中／納品物確認待ち）：納品物の承認、差戻しを行う直前の状態。
• 状態番号 13（納品待ち／委託請発中）：委託先が納品物の入力を行う状態のひとつ。
• 状態遷移の逆戻り：納品差戻しによって、納品確認の状態（15）から納品入力待ちの状態（13）に戻ること。
• 図2の省略部分の補完：「納品物差戻し」による遷移を想定し、矢印の始点と終点を答える問題。

解答が「始点：15、終点：13」となる理由の論理的説明

1. 【納品受領における業務の流れ】（問題文の(4)より）
   • 「委託責任者は納品物を受領し確認を行う」
   • 「注文書に記載された納品物と一致していれば承認し、異なれば差し戻す」
   • 「納品物の差戻しがあっても履歴は残る」
   • 「納品物の内容・品質の確認は次工程（検査以降）で行う」
2. 【状態遷移図（図2）】納品関連の遷移部分
   • 状態番号15は「納品物確認中／納品物確認待ち」という確認のための状態である。
   • 状態番号13は「納品待ち／委託請発中」で、納品がD社に対して行われておらず、委託先側の入力待ち状態である。
   • 「納品差戻し」は注文書の納品物と不一致のため、納品物の入力や再提出が必要なため、遡って納品「入力待ち」の状態に戻す必要がある。
   • 問題文冒頭にも「納品物を差戻した場合でも納品の履歴は残す」とあり、状態の遷移として戻ることが想定されていることがわかる。

• 始点（差戻される直前の状態）：15
• 終点（差戻し先の状態）：13

受験者が誤りやすいポイントとその理由

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

• 状態遷移図の読み取りに慣れること
  状態遷移図ではイベントにより現在の状態がどの状態に遷移するかを把握し、特に「差戻し」という逆戻りのケースも重要。
• 納品・検収段階の業務フローを理解すること
  納品物の不備時には、納品「承認待ち」状態から再度「納品入力」状態に戻るというフローは多くの実際の業務システムで共通。
• ステータスの管理対象が双方（D社、委託先）で別々にあることに注意
  問題文にあるように、D社ステータスと委託先ステータスが存在し、双方の状態が組み合わさって一つの状態番号で表現されていることを理解するとミスが減る。
• 状態番号はあくまでも組み合わせによる一意の番号であること
  状態番号自体に意味を求めすぎず、図中のステータスの中身やイベントの意味を理解すること。

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

• (f)に入る属性名：見積番号
• (g)に入る属性名：注文番号

解答根拠の論理的説明

(f) 注文ファイルの(f)の属性

• 「注文」ファイルは、見積書の内容を承認後に注文書を作成するものであることから、
  注文ファイルは、対応する「見積」ファイルの情報を参照できる必要があります。
• したがって、(f)には「見積番号」を設定して、どの見積に基づく注文かを管理します。

「(3) 注文：委託責任者は，見積内容を承認すると，見積書に基づいて注文書を作成する。」

(g) 納品ファイルの(g)の属性

• 「納品」ファイルは、実際に納品された成果物を管理するためのファイルで、
  それがどの注文に対応する納品かを明示できるようにする必要があります。
• したがって、(g)には「注文番号」を入れて、どの注文に対する納品かを管理します。

「(4) 納品受領：委託先は開発作業が完了すると納品する。...納品物を受領し，確認を行う。」
「（注文書に記載された納品物と一致していれば...）」

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

• (f)に「案件番号」を入れてしまう誤りがあります。
  「案件番号」は案件管理の単位であり、注文はその中の単位として「見積番号」とリンクすべきだからです。
• (g)に「納品番号」を入れてしまうこともありますが、
  納品ファイル内の主キーはすでに「納品番号」として存在します。
  (g)は注文ファイルとの関連を示すための外部キーとして必要です。
• 「見積依頼番号」など、別の番号を入れる選択肢もありますが、
  見積依頼は見積書の元になる依頼書であり、注文と納品には直接リンクしません。

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

• システムのファイル設計では、各業務段階に応じて関連ファイルは一意の番号で紐づける「キー属性」を必ず持つ。
• 要件に基づく業務フローを理解し、どの番号（ID）がどの段階のデータを示すかを明確に把握する。
• 「見積書」→「注文書」→「注文請書」→「納品」という流れを踏まえ、各ファイルの関連を理解すること。
• ファイル主キー、外部キーの違いを整理し、外部キーとして他ファイルの主キーを保持している点を押さえる。

まとめ

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

• 見積ファイルの「見積履歴番号」属性の目的
• 同一見積依頼番号に対し複数回の見積りが発生することがある
• 業務上の「見積差戻し」によって再提出が求められるケース
• 履歴管理（履歴番号）で過去の見積データを管理・追跡可能にする

なぜその解答になるのか（問題文の引用と論理的解説）

見積内容を承認しない場合は差し戻し，再度見積書の提出を求める。 見積書を差し戻した場合でも見積内容及び確認結果の履歴は残す。

• 見積書は1回の提出で成立するとは限らず、「差し戻し」が発生した際には、委託先は再提出する必要がある。
• つまり、同じ「見積依頼番号」に対して複数の「見積書」が提出されることがある。
• これを管理システムで扱うために「見積履歴番号」という属性を設け、1件の見積依頼に対して複数の異なる見積り情報が登録可能にしている。
• 「履歴番号」によってどの見積りが最新か、どの履歴が差し戻し後の再提出かを判別・管理し、履歴の追跡も可能となる。

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

• 誤解ポイント1：単純に「見積書の複数提出」だけを想定していると思い込むこと
  → 単発の再提出なら履歴管理は不要ですが、「差戻し」による複数回提出や差戻し理由の管理が重要。
• 誤解ポイント2：「履歴」は日付や作成回数の管理として誤認し、業務上の差戻しという理由を見落とすこと
  → 「履歴」は単なるデータ更新履歴でなく、業務プロセス上の段階を示すために設計されている。
• ひっかけ選択肢例
  • 「見積書の変更や訂正」 → 変更後に再提出するのは正しいが、なぜ変更が発生するか（差戻しが原因）が問われている。
  • 「類似案件の見積りを区別するため」 → 「同一見積依頼番号」が前提なので想定外。

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

• 見積依頼番号は案件にリンクし、1件の見積依頼に対して複数の見積書が提出されることがある。
• その際、**「見積履歴番号」**で履歴管理をし、過去の差戻しや再提出を含めた情報を管理することが重要。
• 業務上で「差戻し」が発生すると、再度見積書を提出する必要があるため、1つの依頼に対して複数の見積書が存在しうる。
• システム設計ではこれらの履歴管理のための属性設計を必ず押さえ、業務要件との整合性を意識する。
• 問題文の業務フローを丁寧に読み取り、「なぜ履歴管理が必要か」という業務背景を理解することが合格への近道。

まとめ

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

• 【目的】
  • 「案件の開始から完了に至るまでの経緯についてシステムで追跡調査を行うため」
  • つまり、いつ誰がどの段階・どの書類を作成・承認したかを明確に記録し、業務の履歴を追えるようにすること
• 【属性名】
  • 作成の記録を残すための「承認者コード」
  • 承認日時の記録を残すための「承認日」

論理的な説明（問題文の引用を交えて）

(3) 案件の開始から完了までの経緯について追跡調査を行いたい場合、全ての書類の日付及び署名を確認しなければならないので、新システムで追跡できるようにする。

• 書類の真正性を確保し、
• 後で不明点や問題が発生した際に履歴調査ができる

• 目的は「経緯の追跡調査を行うため」
• 属性名は「承認者コード」「承認日」

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

• 作成者コードと作成日は「誰がいつ作成したか」を表すが、 「承認者コード」と「承認日」がセットで記録されていることを見落としがちです。
  → 作成者だけでなく承認者の情報も重要であることを理解していないと正解できません。
• 「状態区分（入力中、承認、差戻しなど）」の属性も重要情報ですが、経緯の「追跡調査」に直結するのは日時・担当者の記録の方であり、状態区分そのものは選択肢として適切でないことに注意。
• 書類ごとに作成者コード・作成日が設定されていることはわかっても、 追加で承認者コード・承認日がセットであることをシステム要件から明示的に理解していなければ見落とされるケースがあります。

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

• 情報処理技術者試験の業務系問題において、 「追跡調査」や「履歴管理」を行うために「誰が」「いつ」行ったかのログ（作成者・承認者と日付）を設計に組み込むことは基本的な要件である。
• 作成者コード・作成日は「作成履歴」、
  承認者コード・承認日は「承認履歴」としてセットで管理されることが多い。
• 状態遷移管理や履歴管理では「電子的な署名情報の代替」としてこれらの属性が使われるため、「書類の真正性と管理責任の明確化」に役立つ。
• システム要件で「経緯の追跡調査」が求められている場合は、作成・承認関連属性を聞かれることが多いため、このポイントは必ず押さえておく。