平成25年度 秋期 午後Ⅰ

本文の根拠

〔新システムの機能〕(3) 安否確認応答機能

登録された緊急連絡先がメールアドレスか電話番号かを自動判別し，メール送信又は電話の発呼を行う。

〔新システムの機能〕(3) 安否確認応答機能

対象者全員に送信又は発呼が終了すると，安否情報が登録されていない社員について，第 2 連絡先へ送信又は発呼を行う。同様に第 5 連絡先まで繰り返す。

〔新システムの機能〕(4) 安否情報自主登録機能

社員が，安否確認システムへ直接アクセスすることによって，自主的に安否情報を登録する。

〔新システムの運用の検討〕

新システムにアクセスするための URL は，全社員が常時携帯している危機管理ハンドブックに記載する。

安否確認応答機能は，新システムの側から登録済みの緊急連絡先へメールを送るか電話を掛け，社員はその応答として安否を登録する仕組みである。連絡先は最大5件で，第5連絡先まで試しても届かなければそれで終わる。つまり，新システムからの緊急連絡を受けられない社員は，応答機能だけでは安否を登録できない。安否情報自主登録機能は，そうした社員が自分から新システムにアクセスして登録するための機能である。

本文は，新システムにアクセスするための URL を全社員が常時携帯している危機管理ハンドブックに記載するとしている。これは，緊急連絡のメールに埋め込まれた URL を使えない社員でも，自分から新システムにたどり着けるようにするためであり，自主登録の使い方と対応している。講評によれば，“どのような場合に”だけを答えた受験者が多かった。設問は「どのような場合に」と「どのように利用するか」の二つを問うているので，両方を書く必要がある。

35字で「緊急連絡を受けられない場合」と「自主的に安否情報を登録する」を一文にする。解答例は「緊急連絡を受けられない場合に，自主的に安否情報を登録すること」で30字。

採点講評（IPA）

設問1では，安否確認自主登録機能について，“どのような場合に，どのように利用するか”を問う問題であったが，“どのような場合に”だけを解答した受験者が多かった。

本文の根拠

〔安否確認システムの導入に向けての検討〕(4)

安否確認システム以外の既存のシステム（以下，社内システムという）は社員コードを共通の利用者 ID としてシングルサインオンを実現しているので，各社員は自分の社員コードを覚えている。

〔新システムの機能〕(6) 個人マスタ管理機能

利用者 ID は 10 桁以内の数字である。

〔新システムの導入に当たっての対応〕(1) 社員コード変換

会社及び雇用形態を表す 2 桁のアルファベットを，それぞれ 01〜26 の数字に置き換えて 4 桁の数字とし，その後に社員コードの下 4 桁の数字を加え，8 桁の新番号を作成する。

〔新システムの導入に当たっての対応〕(1) 社員コード変換

B 課長は，安否確認システムの利用頻度が少なく，また，社員が緊急時に利用しなければならないことを考慮して③を採用することを決定した。

新システムの利用者 ID は10桁以内の数字なので，アルファベットを含む社員コードはそのまま使えない。一方，各社員は社員コードを覚えている。③はアルファベットを 01〜26 の数字（アルファベットの順番）に置き換え，下4桁をそのまま付けるだけなので，社員は自分の社員コードから利用者 ID をその場で導ける。

①は社員コードと無関係な番号を新たに覚える必要がある。②はアルファベットの組合せと数字3桁の対応を知らなければ導けない。安否確認システムは利用頻度が少ないので，新しい番号を覚えさせても忘れやすく，しかも緊急時に使わなければならない。何かを調べなくても社員コードから導けることが③の優位な点である。講評は，単に“覚えやすいから”といった客観的な根拠に乏しい解答が見受けられたとしている。なぜ覚えなくてよいのか（社員コードから導ける）まで書く。

25字で「社員コードだけで導ける」ことを書く。解答例は「社員コードだけで容易に導ける利用者IDだから」で22字。

採点講評（IPA）

設問2(1)では，社員コードの変換方式について，三つの方式の比較で，他の二つの方式に比べてどう優位かを問うたが，単に“覚えやすいから”といった，客観的な根拠に乏しい解答が見受けられた。一方，(2)は正答率が高かった。多くの受験者が，社内システムの共通パスワードが安否確認システムに反映されるタイミングを理解し，正解を導くことができたと思われる。

本文の根拠

〔現状調査の結果〕(2)

共通パスワードは社員が随時変更可能であり，社内システムにリアルタイムで反映される。

〔新システムの導入に当たっての対応〕(2) パスワード連携

そこで，リアルタイムでの反映は行わず，夜間のバッチ処理で反映させることにした。

〔新システムの導入に当たっての対応〕(2) パスワード連携

社内システムと同じパスワードに限定するために，新システムのパスワード変更機能は使用させないことにした。

共通パスワードは社員が随時変更でき，社内システムにはすぐ反映される。しかし新システムへの反映は夜間のバッチ処理なので，社員がパスワードを変更した日は，夜間のバッチ処理が終わるまで新システムには変更前のパスワードが残っている。その間に新システムにアクセスするには，旧パスワードを使わなければならない。

新システム側でパスワードを変更させないことにしているので，社員が自分で新システムのパスワードを合わせることもできない。社内システムと同じパスワードが使えると思っている社員は，変更した当日に新しいパスワードで入れず困ることになる。これを全社員に周知しておく必要がある。講評によれば，この設問は正答率が高かった。

40字で「変更した日は」という期間と「旧パスワードでアクセスする」という行動を書く。解答例は「パスワードを変更した日は，安否確認システムには旧パスワードでアクセスすること」で38字。

採点講評（IPA）

設問2(1)では，社員コードの変換方式について，三つの方式の比較で，他の二つの方式に比べてどう優位かを問うたが，単に“覚えやすいから”といった，客観的な根拠に乏しい解答が見受けられた。一方，(2)は正答率が高かった。多くの受験者が，社内システムの共通パスワードが安否確認システムに反映されるタイミングを理解し，正解を導くことができたと思われる。

本文の根拠

〔安否確認システムの導入に向けての検討〕(2)

A 社グループでは，ほとんどの社員が携帯電話を保有しているので，これを有効に活用する。

〔新システムの機能〕(3) 安否確認応答機能

メールには応答用 Web ページの URL を埋め込み，この URL にアクセスすることによって社員が自動認証されて安否情報を登録することができる。

〔新システムの運用の検討〕

新システムに登録する緊急連絡先の優先順位は，携帯電話メールアドレス，電子メールアドレス，携帯電話番号，自宅電話番号の順とする。

緊急連絡は第1連絡先から順に送り，登録がなければ次の連絡先へ回すので，最優先の連絡先は最も確実に社員に届き，すぐ応答できるものがよい。ほとんどの社員が携帯電話を保有しており，携帯電話は常に身に着けている可能性が高いので，震災時に社員がどこにいても届きやすい。

さらに，メールは電話と違って着信の時点で応答しなくてよい。社員は落ち着いたときにメールを開き，埋め込まれた URL から自動認証で安否情報を登録できる。電話の発呼は応答しなければ繰り返すだけで，その場で出られなければ登録できない。電子メールアドレス（PC 向け）は PC の前にいないと読めない。携帯電話メールアドレスは，常に携帯していることと任意のタイミングで応答できることの両方を満たす。

40字で「常時携帯している」と「任意のタイミングで応答できる」の二つを理由として書く。解答例は「携帯電話は常時携帯している可能性が高く，任意のタイミングで応答できるから」で36字。

本文の根拠

〔安否確認システムの導入に向けての検討〕(3)

社員の緊急連絡先は，社員が自ら登録する。

〔新システムの運用の検討〕

③ 全社員への緊急連絡という観点から，あるリスクを回避するため

〔新システムの運用の検討〕

また，B 課長は，次の三つの目的のために，今後，年 2 回定期的に安否確認訓練を行うことを提言した。

緊急連絡先は社員が自ら登録するので，人事マスタのように会社が管理する情報とは違い，メールアドレスや電話番号が変わっても社員が登録し直さなければ古いままになる。古い連絡先しか登録されていない社員には，本番の地震のときに緊急連絡が届かない。

定期的に安否確認訓練を行えば，訓練の緊急連絡が届かない社員が見つかり，連絡先の変更を登録させるきっかけになる。①のシステムの動作確認や②の操作の習熟とは別に，「全社員への緊急連絡という観点」から回避したいのは，一部の社員に連絡が届かなくなることである。年2回と定期的に行うのも，連絡先の変更が時間とともに積み重なるからである。

35字で原因（社員が連絡先の変更を登録しない）と結果（緊急連絡が届かない）をつなげ，「リスク」で結ぶ。解答例は「社員が緊急連絡先の変更を登録せず，緊急連絡が届かなくなるリスク」で31字。

本文の根拠

〔安否確認システムの導入に向けての検討〕(8)

安否情報が一定時間以内に確認できない社員のうち，地震区域にいないことが明らかな社員については，一旦，安否確認作業の対象外とする。

〔安否確認システムの導入に向けての検討〕(1)

社員に対する安否確認は，A 社グループの国内営業地域内で震度 5 強以上の地震が発生したときに発動する。

〔現状調査の結果〕

海外出張者については，危機管理の観点から，誰がどの都市に出張しているかの情報を，総務部が正確に把握している。

〔現状調査の結果〕

常時，全社員の数％に当たる約 100 人が海外出張をしていることが分かった。

個別確認の対象は，安否が確認できない社員のうち，地震区域にいる可能性がある社員である。地震区域にいないことが明らかな社員を確認担当者に示せれば，その分だけ個別確認の対象を減らせる。安否確認は国内の地震で発動するので，海外に出張している社員は地震区域にいないことが明らかである。

海外出張者は常時約100人おり，総務部が誰がどの都市に出張しているかを正確に把握している。この海外出張者の一覧を確認担当者に渡せば，海外出張者を個別確認から外せる。講評は，社員の勤務場所や担当営業区域といった解答が散見されたが，これらだけでは地震区域にいないことは判断できないとしている。勤務場所が地震区域の外でも，その時にどこにいるかは分からないからである。本文が「正確に把握している」と書いている情報を使う。

内容は10字で「海外出張者の一覧」（8字）。理由は30字で「国内にいない」と「個別確認の対象としない」をつなぐ。解答例は27字。

採点講評（IPA）

設問3(3)では，個別確認の対象人数を少なくするための情報を問うた。個別確認は，地震区域にいないことが明らかである社員以外について行われるので，地震区域にいないことを示す情報が必要となる。社員の勤務場所や担当営業区域といった解答が散見されたが，これらの情報だけでは判断できないことに注意して解答することが求められる。

本文の根拠

図2 処理3

代行処理として成立した出金取引及び事故カードの設定を，取引発生順に 1 取引ごとに，E 銀行システム宛てにトランザクションとして送信し，E 銀行元帳を更新する。D 社からの送信時間は，1 件／秒である。代行処理した取引の送信は，6:30 から開始し，国内 ATM サービスが開始する 7:00 までに完了させる。

図2 処理3

注1）①の送信時間は，②の処理の影響を受けない。

〔海外 ATM 利用時の処理概要〕

代行処理した取引の件数が増加した場合，図 2 の処理 3 の開始時刻の見直しを行う。

処理3の①は 6:30 に送信を始め，国内 ATM サービスが始まる 7:00 までに終えなければならない。使える時間は30分，つまり1,800秒で，送信時間は1件／秒なので，送れるのは1,800件までである。代行取引がこれを超えると 7:00 までに送り終わらないので，処理3の開始時刻を早める必要がある。

注1）により①の送信時間は②の処理の影響を受けないので，②のリアルタイム処理を差し引いて考える必要はない。なお，海外 ATM の出金取引は1日約2,400件で全時間帯にほぼ同様と予測されているので，代行処理時間（日曜日 21:00〜月曜日 6:30 の9時間30分）の取引は2,400×9.5／24＝950件程度であり，当面は1,800件に収まる。

答えは件数だけでよい。30分×60秒×1件／秒で「1,800」。講評によれば正答率は高かった。

採点講評（IPA）

設問1では，(1)の正答率が高かった。(2)は，代行処理した取引の反映が処理時間内に終了しなかった場合にE銀行元帳に不整合が生じる理由について記述する問題であったが，単に“処理時間内に終了しないから”との解答が散見された。

本文の根拠

〔E 銀行の勘定系システム及び海外 ATM サービスのシステム概要〕(2)

国内 ATM は，毎週日曜日の 21:00 から翌月曜日の 7:00 まで停止している。

〔E 銀行の勘定系システム及び海外 ATM サービスのシステム概要〕(8)

この元帳反映時には，E 銀行で(4)のチェックを再度行う。

図2 処理3

代行処理した取引の送信は，6:30 から開始し，国内 ATM サービスが開始する 7:00 までに完了させる。

7:00 になると国内 ATM サービスが再開し，国内 ATM の取引が E 銀行元帳を直接更新し始める。処理3の送信が 7:00 までに終わらないと，代行処理時間中に実際には先に行われた海外 ATM の取引が，後から行われた国内 ATM 取引よりも後で E 銀行元帳に反映される。取引の順序が逆転するのである。

代行処理した出金取引は，元帳反映時に(4)のチェック（支払可能残高の範囲内か，事故カードの設定がないか）を再度受ける。順序が逆転すると，例えば国内 ATM で先に出金されて残高が減り，D 社で既に成立して現金を払い出した出金取引が E 銀行元帳に反映できなくなる。これが不整合である。講評は，単に“処理時間内に終了しないから”との解答が散見されたとしている。時間内に終わらないと何が起きるのか，国内 ATM 取引との順序まで書く。

35字で「代行処理した取引」と「国内ATM取引」の順序が逆転することを書く。解答例は「代行処理した取引と国内ATM取引の順序が逆転する可能性があるから」で32字。

採点講評（IPA）

設問1では，(1)の正答率が高かった。(2)は，代行処理した取引の反映が処理時間内に終了しなかった場合にE銀行元帳に不整合が生じる理由について記述する問題であったが，単に“処理時間内に終了しないから”との解答が散見された。

本文の根拠

表1 送信データ

店番号（主キー），口座番号（主キー），顧客名，顧客住所，顧客電話番号，事故カードの設定情報，支払可能残高，カード暗証番号，抽出日時（注1）

表2 日曜日の 0:00〜21:00

リアルタイムでの送信時には，電文長に制約があるので，表1 の送信データの属性のうち，送信を省略しても問題がないと判断した三つの属性を省略する。

〔E 銀行の勘定系システム及び海外 ATM サービスのシステム概要〕(3)

口座の開設，及び顧客名，顧客住所，顧客電話番号などの顧客属性の変更は，平日の 8:00 から 21:00 まで支店窓口で受け付けている。

リアルタイムで送信するのは日曜日の 0:00〜21:00 で，支払可能残高など変更が発生した属性を送る。一方，顧客名，顧客住所，顧客電話番号の変更は平日の 8:00〜21:00 に支店窓口でしか受け付けていない。日曜日にはこの三つの属性は変わらないので，土曜日・日曜日の 0:00〜2:00 のバッチ処理で送った値のままでよく，リアルタイムの電文から省略しても D 社元帳は正しいままである。

他の属性は省略できない。事故カードの設定情報と支払可能残高は日曜日にも変わり，D 社での(4)のチェックに使う。カード暗証番号も国内 ATM でカード暗証番号変更サービスが利用できるので日曜日に変わりうる。店番号と口座番号は主キーで，抽出日時は D 社元帳の整合性の判断に使う。講評は，属性名の正答率は高かったが，理由については関係のない時間帯を記述しているなど誤った解答が多かったとしている。問題になるのはリアルタイム送信を行う日曜日の時間帯である。

属性は表1 の表記どおりに三つ並べる。理由は25字で「日曜日には更新されない」を書く。解答例は「三つの属性は，日曜日には更新されないから」（20字）で，「三つの属性の変更は，平日だけ可能だから」（19字）も別解に挙がっている。どちらも同じ事実を，リアルタイム送信の側から見るか，変更の受付の側から見るかの違いである。

採点講評（IPA）

設問2(1)では，属性名の正答率は高かったが，理由については，関係のない時間帯を記述しているなど，誤った解答が多かった。受験者が各処理と時間帯の整理を十分にできていなかったものと思われる。

本文の根拠

表2 土曜日の 0:00〜2:00 及び日曜日の 0:00〜2:00

このとき，送信データには抽出日の 0:00 時点で完了している取引までを反映することとし，送信データの抽出日時には，抽出日の日付と 0:00 をセットする。

表2 日曜日の 0:00〜21:00

国内 ATM 取引などによって，支払可能残高など送信データの属性に変更が発生した対象口座について，発生の都度，送信データを作成し，リアルタイムで D 社宛てに送信する。

〔D 社元帳の更新処理の概要〕(1)

E 銀行がバッチ処理で送信したデータについては，全データ受信後に D 社元帳を更新する。全データ受信の終了予想時刻は 2:00，D 社元帳の更新処理性能は 3,000 件／分である。

〔D 社元帳の更新処理の概要〕(2)

E 銀行がリアルタイムで送信したデータについては，受信後，即時に D 社元帳を更新する。

日曜日は 0:00〜2:00 にバッチ処理の送信データが送られ，同時に 0:00 からリアルタイムの送信も始まる。バッチ処理のデータは全データを受信してから更新するので，D 社元帳への反映は早くても 2:00 以降になる。その間に国内 ATM 取引などがあった口座は，リアルタイムのデータで先に最新の値に更新されている。

バッチ処理のデータは 0:00 時点の内容なので，後からそれで上書きすると，リアルタイムで反映した新しい支払可能残高などが古い値に戻ってしまう。そこで，リアルタイムで更新した口座には，バッチ処理で受信したデータを反映しないようにする。バッチ処理のデータには抽出日時（抽出日の日付と 0:00）がセットされているので，これと比べて判断できる。講評によれば正答率は低く，“バッチ処理の終了後にリアルタイム処理を行う”など更新タイミングを変えてしまう解答が多かった。両方の更新タイミングは前提条件で，変えられるのは D 社での更新のしかただけである。

40字で「リアルタイムで更新した口座は」と対象を限り，「バッチ処理で受信したデータで更新しない」と対応を書く。解答例は35字。

採点講評（IPA）

設問2(2)の正答率は低かった。バッチ処理と即時更新のリアルタイム処理の更新タイミングは前提条件であるにもかかわらず，“バッチ処理の終了後にリアルタイム処理を行う”など，本文中の前提条件を考慮せず更新タイミングを変更してしまう解答が多く見られた。

本文の根拠

表3 要望1

代行処理した取引は，取引発生順に送信する仕様であったが，事故カードの設定については，出金取引より先に送信することにした。

〔E 銀行の勘定系システム及び海外 ATM サービスのシステム概要〕(4)

② カードの盗難又は紛失の設定（以下，事故カードの設定という）がないこと

〔E 銀行の勘定系システム及び海外 ATM サービスのシステム概要〕(8)

この元帳反映時には，E 銀行で(4)のチェックを再度行う。

代行処理した出金取引も，E 銀行元帳に反映するときに(4)のチェックを再度受け，その②は事故カードの設定がないことである。要望1に応えて事故カードの設定を出金取引より先に送るようにすると，代行処理時間中に「出金→事故カードの設定」の順で取引があった口座では，E 銀行元帳に先に事故カードの設定が入る。その後で送られた出金取引は，実際には設定前に成立して現金も払い出されているのに，②のチェックで弾かれてしまう。

この出金取引は D 社で(4)と同じチェックを通って既に成立しているので，E 銀行元帳に反映しなければ不整合になる。そこで，代行処理した出金取引を反映する際は，事故カードの設定の有無をチェックしないようにする。事故カードの設定より後の出金は D 社のチェックで既に弾かれているので，チェックを外しても不正な出金を通すことにはならない。

口座は35字で，代行処理時間中であることと，出金と事故カードの設定の順序を書く。解答例は29字。変更内容は25字で，(4)のどのチェックを外すかを書く。解答例は「事故カードの設定の有無をチェックしない。」で20字。

本文の根拠

〔E 銀行の勘定系システム及び海外 ATM サービスのシステム概要〕(9)

キャッシュカードを保有している全口座（約 5 百万口座）のうち，3 年間で約 5％の 25 万口座が海外 ATM サービスの対象になると予測している。

表2 土曜日の 0:00〜2:00 及び日曜日の 0:00〜2:00

土曜日に全ての対象口座を抽出し，日曜日には土曜日に更新があった対象口座を抽出する。

〔D 社元帳の更新処理の概要〕(1)

全データ受信の終了予想時刻は 2:00，D 社元帳の更新処理性能は 3,000 件／分である。

土曜日のバッチ処理では全ての対象口座を抽出して D 社に送り，D 社は全データを受信してから 3,000件／分で D 社元帳を更新する。当初の予測の25万口座なら，250,000÷3,000≒83分で終わる。全口座（約5百万口座）を対象にすると，5,000,000÷3,000≒1,667分，約28時間掛かり，1日では更新が終わらない。

土曜日の更新が日曜日までに終わらなければ，日曜日のバッチ処理やリアルタイムの更新と重なり，21:00 からの代行処理に必要な D 社元帳がそろわない。表3 の対応内容の「処理時間に大幅な設計の見直しが必要」はこのことを指す。設問は「D 社元帳の更新処理の観点から」起きる問題を問うているので，対応策ではなく，更新処理時間が足りなくなることを書く。なお，講評は(2)について「E銀行システムの変更内容について問うている」と述べているが，E 銀行システムの変更内容（チェック方法の変更）を問うているのは設問3(1)であり，講評の記述は(1)と入れ違って読める。講評は原文のまま載せている。

40字で「更新処理時間が大幅に増加」と「1日では更新できない」を書く。解答例は「D社元帳の更新処理時間が大幅に増加し，1日では更新できなくなる。」で32字。

採点講評（IPA）

設問3は，商品企画部からの追加要望への対応内容について，その方法と理由を記述する問題であった。(2)は正答率が低かった。E銀行システムの変更内容について問うているが，D社システムの対応も必要な方法を記述している解答が多く，D社システムとE銀行システムの機能配置の理解が不十分だったと思われる。

本文の根拠

〔改善対象となった現行の業務及び関連する基幹システムの概要〕(1)(a)

先日付の受注は，生産計画に反映させるために，受注部門から生産管理部門に集計表が渡されている。

〔現行システムに対する改善要件〕(1)(a)

先日付の受注もシステムに登録し，未出荷分の受注に対して受注残高管理を行う。

〔現行システムに対する改善要件〕(1)(c)

受注登録されたデータは，基幹システムを構成する既存の生産管理システムに渡す。

現行では，先日付の受注は人手の台帳で管理し，生産計画に反映させるために受注部門から生産管理部門へ集計表を渡している。改善後は先日付の受注もシステムに登録し，受注登録されたデータを生産管理システムに渡す。生産管理システムと連携させて達成したいのは，現行で集計表が担っている目的，すなわち先日付の受注を生産計画へ反映させることである。

与信管理強化は改善要件の(1)(a)(b)の受注残高管理と与信限度のチェックに当たり，設問はそれ以外の目的を問うている。講評によれば正答率は低く，生産計画業務の効率化，省力化，精度向上といった抽象的な表現が散見された。本文は目的を「生産計画に反映させるために」と具体的に書いているので，それをそのまま使う。

15字なので「生産計画へ反映させること」（12字）と目的だけを書く。

採点講評（IPA）

設問1は(1)，(2)とも正答率が低かった。(1)は，生産計画業務の効率化，省力化，精度向上といった抽象的な表現が散見された。(2)は，与信限度額から更に受注残高を減算すべきことが理解できていないと思われる誤った解答が多く見られた。

本文の根拠

〔改善対象となった現行の業務及び関連する基幹システムの概要〕(1)(b)

①今回受注登録額≦与信限度額−前月末売掛金残高−当月売上額＋当月入金額

〔現行システムに対する改善要件〕(1)(a)

受注残高は，得意先ごとに，前回までに入力された受注のうち未出荷分の受注金額合計として算出する。

〔現行システムに対する改善要件〕(1)(b)

今回受注した，先日付の受注も含む金額を，今回受注登録額として，前回までに入力された先日付の受注も加味した与信限度のチェックを行う。

下線①の右辺は，与信限度額から，まだ入金されていない売掛金（前月末売掛金残高＋当月売上額−当月入金額）を差し引いた，今回使える与信の残りである。現行では翌日出荷分だけを受注登録し，出荷すれば売上になるので，これで足りていた。

改善後は先日付の受注も登録するので，前回までに入力されたがまだ出荷していない受注がある。これはまだ売上にも売掛金にもなっていないが，いずれ出荷されて売掛金になる金額で，与信を既に使っているとみなさなければならない。改善要件は，これを受注残高（前回までの受注のうち未出荷分の受注金額合計）として管理し，「前回までに入力された先日付の受注も加味した」チェックを行うとしている。したがって右辺から受注残高を更に減算する。講評によれば正答率は低く，受注残高を減算すべきことが理解できていない解答が多かった。

15字なので，何を（受注残高）どうする（減算する）だけを書く。解答例は「受注残高分を減算する。」で11字。

採点講評（IPA）

設問1は(1)，(2)とも正答率が低かった。(1)は，生産計画業務の効率化，省力化，精度向上といった抽象的な表現が散見された。(2)は，与信限度額から更に受注残高を減算すべきことが理解できていないと思われる誤った解答が多く見られた。

本文の根拠

〔改善対象となった現行の業務及び関連する基幹システムの概要〕(4)(b)

原材料の在庫は，原材料倉庫での入出庫実績を登録することによってシステムで管理している。製造現場に未使用分の原材料が残ることがあり，それは人手で台帳管理している。

〔現行システムに対する改善要件〕(4)(c)

製造現場では，原材料の使用実績と未使用残実績を登録する。

〔現行システムに対する改善要件〕(4)(d)

原材料在庫は，在庫場所ごとに原材料ロット別にシステムで管理する。

現行のシステムが管理している原材料在庫は，原材料倉庫の入出庫実績に基づくものだけで，製造現場に残った未使用分の原材料は人手の台帳で管理している。改善後は製造現場で原材料の使用実績と未使用残実績を登録し，原材料在庫を在庫場所ごとにシステムで管理する。

したがって新たにシステムの管理対象になるのは，製造現場（場所）に残った未使用の原材料在庫（在庫）である。原材料倉庫から払い出された原材料は，使われなければ製造現場に在庫として残るので，これを管理しなければ原材料ロット別の在庫が合わない。講評によれば正答率は高かった。

20字で「どの場所の」（製造現場）と「どのような在庫」（未使用で残った原材料在庫）の両方を書く。解答例は「製造現場に未使用で残った原材料在庫」で17字。

採点講評（IPA）

設問2では，(1)の正答率が高く，(2)は低かった。(2)では，原材料倉庫に加え，製造現場も原材料在庫の管理場所になることから，両者を総称した解答を求めていたが，単に“製造現場コード”と解答したものが多かった。

本文の根拠

〔現行システムに対する改善要件〕(4)(d)

原材料在庫は，在庫場所ごとに原材料ロット別にシステムで管理する。

表1 原材料ロット別在庫マスタ

原材料コード（主キー），原材料ロット番号（主キー），実在庫数量，引当可能在庫数量，原材料賞味期限

〔改善対象となった現行の業務及び関連する基幹システムの概要〕(4)(a)

原材料は，購買先からの納品・検品の後，工場内に 1 か所ある原材料倉庫に入庫され，製造現場からの払出し要求によって出庫される。

設計中の原材料ロット別在庫マスタの主キーは原材料コードと原材料ロット番号だけで，どこにある在庫かを区別できない。改善後は，同じ原材料ロットの一部が原材料倉庫に残り，残りが製造現場に未使用で残るということが起きる。在庫場所ごとに管理するには，キーに在庫場所を加える必要がある。

在庫場所は原材料倉庫と製造現場の二つになるので，属性はその両方を表せる名前にする。講評は，単に“製造現場コード”と解答したものが多かったとしている。製造現場コードでは原材料倉庫の在庫を表せない。両者を総称した名前が求められている。

字数制限はない。解答例は「在庫場所コード」。本文の「在庫場所ごとに」の語を使い，コードの形で書く。

採点講評（IPA）

設問2では，(1)の正答率が高く，(2)は低かった。(2)では，原材料倉庫に加え，製造現場も原材料在庫の管理場所になることから，両者を総称した解答を求めていたが，単に“製造現場コード”と解答したものが多かった。

本文の根拠

〔現行システムに対する改善要件〕(2)(b)

受注数量に満たなくても，在庫がある分だけでも出荷できるような出荷指示を行う。

図1

Yes なら“・X を出荷指示数量とし，出荷指示レコードを作成し，出荷指示ファイルに出力する ・製品ロット別在庫マスタのレコードの引当可能在庫数量から X を減算し，製品ロット別在庫マスタを更新する ・受注レコードの未引当受注数量を 0 とし，受注ファイルを更新する”を行い

図1

No なら“・b（空欄）を出荷指示数量とし，出荷指示レコードを作成し，出荷指示ファイルに出力する ・X ←（X − 製品ロット別在庫マスタのレコードの引当可能在庫数量） ・製品ロット別在庫マスタのレコードの引当可能在庫数量を 0 とし，製品ロット別在庫マスタを更新する”を行い

図1 注1）

X は，未引当受注数量のワークエリアを示す。

aの Yes 側は，未引当の受注数量 X をそのまま出荷指示数量にし，製品ロットの引当可能在庫数量から X を減算して，受注の引当てを終える。これができるのは，その製品ロットの引当可能在庫数量が X 以上のときである。よってaは「X≦製品ロット別在庫マスタのレコードの引当可能在庫数量」。

No 側は，その製品ロットの在庫では足りない場合で，改善要件(2)(b)のとおり在庫がある分だけ出荷指示を出す。処理は X から引当可能在庫数量を引き，引当可能在庫数量を 0 にしているので，出荷指示数量bはその製品ロットの引当可能在庫数量全部である。残った X は次の製品ロット（賞味期限が次に新しいもの）で引き当て，製品ロットがなくなれば欠品リストに出す。講評によれば正答率は高かったが，a では“≦”とすべきところを“＜”と書いた解答が散見された。X と引当可能在庫数量が等しいときも全量を引き当てられるので，Yes 側に入れなければならない。“＜”にすると，等しいときに No 側に進んでしまい，引当てが済んでいるのに次の製品ロットを読みにいくことになる。

どちらも30字以内。図の中の語をそのまま使い，「製品ロット別在庫マスタのレコードの引当可能在庫数量」と書く。解答例は a が27字，b が25字。

採点講評（IPA）

設問3は，a，bとも正答率が高かった。aでは“≦”と記述すべきところを，“＜”と記述した解答が散見された。

本文の根拠

〔ロット追跡〕(1)

出荷実績から，ある製品ロットについて，その製品に使用した原材料ロットの全ての購買先を抽出する手順

〔ロット追跡〕(2)

ある原材料ロット番号について，その原材料を使用した製品を出荷した全ての得意先を抽出する手順

表1 原材料受入実績

発注番号（主キー），購買先コード，原材料コード，原材料ロット番号，原材料賞味期限，入荷実績数量，入荷実績日

表1 出荷実績

出荷指示番号（主キー），得意先コード，製品コード，製品ロット番号，出荷数量，賞味期限，出荷実績日，受注番号

(1)は製品ロットから購買先へたどる。手順2で原材料使用実績から使用した原材料ロット番号が分かったので，次は原材料ロット番号から購買先を引く。表1 で原材料ロット番号と購買先コードを両方持つのは原材料受入実績である。よってcは，原材料受入実績から手順2で抽出した原材料ロット番号に対応する購買先コードを抽出する手順になる。

(2)は逆向きに原材料ロットから得意先へたどる。手順1で原材料使用実績からその原材料ロットを使った製品ロット番号が分かったので，次は製品ロット番号から得意先を引く。製品ロット番号と得意先コードを両方持つのは出荷実績（出荷指示にもあるが，実際に出荷したのは出荷実績）である。よってdは，出荷実績から手順1で抽出した製品ロット番号に対応する得意先コードを抽出する手順になる。講評によれば c，d とも正答率は高かった。

それぞれ45字以内。設問の指定どおり表1 のファイル名と属性名を使い，「どのファイルから」「どの手順の結果をキーに」「何を抽出するか」を書く。解答例は c が40字，d が36字。

採点講評（IPA）

設問4は，c，dとも正答率が高かった。ロット追跡の手順については，よく理解されているようだった。

本文の根拠

〔車いすシステムの概要〕(3) 監視センタ

監視センタは，電動車いすが行き先に到着して施設の職員が利用者を降ろした後，その電動車いすを次の利用者の出発場所又は駐機場所へ向かわせる。

〔車いすシステムの概要〕(1) 車いすシステム

車いすシステムは，電動車いす，監視センタ，位置の検知・通信のための無線 LAN 設備，入力用のタブレット端末などで構成する。

〔車いすシステムの概要〕(3) 監視センタ

監視センタは，全ての電動車いすの走行を監視・制御しており，電動車いす同士が接触して事故が起きないように走行を制御したり，渋滞が発生しないように走行を制限したりする。

表2 障害物検知用のカメラ

制御部で画像データを処理し，前方にある障害物の位置と形状を検知する。

a：車いすシステムの狙いは，職員が要介護者の移動に常時付き添う必要をなくすことである。ただし本文では，行き先に到着すると施設の職員が利用者を降ろしており，乗るときも職員が出発場所で利用要求を入力して待っている。付添いが要るのは乗り降りのときだけなので，a は「乗降」。

b：無線 LAN 設備は「位置の検知・通信のため」のもので，表1 の電動車いすの誘導も無線 LAN アクセスポイントで電動車いすの位置を検知する技術を使う。b は「位置検知」。c：全ての電動車いすの走行を監視・制御し，電動車いす同士が接触しないように制御するのは監視センタである。d：表2 の障害物検知用のカメラの欄に，制御部が前方にある障害物の位置と形状を検知し，電動車いすを停止させるとある。d は「障害物」。

字数制限はないが，空欄の前後の語とつながる本文の用語を入れる。解答例は a「乗降」，b「位置検知」，c「監視センタ」，d「障害物」。

本文の根拠

表2 障害物検知用のカメラ

電動車いすの前面左右に取り付けられた 2 台のカメラからの画像データを，制御部に渡す。制御部で画像データを処理し，前方にある障害物の位置と形状を検知する。

〔車いすシステムの概要〕(2) 電動車いすの仕組み・走行

電動車いすは，前方の障害物を監視しながら走行ルートを走行し，障害物を検知した場合は，走行を停止する。

前進時の安全性は，前面左右に取り付けたカメラで前方の障害物を検知し，検知したら停止することで確保している。今のカメラは前方しか写さないので，後退するときには進行方向（後方）の障害物を検知できない。

前進時と同等の安全性を確保するには，後方を写すカメラを取り付け，前方と同じように後方の障害物を検知できるようにする必要がある。制御部は既にカメラ画像処理を行っているので，追加するのは後退走行用のカメラという装置と，後方の障害物検知という機能である。

字数制限はない。装置と機能を分けて，装置は「後退走行用カメラ」，機能は「後方の障害物検知」のように，前進時の仕組みと対応させて書く。

本文の根拠

〔電動車いすの利用方法〕

行き先ボタンを押した場合，監視センタは他の電動車いすの走行状態，他の利用要求などから行き先変更に問題がないことを確認できたら，変更後の走行パラメタを送信する。

〔車いすシステムの概要〕(3) 監視センタ

監視センタに利用要求があったときに，利用可能な電動車いすがあれば，監視センタが出発場所に向けて走行を開始させる。

監視センタは，行き先変更の要求を受けると，他の電動車いすの走行状態と他の利用要求などから，変更に問題がないかを確認している。問題があれば変更できない。変更できないのは，この二つに影響が生じる場合である。

一つは，変更後の走行ルートが他の電動車いすの走行とぶつかり，接触や渋滞が起きる場合である。監視センタは電動車いす同士の接触や渋滞を防ぐように走行を制御している。もう一つは，その電動車いすが到着後に次の利用者の出発場所へ向かう予定になっているなど，他の利用要求の処理に影響する場合である。講評は，本文中に記述した二つを期待したが，“他の利用要求”について記述していない解答が散見されたとしている。本文の「他の電動車いすの走行状態，他の利用要求など」の二つをそのまま使う。

それぞれ25字以内で「…に影響が生じる場合」と書く。解答例は19字と15字。二つの欄の順は問われていない。

採点講評（IPA）

設問2(2)は，本文中に記述した二つを解答に期待したが，その一つである“他の利用要求”について記述していない解答が散見された。題意を十分理解してもらいたい。

本文の根拠

表1 電動車いすの誘導

この技術では，1 秒間に数十台の無線 LAN 端末の位置を検知できる。監視センタは，電動車いすの位置を検知し，行き先までの走行ルートを探索し，走行パラメタを電動車いすに送信する。

〔車いすシステムの構成〕

常に複数の無線 LAN アクセスポイントが電動車いすと通信可能となるように，無線 LAN アクセスポイントを，各施設のレイアウトに合わせて設置する。

表3 RF タグ方式

位置検知ポイントの床などに RF タグを貼り，電動車いすに設置されたタグリーダでデータを読み出して位置を検知する。

RF タグ方式とカメラ方式は，走行ルート上の位置検知ポイントに来たときにしか位置が分からない。これに対して無線 LAN 方式は，常に複数の無線 LAN アクセスポイントが電動車いすと通信できるように設置されているので，施設内のどこにいても電動車いすの位置を検知できる。1秒間に数十台の位置を検知できるので，全ての電動車いすの位置を常時把握できる。

監視センタは全ての電動車いすの位置を監視して接触を防ぎ，走行ルートを探索するので，位置検知ポイントの間でも位置が分かることが必要になる。開発目標の「全ての電動車いすの位置を把握できるようにする」にも対応する。

20字で「常に」位置が分かることを書く。解答例は「常に電動車いすの位置が分かる。」で15字。

本文の根拠

表3 無線 LAN 方式

誤差は 3m 程度である。

〔車いすシステムに用いる位置検知方式の検討〕

二つの方式を組み合わせることにしたのは，無線 LAN 方式だけでは，走行ルートから外れることが考えられたからである。

無線 LAN 方式の誤差は3m程度で，施設内の通路を走る電動車いすを正確に誘導するには大きすぎる。本文も，無線 LAN 方式だけでは走行ルートから外れることが考えられたので二つの方式を組み合わせたとしている。

併用する RF タグ方式（読取り範囲30cm以内）やカメラ方式（認識範囲1m以内）は，位置検知ポイントでしか使えないが，位置の精度は無線 LAN 方式よりずっと高い。常に位置が分かるが誤差が大きい方式と，ポイントでしか分からないが正確な方式を組み合わせて，互いの弱点を補っている。

25字で，無線 LAN 方式の欠点（位置検知の誤差が大きい）を理由として書く。解答例は「無線LAN方式は位置検知の誤差が大きいから」で21字。

本文の根拠

表3 RF タグ方式

1 台のタグリーダの読取り範囲は 30cm 以内である。

〔車いすシステムに用いる位置検知方式の検討〕

そこで位置検知ポイントとして走行ルート上に設置された，無線通信方式による IC タグ（以下，RF タグという）又はマーカの位置を電動車いすが検知し，走行ルートからのずれを修正しながら走行できるようにする。

RF タグは走行ルート上の位置検知ポイントに貼ってあり，電動車いすはそれを読んで走行ルートからのずれを修正する。タグリーダ1台では，読取り範囲30cm以内に RF タグがあるかどうかしか分からず，電動車いすが走行ルートの左右どちらにずれているかは分からない。

中央と左右に合計3台置けば，どのタグリーダが RF タグを読んだかで，走行ルートに対して電動車いすが左右どちらにずれているかが分かる。ずれの向きが分かれば，逆向きに修正する走行制御ができる。講評は，“車体の幅をカバーするためにタグリーダを3台設置した”との解答が散見されたとしている。読み取れる範囲を広げるだけでは，本文にある“ずれを修正しながら走行”するための情報にならない。問われているのは，ずれの向きを知る方法である。

40字で「左右のずれが分かる」と「走行制御が可能」をつなげる。解答例は「走行ルートに対する電動車いすの左右のずれが分かり，走行制御が可能となる。」で36字。

採点講評（IPA）

設問3(2)は，“車体の幅をカバーするためにタグリーダを3台設置した”との解答が散見された。本文にある“ずれを修正しながら走行”するために，どのような方法が求められているかが問われていることを理解してほしい。

本文の根拠

〔車いすシステムの構成〕

常に複数の無線 LAN アクセスポイントが電動車いすと通信可能となるように，無線 LAN アクセスポイントを，各施設のレイアウトに合わせて設置する。

〔車いすシステムの概要〕(2) 電動車いすの仕組み・走行

電動車いすは待機時，施設内に設けられた駐機場所に置かれている。

〔車いすシステムを提案するための見積りツールの検討〕

施設から車いすシステム導入の要望が寄せられたときに，その施設の規模と状況に応じて適切なシステム提案を行えるように，見積りツールを準備する。

e：無線 LAN アクセスポイントは各施設のレイアウトに合わせて設置し，走行ルートも施設の通路で決まる。施設ごとに違い，見積りに入力しなければならないのは施設のレイアウトである。f：電動車いすは待機時に施設内の駐機場所に置かれるので，必要配備台数が決まれば，その台数を置くための駐機場所の位置と広さが求まる。g：無線 LAN アクセスポイントは，常に複数が電動車いすと通信できるようにレイアウトに合わせて設置するので，見積りツールは施設のレイアウトから設置位置を求める。

見積りツールは施設の規模と状況に応じた提案のためのもので，入力は1時間当たりの最大利用者数と施設のレイアウト，出力は配備台数，駐機場所，アクセスポイントの設置位置という組になっている。

字数制限はない。本文の用語をそのまま使い，e「レイアウト」，f「駐機場所」，g「設置位置」と答える。

本文の根拠

表2 電源

充電可能な電池を用いて，電動車いすの制御及び駆動に必要な電力を供給する。電池残量は制御部で読み取ることができる。監視センタからの指示で急速充電器に接続し，充電を行う。

〔車いすシステムの構成〕

電動車いすのバッテリを充電する急速充電器及び監視カメラを設置する。

設問の条件では，充電は電動車いすを使わない夜間に行い，利用開始時刻までに全ての電動車いすの充電を終える。充電できる時間帯はあらかじめ与えられ，充電する電動車いすの台数は見積りツールが求める必要配備台数である。あと1台の充電に何時間掛かるかが分かれば，1台の急速充電器が時間帯の中で何台充電できるかが決まり，必要な急速充電器の台数が求まる。

不足しているのは1台当たりの充電所要時間である。講評は，“バッテリ残量”などの解答が散見されたとしている。バッテリ容量は1日の走行に十分とされており，残量は制御部で読み取れる運用中の値で，見積りの入力にはならない。ある項目を入力すれば台数が求まるという設問の要件に照らし，不足している事項だけを答える。

20字以内。解答例は「1台当たりの充電所要時間」で12字。

採点講評（IPA）

設問4(2)は，“バッテリ残量”などの解答が散見された。ある項目を見積りツールに入力すれば急速充電器の台数が求まることから，設問の要件に不足している事項を解答すればよいはずである。