平成29年度 秋期 午後Ⅰ

本文の根拠

〔マイナンバー制度導入後の業務概要〕(1) マイナンバー取得業務

契約管理システムで，顧客番号と顧客氏名を記載したマイナンバー申告書を印刷する。既に新システムにマイナンバーを登録済みの顧客のマイナンバー申告書は印刷しない。

〔マイナンバーに関する業務とシステム化の方針〕

マイナンバーを含むデータは，新システムだけで扱うこととする。

〔マイナンバー制度導入後の業務概要〕(1) マイナンバー取得業務

顧客からマイナンバーが変更になった旨の連絡があった場合は，新システムで管理しているマイナンバーを即時削除し，再度マイナンバー提供依頼書類を顧客に送付する。

マイナンバー申告書を印刷するのは契約管理システムで，登録済みの顧客の申告書は印刷しない決まりである。ところが，マイナンバーを含むデータは新システムだけで扱うので，契約管理システムは自分ではどの顧客が登録済みかを知ることができない。そこで，新システムでマイナンバーを登録した顧客の顧客番号を送り，契約管理システムが印刷するかしないかを判断できるようにする。

削除した顧客の顧客番号も送るのは，マイナンバーが変更になった顧客には，マイナンバーを削除したうえで再度マイナンバー提供依頼書類を送付するからである。削除を知らせなければ，契約管理システムは登録済みとみなしたまま申告書を印刷しない。送るのが顧客番号だけでマイナンバーそのものではない点も，マイナンバーを新システムだけで扱う方針に沿っている。講評は，契約管理システムにない機能である“支払調書の印刷”と書いた誤答があったとしている。支払調書にマイナンバーを追記するのは新システムの側である。

35字で「契約管理システムで」「マイナンバー申告書の印刷を制御する」ことを書く。解答例は「契約管理システムでマイナンバー申告書の印刷を制御するため」で28字。

採点講評（IPA）

設問1では，マイナンバー制度導入後の業務において，契約管理システムでは，マイナンバーを登録済みか未登録かによって顧客のマイナンバー申告書の印刷を制御することがポイントであるが，契約管理システムにない機能である“支払調書の印刷”という誤った解答が見受けられた。問題文中の業務の背景を読み取り各システムの機能配置を正しく理解・把握してほしい。

本文の根拠

〔マイナンバー制度導入後の業務概要〕(3) 支払調書提出業務

まだマイナンバーが提供されていない場合又は書類に不備があった場合は，該当する契約者又は受取人のマイナンバー記載欄を空白で提出する。その後，マイナンバーが提供されたら，マイナンバーを記載した支払調書を，訂正支払調書として再度提出する。

〔新システムの設計〕(2) マイナンバー取得管理機能

①該当する顧客の支払調書データのレコードが存在し，最新のレコードのマイナンバーが空白である場合に，再度，支払調書データのレコードを作成し，登録する

〔新システムの設計〕(4) 支払調書提出機能

支払調書データから訂正支払調書として税務署に提出するレコードを抽出し，訂正支払調書を格納した CD を作成する。

下線①のレコードが作られるのは，支払調書データの最新のレコードでマイナンバーが空白，つまりマイナンバー記載欄を空白のまま支払調書を提出済みの顧客について，後からマイナンバーが登録されたときである。業務では，このときマイナンバーを記載した支払調書を訂正支払調書として再度提出する。新たに作ったレコードは，その訂正支払調書の元になる。

支払調書提出機能は，支払調書データから訂正支払調書として提出するレコードを抽出し，訂正支払調書を格納した CD を作成する。支払調書データはレコードを履歴で保存するので，空白で提出した元のレコードは残したまま，マイナンバーを設定した新しい履歴を追加することになる。講評は，“履歴データを管理するため”とシステム設計と混同した解答があったとしている。問われているのはレコードの利用目的で，履歴で保存するのは手段である。

25字で「訂正支払調書」と「CD を作成する」を入れる。解答例は「訂正支払調書を格納したCDを作成するため」で20字。

採点講評（IPA）

設問2は，正答率が高かった。一方で，作成しているレコードの利用目的の解答を求めたにもかかわらず，システム設計と混同し“履歴データを管理するため”と誤って解答した例も見受けられた。

本文の根拠

〔マイナンバー制度導入後の業務概要〕(4) マイナンバー申告書督促業務

支払調書提出時までに A 社にマイナンバー申告書が届かず，支払調書の契約者又は受取人のマイナンバー記載欄を空白で提出した場合は，対象の顧客にマイナンバー申告書の提出を督促する。

表1 支払調書データ

支払調書番号（主キー），履歴番号（主キー），提出年月日，契約者顧客番号，契約者氏名，契約者住所，契約者マイナンバー，受取人顧客番号，受取人氏名，受取人住所，受取人マイナンバー，支払金額，支払年月日

督促の対象は，支払調書の契約者又は受取人のマイナンバー記載欄を空白で提出した顧客である。支払調書データの最新の履歴のレコードで見ると，契約者マイナンバーか受取人マイナンバーが空白になっているものがこれに当たる。

抽出するのは顧客番号なので，契約者マイナンバーが空白なら契約者顧客番号を，受取人マイナンバーが空白なら受取人顧客番号を取り出す。表1 の支払調書データには契約者と受取人の顧客番号・マイナンバーが別々の属性で持たれているので，条件は二つの「又は」で書く。最新の履歴に限るのは，マイナンバーが登録されると下線①で新しいレコードが作られ，空白でなくなるからである。

35字で表1 の属性名「契約者マイナンバー」「受取人マイナンバー」を使い，「空白である顧客番号」と結ぶ。解答例は「契約者マイナンバー又は受取人マイナンバーが空白である顧客番号」で30字。

本文の根拠

〔新システムの設計〕(3) マイナンバー申告書進捗管理機能

申告書ステータスの初期値は“取得中”である。不備があった場合は，画面から申告書ステータスの値を“不備対応中”にする。

〔マイナンバー制度導入後の業務概要〕(1) マイナンバー取得業務

マイナンバー管理部は，顧客から提出されたマイナンバー申告書の内容に不備がないことを確認した後，新システムにマイナンバーを登録する。不備があった場合は，マイナンバー管理部で顧客に連絡し，対応する。

〔マイナンバー制度導入後の業務概要〕(4) マイナンバー申告書督促業務

支払調書提出時までに A 社にマイナンバー申告書が届かず

督促は，支払調書提出時までにマイナンバー申告書が A 社に届いていない顧客に対して行う。マイナンバーが空白のまま提出された顧客には，申告書が届いていない顧客のほかに，申告書は届いたが不備があってマイナンバーを登録できていない顧客も含まれる。後者は申告書ステータスが“不備対応中”で，マイナンバー管理部が既に顧客に連絡して対応しているので，督促書類を送る必要はない。

申告書ステータスの値のうち，“取得中”は申告書が届いていない状態で督促の対象そのものである。“登録済み”の顧客は下線①でマイナンバーを設定したレコードが作られるので，最新の履歴が空白のまま残ることはない。したがって除外するのは“不備対応中”である。講評は，理由ではなく申告書ステータスの説明だけを書いた解答があったとしている。

値は本文の表記どおり「不備対応中」。理由は35字で「A 社にマイナンバー申告書が届いていない顧客」を督促の対象とすることを書く。解答例は「A社にマイナンバー申告書が届いていない顧客を対象とするから」で29字。

採点講評（IPA）

設問3(2)では，申告書ステータスの値を正しく解答している受験者の多くは，その理由も正しく理解していた。一方で，理由ではなく単純に申告書ステータスの説明だけを記載している解答も見受けられた。

本文の根拠

〔マイナンバー制度導入後の業務概要〕(5) マイナンバー削除業務

顧客から提供されたマイナンバーは，支払調書を最後に提出してから 7 年経過した際に新システムで一括削除する。

〔新システムの設計〕(6) 削除機能

なお，削除予定年月日は，マイナンバーデータのレコードを登録する際，システムで計算して設定する。また，削除予定年月日は，ある機能で変更する。

〔新システムの設計〕(4) 支払調書提出機能

契約管理システムから支払調書基本情報を受領後，支払調書番号を採番し，支払調書データのレコードを作成して，登録する。その際，契約者及び受取人のマイナンバーを設定する。

マイナンバーを削除するのは，支払調書を「最後に」提出してから 7 年経過したときである。削除予定年月日は登録時に計算して設定するが，その後に同じ顧客の支払調書を提出すれば，最後の提出日が後ろへずれ，削除予定年月日も延ばさなければならない。

支払調書の提出を扱うのは支払調書提出機能で，支払調書基本情報を受領して支払調書データのレコードを作り，その際に契約者及び受取人のマイナンバーを設定している。どの顧客の支払調書を提出したかが分かるのはこの機能なので，提出のたびに該当する顧客のマイナンバーデータの削除予定年月日を，提出してから 7 年後の日付に変更すればよい。1 人の顧客が複数の保険契約に関係していることもあるので，提出は一度で終わるとは限らない。

機能名は本文の表記どおり「支払調書提出機能」。理由は35字で「支払調書を提出してから 7 年後の日付」を設定する必要があることを書く。解答例は29字。

本文の根拠

〔マイナンバー制度導入後の業務概要〕(1) マイナンバー取得業務

顧客からマイナンバーが変更になった旨の連絡があった場合は，新システムで管理しているマイナンバーを即時削除し，再度マイナンバー提供依頼書類を顧客に送付する。

〔新システムの設計〕(6) 削除機能

マイナンバーデータのレコードを一括で削除する処理に加えて，画面から 1 件ずつ削除可能とする。

一括削除は，削除予定年月日を過ぎたレコードをまとめて消す処理なので，期限前の特定の顧客のマイナンバーを消すことはできない。期限前に個別に消す必要がある場面を業務の中から探すと，誤登録のほかに，顧客からマイナンバーが変更になった旨の連絡があった場合がある。このときは新システムで管理しているマイナンバーを即時削除する。

「即時」なので，削除予定年月日を待つ一括処理では間に合わない。画面から 1 件ずつ削除できれば，連絡を受けたその場で該当する顧客のマイナンバーを消し，再度マイナンバー提供依頼書類を送付する流れに進める。講評は，“契約終了”や“不具合”といった，利用者から求められている背景ではない解答があったとしている。本文に書かれた業務の中から削除が必要になる場面を探す。

35字で「顧客からマイナンバーの変更の連絡があった場合」と「削除する」を入れる。解答例は「顧客からマイナンバーの変更の連絡があった場合に削除するため」で29字。

採点講評（IPA）

設問4(2)は，正答率が高かったが，“契約終了”や，“不具合”などの，利用者から求められている背景ではない解答があった。業務の背景を読み取り，利用者から求められている内容を解答してほしかった。

本文の根拠

〔現在の生産管理の業務内容〕(1) ① 基準生産計画

これらの情報を基に，どの製品を，いつ，どれだけ生産するかという基準生産計画を月次で立案する。計画を立案する際には，工場側の状況も考慮している。

〔現行システムへの改善要望〕(1) 生産管理部門からの要望

基準生産計画の立案に当たっては，工場全体の稼働率の視点から，工場の設備機械，作業者などの生産能力とのバランスを調整する必要があるので，立案時にその調整をシステムで支援してほしい。

基準生産計画は，営業部門からの注文情報や販売計画・製品在庫状況の情報を基に立案し，その際に「工場側の状況も考慮している」と書かれている。設問は，時間的要素と営業部門からの情報を除いた残りを問うので，この「工場側の状況」の中身を答える。

中身は生産管理部門の改善要望に書かれている。基準生産計画の立案では，工場全体の稼働率の視点から，工場の設備機械，作業者などの生産能力とのバランスを調整する必要がある。つまり，考慮しているのは設備機械や作業者の生産能力がどれだけあるかという状況である。講評は，生産能力や稼働率まで書かずに単に「工場側の状況」とだけ書いた解答があったとしている。本文の語をそのまま写すだけでは足りず，要望の記述で具体化する必要がある。

20字で「設備機械，作業者など」と「生産能力の状況」を入れる。解答例は「設備機械，作業者などの生産能力の状況」で18字。

採点講評（IPA）

設問1(1)では，基準生産計画での工場側での考慮点について，工場側の生産能力や稼働率まで記述してほしかったが，単に工場側の状況とだけ記述した解答が見受けられた。

本文の根拠

〔現在の生産管理の業務内容〕(1) ① 基準生産計画

受注生産の製品については，顧客からの注文情報を営業部門から入手する。また，見込生産の製品については，販売計画及び製品在庫状況の情報を営業部門から入手する。

〔現行システムへの改善要望〕(1) 生産管理部門からの要望

基準生産計画立案の効率向上のために，現行の販売管理システムの注文情報，販売計画情報，製品在庫状況情報をシステム間で連携してほしい。

基準生産計画の材料は，製品の生産形態によって違う。受注生産の製品は顧客からの注文情報を，見込生産の製品は販売計画及び製品在庫状況の情報を使う。見込生産は汎用部品や保守用部品を在庫として保持して販売する形態なので，どれだけ売れる見込みか（販売計画）と，今どれだけ在庫があるか（製品在庫状況）から生産量を決める。

改善要望では，販売管理システムの注文情報，販売計画情報，製品在庫状況情報の三つを連携してほしいとしている。このうち見込生産に使うのは販売計画情報と製品在庫状況情報で，注文情報は受注生産のためのものである。

要望の表記に合わせて「販売計画情報」「製品在庫状況情報」と書く。

本文の根拠

〔製造実施計画のシステム要件検討〕(1) 作業日程計算

作業日程計算に必要な製造基準は，工程手順表マスタに定義されている。

〔製造実施計画のシステム要件検討〕(1) 作業日程計算

加工オーダの作業工程について，工程手順を参照する。次に，加工対象品の単位当たりの標準作業時間を基に，各作業工程の作業時間を見積もり，加工オーダの作業工程ごとの着手予定日，完了予定日を計算する。

作業日程計算の手順は本文に書かれている。工程手順を参照して加工オーダがどの作業工程を通るかを決め，単位当たりの標準作業時間から各作業工程の作業時間を見積もり，最後に作業工程ごとの着手予定日，完了予定日を計算する。製造基準（工程手順，標準作業時間など）はこの計算のために参照される。

設問は「作業日程上の何を求めるため」かを問うので，途中の作業時間の見積りではなく，作業日程計算の結果である着手予定日と完了予定日を答える。作業時間は日程を出すための中間の値である。着手予定日だけ，完了予定日だけでは日程が決まらないので両方を書く。

30字で「加工オーダの作業工程ごとの」と「着手予定日，完了予定日」を入れる。解答例は「加工オーダの作業工程ごとの着手予定日，完了予定日」で24字。

本文の根拠

〔製造実施計画のシステム要件検討〕(2) 作業負荷の山積み，作業負荷調整

全ての加工オーダの作業日程計算後，設備機械ごとに，その設備機械で加工対象となる各加工オーダの作業時間を日単位に累積していく。これを作業負荷の山積みという。

〔現在の生産管理の業務内容〕(3) 生産技術部門での業務

製造対象品の個々の作業工程の中での，作業標準，単位当たりの標準作業時間，使用する設備機械とその能力基準などの製造基準の設定を行い

表1 基準情報管理

生産管理パッケージの工程手順表マスタ及び設備機械マスタのメンテナンス機能の新規利用

作業負荷の山積みは設備機械ごとに行う。加工オーダの作業時間は作業工程ごとに見積もられるので，それを設備機械ごとに累積するには，各作業工程がどの設備機械を使うかが分かっていなければならない。設備機械がもつ生産能力と比べて負荷調整をするにも，設備機械マスタの情報と結び付ける必要がある。

生産技術部門は，作業工程ごとの製造基準として「使用する設備機械とその能力基準」を設定している。工程手順表マスタの作業工程に使用する設備機械を定義しておけば，それをキーに設備機械マスタを参照でき，作業工程の作業時間を設備機械の負荷として積み上げられる。講評は，作業工程とそこで使う設備機械とのマスタ上での関係を正しく理解できていない解答があったとしている。

15字で「作業工程で使用する設備機械」と書く。解答例は13字。

採点講評（IPA）

設問2(2)では，作業工程と当該作業工程で使用する設備機械とのマスタ上での関係を正しく理解できていないと思われる解答が見受けられた。

本文の根拠

〔製造実施計画のシステム要件検討〕(1) 作業日程計算

次に，加工対象品の単位当たりの標準作業時間を基に，各作業工程の作業時間を見積もり

〔現在の生産管理の業務内容〕(3) 生産技術部門での業務

製造対象品の個々の作業工程の中での，作業標準，単位当たりの標準作業時間，使用する設備機械とその能力基準などの製造基準の設定を行い

一つの作業工程の作業時間は，加工対象品の単位当たりの標準作業時間を基に見積もる。単位当たりの時間から全体の時間を出すには，それに加工する数を掛ける必要がある。したがって必要な情報は，単位当たりの標準作業時間と加工対象の数量の二つである。

単位当たりの標準作業時間は生産技術部門が作業工程ごとに設定する製造基準で，工程手順表マスタに定義されている。加工対象の数量は製造基準ではなく，加工オーダがいくつ作るかという側の情報である。講評は，単位当たりの標準作業時間は書けていたが，加工対象の数量が書けていない解答が多かったとしている。「単位当たり」という語に気付けば，数量が要ることが分かる。

「加工対象の数量」「単位当たりの標準作業時間」の二つを書く。

採点講評（IPA）

設問3では，設問で求めた二つの情報のうち，単位当たりの標準作業時間という解答は記述できていたが，作業時間を算出するために必要な加工対象の数量が記述できていない解答が多かった。

本文の根拠

〔現在の生産管理の業務内容〕(3) 生産技術部門での業務

また，製造現場の作業実態及び作業実績データを収集・分析し，製造基準の見直しや製造方法の改善を行っている。

〔現行システムへの改善要望〕(3) 経理部門からの要望

現行の会計システムの原価計算処理で，加工費計算に作業実績データの中の作業時間実績が必要となる。これが会計システムに反映されるようにしてほしい。

作業実績データを各部門が何に使うかは，業務内容と改善要望に書かれている。生産技術部門は，製造現場の作業実態及び作業実績データを収集・分析し，製造基準の見直しや製造方法の改善を行っている。経理部門は，会計システムの原価計算処理のうち加工費計算に，作業実績データの中の作業時間実績を使う。

新システムでは工程管理から設計技術システムと会計システムに作業実績データを連携するので，それぞれの部門の既存の用途にそのまま使われる。講評は，経理部門について加工費計算まで書かず，単に「原価計算を行う」とだけ書いた解答があったとしている。作業時間実績が要るのは原価計算の中の加工費計算である。

各20字で，生産技術部門は「製造基準の見直しや製造方法の改善」（16字），経理部門は「原価計算処理の加工費計算」（12字）と本文の語で書く。

採点講評（IPA）

設問4は，正答率が高かった。ただ，経理部門については，原価計算の中の加工費計算までの解答を記述してほしかったが，単に原価計算を行うというだけの解答が見受けられた。

本文の根拠

〔新システム構築の背景〕(2)

制度改正によるシステム改修が毎年発生しており，他の中核市と比較してシステム改修費用が多く掛かっている。

〔新システム構築の背景〕(2)

導入して標準機能を基に運用している他市では，システム改修を行わずに，製品バージョンアップなどの人事給与パッケージの標準保守の中で，全国の地方自治体に共通する制度改正に対応している。

〔フィット&ギャップ分析の実施〕

職員課は，分析に当たって，人事給与パッケージ導入の背景，目的を踏まえて，カスタマイズを極力行わず，標準機能に合わせて現行業務を見直す前提で検討することにした。

人事給与パッケージを利用することにした背景は外部評価の指摘にある。K 市は制度改正のたびにシステム改修をしており，改修費用が他の中核市より多く掛かっている。一方，人事給与パッケージを標準機能を基に運用している他市は，システム改修をせず，製品バージョンアップなどの標準保守の中で制度改正に対応している。

この利点は「標準機能を基に運用している」ことが前提である。カスタマイズした部分は標準保守の対象から外れるので，制度改正のたびにカスタマイズ部分を改修することになり，これまでと同じく改修費用が掛かる。だからカスタマイズを極力行わず，標準機能に合わせて現行業務の方を見直す。もう一つの指摘（サーバの使用率が低い）はハードウェア費用の話で，カスタマイズとは関係しない。

40字で「制度改正」に「人事給与パッケージの標準保守で対応できる」ようにすることを書く。解答例は「制度改正に対して人事給与パッケージの標準保守で対応できるようにしたいから」で36字。

本文の根拠

表1 項番7

庶務事務システムから，勤怠実績データをファイル出力し，出力したファイルを給与計算システムに手動で登録する。

表3 勤怠実績の自動連携

締め処理された勤怠実績データを給与計算用に自動連携する機能。締め処理が未完了で，連携されていない部署を確認できる。

表1 項番11

給与計算システムから給与支給明細書を印刷，仕分けし，各課の庶務担当者宛てに配送する。

表3 給与支給明細書の印刷

部署ごとに，庶務担当者，所属長などの権限を有する利用者が，所属する職員の給与支給明細書を印刷する機能。

〔例月給与の計算・支給事務に係る標準機能の利用検討〕

一部の部署を除き電子給与支給明細書の交付を導入する方針とし，表 3 に示す標準機能については，全て利用することにした。

表1 で職員課が行う作業は項番6〜11である。これを表3 の標準機能と一つずつ突き合わせ，作業そのものが要らなくなるものを選ぶ。項番7 の勤怠実績データの手動登録は，勤怠実績の自動連携で締め処理済みのデータが給与計算用に自動で連携されるので不要になる。項番11 の給与支給明細書の印刷・仕分け・配送は，電子給与支給明細書の交付を導入し，PC のない一部の部署でも各部署の庶務担当者などが自部署の分を印刷できるので，職員課の作業ではなくなる。

残りは機能があっても職員課の作業が残る。項番6 は，連携されていない部署を確認できても未完了の課への督促は人が行う。項番8 は，外部機関からデータを受領し，登録画面から取り込む作業が残る。項番9 は，計算は機能が行うが，支給額の確認機能を使って確認する作業は残る。項番10 は，口座振込データを作成・出力しても指定金融機関への提出は残る。講評はこの設問の正答率が低かったとし，不要になるものと残るものを適切に見極めてほしいとしている。

表1 の項番で「7，11」と答える。

採点講評（IPA）

設問1(2)は正答率が低かった。新システムの標準機能を十分理解し，現在行っている事務について，新システムによって不要になるものと，引き続き残るものを適切に見極めてほしかった。

本文の根拠

表1 項番5

各課の庶務担当者が前月の出勤簿の記録を庶務事務システムに入力，確定する。それによって，庶務事務システム上で当該課における前月分の勤怠実績の締め処理が行われる。

表2 打刻

出退勤時刻を簡易登録する機能。ポータル画面上で“出勤”ボタン又は“退勤”ボタンを押すと，ボタンを押した時刻を出退勤時刻として記録し，出勤簿に自動反映する。

〔勤怠管理に係る標準機能の利用検討〕

①表 1 において毎月発生している，ある作業の負担を軽減する

下線①は「表1 において毎月発生している」作業なので，頻度が毎月の項番5〜12から選ぶ。打刻機能は出退勤時刻を記録して出勤簿に自動反映する機能なので，軽減されるのは出勤簿の記録にかかわる作業である。項番5 では，各課の庶務担当者が紙の出勤簿に記録された前月分の出退勤時刻を庶務事務システムに入力し，確定している。

打刻を使えば出退勤時刻が出勤簿に自動で入るので，庶務担当者が前月の出勤簿の記録を手で入力する負担が軽くなる。項番1・2 も出勤簿に関係するが，頻度は毎日なので下線①には当たらない。なお，打刻機能は最終的に採用されず，代わりにタイムレコーダのデータを月に 1 回取り込むことにしたが，これも出勤簿への自動反映で同じ作業を軽くする。

35字で項番5 の作業内容を「前月の出勤簿の記録を庶務事務システムに入力，確定する作業」と書く。解答例は28字。

本文の根拠

表1 項番1

ほとんどの職員は8時30分から8時45分の間に出勤し，出勤時刻を紙の出勤簿に記録する。

〔新システム構築の背景〕(1)

庶務事務システムは，最もアクセスが集中する時間帯が，前勤務日に時間外勤務などを行った職員が実績を申請する 8 時 45 分から 12 時であり，利用する時間帯が比較的分散している。

表2 打刻

ポータル画面上で“出勤”ボタン又は“退勤”ボタンを押すと，ボタンを押した時刻を出退勤時刻として記録し，出勤簿に自動反映する。

打刻機能では，職員が出勤したときにポータル画面の“出勤”ボタンを押す。表1 によれば，ほとんどの職員は 8 時 30 分から 8 時 45 分の間に出勤する。約 2,000 人の職員の多くがこの 15 分ほどの間に一斉にシステムにアクセスすることになる。

現行の庶務事務システムは，最もアクセスが集中する時間帯でも時間外勤務などを行った一部の職員が 8 時 45 分から 12 時にかけて申請するだけで，利用する時間帯が比較的分散している。出勤時刻の打刻はほぼ全職員が同じ時間帯に行うので，同時アクセス数が現行より多くなる。講評は，毎朝同じ時間帯に出勤するという業務面の理由と，打刻によってアクセスが集中するというシステム面の理由の両方に触れてほしかったが，どちらか一方の解答が多かったとしている。

25字で「毎朝の出勤時間帯」と「アクセスが集中する」の両方を入れる。解答例は「毎朝の出勤時間帯にアクセスが集中するから」で20字。

採点講評（IPA）

設問2(2)は，ほとんどの職員が毎朝同じ時間帯に出勤するという業務面の理由と，出勤時刻の打刻によってアクセスが集中することのシステム面の理由の両方に触れて解答してほしかったが，どちらか一方の記述しかない解答が多かった。

本文の根拠

〔勤怠管理に係る標準機能の利用検討〕

その結果，一部の部署では庶務担当者以外の職員に PC が貸与されていないことと

〔例月給与の計算・支給事務に係る標準機能の利用検討〕

一部の部署を除き電子給与支給明細書の交付を導入する方針とし

表3 電子給与支給明細書の交付

電子文書ファイルによる給与支給明細書を参照，ダウンロードする機能。

電子給与支給明細書は，電子文書ファイルを参照，ダウンロードして受け取る。これには職員が PC を使えることが前提になる。ところが，勤怠管理の検討で分かったとおり，一部の部署では庶務担当者以外の職員に PC が貸与されていない。そのため電子交付は「一部の部署を除き」導入することになった。

PC のない職員には，これまでどおり紙の給与支給明細書を配布する必要がある。表3 の給与支給明細書の印刷機能は，部署ごとに庶務担当者などが所属する職員の明細書を印刷できるので，PC が貸与されている庶務担当者が印刷して配布できる。

40字で「PC が貸与されていない職員」と「印刷して配布する」を入れる。解答例は「PCが貸与されていない職員に給与支給明細書を印刷して配布するから」で32字。

本文の根拠

〔例月給与の計算・支給事務に係る標準機能の利用検討〕

寒冷地手当は，職員が世帯主であるか否か，扶養親族があるか否かといった世帯の区分に応じた額を，支給対象期間の初月の例月給与に加えて一括して支給する。

〔例月給与の計算・支給事務に係る標準機能の利用検討〕

支給対象職員に対して支給対象期間の例月給与に含めて毎月支給する。日割りでの支給額の計算はできず，追給及び返納にも対応していない。

現在の規則では，寒冷地手当は支給対象期間の初月の例月給与に加えて一括して支給する。一方，L 社パッケージの標準機能は，支給対象期間の例月給与に含めて毎月支給する。支給のしかたが一括と毎月とで食い違っており，これがギャップである。

職員課はカスタマイズを極力行わず，標準機能に合わせて現行業務を見直す前提で検討している。したがって，機能を追加開発するのではなく，規則の方を標準機能に合わせて毎月支給に変更する。講評は，追給及び返納を廃止するといった解答があったとしている。追給及び返納が要らなくなるのは毎月支給に変えた結果であり，規則で変えるのは支給のしかたである。

20字で「一括支給を毎月支給に変更する」と書く。解答例は15字。

採点講評（IPA）

設問3(2)は，追給及び返納を廃止するといった解答が見受けられた。寒冷地手当の支給を一括支給から毎月支給に変更することによって，結果として追給及び返納が不要になるという業務上の関係を正しく理解してほしかった。

本文の根拠

〔例月給与の計算・支給事務に係る標準機能の利用検討〕

支給対象期間中に，世帯の区分の変更，支給対象地域をまたぐ異動などが生じた場合には，月割りで手当額を計算して，不足額を追加で支給（以下，追給という）又は支給済額を例月給与から控除（以下，返納という）する。

〔例月給与の計算・支給事務に係る標準機能の利用検討〕

なお，手当額は各月の 1 日時点の情報を基準に算出し，月途中の変更，異動などは考慮しない。

〔例月給与の計算・支給事務に係る標準機能の利用検討〕

日割りでの支給額の計算はできず，追給及び返納にも対応していない。

一括支給では，初月に期間全体の手当をまとめて払うので，期間の途中で世帯の区分が変わったり，支給対象地域をまたぐ異動があったりすると，払い過ぎや払い不足が生じる。現在の規則はそのために月割りで計算し直して追給又は返納をしている。L 社パッケージの標準機能は追給及び返納に対応していないので，規則をそのままにすれば，この機能を追加開発しなければならない。

毎月支給に変えれば，手当額は各月の 1 日時点の情報を基準にその月の分だけ算出される。途中で世帯の区分が変わっても，翌月からその時点の区分の額を払えばよく，既に払った分との差額を精算する必要がない。したがって，下線②の状況は期間中の世帯の区分の変更や異動で，不要になるのは追給及び返納の機能である。

状況は40字で規則の文言「支給対象期間中に，世帯の区分の変更，支給対象地域をまたぐ異動などが生じた場合」（38字）を写す。機能は15字で「追給及び返納の機能」（9字）と書く。

本文の根拠

〔農業生産システムの概要〕(2) 農場の情報ネットワークの構築と環境モニタリング

無線 LAN 中継機能を利用して，農場内のどこからでも無線 LAN に接続できるようにする。そのために，環境モニタリング機能と無線 LAN 中継機能を併せもつモニタリングポストを開発する。

〔開発項目の検討結果〕(2) モニタリングポストの設置

農場内のどこからでも無線 LAN を使用できるようにモニタリングポストを設置する。

表1 センサによる測定

気温・湿度，土壌中の温度・酸性度・電気伝導度，水田の水位・水温などを，必要に応じてセンサによって測定する。

モニタリングポストは，環境モニタリング機能と無線 LAN 中継機能を併せもつ装置として開発される。どちらの機能も，設置した場所でなければ働くかどうかを確かめられない。そこで設置後には，この二つの機能を確認する。

無線 LAN 中継機能は，農場内のどこからでも無線 LAN に接続できるようにするためのもので，設置位置によって電波が届くかどうかが変わる。モニタリングポスト間，農業機械やモバイル端末との間で中継できるかを現地で確かめる必要がある。環境モニタリング機能は，気温・湿度，土壌の状態，水田の水位などをセンサで測定するので，設置した農地で正しく測定し，サーバにアップロードできるかを確かめる。

各15字で本文の機能名どおり「環境モニタリング機能」（10字）と「無線 LAN 中継機能」（9字）と書く。

本文の根拠

〔開発項目の検討結果〕(3) モニタリングポストによる環境モニタリング

ここで，隣接するモニタリングポストからのデータは同じ傾向を示す場合が想定できるので，内容によっては，保存するデータをサーバが選択できるようにする。

表1 無線LANによるデータ通信

測定した環境モニタリングデータ，太陽電池パネルの発電量，及び二次電池残量を送信する。

〔開発項目の検討結果〕(3) モニタリングポストによる環境モニタリング

その結果，各農場の年間日射量と太陽電池パネルの発電量の関係を基に，測定した発電量から日射量をサーバで推計できることが分かった。

発電量は日射量で決まり，日射量は天候によって日々変わるので，発電量が少ないというだけでは太陽電池パネルの異常なのか天候のせいなのか区別できない。比べる相手は，同じ天候の下にあるパネルがよい。本文は，隣接するモニタリングポストからのデータは同じ傾向を示す場合が想定できるとしている。

各モニタリングポストは太陽電池パネルの発電量をサーバに送信している。隣接するモニタリングポストのパネルは同じ日射を受けるので，発電量も同じ傾向を示すはずである。1 台だけ発電量が大きく下回れば，そのパネルの異常と判断できる。講評は，“サーバで予測した発電量と比較する”という誤答があったとしている。予測値は気象状況の影響で実際とは必ずしも一致しないので，異常の判定には向かない。

30字で「隣接するモニタリングポストの発電量データと比較する」と書く。解答例は26字。

採点講評（IPA）

設問1(2)では，太陽電池パネルの異常を検出する方法を問うたが，“サーバで予測した発電量と比較する”との誤った解答が見受けられた。太陽電池パネルの発電量は，気象状況の影響なども受け，予測値とは必ずしも一致しない。また，農場内には複数のモニタリングポストが設置されていることを考慮してほしかった。

本文の根拠

〔開発項目の検討結果〕(4) 農業機械の現在位置測位の高精度化

モニタリングポストの識別コード，測定した距離と方位をサーバに送信して，サーバが農業機械の正確な現在位置を算出する。サーバは算出した測位データを保存し，農業機械にも送信する。

〔開発項目の検討結果〕(5) 農業機械の自動走行の高度化

一定範囲内の自動走行の場合，サーバが農業機械に作業域を指示し，自動走行させる。

〔開発項目の検討結果〕(5) 農業機械の自動走行の高度化

障害物を検出した場合は走行を停止し，前方の農業機械にも通知して停止させる。

サーバ算出測位では，農業機械の正確な現在位置を算出するのはサーバで，農業機械はサーバから送られる測位データで自分の位置を知る。データ通信が切断されると，農業機械は正確な現在位置が分からなくなる。GPS 受信機による測位は誤差が大きいので，そのまま無人で自動走行を続けると，作業域を外れたり何かにぶつかったりするおそれがある。

農業機械は無人で走行しているので，異常が起きても人がすぐに止めることはできない。本文でも，障害物を検出した場合は走行を停止させるとしている。安全を確保するには，通信の切断を検出したら農業機械が自ら走行を止めるようにしておく必要がある。

25字で「データ通信切断時に」「自動的に走行を停止する」と書く。解答例は21字。

本文の根拠

表2 無線LANによるデータ通信

モニタリングポスト及び他の農業機械とのデータ通信機能によって，次のデータ送受信を行う。

表2 無線LANによるデータ通信

動作履歴のサーバへの送信

〔X 社の農業機械の現状と課題〕

農業機械の動作履歴は，内部に記録され，必要に応じて取り出せる。

農業機械は動作履歴などをサーバに送信する。通信が切断されている間のデータは一時保管しておき，復帰後に送ればよい。しかし，切断の直前に送ったデータがサーバに届いたかどうかは，農業機械の側からは分からない。送ったつもりで届いていないデータがあれば，それが漏れになる。

そこで，サーバがデータを受け取ったことを確認する機能を持たせる。受信を確認できたデータは送信済みとし，確認できていないデータは一時保管の対象として復帰後に再送する。こうすれば，切断のタイミングにかかわらずサーバへのデータを漏れなく送れる。設問はデータの一時保管以外の機能を問うので，保管したデータを送り直す判断の元になる受信確認を答える。

25字で「サーバがデータを受け取ったことを確認する機能」と書く。解答例は22字。

本文の根拠

〔開発項目の検討結果〕(4) 農業機械の現在位置測位の高精度化

農業機械は GPS 受信機による測位データを基に，近くのモニタリングポストを検索し，ステレオカメラと方位センサを用いてその距離と方位を測定する。測定したデータ及びモニタリングポストの位置情報を用い，農業機械が正確な現在位置を算出する。

〔開発項目の検討結果〕(2) モニタリングポストの設置

設置した位置は正確に測位し，モニタリングポストの位置情報としてサーバに登録する。

自律算出測位では，農業機械自身が，測定したモニタリングポストまでの距離と方位と，そのモニタリングポストの位置情報とから正確な現在位置を算出する。近くのモニタリングポストを検索するのにも，どこにモニタリングポストがあるかを知っていなければならない。

モニタリングポストの位置情報は，設置時に正確に測位してサーバに登録されている。農業機械はそれを持っていないので，走行を始める前にサーバに要求して受け取っておく必要がある。サーバ算出測位ではサーバが算出するので，この要求は要らない。

20字で「モニタリングポストの位置情報」と本文の語で書く。解答例は14字。

本文の根拠

〔開発項目の検討結果〕(4) 農業機械の現在位置測位の高精度化

サーバ算出測位：農業機械は，ステレオカメラをスキャンさせて，近くのモニタリングポストを認識する。モニタリングポストの識別コード，測定した距離と方位をサーバに送信して，サーバが農業機械の正確な現在位置を算出する。サーバは算出した測位データを保存し，農業機械にも送信する。

表2 一定範囲内の自動走行

複数の農業機械に，異なる作業域を自動走行させた場合でも，未走行領域が生じないよう，正確な走行制御を行う。

表2 縦列走行

前後の農業機械が連携し，走行経路が正確に重なるように制御する。

サーバ算出測位では，農業機械が測定したデータをサーバに送り，サーバが現在位置を算出して農業機械に送り返す。この送受信と計算には時間が掛かり，その間も農業機械は走行し続けている。受け取った測位データは，測定した時点の位置であって，受け取った時点の位置ではない。

自動走行の高度化では，未走行領域が生じないような正確な走行制御や，走行経路が正確に重なる縦列走行を目指している。送受信の遅延の分だけ位置がずれていると，この正確な制御ができない。講評は，“データ送受信に時間が掛かる”という解答が多かったが，その間にも農業機械が移動していることも書いてほしかったとしている。遅延そのものではなく，遅延の間に移動することで生じる位置のずれが配慮すべき点である。

20字で「データ送受信の遅延」と「位置ずれ」を入れる。解答例は「データ送受信の遅延による位置ずれ」で16字。

採点講評（IPA）

設問2(2)(b)は，正答率が低かった。“サーバと農業機械間のデータ送受信に時間が掛かる”との解答が多かったが，その間にも農業機械が移動していることも併せて記述してほしかった。

本文の根拠

表2 縦列走行

ステレオカメラによって，前方の農業機械との距離を測定し，前方の障害物を高精度に検出する。

〔開発項目の検討結果〕(5) 農業機械の自動走行の高度化

縦列走行の場合，後方の農業機械からステレオカメラで前方の農業機械を監視し，一定の距離を保って自動走行させる。ステレオカメラによって，前方の農業機械との間の障害物も検出できる。障害物を検出した場合は走行を停止し，前方の農業機械にも通知して停止させる。

前方の農業機械の走行経路を送信して後方に同じ経路をたどらせるだけなら，後方の農業機械は前を見ていなくても走れる。しかしそれでは，前方の農業機械が通り過ぎた後に経路上に現れた人や物に気付けない。

ステレオカメラで前方の農業機械を監視して追走すれば，前方の農業機械との距離を測れるだけでなく，前方の農業機械との間にある障害物も高精度に検出できる。障害物を検出すれば走行を止め，前方の農業機械にも通知して停止させることができるので，安全確保につながる。取組方針の「危険な作業からの解放」を無人の縦列走行で実現するための仕組みである。

20字で表2 の語を使い「前方の障害物を高精度に検出できる」と書く。解答例は17字。

本文の根拠

〔X 社の農業機械の現状と課題〕

農業機械の動作履歴は，内部に記録され，必要に応じて取り出せる。

〔X 社の農業機械の現状と課題〕

適切かつ迅速な保守サービスへの利用者からの要望は強い。

表2 無線LANによるデータ通信

動作履歴のサーバへの送信

現行製品では，農業機械の動作履歴は内部に記録され，必要に応じて取り出すだけである。これでは故障が起きてから履歴を取り出して調べることになり，迅速な保守にはならない。新しい農業生産システムでは，表2 のとおり動作履歴を無線 LAN でサーバへ送信するので，サーバで常に動作履歴を集められる。

集めた動作履歴を分析すれば，故障の兆候を捉えて故障が起きる前に予測し，部品の手配や点検を前もって行える。これが適切かつ迅速な保守サービスにつながる。サーバには生産計画に基づいて農業機械の運用・保守などを指示・サポートする役割もある。

各10字で，データは「農業機械の動作履歴」（9字），機能は「故障予測」（4字）と書く。

本文の根拠

〔開発項目の検討結果〕(1) サーバの機能

サーバには，農業機械の走行に関する指示を行う機能，農業機械による現在位置の測位をサポートする機能，農場内の機器の監視・制御を行う機能，環境モニタリングデータを監視して必要な措置を行う機能，農場内において収集したデータをデータベース化する機能，これらのデータを分析して生産計画を立案・変更する機能を実装する。

〔開発項目の検討結果〕(1) サーバの機能

サーバを X 社が提供するクラウドサービスと接続し，複数の農場のデータベースが連携できるようにする。

〔農業生産システムの概要〕(2) 農場の情報ネットワークの構築と環境モニタリング

長期天気予報などの情報を収集するために，農場内オフィスに設置したルータを介してインターネットに接続できるようにする。

サーバの機能のうち，農業機械の走行に関する指示，現在位置の測位のサポート，農場内の機器の監視・制御は，走行中の農業機械や農場内の機器とやり取りしながらその場で結果を返す必要がある。設問2(2)(b)で見たとおり，送受信に時間が掛かればその間に農業機械が移動して位置がずれてしまう。これらの機能には高い応答性が要求される。

クラウドサービスは農場の外にあり，農場内オフィスのルータを介してインターネット経由で接続するので，農場内のサーバよりも通信に時間が掛かり，応答が遅れるおそれがある。一方，データベース化や生産計画の立案・変更のように即時の応答を必要としない機能はクラウドサービスに置いても支障がない。講評は，この設問の正答率は高く，クラウドサービス利用上の問題はよく理解されていたとしている。

15字で「高い応答性が要求される」と共通する特徴を書く。解答例は12字。

採点講評（IPA）

設問4では，サーバからクラウドサービスへの移管が適切ではない機能に共通する特徴を問うたが，正答率は高かった。クラウドサービス利用上の問題については，よく理解されているようであった。