平成27年度 秋期 午後Ⅰ

本文の根拠

〔金融機関とのデータ連携の概要〕

振替依頼データの個別コードは，請求レコードを一意に特定する属性である。業務システムでは，自システム内の請求データを一意に特定する値（以下，請求コードという）を個別コードに設定している。

〔新システムの機能設計〕(2) 振替依頼データ送信機能

請求レコードの個別コードには，集約請求データのシステムコードと請求コードとを結合して設定する。

〔新システムの機能設計〕(3) 振替結果データ受信機能

受領した振替結果データの個別コードの値から集約請求データを特定し，引落結果コードの値を集約請求データの引落結果コードに設定する。

請求コードは，各業務システムが「自システム内の」請求データを一意に特定する値である。業務システムどうしで採番を調整しているわけではないので，別の業務システムが同じ請求コードを使うことがありうる。新システムは全業務システムの請求データを集約請求データに集め，金融機関単位に振替依頼データを作るので，請求コードをそのまま個別コードにすると，一つの振替依頼データの中で個別コードが重複しかねない。

個別コードは請求レコードを一意に特定する属性で，振替結果データ受信機能は個別コードの値から集約請求データを特定する。重複があると引落結果をどの請求に反映すればよいか決まらない。そこで，どの業務システムから受領したかを表すシステムコードを結合し，全社で一意になる値にしている。表1 の集約請求データの主キーがシステムコードと請求コードの組になっているのも同じ理由である。講評は，システムコードに関する解答が散見されたとしている。問われているのは請求コードをそのまま使わなかった理由であり，システムコードを結合する手段ではない。

35字で「請求コード」が「複数の業務システムで同じ値になる」ことを書く。解答例は「請求コードは複数の業務システムで同じ値になる可能性があるから」で30字。

採点講評（IPA）

設問1では，複数の業務システムからデータを受領する新システムにおける，請求コードに関する設計で考察すべきポイントを問うたが，システムコードに関する解答が散見された。設問として求めている内容を理解して解答してほしい。

本文の根拠

〔新システムへの要望〕

新システムを利用する際には，利用者が担当する業務システムのデータだけが表示されるようにしてほしい。

〔新システムの機能設計〕(5) 認証機能

利用者が担当している業務システムのシステムコードを，担当システムデータとして管理する。

〔新システムの機能設計〕(1) データ受付機能

集約請求データには，全業務システムのデータが格納される。

〔新システムの機能設計〕(6) 集約請求データ照会機能

ただし，ある属性の値は，暗黙の検索条件として新システムで設定する。

集約請求データには全業務システムのデータが格納されるので，任意の条件で照会させると，利用者は担当外の業務システムのデータまで見られてしまう。要望は，利用者が担当する業務システムのデータだけを表示することである。

認証機能では，利用者が担当している業務システムのシステムコードを担当システムデータとして管理している。ログインした利用者 ID から担当システムデータのシステムコードを引き，集約請求データのシステムコードをその値に限る条件を，利用者が入力しなくても新システムが自動で付け加える。これが暗黙の検索条件である。集約請求データの属性のうち，どの業務システムのデータかを表すのはシステムコードだけである。

属性名は表1 の表記どおり「システムコード」。目的は30字で，要望の文言「利用者が担当する業務システムのデータだけを表示する」を使う。解答例は27字。

本文の根拠

〔新システムへの要望〕

当月に振り替えられた業務システム別の引落金額合計を，新システムから帳票に出力してほしい。

〔金融機関とのデータ連携の概要〕

引落口座から収納口座に全額振り替えられた場合は，請求レコードの引落結果コードに，“引落済み”が，資金不足によって振り替えられなかった場合は，“資金不足”が設定されている。

表1 集約請求データ

システムコード（主キー），請求コード（主キー），ステータス，引落日，引落金融機関番号，引落支店番号，引落預金種目，引落口座番号，引落金額，引落結果コード

帳票に出すのは「当月に」「振り替えられた」請求の引落金額合計である。条件は二つに分かれる。一つは当月の請求であることで，集約請求データの引落日が出力対象月内の日であればよい。引落しは毎月10日又は20日で，休業日なら翌営業日にずれるので，特定の日付ではなく月内の日という条件にする。

もう一つは実際に振り替えられたことで，引落結果コードが“引落済み”のものに限る。資金不足で振り替えられなかった請求は“資金不足”が設定されるので，これを含めると合計が実際の振替額と合わなくなる。ステータスを条件にしても，“振替結果受領”や“振替結果返却済み”には資金不足の請求も含まれるので，振り替えられたかどうかは区別できない。業務システム別の集計はシステムコードで分ければよく，抽出条件ではない。

条件はそれぞれ15字以内。解答例は「出力対象月内の日であること」13字と「“引落済み”であること」11字。値は本文の表記“引落済み”のまま書く。

本文の根拠

〔新システムへの追加要望〕

金融機関への振替依頼データの送信を，集約請求データ 1 件単位で停止する機能を追加してほしいという要望が提示された。

〔新システムへの追加要望〕

停止可能な集約請求データのステータスを“振替依頼停止”に変更することで，振替依頼データ送信機能で抽出対象外となる。

〔新システムの機能設計〕(2) 振替依頼データ送信機能

集約請求データからステータスが“振替依頼待ち”のデータを金融機関単位に抽出し，図 2 のフォーマットに編集して金融機関に送信する。

止めたいのは金融機関への振替依頼データの送信である。送信は振替依頼データ送信機能が，ステータスが“振替依頼待ち”の集約請求データを抽出して行う。ステータスを“振替依頼停止”に変えれば抽出対象から外れるので，送信を止められる。

逆に，送信した後のデータはステータスが“振替依頼中”以降になっており，既に金融機関に依頼が渡っているので，新システムで止めることはできない。表2 のとおり，ステータスはデータ受付機能で“振替依頼待ち”になり，振替依頼データ送信機能で“振替依頼中”に変わる。停止できるのはその間，つまりステータスが“振替依頼待ち”の間だけである。

「表1 中の属性名を用いて」とあるので，属性名「ステータス」と値“振替依頼待ち”を組にして書く。解答例は「ステータスが“振替依頼待ち”の集約請求データ」。

本文の根拠

〔新システムへの要望〕

金融機関からの振替結果データは，全て新システムで受領し，業務システムに送信してほしい。その際，業務システムから新システムに送信した，全ての振替依頼データの処理結果を送信してほしい。

〔新システムの機能設計〕(4) データ返却機能

引落日の 3 営業日後に，ステータスが“振替結果受領”の集約請求データを業務システム単位に抽出し，図 2 のフォーマットで業務システムに送信する。

〔新システムへの追加要望〕

しかし，この機能追加によって〔新システムの機能設計〕で行ったある機能設計では〔新システムへの要望〕を満たせなくなるので，設計を一部変更する必要がある。

要望は，業務システムから送信された「全ての」振替依頼データの処理結果を業務システムに返すことである。ところがデータ返却機能は，ステータスが“振替結果受領”の集約請求データだけを抽出して返す。振替依頼を停止したデータはステータスが“振替依頼停止”のまま金融機関に送られず，振替結果データも来ないので，“振替結果受領”にならない。このままでは停止したデータの処理結果が業務システムに返らず，要望を満たせない。

そこで変更するのはデータ返却機能で，抽出条件に“振替依頼停止”を加え，“振替結果受領”と“振替依頼停止”の集約請求データを抽出して返す。振替依頼データ送信機能は“振替依頼待ち”だけを抽出するので停止の影響を受けず，振替結果データ受信機能も受け取ったデータを処理するだけなので，変更は要らない。講評は，機能名の正答率は高かったが，変更内容の記述がない解答が散見されたとしている。

機能名は本文の表記どおり「データ返却機能」。変更内容は40字で，抽出するステータスの値を二つとも書く。解答例は「ステータスが“振替結果受領”と“振替依頼停止”の集約請求データを抽出する。」で37字。

採点講評（IPA）

設問4(2)は，業務機能の追加が新システムの機能設計に与える影響を考察する設問であった。機能については，正答率が高かったが，変更内容の記述がない解答が散見された。業務要件と機能設計を関連付けて理解・把握して解答してほしい。

本文の根拠

〔B 社の業務の概要〕(5)

在庫管理業務の一環として，同じ営業所グループの他の営業所から商品を融通してもらうことがある。

〔B 社の現行システムの概要〕(7)

他の営業所から商品を融通してもらう場合，商品を譲り受ける営業所で倉庫間移動入庫をシステムに登録し，商品を譲った営業所がシステムで承認する。承認後，商品の受渡しを行う。

〔移行方法の具体化〕(3)

また，ある業務における一部の処理を，移行期間中も問題なく行うためには，移行単位を営業所グループごとにする必要がある。

営業所グループが業務に出てくるのは，在庫管理業務の一環としての商品の融通だけである。融通は同じ営業所グループの他の営業所との間で行う。したがって「ある業務」は在庫管理業務で，「一部の処理」は商品の融通である。

融通では，譲り受ける営業所が倉庫間移動入庫をシステムに登録し，譲った営業所が同じシステムで承認してから商品を受け渡す。移行期間中は，移行した営業所は新システムだけを，移行前の営業所は現行システムを使う。同じグループの中で使うシステムが分かれると，一方が登録した倉庫間移動入庫をもう一方が承認できず，融通ができなくなる。グループごとにまとめて移行すれば，グループ内の営業所は常に同じシステムを使う。

業務名は本文の表記どおり「在庫管理業務」。理由は40字で「利用しているシステムが異なる」と「商品の融通ができなくなる」を因果でつなぐ。解答例は34字。

本文の根拠

〔新システムへの移行方針〕

現行システムと新システム（以下，両システムという）のマスタは互換性がないが，ツールの使用と手作業による項目追加によって，マスタデータの移行は可能である。

〔新システムへの移行方針〕

しかし，本社システムのトランザクションデータは，両システムで互換性がなく，新システムでは読み込めない。

〔移行方法の具体化〕(2)

本社では，両システムを 1 月から 6 月まで併用する。その間，本社で行う，従業員マスタ，自販機マスタ，商品マスタなどの修正業務については，両システムに同じ修正データを入力する。

移行期間中は，現行システムを使う営業所も新システムを使う営業所もあるので，本社はマスタの修正を両方のシステムに反映しなければならない。現行システムの営業所システムは本社システムからマスタを受け取って動作し，新システムでは全社の管理帳票などを出力するからである。

片方に入力したデータをもう片方に送れれば二重入力は要らない。しかし，マスタ修正は本社で行う処理なので，その結果は本社システムのトランザクションデータになる。本社システムのトランザクションデータは両システムで互換性がなく，新システムでは読み込めない。営業所システムのトランザクションデータは互換性があって夜間に転送できるのと対照的である。マスタデータそのものも互換性がなく，移行はツールと手作業の項目追加が要る一度きりの作業である。講評は，“互換性”“整合性”を書いていても，現行システムと新システム，本社システムと営業所システムの区別がついていない解答が散見されたとしている。

40字で「本社システムのトランザクションデータ」を主語にし，「新システムでは読み込めない」ことを書く。解答例は34字で，「互換性がないから」とした27字の別解もある。

採点講評（IPA）

設問2(1)は，並行運用期間中，本社が現行システムと新システムに同じデータを入力し続ける必要がある理由を問うた。“互換性”，“整合性”の記述はあるが，“現行システム”と“新システム”，“本社システム”と“営業所システム”の区別のついていない解答が散見された。

本文の根拠

〔B 社の現行システムの概要〕(3)

営業員は自販機から売上金を回収し，HT を自販機と通信させ，売上額を HT に入力して，売上計上処理を行う。さらに，自販機から収集した売上情報を基に HT が算出した補充数だけ，商品を補充する。自販機が保持している売上情報は，HT と一度通信するとクリアされる。

〔新システムの概要〕(3)

HT の機能，自販機と HT との通信仕様は，現行システムと同じである。

〔移行方法の具体化〕(3)

営業所には，一度システムで実施すると再度実施できない業務があるので，移行した営業所は，新システムだけを利用する。

営業員は HT を自販機と通信させて売上計上処理を行い，自販機から収集した売上情報を基に HT が算出した補充数だけ商品を補充する。ところが自販機が保持している売上情報は，HT と一度通信するとクリアされる。新システムの HT も自販機との通信仕様は同じなので，現行 HT で一度通信した自販機の売上情報を，新 HT でもう一度取ることはできない。

したがって，売上情報を使う売上計上業務と商品補充業務は，一度実施すると再度実施できない。両システムで同じ自販機を扱えば，片方では売上も補充数も分からなくなる。移行した営業所が新システムだけを使うのはこのためである。二つの業務はどちらも〔B 社の業務の概要〕(6)に業務名として挙がっている。

業務名は本文の表記どおり「売上計上業務」「商品補充業務」。理由は30字で，「HT と通信すると売上情報をクリアする」ことを書く。解答例は24字で，「売上情報が1回しか取得できず，補充数が算出できない」とした27字の別解もある。

本文の根拠

〔B 社の業務の概要〕(7)

手数料支払業務：営業所では，自販機設置先への手数料支払を行う。

〔新システムの概要〕(6)

日次処理はセンタサーバで夜間定時に実行され，手数料計算処理を行う。手数料計算書は，本社で一括して印刷・送付する。手数料振込みも本社で一括して行う。

〔移行方法の具体化〕(5)

移行期間中は，現行システムを利用している営業所の営業所トランザクションデータを日次処理前に抽出し，本社の現行システム経由で新システムに，夜間に一括転送して新システムでも日次処理を実行する。

現行では，手数料支払業務（手数料計算，手数料計算書作成・送付，振込み）は営業所で行っている。新システムでは，手数料計算は夜間の日次処理で行われ，手数料計算書の印刷・送付も振込みも本社で一括して行う。

移行期間中，現行システムを使う営業所のトランザクションデータは夜間に新システムへ転送され，新システムでも日次処理が実行される。つまり，まだ移行していない営業所の分も新システムで手数料が計算され，本社がまとめて計算書を送り，振り込む。営業所が自分で手数料支払業務を行う必要はなくなる。本社移行前日の 12 月 31 日に全営業所で手数料計算処理を行うのも，1 月からは新システム側で扱うための区切りである。

業務名は本文の表記どおり「手数料支払業務」。理由は15字しかないので，「本社で一括して行う」ことだけを書く。解答例は「本社で一括して行うから」で11字。

本文の根拠

〔B 社の業務の概要〕(7)

締日は，自販機設置先ごとに異なるが，20 日又は月末が多い。

表2 項番1

全営業所で，業務終了後，締日であるか否かにかかわらず，全ての自販機設置先の手数料計算処理を行い，帳票を作成する。

〔移行方法の説明〕

表 2 の手順で各営業所のシステムを切り替えると，12 月の手数料計算書が 2 枚に分かれることになり，業務上の問題があるとの指摘があった。

表2 の項番1 では，12 月 31 日に締日かどうかにかかわらず全ての自販機設置先の手数料計算を行う。締日が 20 日の設置先なら，12 月 20 日の締めで一度計算書を作り，さらに 12 月 21 日から 31 日までの分でもう一度作ることになり，12 月の計算書が 2 枚に分かれる。

そこで 12 月 31 日には計算せず，まだ手数料を計算していない分のデータを新システムに渡し，次の締日に新システムで 1 月分と合わせて計算させる。渡すのは，12 月の締日の翌日から 12 月末日までの自販機の売上などのトランザクションデータである。締日は設置先ごとに異なり，20 日と月末に限られないので，期間は「12 月の締日の翌日から末日まで」と締日を特定しない書き方にする。講評は，締日が例として挙げた 20 日と月末しかないと思い込んだ解答も散見されたとしている。

35字で期間（12 月の締日の翌日から末日まで）とデータの種類（自販機のトランザクションデータ）の両方を書く。解答例は31字。

採点講評（IPA）

設問3(1)は，移行方法の説明の際に営業部門から指摘された業務上の問題への対策について問うたが，想定している移行手順を理解できていないと思われる解答が多く見受けられた。また，締日が，例としてあげた20日と月末しかないと思いこんだと想定される解答も散見された。

本文の根拠

〔B 社の現行システムの概要〕(5)

営業所システムに入力された商品の注文データは，朝 1 回，本社システムに一括転送され，本社は注文データを集約し，朝 10 時に M 社に発注する。

〔新システムの概要〕(5)

新システムに入力された営業所の注文は，朝 10 時で締め切られ，その後 M 社に自動的に発注される。

〔移行方法の具体化〕(5)

移行期間中は，現行システムを利用している営業所の営業所トランザクションデータを日次処理前に抽出し，本社の現行システム経由で新システムに，夜間に一括転送して新システムでも日次処理を実行する。

〔移行方法の具体化〕(6)

M 社への発注は，新システムの機能を利用して，新システムだけから行う。

現行では，営業所が毎朝入力した注文は朝 1 回本社システムに転送され，その日の朝 10 時に M 社に発注される。移行期間中は，M 社への発注は新システムだけから行い，新システムは朝 10 時で注文を締め切る。

現行システムを使う営業所の注文も営業所トランザクションデータなので，新システムに届くのは夜間の一括転送のときである。朝に入力した注文が新システムに入るのはその日の 10 時の締切より後なので，発注は翌日の朝 10 時になり，今までより 1 日遅れる。講評は，移行終了後の業務の変更点と誤解した解答が多かったとしている。問われているのは移行期間中だけの制約である。

異なる点は15字で「1 日遅れて発注される」こと。理由は35字で，処理タイミングとして「新システムに転送するのは 10 時以降」であることを書く。解答例は12字と28字。

採点講評（IPA）

設問3(2)は，移行期間中だけの制限事項について，その内容と理由を問うたが，移行終了後の業務の変更点と誤解したと想定される解答が多かった。問題文をよく読んで，現行業務の内容，現在の移行手順，移行計画の全体の内容を理解して解答してほしい。

本文の根拠

〔新システムの業務要件〕(4)

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

〔新システムの設計〕

それぞれの作業の進捗状況は別々に管理され，委託先トップ画面に表示するステータスは，委託先ステータスである。

新システムは案件ごとに D 社ステータスと委託先ステータスを別々に持つ。図2 を見ると，D 社ステータスには“見積内容確認中”“注文承認待ち”のように，見積りの審査や管理責任者の承認といった D 社社内の手続の段階が現れる。

業務要件(4)は，委託先と情報を共有しても社内の手続の状況は委託先に開示しないことを求めている。委託先トップ画面に D 社ステータスを出すと，社内で審査中か承認待ちかといった状況が委託先に見えてしまう。委託先ステータスだけを表示すれば，委託先には自分が何をすべきかだけが伝わり，要件を満たせる。

30字で業務要件(4)の文言をそのまま目的の形にする。解答例は「社内の手続の状況が委託先に開示されないようにするため」で26字。

採点講評（IPA）

設問1は，(1)は正答率が高く，(3)は正答率が低かった。(3)では，“D社が差し戻したときは電子メールが送信されない”，“新システムでも書類を郵送して時間が掛かっている”などと勘違いしたと想定される解答が多く見受けられた。これは，問題文の理解不足と思われる。

本文の根拠

〔新システムの設計〕(1) 通知案件一覧

ある案件に対して，D 社が処理を完了したことによって委託先が対応すべき作業が発生した場合，そのことを委託先に知らせるために，委託先に電子メール（以下，メールという）を送信し，当該案件を通知案件一覧に表示する。

〔現在の業務委託管理に関する業務の概要〕(3)

その後，管理責任者が，見積り及び注文の内容を審査し，承認又は否認を行う。否認した場合は，委託責任者に見積内容を再度確認させる。承認した場合は，注文書を発行し，委託先に注文する。委託先は注文書の内容を確認し，注文請書を発行して開発に着手する。

通知案件一覧に載るのは，D 社の処理の完了によって委託先の作業が発生した案件である。例示の状態番号2 は，D 社の【見積依頼入力完了】で委託先ステータスが“見積依頼確認待ち”になった状態である。同じように，D 社のイベントで委託先に確認や入力の作業が生じる遷移を図2 から探す。

状態9 からc（注文承認）で状態10 に移ると，委託先ステータスは“注文確認待ち”になる。管理責任者の承認で注文書が発行され，委託先が注文書の内容を確認する作業が発生するので，これがもう一つである。【見積差戻し】も状態2 に戻るが，状態番号としては2 と同じである。【見積依頼確認】【見積入力完了】など委託先自身のイベントや，D 社の確認・承認で委託先ステータスが変わらない遷移（状態5→6，状態12→13）は通知の対象ではない。

状態番号は図2 の番号をそのまま答える。解答例は「10」。

本文の根拠

〔新システムの設計〕(1) 通知案件一覧

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

〔新システムの設計〕

委託先トップ画面には，委託先が遅滞なく手続を進められるように，次の一覧を表示する領域を設けた。

委託先に作業が発生したことは，まずメールで知らせる。それでも同じ案件を委託先トップ画面の通知案件一覧にも表示するのは，メールだけでは知らせが届かないことがあるからである。委託先がメールを見落とせば，対応すべき作業が発生したことに気付かず，手続が止まってしまう。

委託先トップ画面の一覧は，委託先が遅滞なく手続を進められるように設けたものである。画面を開けば通知案件一覧で新しく発生した作業が分かるので，メールを見落としても気付ける。講評は，“D 社が差し戻したときは電子メールが送信されない”“新システムでも書類を郵送して時間が掛かっている”などの勘違いが多く，正答率が低かったとしている。また問全体の講評で，“どのようなケースか”と問う設問（この設問と設問3(2)）に目的や理由を答えた誤りが目立ったとしている。答えはケースの形で書く。

40字で「委託先がメールを見落とす」ことと，その結果「作業の発生に気付かない」ことを書き，「ケース」で結ぶ。解答例は33字。

採点講評（IPA）

設問1は，(1)は正答率が高く，(3)は正答率が低かった。(3)では，“D社が差し戻したときは電子メールが送信されない”，“新システムでも書類を郵送して時間が掛かっている”などと勘違いしたと想定される解答が多く見受けられた。これは，問題文の理解不足と思われる。

本文の根拠

〔新システムの設計〕(2) 未済案件一覧

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

〔現在の業務委託管理に関する業務の概要〕(3)

委託先は注文書の内容を確認し，注文請書を発行して開発に着手する。委託責任者は，注文請書を受け取ると，委託先が開発に着手したとして，納品を待つ。

図2 の状態のうち，委託先が作業を行うべきものを委託先ステータスで拾う。状態2（見積依頼確認待ち），3（見積入力待ち），4（b見積入力中），10（注文確認待ち），11（注文請入力待ち），12・13（委託開発中），14（納品入力中）がそれに当たる。状態5〜9 と15 は委託先ステータスが“見積送信済”“納品物確認待ち”で，D 社の処理を待っている。

このうち状態2 と10 は，D 社の処理の完了で委託先の作業が発生した直後の状態で，通知案件一覧に表示される（設問1(2)）。未済案件一覧は通知案件一覧に表示されていない案件なので，これを除いた 3，4，11，12，13，14 の六つになる。状態12 と13 は D 社側が注文請の確認待ちか納品待ちかの違いだけで，委託先はどちらも開発中である。

状態番号を六つ全て答える。状態12・13 の“委託開発中”を作業中と数えるかで迷いやすいが，開発も委託先が行うべき作業である。解答例は「3，4，11，12，13，14」。

本文の根拠

〔現在の業務委託管理に関する業務の概要〕(3)

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

〔現在の業務委託管理に関する業務の概要〕(3)

委託責任者は，注文請書を受け取ると，委託先が開発に着手したとして，納品を待つ。

〔新システムの設計〕

また，図中の状態番号は，D 社ステータスと委託先ステータスの組合せによる一意の状態に対して，1 から昇順に付与した番号である。

a・b は状態4 で，委託先が【見積入力】を行い【見積入力完了】の前の状態である。D 社はまだ見積りを受け取っていないので，状態2・3 と同じ“見積待ち”のまま。委託先は見積りを入力している途中なので，“見積依頼入力中”“注文入力中”“納品入力中”にならって“見積入力中”とする。

c・d は状態9（注文承認待ち）から出るイベントで，管理責任者の承認又は否認である。“注文承認”なら注文書が発行されて状態10（注文確認待ち）へ進む。“注文否認”なら委託責任者に見積内容を再度確認させるので，結合子B を経て状態6（見積内容確認中）に戻る。e は状態12 の D 社ステータスで，委託先が【注文請入力完了】した後，D 社が【注文請確認】を行う前の状態なので“注文請確認待ち”である。講評は，e を“納品待ち”とした誤りが多かったとしている。“納品待ち”は【注文請確認】の後の状態13 の値で，状態番号は組合せごとに一意なので状態12 と同じ組合せにはならない。

図中の他のステータス・イベント名の語形（“〜待ち”“〜中”）にそろえて書く。

採点講評（IPA）

設問2(1)は，全体として正答率が高かったが，eを“納品待ち”と誤って解答した受験者が多かった。次に来るイベントがD社の“注文請確認”という行為であることに気付けば解答できるはずである。

本文の根拠

〔現在の業務委託管理に関する業務の概要〕(4)

注文書に記載された納品物と一致していれば，承認して納品年月日を管理システムに登録し，一致していなければ差し戻す。納品物を差し戻した場合でも納品の履歴は残す。

〔新システムの設計〕

ここで，図 2 では案件中止，納品差戻し及び検査以降の遷移は省略している。

納品物の確認は，状態15（納品物確認中／納品物確認待ち）で D 社が行う。一致していれば【納品物承認】で検査以降に進み，一致していなければ差し戻す。したがって納品差戻しの矢印の始点は状態15 である。

差し戻された委託先は，納品物を作り直してから改めて納品する必要がある。その状態は，D 社が“納品待ち”，委託先が“委託開発中”の状態13 で，そこから再び【納品入力】で状態14 に進む。状態14（納品入力中）は【納品入力】の後の状態なので，差戻しの行き先にはならない。見積りの差戻しが状態2 に戻るのと同じく，相手が作業をやり直す前の状態に戻すと考える。

状態番号は図2 の番号で答える。解答例は始点15，終点13。

本文の根拠

〔現在の業務委託管理に関する業務の概要〕(3)

委託責任者は，見積内容を承認すると，見積書に基づいて注文書を作成する。注文書には，見積依頼書及び見積書に記載された内容に，委託金額，検収予定日及び支払予定日が追記され，この内容は管理システムに登録される。

〔現在の業務委託管理に関する業務の概要〕(4)

注文書に記載された納品物と一致していれば，承認して納品年月日を管理システムに登録し，一致していなければ差し戻す。

表1 見積

見積番号（主キー），見積依頼番号，見積履歴番号

表1 のファイルは，見積依頼が案件番号を，見積が見積依頼番号を持つように，前の段階のファイルの主キーを持ってつながっている。注文ファイルには，この連鎖の中で見積を指す属性が無い。注文書は承認された見積書に基づいて作成し，見積依頼書及び見積書の内容を引き継ぐので，どの見積に基づく注文かを表す見積番号を f に置く。見積は差戻しで同じ見積依頼番号に複数できるので，見積依頼番号ではなく見積番号で特定する。

納品ファイルも同じで，納品物は注文書に記載された納品物と突き合わせて確認する。どの注文に対する納品かを表す注文番号を g に置く。注文請ファイルは主キーが注文番号で，注文と1対1に対応している。

属性名は表1 の表記どおり「見積番号」「注文番号」と書く。

本文の根拠

〔現在の業務委託管理に関する業務の概要〕(2)

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

〔現在の業務委託管理に関する業務の概要〕(4)

なお，D 社では個別契約は納期ごとに締結し，納期が異なる場合は別の個別契約を締結する。

同一の見積依頼番号に見積が複数できるのは，委託責任者が見積内容を承認せずに差し戻し，委託先が見積書を再提出するときである。差し戻した場合でも見積内容及び確認結果の履歴を残すので，見積履歴番号で何回目の見積りかを区別する。図2 でも【見積差戻し】で状態2 に戻り，再び見積りが入力される。

講評は，“納期が変更になった場合”“見積条件が変わった場合”などの誤りがあったとしている。納期が異なる場合は別の個別契約になるので，新たな案件番号が付与され，見積依頼も別レコードになる。同一見積依頼番号の中での履歴にはならない。また問全体の講評で，“どのようなケースか”と問う設問（この設問と設問1(3)）に目的や理由を答えた誤りが目立ったとしている。

25字で「見積りの差戻し」と「再提出」をつなぎ，「ケース」で結ぶ。解答例は22字。

採点講評（IPA）

設問3(2)では，見積履歴番号の設定について問うたが，正答率が低かった。“納期が変更になった場合”，“見積条件が変わった場合”などの解答があったが，納期や見積条件が変わる場合は，新たな案件番号が付与され，見積依頼も別レコードとなることに気付いてほしかった。

本文の根拠

〔新システムの業務要件〕(3)

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

〔現在の業務委託管理に関する業務の概要〕(6)

各書類には，作成者が日付を記入し，署名する。承認が必要な書類には，承認者も日付を記入し，署名する。

現在は，案件の経緯を追跡調査するには全ての書類の日付と署名を確認しなければならない。業務要件(3)は，これを新システムで追跡できるようにすることである。書類の作成者の署名と日付に当たるものを，見積依頼から納品までの各ファイルに作成者コードと作成日として持たせれば，誰がいつ作成したかをシステムで追える。

書類には作成者のほかに，承認が必要な書類では承認者も日付を記入し，署名する。表1 で見ると，見積・注文・納品のファイルに承認者コードと承認日があり，これが同様の目的で設定した二つの属性である。見積年月日や注文年月日は書類そのものの日付で，誰が処理したかは表さない。

目的は40字で，業務要件(3)の「案件の開始から完了」「経緯」「追跡調査」を使う。解答例は35字。属性名は表1 の表記どおり「承認者コード」「承認日」。

本文の根拠

〔従来の監視 UAS の概要〕

オペレータが，無人機に監視させたい地点，時間及び着陸地点を含む飛行計画を指定すると，地上局は，無人機の現在位置から自律飛行に必要な複数の飛行経由地点を自動的に決定する。このとき，飛行禁止空域を含む，航空法に適合した 3 次元地形データを参照する。

表2 通信部

ウェイポイント情報を制御部から，操作指令を制御部又は防災センタから，操縦指令を操縦端末からそれぞれ受け取り，無人機に送信する。

〔新監視 UAS の構成〕④

防災センタでは，地上局と同じ映像を表示でき，監視カメラの操作もできる。

b：飛行計画と 3 次元地形データから，地上局は自律飛行に必要な飛行経由地点を決め，それをまとめたウェイポイント情報を無人機に送る。表2 の通信部も「ウェイポイント情報を制御部から」受け取るとしているので，制御部が生成して通信部に送るのはウェイポイント情報である。

c：通信部は監視カメラの映像と監視用センサのデータを受信し，制御部とディスプレイのほかにもう一か所へ送る。防災センタでは地上局と同じ映像を表示でき，要望⑥も防災センタでの監視対象の情報のリアルタイムな共有を求めている。通信部は高速通信回線で防災センタとつながっており（図2），防災センタからの操作指令も受け取るので，送り先は防災センタである。

字句は本文の表記どおり「ウェイポイント情報」「防災センタ」と書く。

本文の根拠

〔新監視 UAS の運用〕①

一つの地上局には，設営と監視カメラの操作を行う要員を配置する。

〔新監視 UAS の構成〕④

防災センタでは，地上局と同じ映像を表示でき，監視カメラの操作もできる。

表1 監視カメラ・監視用センサ

監視カメラの操作は，地上局又は防災センタからの操作指令に従って行われる。

防災センタは地上局と同じ映像を表示できるので，映像を見るだけなら情報の共有はできている。監視カメラを操作できるようにする利点は，防災センタが見たいものを自分で見られることである。操作できなければ，防災センタは見たい場所や向きを地上局に伝え，地上局の要員に監視カメラを操作してもらうしかない。

監視カメラの操作は地上局又は防災センタからの操作指令に従って行われる。防災センタから直接操作すれば，地上局の要員を介さずに，必要な監視対象の情報をすぐに得られる。講評は，“情報を共有できるようになる”という解答が散見されたとしている。映像を見られる点で共有は既にできており，問われているのはカメラを操作できることによる利点である。

45字で「地上局の要員を介さずに」と「監視対象の情報が得られる」を書く。解答例は40字。

採点講評（IPA）

設問1(2)では，防災センタから監視カメラを操作できるようにすることの利点を問うたが，“情報を共有できるようになる”との解答が散見された。防災センタでも映像を見ることができる点で情報共有が行われており，監視カメラを操作できることで得られる利点を解答してもらいたかった。

本文の根拠

〔新監視 UAS に対する要望〕

⑤ 連続監視時間を長くしてほしい。

表1 飛行時間・速度

連続飛行時間：最大30分

〔無人機の 2 機同時運用〕②

2 機の無人機の飛行開始時刻をずらして運用することによって，aという要望にも応えることができる。

無人機はバッテリを動力源とし，連続飛行時間は最大30分である。1 機だけでは，バッテリが切れる前に帰還させなければならず，その間は監視が途切れる。2 機の飛行開始時刻をずらせば，1 機が帰還する頃にもう 1 機が監視を続けられるので，監視全体を長く続けられる。

空欄は「〜という要望」とあるので，〔新監視 UAS に対する要望〕の中から当てはまるものを選ぶ。飛行開始時刻をずらすことで応えられるのは，時間に関わる要望⑤「連続監視時間を長くしてほしい」である。

20字以内なので要望⑤の文言をそのまま使う。解答例は「連続監視時間を長くしてほしい」で14字。

本文の根拠

〔無人機の 2 機同時運用〕①

もう 1 機に地上局から電波が届かなくても，無人機間の無線データ通信ができれば，無線中継によって遠隔操縦飛行及び監視を行うことができる。

〔無人機の 2 機同時運用〕③

無線データ通信は，他のアクセスポイントを介さずに行う方式とする。

表1 通信機能

受信したデータが自機宛てでなく，もともと自機から送信したものでなければ，そのデータをそのまま送信する。

無線中継では，地上局から電波の届く範囲にいる無人機が，地上局ともう 1 機の間のデータを受け渡す。無線データ通信は他のアクセスポイントを介さない方式なので，中継は無人機自身の通信機能で行うしかない。

表1 の通信機能の三つ目がこれに当たる。受信したデータが自機宛てでなければ，他の無人機か地上局に宛てたものなので，そのまま送信して相手に届ける。ただし，もともと自機から送信したデータまで送り返すと，同じデータが行き来し続けてしまうので除く。二つの条件がそろって初めて中継が成り立つ。

55字で表1 の文を条件ごとそのまま書く。解答例は51字。

本文の根拠

〔従来の監視 UAS の概要〕

このとき，飛行禁止空域を含む，航空法に適合した 3 次元地形データを参照する。

表2 制御部

航法センサからのデータを用いて，無人機の位置，速度，方角などの表示処理を行い，ディスプレイに送るとともに，通信部経由で防災センタに送信する。

表2 制御部

遠隔操縦飛行の場合，ナビゲーションに用いる模擬画像を生成し，操縦端末に送る。

カメラ映像の代わりに，制御部で進行方向の様子を再現した模擬画像を作る。地上の地形や障害物の形は，地上局が飛行経由地点を決めるときに参照している 3 次元地形データから分かる。無人機がどこをどの向き・速さで飛んでいるかは，航法センサのデータから分かり，制御部はこれを使って位置，速度，方角の表示処理を既に行っている。

二つを組み合わせれば，無人機の位置から見た地形を描いた模擬画像を生成できる。航法センサのデータは無人機から受信する小さなデータなので，映像を送るような伝送の負担もない。どちらも地上局の制御部が既に手元に持っているデータである。

字句は本文の表記どおり「3次元地形データ」「航法センサのデータ」と書く。d と e は順不同。

本文の根拠

〔無人機の 2 機同時運用〕③

伝送速度は，無人機 2 機の飛行制御に必要な情報の送受信ができ，さらに無人機 1 機の監視カメラ及び監視用センサの制御と映像データなどの送受信が支障なく行えるように定める。

〔操縦端末の表示画像の検討〕

しかし，無線データ通信の制約から，この方法は困難と判断した。

無線データ通信の伝送速度は，無人機 2 機の飛行制御の情報と，無人機 1 機の監視カメラの映像データなどを送受信できるように定められている。カメラを追加して進行方向の映像も送ると，監視カメラの映像に加えてもう一本の映像を送ることになり，想定した伝送速度を超える。

伝送が追いつかなければ，操縦端末に表示される追加カメラの映像が遅れる。遠隔操縦は操縦者が画面を見ながら操作するので，映像が遅れては操縦に使えない。これが困難と判断した根拠である。講評は，“見通せる範囲での通信”“5km の範囲での通信”といった距離の制約を書いた解答が散見されたとしている。問題文から読み取るべきは伝送速度の制約である。

35字で「追加カメラ映像のリアルタイム性が確保できない」ことを書く。解答例は33字。

採点講評（IPA）

設問3(2)では，操縦用にカメラを追加することが困難と判断した無線データ通信の制約について問うたが，“見通せる範囲での通信”，“5kmの範囲での通信”などの解答が散見された。無線データ通信の伝送速度の制約を問題文から読み取ってほしかった。

本文の根拠

〔従来の監視 UAS の概要〕

オペレータが，無人機に監視させたい地点，時間及び着陸地点を含む飛行計画を指定すると，地上局は，無人機の現在位置から自律飛行に必要な複数の飛行経由地点を自動的に決定する。このとき，飛行禁止空域を含む，航空法に適合した 3 次元地形データを参照する。

〔遠隔操縦飛行の検討〕

遠隔操縦飛行中の無人機は，自機の現在位置を把握できても，その位置から着陸地点までの最短経路が分からないので，着陸地点まで飛行できる範囲内かどうか判断できない。

着陸地点までの経路を決めるには，途中の山や飛行禁止空域を避けなければならない。その判断に使うのが航空法に適合した 3 次元地形データで，これを参照して飛行経由地点を決めているのは地上局である。無人機は航法センサで自機の現在位置は分かるが，3 次元地形データを持っていないので，自分で経路を生成できない。

そこで地上局が，無人機からデータを受信するたびにウェイポイント情報を生成して無人機に送る設計にしている。講評は，“ウェイポイント情報を保持していないから”という解答が見られたとしている。ウェイポイント情報は地上局から受け取れるもので，最短経路を生成できない根本の理由は，経路を作る材料の 3 次元地形データが無人機に無いことである。

20字で「3 次元地形データをもっていない」ことを書く。解答例は17字。

採点講評（IPA）

設問4(1)では，遠隔操縦中の無人機が着陸地点までの最短経路を生成できない理由を問うたが，“ウェイポイント情報を保持していないから”との解答が見られた。設問の文章を理解して解答してほしかった。

本文の根拠

表1 通信機能

航法センサ及びバッテリ残量のデータを地上局へ送信し，操縦指令又はウェイポイント情報を受信する。

〔新監視 UAS の運用〕④

バッテリ残量を確認し，飛行可能な距離の限界に近づいたと判断した場合は，最後に送信したウェイポイント情報を用いた自律飛行に切り替える。

〔新監視 UAS に対する要望〕

③ 自律飛行，遠隔操縦飛行にかかわらず，無人機のバッテリ残量が低下したとき，指定した場所に確実に帰還できるようにしてほしい。

f：無人機が地上局へ送るのは，航法センサとバッテリ残量のデータである（表1 の通信機能）。着陸地点まで飛行できるかどうかは，残りのバッテリで飛べる距離で決まる。「fが着陸地点までの飛行分しかない」と判断した場合に自律飛行に切り替える，という文にも当てはまるのはバッテリ残量である。

g：無線データ通信ができなくなると，地上局から操縦指令もウェイポイント情報も届かない。無人機は最後に受信したウェイポイント情報に従って，航法センサのデータを参照しながら自分で飛ぶしかない。これは表1 の自律飛行そのものである。運用④でも，限界に近づいたら最後に送信したウェイポイント情報を用いた自律飛行に切り替えるとしている。

字句は本文の表記どおり「バッテリ残量」「自律飛行」と書く。