平成24年度 秋期 午後Ⅰ

本文の根拠

〔現在のシステム化の状況とその関連する業務〕(2)

受領実績登録後に，受領書が出荷部門から経理部門に回付され，売上及び売掛金に計上される。

〔会計システム再構築の背景〕(2)

① A 社の売上計上基準を納品基準から出荷基準へ変更する。

現在は納品基準なので，納品後の受領実績登録を済ませた後に，受領書を出荷部門から経理部門に回付し，それを基に売上と売掛金を計上している。受領書の回付は，納品が済んだことを経理部門に伝えるための人手の業務である。

売上計上基準が出荷基準に変わると，売上は出荷の時点で計上するので，経理部門は納品が済んだことを受領書で確かめる必要がなくなる。したがって，出荷部門で人手で行っていた「受領実績登録後，受領書を経理部門に回付する業務」が不要になる。受領実績登録そのものは販売管理システムの処理なので，「人手で行っていた業務」には当たらない。

25字で，いつ（受領実績登録後）・何を（受領書を）・どこへ（経理部門に回付する）の三つを入れる。解答例は「受領実績登録後，受領書を経理部門に回付する業務」で23字。

採点講評（IPA）

設問1では，(1)の正答率が高かった。(2)は，渡された情報で行うべき処理について，売上と売掛金への仕訳計上処理が必要であることに対し，どちらか一方のみの解答が散見された。仕訳は分からなくとも，本問での出荷という行為が，会計上は売上と売掛金という二面性をもつことを理解してほしい。

本文の根拠

表1 データ収集関連

回付されてきた受領書，検収伝票，給与関連帳票を基に，仕訳伝票を起票して入力することの負荷が大きい。会計システムで仕訳処理を行いたい。

〔会計システム再構築の方針〕(2)

① 各システムから新会計システムへ渡す情報は，伝票ではなくデータで渡すことにする。

〔現在のシステム化の状況とその関連する業務〕(2)

出荷・売上処理では，出荷伝票の発行，出荷実績の登録，受注の消込み，在庫の引落し及び納品後の受領実績登録が行われる。

出荷基準に変わると，売上は出荷の時点で計上する。販売管理システムでは出荷・売上処理の中で出荷実績を登録しているので，受領書の代わりに，この出荷実績情報をデータで新会計システムに渡せばよい。

新会計システム側では，受け取った出荷実績情報から仕訳を自動で起こす。現在，受領書に基づいて「売上及び売掛金に計上」しているとおり，出荷という取引は会計上は売上と売掛金の両方に計上される。講評も，売上と売掛金のどちらか一方だけの解答が散見されたとし，出荷が会計上は売上と売掛金という二面性をもつことを理解してほしいとしている。

情報は10字なので「出荷実績情報」（6字）と名詞で答える。処理は20字で「売上及び売掛金」の両方と「自動仕訳処理」を入れる。解答例は「売上及び売掛金計上の自動仕訳処理」で16字。

採点講評（IPA）

設問1では，(1)の正答率が高かった。(2)は，渡された情報で行うべき処理について，売上と売掛金への仕訳計上処理が必要であることに対し，どちらか一方のみの解答が散見された。仕訳は分からなくとも，本問での出荷という行為が，会計上は売上と売掛金という二面性をもつことを理解してほしい。

本文の根拠

表1 資金管理関連

入金予定は，売掛金だけでなく，受注時点での入金予定情報も把握したい。

〔会計システム再構築の背景〕(3)

資金収支の実績だけでなく，将来の資金収支予定を正確に把握することが重要になっている。

経理部門は入金予定について，売掛金だけでなく受注時点での入金予定情報も把握したいとしている。受注は販売管理システムの受注処理で登録され，売掛金は新会計システムの売掛金管理サブシステムで管理される。したがって，販売管理システムからは受注時点での入金予定情報を，売掛金管理サブシステムからは売掛金の入金予定情報を取り込む。

図2 でも，販売管理システムと売掛金管理サブシステムからの線が合流して資金管理サブシステムに入っている。講評は，入金予定を出金予定と取り違えた解答が散見されたとしている。買掛金や発注時点の支払予定は出金予定であり，ここで問われているのは入金予定である。

それぞれ15字で，「いつの時点の」「何の」入金予定情報かが分かるように書く。解答例は「受注時点での入金予定情報」（12字）と「売掛金の入金予定情報」（10字）。

採点講評（IPA）

設問2では，資金管理について問うたが，(1)は入金予定を出金予定と取り違えた解答が散見された。(2)，(3)は正答率が高かった。

本文の根拠

〔現在のシステム化の状況とその関連する業務〕(4)

また，給与，賞与，法定福利費などの人件費の見込情報も人事給与システムで計算している。

人事給与システムは，人件費の実績のほかに，給与，賞与，法定福利費などの人件費の見込情報も計算している。人件費は将来支払う出金なので，この見込情報を取り込めば，資金管理サブシステムで出金予定として把握できる。

人件費の実績は給与関連帳票として一般会計に計上されるもので，すでに発生した支出である。出金「予定」に当たるのは見込情報のほうである。図2 でも，人事給与システムからの矢印は経費管理サブシステムに入り，経費管理サブシステムから資金管理サブシステムへ矢印が出ている。

25字で，本文の「給与，賞与，法定福利費などの人件費の見込情報」をそのまま使う。解答例もこの22字。

採点講評（IPA）

設問2では，資金管理について問うたが，(1)は入金予定を出金予定と取り違えた解答が散見された。(2)，(3)は正答率が高かった。

本文の根拠

〔現在のシステム化の状況とその関連する業務〕(1)

出力帳票として，一般会計処理では，仕訳帳，総勘定元帳，試算表，貸借対照表及び損益計算書があり，支払手形処理では，支払手形及び支払手形管理資料がある。

〔会計システム再構築の背景〕(2)

② 買掛金の支払は，全て銀行振込による支払へ変更する。

現行の会計システムでは，一般会計処理と支払手形処理が稼働しており，支払手形処理は支払手形と支払手形管理資料を出力している。仕入管理システムの説明にあるとおり，買掛金の支払の一部を手形で行っているためである。

取引方法の変更によって，買掛金の支払は全て銀行振込になる。手形で支払うことがなくなるので，支払手形の発行や，その期日などを管理する機能は新会計システムでは要らなくなる。資金収支の管理の観点では，支払手形の期日が出金予定になるが，手形そのものがなくなるので管理の対象もなくなる。

15字なので「支払手形管理の機能」（9字）のように機能名で答える。

採点講評（IPA）

設問2では，資金管理について問うたが，(1)は入金予定を出金予定と取り違えた解答が散見された。(2)，(3)は正答率が高かった。

本文の根拠

表1 データ収集関連

連結子会社の決算情報において，各連結子会社の勘定科目が A 社と統一されておらず，連結情報の合算に手間が掛かる。

表1 連結決算関連

連結子会社はそれぞれ独自の会計システムを導入しているが，それらのシステムを変更することなく，連結決算処理のシステム化を図りたい。

連結子会社の決算情報を合算する手間が掛かるのは，各連結子会社の勘定科目が A 社と統一されていないからである。一方で，連結子会社の会計システムは変更しないという要望もあるので，子会社側で勘定科目をそろえることはできない。

そこで，連結会計サブシステムの側で，受け取った連結子会社の勘定科目を，合算できる勘定科目に変換する機能を実装する。講評も，各連結子会社の勘定科目が A 社と統一されていないことが読み取れれば解答できる設問だったとしている。

30字で「連結子会社の勘定科目を」「連結可能な勘定科目に」「変換する機能」を入れる。解答例は「連結子会社の勘定科目を連結可能な勘定科目に変換する機能」で27字。

採点講評（IPA）

設問3は，正答率が高かった。連結子会社の決算情報を合算するとき，各連結子会社の勘定科目がA社と統一されていないということが読み取れれば解答できる設問であった。

本文の根拠

〔内部統制面からの検討〕

完全性とは，記録した取引に漏れ，重複がないことをいい

〔内部統制面からの検討〕

入力情報については，“入力情報の完全性，正確性，正当性などを確保する統制”が挙げられている。

〔現在のシステム化の状況とその関連する業務〕(3)

入荷・検収処理では，入荷した時の受取登録，検品後の検品実績登録，検収伝票発行及び在庫計上が行われる。

〔現在のシステム化の状況とその関連する業務〕(3)

在庫管理処理では，販売と仕入に伴う入出庫の処理，月次の棚卸処理及び在庫管理資料の作成が行われている。

本文は，完全性を「記録した取引に漏れ，重複がないこと」と定義している。入力情報の完全性を確保するには，取引が漏れも重複もなく入力されていることを確かめる必要がある。

新会計システムと仕入管理システムの関連では，仕入管理システムで検収や棚卸しなどの取引情報が入力され，それが新会計システムへデータで渡される。したがって，取引情報が漏れ・重複なく入力されていることに加えて，新会計システムへの連携でも漏れ・重複がないことを確認する。講評も，取引の入力と会計システムへの連携において漏れ及び重複がないことが入力情報の完全性であると読み取ってほしかったとしている。

40字で「何の取引か（検収，棚卸しなど）」「漏れ・重複なく入力され」「新会計システムに連携されること」の三つを入れる。解答例はちょうど40字。

採点講評（IPA）

設問4は，正答率が低かった。内部統制実施基準の，ITに係る業務処理統制について，入力情報の完全性，正確性，正当性を確保することの中で，入力情報の完全性の確保について問うたが，取引の入力と会計システムへの連携において漏れ及び重複がないことが入力情報の完全性である，ということを読み取ってほしかった。

本文の根拠

〔汎用化システムへの要望や制約〕(1)

ショップの特色を出したいので，独自の商品を開発して販売するなどの工夫を行えるようにしたい。

表1 電子商店街案

③ フォトブック，カレンダなどの独自の商品，特色ある Web ページなど，各ショップの創意工夫を生かせる。

表1 B 社単独通販サイト案

④ B 社主導の商品展開になりやすい。

ショップからの要望の(1)は，ショップの特色を出すために独自の商品を開発して販売するなどの工夫を行えるようにしたい，というものである。表1 の電子商店街案の③は，独自の商品や特色ある Web ページなど，各ショップの創意工夫を生かせるとしており，この要望に合う。

B 社単独通販サイト案は，B 社注文システムの修正が少なく管理が容易という利点はあるが，B 社主導の商品展開になりやすく，各ショップが独自の商品を出す余地が小さい。C マネージャは〔汎用化システムへの要望や制約〕を踏まえて運営形態を検討しており，ショップの工夫を生かせるかどうかが決め手になる。

20字なので「各ショップの創意工夫が生かせるから」（17字）のように，表1 の言葉を使って理由の形で結ぶ。「各ショップの特色が出せるから」（14字）も解答例に挙がっている。

本文の根拠

表2 SaaS 案

④ B 社が，各ショップの運営状況などを把握しやすく，一括した管理が可能である。

〔汎用化システムへの要望や制約〕(2)

システムやサイト全体の運営，管理は，B 社が行ってほしい。

〔汎用化システムへの要望や制約〕(5)

システムの開発，改造や Web ページの作成を独自に実施できないショップがある。

表2 ソフトウェアパッケージ案

② サーバやデータベースは各ショップが個別に保有し，運用する。

B 社のメリットは，表2 の SaaS 案④のとおり，各ショップの運営状況などを把握しやすく一括した管理ができることである。サーバやデータベースを全 Web 店舗で共有し運用も全ショップ共通なので，B 社はサイトの運営，管理とショップの管理をまとめて行える。これはショップからの要望(2)(3)（サイト全体の運営，管理は B 社が行う，運営のアドバイスや情報提供をしてほしい）にも応えるものである。

各ショップのメリットは，システムを自分で持たずに済むことである。ソフトウェアパッケージ案ではサーバやデータベースを各ショップが個別に保有・運用し，カスタマイズも各ショップが行う。要望(5)のとおり，システムの開発や改造を独自に実施できないショップがあるので，SaaS として提供を受ければ，システムの導入，開発及び運用をショップで行わなくてよい。

それぞれ30字で，誰にとって何が楽になるかを「〜から」で結ぶ。解答例は B 社が「サイトの運営，管理やショップの管理を一括して行えるから」で27字，各ショップが「ショップでシステムの導入，開発及び運用をしないで済むから」で28字。

本文の根拠

〔汎用化システムの開発方針〕(2)

Web 店舗ごとに異なる可能性がある選択肢は，汎用化システムでは全て選択できるように開発し，Web 店舗ごとに表示できる選択肢を選べるようにする。

表2 SaaS 案

③ 要求機能のうち，ショップごとに違う部分は，個々の Web 店舗の設定を変えることで実現する。

〔汎用化システムの利用イメージ〕(3)

プリント種別，対応できる受取方法，支払方法は Web 店舗ごとに異なる。

SaaS 案では，システムを全ショップで共有するので，ショップごとにプログラムを作り分けることはできない。表2 の SaaS 案③のとおり，ショップごとに違う部分は個々の Web 店舗の設定を変えることで実現する。選択肢を全て選べるように開発しておき，Web 店舗ごとに表示する選択肢を選べるようにすれば，各 Web 店舗の違いを設定の変更だけで吸収できる。

本文では，プリント種別，対応できる受取方法，支払方法が Web 店舗ごとに異なるとしている。これらを設定で切り替えられれば，Web 店舗ごとの要望に改造なしで対応できる。講評は，“各ショップの創意工夫を出すため”など開発方針とは異なる視点の解答があったとし，汎用化の観点で読み取ってほしいとしている。創意工夫は運営形態を選んだ理由（設問1(1)）で，ここで問われているのは汎用化の開発方針である。

35字で「Web 店舗ごとの要望に」「設定変更で対応できるように」を入れる。解答例は「Web店舗ごとの要望に設定変更で対応できるようにしたいから」で29字。

採点講評（IPA）

設問2では，開発方針として汎用化の基本的な留意点を問うたが，“各ショップの創意工夫を出すため”など，開発方針とは異なる視点の解答があった。汎用化の観点で問題文から読み取ってほしい。

本文の根拠

〔汎用化システムへの要望や制約〕(8)

ショップでは，メールの受信を数分以内に知ることはできるが，Web ページを毎日確実に確認することは難しい。

〔汎用化システムへの要望や制約〕(7)

ショップでは，ブラウザを用いて大きなサイズのデータを受け取ることはできるが，メールで受信できるデータのサイズには制限がある。

〔汎用化システムの開発方針〕(3)

B 社からショップに顧客データ，写真データを受け渡す“データ受渡し”

“注文伝達”は，注文があったことを B 社からショップに伝える機能である。要望や制約の(8)のとおり，ショップはメールの受信を数分以内に知ることはできるが，Web ページを毎日確実に確認することは難しい。メールで実装すれば，注文を速やかにショップへ通知できる。講評は，“メールを素早く受信できるから”という解答が多かったが，業務上素早く知りたいのは注文であることを意識してほしいとしている。

“データ受渡し”は，顧客データと写真データを受け渡す機能である。写真データはサイズが大きく，(7)のとおり，メールで受信できるデータのサイズには制限があるが，ブラウザを用いれば大きなサイズのデータを受け取ることができる。

それぞれ20字で，業務上の効果を主語にして書く。解答例は「注文を速やかに通知できるから」（14字）と「大きなサイズのデータを受け取れるから」（18字）。

採点講評（IPA）

設問3(1)では，メールでの実装について，“メールを素早く受信できるから”との解答が多かったが，業務上素早く知りたいのは注文であることを意識してほしい。

本文の根拠

〔汎用化システムの利用イメージ〕(7)

また，B 社は，顧客ごとの完了した取引回数に応じて優遇を行ったり

〔汎用化システムへの要望や制約〕(4)

顧客ごとの完了した取引回数などに応じた優遇を B 社で行ってほしい。

〔汎用化システムの利用イメージ〕(6)

ショップは，写真の受渡しと決済の確認後，B 社に取引の完了登録を行う。

B 社は，顧客ごとの完了した取引回数に応じて優遇を行う。ショップからもそうしてほしいという要望が出ている。ところが，受渡しや決済はショップが行い，入金管理もショップの責任で行うので，取引が完了したかどうかは B 社からは分からない。ショップが写真の受渡しと決済を確認した後に“取引完了登録”を行えば，B 社は顧客ごとの完了した取引回数を数えられ，優遇に使える。

講評は，“写真データ削除のタイミングを知るため”など，問題文に記載していないシステム上の都合を想像した誤った解答が多かったとしている。理由は本文に書かれている B 社の業務（顧客ごとの完了した取引回数に応じた優遇）から探す。

30字で「顧客ごとの完了した取引回数に応じた優遇」を入れ，「行うから」で結ぶ。解答例は「顧客ごとの完了した取引回数に応じた優遇を行うから」で24字。

採点講評（IPA）

設問3(2)では，追加する機能が必要な理由を問うたが，“写真データ削除のタイミングを知るため”など，問題文に記載していないシステム上の都合を想像して解答したと思われる誤った解答が多かった。

本文の根拠

〔現状と課題〕

申込者は申込時に 1〜5 個のセッションを予約するが，同一時限に開催されるセッションを複数予約することはできない。

〔新システムの設計〕

“受講セッション”の主キーについては，セミナ番号，申込 ID，セッション ID を設定する方法と，セミナ番号，申込 ID，選択したセッションの時限を設定する方法が考えられたが，業務プログラムの作成負荷を軽減するために，後者を選択した。

申込者は同一時限に開催されるセッションを複数予約できない。主キーを（セミナ番号，申込 ID，時限）にすると，一つの申込みで同じ時限の“受講セッション”を二つ登録しようとすれば主キーが重複するので，データベースの一意制約で登録が拒否される。“受講申込”に対して同一時限の“受講セッション”が一つしか作れなくなる。

主キーを（セミナ番号，申込 ID，セッション ID）にした場合は，同じ時限の別のセッションでも主キーは重複しない。そのため，同一時限の予約が既にないかを業務プログラムで調べる処理が必要になる。時限を主キーに入れれば，このチェックをプログラムで書かずに済むので，作成負荷が軽減できる。

40字で「同一時限の複数セッションのチェック」と「データベースの一意制約で実現」を結ぶ。解答例は「同一時限の複数セッションのチェックをデータベースの一意制約で実現できるから」で37字。「“受講申込”に対して同一時限の“受講セッション”が一つしか作れなくなるから」（37字）も解答例にある。

採点講評（IPA）

設問1(1)，(2)は，E-R図を用いてエンティティタイプの設計に関して出題したが，正答率は低かった。特に，リレーションシップについては，システムの要件をしっかり理解しなければ正答を導くことができないことを十分に理解してほしい。

本文の根拠

〔現状と課題〕

また，顧客以外の受講希望者の参加申込みも受け付けている。

表1 申込み

なお，1 回のセミナに同一顧客が複数回申し込むことはできない。

〔現状と課題〕

1 回のセミナでは，20〜30 個のセッションが開催され，申込者は申込時に 1〜5 個のセッションを予約する

表1 顧客招待

事務局はこれに基づいて，“顧客招待”に顧客を登録する。

5か所を順に見る。顧客と顧客招待は1対多で，顧客招待は必ず顧客を指すが，招待されない顧客もいるので“顧客”（●）→“顧客招待”（○，矢印）となる。セミナとセッションは1対多で，1回のセミナで20〜30個のセッションを開催し，セッションは必ずどれかのセミナに属するので，両側とも●になる。受講申込と受講セッションも1対多で，申込者は1〜5個のセッションを必ず予約するので，両側とも●になる。セッションと受講セッションは1対多で，受講セッションは必ずセッションを指すが，予約が一件もないセッションもあり得るので“セッション”（●）→“受講セッション”（○，矢印）となる。

残る顧客招待と受講申込は1対1で，両側とも○になる。1回のセミナに同一顧客は複数回申し込めないので，顧客招待（セミナ番号，顧客 ID）一つに対応する受講申込は高々一つである。招待されても申し込まない顧客がおり，顧客以外の受講希望者の申込みもあるので，どちらから見ても相手が存在しないことがある。講評は，リレーションシップはシステムの要件をしっかり理解しなければ正答を導けないとしている。

この設問は解答用紙の図に記号を描き込むので，入力欄はない。多重度（1対1か1対多か）と，それぞれの側から相手が必ず存在するか（●か○か）を，主キーの構成と本文の要件の両方から確かめる。特に顧客招待と受講申込は，“同一顧客が複数回申し込むことはできない”から1対1になる点を見落としやすい。

採点講評（IPA）

設問1(1)，(2)は，E-R図を用いてエンティティタイプの設計に関して出題したが，正答率は低かった。特に，リレーションシップについては，システムの要件をしっかり理解しなければ正答を導くことができないことを十分に理解してほしい。

本文の根拠

表1 会議室変更

同時限の他のセッションの予約状況を確認し，可能であれば，定員が多い会議室への変更を行う。

〔新システムの設計〕

(3) 選択したセッションのcを，選択したセッションの会議室のaで割って倍率を求め，その倍率が最も低いセッションを選択する。

〔新システムの設計〕

(4) 選択したセッションのeと当該セッションのeを入れ替える。

会議室変更は，同時限の他のセッションと会議室を入れ替えて，定員が多い会議室に移す処理である。(1)ではまず，会議室の定員が当該セッションの会議室の定員よりも多いセッションを選ぶ（a は定員，b は多い）。(2)では，その中から予約人数が当該セッションの予約人数よりも少ないセッションを選ぶ（c は予約人数，d は少ない）。入れ替えた後に相手のセッションが困らないよう，予約の少ないセッションに限る。

(3)は，予約人数を会議室の定員で割った倍率が最も低い，つまり会議室に最も余裕のあるセッションを選ぶ手順で，(1)(2)の a と c がここでも同じ属性であることが確かめられる。(4)で入れ替えるのは，“セッション”の属性のうち会議室を表す会議室 ID である（e）。

字数制限はないが，(4)の e は“会議室”エンティティではなく，“セッション”がもつ属性の「会議室ID」を答える。解答例は a「定員」，b「多い」，c「予約人数」，d「少ない」，e「会議室ID」。

本文の根拠

〔新システムに対する要件〕(4)

各セッションの予約人数，当該会議室の定員，予約者の来場情報，予約者の当該セッションへの入室情報及び現在入室している人数を基に，受講見込人数の推定を行い，空席待ちの受講者の入室を段階的に効率よく行えるようにする。

図1

受講申込：セミナ番号（下線），申込ID（下線），顧客ID，会社名，所属部署名，役職名，氏名，申込日時，来場日時。

図1

受講セッション：セミナ番号（下線），申込ID（下線），時限（下線），セッションID，入室日時。

要件(4)は，予約人数と定員のほかに，予約者の来場情報，予約者の当該セッションへの入室情報，現在入室している人数の三つを使うとしている。これを図1 の属性で表すと，来場情報は“受講申込”の来場日時，入室情報は“受講セッション”の入室日時，現在入室している人数は“セッション”の入室人数になる。

来場日時と入室日時は，どの受講者のものかを示さないと意味をもたない。当該セッションを受講する（予約している）受講者の，セミナへの来場日時とセッションへの入室日時である。講評は，属性名だけを記述した解答が多く，設問の理解が十分でなかったとしている。問われているのは「どのような情報か」なので，誰の何の情報かまで書く。

それぞれ30字で，「当該セッションを受講する受講者の」と対象を限定し，属性名で結ぶ。解答例は「当該セッションを受講する受講者のセミナへの来場日時」（25字），「当該セッションを受講する受講者のセッションへの入室日時」（27字），「当該セッションの入室人数」（12字）。

採点講評（IPA）

設問2は，システム要件に書かれた情報を，属性名を用いて記述する問題であった。システム要件に書かれた情報は五つあり，設問の記述の中に，その中の二つが書かれているので，残りの三つの情報を属性名を用いてどう表すかを考えれば解答できる設問であったが，正答率は低かった。属性名だけ記述してある解答も多く，設問の理解が十分でなかったものと思われる。

本文の根拠

〔営業担当役員からの追加要望〕

セミナの開催場所と内容によって，重要顧客を選定する。

表2 顧客招待

営業担当は，当該セミナに招待したい顧客を選んだとき，重要顧客については，顧客の一覧にその区分を付けて事務局へ提出する。

図1

顧客招待：セミナ番号（下線），顧客ID（下線）。

重要顧客は，セミナの開催場所と内容によって選定される。同じ顧客でも，あるセミナでは重要顧客で，別のセミナではそうでないことがあるので，顧客そのものの属性ではなく，セミナと顧客の組合せの属性になる。図1 で主キーが（セミナ番号，顧客 ID）のエンティティタイプは“顧客招待”である。

表2 の顧客招待の追加点でも，営業担当が招待したい顧客を選ぶときに重要顧客に区分を付けて提出している。つまり重要顧客は招待時に選定され，事務局が“顧客招待”に登録する時点で区分が決まる。講評は，属性名を見て思い込みで解答したと思われる誤答が多かったとし，その情報がどの時点で何に対して付与されるかを理解すれば容易に解けたとしている。“顧客”に追加するとセミナごとの違いを表せない。

理由は35字で，「開催場所と内容によって」と「招待時に選定される」を入れる。解答例は「重要顧客はセミナの開催場所と内容によって，招待時に選定されるから」で32字。

採点講評（IPA）

設問3(1)は，利用者の追加要件から出た項目を，どのエンティティタイプに追加すべきかを問う問題であった。その情報は，どの時点で何に対して付与されるものかを理解すれば容易に解けたはずだが，属性名を見て思い込みで解答したと思われる誤った解答が多く見られた。

本文の根拠

表1 セミナ受付

受講者から受講票を提示してもらい，申込 ID を記録した受講カードを発行し，受講者の来場を記録する。

表1 セッション入室

各会議室の入口に IC カードリーダを設置し，受講者は受講カードをかざして入室する。

図1

受講申込：セミナ番号（下線），申込ID（下線），顧客ID，会社名，所属部署名，役職名，氏名，申込日時，来場日時。

重要顧客区分は“顧客招待”にあり，その主キーは（セミナ番号，顧客 ID）である。したがって，受付や入室のときに顧客 ID を求められれば重要顧客区分を参照できる。受付と入室で手元にあるのは申込 ID なので，申込 ID で“受講申込”を参照し，その属性の顧客 ID を得る（g は申込ID，h は受講申込，i は顧客ID）。

申込 ID をどこから読むかは処理で異なる。セミナ受付では受講者が受講票を提示し，受講票には申込 ID が表示されているので f は受講票になる。セッション入室では受講者が受講カードをかざし，受講カードには申込 ID が記録されているので j は受講カードになる。

字数制限はないが，g・h・i は図1 の属性名とエンティティタイプ名をそのまま使う。h は表2 で“ ”で囲まれているのでエンティティタイプ名が入る。解答例は f「受講票」，g「申込ID」，h「受講申込」，i「顧客ID」，j「受講カード」。

本文の根拠

〔現状と課題〕(3)

受講者が実際にどのセッションを受講したか把握できないので，有効なフォロー営業ができない。

〔新システムに対する要件〕(3)

各セッションの会議室の入口に設置した IC カードリーダに，受講者が受講カードをかざすことによって，予約の有無の確認を行い，セッションの受講を記録する。

現状の課題(3)は，受講者が実際にどのセッションを受講したかを把握できないので，有効なフォロー営業ができないというものである。会議室の入口では受講票の確認だけで，申込 ID などの受講者の情報を記録していなかった。

新システムでは，受講者が IC カードリーダに受講カードをかざすことで，セッションの受講を記録する。これによって，予約したセッションではなく実際に受講したセッションが分かるようになり，フォロー営業に確実に渡せる。予約の情報や来場の情報は現在のシステムでも把握できているので，新たに確実に渡せるようになった情報には当たらない。

25字で「受講者が」「どのセッションを受講したか」を入れる。解答例は「受講者がどのセッションを受講したかという情報」で22字。

本文の根拠

〔運営システムの運用〕

利用者は，返却予定時刻までに，貸出しを受けた駐車ステーションに EV を返却する。

〔運営システムの機能〕(2)

USB I/F 経由で，カーナビと通信し，現在位置，目的地までの距離及び所要時間の情報を得る。

〔運営システムの機能〕(2)

カーナビから得られる情報を監視し，返却予定時刻の超過又は走行可能距離の不足が予測される場合は，サーバに通知し，利用者に警告する。

〔運営システムの機能〕(2)

また，必要に応じて最寄りの駐車ステーションの位置情報・充電可否情報を得る。

〔運営システムに用いる EV の仕様概要〕

カーナビは，USB I/F 経由で他の機器と接続され，データの入出力，画像表示，音声の再生などができる。

EV は貸出しを受けた駐車ステーションに返却するので，車載端末がカーナビに送る返却先の位置情報は a「貸出しを受けた駐車ステーション」である。カーナビは現在位置からそこまでの最短経路を求め，渋滞情報も参照して所要時間を求める（b は「所要」）。車載端末はカーナビから得た情報を監視し，返却予定時刻の超過が予測される場合にサーバに通知するので，c は「返却予定時刻」になる。

走行可能距離が不足すると判断した場合は，最寄りの駐車ステーションで充電できる。車載端末は必要に応じてサーバから最寄りの駐車ステーションの位置情報を得るので，d は「最寄りの駐車ステーション」である。その位置情報を利用者に示すには，画像表示ができるカーナビに送って表示させればよいので，e は「カーナビ」になる。

字数制限はないが，a と d はどちらも駐車ステーションなので，「貸出しを受けた」と「最寄りの」で区別して書く。b は後に「時間」が続くので「所要」の2字だけを入れる。

本文の根拠

表1 RF タグリーダ

会員証の RF タグを読み取る。

表1 キーボックス

キーを保管する。自動開閉する扉がある。各駐車ステーションでの設置数は，EV 配備台数分とする。

〔運営システムの機能〕(1)

次に，充電ケーブルに対応するキーボックスにキーが返却されたことを確認し，キーボックスの扉を閉め，サーバに返却確認情報を送信する。

表1 の構成品のうち，物を識別して読み取る機能をもつのは RF タグリーダで，会員証の RF タグを読み取るのに使っている。キーにも RF タグを付け，それぞれのキーボックスに RF タグリーダを増設すれば，返却されたキーの RF タグを読み取って，どの EV のキーかを確かめられる。

充電スタンドは，EV が返却されたときに充電ケーブルに対応するキーボックスにキーが返却されたことを確認している。キーボックスは EV 配備台数分あり，充電ケーブルとの対応で EV が分かるので，キーボックスの中のキーを読み取れば EV とキーの対応を確認できる。充電ケーブルや制御部を増設しても，キーそのものは識別できない。

方法は30字で，「キーに RF タグを付け」と「追加した RF タグリーダで読み取る」の二つを入れる。解答例は構成品が「RFタグリーダ」，方法が「キーにRFタグを付け，追加したRFタグリーダで読み取る。」で28字。

本文の根拠

〔運営システムの機能〕(3)

EV の利用時間割当てなどを参照し，各充電スタンドの充電スケジュールを管理する。そのとき，EV のバッテリ残量によって決まる充電所要時間を求めてスケジュールを決める。

〔運営システムの機能〕(1)

充電ケーブルを介して，EV と定期的に通信し，バッテリ残量を読み取り，サーバに送信する。

〔運営システムの機能〕(1)

接続されている EV が複数台でも，1 台ずつ充電する。

充電スケジュールを決めるのはサーバで，EV のバッテリ残量から充電所要時間を求めて決める。そのためにサーバが充電スタンドから受け取る必要があるのは，駐車中の EV のバッテリ残量である。充電スタンドは充電ケーブルを介して EV と定期的に通信し，バッテリ残量を読み取ってサーバに送信している。

一つの充電スタンドは接続された EV を1台ずつ充電するので，スケジュールを決めるには，その充電スタンドに駐車している各 EV のバッテリ残量が要る。講評は，“充電所要時間”という解答が散見されたが，充電スタンドからサーバへ送信されるデータとしては不適切だとしている。充電所要時間はサーバがバッテリ残量から求めるものである。

20字で「駐車中の各 EV の」と対象を限って「バッテリ残量」と書く。解答例は「駐車中の各EVのバッテリ残量」で14字。

採点講評（IPA）

設問2(2)は，“充電所要時間”との解答が散見されたが，充電スタンドからサーバへ送信されるデータとしては不適切である。問題文を十分理解してもらいたい。

本文の根拠

〔運営システムの機能〕(2)

車両通信 I/F 経由で，バッテリ残量，走行速度を監視し，走行可能距離を計算する。

〔運営システムの機能〕(2)

一方，定期的に，走行可能距離と各 I/F 経由で得られた自車の監視情報を，サーバに送信する。

〔運営システムの機能〕(3)

車載端末から受信した情報によって，EV の現在位置，バッテリ残量，走行可能距離を監視し，状況によっては EV に必要な情報を送信する。

サーバは車載端末から受信した情報で，EV の現在位置，バッテリ残量，走行可能距離を監視する。このうち走行可能距離は車載端末が計算して別に送るものなので，各 I/F 経由で得た監視情報は現在位置とバッテリ残量である。

バッテリ残量は車両通信 I/F 経由で電子制御ユニットから得る。現在位置は USB I/F 経由でカーナビから得る。カメラ入力 I/F は車内カメラの画像を入力して画像記録用メモリに記録するためのもので，定期的にサーバへ送る監視情報には当たらない。

字数制限はないが，I/F と監視情報を対にして答える。解答例は①が「車両通信I/F」と「バッテリ残量」，②が「USB I/F」と「現在位置」。①，②は順不同。

本文の根拠

〔運営システムの機能〕(2)

事故の状況を把握したり，車内の状況を確認したりするために，車内，車外を撮れる車内カメラによる画像を記録する。

表2 カメラ入力 I/F

車内カメラからの画像を入力する。

顔認証をサーバで行うには，運転者の顔の画像を車載端末からサーバに送ればよい。送信すべき情報は顔画像データである。

新たに専用機器を追加しないという条件なので，顔の撮影には既にある車内カメラを使う。車内カメラは車内，車外を撮れ，カメラ入力 I/F から車載端末に画像を入力できる。車載端末は移動体通信モジュールでサーバと通信できるので，撮影した顔画像をそのままサーバへ送信できる。

方法は20字で，「車内カメラで」と「運転者の顔を撮影する」を入れる。解答例は情報が「顔画像データ」，方法が「車内カメラで運転者の顔を撮影する。」で17字。

本文の根拠

〔運営システムに対する要望〕

事故が発生した時の画像記録を残し，要因及び責任の所在を調査できるようにしてほしい。

表2 画像記録用メモリ

車内カメラから入力した画像を記録する。

異常発生時の前後それぞれ一定時間の記録を残すには，異常が起きる前の画像も記録されていなければならない。そこで画像は常に記録し続けるが，一定時間を経過した部分から順に上書きしていけば，メモリには直近の一定時間分だけが残り，使用量が一定に抑えられる。異常が発生したら，その後の一定時間を記録したところで上書きをやめれば，前後の記録が残る。

講評は，“異常発生をトリガにして記録開始する”という解答が散見されたとしている。問題文は異常発生時の“前後”の記録を残すとしているので，異常が起きてから記録を始めたのでは，発生前の画像が残らない。

30字で「一定時間を経過した画像データ部分から」と「順次上書きする」を入れる。解答例は「一定時間を経過した画像データ部分から順次上書きする。」で26字。

採点講評（IPA）

設問4(1)は，“異常発生をトリガにして記録開始する”との解答が散見された。問題文に異常発生時の“前後”の記録を残す必要があると記述しているので，要件を正確に理解し，実現できる方法を求められていることを理解してほしい。

本文の根拠

〔運営システムの機能〕(1)

充電ケーブルを介して，EV と定期的に通信し，バッテリ残量を読み取り，サーバに送信する。

〔運営システムに用いる EV の仕様概要〕

また，LAN は，充電ケーブルを介して外部の充電スタンドと接続でき，EV と充電スタンドとの間で EV の識別情報，バッテリ残量の確認などの通信を可能とする。

充電スタンドは，充電ケーブルを介して EV と定期的に通信し，バッテリ残量を読み取っている。この定期的な通信は，充電ケーブルが EV につながっている間だけ成り立つ。

利用開始時の手続を経ずに充電ケーブルが EV から切り離されると，この定期的な通信が途絶える。正規の貸出しでは認証の後に充電ケーブルのロックを解除するので，充電スタンドは切り離しが正規かどうかを区別できる。手続なしに通信が途絶えたことを検知すれば，盗難の疑いとして扱える。

方法は20字で「通信が途絶えたことを検知する」と書く。解答例は機能が「EVとの定期的な通信」，方法が「通信が途絶えたことを検知する。」で15字。