平成26年度 秋期 午後Ⅰ

本文の根拠

〔社内システムの強化・改善の内容〕(1)

強化・改善後は，受注システムに，見積書及び定期保守通知書の作成処理を新規に追加し，その中で工番の自動採番を行う。

〔社内システムの強化・改善の内容〕(1)

改修については，見積書を作成後，管理者の承認を受け，承認登録する。定期保守については，付帯作業の見積金額を含む定期保守通知書の作成後，管理者の承認を受け，承認登録する。いずれも，管理者の承認がなければ工番の採番はできない。

強化・改善後は，見積書及び定期保守通知書の作成処理の中で工番を自動採番する。見積書も定期保守通知書も，作成した後に管理者の承認を受けて承認登録する流れで，本文は「管理者の承認がなければ工番の採番はできない」と明記している。したがって採番は，見積書又は定期保守通知書の承認が登録された時点で行う。

作成しただけの段階では承認前なので採番できず，受注登録時では作成処理の中で採番するという強化・改善の内容に合わない。講評も，“見積書又は定期保守通知書の作成時”“受注登録時”という誤答を挙げている。表1 の番号1 と番号2 がそれぞれ“承認が登録されたとき”を終了のタイミングにしているのも，ここで次の業務（受注）へ進むことを示している。

30字で「見積書又は定期保守通知書」の両方を挙げ，「承認が登録されたとき」と結ぶ。解答例は「見積書又は定期保守通知書の承認が登録されたとき」で23字。

採点講評（IPA）

設問1は，(1)，(2)とも正答率が高かったが，(1)では，“見積書又は定期保守通知書の承認が登録されたとき”という解答に対し，“見積書又は定期保守通知書の作成時”，“受注登録時”といった誤った解答が散見された。(2)では，顧客との契約上での，案件の完了時期を問う問題であったが，“実績原価集計が終了したとき”，“工番損益が確定したとき”といった，社内的な完了時期の解答が散見された。

本文の根拠

〔案件の発生から完了までの現行業務の流れ〕(4) 売上・請求・入金

② 顧客からの入金額が，当該案件の売上額と一致していることを確認する。

〔案件の発生から完了までの現行業務の流れ〕(5) 工番別損益管理

② 入金を確認し，工番別実績原価を集計して，工番別損益を確定する。この時点で，案件は完了となる。

顧客との契約は，改修・保守の作業を実施して顧客検収を受け，売上を請求し，その代金が支払われることで果たされる。顧客の側から見た最後の行為は入金なので，契約上の完了時期は，顧客からの入金額が当該工番の売上額と一致していることを確認したときになる。

本文の業務の流れでは，(4)②で入金額が売上額と一致していることを確認し，その後の(5)②で工番別実績原価を集計して工番別損益を確定した時点を「案件は完了」としている。しかし実績原価の集計や損益の確定は A 社の社内管理の処理で，顧客は関わらない。講評も，“実績原価集計が終了したとき”“工番損益が確定したとき”という社内的な完了時期の解答が散見されたとしている。問われているのは「顧客との契約上での」完了時期である。

40字で「顧客からの入金額」「当該工番の売上額と一致」「確認したとき」を入れる。解答例は「顧客からの入金額が，当該工番の売上額と一致していることを確認したとき」で34字。

採点講評（IPA）

設問1は，(1)，(2)とも正答率が高かったが，(1)では，“見積書又は定期保守通知書の承認が登録されたとき”という解答に対し，“見積書又は定期保守通知書の作成時”，“受注登録時”といった誤った解答が散見された。(2)では，顧客との契約上での，案件の完了時期を問う問題であったが，“実績原価集計が終了したとき”，“工番損益が確定したとき”といった，社内的な完了時期の解答が散見された。

本文の根拠

〔案件の発生から完了までの現行業務の流れ〕(2) 手配計画・部品手配・作業手配

① 案件の作業時期から，手配計画を作成する。部品の手配計画として，改修及び保守に必要な部品の所要量を計算し，調達時期を決定する。また，作業の手配計画として，案件の作業量を見積もり，作業期間に合わせた作業員，機材の手配を決定する。

〔工番別進捗管理システムと工番別損益管理システムの概要〕(1)

② 手配計画の中で，手配の予定を工番別進捗マスタに登録するとき，作業時期からみて，手配の整合性をチェックし，問題があるときは，警告を表示する。

手配計画には，作業の手配計画と部品の手配計画の二つがある。作業の手配計画は作業員，機材（間に合わなければ外注）の手配で，設問はこれらを除いた「他に」何をチェックしているかを問うているので，残るのは部品の手配計画である。部品の手配計画では，必要な部品の所要量を計算し，調達時期を決定する。

整合性のチェックは「作業時期からみて」行う。作業の時期に部品が届いていなければ作業ができないので，部品手配が作業時期に合わせて計画されているかを確かめることになる。講評は，作業手配や原価に関する解答が多く正答率が低かったとしている。作業員・外注・機材は設問文が既に除いており，原価は手配の整合性とは関係がない。

30字で「何が」に当たる「部品手配」と，「どのように」に当たる「作業時期に合わせて計画されているか」を書く。解答例は「部品手配が，作業時期に合わせて計画されているか」で23字。

採点講評（IPA）

設問2は，正答率が低かった。手配計画には，作業の手配計画と部品の手配計画があり，ここでは部品の手配計画に関して問うているが，作業手配や原価に関しての解答が多く見られた。

本文の根拠

〔社内システムの強化・改善の内容〕(4)

購買管理システムの機能には，部品所要量計算，部品発注・検収処理，外注発注・検収処理がある。作業管理システムの機能には，作業予定登録，作業指示処理，部品出庫指示処理，作業実績処理，顧客検収登録がある。

表1

8：作業手配・外注発注，外注先への発注書が発行されたとき。

表1

11：工事実施・外注検収，外注検収報告が登録されたとき。

表1 で作業手配及び工事実施関連の業務機能は，番号7（作業指示），8（外注発注），9（部品出庫），10（作業実施），11（外注検収）の五つである。このうち作業指示・部品出庫・作業実施は作業管理システムの機能（作業指示処理，部品出庫指示処理，作業実績処理）に当たる。購買管理システムの機能は部品所要量計算，部品発注・検収処理，外注発注・検収処理なので，購買管理システムからの情報で終了と判断するのは外注に関わる番号8 と番号11 である。

取得すべき情報は，表1 の終了のタイミングから決まる。番号8 は「外注先への発注書が発行されたとき」なので外注先への発注書発行情報，番号11 は「外注検収報告が登録されたとき」なので外注検収報告の登録情報を取得する。講評は，部品手配関連の業務機能（番号5・6）を挙げた誤答が多かったとしている。部品の発注・検収も購買管理システムの機能だが，表1 では“部品手配”に分類され，作業手配・工事実施関連ではない。

情報はそれぞれ15字で，表1 の終了タイミングの言葉を名詞の形に直して書く。解答例は「外注先への発注書発行情報」（12字）と「外注検収報告の登録情報」（11字）。①と②は順不同。

採点講評（IPA）

設問3(1)は，二つ挙げる業務機能のうち，一つは正答率が高く，もう一つは正答率が低かった。誤答の多くは，作業手配及び工事実施関連の業務機能ではなく，部品手配関連の業務機能を挙げた解答であった。

本文の根拠

〔社内システムの強化・改善の内容〕(1)

定期保守については，付帯作業の見積金額を含む定期保守通知書の作成後，管理者の承認を受け，承認登録する。

表1

1：見積り・改修，見積書の承認が登録されたとき。

〔工番別進捗管理システムと工番別損益管理システムの概要〕(2) ① 売上の登録

見積時に，予定売上の登録を行い，顧客検収報告の登録時に，実績売上として登録する。

a は“見積り・定期保守”の終了タイミングである。改修の見積りは番号1 で「見積書の承認が登録されたとき」に終了とする。定期保守では，見積書に当たるものが付帯作業の見積金額を含む定期保守通知書で，作成後に管理者の承認を受けて承認登録する。よって a は「定期保守通知書の承認が登録されたとき」になる。

b は“顧客検収・売上”の終了タイミングである。現行業務では顧客検収を受けた後に顧客検収報告を行い，売上はその顧客検収報告に基づいて計上する。工番別損益管理システムでも，顧客検収報告の登録時に実績売上を登録する。顧客検収と売上の両方が済むのは顧客検収報告が登録されたときで，作業管理システムの機能“顧客検収登録”がこれに当たる。

それぞれ20字で，表1 の他の行と同じ「〜が登録されたとき」の形にそろえる。解答例は a が「定期保守通知書の承認が登録されたとき」で18字，b が「顧客検収報告が登録されたとき」で14字。

本文の根拠

〔工番別進捗管理システムと工番別損益管理システムの概要〕(2) ② 予定原価の登録

予定原価は，見積段階では，作業は社内の作業員だけで行うものとみなし，原価要素別に部品費，労務費，直接経費を見積もり，登録する。

〔案件の発生から完了までの現行業務の流れ〕(2) 手配計画・部品手配・作業手配

社内の作業員だけで作業が間に合わないときは，外注の手配を計画に含める。

〔案件の発生から完了までの現行業務の流れ〕(5) 工番別損益管理

集計する原価要素には，部品費，労務費，外注費及び直接経費がある。

原価要素は部品費，労務費，外注費，直接経費の四つである。見積段階では作業を社内の作業員だけで行うものとみなすので，予定原価として登録するのは部品費，労務費，直接経費の三つで，外注費が抜けている。

外注を使うかどうかは，手配計画で作業期間に合わせた作業員の手配を決めるときに，社内の作業員だけで間に合わないと分かって初めて決まる。したがって外注費は，見積時には設定できず，作業計画の立案時に初めて設定できる原価要素である。

字数の制限はない。本文の原価要素の名前どおり「外注費」と答える。「外注」だけでは原価要素の名前にならない。

本文の根拠

〔工番別進捗管理システムと工番別損益管理システムの概要〕(2)

賃率マスタは，作業員の資格別の時間当たり単価を管理している。

〔案件の発生から完了までの現行業務の流れ〕(3) 工事実施・顧客検収

作業実績報告では，作業員別作業時間，改修及び保守に使用した部品の使用量，作業員の出張滞在費，部品・工事機材の運搬費などを報告する。

〔工番別進捗管理システムと工番別損益管理システムの概要〕(2) ③ 実績原価の収集

労務費は，作業実績報告から計算し，計上する。

〔案件の発生から完了までの現行業務の流れ〕(5) 工番別損益管理

直接経費は，作業員の出張滞在費と部品・工事機材の運搬費である。

労務費は作業実績報告から計算する。作業実績報告のうち作業員に関わる時間の情報は作業員別作業時間で，工番別損益管理システムの賃率マスタは作業員の資格別の時間当たり単価を管理している。作業員一人一人の労務費は，その作業員の作業時間実績に，その作業員の資格別の時間当たり単価を掛けて求める。

作業実績報告には作業員の出張滞在費も含まれるが，本文は出張滞在費を部品・工事機材の運搬費とともに直接経費と定めている。講評も，直接経費である出張滞在費まで労務費に含めた解答が散見され，正答率が低かったとしている。原価要素は別々に集計するので，労務費に直接経費を足すと二重に計上してしまう。

字数の制限はない。計算式なので「作業時間実績」と「資格別の時間当たり単価」の掛け算で書く。解答例は「作業員の作業時間実績×作業員の資格別の時間当たり単価」。

採点講評（IPA）

設問4(2)は正答率が低かった。労務費の計算方法を問う問題であったが，直接経費である出張滞在費まで含めた解答が散見された。

本文の根拠

〔物流センタ新設後の業務概要〕(1) 受注・在庫引当て

③ 物流センタの商品別在庫を管理する在庫マスタの在庫関連項目として，実在庫，引当済実在庫，入荷予定在庫及び引当済入荷予定在庫を設ける。受注登録時の在庫引当ては，これらの在庫情報から算出した引当可能在庫に対して行われる。

〔物流センタ新設後の業務概要〕(1) 受注・在庫引当て

引当可能在庫 ＝ a − b ＋ c −（cのうち引当済みのもの）

〔物流センタ新設後の業務概要〕(1) 受注・在庫引当て

② 受注登録時に，物流センタの商品在庫の引当てを行い，結果を出荷予定ファイルに出力する。

在庫マスタの在庫関連項目は，実在庫，引当済実在庫，入荷予定在庫，引当済入荷予定在庫の四つである。引当てに使えるのは，今ある在庫のうちまだ引き当てていない分と，これから入荷する在庫のうちまだ引き当てていない分である。式の前半が「a − b」，後半が「c −（c のうち引当済みのもの）」の形なので，a は実在庫，b は引当済実在庫，c は入荷予定在庫に当たる。

ただし c は入荷予定在庫そのままではない。受注の引当ての結果は出荷予定ファイルに出力され，商品はその出荷予定日に出荷する。出荷予定日より後に入荷する在庫を引き当てても，その受注の出荷には間に合わない。引当ての対象にできる入荷予定在庫は，出荷予定日までに入荷するものに限られる。講評も，“出荷予定日までの入荷予定在庫”に対して“入荷予定在庫”だけの解答が多かったとしている。

字数の制限はない。a と b は在庫マスタの項目名どおりに書く。c は項目名に「出荷予定日までの」という条件を付けるのを忘れない。解答例は a「実在庫」，b「引当済実在庫」，c「出荷予定日までの入荷予定在庫」。

採点講評（IPA）

設問1は(1)，(2)とも正答率が高かったが，(1)のcについて“出荷予定日までの入荷予定在庫”という解答に対し，“入荷予定在庫”だけの解答が多かった。(2)では，在庫マスタへの更新であるにもかかわらず，棚番別在庫ファイルへの更新の記述が散見された。

本文の根拠

〔物流センタ新設後の業務概要〕(2) 入荷

② 入荷実績を物流センタの受入場の端末から入力し，保管庫に棚入れするための棚入指示表を出力するとともに，在庫マスタの実在庫，引当済実在庫，入荷予定在庫及び引当済入荷予定在庫を更新し，棚番別在庫ファイルの棚入指示済在庫を更新する。

〔物流センタ新設後の業務概要〕(1) 受注・在庫引当て

引当可能在庫 ＝ a − b ＋ c −（cのうち引当済みのもの）

入荷時には，在庫マスタの実在庫，引当済実在庫，入荷予定在庫，引当済入荷予定在庫の四つを更新する。設問は実在庫の加算と入荷予定在庫の減算を示しているので，残る二つは引当済実在庫と引当済入荷予定在庫である。

入荷予定在庫の一部は，受注登録時に既に引き当てられている（引当済入荷予定在庫）。その商品が入荷すると，入荷予定在庫が実在庫に変わるのと同じように，引き当てた分も“入荷予定在庫のうち引当済み”から“実在庫のうち引当済み”に移る。つまり引当済実在庫が加算され，引当済入荷予定在庫が減算される。入荷した商品がまだ引き当てられていなければこの二つは変わらないので，設問は「更新される可能性がある」と書いている。講評は，在庫マスタへの更新を問うているのに，棚番別在庫ファイルへの更新を書いた解答が散見されたとしている。

それぞれ20字で，「何の在庫情報が」と「どのように（加算か減算か）」を1文で書く。解答例は「引当済実在庫が加算更新される。」（15字）と「引当済入荷予定在庫が減算更新される。」（18字）。

採点講評（IPA）

設問1は(1)，(2)とも正答率が高かったが，(1)のcについて“出荷予定日までの入荷予定在庫”という解答に対し，“入荷予定在庫”だけの解答が多かった。(2)では，在庫マスタへの更新であるにもかかわらず，棚番別在庫ファイルへの更新の記述が散見された。

本文の根拠

〔物流センタ新設後の業務概要〕(3) 棚入れ・保管

② 保管庫では，1 種類の商品を一つ以上の棚に保管している。保管庫の在庫管理は，物流センタサーバの棚番別在庫ファイルで行い，

図1

項目は左から，棚番，商品コード，実在庫，棚入指示済在庫，棚出指示済在庫と続き，

表1 棚出指示表作成

(2) 日付を指定して出荷予定ファイルから翌日出荷予定レコードを抽出する。(3) dを特定する。(4) 棚番別在庫ファイルの棚出指示済在庫を更新する。

棚出指示表作成では，出荷予定ファイルから翌日出荷予定レコードを抽出した後，d を特定し，棚番別在庫ファイルの棚出指示済在庫を更新する。出荷予定レコードで分かるのは出荷する商品と数量で，その商品が保管庫のどの棚にあるかは分からない。保管庫では 1 種類の商品を一つ以上の棚に保管しているので，棚出しを指示するには，出荷対象の商品を保管している棚を決めなければならない。

棚の在庫を管理しているのは棚番別在庫ファイルで，主キーは棚番，属性に商品コードと実在庫を持つ。このファイルを商品コードで探せば出荷対象商品の棚番が分かり，特定した棚番のレコードの棚出指示済在庫を(4)で更新できる。講評は，棚番を特定すること以外の記述が散見されたとしている。

25字で「棚番別在庫ファイル」「出荷対象商品」「棚番」を入れる。解答例は「棚番別在庫ファイルの出荷対象商品の棚番」で19字。

採点講評（IPA）

設問2(1)は，棚番を特定すること以外の記述が散見された。

本文の根拠

〔物流センタ新設後の業務概要〕(4) 棚出し

② 棚出実績によって，棚番別在庫ファイルの実在庫及び棚出指示済在庫を更新する。

表1 棚出処理

(3) ポータブル端末から棚出実績が入力されたら，次の処理を行う。① e ② 出荷予定ファイルの翌日出荷予定レコードの状態を，棚出済みにする。

e は棚出処理で，ポータブル端末から棚出実績が入力されたときに行う処理である。業務概要の(4)②は，棚出実績によって棚番別在庫ファイルの実在庫及び棚出指示済在庫を更新するとしている。表1 の②は出荷予定ファイルの状態の更新なので，残る棚番別在庫ファイルの更新が e に当たる。

棚から商品を出せば，その棚の実在庫が減る。また，棚出指示表作成で棚出指示済在庫を更新しているので，指示どおりに棚出しが済んだ分を棚出指示済在庫から減らす必要がある。図2 でも棚出処理は棚番別在庫ファイルと双方向で結ばれている。

35字で，更新するファイル名と二つの項目名（実在庫，棚出指示済在庫）を書く。解答例は「棚番別在庫ファイルの実在庫及び棚出指示済在庫を更新する。」で28字。

本文の根拠

表2 出荷処理

(2) 出荷予定表の出荷番号を入力し，出荷予定ファイルから該当する出荷予定レコードの内容を表示する。

表2 出荷処理

① fの該当する出荷予定レコードの状態を出荷済みにするとともに，出荷実績ファイルに出力する。

図2

出荷処理は在庫マスタ，受注ファイル，出荷予定ファイルと双方向で結ばれ，出荷実績ファイルへ出力する。

f は「出荷予定レコード」を持つファイルである。出荷処理の(2)では，出荷予定表の出荷番号を入力して出荷予定ファイルから該当する出荷予定レコードを表示している。出荷実績が入力されたら，そのレコードの状態を出荷済みにするので，f は出荷予定ファイルである。

出荷予定ファイルのレコードの状態は，棚出指示表作成で棚出指示済み，棚出処理で棚出済み，出荷予定表・出荷ラベル作成で出荷指示済みと，処理ごとに進んでいく。出荷処理はその最後に出荷済みにする。図2 でも出荷処理は出荷予定ファイルと双方向で結ばれている。

字数の制限はない。本文と図のファイル名どおり「出荷予定ファイル」と書く。

本文の根拠

〔物流センタ新設後の業務概要〕(5) 出荷

その出荷実績を出荷場の端末から入力し，受注の消込み，在庫マスタの実在庫，引当済実在庫を更新するとともに，納品伝票などの出荷関連帳票を出力する。

図2

出荷処理は在庫マスタ，受注ファイル，出荷予定ファイルと双方向で結ばれ，出荷実績ファイルへ出力する。

表2 出荷処理

② 在庫マスタの実在庫，引当済実在庫を更新する。③ 出荷実績に該当するg ④ 出荷関連帳票の編集，出力を行う。

業務概要の(5)②は，出荷実績の入力で「受注の消込み」「在庫マスタの実在庫，引当済実在庫の更新」「出荷関連帳票の出力」を行うとしている。表2 の出荷処理では，在庫マスタの更新が②，帳票の出力が④にあるが，受注の消込みがどこにもない。これが g に当たる。

図2 で出荷処理とつながっているファイルは，在庫マスタ，受注ファイル，出荷予定ファイル，出荷実績ファイルである。表2 で使っていないのは受注ファイルだけで，受注の消込みとは，出荷した受注の受注レコードの状態を出荷済みにすることである。講評は，受注ファイルに対する処理以外の処理記述が散見され，図の業務フローと表の処理記述書を注意深く比較して読めば防げた誤りだとしている。

30字で「受注ファイル」「受注レコード」「出荷済み」を入れる。解答例は「受注ファイルの受注レコードの状態を出荷済みにする。」で25字。

採点講評（IPA）

設問3(2)は正答率が低かった。受注ファイルに対する処理以外の処理記述が散見された。図の業務フローと表の処理記述書を注意深く比較して読めば，防ぐことができた誤りであった。

本文の根拠

〔現在の受注・出荷業務及びシステム化状況〕

(6) 顧客への出荷データは売上データとして，営業所サーバから夜間に本社へ送信され，本社サーバで売上計上，請求・入金処理が行われる。売上は，受注した営業所への計上が原則であるが，他営業所から出荷した場合は，売上の一部が出荷手数料として，出荷した営業所に振替計上される。

〔物流センタ新設後の業務概要〕

新設した物流センタで商品在庫を集中管理し，顧客への出荷は全て物流センタから行う。

〔物流センタ新設後の業務概要〕(5) 出荷

③ 物流センタからの出荷時点で，受注した営業所の売上として計上される。

現状は営業所ごとに在庫を持ち，自営業所の在庫で引き当てられない受注は他営業所から出荷することがある。そのとき売上の一部が出荷手数料として出荷した営業所に振替計上されるので，営業所別の売上集計には，他営業所に振替計上する出荷手数料分のデータが発生している。

物流センタ新設後は，顧客への出荷は全て物流センタから行い，出荷時点で受注した営業所の売上として計上される。他営業所から出荷することがなくなるので，出荷手数料の振替計上も起きず，そのデータが発生しなくなる。

25字で「他営業所に振替計上する」「出荷手数料」「データ」を入れる。解答例は「他営業所に振替計上する出荷手数料分のデータ」で21字。

本文の根拠

〔勤務管理に関する内部監査の指摘〕

指摘 1：部長が，月次で，勤務管理表，プロジェクト別業務時間及び残業届出書の 3 種類のデータを確認しているが，データの不一致が発生している。また，平均 50 名いる部員全員について，全ての日の明細を部長が確認していることに無理がある。

〔新システムを用いた勤務管理の概要〕(2)

プロジェクト別業務時間の合計は，1 日の業務時間と一致させる必要がある。一致しない場合，入力は完了しない。

〔新システムを用いた勤務管理の概要〕(3)

追加開発で作成された警告一覧を出力し，その内容を精査して部員に確認する。

〔ダウンロードデータを使用した処理〕(2) 警告一覧を出力する機能

これらの基準を満たしていない場合に，その内容を警告一覧に出力する。

指摘1 は二つの問題を挙げている。一つは，勤務管理表（時間入力システムと紙），プロジェクト別業務時間（表計算ソフト），残業届出書（紙）の 3 種類のデータが別々に管理されていて不一致が起きていること。もう一つは，部長が全部員の全ての日の明細を確認していて無理があることである。

データの管理方法については，新システムで勤務実績入力，プロジェクト別業務時間入力，残業予定入力をどれもイントラネットから行い，3 種類のデータを全て新システムで一元管理する。プロジェクト別業務時間の合計を 1 日の業務時間と一致させないと入力が完了しない仕組みも，一元管理したから持てるものである。講評は，業務時間明細とプロジェクト別工数一覧の二つだけを取り上げた解答が多かったとしている。残業届出書（残業予定）も含めた 3 種類である。部長の確認方法については，表2 の容認される基準を満たしていないものだけを警告一覧に出力し，部長はそれを精査する。全ての明細を見る必要がなくなる。

それぞれ30字で，管理方法は「3 種類のデータ」「新システムで一元管理」，確認方法は「確認すべきデータだけ」「警告一覧に出力」を入れる。解答例は「3種類のデータを全て新システムで一元管理する。」（23字）と「部長が確認すべきデータだけを警告一覧に出力する。」（24字）。

採点講評（IPA）

設問1は，正答率が高かった。(1)のデータの管理方法は，今までバラバラに管理されていた3種類のデータの一元化について問う問題であったが，業務時間明細とプロジェクト別工数一覧の二つのデータだけを取り上げた解答が多く見られた。

本文の根拠

〔勤務管理に関する内部監査の指摘〕

指摘 2：開始時刻及び終了時刻が勤務実態どおりに正しく入力されているかどうかの保証がない。入力された時刻が妥当かどうかを確認する必要がある。

〔新システムを用いた勤務管理の概要〕

(1) 各フロアの出入口に IC カードリーダ付き入力端末を設置し，入退室時に IC カード付き社員証をタッチして，入室・退室の時刻を記録する。

表2 ②開始時刻，終了時刻

月間業務時間明細について，開始時刻と初回入室時刻，終了時刻と最終退室時刻が，それぞれ 30 分以上かい離していない。

開始時刻と終了時刻は社員が自分で入力するので，それだけでは勤務実態どおりかどうか分からない。比べる相手として，社員の入力とは別に記録される客観的な時刻が要る。新システムでは，各フロアの出入口に IC カードリーダ付き入力端末を設置し，入退室時に IC カード付き社員証をタッチして入室・退室の時刻を記録する。

記録した 1 日の初回入室時刻と最終退室時刻は新システムに取り込まれ，表2 の②では開始時刻と初回入室時刻，終了時刻と最終退室時刻が 30 分以上かい離していないかを確認する。これで入力された時刻の妥当性を確かめられる。

35字で「IC カードリーダ付き入力端末」と「入室，退室の時刻を記録する機能」を書く。解答例は「ICカードリーダ付き入力端末で，入室，退室の時刻を記録する機能」で31字。

本文の根拠

〔新システムを用いた勤務管理の概要〕(2) ① 勤務実績入力

終業区分として，通常退社，早退，又は直帰を選択して入力する。始業区分が出張又は休暇種別の場合は，終業区分は空白とする。

表2 ①始業区分，終業区分

月間業務時間明細について，初回入室時刻が未入力のときは，始業区分が出張，休暇のいずれかであり，初回入室時刻が開始時刻よりも遅いときは，始業区分が直行である。

〔D 社の就業条件〕

(4) 残業時間の上限は，労使協定で，1 日 7 時間，月間 45 時間，連続する 3 か月累計 120 時間，年度累計 360 時間と定められている。

〔ダウンロードデータを使用した処理〕(2) 警告一覧を出力する機能

⑤ プロジェクト別業務時間の入力が，翌営業日中に行われているかどうかを確認する。

表1 月間プロジェクト別業務時間明細

社員番号，勤務年月日，プロジェクトコード，業務時間，入力年月日。

a，b は終業区分で，選べるのは通常退社，早退，直帰と，始業区分が出張又は休暇種別のときの空白の四つである。最終退室時刻が未入力なのはその日一度もフロアに入っていない場合で，始業区分の行が「初回入室時刻が未入力のときは出張，休暇のいずれか」としているのと対になる。出張・休暇の日の終業区分は空白なので a は空白。最終退室時刻が終了時刻より早いのは，フロアを出た後も社外で業務を続けてそのまま帰った場合で，b は直帰である。講評は，この 4 種類以外の解答も少なからず見られたとしている。

c は④残業時間の上限で，基準の数値は労使協定の上限の 9 割（月間 45 時間→40.5 時間，連続する 3 か月累計 120 時間→108 時間，年度累計 360 時間→324 時間）になっている。108 時間に当たるのは連続する 3 か月の累計で，月間残業時間集計には勤務年月ごとの月間残業時間があるので，当月までの連続する 3 か月の月間残業時間を合計して確かめる。講評は，“連続する3か月の累計”と誤って答えた受験者が多かったとしている。空欄の後に「の月間残業時間の合計」と続くので，入るのは期間を表す字句である。d〜f は⑤で，プロジェクト別業務時間の入力が翌営業日中に行われたかを見る。月間プロジェクト別業務時間明細には勤務年月日と入力年月日があり，この二つが 2 営業日以上離れていなければ翌営業日中の入力である。

字数の制限はない。a，b は本文の区分名どおり，d はファイル名，e，f は属性名をそのまま書く。解答例は a「空白」，b「直帰」，c「当月までの連続する3か月」，d「月間プロジェクト別業務時間明細」，e「勤務年月日」，f「入力年月日」（e と f は順不同）。

採点講評（IPA）

設問2では，a，b，cの正答率が低かった。a，bは終業区分を問うているので，問題文中に現れる4種類の区分から解答を導き出せばよかったが，4種類の区分以外の解答も少なからず見られた。cは，問題文の記述をそのまま引用して“連続する3か月の累計”と誤って解答した受験者が多かったが，これは穴埋めの文章をよく読めば，防ぐことができた誤りであった。

本文の根拠

〔ダウンロードデータを使用した処理〕

D 社では，部ごとにダウンロードを行うよう設定し，部長が自分の部のデータをダウンロードできるようにした。

〔現在の勤務管理の概要〕

プロジェクトは複数の部が関わっているものが多い。

〔内部監査担当者によるレビュー〕

(1) 個人のプロジェクト別業務時間は正しく把握できるようになったが，プロジェクト単位に工数の実績を管理するためには，考えているプロジェクト別工数一覧では不十分であり，更なる考慮が必要である。

プロジェクト別工数一覧は，月間プロジェクト別業務時間明細から出力する。ところがダウンロードは部ごとに行う設定で，部長がダウンロードできるのは自分の部のデータだけである。そのため，できる一覧には自分の部の部員の工数しか入らない。

本文は「プロジェクトは複数の部が関わっているものが多い」としている。複数の部が関わるプロジェクトの工数の実績をプロジェクト単位に管理するには，部内のデータだけでなく，関わっている他部のデータと合わせた一覧を作成しなければならない。講評は，(1)の内容と理由の正答率が低かったとしている。

それぞれ30字で，内容は「他部のデータと合わせた一覧」，理由は「複数の部が関わっている」を入れる。解答例は「部内だけでなく他部のデータと合わせた一覧を作成すること」（27字）と「プロジェクトは複数の部が関わっているものが多いから」（25字）。

採点講評（IPA）

設問3では，(1)の内容と理由，及び(2)の社員の条件の正答率が低かった。(2)では，問題文の理解不足で，夏期休暇明細のファイル設計を誤解したと思われる解答が目立った。

本文の根拠

〔勤務管理に関する内部監査の指摘〕

指摘 4：夏期休暇は，予定をあらかじめ決めて取得することになっているが，予定を入力しなかったり，予定どおりに休まなかったりする社員が多く，取得率が低迷している。

〔新システムを用いた勤務管理の概要〕(4)

なお，夏期休暇明細については，予定データは夏期休暇の取得予定年月日から，実績データは毎日の勤務実績から作成する。予定データの予定実績区分には“予定”が，実績データの予定実績区分には“実績”がそれぞれ設定される。

表1 夏期休暇明細

社員番号，予定実績区分，休暇年月日。

〔内部監査担当者によるレビュー〕

(2) 夏期休暇の取得率向上については，取得予定年月日を 3 日分入力していない社員の確認と取得奨励メールの送信を考えているが，現状を考えるとこれだけでは不十分である。

指摘4 は，取得率が低迷している原因として，予定を入力しない社員と，予定どおりに休まない社員の二つを挙げている。考えている対策のうち，取得予定年月日を 3 日分入力していない社員の確認は前者への対策である。取得奨励メールは休暇取得予定日の 1 週間前に送るだけで，実際に休んだかどうかは見ていない。したがって，休暇取得予定日に休まなかった社員を把握できないことが不十分な点である。

夏期休暇明細には，取得予定年月日から作る予定データと，毎日の勤務実績から作る実績データがあり，予定実績区分で見分けられる。予定どおりに休んでいれば，予定日が過ぎた予定データには同じ数の実績データがあるはずである。当年の夏期休暇明細で，過去日付の予定データの件数が実績データの件数より多い社員を警告一覧に出力すればよい。別解のように，予定データの取得予定日が過ぎても実績データが存在しない社員と書いてもよい。講評は，夏期休暇明細のファイル設計を誤解したと思われる解答が目立ったとしている。夏期休暇明細は予定と実績を同じファイルに持ち，予定実績区分で分けている点を押さえる。

理由は35字で「休暇取得予定日に休まなかった社員を把握できない」ことを書く。条件は40字で，設問の指示どおり表1 のファイル名「夏期休暇明細」を使い，「予定データ」と「実績データ」を比べる形にする。解答例は理由が30字，条件が37字（別解は38字）。

採点講評（IPA）

設問3では，(1)の内容と理由，及び(2)の社員の条件の正答率が低かった。(2)では，問題文の理解不足で，夏期休暇明細のファイル設計を誤解したと思われる解答が目立った。

本文の根拠

表1 操作処理部

マスタマニピュレータの移動量からスレーブマニピュレータの絶対位置情報を算出する。また，ペダルの状態を入力する。得られた情報を，操作コマンドとして手術台に送信する。

表2 スレーブマニピュレータ

制御部からの信号によって，リンク機構を通じて先端に取り付けられた器具の移動，回転，挟むなどの動きを実現する。また，器具のスイッチの ON/OFF 制御信号を器具に伝える。

表2 制御部

aを受信し，bを動作させる信号及び ON/OFF 制御信号を出力する。

制御部は手術台の一部で，a を受信して b を動作させる信号を出力する。手術台に送られてくるのは，操作卓の操作処理部が送信する操作コマンドである。操作コマンドには，マスタマニピュレータの移動量から算出したスレーブマニピュレータの絶対位置情報とペダルの状態が入っている。よって a は操作コマンド。

スレーブマニピュレータは「制御部からの信号によって」器具を動かし，器具のスイッチの ON/OFF 制御信号を器具に伝える。制御部が出力する“動作させる信号”の相手はスレーブマニピュレータで，ON/OFF 制御信号はペダルの状態から作られる。よって b はスレーブマニピュレータである。

字数の制限はない。表1・表2 の用語どおりに書く。解答例は a「操作コマンド」，b「スレーブマニピュレータ」。

本文の根拠

〔遠隔手術システムの開発目標〕

⑤ 執刀医師のストレスを減らすために，マニピュレータの操作が内視鏡モニタに表示されるまでの遅延時間が短くなるようにする。

表3

3D 内視鏡映像：手術室⇒遠隔オペレーション室，

表3

操作コマンド：遠隔オペレーション室⇒手術室，

遠隔手術では，執刀医師が遠隔オペレーション室でマスタマニピュレータを操作すると，操作コマンドが通信回線で手術室の手術台に送られてスレーブマニピュレータが動き，その様子を映した 3D 内視鏡映像が通信回線で遠隔オペレーション室に送り返されて 3D 内視鏡モニタに表示される。手術室内での操作に比べ，往復の伝送の分だけ操作が表示されるまでに時間がかかる。

開発目標⑤も，執刀医師のストレスを減らすために，マニピュレータの操作が内視鏡モニタに表示されるまでの遅延時間を短くするとしている。講評は，単なる“伝送遅延”という解答が散見され，伝送遅延が双方向で生じることを問題文中の表現を用いて記述してほしかったとしている。操作コマンドの行きと映像の帰りの両方を含むことが伝わる書き方にする。

40字で「マスタマニピュレータの操作が」「3D 内視鏡モニタに表示されるまでの」「遅延時間」をつなぐ。解答例は「マスタマニピュレータの操作が3D内視鏡モニタに表示されるまでの遅延時間」で35字。

採点講評（IPA）

設問1(2)は，正答率が高く，題意はよく理解されていたようだが，単なる“伝送遅延”との解答が散見された。伝送遅延が双方向で生じることを問題文中の表現を用いて記述してほしかった。

本文の根拠

〔通信回線の検討〕

この条件に適合する通信回線の検討では，執刀医師の操作に大きく影響するcの伝送遅延及び操作コマンドの伝送遅延を重視した。そのため圧縮処理は，ハードウェアで行うことにする。

表3

3D 内視鏡映像：手術室⇒遠隔オペレーション室，内視鏡からの二眼のカメラによる映像を 3D 化するのに必要な処理及びデータ圧縮処理を施したデータ。

c は表3 の通信データのうち，操作コマンドと並んで執刀医師の操作に大きく影響するものである。執刀医師は 3D 内視鏡モニタを確認しながらマスタマニピュレータを操作するので，操作コマンドとともに，手術室から送られてくる 3D 内視鏡映像の遅れが操作に直接響く。設問1(2)の遅延時間の行きと帰りがこの二つに当たる。

本文は続けて，そのため圧縮処理をハードウェアで行うとしている。表3 で圧縮処理を施すのは 3D 内視鏡映像と室内映像・音声だが，室内映像・音声はコミュニケーション用で，操作への影響は小さい。生体データも操作そのものには関わらない。

字数の制限はない。表3 のデータ種別の名前どおり「3D 内視鏡映像」と書く。

本文の根拠

〔遠隔手術システムの開発目標〕

③ より正確な手術がしやすいように，内視鏡モニタは 3D 化する。

〔通信回線の検討〕

通信速度の相違については，圧縮方法及び圧縮率を変えないで，伝送データ量を変動させる方法も検討する。

伝送データ量は，1 秒当たりのフレーム数と 1 フレーム当たりの画素数を掛けたものに比例する。フレーム数を減らす方法では，1 フレームの画素数はそのままなので，一枚一枚の映像の解像度を維持できる。より正確な手術がしやすいように内視鏡モニタを 3D 化するほど細部を見たい用途なので，解像度が落ちないのは有利な点である。

一方，1 秒当たりのフレーム数が減ると，映像の動きがこま送りのようになり，スムーズでなくなる。執刀医師はモニタの映像を見ながらマニピュレータを操作するので，これが不利な点になる。講評は，“画像がより鮮明になる”などの記述が散見されたとしている。フレーム数を減らしても画素数は元のままで，鮮明になるわけではない。問題文の条件（圧縮方法及び圧縮率を変えないで伝送データ量を変動させる）を踏まえて答える。

それぞれ15字で，有利な点は「解像度を維持できる」，不利な点は「動きがスムーズでなくなる」と簡潔に書く。解答例は10字と13字。

採点講評（IPA）

設問2(2)は，伝送データ量を削減する方法として，“有利な点”及び“不利な点”を述べてもらいたかったが，“画像がより鮮明になる”などの記述が散見された。問題文中の条件を理解して記述してほしかった。

本文の根拠

〔3D 内視鏡モニタの検討〕

裸眼での 3D 化を実現するためには，映像に画像処理を行ってから 3D モニタに入力する必要がある。ハードウェアによる 3D 化画像処理ユニットを，データ圧縮処理ユニットとともに手術台の制御部に設置する。

〔遠隔手術システムの概要〕

③ 遠隔オペレーション室には操作卓を設置する。

〔遠隔手術システムの概要〕

④ 手術室には，ベッド，スレーブマニピュレータなどで構成する手術台及び操作卓を設置する。

3D 内視鏡モニタは操作卓に組み込まれていて，操作卓は遠隔オペレーション室と手術室の両方に設置する。3D 化画像処理ユニットを表示する側の操作卓に置くと，操作卓ごとに 1 台ずつ，少なくとも 2 台が必要になる。

手術台は 1 台で，内視鏡の映像はすべて手術台から出ていく。手術台の制御部で 3D 化の処理をしておけば，処理済みの映像を LAN で手術室の操作卓に，通信回線で遠隔オペレーション室の操作卓に送ればよく，3D 化画像処理ユニットは 1 台で済む。講評は，単に“送信データ量が削減できる”という解答が目立ったとしている。手術台に設置することの利点を問うているので，置き場所を手術台にしたことで何が良くなるかを書く。

25字あるが，要点は「1 台で済む」ことだけである。解答例は「3D化画像処理ユニットが1台で済む。」で18字。

採点講評（IPA）

設問3は，単に“送信データ量が削減できる”との解答が目立った。3D化画像処理ユニットを手術台に設置することの利点を問う出題なので，それが明確になるように記述してもらいたかった。

本文の根拠

〔安全性及びセキュリティ面の検討〕

d中は，遠隔オペレーション室のマスタマニピュレータを優先する。

〔遠隔手術システムの概要〕

⑨ 遠隔オペレーション室の操作卓と手術室の操作卓の両方が手術台と接続されたとき，2 台のマスタマニピュレータからは同時に操作できないようにする。

〔遠隔手術システムの概要〕

⑧ 執刀医師は，遠隔オペレーション室に設置された操作卓の 3D 内視鏡モニタを確認しながら，マスタマニピュレータを操作して遠隔手術を行う。

遠隔オペレーション室と手術室の両方の操作卓が手術台と接続されたとき，2 台のマスタマニピュレータから同時には操作できないようにする。どちらを優先するかを決める必要があり，執刀医師が遠隔オペレーション室から操作して遠隔手術を行っている間は，遠隔オペレーション室のマスタマニピュレータを優先する。

続く箇条でも，通信が中断した場合は「遠隔手術を止め」手術室のマスタマニピュレータの操作を有効にするとしている。遠隔手術を行っている間が遠隔オペレーション室の優先，止めたら手術室が有効という対になっている。

字数の制限はない。本文の用語どおり「遠隔手術」と書く。

本文の根拠

〔安全性及びセキュリティ面の検討〕

通信が中断した場合は，制御部からスレーブマニピュレータへの出力を停止して遠隔手術を止め，手術室のマスタマニピュレータの操作を有効にする。

〔安全性及びセキュリティ面の検討〕

緊急時には，手術室のスタッフの判断で，遠隔オペレーション室からの操作を無効にできるようにする。

表1 操作処理部

マスタマニピュレータの移動量からスレーブマニピュレータの絶対位置情報を算出する。

通信が中断したときや緊急時には，遠隔オペレーション室からの操作が無効になり，手術室のマスタマニピュレータの操作が有効になる。手術は途中で止められないので，そのときは手術室で操作を引き継いで継続しなければならない。

手術室のマスタマニピュレータが遠隔オペレーション室のマスタマニピュレータの状態と違っていると，引き継いだ時点でマスタマニピュレータの状態とスレーブマニピュレータの位置が食い違い，そのまま操作を続けられない。操作処理部はマスタマニピュレータの移動量からスレーブマニピュレータの絶対位置情報を算出するので，手術室のマスタマニピュレータを常に遠隔オペレーション室の状態に追随させておけば，切り替えた時点の状態から続けて操作できる。

50字で，「遠隔オペレーション室からの操作が無効になったとき」という場面と，「手術室で操作を継続する必要がある」という理由をつなぐ。解答例は43字。