平成27年度秋期 システムアーキテクト 午後Ⅰ 問3

用語の意味と対象範囲をそろえる

検討を始める前に、記述されている用語が何を指すのかに注目しましょう。同じ言葉でも、文脈によって対象の範囲が違うことがあります。自分の経験で意味を補わず、与えられた条件の中で捉えることが大切です。

この問題で問われていること

この分野では、複数の情報を関連付ける際に、同じ対象を指しているつもりで別の範囲を捉えていないかを確認します。まず一つの用語に絞り、その意味を与えられた条件に沿って説明できるか考えてみましょう。

視点

用語を見慣れていることと、その場での意味を把握していることは別です。一つの用語に注目し、何を指す言葉として扱っているかを短く整理すると、考える途中で対象の範囲がずれていないかを確認しやすくなります。

確認ポイント

• 注目する用語が指す対象を意識したか
• その対象の範囲を途中で広げたり狭めたりしていないか
• 意味の説明に、与えられた条件にない前提を加えていないか

解説

業務委託の手続を基に、社内状況の非開示、作業の見落とし防止、当事者別の状態遷移、書類間の関連付け、差戻し履歴と追跡調査のための属性を設計する問題です。

問題の全体像

D社は、社内だけで使っていた管理システムを拡充し、開発業務の委託先と共有するオンラインシステムを構築します。課題は、郵送による遅延、転記ミス、案件経緯の調査負担です。同時に、社内手続の状況を委託先へ開示しない要件もあります。出題趣旨では、利用者の業務要件を理解し、外部設計と内部設計へ具体化する能力を評価するとしています。画面の表示条件、イベントによる状態遷移、ファイルの関連と履歴管理を、本文の業務に結び付けて読むことが要点です。

設問1(1)

〔新システムの業務要件〕(4)の「社内の手続の状況は委託先に開示されないようにする」に着目します。図2のD社ステータスには、見積内容確認中や注文承認待ちなどの社内手続が表れます。委託先ステータスだけを表示すれば、その詳細を委託先に示さずに済みます。公式解答例では「社内の手続の状況が委託先に開示されないようにするため」としています。30字以内の答案では、非開示の対象が社内手続の状況であることを明記します。

設問1(2)

通知案件一覧の条件は、D社の処理完了によって委託先の作業が発生することです。状態2では、見積依頼入力の完了により、委託先の見積依頼確認が必要になります。もう一つは、管理責任者の注文承認によって注文書が発行され、委託先が注文内容を確認する段階です。図2では状態9から状態10へ遷移し、委託先ステータスが注文確認待ちになります。したがって、公式解答例では「10」です。

設問1(3)

〔新システムの設計〕(1)では、作業の発生をメールで知らせると同時に、通知案件一覧にも表示します。この併用が必要になるケースを答えます。公式解答例では、委託先がメールを見落とし、対応すべき作業の発生に気付かないケースを挙げています。40字以内では「メールの見落とし」と「作業発生に気付かない」を結び付けます。採点講評では、差戻し時にメールが送られない、オンライン化後も郵送に時間が掛かる、といった問題文にない想定への注意を示しています。

設問1(4)

未済案件一覧は、委託先が作業を行うべき状態にあり、通知案件一覧には表示されていない案件が対象です。図2の右側にある委託先ステータスを追うと、状態3は見積入力待ち、4は見積入力中、11は注文請入力待ち、12と13は委託開発中、14は納品入力中です。状態2と10は通知案件一覧の対象なので除きます。状態12ではD社が注文請の確認を待っていても、委託先は既に開発を行う段階です。公式解答例では「3、4、11、12、13、14」です。

設問2(1)(a)

図2の凡例では、斜線の左がD社ステータスです。状態3から状態4へのイベントは、委託先による見積入力です。その間、D社は見積りの提出を待っており、状態5へ進む見積入力完了までは確認作業を開始できません。したがって、状態4のD社ステータスについて、公式解答例では「見積待ち」としています。

設問2(1)(b)

空欄bは状態4の委託先ステータスです。直前の状態3は見積入力待ちで、見積入力のイベントによって状態4へ進みます。その後、見積入力完了によって状態5の見積送信済へ進むため、状態4は入力作業を行っている途中です。公式解答例では「見積入力中」としています。

設問2(1)(c)

空欄cは、状態9の注文承認待ちから、状態10の注文請待ち／注文確認待ちへ進むイベントです。〔現在の業務委託管理に関する業務の概要〕(3)では、管理責任者が承認すると注文書を発行し、委託先へ注文するとあります。この承認が、委託先の注文確認を開始させる契機になります。公式解答例では「注文承認」としています。

設問2(1)(d)

空欄dの矢印は、状態9から接続記号Bを経由し、状態6の見積内容確認中へ戻ります。本文の注文業務では、管理責任者が注文を否認した場合、委託責任者に見積内容を再度確認させるとあります。図の戻り先がこの業務に対応するため、公式解答例では「注文否認」としています。委託先に見積りを再提出させる見積差戻しとは区別します。

設問2(1)(e)

状態11から状態12へ進むイベントは注文請入力完了で、状態12から状態13へ進むイベントはD社による注文請確認です。したがって、状態12では委託先が注文請書を提出して開発に着手していても、D社はまだその確認を待っています。公式解答例では「注文請確認待ち」としています。採点講評では「納品待ち」という誤答が多かったとし、次のイベントがD社の注文請確認であることに着目するよう示しています。

設問2(2)

納品差戻しは、D社が納品物を確認し、注文書に記載された納品物と一致しない場合に行います。確認を行っているのは状態15の納品物確認中なので、矢印の始点は15です。差戻し後は委託先が再び作業を行い、D社は納品を待つ段階へ戻ります。この組合せは状態13の納品待ち／委託開発中です。公式解答例では、始点を「15」、終点を「13」としています。

設問3(1)(f)

本文の注文業務では、承認した見積書に基づいて注文書を作成します。表1の注文ファイルには、その注文がどの見積りに基づくかを関連付ける属性が必要です。見積ファイルの主キーは見積番号なので、これを注文ファイルに持たせることで、元の見積内容を参照できます。公式解答例では、空欄fを「見積番号」としています。

設問3(1)(g)

納品受領では、納品物が注文書に記載された納品物と一致するか確認します。そのため、納品ファイルには、どの注文に対する納品かを関連付ける属性が必要です。表1の注文ファイルの主キーは注文番号であり、納品ファイルにこれを持たせれば対象の注文を参照できます。公式解答例では、空欄gを「注文番号」としています。

設問3(2)

本文の見積受領では、見積内容を承認しない場合に差し戻し、再提出を求め、差戻し前の内容と確認結果も履歴として残します。同じ見積依頼に対して提出が繰り返されるため、見積履歴番号が必要になります。公式解答例では「見積りの差戻しによって再提出が発生するケース」としています。25字以内では、差戻しによる再提出という具体的なケースを示します。採点講評では、納期や見積条件の変更は新たな案件番号や別レコードにつながるとして、この履歴の説明と混同しないよう示しています。

設問3(3)

〔新システムの業務要件〕(3)では、案件の開始から完了までの経緯をシステムで追跡できるようにするとあります。現在は書類の日付と署名を確認する必要があるため、作成者コードと作成日を保存し、誰がいつ作成したかを追えるようにします。公式解答例では、目的を「案件の開始から完了に至るまでの経緯についてシステムで追跡調査を行うため」としています。40字以内では、案件全体の経緯をシステムで追跡する目的を示します。同様に、誰がいつ承認したかを残す属性として、公式解答例では「承認者コード」と「承認日」を挙げています。

学習のポイント

業務要件と図表を対応付け、作業主体、遷移の契機、履歴を残す理由を区別して読み取ることが重点です。