令和6年度 春期 午後Ⅰ

本文の根拠

〔A 社の業務の概要〕

A 社では，販売戦略上，製品を生産計画で定めた期日までに効率的に製造することが求められている。

〔A 社の業務の概要〕

各工程の製造指示は，期日に合わせて製造するためには遅くともいつから当該工程の製造を開始しなければいけないかを考えて，開始予定日時を決定した上で作成する。

〔A 社の業務の概要〕

翌々週の生産計画に基づいて，充填，殺菌，調合，仕込の順番で各工程の所要時間を計算し

設問が挙げた一つ目の理由は「数」の逆算である。後工程の投入指示数が決まらないと，前工程でその仕掛品をいくつ作ればよいかが決まらない。もう一つは「日時」の逆算である。A 社は製品を生産計画の期日までに仕上げる必要があり，各工程の製造指示には「遅くともいつから開始しなければいけないか」で決めた開始予定日時を書く。最後の充填の開始日時が決まって初めて，その前の殺菌がいつまでに終わればよいか，したがっていつ始めるかが決まる。だから期日から逆向きに，充填，殺菌，調合，仕込の順で作る。

本文の「期日に合わせて製造するためには遅くともいつから当該工程の製造を開始しなければいけないか」がそのまま答えの芯になる。講評のとおり，「期日までに製造するため」と本文を切り取るだけでは，なぜ後工程から作るのかが伝わらない。期日から逆算して開始日時を決める，という因果まで書く。

40字以内。解答例は35字で，「期日までに製造するため」「逆算して」「各工程の製造開始日時を決める」の三つを入れている。一つ目の理由（数の逆算）と区別するために，日時を決める話であることをはっきり書くのが要点である。

採点講評（IPA）

設問1(1)は正答率が低かった。製造指示及び投入指示を作成する際，充填，殺菌，調合，仕込の順番で作成している理由を問う問題であったが，単純に問題文の一部を切り取っただけで，後工程から先に作成している理由が不明確な解答が多かった。

本文の根拠

〔A 社の業務の概要〕

数に比例する工程は単位当たり所要時間，一定の時間を要する工程は固定の所要時間が，製造される品目ごとに決まっている。

表1 工程マスター

工程マスター：工場コード，工程コード（以上に下線），製造品目コード，工程名称，時間計算区分（“比例”，“一定”），所要時間。

表1 製造

製造：工場コード，製造開始予定年月日，工程コード（以上に下線），製造指示数，想定所要時間

工程マスターの「所要時間」は，時間計算区分によって意味が変わる。“比例”なら単位当たりの所要時間，“一定”なら数によらない固定の時間である。したがって“比例”は所要時間に製造する数を掛け，“一定”は所要時間をそのまま使う。掛ける数は，その工程で製造する数である製造ファイルの「製造指示数」を使う。

本文の「数に比例する工程は単位当たり所要時間，一定の時間を要する工程は固定の所要時間が…決まっている」が式の形を決め，表1の属性名が答えに使う言葉を決める。求める値は製造ファイルの「想定所要時間」である。

表1中の属性で書くよう指定されているので，「生産数」は使わない。生産数は生産計画ファイルの製品の数で，仕掛品の工程には当てはまらない。各工程が作る数は製造指示数である。解答例は「所要時間×製造指示数」と「所要時間」。

本文の根拠

〔A 社と B 社の品目と工程の概要〕

製品は製造後，直ちに出荷されるので在庫管理を行わない。また，仕掛品も製造後，直ちに次の工程に投入されるので在庫管理を行わない。原材料は表計算ソフトを用いて在庫管理を行っている。

〔A 社のシステムの概要〕

品目マスターでは，原材料，仕掛品，製品を区分するために，品目分類を設定して管理している。

〔システム統合の方針〕

製品の製造については現行どおりとするが，業務の運用もできるだけ A 社の運用に合わせる。

B 社の品目を在庫管理するかどうかは，品目分類で一律に決まる。製品は製造後すぐ出荷，仕掛品はすぐ次の工程に投入するので在庫管理をしない。原材料は表計算ソフトで在庫管理をしている。よって製品と仕掛品は“無”，原材料は“有”を設定する。

B 社の品目マスターにもともと無いフラグを，移行時に機械的に埋める規則が問われている。手掛かりは，B 社の品目も品目マスターで「原材料」「仕掛品」「製品」の品目分類を持つことである。分類ごとに在庫管理の有無が決まっているので，品目分類から値を決める規則が書ける。A 社のように仕掛品の中で品目ごとに分かれることはない。

30字以内。講評は“有”“無”の一方だけを書いた解答が多かったと述べている。規則である以上，どの場合に“有”でどの場合に“無”かの両方を書く。解答例は24字。

採点講評（IPA）

設問2(1)は正答率がやや低かった。属性の値として“有”，“無”がどのような場合に設定されるかを問う問題であったが，“有”，“無”の一方だけを記述した解答が散見された。システムの仕様を記述する際，何を書けば正しく伝わるかを意識してほしい。

本文の根拠

〔B 社の業務の概要〕

得意先からの受注に基づき，翌日の製品の生産予定数と翌日の製造の開始予定時刻及び終了予定時刻を，品目単位に立案する。一つの製品を，1 日に複数回製造する場合がある。

〔A 社の業務の概要〕

一つの品目は，1 日に 1 回まとめて製造する。

表1

投入：工場コード，製造開始予定年月日，工程コード，投入品目コード（以上に下線）

〔システム統合の方針〕

統合後の生産管理システムに，B 社の得意先からの受注データを基に，翌日の製造データ及び投入データを作成する機能を追加する。

A 社は一つの品目を1日に1回まとめて製造するので，製造ファイルの主キー（工場コード，製造開始予定年月日，工程コード）で1日1件に決まる。工程コードは製造品目も一意に決まるコードなので，これは「その品目のその日の製造」1件を表す。B 社には一つの製品を1日に複数回製造する場合があり，同じキーのレコードが同じ日に2件以上できてしまう。そこで，同じ日の何回目かを区別できる属性を主キーに足す必要がある。製造に対応する投入ファイルも同じ3項目に投入品目コードを加えたキーなので，同じ理由で足す。

対象を製造と投入に絞れるのは，方針が B 社については「受注データを基に，翌日の製造データ及び投入データを作成する」としているからである。B 社の製造は生産計画ファイルを経由しない。

要件は30字以内。解答例は「一つの製品を1日に複数回製造する場合があるという要件」で26字。本文の B 社の業務の記述をそのまま使えばよい。

本文の根拠

〔A 社のシステムの概要〕

仕入先へは，1 日に 1 回，A 社で定めた様式の発注書を添付して，電子メールで送信する。

〔B 社の業務の概要〕

発注書の様式は，各仕入先の要望に応じて表計算ソフトを用いて作成しており，複数の様式が存在する。

〔システム統合の方針〕

B 社の原材料調達業務を実施するに当たり，仕入先に変更点を説明して，仕入先に業務手続を変更してもらうよう依頼する。

A 社と B 社の調達の手順を並べると，どちらも最低在庫数を下回ったら発注書を電子メールで送る点は同じで，違うのは発注書の様式である。A 社のシステムは A 社で定めた一つの様式で発注書を作る。B 社は仕入先ごとの要望に合わせて複数の様式を使っている。統合後は A 社のシステムをそのまま使うので，B 社の仕入先には A 社の様式の発注書で受けてもらうよう依頼することになる。

方針に「B 社はできるだけ，A 社のシステムをそのまま用いる」「どうしても対応できない部分に対してだけ，改修や追加を行う」とある。様式の違いは仕入先に合わせてもらえば済むので，改修ではなく仕入先への依頼で片付ける，という筋になる。

25字以内。解答例は22字。「発注書の様式」「A 社で定めた様式」の二つを入れれば足りる。

本文の根拠

〔B 社の業務の概要〕

月次処理で，製造実績と投入実績の集計表を出力するために，月末に記録表を参照し，まとめて生産管理システムに入力しているが，転記ミスの発生が問題視されている。また，製造担当者の月末の入力作業の負荷が高いこと

〔A 社のシステムの概要〕

各工程の製造が終了した時点で，製造担当者がタブレット端末を用いて，製造データ，投入データの実績を登録する。

統合前の B 社では，製造担当者が記録表に手書きした実績を，月末にまとめて生産管理システムに入力していた。統合後は A 社のやり方になり，各工程の終了時点でタブレット端末から実績を登録する。月末にまとめて入力する作業がなくなり，入力が日々に分散したので「負荷が平準化された」。

「平準化」という言葉が手掛かりになる。月末に作業が集中していたことが本文の問題点として挙がっている（「製造担当者の月末の入力作業の負荷が高いこと」）。削減された作業は，その集中の原因である月末の一括入力である。

40字以内。解答例は36字で，「月末に」「記録表を参照し」「まとめて入力する」の三つを入れている。転記ミスの話は評価の1項目目で別に書かれているので，ここでは負荷の側から書く。

本文の根拠

〔B 社の業務の概要〕

本社管理部門で管理指標値が翌月にならないと確認できないことが問題となっている。

〔A 社のシステムの概要〕

また，夜間に工場の稼働率などの管理指標値を集計し，翌日に本社から参照可能にする。

統合前の B 社では，実績を翌月に集計して帳票で渡していたので，本社管理部門は翌月にならないと管理指標値を確認できなかった。統合後は A 社の生産管理システムが夜間に管理指標値を集計し，翌日に本社から参照できるようにする。実績も工程の終了時点で登録されるので，前日までの実績を反映した管理指標値が翌日には見られる。

講評が指摘するとおり，ここを「リアルタイムに確認できる」と書くのは誤りである。本文は「夜間に…集計し，翌日に本社から参照可能にする」と書いており，反映は日単位である。本文にある時間の単位をそのまま答えに使う。

30字以内。解答例は27字。「前日までの実績」「参照可能になった」で，翌月から翌日への変化を表している。

採点講評（IPA）

設問3(2)の正答率は平均的であった。B社が問題としていた“本社管理部門で管理指標値が翌月にならないと確認できないこと”が，システム統合によって“夜間に管理指標値を集計し，翌日に本社から参照可能になること”を答えてほしかったが，リアルタイムに反映されると誤解した解答が散見された。業務を正しく理解した上で情報システムを設計することの重要性を理解してほしい。

本文の根拠

〔E 社のカードローンの概要〕

口座から正常に引き落とすことができたかどうかを金融機関が E 社に連携するまでには数営業日掛かる（以下，この期間を口振結果営業日数という）。

〔現在の会員サービスと関連システムの概要〕

基幹システムでは，金融機関に口座振替を依頼し，金融機関から口座振替の結果を受領した日に借入残高を更新している。口振結果営業日数は金融機関によって異なるので，基幹システムの金融機関マスターで管理している。

〔現在の会員サービスと関連システムの概要〕(5)

各種情報照会画面には，実約定日も表示しており，会員は，次回の口座振替日を確認できる。

借入残高が更新されるのは，口座から引き落とした日（実約定日）ではなく，その結果を金融機関から受け取った日である。結果が届くまでの日数が口振結果営業日数なので，更新日は「次回の実約定日＋口振結果営業日数」で求まる。口振結果営業日数は金融機関ごとに違うので，会員の振替先口座がある金融機関の値を金融機関マスターから取って足す。

本文には材料が三つ散らばっている。実約定日の定義，口振結果営業日数の定義，そして基幹システムが「口座振替の結果を受領した日に借入残高を更新している」という記述である。講評は，この更新のタイミングを読み取れていない解答が多かったと述べている。実約定日をそのまま答えると，引き落としの日と残高の更新日を取り違えることになる。

40字以内。解答例は33字で，「次回の実約定日に」「振替先口座がある金融機関の」「口振結果営業日数を足す」の三つを入れている。どの金融機関の日数かを書かないと，金融機関によって異なるという本文の条件が生きない。

採点講評（IPA）

設問1は，正答率が低かった。現在の基幹システムで借入残高を更新しているタイミングを十分に理解していないと思われる解答が散見された。既存の情報システムの仕様を正しく理解した上で，機能を設計することが重要であることを理解してほしい。

本文の根拠

〔会員サービスに関わるシステム改善要望〕

解約を受け付けた会員に対しては，キャンペーンは実施しないこととする。解約を受け付けた後，フロントシステムで解約の取消は受け付けないこととし，会員情報，契約情報の変更及び新規の貸付けもフロントシステムではできないようにしてほしい。

〔現在の会員サービスと関連システムの概要〕(2)

会員は，フロントシステムを利用して，電話番号，メールアドレス，自宅住所，勤務先情報及び約定条件を変更することができる。

〔現在の会員サービスと関連システムの概要〕(8)

キャンペーンの対象となる会員に事務部門から電話で連絡し，キャンペーンの内容を説明している。

会員サービスは(1)〜(8)の八つある。改善要望が“解約予約”の会員に禁じたものを一つずつ消していく。各種変更サービスは会員情報と約定条件（契約情報）の変更なので不可。借入サービスは新規の貸付けなので不可。限度額の変更サービスは契約情報の限度額を変えるので不可。解約サービスは，すでに解約を受け付けており，取消も受け付けないので使う場面がない。キャンペーンサービスは実施しない。残るのは，お知らせサービス，各種情報照会サービス，問合せサービスの三つである。

消去の根拠はすべて改善要望の解約の項目にある。「会員情報，契約情報の変更及び新規の貸付け」ができないという一文で，各種変更・限度額の変更・借入の三つが同時に消える。限度額が契約情報に含まれることは，概要の「契約情報には，約定条件，契約商品，限度額，利率，契約ステータスなどが含まれる」で確かめられる。

字数制限はなく，「全て答えよ」なので漏れも余計なものも減点になりうる。キャンペーンサービスはフロントシステムの機能ではなく事務部門からの電話連絡である点も，外す理由になる。サービス名は本文の見出しどおりに書く。

本文の根拠

〔E 社のカードローンの概要〕

ただし，毎月の返済額が利息より少なくならないように，またボーナス月の変更の際にはボーナス月が 1 年に 3 回以上とならないように調整している。

〔現在の会員サービスと関連システムの概要〕(2)

約定条件の変更でボーナス月を変更する場合には，事務部門で変更内容を確認し，ボーナス月の反映日を調整している。

〔システム改善の方針〕

各種変更サービスと限度額の変更サービスで事務部門が実施している作業をシステム化する。

ボーナス月の反映日は，これまで事務部門が変更内容を確認して調整していた。その作業をフロントシステムに移すので，事務部門が守っていた条件をシステムが考慮する必要がある。その条件が「ボーナス月が1年に3回以上とならないように」である。たとえば今年のボーナス月が1回済んだ後で残りの月を別の月に変えると，反映日の取り方しだいで同じ1年の中にボーナス月が3回入ってしまう。反映日はそれを避けるように決める。

本文の冒頭で，約定条件の調整には二つの制約が書かれている。毎月の返済額が利息を下回らないことと，ボーナス月が1年に3回以上にならないことである。下線②は「ボーナス月に関する変更内容」と対象を絞っているので，後者を選ぶ。

40字以内。解答例は37字。「ボーナス月の変更によって」と原因を添え，「1年に3回以上とならない」という本文の条件をそのまま使っている。

本文の根拠

〔現在の会員サービスと関連システムの概要〕(4)

また，E 社では，審査が完了した後に限度額変更に関する書類を会員へ郵送する。そこで，書類が確実に届くようにするために，事務部門が会員の現在の住所が変更されていないかどうかを電話で確認している。

〔システム改善の方針〕

各種変更サービスと限度額の変更サービスで事務部門が実施している作業をシステム化する。

限度額の変更サービスで事務部門が電話でしていた作業は，書類の郵送先となる住所が変わっていないかの確認である。方針はこの作業をシステム化するとしているので，申込画面で会員に住所変更の有無を答えてもらう項目を足す。変更があれば，各種変更サービスで住所を直してもらえば書類が確実に届く。

限度額の変更サービスの記述のうち，事務部門の作業は「必要に応じて審査する」「収入証明書…内容を確認し」「住所が変更されていないかどうかを電話で確認」の三つである。収入証明書は別の改善点（同時アップロード）で扱われているので，項目の追加に当たるのは住所の確認である。

10字以内と短い。解答例は「住所変更の有無」で7字。何を確認するかだけを名詞で書く。

本文の根拠

〔会員サービスに関わるシステム改善要望〕

収入証明書の再提出が必要となる会員のマイページにメッセージを表示し，収入証明書の提出画面に誘導してほしい。

〔会員サービスに関わるシステム改善要望〕

事務部門からの電話連絡を効率化するために，対応が必要な会員のマイページにメッセージを表示し，各種変更画面へ誘導してほしい。

〔E 社のカードローンの概要〕

会員から提出された収入証明書に有効期限を設け，その有効期限が到来する 3 か月前に再提出を依頼している。

〔現在の会員サービスと関連システムの概要〕

電話番号ステータスの初期値は，“正常”としており，電話で会員に連絡した際に電話番号が無効であった場合に，“無効”に変更している。

改善要望のうちマイページにメッセージを出すものは二つある。一つは収入証明書の再提出が必要な会員で，再提出の依頼は有効期限の3か月前なので「収入証明書有効期限が3か月以内に到来すること」が条件になる。もう一つは事務部門からの電話連絡を効率化する要望で，電話がつながらない会員に電話番号を直してもらうことが狙いなので「電話番号ステータスが“無効”であること」が条件になる。

下線③の後の「それぞれ対象の画面へ誘導する」が，条件が二つで誘導先がそれぞれ違うことを示している。誘導先は収入証明書の提出画面と各種変更画面である。キャンペーンサービスの「会員が電話番号を変更して連絡が取れないこともある」が，電話番号ステータスを使う理由を裏付ける。

設問は「会員情報の属性を用いて」と指定している。会員情報の属性名は「電話番号ステータス」「収入証明書有効期限」なので，この名前を使って書く。それぞれ25字以内で，解答例は19字と22字。

本文の根拠

〔E 社のカードローンの概要〕

具体的には，転職，転籍又は退職の理由で勤務先の変更があった場合や収入に大きな変動があった場合に，見直しが行われる。

〔現在の会員サービスと関連システムの概要〕(2)

勤務先変更理由には，転職，転籍，退職，転勤，会社の住所変更又は社名変更がある。E 社では，勤務先情報の変更で再度審査して限度額を再設定する場合があるので，フロントシステムから基幹システムに連携された勤務先変更理由を事務部門で確認し，勤務先変更理由によっては審査システムに審査を依頼する。

勤務先変更理由は六つあるが，限度額を見直すのは転職，転籍又は退職のときだけである。転勤，会社の住所変更，社名変更は勤め先そのものは変わらないので審査は要らない。これまで事務部門が勤務先変更理由を見て審査を依頼していたので，基幹システムが勤務先変更理由を判定して，転職・転籍・退職のときに審査システムと連携する。

講評は事務部門の現在の業務に関係のない解答が多かったと述べている。改善の出発点は「勤務先変更理由を事務部門で確認し，勤務先変更理由によっては審査システムに審査を依頼する」という事務部門の作業であり，その判断基準は本文の冒頭の限度額の見直しの記述にある。二か所をつなげば条件が決まる。

25字以内。解答例は21字。条件の対象が「勤務先変更理由」であることを主語にして，三つの理由を並べる。

採点講評（IPA）

設問4(1)は，正答率が低かった。事務部門の業務効率化を目的として，勤務先情報の変更時，基幹システムが審査システムと連携する条件を問う問題であったが，事務部門の現在の業務に関連しない解答が散見された。どのような要望に基づいてシステムの改善を行うかを意識し，適切な処理内容を設計するよう心掛けてほしい。

本文の根拠

〔会員サービスに関わるシステム改善要望〕

すぐに解約できない場合でも，解約サービスで解約を受け付けられるようにしてほしい。

〔現在の会員サービスと関連システムの概要〕(6)

借入残高がある場合は解約を受け付けない。

〔各システムの改善点〕(2)

解約を受け付けた場合，契約ステータスを“解約予約”に変更する。

“解約予約”は，借入残高が残っていてすぐには解約できない会員の解約を受け付けておく状態である。借入残高が0円になれば解約できるので，夜間バッチで「契約ステータスが“解約予約”で借入残高が0円」の会員を“解約”に変える。

すぐに解約できない理由は，現行の解約サービスの「借入残高がある場合は解約を受け付けない」である。借入残高は口座振替の結果を受け取った日に更新されるので，完済の時点は日々のバッチで拾うのが自然である。“解約予約”であることを条件に入れないと，解約を申し込んでいない完済会員まで解約してしまう。

30字以内。解答例は27字。契約ステータスと借入残高の二つの条件を両方書く。

本文の根拠

〔新システムの設計〕

生徒数が多い拠点では，登下校用端末を複数設置してどの端末でも登下校の手続ができるようにする。

〔新システムの設計〕

登下校用端末からは管理サーバ内のファイルにはアクセスしない。登下校用端末が管理サーバから受け取る情報は，依頼した処理の成功又は失敗だけとする。

〔新システムの設計〕

その日 1 回目の登下校登録は登校，2 回目は下校というように自動判定する。

登校か下校かは，その日にその生徒の登録が何回目かで決める。端末に判定を置くと，端末は自分が受け付けた回数しか知らない。端末が複数ある拠点で，登校時と下校時に別の端末を使うと，下校時の端末にとってはその日1回目になり，下校を登校と誤って判定する。

端末が他の端末の記録を知る手段も本文で塞がれている。登下校用端末は管理サーバのファイルにアクセスせず，受け取るのは処理の成否だけである。だから回数を正しく数えられるのは，全端末の登録が集まる管理サーバの登下校履歴ファイルだけになる。

30字以内。解答例は23字。「複数の端末」だけでなく，登校と下校で別の端末を使うという場面まで書く。

本文の根拠

〔業務の概要と新システムへの要望〕

保護者が生徒の顔を見て安心できるように，登下校を通知するメール（以下，登下校通知メールという）には登下校時に撮影した写真を添付したい。

表2 登下校代理登録

登下校通知メール送信機能を呼び出し，登録した登下校履歴ファイルの情報を渡す。

表2 登下校登録

登下校通知メール送信機能を呼び出し，登録した登下校履歴ファイルの情報と登下校用端末から受け取った写真を渡す。

登下校代理登録は，拠点長が管理画面から手で登下校履歴を登録する機能で，写真を撮らない。登下校通知メール送信機能には登下校履歴ファイルの情報しか渡さないので，メールに写真が付かない。拠点長の要望のうち「登下校時に撮影した写真を添付したい」が実現できない。

表2の登下校登録と登下校代理登録の最後の項目を見比べると違いが分かる。登下校登録は「情報と登下校用端末から受け取った写真を渡す」，代理登録は「情報を渡す」だけである。忘れ物をしても使えるようにする要望は代理登録で満たしており，欠けるのは写真だけである。

25字以内。解答例は18字。どの要望かが分かるよう「写真を添付する」を入れる。

本文の根拠

〔業務の概要と新システムへの要望〕

兄弟姉妹で入会する生徒も多いが，それぞれが別の拠点に所属する場合もある。

表2 メール送信エラー通知

エラーメッセージに含まれる宛先メールアドレスを生徒マスターに設定されている保護者メールアドレスと照合の上，一致した生徒が所属する拠点の拠点長にメール送信がエラーになった旨を通知する。

メール送信エラー通知機能は，エラーになった宛先メールアドレスで生徒マスターの保護者メールアドレスを探し，一致した生徒の所属拠点に通知する。兄弟姉妹が別々の拠点に所属していると，同じ保護者メールアドレスで複数の生徒が見つかり，所属拠点も複数になる。どの生徒の登下校通知がエラーになったのか分からないので，通知すべき拠点を一つに決められない。

手掛かりは，業務の概要にある「兄弟姉妹で入会する生徒も多いが，それぞれが別の拠点に所属する場合もある」である。兄弟姉妹なら保護者は同じで，保護者メールアドレスも同じになりうる。照合のキーがメールアドレスである点と組み合わせると答えが出る。

40字以内で「具体的に」。解答例は35字で，「保護者メールアドレスが同一」と「別々の拠点に所属」の二つを入れる。講評のとおり，臨時で別拠点の授業を受ける場合は答えにならない。その場合も生徒マスターの所属拠点は一つに決まるからである。

採点講評（IPA）

設問2(2)は，正答率がやや低かった。保護者メールアドレスをキーに検索すると複数拠点の生徒が一致する場合があることを問う問題であったが，“臨時で別拠点の授業を受けている場合”と誤って解答した受験者が多かった。本文中の記述から処理の内容と指摘事項を読み取り，正答を導き出してほしい。

本文の根拠

表2 生徒情報管理

保護者が登下校通知メールの受信を希望しない場合は，登下校通知メール受信有無を“無”にし，保護者メールアドレスは設定しない。

〔システムの設計変更〕(2)

拠点長の場合は自拠点に所属する全生徒が，本部担当者の場合は全拠点又は選択した拠点の全生徒が対象となる。件名，本文を入力して送信ボタンを押すことで，対象となるメールアドレス全てにメールが送信される。

お知らせメールは所属する全生徒の保護者に送る。ところが今の生徒情報管理では，登下校通知メールを希望しない保護者のメールアドレスは設定しない。そのままではお知らせメールが届かない保護者が出るので，生徒情報管理を変えて，全ての生徒の保護者メールアドレスを設定するようにする。

変える機能は，保護者メールアドレスを登録する側である。講評は「登下校通知メール送信」と答えた受験者が多かったと述べているが，お知らせメールは新しく追加する別の機能で，登下校通知メールの送り方を変える必要はない。登下校通知メール受信有無が“無”の生徒に登下校通知を送らない仕組みは，受信有無の値で判定しているのでそのまま残る。

変更内容は35字以内。解答例は29字。機能名は表2の名前どおりに書く。

採点講評（IPA）

設問3(1)は，正答率がやや低かった。変更する機能名を，“登下校通知メール送信”と誤って解答した受験者が多かった。追加機能の実装に併せて，既存機能にどのような変更が必要となるかを正しく把握してほしい。

本文の根拠

〔業務の概要と新システムへの要望〕

登下校通知メールの送信が遅延すると保護者に不安を与えるので，可能な限り早く送信したい。

表2 登下校通知メール送信

メールは新システム全体で一つのメールアドレスから送信する。メールサーバの仕様上，一度に大量に送信すると送信完了までに時間が掛かることがあるが，夕方のピーク時間帯でも問題ない程度の性能を確保する。

お知らせメールは，全拠点の全生徒の保護者に一斉に送ることがある。登下校通知メールと同じメールサーバで送れば，一度に大量の送信が重なり，登下校通知メールの送信完了が遅れる。登下校通知メールの遅れは保護者の不安につながるので，お知らせメールには専用のメールサーバを用意した。

表2の「一度に大量に送信すると送信完了までに時間が掛かることがある」と，性能は「夕方のピーク時間帯でも問題ない程度」しか見込んでいないことが根拠になる。お知らせメールの一斉送信はその想定の外にある。

20字以内。解答例は「登下校通知メールの送信が遅延する。」で17字。悪影響を受ける「他の機能」が登下校通知メール送信であることを名指しする。

本文の根拠

〔システムの設計変更〕(3)

登下校履歴ファイルに，実際に登下校した拠点を示す“拠点コード”属性を追加する。

表2 登下校通知メール送信

また，検索結果から拠点コードも取得し，その拠点コードで拠点マスターを検索して拠点名を取得する。

表2 拠点在室人数表示

登下校履歴ファイルのうち，登下校日時が当日で生徒番号が自拠点の生徒番号のものを抽出し，登下校区分が“登校”の件数と“下校”の件数の差を在室人数として表示する。

表2の機能のうち，拠点を「所属拠点」で扱っていて，別拠点への登下校で結果が狂うものを探す。一つは登下校通知メール送信で，メール本文の拠点名を生徒マスターの拠点コード（所属拠点）から取っている。別拠点に登校すると，所属拠点に到着したと通知してしまう。登下校履歴ファイルに追加した拠点コードから拠点名を取るように変える。もう一つは拠点在室人数表示で，自拠点に所属する生徒の履歴を数えている。別拠点から来た生徒は数えられず，別拠点へ行った自拠点の生徒は数えられてしまう。登下校日時が当日で，履歴の拠点コードが自拠点のものを抽出するように変える。

設計変更(3)が登下校履歴ファイルに「実際に登下校した拠点」を足したのは，この二つの機能で使うためである。講評は，拠点在室人数表示の変更で「別拠点の生徒も抽出対象に加える」のように片方の向きにしか触れない解答が多かったと述べている。自拠点の生徒が別拠点へ行く場合もあるので，所属ではなく履歴の拠点コードで数える，と書く必要がある。

変更内容はそれぞれ40字以内で「具体的に」。解答例は33字と35字。どのファイルのどの属性を使うかまで書く。

採点講評（IPA）

設問3(3)は，拠点在室人数表示機能に関する変更内容の正答率がやや低かった。“別拠点の生徒も抽出対象に加える”のような，条件の変更には触れているものの，内容が不十分な解答が散見された。別拠点の生徒が自拠点に登下校するケースだけでなく，自拠点の生徒が別拠点に登下校するケースもあることから，人数の計算には登下校履歴ファイルの“拠点コード”を使用する必要がある。追加要望に応じた変更を加える際の影響範囲を正しく把握し，適切な処理内容を設計できるよう心掛けてほしい。