問1 販売管理システム
販売管理システムに関する次の記述を読んで，設問1〜4に答えよ。
A 社は，缶入りの飲料を製造・販売している。商品の大部分は自動販売機（以下，自販機という）で販売されるので，自販機向けの販売管理システム（以下，A 社販売管理システムという）を構築し，運用している。このたび，A 社販売管理システムの機能強化を図ることにした。
〔A 社の概要〕
(1) 営業所が全国に 300 か所あり，各営業所には商品倉庫が一つずつある。 (2) 各営業所には，約 10 名の営業担当者が所属しており，各営業担当者にトラック 1 台が割り当てられている。 (3) 各営業担当者は，ハンディターミナル（以下，HT という）を 1 台ずつ所持する。各営業担当者は，約 200 台の自販機を担当し，毎日数回から毎月 1 回の頻度で担当の自販機を巡回して，売上金の回収や商品の補充などを行う。 (4) 自販機は，商品を格納する縦型のストッカ（以下，コラムという）を 30〜40 個内蔵しており，自販機前面の操作ボタンと連動して商品を販売する。 (5) 工場での商品の 1 回の製造単位をロットといい，1 ロット当たりの商品数量は数十万本である。ロットごとに一意のロット番号が付与される。ロット番号，製造年月日，製造工場番号，商品コード，商品賞味期限，原材料番号などは生産管理システムで管理されている。 〔販売管理業務と A 社販売管理システムの概要〕
① A 社販売管理システムは，サーバ，各営業所に設置される Web 端末及び HT から構成される。HT はサーバや自販機と通信をすることができる。 ② サーバ及び HT はファイルを保持しており，ファイルは，Web 端末や HT を介した入力，サーバと HT との通信，HT と自販機との通信，夜間バッチ処理で更新される。 ① ダウンロード処理：自販機の巡回出発前に，当日の巡回に必要なファイルを，サーバから HT にダウンロードする。 ② 売上処理：自販機に到着後，HT と自販機を通信させ，自販機コードと，コラムごとにコラム番号，販売単価及び売上数のデータを取得する。HT のアプリケーションは，販売単価及び売上数から売上金額を計算し，取得及び計算したデータを HT に保存する。その後，売上金を回収する。 ③ 補充処理：HT のアプリケーションで，売上処理で取得した売上数を基にコラムごとの最適補充数を計算する。それを参考に商品を補充し，補充数を HT に入力する。HT のアプリケーションは，HT 内のファイルの情報，売上数及び補充数から，コラムごとの在庫数及びトラックの商品ごとの在庫数を計算し，入力及び計算したデータを HT に保存する。さらに，自販機内のコラムごとの売上数をゼロにする。 ④ トラック棚卸処理：自販機の巡回終了後，営業所に戻り，トラックの商品の棚卸しを行う。棚卸しでは，トラックコード，商品コード及び実地棚卸数を HT に入力する。HT のアプリケーションは，トラック在庫マスタの在庫数を実地棚卸数で更新する。 ⑤ 積込積降処理：棚卸結果などから次の巡回に必要な商品をトラックに積み込み，倉庫コード，トラックコード，商品コード及び積込数を HT に入力する。また，不要な商品はトラックから倉庫に降ろし，倉庫コード，トラックコード，商品コード及び積降数を HT に入力する。HT のアプリケーションは，HT 内のファイルの情報及び入力されたデータから，トラックの商品ごとの在庫数を計算し，入力及び計算したデータを HT に保存する。 ⑥ アップロード処理：積込積降処理終了後，HT 内のファイルをサーバにアップロードする。サーバでは，該当するファイルの該当するレコードを更新する。 (3) 営業所の業務（倉庫担当者が Web 端末で行う） ① 入庫処理：工場から倉庫に商品が届いた際，検品後に登録する。 ② 移動出庫処理：ほかの倉庫に商品を移動する際，移動元倉庫で登録する。 ③ 移動入庫処理：ほかの倉庫から商品が届いた際，移動先倉庫で検品後に登録する。 ④ 返品出庫処理：商品を工場に返品する際，登録する。 ⑤ 倉庫在庫確定処理：HT から当日アップロードされたデータを入力として，倉庫在庫マスタを更新し，当日の在庫数を確定する。夜間バッチ処理で行われる。 主要なファイルの一覧を表 1 に，ダウンロード処理とアップロード処理を除く HT のアプリケーションの処理の DFD を図に示す。図は作成途中であり，データのうち HT 番号と各伝票番号は省略している。
表1 主要なファイルの一覧
図 HT のアプリケーションの処理の DFD（作成途中）
〔機能強化〕
次の二つの対応を行うことにした。
(1) ほかの営業担当者が担当する自販機への巡回対応 現在，1 日のうちに複数の営業担当者が同一自販機を巡回することはない。しかし，今後は巡回する可能性があり，問題なく対応できるようにする。そのため，サーバのコラムマスタの在庫数を，HT 内のコラムマスタのアップロード時に HT 内に保存されている値で更新するのではなく，サーバで計算し直すことを考えている。
自販機内の商品は，通常 1 か月以内に販売される。したがって，トラックや倉庫の在庫の賞味期限が 2 か月以上あれば，賞味期限に余裕をもった商品を販売できる。
生産管理システムからロットごとの商品賞味期限を入手し，その商品賞味期限が，本日から 2 か月以内に迫っているロットが，どの倉庫，どのトラックに存在するかを調べ，一覧表として出力する。この機能の実現のためには，ロット番号を関連するファイルに記録する必要がある。ロット番号を属性として追加するファイルと，そのロット番号を利用する処理との関連の一部を抜き出して，表 2 に整理した。
表2 ロット番号を追加するファイルと利用する処理との関連（一部）
出題趣旨（IPA）
情報システムがほかのシステムと連携することは一般的であり，組込みシステムと連携する場合も多い。また，企業環境の変化からシステム変更も発生するようになった。システムアーキテクトには，組込みシステムとの適切な連携方式の設計や，そのシステム変更を速やかに実施することが求められる。本問では，既に小売形態として一般化した，自動販売機向けの販売管理システムを例にとり，組込みシステムとの連携の設計能力や業務変更仕様からシステム変更点を適切に指摘できる能力を評価する。また，業務要件をDFDに適切に反映できる能力も評価する。
採点講評（問全体・IPA）
問1では，自販機の販売管理システムを例にとり，組込みシステムとの適切な連携方式の設計や，システム変更について出題した。全体として，題意はよく理解されていたようであった。
システムアーキテクトとして，アプリケーションの仕様を正確に理解したうえで，システム変更方法を考えることを心がけてもらいたい。
設問と解答例
設問1(1)
30字以内
図中の補充プロセスは売上プロセスの後に実行される。そのように設計した理由を 30 字以内で述べよ。
解答例
解説
本文の根拠
〔販売管理業務と A 社販売管理システムの概要〕(2) ② 売上処理
自販機に到着後，HT と自販機を通信させ，自販機コードと，コラムごとにコラム番号，販売単価及び売上数のデータを取得する。
〔販売管理業務と A 社販売管理システムの概要〕(2) ③ 補充処理
HT のアプリケーションで，売上処理で取得した売上数を基にコラムごとの最適補充数を計算する。
図 HT のアプリケーションの処理の DFD
売上から補充へ“コラム番号，売上数”。
補充プロセスは，コラムごとの最適補充数を計算する。その計算の基になるのは，売上処理で自販機から取得した売上数である。売上数は，売上プロセスが自販機と通信して初めて HT に入るので，補充プロセスは売上プロセスが終わってからでないと動けない。
図の DFD でも，売上から補充へ“コラム番号，売上数”のデータフローが引かれている。補充プロセスの入力に売上プロセスの出力が含まれていることが，実行順序を決めている。講評によれば，設問1は正答率が高かった。
30字で「補充の処理が売上数を使う」ことを理由の形にする。解答例は「補充プロセスの処理では売上数を必要とするから」で22字。
採点講評（IPA）
設問1は，正答率が高かった。
設問1(2)
30字以内
補充処理で，自販機内のコラムごとの売上数をゼロにしている理由を，30 字以内で述べよ。
解答例
売上数をゼロにしないと売上数が累積されてしまうから
解説
本文の根拠
〔A 社の概要〕(3)
毎日数回から毎月 1 回の頻度で担当の自販機を巡回して，売上金の回収や商品の補充などを行う。
〔販売管理業務と A 社販売管理システムの概要〕(2) ② 売上処理
HT のアプリケーションは，販売単価及び売上数から売上金額を計算し，取得及び計算したデータを HT に保存する。その後，売上金を回収する。
〔販売管理業務と A 社販売管理システムの概要〕(2) ③ 補充処理
さらに，自販機内のコラムごとの売上数をゼロにする。
自販機は，コラムごとの売上数を内部に持っている。営業担当者は巡回のたびに売上処理でこの売上数を読み取り，売上金額を計算して売上金を回収する。つまり，1回の巡回で扱う売上数は，前回の巡回から今回までに売れた分でなければならない。補充処理の最後に売上数をゼロにしておかないと，次の巡回で読み取る売上数に今回までの分が累積されて残り，売上金額や最適補充数を二重に数えてしまう。
担当の自販機は毎日数回から毎月1回の頻度で巡回されるので，巡回ごとに区切りを付ける必要がある。講評によれば，“売上金を回収するから”“補充数を入力するから”のように，問題文中の関連のありそうな文章を抜き出しただけの解答が多かった。売上数をゼロにしないと何が起きるかを書く。
30字で「ゼロにしないと累積される」ことを書く。解答例は「売上数をゼロにしないと売上数が累積されてしまうから」で25字。
採点講評（IPA）
設問1は，正答率が高かった。設問1(2)の誤った解答としては，“売上金を回収するから”，“補充数を入力するから”など問題文中の関連のありそうな文章を抜き出したままの解答が多かった。
設問1(3)
図の DFD を完成させよ。図の DFD の表記例に倣って，プロセスを一つ，データフローを三つ，データとともに追記すること。ただし，データは属性名で記述し，ほかの部分と同様，HT 番号と各伝票番号は省略し，その他の属性は省略しない。なお，図に〔機能強化〕は反映させない。
解答例（図）
解説
本文の根拠
〔販売管理業務と A 社販売管理システムの概要〕(2) ④ トラック棚卸処理
棚卸しでは，トラックコード，商品コード及び実地棚卸数を HT に入力する。HT のアプリケーションは，トラック在庫マスタの在庫数を実地棚卸数で更新する。
表1
トラック在庫マスタ：トラックコード（下線），商品コード（下線），在庫数。
表1
トラック棚卸：HT 番号（下線），トラック棚卸伝票番号（下線），棚卸日，トラックコード。
表1
トラック棚卸明細：HT 番号（下線），トラック棚卸伝票番号（下線），商品コード（下線），実地棚卸数。
図 HT のアプリケーションの処理の DFD
営業担当者から出た“トラックコード，商品コード，実地棚卸数”の矢印と，商品マスタから出た“商品マスタ情報”の矢印は，どのプロセスにもつながらず空白を指している。
図の DFD には，売上・補充・積込積降の三つのプロセスがあるが，HT のアプリケーションの処理のうちトラック棚卸処理のプロセスが無い。営業担当者からの“トラックコード，商品コード，実地棚卸数”と商品マスタからの“商品マスタ情報”が空白を指しているのは，そこにトラック棚卸のプロセスが入るからである。一方，トラック棚卸とトラック棚卸明細のファイルにはどこからもデータフローが来ていない。したがって，追記するプロセスはトラック棚卸で，データフローはトラック棚卸からトラック在庫マスタ，トラック棚卸，トラック棚卸明細への三つになる。
データは表1の属性から HT 番号と各伝票番号を除いて書く。トラック棚卸のファイルは“棚卸日，トラックコード”，トラック棚卸明細は“商品コード，実地棚卸数”である。トラック在庫マスタは，本文が「トラック在庫マスタの在庫数を実地棚卸数で更新する」としているので，キーのトラックコード・商品コードと，更新後の在庫数を渡す“トラックコード，商品コード，在庫数”になる。
字数制限の無い作図の設問である。設問は「その他の属性は省略しない」としているので，トラック棚卸の“棚卸日”のように入力データに無い属性も落とさない。トラック在庫マスタへのデータは，入力の“実地棚卸数”ではなくファイルの属性名の“在庫数”で書く点を間違えやすい。
採点講評（IPA）
設問1は，正答率が高かった。
設問2(1)
この処理の入力ファイルを，表 1 中のファイル名を用いてすべて答えよ。
解答例
解説
本文の根拠
〔販売管理業務と A 社販売管理システムの概要〕(3) ⑤ 倉庫在庫確定処理
HT から当日アップロードされたデータを入力として，倉庫在庫マスタを更新し，当日の在庫数を確定する。夜間バッチ処理で行われる。
〔販売管理業務と A 社販売管理システムの概要〕(2) ⑤ 積込積降処理
棚卸結果などから次の巡回に必要な商品をトラックに積み込み，倉庫コード，トラックコード，商品コード及び積込数を HT に入力する。また，不要な商品はトラックから倉庫に降ろし，倉庫コード，トラックコード，商品コード及び積降数を HT に入力する。
表1
積込積降：HT 番号（下線），積込積降伝票番号（下線），積込積降日，倉庫コード，トラックコード。
表1
積込積降明細：HT 番号（下線），積込積降伝票番号（下線），商品コード（下線），積込積降フラグ，積込積降数。
倉庫在庫確定処理は，HT から当日アップロードされたデータを入力にして倉庫在庫マスタを更新する。HT のファイルのうち倉庫の在庫を増減させるのは，積込み（倉庫からトラックへ）と積降ろし（トラックから倉庫へ）を記録した積込積降処理のデータだけである。売上補充やトラック棚卸は自販機やトラックの在庫の話で，倉庫の在庫は動かない。
倉庫在庫マスタのキーは倉庫コードと商品コードである。倉庫コードは積込積降（見出し）にあり，商品コードと積込積降数は積込積降明細にある。どちらか一方では，どの倉庫のどの商品が何個増減したかが分からないので，二つとも入力になる。
字数制限の無い設問で，表1のファイル名で答える。明細だけを挙げると倉庫コードが得られないので，見出しの積込積降も忘れずに挙げる。
採点講評（IPA）
設問2は正答率が低かった。HTに倉庫在庫マスタがないことには気づいても，HTのどのデータからどのようにサーバの倉庫在庫を更新すべきか理解できていないようであった。倉庫在庫の増減に関連する処理のうち，オンラインで倉庫在庫を更新していない処理の結果を反映する必要があることに気づいてほしかった。
設問2(2)
35字以内
倉庫の在庫を確定するためにこの処理が必要な理由を，35 字以内で述べよ。
解答例
積込み・積降ろしした分を倉庫在庫に反映させる必要があるから
解説
本文の根拠
表1
注 ※は，ファイルがサーバだけに存在することを示し，無印はサーバ及び HT 上に存在することを示す。
〔販売管理業務と A 社販売管理システムの概要〕(2) ⑤ 積込積降処理
HT のアプリケーションは，HT 内のファイルの情報及び入力されたデータから，トラックの商品ごとの在庫数を計算し，入力及び計算したデータを HT に保存する。
表2
倉庫在庫マスタ（S）：b が CU，c が CU，d が U，e が U，f が U。
倉庫在庫マスタには※が付いており，サーバだけにある。積込積降処理は HT のアプリケーションで行われ，計算するのはトラックの商品ごとの在庫数だけである。倉庫から商品を積み込んだり倉庫へ降ろしたりしても，その時点では倉庫在庫マスタは更新されない。入庫・移動入庫・返品出庫・移動出庫は倉庫担当者が Web 端末で登録するのでサーバの倉庫在庫マスタが直接更新されるが，積込み・積降ろしの分だけは，後からサーバ側で反映する処理が必要になる。これが倉庫在庫確定処理である。
表2でも，倉庫在庫マスタを更新する処理のうち，積込積降明細（S）を参照するのは f の倉庫在庫確定処理だけである。講評によれば，設問2は正答率が低く，HT に倉庫在庫マスタがないことに気づいても，HT のどのデータからどのように倉庫在庫を更新すべきか理解できていない解答が多かった。
35字で「積込み・積降ろしの分」と「倉庫在庫に反映させる」を理由の形にする。解答例は「積込み・積降ろしした分を倉庫在庫に反映させる必要があるから」で29字。
採点講評（IPA）
設問2は正答率が低かった。HTに倉庫在庫マスタがないことには気づいても，HTのどのデータからどのようにサーバの倉庫在庫を更新すべきか理解できていないようであった。倉庫在庫の増減に関連する処理のうち，オンラインで倉庫在庫を更新していない処理の結果を反映する必要があることに気づいてほしかった。
設問3(1)
40字以内
サーバのコラムマスタの在庫数を計算し直す理由を，40 字以内で述べよ。
解答例
在庫数は巡回したすべてのHT内の売上と補充の情報から計算する必要があるから
解説
本文の根拠
〔販売管理業務と A 社販売管理システムの概要〕(2) ① ダウンロード処理
自販機の巡回出発前に，当日の巡回に必要なファイルを，サーバから HT にダウンロードする。
〔販売管理業務と A 社販売管理システムの概要〕(2) ③ 補充処理
HT のアプリケーションは，HT 内のファイルの情報，売上数及び補充数から，コラムごとの在庫数及びトラックの商品ごとの在庫数を計算し，入力及び計算したデータを HT に保存する。
〔機能強化〕(1)
そのため，サーバのコラムマスタの在庫数を，HT 内のコラムマスタのアップロード時に HT 内に保存されている値で更新するのではなく，サーバで計算し直すことを考えている。
各 HT のコラムマスタの在庫数は，巡回出発前にダウンロードした値を起点に，その HT で行った売上と補充だけを反映して計算されている。1日に2人の営業担当者が同じ自販機を巡回すると，2台の HT はどちらも朝の同じ在庫数から出発し，それぞれ自分の巡回分しか反映していない。アップロード時に HT の値でサーバを上書きすると，後からアップロードした HT の値だけが残り，先に巡回した分の売上・補充が失われる。
そこで，サーバの在庫数は，巡回したすべての HT の売上と補充の情報から計算し直す必要がある。講評によれば，設問3は正答率が低く，HT のコラムマスタを巡回の順序でアップロードすれば正しい在庫数が得られるとする解答が散見された。各 HT の在庫数は朝の在庫数から計算されているので，巡回順にアップロードしても正しくならない。
40字で「すべての HT の売上と補充の情報から計算する」ことを理由の形にする。解答例は「在庫数は巡回したすべてのHT内の売上と補充の情報から計算する必要があるから」で37字。
採点講評（IPA）
設問3も正答率が低かった。HTのコラムマスタを巡回の順序でアップロードすれば，正しい在庫数が得られるとしている解答が散見されたが，各HTのコラムマスタの在庫数は，朝のダウンロード時の在庫数から計算されているので，巡回順でアップロードしても正しい在庫数にはならない。コラムマスタ在庫の増減の原因である売上と補充から，再計算する必要があることを読み取ってほしかった。
設問3(2)
解答欄2つ
(1)で在庫数を計算し直す際に，サーバでコラムマスタの在庫数を計算するのに必要な HT のファイル名を，表 1 中から二つ選べ。
〔備考〕このうち異なる二つを答える（順不同）
解説
本文の根拠
表1
コラムマスタ：自販機コード（下線），コラム番号（下線），商品コード，在庫数，販売単価。
表1
売上補充：HT 番号（下線），売上補充伝票番号（下線），売上日，自販機コード，回収金額。
表1
売上補充明細：HT 番号（下線），売上補充伝票番号（下線），コラム番号（下線），商品コード，売上金額，売上数，補充数。
コラムマスタの在庫数を増減させるのは，売上（減る）と補充（増える）である。コラムマスタのキーは自販機コードとコラム番号なので，サーバで計算し直すには，どの自販機のどのコラムで売上数と補充数がいくつだったかが要る。売上数と補充数とコラム番号は売上補充明細にあるが，自販機コードは明細には無く，見出しの売上補充にある。
したがって，売上補充と売上補充明細の二つを伝票番号で結び付けて使う。どちらも※が付いていないので HT 上にあり，アップロードの対象になる。
字数制限の無い設問で，表1のファイル名で二つ答える。順不同で，①②に一つずつ書く。明細だけでは自販機が特定できないことに気付けば，見出しも要ることが分かる。
採点講評（IPA）
設問3も正答率が低かった。HTのコラムマスタを巡回の順序でアップロードすれば，正しい在庫数が得られるとしている解答が散見されたが，各HTのコラムマスタの在庫数は，朝のダウンロード時の在庫数から計算されているので，巡回順でアップロードしても正しい在庫数にはならない。コラムマスタ在庫の増減の原因である売上と補充から，再計算する必要があることを読み取ってほしかった。
設問4
解答欄7つ
表 2 中のa 〜g に入れる適切な字句を，〔販売管理業務と A 社販売管理システムの概要〕内の処理名を用いて答えよ。
〔備考〕bとcは順不同，dとeは順不同
解説
本文の根拠
表2
トラック在庫マスタ（H）：a が CU，g が U，補充処理が U。積込積降明細（H）：a が C。積込積降明細（S）：f が R。トラック棚卸明細（H）：g が C。入出庫明細（S）：b が C，c が C，d が C，e が C。
表2
倉庫在庫マスタ（S）：b が CU，c が CU，d が U，e が U，f が U。
〔販売管理業務と A 社販売管理システムの概要〕(3) ① 入庫処理
工場から倉庫に商品が届いた際，検品後に登録する。
〔販売管理業務と A 社販売管理システムの概要〕(3) ② 移動出庫処理
ほかの倉庫に商品を移動する際，移動元倉庫で登録する。
表2はロット番号を持たせるファイルと，それを登録・参照・更新する処理の関係である。a はトラック在庫マスタ（H）と積込積降明細（H）を作るので，HT で積込み・積降ろしを記録する積込積降処理である。g はトラック棚卸明細（H）を作りトラック在庫マスタ（H）を更新するので，トラック棚卸処理である。f は積込積降明細（S）を参照して倉庫在庫マスタ（S）を更新するので，夜間の倉庫在庫確定処理である。
b〜e は入出庫明細（S）を登録して倉庫在庫マスタ（S）を更新するので，Web 端末で行う入庫・移動入庫・返品出庫・移動出庫のいずれかである。倉庫に商品が入ってくる処理では，その倉庫に無かったロットが届くことがあるので倉庫在庫マスタに新しいレコードを登録する（C）場合がある。出ていく処理では既にあるロットを減らすだけなので U になる。したがって，CU の b，c が入庫処理と移動入庫処理，U の d，e が返品出庫処理と移動出庫処理である。a がトラック在庫マスタで CU なのも，積込みで新しいロットがトラックに載ることがあるからで，補充処理が U だけなのはトラックの在庫を減らすだけだからである。
字数制限の無い設問で，本文の処理名で答える。b と c，d と e はそれぞれ順不同である。C と U の違いが，在庫が入ってくるか出ていくかに対応していることを読み取るのがかぎになる。
出典：平成21年度 秋期 システムアーキテクト試験 午後Ⅰ 問1（表記を一部改変）
問2 物流システムの再構築
物流システムの再構築に関する次の記述を読んで，設問1〜4に答えよ。
B 社は，大手食品メーカ X 社の関連会社で倉庫業を中心に事業を展開してきたが，総合物流会社を目指し，配送業中心の C 社を吸収合併することになった。それに伴い，B 社と C 社のシステムを統合再構築することになり，システム再構築の企画プロジェクトを立ち上げた。B 社情報システム部の D 課長がプロジェクトチームのリーダとなり，メンバには B 社及び C 社から業務担当の中核となる人材が任命された。
〔B 社の現行業務システム概要〕
(1) B 社は，関東に 2 か所ある X 社の工場で生産された製品を保管し，X 社の顧客である食品卸会社及び量販店に出荷するための仕分・包装を行っている。B 社倉庫に入荷する製品の配送及び X 社顧客に納品する製品の配送は，X 社が手配した車両で行っている。 (2) X 社の製品は，冷凍品，冷蔵品，常温品と温度帯別に管理する必要があり，倉庫は温度帯別に複数の保管庫に分かれている。 (3) 現行のシステムにおいて，X 社とのオーダの授受，保管・荷役などの実績送付，請求及び月次決算情報の送付などは，EDI で行っている。 (4) 倉庫業務のシステムには，ソフトウェアパッケージを利用しており，主に在庫管理と倉庫作業の実績収集を行っている。倉庫全体の在庫状況は把握できるが，保管庫ごとの在庫は把握できない。 (5) 会計システム及び給与計算システムには，X 社が利用しているソフトウェアパッケージと同じベンダのソフトウェアパッケージを利用している。会計処理では，仕訳伝票の入力から月次決算までを会計システムで行っている。 (6) 現在，X 社の物流部門と共同で，倉庫業務に関連する物流コストの管理方式の見直しを進めている。 〔C 社の現行業務システム概要〕
(1) C 社は，関東圏の食品メーカや食品卸会社を主な荷主とし，荷主の顧客に商品を配送している。配送は，冷凍品，冷蔵品，常温品を対象とし，温度帯別に対応できる自社保有車で行っている。 (2) 荷主から配送オーダを電話又はファクシミリで受け，受けたオーダに基づき配車計画を立て，車両及び運転手の手配を行う。 (3) 現行の配送関連システムは，車両の運行状況の管理を行っており，車両にはすべて，GPS 対応車載端末を搭載している。これによって道路混雑時に迂回路を指示して納品遅れを回避する効果を上げている。配送実績を収集し，運賃計算を行い，荷主に対して配送料を請求する業務も配送関連システムで行っている。 (4) 会計システム及び給与計算システムには，ソフトウェアパッケージを利用している。会計処理では，仕訳伝票の入力から月次決算までを会計システムで行っている。 (5) 配送コストは，人件費，燃料費など費目別に月単位で把握している。 〔合併後のビジネス概要〕
合併後の B 社は，倉庫事業と配送事業を営む総合物流会社へ変身を図る。倉庫事業においては，C 社の顧客である食品メーカや食品卸会社を中心に在庫・保管ビジネスへの拡大を図る。配送事業においては，X 社製品の入荷・出荷配送も取り込んでいく予定である。
〔システム再構築の基本方針〕
合併に向けて，プロジェクトチームに示されたシステム再構築の基本方針は，次のとおりである。
(1) B 社が利用しているソフトウェアパッケージが倉庫管理システムのほかに配送管理システムも備えていることから，B 社が利用しているソフトウェアパッケージを合併後の業務プロセスに適用し，課題と要望を取り込んで新たな業務プロセスとする。 (2) 現在 X 社の物流部門と共同で進めている物流コストの管理方式の見直しを，配送業務領域まで拡大し，その結果を踏まえて物流コスト管理システムにソフトウェアパッケージを利用するか否かを検討する。 〔合併に向けての業務システムへの課題と要望〕
プロジェクトチームは，合併に向けた課題と要望の洗い出しを行った。課題と要望を表に示す。
表 課題と要望
〔合併後の全体業務構成〕
D 課長は，合併後の全体業務構成を整理した。合併後の全体業務構成を図に示す。
図 合併後の全体業務構成
また，各業務のシステムでの対応方針を，次のように考えた。
① 在庫管理において，温度帯別管理の強化を基本に在庫管理精度の向上を図る。 ② 倉庫作業管理において，棚入れ，ピッキング，仕分，包装，棚卸しの作業指示と作業実績収集を強化する。 ③ 入荷管理において，荷降しから棚入れの準備までを配送の入荷オーダと連動させる。 ④ 出荷管理において，車両の運行方面や積載量を考慮して，配送品の積込みを効率よく行えるように，倉庫作業管理での作業指示の時点からシステムで対応できるようにする。 ① 配車管理において，配送ルート及び車両 1 台当たりの積載率の最適化を行う。 ② 運行管理において，車両位置管理の機能は，B 社が利用しているソフトウェアパッケージにはなく，今後 X 社からの配送を請け負うことの強みになるので，C 社のシステムを組み込むこととする。 ③ 車両管理において，車両の安全確保を意識した，点検・整備状況の管理を行う。 ① トレーサビリティへの対応として，荷主からの入荷から，商品の保管，仕分，包装，配送先への納品まで，倉庫管理システム及び配送管理システムで追跡できるようにする。 ② X 社の物流部門と共同で検討している，倉庫業務及び配送業務の活動要素別の原価計算を前提に，物流コスト管理のシステム化を図る。 ③ 財務管理の一般会計処理へは，会計上の取引発生元の業務システムから，自動仕訳で仕訳データを渡す。 ④ 受注管理において，荷主からの入荷オーダ，出荷オーダ，配送オーダを一元的に受け取り，倉庫業務及び配送業務に必要な指示が出せるようにする。 ⑤ 売上請求管理において，保管料，荷役料，運賃などの計算，売上処理，請求処理までを，合併後のすべての請求先に対して行う。 ⑥ 労務管理において，運転手及び倉庫作業者のシフト管理及び勤怠管理を行う。給与計算は，B 社で利用しているソフトウェアパッケージに統一する。 出題趣旨（IPA）
経済環境，市場環境の厳しさが増す中で，企業の吸収合併，資本提携，業務提携などが行われるケースが増加している。その場合，合併に向けて基幹業務などのシステムの統合，再構築が併せて検討される。本問は，物流会社の合併を例にとり，合併会社の情報システム戦略，合併に向けての業務システムの課題・要望を踏まえ，システムアーキテクトとして，全体最適の観点から，対象とする情報システムの構造を設計することについて，具体的な記述を求めている。本問では，システムアーキテクトとして，情報システム戦略を正しく理解し，全体最適の観点からあるべき業務プロセスの検討，業務モデルの設計，情報システム構造の設計を行う能力を評価する。
採点講評（問全体・IPA）
問2では，物流会社の合併におけるシステムの統合再構築を例にとり，全体最適の観点から，合併後の情報システム構造設計について出題した。全体として，題意はよく理解されていたようであった。
設問と解答例
設問1(1)
解答欄4つ
配送業務で，車両の有効活用の観点から解決すべき業務課題を二つ挙げよ。また，各課題に対してシステムでどのような対応策が考えられるか。それぞれ 40 字以内で述べよ。
〔①対応策〕解答例
出荷配送後の車両を，入荷配送に回せる最適配送ルート計画をシステムで行う。
〔②対応策〕解答例
納品物の容量と配送先から見て，最適な積載率になる混載計画をシステムで行う。
〔備考〕①，②は順不同
解説
本文の根拠
〔合併後のビジネス概要〕
配送事業においては，X 社製品の入荷・出荷配送も取り込んでいく予定である。
表 配送業務
納品後の車両が空車で帰るのはもったいない。帰り便をうまく活用した配車計画が必要だ。
表 配送業務
最近の傾向として配送が小口化しており，配送品の重量及び容積を勘案した配車や混載を考慮した車両 1 台当たりの積載効率を上げる仕組みが必要だ。
各業務のシステムでの対応方針 (2) ①
配車管理において，配送ルート及び車両 1 台当たりの積載率の最適化を行う。
表の配送業務の課題と要望のうち，“車両の有効活用”にかかわるのは，納品後の空車の帰り便と，小口化で下がる積載効率の二つである。前者に対しては，合併後は X 社製品の入荷配送（工場から B 社倉庫へ）も取り込むので，出荷配送で納品を終えた車両をそのまま入荷配送に回すよう，配送ルートを最適化する。後者に対しては，配送品の重量・容積と配送先を勘案して，1台当たりの積載率が最適になる混載計画を立てる。どちらもシステムで計画を行うことが対応方針の“配送ルート及び車両1台当たりの積載率の最適化”に当たる。
課題は表の要望を短くまとめればよい。講評によれば，配送業務の課題を問うているのに倉庫業務の課題を挙げた解答が散見された。また積載率の向上については，配送ルートと配送品の重量・容積の両面からの解答を期待したが，どちらか一方の解答が多かった。解答例の②の対応策も“容量”と“配送先”の両方に触れている。
対応策は各40字で「何を基に」「何の計画を」「システムで行う」を書く。解答例の対応策は①が36字，②が37字。①と②は順不同。
採点講評（IPA）
設問1(1)は，配送業務での業務課題を挙げよとしているにもかかわらず，倉庫業務での業務課題を挙げた解答が散見された。対応策については，積載率の向上に関して，配送ルートと配送品の重量・容積の両面からの解答を期待したが，どちらか一方の解答が多かった。
設問1(2)
15字以内
温度帯別管理の現状，課題と要望から見て，現状の倉庫管理システムにどのような機能の追加が必要か。15 字以内で述べよ。
解答例
解説
本文の根拠
〔B 社の現行業務システム概要〕(2)
X 社の製品は，冷凍品，冷蔵品，常温品と温度帯別に管理する必要があり，倉庫は温度帯別に複数の保管庫に分かれている。
〔B 社の現行業務システム概要〕(4)
倉庫全体の在庫状況は把握できるが，保管庫ごとの在庫は把握できない。
表 倉庫業務
倉庫全体の在庫状況はシステムで把握しているが，保管庫ごとの在庫もシステムで把握できるようにしたい。
倉庫は温度帯別に複数の保管庫に分かれており，温度帯別の管理はこの保管庫の単位で行われる。ところが現状の倉庫管理システムは倉庫全体の在庫しか把握できず，保管庫ごとの在庫は分からない。課題と要望にも，保管庫ごとの在庫をシステムで把握したいとある。したがって追加すべきは，保管庫ごとに在庫を管理する機能である。
合併後の全体業務構成でも，在庫管理の中に“保管庫別在庫管理”が置かれており，対応方針の「温度帯別管理の強化を基本に在庫管理精度の向上を図る」もこれを指している。
15字と短いので，「保管庫ごと」と「在庫管理機能」の二語を残す。解答例は「保管庫ごとの在庫管理機能」で12字。
設問2
35字以内
倉庫管理システム及び配送管理システムにおいて，トレーサビリティを一貫して確保するために，システムでどのような対応をすべきか。35 字以内で述べよ。
解答例
トレース対象品に識別子を割り当て，トレース対象品の動きを記録し関連付けることを，適切に記述していること 〔備考〕解答の要点を示す
解説
本文の根拠
表 共通業務
トレーサビリティの確保は今後の必須課題である。荷主からの入荷から，商品の保管，仕分，包装，配送先への納品まで，トレース対象品を追跡できるようにしたい。
各業務のシステムでの対応方針 (3) ①
トレーサビリティへの対応として，荷主からの入荷から，商品の保管，仕分，包装，配送先への納品まで，倉庫管理システム及び配送管理システムで追跡できるようにする。
トレーサビリティは，入荷から保管，仕分，包装，納品までの各段階で，同じトレース対象品がどこでどう扱われたかをたどれることである。倉庫管理システムと配送管理システムという二つのシステムをまたいで一貫して追跡するには，まず個々のトレース対象品を見分けられるように識別子を割り当て，各段階での動き（入荷，保管，仕分，包装，納品）をその識別子で記録し，前後の記録を関連付けておく必要がある。
解答例は“解答の要点”として示されており，識別子の割当て，動きの記録，関連付けの三つを記述していることが求められている。講評によれば，“一貫して管理する”“追跡可能にする”だけの解答が散見されたが，システムで対応する“手段”“方法”にも触れる必要がある。本文の言葉を繰り返すだけでは答えにならない。
35字に収めるには，三つの要素を短い動詞でつなぐ。例えば「トレース対象品に識別子を付け，各工程での動きを記録して関連付ける」なら32字。解答の要点の文は採点の観点を述べたもので，51字ある。
採点講評（IPA）
設問2は，正答率が高かった。“一貫して管理する”，“追跡可能にする”だけの解答が散見されたが，少なくともシステムアーキテクトの視点として，システムで対応する“手段”，“方法”にも，触れる必要がある。
設問3(1)
30字以内
運行管理において C 社のシステムを活用することが，今後 X 社から配送を請け負うことの強みになる理由は何か。30 字以内で述べよ。
解答例
X社の要請である，納品時間遅れ解消に対応できるから
解説
本文の根拠
〔C 社の現行業務システム概要〕(3)
車両にはすべて，GPS 対応車載端末を搭載している。これによって道路混雑時に迂回路を指示して納品遅れを回避する効果を上げている。
表 配送業務
X 社の製品配送を請け負うに当たり，X 社からは道路混雑などによる納品遅れの解消が求められている。
各業務のシステムでの対応方針 (2) ②
運行管理において，車両位置管理の機能は，B 社が利用しているソフトウェアパッケージにはなく，今後 X 社からの配送を請け負うことの強みになるので，C 社のシステムを組み込むこととする。
X 社は配送を任せるに当たり，道路混雑などによる納品遅れの解消を求めている。C 社の配送関連システムは，GPS 対応車載端末で車両の位置を把握し，道路混雑時に迂回路を指示して納品遅れを回避する効果を上げている。この車両位置管理の機能は B 社のパッケージには無い。C 社のシステムを組み込めば，X 社の要請にそのまま応えられることが強みになる。
設問は“強みになる理由”を問うているので，X 社の要請（納品遅れの解消）と C 社のシステムの効果（迂回路の指示による回避）を結び付ける。
30字で「X 社の要請」「納品遅れ解消に対応できる」を理由の形にする。解答例は「X社の要請である，納品時間遅れ解消に対応できるから」で25字。
設問3(2)
解答欄2つ
合併後の物流コスト管理システムの構築に当たって，システムで重点的に対応すべき機能を二つ挙げ，それぞれ 15 字以内で述べよ。
〔備考〕このうち異なる二つを答える（順不同）
解説
本文の根拠
〔C 社の現行業務システム概要〕(5)
配送コストは，人件費，燃料費など費目別に月単位で把握している。
表 共通業務
物流コスト管理においては，原価が手作業での集計なので，きめ細かい管理ができていない。配送，保管，荷役などの活動要素別の原価実績把握と，活動要素別の原価差異分析ができるようにしたい。
各業務のシステムでの対応方針 (3) ②
X 社の物流部門と共同で検討している，倉庫業務及び配送業務の活動要素別の原価計算を前提に，物流コスト管理のシステム化を図る。
物流コスト管理の課題は，原価を手作業で集計しているためにきめ細かい管理ができないことである。要望は，配送・保管・荷役などの活動要素別に原価の実績を把握することと，活動要素別に原価差異を分析することの二つで，対応方針も活動要素別の原価計算を前提にシステム化するとしている。したがって，システムで重点的に対応すべき機能は“活動要素別の原価実績把握”と“活動要素別の原価差異分析”になる。
現状の C 社は配送コストを人件費，燃料費などの費目別に把握しているだけで，活動要素別にはなっていない。講評によれば，“活動要素別”というキーワードを明示していない解答が多かった。単に“原価実績の把握”と書くと，今の費目別の把握と区別が付かない。
各15字なので，「活動要素別の」を必ず残し，後ろを「原価実績把握」「原価差異分析」と体言止めにする。解答例はどちらも12字。①②は順不同。
採点講評（IPA）
設問3(2)は，“活動要素別”というキーワードを明示していない解答が多かった。
設問4
解答欄3つ
会計システムに関して，合併後の一般会計処理で，自動仕訳データとして図の“財務管理”に渡すべき会計上の取引が発生している業務は何か。図の“財務管理”と同一レベルの業務名で，三つ挙げよ。
〔備考〕このうち異なる三つを答える（順不同）
解説
本文の根拠
各業務のシステムでの対応方針 (3) ③
財務管理の一般会計処理へは，会計上の取引発生元の業務システムから，自動仕訳で仕訳データを渡す。
図 合併後の全体業務構成
物流コスト管理（・配送コスト管理 ・倉庫コスト管理），財務管理（・一般会計処理 ・収支管理），労務管理（・シフト管理 ・勤怠管理 ・給与計算），受注管理（・入荷オーダ処理 ・出荷オーダ処理 ・配送オーダ処理），売上請求管理（・保管荷役料計算 ・運賃計算 ・売上処理 ・請求処理）
各業務のシステムでの対応方針 (3) ⑤
売上請求管理において，保管料，荷役料，運賃などの計算，売上処理，請求処理までを，合併後のすべての請求先に対して行う。
一般会計処理には，会計上の取引が発生した業務から自動仕訳で仕訳データを渡す。図の“財務管理”と同じレベルの業務（下線の付いた業務名）のうち，会計上の取引が発生するのは，売上処理・請求処理で売上を計上する売上請求管理，給与計算で人件費を計上する労務管理，配送・倉庫のコストを原価として計上する物流コスト管理の三つである。
受注管理はオーダを受け付けて倉庫・配送業務に指示を出す業務で，受注した時点では売上も費用も発生していない。講評によれば，設問4は正答率が高かったが，誤った解答の中に“受注管理”が散見された。企業取引活動の中で，会計上の取引として認識すべきものとそうでないものを区別する必要がある。
字数制限の無い設問で，図の業務名で三つ答える。“給与計算”や“売上処理”のような下位の項目ではなく，同一レベルの業務名で書く。①〜③は順不同。
採点講評（IPA）
設問4は，正答率が高かった。誤った解答の中に“受注管理”の解答が散見されたが，企業取引活動の中で会計上の取引として認識すべきものとそうでないものを，明確に理解しておいてもらいたい。
出典：平成21年度 秋期 システムアーキテクト試験 午後Ⅰ 問2（表記を一部改変）
問3 システム開発のテスト計画
システム開発のテスト計画に関する次の記述を読んで，設問1〜4に答えよ。
E 社は，リース業向けのソフトウェアパッケージ（以下，パッケージという）を自社で開発し，販売している。このたび，F 社向けにカスタマイズ開発を行うことになった。現在，システム結合テストを実施中であり，並行してシステム適格性確認テストの計画書を作成している。
〔パッケージの機能〕
E 社が開発したパッケージの機能は，次のとおりである。
リース物件について，契約先への見積書の作成，契約書の作成，仕入先への発注書の作成を行う。リース期間は，4 年又は 5 年とする。
契約先あての請求書を，月次処理で作成する。銀行からの入金データを受け取り，請求データとの照合を行う。
翌々月にリース期間満了となる契約について，契約先への満了通知書兼再リース契約申請書を，月次処理で作成する。契約先から再リース契約の申請があれば，契約情報を入力し，再リース契約書を作成する。
会計システムに渡す経理仕訳データを，月次処理で作成する。
契約先及び仕入先の属性項目の登録・変更を行う。
解約，物件処分，営業統計，年次集計などの処理を行う。
〔カスタマイズの内容〕
E 社では，パッケージの仕様と F 社業務とのフィットギャップ分析の結果を基に，パッケージのカスタマイズを行った。カスタマイズの内容は，次のとおりである。
(1) 契約情報の属性項目の追加 (2) 見積書，契約書などの出力帳票の書式の変更，及び一部帳票への項目の追加 (3) 経理仕訳データの勘定科目及びフォーマットの変更 〔サイクルテストの計画〕
E 社では，システム適格性確認テストとして，カスタマイズを行わなかった機能を含めたシステム全体の機能について，日々の業務が確実に遂行できることを確認するサイクルテスト，性能及び耐障害性を確認する性能・障害テストなどを行う。
カスタマイズ開発のプロジェクトマネージャである G 氏は，サイクルテストの責任者として H 氏を任命し，サイクルテストの計画を作成するよう命じた。
H 氏は，サイクルテストの計画を作成するのは初めてであり，過去の事例を参考にしながらテスト計画書，運営要領書及び進捗管理表を作成した。サイクルテストの計画の作成に当たっては，次の点を考慮した。
(1) H 氏は，サイクルテストの責任者として，テストケースやテストスケジュールの承認を行い，テスト期間中は，当日のテストの開始，終了などの判断を行う。また，H 氏を補佐する管理チームを設置し，管理チームで進捗管理や課題管理を行う。 (2) テストの体制は，管理チームのほか，契約，料金回収などのパッケージの機能ごとに六つの機能検証チーム，テストのオペレーションを実行する実行チーム，テスト環境を維持・管理する環境チームの編成とする。各機能検証チームは，テストケースの作成，テスト結果の検証と発生した障害への対応を行う。 (3) 管理チームは，毎日，テスト開始前に行う朝会と，テスト終了後に行う夕会を主催する。朝会，夕会には，各チームのリーダとサブリーダが出席し，管理チームは，各チームからテストの状況や障害対応の状況の報告を受け，また，各チームへテストに関する指示を伝える。 (4) 各チームのリーダ及びサブリーダは，朝会，夕会での指示を，自チームのメンバ全員に周知させるとともに，自チームメンバが担当するタスクの状況を把握する。また，自チーム内で発生した障害について，障害管理票を用いて管理し，障害の対応状況については障害の対応担当者から報告を受け，その内容を把握する。 H 氏が作成したテスト計画書の概要の抜粋を表 1 に，運営要領書の概要の抜粋を表 2 に，進捗管理表を表 3 に示す。
表1 H 氏が作成したテスト計画書の概要（抜粋）
表2 H 氏が作成した運営要領書の概要（抜粋）
表3 H 氏が作成した進捗管理表
〔テストデータ作成の方式の検討〕
H 氏は，サイクルテストで使用するテストデータのうち，取引先データ及び契約データの作成の方式について，次の二つの方式の比較検討を行った。
方式 1：F 社が現在の業務で使用している取引先データ及び契約データを，一部の項目のマスク処理や形式の変換など，必要な措置を行って使用する。 方式 2：契約データは，テストの中で，新システムの契約機能の新規登録操作によって登録していく。その契約データを登録するために必要な取引先データは，テストケースに合わせて，ツールを用いて，あらかじめ作成しておく。 二つの方式の比較検討結果の抜粋を，表 4 に示す。
表4 二つの方式の比較検討結果（抜粋）
H 氏は，これらを検討した結果，方式 2 を採用することを決定した。
〔サイクルテスト計画のレビュー〕
テストデータ作成の方式が決定され，テスト計画書が完成されたのを受けて，G 氏がサイクルテスト計画のレビューを実施し，次の問題点を指摘した。
(1) 今回決定した方式でテストデータを作成すると，システム全体の機能を確認する上で，システム日付の設定に問題がある。 (2) サイクルテストを円滑に運営する上で，障害発生時の対応に問題がある。 出題趣旨（IPA）
業務システムの開発に当たっては，ソフトウェアパッケージを導入し，その一部にカスタマイズを行って自社業務に適合させることが増加してきている。システムのサービスインを成功裏に迎えるためには，システム適格性確認テストを正しく計画し，実施，管理していくことが重要である。システムアーキテクトには，システム適格性確認テストを計画し，実施する能力が求められており，テストの計画と管理を行い，システム移行及び受入れテストで利用者を支援することが期待されている。本問では，ソフトウェアパッケージのカスタマイズ開発を例に取り，システムアーキテクトに要求されているシステム適格性確認テストの計画作成能力を評価する。
採点講評（問全体・IPA）
問3では，ソフトウェアパッケージのカスタマイズ開発を例にとり，システム適格性確認テストで行うサイクルテストのテスト計画について出題した。
全体として，問題文に記述された背景や計画書，運営要領書の理解不足と思われる解答が目に付いた。システム適格性確認テストの実施はシステムアーキテクトの主要業務の一つであり，理解を深めてもらいたい。
設問と解答例
設問1(1)
解答欄2つ
表 1 中のa ，表 2 中のb に入れる適切な確認事項を，それぞれ 25 字以内で述べよ。
解説
本文の根拠
問3 冒頭
E 社は，リース業向けのソフトウェアパッケージ（以下，パッケージという）を自社で開発し，販売している。
〔カスタマイズの内容〕
E 社では，パッケージの仕様と F 社業務とのフィットギャップ分析の結果を基に，パッケージのカスタマイズを行った。
表1 テストの実施と検証の内容
契約，料金回収，再リースなど，一連の業務を実際の業務の流れに沿って行い，ユーザ要件どおりに動作することを確認する。カスタマイズを行っていない機能についてはa を含めて確認する。
表2 夕会の開催
また，各チームで管理している障害管理票の中に当日が対応期限になっている障害があれば，その状況を，そのチームのリーダに確認する。
表2 進捗管理
障害は対応期限を明確にして管理されており，障害が発生したテストケースは，障害が解決するまで確認完了とはしない。
a：カスタマイズを行っていない機能は，フィットギャップ分析で F 社業務にそのまま合うとされた，パッケージ本来の機能である。これらの機能の“正しい動作”はパッケージの仕様で決まっているので，ユーザ要件どおりかに加えて，パッケージの仕様どおりに動作することも確かめる。
b：朝会で H 氏は，障害管理票の報告を基に当日のテストが開始できるかを判断する。障害は対応期限を明確にして管理され，夕会では当日が対応期限の障害を当日中に終わらせるよう指示している。つまり，当日から始まるテストの前提になるのは，対応期限が到来した障害がきちんと解決していることである。これが確認できなければ，その障害にかかわるテストを始められない。講評によれば，a については，“日々の業務が確実に遂行できることを確認する”“性能及び耐障害性を確認する”のように，問題文にあるシステム適格性確認テスト全体の目的を記入しただけの解答が散見された。
各25字。a は「パッケージの仕様どおりに動作すること」で18字，b は「対応期限が到来している障害が解決していること」で22字。空欄の後ろが「を含めて確認する」「を確認し」なので，“〜こと”で終える。
採点講評（IPA）
設問1(1)aは，カスタマイズしなかった機能についてどういう観点でテストを行うかを問う設問であったが，“日々の業務が確実に遂行できることを確認する”，“性能及び耐障害性を確認する”という，問題文に書いてあるシステム適格性確認テスト全体の目的を記入しただけの解答が散見された。
設問1(2)
解答欄2つ
障害管理票には，表 2 に従ってテストを進めていくために必要不可欠な項目がある。表 2 中のc ，d に入れる適切な字句を答えよ。
〔備考〕cとdは順不同
解説
本文の根拠
表2 障害発生時の対応と管理
その後，原因，対応の要否，対応の内容，予定工数，優先度，c ，d を追記する。
表2 進捗管理
障害は対応期限を明確にして管理されており，障害が発生したテストケースは，障害が解決するまで確認完了とはしない。
表2 夕会の開催
もし，対応が終了していない障害があれば，記載された対応担当者に当日中に対応を終了させるよう，そのリーダに指示する。
表2の運営要領書は，障害を“対応期限”で管理し，夕会では当日が対応期限の障害について，“記載された対応担当者”に当日中に対応を終了させるよう指示するとしている。この運営を回すには，障害管理票に対応期限と対応担当者が書かれていなければならない。
障害管理票の既に挙がっている項目（原因，対応の要否，対応の内容，予定工数，優先度）には，この二つが無い。表2のほかの行が前提にしている情報を，空欄に当てはめる。
字数制限の無い設問で，c と d は順不同。表2 の中の言葉（“対応期限”“対応担当者”）をそのまま使う。
設問2
解答欄1つ
〔テストデータ作成の方式の検討〕について，表 4 中のe に入れる適切な字句を 30 字以内で述べよ。
解説
本文の根拠
〔テストデータ作成の方式の検討〕方式 1
F 社が現在の業務で使用している取引先データ及び契約データを，一部の項目のマスク処理や形式の変換など，必要な措置を行って使用する。
〔テストデータ作成の方式の検討〕方式 2
その契約データを登録するために必要な取引先データは，テストケースに合わせて，ツールを用いて，あらかじめ作成しておく。
表1 テストケース
上記のスケジュールに従い，当日の業務やイベントごとに，実施するテストケースと得られるべき実行結果を，テストケース一覧表に記載する。
方式1は，F 社が現在の業務で使っているデータをそのまま使う。現行業務のデータは実際に起きた取引の記録なので，テストケースで確かめたい条件のデータがそろっているとは限らない。テストケースの中には，現行データに該当するものが無く，確認できない機能が出てくるおそれがある。方式2は取引先データをテストケースに合わせて作り，契約データもテストの中で登録していくので，テストケースに必要なデータを漏れなく用意できる。
表4の“機能の確認は十分にできるか”で方式1が×なのは，この違いによる。講評によれば，設問2は正答率が低く，個別の機能確認や境界値テストといった，システム結合テストまでに確認しておくべき項目を挙げた解答が多かった。問われているのは現行業務のデータを使う方式の問題点である。講評は“システム連結テスト”と書いているが，本文でいうシステム結合テストのことと読める。
30字で「テストケースを網羅するデータがない」ことを書く。空欄の前が「方式1は」なので主語は書かない。解答例は「テストケースを網羅するデータがない可能性がある」で23字。
採点講評（IPA）
設問2は正答率が低かった。現行業務のデータを用いてテストを実施する方式での問題点について記述してほしかったが，個別の機能確認や境界値テストといったシステム連結テストまでに確認しておくべき項目を挙げた解答が多かった。
設問3
解答欄2つ
〔サイクルテスト計画のレビュー〕において G 氏が指摘した二つの問題点について，具体的にどのような問題が発生するかを，それぞれ 40 字以内で述べよ。
〔システム日付の設定に関する問題点〕解答例
想定している1年分のシステム日付では再リース機能の確認ができない。
〔障害発生時の対応に関する問題点〕解答例
他チームに影響が及ぶ重大な障害の発生時に，即座に情報が連携されない。
解説
本文の根拠
〔パッケージの機能〕(1) 契約機能
リース期間は，4 年又は 5 年とする。
〔パッケージの機能〕(3) 再リース機能
翌々月にリース期間満了となる契約について，契約先への満了通知書兼再リース契約申請書を，月次処理で作成する。
〔テストデータ作成の方式の検討〕方式 2
契約データは，テストの中で，新システムの契約機能の新規登録操作によって登録していく。
表1 テストの日付とスケジュール
システム上の日付（以下，システム日付という）を年度の初日に当たる 4 月 1 日に設定し，最初の 1 週間は，システム日付を 1 日ずつ進める。その後は，月次処理，年次処理などのイベントに合わせてシステム日付を設定し，翌年度 4 月に行う年次集計処理まで行う。
〔サイクルテストの計画〕(2)
テストの体制は，管理チームのほか，契約，料金回収などのパッケージの機能ごとに六つの機能検証チーム，テストのオペレーションを実行する実行チーム，テスト環境を維持・管理する環境チームの編成とする。
表2 障害発生時の対応と管理
テスト結果の検証において障害が発見された場合，機能検証チームのリーダが障害管理票を起票し，チーム内で管理する。
システム日付の設定：方式2では，契約データはテストの中で新規登録していくので，どの契約もテスト期間中に始まったものになる。リース期間は4年か5年で，再リース機能は翌々月に満了となる契約を対象に動く。ところがテストのシステム日付は4月1日から翌年度4月までの1年分しかないので，新規登録した契約は満了に近づかず，再リース機能を確認できない。
障害発生時の対応：サイクルテストは契約，料金回収，再リースなどの一連の業務を流れに沿って行うので，ある機能の障害が後続の機能を受け持つ他チームのテストにも影響する。ところが障害は機能検証チームのリーダがチーム内で管理し，他チームに伝わるのは朝会・夕会での報告の場だけである。重大な障害が起きても，すぐに情報が連携されず，他チームが誤った結果のままテストを進めてしまうおそれがある。講評によれば，設問3は表1のシステム日付の設定，表2の障害発生時の対応をきちんと理解すれば正解を導けるが，正答率は低かった。
それぞれ40字で，「どの機能が／どんな場合に」と「何ができない」を一文にする。解答例は「想定している1年分のシステム日付では再リース機能の確認ができない。」が33字，「他チームに影響が及ぶ重大な障害の発生時に，即座に情報が連携されない。」が34字。
採点講評（IPA）
設問3は，テスト計画の問題点に関する設問であった。表1のシステム日付の設定，表2の障害発生時の対応をきちんと理解すれば，それぞれ正解を導ける問題であったが，正答率は低かった。本来のあるべきテスト計画を念頭において，“何が問題なのか”を正しく読み取ってほしかった。
設問4(1)
解答欄2つ
テストケースの確認が，予定したスケジュールに遅れることなく進んでいることの判断
解説
本文の根拠
表3
第 n 日の行は，テストケース確認完了件数の予定がイ，予定累計がウ，実績がエ，実績累計がオ，
表2 進捗管理
進捗管理表には，あらかじめ，テストケースの総件数と毎日の確認完了予定件数を記入しておく。
表1 テストの日付とスケジュール
当日までのテストケースのすべてについて正しい結果が得られたことを確認できた場合には，翌日以降に予定されたテストを前倒しして行うことがある。
予定したスケジュールに遅れていないかは，ある時点までに確認完了した件数の累計が，その時点までの予定の累計に達しているかで判断できる。表3では，予定累計がウ，実績累計がオなので，オがウ以上であれば遅れていない。
日ごとの予定（イ）と実績（エ）で比べると，前日までの遅れや前倒しが反映されない。テスト計画書は予定のテストを前倒しすることを認めているので，実績累計が予定累計を上回ることもあり，“等しい”ではなく“以上”になる。講評によれば，設問4は正答率が高かった。
数値は記号二つ，大小関係は15字で書く。解答例は「オがウ以上であるとき」で10字。
採点講評（IPA）
設問4は，テスト進捗の判断を問う設問であったが，正答率が高かった。
設問4(2)
解答欄2つ
サイクルテストが完了していることの判断
解説
本文の根拠
表3
注 アはテストケースの総件数，イ〜ケはある時点での予定又は実績の件数
表2 進捗管理
それぞれのテストケースについて，結果が正しいことが確認できたら確認完了とする。障害は対応期限を明確にして管理されており，障害が発生したテストケースは，障害が解決するまで確認完了とはしない。
サイクルテストが完了したといえるのは，すべてのテストケースが確認完了になったときである。表3では，総テストケース数がア，確認完了件数の実績累計がオなので，アとオが等しければ完了と判断できる。
障害が発生したテストケースは，障害が解決するまで確認完了にしない。したがって，実績累計オには未解決の障害を抱えたテストケースは含まれず，障害発生件数や解決件数（カ〜ケ）を別に見なくても，オだけで完了を判断できる。予定累計（ウ）との比較では，予定どおり進んだかは分かっても，全件を終えたかは分からない。
数値は記号二つ，大小関係は15字で書く。解答例は「アとオが等しいとき」で9字。
採点講評（IPA）
設問4は，テスト進捗の判断を問う設問であったが，正答率が高かった。
出典：平成21年度 秋期 システムアーキテクト試験 午後Ⅰ 問3（表記を一部改変）
問4 新入退室管理システムの開発
新入退室管理システムの開発に関する次の記述を読んで，設問1〜4に答えよ。
J 社は，定められた区画に，許可された人だけが入退室できるようにするための入退室管理システムを製造・販売している。これまでは，個別の企業，事業所などの入退室管理システムを，利用者の要望に合わせて構築していた。今回は，大規模賃貸オフィスビル向けの新入退室管理システム（以下，新システムという）を企画し，要件定義を行った。この新システムは，複数のテナントが入っているオフィスビル全体を対象とし，各テナント個別の入退室管理を実現する。
テナントは，1 区画だけを使う場合から，フロアを越えて複数の区画を使う場合まで多様である。このため新システムでは，テナント単位に専有する区画（以下，専有エリアという）を柔軟に変更できる方式を検討する。テナントの専有エリアと区画との関係を図 1 に示す。
図1 テナントの専有エリアと区画との関係
〔既存の個別企業向け入退室管理システムの概要〕
既存の個別企業向け入退室管理システム（以下，既存システムという）の構成を図 2 に示す。既存システムでは，必要な数の認証端末及び電気錠が設置され，専用配線を介して 1 台の入退室コントローラと個別に接続されている。入退室コントローラは，あらかじめ記録された認証データを保持し，認証端末からの入力データと認証データとを照合して，認証に成功したら対応するドアの電気錠を開錠する。システムの管理者は，入退室コントローラに接続された運用端末を操作して，入室許可者の登録及び認証データの登録を行う。
図2 既存システムの構成
〔新システムの要件〕
新システムの開発に当たり，次に示す要件がシステムアーキテクトに提示された。システムアーキテクトには，これらの要件を検討し，新システムの機能仕様を決定することが求められている。
テナントの要求に応じて，認証端末は複数種類から選択できる。 区画ごとに入退室コントローラを 1 台設置する。 1 区画は，上限はあるが，複数のドアをもつことができる。1 ドア単位の入退室管理も，複数のドアをまとめた入退室管理もできる。さらに，専有エリアが複数区画となる場合は，入退室コントローラを連携させることで，複数区画をまとめた入退室管理も行うことができる。 テナントの入替りによって，専有エリアの区画や認証方式を変更しなければならない場合にも，ドアの新設がなければ，認証端末，電気錠などと入退室コントローラの間の配線工事やインタフェースの変更が不要で，短時間で対応できるようにする。 運用端末をテナントごとに 1 台設置する。テナントの管理者が運用端末を操作して，入室許可者の登録及び認証データの登録を行う。 入退室履歴を残すことを標準機能に含めるものとする。入退室履歴は，ドアの開閉を行ったときの日時，ドア番号，入退室者などのデータであり，履歴の参照には運用端末を用いる。 新システム全体の管理や監視のためにシステム管理端末を設置する。 これからのオフィスビルでは，入退室管理システムの情報を利用することによるビルの省エネルギー化，警備の自動化など，ビル設備を監視・制御するシステムの統合運用を進めることが求められている。新システムには，それらに対応できる機能をもたせる。 出題趣旨（IPA）
組込みシステムの開発においては，企画・開発計画に基づき，システムの要件を調査・分析し，機能仕様を決定することが求められる。本問は，入退室管理システムを例にとり，要件の分析に基づいた機能仕様の策定，システムアーキテクチャの決定などについて，具体的な解答を求めている。本問では，組込みシステムの機能仕様策定に携わるシステムアーキテクトに求められる，要件を分析し，機能仕様やシステムアーキテクチャを決定する能力を評価する。
採点講評（問全体・IPA）
問4では，入退室管理システムを例にとり，組込み分野の問として機能仕様の策定，システムアーキテクチャの決定について出題した。全体として，題意はよく理解されていたようであった。
設問と解答例
設問1
45字以内
新システムの要件を検討した結果，専有エリアごとの入退室管理を容易に実現でき，専有エリアの区画の変更に柔軟に対応できるアーキテクチャを提供することが主要な課題であることが明らかとなった。この課題にこたえるために，入退室コントローラ及び運用端末はどのようなインタフェースで接続するのが適切か。45 字以内で述べよ。
解答例
すべての入退室コントローラ及び運用端末を，ビル内に配線したLANで接続する。
解説
本文の根拠
問4 冒頭
この新システムは，複数のテナントが入っているオフィスビル全体を対象とし，各テナント個別の入退室管理を実現する。
〔既存の個別企業向け入退室管理システムの概要〕
既存システムでは，必要な数の認証端末及び電気錠が設置され，専用配線を介して 1 台の入退室コントローラと個別に接続されている。
〔新システムの要件〕
さらに，専有エリアが複数区画となる場合は，入退室コントローラを連携させることで，複数区画をまとめた入退室管理も行うことができる。
〔新システムの要件〕
運用端末をテナントごとに 1 台設置する。テナントの管理者が運用端末を操作して，入室許可者の登録及び認証データの登録を行う。
新システムでは入退室コントローラを区画ごとに1台置き，専有エリアが複数区画にまたがる場合はコントローラ同士を連携させる。専有エリアはフロアを越えることもあり，テナントの入替りで区画の組合せも変わる。運用端末はテナントごとに1台で，そのテナントの専有エリアに属するコントローラすべてに登録を行う必要がある。既存システムのように専用配線で1台ずつ個別につなぐと，専有エリアが変わるたびに配線をやり直すことになる。
ビル内に配線した LAN で，すべての入退室コントローラと運用端末をつないでおけば，どのコントローラ同士でも，どの運用端末とでも通信できる。専有エリアの変更は，配線ではなくどの機器を同じ専有エリアとして扱うかという設定の変更で済む。講評によれば，設問1は正答率が高かったが，専有エリア内だけを対象とする解答も散見された。新システムはビル全体を対象とするので，接続の範囲もビル全体になる。
45字で「すべての」「ビル内の LAN で接続する」を書く。解答例は「すべての入退室コントローラ及び運用端末を，ビル内に配線したLANで接続する。」で38字。
採点講評（IPA）
設問1は，入退室コントローラ及び運用端末の接続インタフェースについて問うた。正答率は高かったが，専有エリア内だけを対象とする解答も散見された。ビル全体を対象とするシステムであることに着目してほしかった。
設問2(1)
20字以内
システム管理端末で上記の変更を柔軟に行うために必要な情報は何か。20 字以内で述べよ。
解答例
解説
本文の根拠
問4 冒頭
テナントは，1 区画だけを使う場合から，フロアを越えて複数の区画を使う場合まで多様である。このため新システムでは，テナント単位に専有する区画（以下，専有エリアという）を柔軟に変更できる方式を検討する。
〔新システムの要件〕
区画ごとに入退室コントローラを 1 台設置する。
〔新システムの要件〕
新システム全体の管理や監視のためにシステム管理端末を設置する。
専有エリアは，テナントが専有する区画の集まりである。入退室コントローラは区画ごとに置かれるので，専有エリア単位の入退室管理を行うには，どの区画がどの専有エリアに属するかが分かっていなければならない。テナントの入替りなどで専有エリアの区画が変わるときも，変わるのはこの対応だけである。
システム管理端末で各区画と専有エリアの対応情報を持っておけば，専有エリアの変更はこの対応を書き換えることで柔軟に行える。講評によれば，設問2は正答率が高かったが，専有エリアの区画変更にシステム管理端末がどのように関与するかという視点が欠けている解答も見られた。
20字で「区画」と「専有エリア」の「対応情報」を書く。解答例は「各区画と専有エリアの対応情報」で14字。
採点講評（IPA）
設問2は，正答率が高かった。専有エリアの区画変更に，システム管理端末がどのように関与するかという視点が欠けている解答も見られた。
設問2(2)
40字以内
(1)で述べた情報を用いて，専有エリア単位の入退室管理を実現するためにシステム管理端末にもたせるべき機能は何か。40 字以内で述べよ。
解答例
各入退室コントローラへ，対応する専有エリアの情報を配信する機能
解説
本文の根拠
〔新システムの要件〕
区画ごとに入退室コントローラを 1 台設置する。
〔新システムの要件〕
さらに，専有エリアが複数区画となる場合は，入退室コントローラを連携させることで，複数区画をまとめた入退室管理も行うことができる。
〔新システムの要件〕
新システム全体の管理や監視のためにシステム管理端末を設置する。
入退室の照合や開錠は区画ごとの入退室コントローラが行う。専有エリアが複数区画にまたがるときは，コントローラ同士を連携させてまとめて管理する。そのためには，各コントローラが，自分の区画がどの専有エリアに属し，どのコントローラと連携すればよいかを知っていなければならない。
システム管理端末は(1)の区画と専有エリアの対応情報を持っているので，これを基に，各入退室コントローラへ対応する専有エリアの情報を配信すれば，コントローラ側で専有エリア単位の入退室管理ができる。専有エリアが変わったときも，配信し直すだけで済む。
40字で「各入退室コントローラへ」「専有エリアの情報を配信する機能」を書く。解答例は「各入退室コントローラへ，対応する専有エリアの情報を配信する機能」で31字。
採点講評（IPA）
設問2は，正答率が高かった。専有エリアの区画変更に，システム管理端末がどのように関与するかという視点が欠けている解答も見られた。
設問3
50字以内
認証データの管理について検討する。照合処理は，既存システムと同様に，入退室コントローラで行うことにする。新システムでは，認証データの管理面で注意すべきことは何か。50 字以内で述べよ。
解答例
認証データを各入退室コントローラで保持するので，データの一元管理が必要になる。
解説
本文の根拠
〔既存の個別企業向け入退室管理システムの概要〕
入退室コントローラは，あらかじめ記録された認証データを保持し，認証端末からの入力データと認証データとを照合して，認証に成功したら対応するドアの電気錠を開錠する。
〔新システムの要件〕
区画ごとに入退室コントローラを 1 台設置する。
〔新システムの要件〕
運用端末をテナントごとに 1 台設置する。テナントの管理者が運用端末を操作して，入室許可者の登録及び認証データの登録を行う。
〔新システムの要件〕
テナントの入替りによって，専有エリアの区画や認証方式を変更しなければならない場合にも，
照合を入退室コントローラで行う以上，各コントローラは照合に使う認証データを保持する。新システムではコントローラが区画ごとにあるので，専有エリアが複数区画にまたがるテナントでは，同じ認証データが複数のコントローラに分散して置かれる。テナントの管理者は運用端末1台から登録するので，登録・変更・削除がすべてのコントローラに正しく行き渡らないと，区画によって入れる人が食い違う。専有エリアの区画が変わったときも，コントローラの認証データを入れ替える必要がある。
したがって，分散して保持される認証データを一元管理することが必要になる。講評によれば，設問3は区画変更を考慮して認証データをどう管理すべきかを問うたが，データのセキュリティ面だけを述べた解答が散見された。区画ごとにコントローラを置き，専有エリアが変わるという新システムの特徴に着目する。
50字で「各コントローラで保持する」という原因と「一元管理が必要」という注意点を書く。解答例は「認証データを各入退室コントローラで保持するので，データの一元管理が必要になる。」で39字。
採点講評（IPA）
設問3は，区画変更を考慮して，認証データをどのように管理すべきかを問うたが，データのセキュリティ面だけを述べた解答が散見された。新システムの特徴を踏まえた認証データの管理を問うていることに着目してほしかった。
設問4
20字以内
ビル内の他システムとの連携機能について検討する。空調・照明制御システムによる省エネルギー化を進めるために，新システムの情報を利用することを検討している。その場合，新システムはどのような情報を提供すべきか。20 字以内で述べよ。
解答例
解説
本文の根拠
〔新システムの要件〕
入退室履歴を残すことを標準機能に含めるものとする。入退室履歴は，ドアの開閉を行ったときの日時，ドア番号，入退室者などのデータであり，
〔新システムの要件〕
これからのオフィスビルでは，入退室管理システムの情報を利用することによるビルの省エネルギー化，警備の自動化など，ビル設備を監視・制御するシステムの統合運用を進めることが求められている。
〔新システムの要件〕
区画ごとに入退室コントローラを 1 台設置する。
空調・照明の省エネルギー化は，人がいない場所の空調や照明を止めたり弱めたりすることで進められる。新システムは入退室履歴として，いつ，どのドアで，誰が出入りしたかを記録しているので，区画ごとに今だれかが中にいるか（有人か無人か）が分かる。これを空調・照明制御システムに提供すれば，無人の区画の空調・照明を制御できる。
入退室コントローラは区画ごとに置かれるので，情報も区画の単位で提供するのが自然である。講評によれば，設問4は正答率が高かったが，温度情報などの提供を記述した解答が散見された。新システムの要件には温度情報に関するものは含まれていないので，入退室管理システムが持っている情報から考える。
20字で「区画ごとに」「有人か無人か」を書く。解答例は「区画ごとに有人か無人かの情報」で14字。
採点講評（IPA）
設問4は，正答率が高かった。誤った解答の中には，温度情報などの提供を記述した解答が散見されたが，新システムの要件には温度情報に関するものは含まれていない。機能仕様の策定においては，システムに求められる要件を前提にするよう心がけてもらいたい。
出典：平成21年度 秋期 システムアーキテクト試験 午後Ⅰ 問4（表記を一部改変）
