令和元年度 秋期 午後Ⅰ

本文の根拠

〔新サービスを利用するペルソナの作成〕

ペルソナは，実際に体組成計を購入，利用している代表的な人物像に近づけるために，PT のメンバの想像だけで作成するのではなく，aに協力を依頼し，より具体的な人物像を設定した。

〔新製品に係る取組〕(4) マーケティング部

従来から行っていた健康機器の購入者情報，アンケート情報，市場調査結果などの管理，分析に加えて

〔新製品に係る取組〕

スマホアプリは，体組成計の購入者のうち，個人情報，趣味・嗜好，健康に関するアンケートに回答した者に対して，無料で提供している。

ペルソナを「実際に体組成計を購入，利用している代表的な人物像」に近づけるには，実際の購入者についての情報を持つ部署の協力が要る。関連部署のうち，健康機器の購入者情報とアンケート情報を管理しているのはマーケティング部である。PT は健康増進事業部とディジタル戦略部の担当者で構成されているので，PT の外にあるこの部署に協力を依頼することになる。

アンケートは，スマホアプリの提供を受ける体組成計の購入者が，個人情報，趣味・嗜好，健康について回答したものである。表1 のペルソナには職業，家族構成，趣味，食生活，健康状態と意識が並んでおり，これらを具体的に設定するにはアンケート情報が材料になる。講評は，購入者情報だけを挙げてアンケート情報を管理していることを理由に書いていない解答が散見されたとしている。

部署名は本文の表記どおり「マーケティング部」と書く。理由は35字で「体組成計の購入者情報」と「アンケート情報」の両方を管理していることを書く。解答例は「体組成計の購入者情報及びアンケート情報を管理しているから」で28字。

採点講評（IPA）

設問1は，部署名については正答率が高かった。一方で，理由についてはペルソナの作成に当たってアンケート情報が必要になるにもかかわらず，アンケート情報を管理していることが理由として記載されていない解答が散見された。

本文の根拠

〔新サービスを利用するペルソナの作成〕

新サービスで提供する機能は，ふだんから健康機器の開発などに関わっている提供者側の視点だけでなく，想定される利用者の人物像を念頭において，利用者側の視点から具体的に考え出す必要があった。

〔カスタマジャーニマップの作成〕

①PT のメンバに加えて，社内のペルソナに近い人物を集めて議論し

〔新製品に係る取組〕

R 社は，健康増進事業部とディジタル戦略部から担当者を集めたプロジェクトチーム（以下，PT という）を立ち上げ

PT のメンバは健康増進事業部とディジタル戦略部の担当者で，ふだんから健康機器の開発などに関わっている。本文は，新サービスの機能を提供者側の視点だけでなく，利用者側の視点から具体的に考え出す必要があったと書いている。社内のペルソナに近い人物を議論に加えるのは，利用者に近い立場からの思考・感情を取り込み，利用者側の視点で必要な機能を考え出すためである。

実際に，このカスタマジャーニマップの分析結果を基に，表3 の機能が新たに抽出されている。講評は，ペルソナやカスタマジャーニマップを作成すること自体を狙いとした解答が多かったとしている。作成は手段であり，問われているのは下線①の議論で何を得ようとしたかである。

40字で「利用者側の視点」と「新サービスで必要な機能を考え出す」の二つを入れる。解答例は「利用者側の視点から新サービスで必要とされる具体的な機能を考え出すため」で34字。

採点講評（IPA）

設問2は，正答率が低かった。PTのメンバはふだんから健康機器の開発などに関わっており，提供者側の視点で考えがちになってしまうので，利用者が本当に必要なものが何なのかを，利用者側の視点で考える必要があることに気付いてほしかったが，ペルソナ及びカスタマジャーニマップの作成に関する解答が多かった。

本文の根拠

〔新製品に係る取組〕(1) 健康増進事業部

新たにオンラインコミュニティを企画，運営し，利用者が継続的にコミュニティ活動を行うことを支援する。

〔新たな機能の抽出〕

健康ポイントは，オンラインコミュニティの利用頻度，目標の達成，順位などに応じて付与する。

健康ポイントは，オンラインコミュニティの利用頻度，目標の達成，順位などに応じて付与される。コミュニティをよく使い，活動を続けるほどポイントがたまる仕組みで，利用者に活動を続ける動機を与える。

健康増進事業部の役割は，オンラインコミュニティを企画，運営し，利用者が継続的にコミュニティ活動を行うことを支援することである。営業推進部の狙い（ポイントで R 社の商品や有料サービスを使ってもらう）は付与したポイントの使い道の側にあり，健康増進事業部の狙いはポイントを付与する側，つまり継続的な活動を促すことにある。〔新サービスの開発方針〕にも「利用者が継続的にコミュニティ活動を行えることを目指す」とある。

30字で「継続的にコミュニティ活動を行ってもらう」ことを書く。解答例は「利用者に継続的にコミュニティ活動を行ってもらうこと」で25字。

本文の根拠

表3 A-4

基礎代謝量及び当日のbから計算した消費カロリの推計と，体重の増減目標を踏まえた摂取カロリ目安の通知機能。

表2 閲覧・分析 思考・感情

活動量などから摂取カロリをどの程度にすべきなのかを知りたい（B）。

〔新製品に係る取組〕

活動量計で計測する歩数，脈拍，睡眠時間などの活動量

消費カロリは，何もしなくても消費する基礎代謝量に，その日に体を動かした分を加えて推計する。A-4 では基礎代謝量は A-3 で自動計算されるので，残る計算根拠は当日の体の動きを表すデータである。本文では，活動量計で計測する歩数，脈拍，睡眠時間などをまとめて「活動量」と呼んでいる。

表2 では，ペルソナB が「活動量などから摂取カロリをどの程度にすべきなのかを知りたい」としている。A-4 の摂取カロリ目安の通知はこの思考・感情に応える機能である。活動量は活動量計で計測され，A-1（活動量計との定期的なデータ連携機能）で健康管理アプリに取り込まれる。

答えは本文の語をそのまま使って「活動量」。歩数だけ，脈拍だけでは一部にとどまる。

本文の根拠

表2 コミュニティ活動 思考・感情

ランニングの記録は共有したいが，体重など一部のデータは共有したくない（A）。

表3 B-6

健康管理アプリからオンラインコミュニティにアップロードするデータを任意に選択できる機能

〔新製品に係る取組〕

具体的には，健康管理アプリの利用者が記録した健康活動ログをインターネット上のコミュニティ（以下，オンラインコミュニティという）で共有し

B-6 は，オンラインコミュニティにアップロードするデータを利用者が選べる機能である。表3 の機能はカスタマジャーニマップによる分析結果を基に抽出されたので，表2 の中にこの機能を必要とする思考・感情を探す。コミュニティ活動のフェーズで，ペルソナA が「ランニングの記録は共有したいが，体重など一部のデータは共有したくない」としている。

健康管理アプリの健康活動ログには体重，体脂肪率などの体組成計のデータも含まれる。これを一律にコミュニティで共有すると，共有したくないデータまで公開されてしまう。利用者によって共有したいデータとしたくないデータがあるので，選択できるようにした。

30字で「利用者によっては」と「一部のデータは共有したくない」を書く。解答例は「利用者によっては，一部のデータは共有したくないから」で25字。

本文の根拠

〔新サービスの機能のリリース方針〕

一方で，一定量のデータの蓄積と有効性検証を行わないと誤った情報の提供をしかねない機能については，初期リリースの対象外とした。

表3 B-4

膨大な健康活動ログとAI分析技術を利用した無料の生活習慣改善助言機能

「一定量のデータの蓄積」が前提になる機能を表3 から探す。B-4 は膨大な健康活動ログと AI 分析技術を利用して生活習慣改善の助言をする機能である。サービス開始直後は健康活動ログが蓄積されておらず，AI 分析の結果が妥当かどうかの検証もできていないので，誤った助言をしかねない。

ほかの機能は，データの蓄積がなくても成り立つ。A-2 の AI 画像認識は「実績のある他社製の技術を活用する」とあり，有効性が確かめられている。A-3・A-4 は一般的な計算式による計算，B-5 は専門家による指導で，蓄積したデータに依存しない。

答えは表3 の機能 ID で「B-4」と書く。

本文の根拠

〔新サービスの機能のリリース方針〕

その他の機能については，機能が新サービスの開発方針であるcに寄与するかどうかの観点で分析し

〔新サービスの開発方針〕

新サービスを通じて利用者の健康意識を高め，生活習慣の改善などの健康づくりにつながることを重視することにした。

空欄 c は「新サービスの開発方針である」観点なので，〔新サービスの開発方針〕の中で新サービスとして重視することを探す。そこには，新サービスを通じて利用者の健康意識を高め，生活習慣の改善などの健康づくりにつながることを重視すると書かれている。機能が利用者の健康づくりに寄与するかどうかで優先順位を付ければ，開発方針に沿った機能から初期リリースに入る。

講評は，「利用者の体験価値」や「サービスデザイン思考」と書いた解答が散見されたとしている。体験価値への着目やサービスデザイン思考は開発アプローチとして重視することで，新サービスが目指す成果ではない。新サービスとして重視する観点を答える必要がある。

15字で本文の語を使い「利用者の健康づくり」とする。解答例は9字。

採点講評（IPA）

設問4(2)は，何に寄与するかどうかの観点として，新サービスの開発方針として記載されている“利用者の健康づくり”と解答してほしかったが，“利用者の体験価値”や“サービスデザイン思考”といった解答が散見された。開発アプローチとして重視することではなく，新サービスとして重視する観点から解答する必要があることに気付いてほしかった。

本文の根拠

〔新サービスの開発方針〕

また，新サービスとして提供する機能を一度に全て開発するのではなく，実際の利用者からのフィードバック内容を分析し，改善と軌道修正を繰り返すことで，段階的に新サービスの機能を拡充させ，利用者が継続的にコミュニティ活動を行えることを目指すことにした。

〔新サービスの機能のリリース方針〕

その上で，短期間で開発可能で，変更がしやすいシステム構造を採用することにした。

「短期間で開発可能」は，新製品の体組成計の発売日に合わせて短期間でリリースする必要があることから説明できる。しかし設問は「新サービスの開発方針上の理由」を問うので，〔新サービスの開発方針〕の中から「変更がしやすい」ことが必要になる記述を探す。

開発方針では，機能を一度に全て開発するのではなく，利用者からのフィードバックを分析し，改善と軌道修正を繰り返して段階的に機能を拡充させるとしている。初期リリースの後も機能の追加や変更が続くので，変更しやすい構造が要る。〔新製品に係る取組〕でもディジタル戦略部が「サービス開始後の追加開発」を行うとしている。

30字で「段階的に機能を拡充させる」ことを書く。解答例は「段階的に新サービスの機能を拡充させることにしたから」で25字。

本文の根拠

〔容器管理システムの処理概要〕(1) 容器購入処理

容器の購入時に，RF タグに容器種コード，容器番号を書き込み，容器に貼付して，容器倉庫へ運ぶ。

〔容器管理システムの処理概要〕(1) 容器購入処理

容器種コード，容器番号をキーにして容器状態管理ファイルに登録し，容器状態区分を“未使用”にする。

〔容器管理システムの処理概要〕(5) 容器洗浄・検査処理

検査に合格した容器は容器倉庫へ運び，不合格となった容器は廃棄する。検査結果によって，容器状態管理ファイルの容器状態区分を“合格”又は“廃棄”にする。

〔容器管理システムの処理概要〕(2) 容器保管処理

化学品の充填が可能になった容器を容器倉庫に入庫する。

容器倉庫に運ばれる容器を処理概要から探すと，二つの経路がある。一つは購入した新しい容器で，容器購入処理で容器状態区分を“未使用”にして容器倉庫へ運ぶ。もう一つは回収して洗浄・検査に合格した容器で，容器状態区分を“合格”にして容器倉庫へ運ぶ。

容器保管処理では，入庫時に容器状態管理ファイルで充填可能な状態であることを確認する。充填可能な状態とは，この二つの区分である。“回収”はまだ洗浄・検査が済んでおらず，“廃棄”は再利用しない。“容器倉庫入庫”は入庫した後に付ける区分なので，入庫前の区分にはならない。

容器状態区分の値は本文の表記どおりに書き，二つとも挙げる。解答例は「未使用，合格」。

本文の根拠

〔容器管理システムの処理概要〕(2) 容器保管処理

容器の出庫は，製造計画で決定した化学品の当日分の生産総量と製品マスタに登録されている情報を用いて，①どの容器が何個必要かを計算し，出庫指示を出す。

表1 製品マスタ

製品マスタ：製品コード（主キー），化学品名，容器種コード，容器一個当たり標準充填量，製品使用可能日数。

〔現行業務の概要〕(1) 充填

化学品は，製造の最終工程のラインで，化学品ごとに一意に定められた容器種の容器に充填されて，製品となる。

下線①は「どの容器が」と「何個必要か」の二つを計算する。どの容器かは，化学品ごとに一意に定められた容器種で決まるので，製品マスタの容器種コードを使う。何個かは，当日分の生産総量を容器一個に充填する量で割れば求まるので，容器一個当たり標準充填量を使う。

製品マスタのほかの属性は計算に使わない。製品コードは製品を特定するキーで，計算の材料ではない。化学品名は名称，製品使用可能日数は使用期限の計算に使う属性である。生産総量は製造計画から得るので，製品マスタから取る必要はない。

表1 の属性名をそのまま使い，二つとも答える。解答例は「容器種コード，容器一個当たり標準充填量」。

本文の根拠

〔D 社で採用した RF タグ及び関連する機器などの説明〕(3)

RF タグの一括読み書きでは，環境によって数％程度の漏れが発生することを事前検証で確認している。

〔容器管理システムの処理概要〕(4) 容器回収処理

数が不一致の場合は，まず，容器返却数のシステムへの入力が正しいことを確認して，その後，HT による個別の読込みに切り替える。

〔容器管理システムの処理概要〕(4) 容器回収処理

個別読込み件数と容器返却書に記載された容器返却数が不一致の場合は，エラー処理を行う。

〔現行業務の概要〕(4) 容器回収

配送業者は，顧客が空になった容器を保管していた場合，容器返却書を起票して容器を回収し，D 社の容器回収場所へ持ち帰る。

HT による個別読込みは，ゲートアンテナの一括読込み件数と容器返却数が合わず，かつ返却数の入力が正しいと確認できた後に行う。個別読込みの件数が容器返却数と一致するのは，実際の容器の数は返却書どおりだったのに，一括読込みで読み漏れが起きていたときである。一括読み書きでは数％程度の漏れが発生することが事前検証で分かっている。

個別読込みでも一致しないのは，読み漏れではなく，実物の数そのものが容器返却書の容器返却数と違っているときである。容器返却書は配送業者が起票するので，記載の誤りや回収時の数え違いが起こりうる。講評は，ゲートアンテナの一括読込みで一致・不一致になるケースと取り違えた解答が多かったとしている。問われているのは個別読込み時の結果なので，一括読込みで数が合わなかったことは前提になる。

どちらも30字以内で「どのようなときか」を書く。解答例は，一致するケースが「RFタグの一括読込みで読込み漏れが発生したとき」で23字，不一致になるケースが「容器返却書の容器返却数と実際の容器の数が違っているとき」で27字。

採点講評（IPA）

設問2(1)は，正答率が低かった。HTによる個別読込みで読み込んだ結果，一致するケースと不一致になるケースを問うたが，ゲートアンテナでの一括読込みで数が一致するケースと不一致になるケースと勘違いした解答が多かった。

本文の根拠

〔D 社で採用した RF タグ及び関連する機器などの説明〕(2)

容器情報領域は，RF タグを容器に貼付する際に書き込み，書込みロックを掛ける。書込みロックが掛けられた領域は，ロックを外さない限り値を変更できない。

〔D 社で採用した RF タグ及び関連する機器などの説明〕(5)

D 社は，容器の誤使用を防ぐために，RF タグへの書込み処理では，対象項目がクリアされていない場合は書き込みできないよう，プログラムでガードする。

〔容器管理システムの処理概要〕(5) 容器洗浄・検査処理

検査担当者が再利用の可否についての検査を行った後，RF タグの製品情報領域をクリアする。

はがした RF タグを別の容器に再利用するには，容器購入処理と同じように，容器情報領域に新しい容器の容器種コードと容器番号を書き込めなければならない。ところが容器情報領域には書込みロックが掛かっていて，ロックを外さない限り値を変更できない。さらに書込み処理は，対象項目がクリアされていなければ書き込めないようにガードされている。

そこで，HT で書込みロックを外し，容器情報領域をクリアしておく。製品情報領域は，検査の後にすでにクリアされているので，ここで行う必要はない。RF タグ番号は書き換えられないが，タグ固有の番号なので再利用の妨げにはならない。

30字で「書込みロックを外す」と「容器情報領域をクリアする」の二つを書く。解答例は「書込みロックを外して，容器情報領域をクリアする処理」で25字。

本文の根拠

〔販売管理システムの改修〕(2) 積込・出荷処理

HT で，積込対象となる製品の RF タグを読み込み，積込指示データと RF タグ情報をチェックする。③データ内容及び数が合っていれば，検品を完了して出荷する。

〔販売管理システムの改修〕(1) ピッキング処理

ピッキング指示データと RF タグ情報をチェックし，製品コードが合っていれば RF タグへ受注伝票番号を書き込み

図1 RF タグのデータレイアウト

製品情報領域（製品コード，ロット番号，充填日，受注伝票番号，（予備））

下線③のデータ内容は，積込指示データと RF タグ情報を突き合わせる項目である。RF タグに入っているのは図1 の項目だけなので，その中から積込の正しさを確かめられるものを選ぶ。ピッキング処理で RF タグに受注伝票番号が書き込まれているので，受注伝票番号でどの受注の積込かを確かめ，製品コードで製品が正しいかを確かめる。

講評は，RF タグのデータレイアウトにない属性は正解にならないとしている。顧客コードは容器状態管理ファイルにはあるが RF タグにはないので，RF タグ情報とのチェックには使えない。ロット番号や充填日は RF タグにあるが，受注に対して積み込む製品が正しいかどうかの判断には関係しない。

表1 の属性名を使って二つとも答える。解答例は「受注伝票番号，製品コード」。

採点講評（IPA）

設問3(1)は，正答率が低かった。HTで受けた積込指示データとHTで読み込んだRFタグ情報のチェックであるから，RFタグのデータレイアウトにない属性は正解にはならない。一般論で解答するのではなく，問題文をよく読めば正解が導けたはずである。

本文の根拠

〔販売管理システムの改修〕(2) 積込・出荷処理

HT の検品を完了した実績データを取り込んで，a。

〔現行業務の概要〕(3) 積込・出荷

出荷作業者は，出荷実績を計上するために，出荷場所の端末から，出荷した製品の情報を販売管理システムに入力する。

〔関連部門からの要望〕

(2) 作業者が行っている入力などの作業の負担を軽減してほしい。

現行業務では，出荷作業者が出荷実績を計上するために，出荷した製品の情報を端末から販売管理システムに入力している。改修後は HT で検品した結果が実績データとして手元にあるので，これを取り込めば入力しなくても出荷実績を計上できる。作業者の入力の負担を軽減してほしいという要望に応える改修である。

製品在庫管理処理でも，HT で読み込んだデータで入庫実績・出庫実績を計上できるようにしており，同じ考え方である。容器状態区分を“出荷”にすることは，直前の文で検品完了時に行うと書かれているので，空欄には入らない。

本文の語を使い「出荷実績を計上する」と書く。解答例は9字。

本文の根拠

〔販売管理システムの改修〕(4) 使用期限警告処理

条件：容器状態管理ファイルの容器状態区分の値が“b”で，cが本日日付の 1 週間後より前の日付である容器

〔関連部門からの要望〕

顧客の下に使用期限間際の製品があれば，その期限の 1 週間前を過ぎたら，システムで警告を出せるようにしてほしい。

表1

製品マスタ：製品コード（主キー），化学品名，容器種コード，容器一個当たり標準充填量，製品使用可能日数。

〔現行業務の概要〕(1) 充填

化学品は，製造の最終工程のラインで，化学品ごとに一意に定められた容器種の容器に充填されて，製品となる。

b は，顧客の下にある製品の容器状態区分である。積込・出荷処理で検品を完了して出荷すると“出荷”になり，回収されて容器回収処理で“回収”になるまで，容器は顧客の下にある。だから“出荷”で絞り込めば顧客の下の製品になる。

c は使用期限にあたる日付である。表1 には使用期限という属性はなく，製品マスタの製品使用可能日数と，容器状態管理ファイルの充填日がある。化学品は充填されて製品になるので，使用期限は充填日から製品使用可能日数を経た日付になる。これが本日の1週間後より前なら，期限の1週間前を過ぎた製品と期限を過ぎた製品の両方が拾える。講評は，化学品が充填されて製品になることを理解せず勝手に解釈した解答があったとしている。

b は本文の容器状態区分の値どおり「出荷」。c は表1 の属性名を二つ使って「充填日から製品使用可能日数後の日付」（17字）のように書く。

採点講評（IPA）

設問3(3)は正答率が高かったが，顧客の下にある容器の容器状態区分は何かを理解できていないと思われる解答が散見された。また，製品使用可能日数について，化学品が充填されて製品になることを理解せずに勝手な解釈をしたと思われる解答も見受けられた。

本文の根拠

〔現在のレンタル業務の内容〕(1) 機器管理部門

校正有効期限を超えてレンタルすることはない。

〔現在のレンタル業務の内容〕(1) 機器管理部門

機器ごとに校正に必要な日数が異なっており，校正が完了するまで出荷しない。

〔現在のレンタル業務の内容〕(2) 営業部門 ① 見積業務

見積書の情報は，見積番号，機器名，型番，台数，レンタル開始希望日，レンタル期間，レンタル終了予定日，レンタル料金などである。

機器管理部門の業務から，校正について守られている決まりを二つ拾う。一つは，出荷前に必ず校正し，校正が完了するまで出荷しないこと。校正に必要な日数は機器ごとに違うので，引当する時点から出荷日までに校正を終えられる機器でなければならない。もう一つは，校正有効期限を超えてレンタルしないこと。レンタル終了予定日が校正有効期限を過ぎる機器は引当できない。

レンタル終了予定日は見積書の情報に含まれ，受注情報に引き継がれるので，自動引当の条件として使える。講評は，問題文を引用しただけで条件としてふさわしくない解答が多かったとしている。「校正が完了するまで出荷しない」は業務の決まりであり，引当する機器が満たすべき条件の形（出荷までに校正が完了する機器）に直して書く必要がある。

30字ずつなので，それぞれ「〜機器」の形で一つの条件を書く。解答例は「出荷までに校正が完了する機器」（14字）と「レンタル終了予定日が校正有効期限を超えない機器」（23字）。

採点講評（IPA）

設問1(1)は，現在の業務において，校正有効期限を超えてレンタルすることがない点と，機器ごとに校正に必要な日数があり完了するまで出荷しない点から，条件を導き解答してほしかったが，問題文を引用しただけの，条件としてふさわしくない解答が多かった。問題文中の背景及び設問の内容から，機能を設計する上での条件をきちんと整理し，理解してほしかった。

本文の根拠

〔新システムへの要望〕(1) 営業部門からの要望

自動引当は，決裁が下りた受注情報を対象としてほしい。

〔現在のレンタル業務の内容〕(2) 営業部門 ③ 引当業務

K 社では，レンタル開始希望日の 15 日前から受注情報への機器の割当て（以下，引当という）を開始する。

自動引当が抽出する受注情報の条件を，要望と現在の業務から探す。営業部門の要望に，自動引当は決裁が下りた受注情報を対象としてほしいとある。受注業務では受注情報を登録した後に責任者が決裁するので，決裁前の受注情報は対象にしない。

もう一つは引当を始める時期である。現在の引当業務は，レンタル開始希望日の15日前から始めている。新システムでもこれに合わせ，レンタル開始希望日まで15日以内になった受注情報を対象にする。三つ目の条件（まだ引当されていないこと）は設問で示されている。

25字ずつで，受注情報が満たす条件の形（〜こと）で書く。解答例は「決裁が下りていること」（10字）と「レンタル開始希望日まで15日以内であること」（21字）。

本文の根拠

〔現在のレンタル業務の内容〕(2) 営業部門 ③ 引当業務

なお，説明書などの付属品が欠けている機器はレンタルしない。ただし，付属品が欠けている状態でレンタルすることを顧客と合意した場合は，レンタルしてもよいことにしている。

〔現在のレンタル業務の内容〕(2) 営業部門 ⑥ 引取業務

説明書などの付属品が欠けている機器の場合，条件付の機器として物流在庫管理システムに登録し

〔新システムへの要望〕(1) 営業部門からの要望

原則，引当は自動引当だけとするが，例外として営業担当者が，機器の状態を個別に確認し，引当する場合がある。

自動引当はレンタル可能な機器を検索して引当する。レンタル可能な機器として登録されていない機器のうち，例外として引当してよいものが手動引当の対象になる。引取業務では，付属品が欠けている機器を条件付の機器として登録し，付属品を取り寄せた後にレンタル可能な機器として再登録する。

付属品が欠けている機器は原則レンタルしないが，顧客と合意すればレンタルしてよい。この判断はシステムでは自動化できず，営業担当者が機器の状態を個別に確認して引当する。修理を依頼した異常のある機器は，レンタルしてよい例外が本文にない。

15字なので「付属品が欠けている機器」（11字）と書けば足りる。

本文の根拠

〔現在のレンタル業務の内容〕(2) 営業部門 ③ 引当業務

ただし，付属品が欠けている状態でレンタルすることを顧客と合意した場合は，レンタルしてもよいことにしている。

表1 手動引当

一覧から個々の機器の状態を表示し，引当できる。

手動引当の対象は付属品が欠けている機器である。付属品が欠けた機器をレンタルするには，その状態でレンタルすることを顧客と合意しなければならない。合意するには，どの付属品が欠けているかなど，機器ごとの状態が分からなければならない。

そこで手動引当機能は，一覧から個々の機器の状態を表示できるようにしている。営業担当者は表示された状態を顧客に伝え，合意を得た機器を引当する。要望にも「営業担当者が，機器の状態を個別に確認し，引当する」とある。

25字で「顧客と合意する」ことを軸に書く。解答例は「機器の状態を顧客と合意する必要があるから」で20字。

本文の根拠

〔現在のレンタル業務の内容〕(2) 営業部門 ⑤ 満了業務

長期レンタルの場合，レンタル期間が満了する月（以下，レンタル期間満了月という）の 3 か月前の第一営業日に，レンタルを延長するか又は終了するかを確認するための満了案内確認書を封書で顧客に送付する。

〔現在のレンタル業務の内容〕(2) 営業部門 ① 見積業務

レンタル期間は，5 日から 6 か月未満の期間（以下，短期レンタルという）か，6 か月以上の期間（以下，長期レンタルという）である。

表1 満了案内

毎月第一営業日に満了案内対象の受注情報を抽出し，送付する。

満了案内確認書は，長期レンタルの場合にだけ送る。短期レンタルは期間満了時にそのまま終了する。長期レンタルはレンタル期間が6か月以上のものなので，一つ目の条件はレンタル期間が6か月以上であることになる。

送付の時期は，レンタル期間満了月の3か月前の第一営業日である。満了案内機能は毎月第一営業日に抽出するので，その日から見て3か月後の月がレンタル期間満了月にあたる受注情報を抜き出せばよい。延長後の受注情報も，延長したレンタル期間の満了月でこの条件に当てはまる。

25字ずつで，受注情報が満たす条件の形で書く。解答例は「レンタル期間が6か月以上であること」（17字）と「3か月後がレンタル期間満了月であること」（19字）。

本文の根拠

〔新システムへの要望〕(1) 営業部門からの要望

ただし，満了案内確認書で顧客からレンタルを終了する旨の通知があった場合は，毎月 15 日までに営業担当者が必要な処理をする。

〔現在のレンタル業務の内容〕(2) 営業部門 ⑤ 満了業務

期日までに顧客から終了する旨の通知がない場合は，延長扱いとする。

表1 延長及び終了

毎月15日の夜間に延長対象の受注情報を抽出し，延長処理をする。

延長処理は，顧客から終了する旨の通知がなかった受注情報を延長扱いにするものである。自動で延長するには，終了する受注情報がすでに処理済みで，延長対象と区別できていなければならない。営業部門の要望では，顧客から終了の通知があった場合は，毎月15日までに営業担当者が必要な処理をする。

そのため，営業担当者の処理が終わった後の15日の夜間に延長対象を抽出すれば，終了する受注情報を誤って延長することがない。講評は「15日前までに引当てするから」という誤答を挙げている。15日は引当を始める時期（レンタル開始希望日の15日前）にも出てくるが，これは引当の条件で，延長処理の時期とは関係がない。

35字で「終了する場合は毎月15日までに営業担当者が処理する」ことを書く。解答例は「延長しない場合は毎月15日までに営業担当者が必要な処理をするから」で32字。

採点講評（IPA）

設問4は，営業部門の要望において，レンタルを終了する際，毎月15日までに営業担当者が必要な処理をすることがポイントであるが，“15日前までに引当てするから”という誤答が見受けられた。これは，引当ての条件であって，延長処理を毎月15日の夜間とした理由とは直接関係がない。営業部門の要望を正しく理解し解答してほしかった。

本文の根拠

表1 購入

また，受注情報を識別する番号を任意に登録できるようにし，ある機能で利用する。

〔現在のレンタル業務の内容〕(2) 営業部門 ③ 引当業務

レンタル可能な機器がない場合は，当該受注情報に引当する機器として購買部門に購入を依頼し，購入後に引当する。

〔現在のレンタル業務の内容〕(3) 購買部門

レンタルの受注が決まっている機器の場合，営業担当者に連絡する。

表1 自動引当

対象の受注情報を抽出し，物流在庫管理システムと連携し，該当する機器を引当する。

レンタル可能な機器がないときは，その受注情報に引当する機器として購買部門に購入を依頼し，購入後に引当する。現在は，購買部門が受注の決まっている機器を納品後に営業担当者に連絡し，営業担当者が引当している。購入情報に受注情報を識別する番号を登録しておけば，購入した機器をどの受注情報に引当すべきかがシステムで分かる。

新システムでは，原則として引当は自動引当だけとしている。したがって番号を利用するのは自動引当機能で，購入した機器を，番号で結び付いた受注情報に自動で引当する。講評は“見積”や“受注”という誤答を挙げている。受注情報の番号という言葉から受注機能を連想しやすいが，番号を使って機器を割り当てるのは引当である。

機能名は表1 の「自動引当」を使う（解答例は「自動引当機能」）。目的は25字で「購入した機器を対象の受注情報に引当する」ことを書く。解答例は21字。

採点講評（IPA）

設問5は，機能に関して“見積”や“受注”という誤答が見受けられた。購買部門の要望と新システムの機能概要をきちんと整理し，理解してほしかった。

本文の根拠

問4 冒頭

しかし，ピッキングの無人化が多様な形状の商品に十分に対応できるまでには至らず，限定された形状の商品に対応するシステムにとどまっている。

〔冷凍倉庫の無人化に向けての問題点とその解決方針〕

取り扱う商品を箱詰めされた冷凍商品に限定することによって，ピッキングを確実に行う。

取組方針に，取り扱う商品を箱詰めされた冷凍商品に限定することによって，ピッキングを確実に行うとある。冒頭には，ピッキングの無人化は多様な形状の商品に十分に対応できるまでには至らず，限定された形状の商品に対応するシステムにとどまっているとある。

NWH システムでは人手を介さず H ロボットがピッキングを行うので，つかむ商品の形状がまちまちだと失敗しやすい。箱詰めされた商品なら形状がそろい，ロボットでも確実につかんで配送箱に収納できる。限定する理由は，無人化したピッキングを確実にすることにある。

20字なので「ピッキングを確実にしたいから」（14字）のように，方針の語をそのまま使って短く書く。

本文の根拠

〔開発項目の検討結果〕(1) 倉庫内の配置の見直し

フローラックを用いて，先に入庫した商品から出庫されるようにする。

表2 フローラック

商品の補充とピッキングとを異なる側から行い，棚板に傾斜を設けることによって，商品の補充側からピッキング側へ商品が自動的に移動する。

取組方針の「商品の先入れ先出しを確実に守る」に対応する記述を，開発項目の検討結果から探す。倉庫内の配置の見直しで，フローラックを用いて，先に入庫した商品から出庫されるようにするとしている。

フローラックは傾斜した棚板にローラが付いており，商品を補充側から入れると，ピッキング側へ自動的に移動する。後から補充した商品は先に入った商品の後ろに並ぶので，ピッキング側では必ず先に入庫した商品から取り出される。補充とピッキングを異なる走行路で行うのもこの仕組みのためである。

25字で「商品の収納にフローラックを用いた」ことを書く。解答例は「商品の収納にフローラックを用いたこと」で18字。

本文の根拠

〔NWH システムの概要〕(1) 倉庫内の配置の見直し

全ての走行路には，各フローラックに対応した停止位置及び分岐位置にマーカを設け，H ロボットはマーカを読み取りながら走行・停止を行う。

表2 H ロボット

AP経由で管理・制御部と通信し，作業の対象となる商品の個数及び収納ロケーション，作業開始，衝突回避のための一時停止などの指示を受信し

〔NWH システムの概要〕(2) H ロボットの開発

ピッキングを行う商品があるフローラックの位置ごとに走行を停止し

H ロボットが管理・制御部から受け取るのは，作業の対象となる商品の収納ロケーション，つまりどのフローラックのどこかという指示である。一方，走行中に読み取るのは床のマーカで，マーカは各フローラックに対応した停止位置に設けられている。指示されたフローラックの前で止まるには，読み取ったマーカがどのフローラックに対応するかが分かっていなければならない。

したがって H ロボットは，マーカとフローラックの対応関係をあらかじめ持つ必要がある。講評は，マーカかフローラックのどちらか一方だけを答えた受験者が多かったとしている。マーカだけ，フローラックだけでは停止位置を判断できず，二つを対応させた情報が要る。

20字で「マーカとフローラックを対応させた情報」（18字）のように，両者の対応関係を書く。

採点講評（IPA）

設問2(1)は，Hロボットの停止位置を示すマーカと商品の収納場所であるフローラックのどちらか一方だけを解答した受験者が多かった。個々の情報とともに，それらの対応関係が必要となるケースに着目して解答してほしかった。

本文の根拠

〔開発項目の検討結果〕(2) H ロボットの開発

1 回の走行で最大 5 件の配送先の商品のピッキングを行い，各配送先に対応する配送箱に間違いなく収納するために，配送箱には識別用バーコードを個別に貼り付けておく。

〔開発項目の検討結果〕(2) H ロボットの開発

H ロボットは，配送箱 1 箱をカートに移すたびに識別用バーコードを読み取り，あらかじめ管理・制御部から受信している配送先の情報の一つとリンクさせ，そのリンク情報を管理・制御部に送信する。

H ロボットは1回の走行で最大5件の配送先の商品をピッキングする。配送箱は識別用バーコードで配送先とリンクされているので，ピッキングした商品をどの配送箱に入れるかは，その商品がどの配送先のものかで決まる。

そのため H ロボットは，配送先ごとにどの個別商品をピッキングするかという情報を，あらかじめ管理・制御部から受け取っておく必要がある。本文の「あらかじめ管理・制御部から受信している配送先の情報」がこれにあたる。商品の収納ロケーションだけでは，ピッキングした商品をどの配送箱に入れるかが決まらない。

15字なので「配送先ごとの個別商品情報」（12字）のように，配送先と商品の組合せを短く書く。

本文の根拠

〔開発項目の検討結果〕(4) 稼働管理

H ロボットによるピッキングの失敗率が低くなるように，AI による画像認識を利用して改善させる。そのため，個々の商品をつかんだり持ち上げたりするのに要した時間，失敗した回数などを測定するのと同時に，aし，それらのデータを管理・制御部で収集・蓄積する。

表2 H ロボット

ピッキングの状況を動画で撮影する。

表2 検品用監視カメラ

Hロボットからコンベヤへ移された配送箱内の商品の品名，個数，異常の有無，配送箱からのはみ出しの確認を行い，映像を記録する。

a は，AI による画像認識で改善するための材料を得る動作である。画像認識には映像が要る。表2 で H ロボットの仕様に「ピッキングの状況を動画で撮影する」とあり，送信するデータにも動画が含まれる。時間や失敗回数の測定と同時に動画撮影し，これらを管理・制御部で収集・蓄積する。

b は検品用監視カメラで検出するもので，「商品の間違い，異常」と並ぶ。表2 の検品用監視カメラは，配送箱内の商品の品名，個数，異常の有無，配送箱からのはみ出しを確認する。品名・個数が商品の間違い，異常の有無が異常にあたるので，残る「配送箱からのはみ出し」が入る。

どちらも表2 の語を使って，a は「動画撮影」，b は「配送箱からのはみ出し」と書く。

本文の根拠

〔開発項目の検討結果〕(4) 稼働管理

H ロボットの適切な稼働管理を行うために，管理・制御部は，H ロボットのバッテリ残量を監視し，適切なタイミングでバッテリ充電開始の指示を行う。充電は 1 台ずつ行う。

〔NWH システムの概要〕(4) 稼働管理

H ロボットの充電，故障などの稼働停止時間を考慮して，H ロボットの適切な台数の決定，メンテナンスの実施時期の決定などを行う。

〔冷凍倉庫の無人化に向けての問題点とその解決方針〕

H ロボットの割当て，ピッキングのスケジューリングなどを効率よくできるようにする。

充電は1台ずつ行う。各 H ロボットが自分のバッテリ残量だけを見て充電を始めると，複数台の充電が重なって待ちが生じたり，作業中の台数が不足したりする。全ての H ロボットのバッテリ残量と作業の予定を把握しているのは管理・制御部なので，管理・制御部が充電の順番とタイミングを決めれば，稼働を止めずに順に充電できる。

稼働管理では充電による稼働停止時間を考慮して台数やメンテナンス時期を決めており，取組方針にも H ロボットの割当てやスケジューリングを効率よくできるようにするとある。充電を管理・制御部が指示するのは，充電を全体で最適にスケジューリングするためである。

30字で「充電を最適なスケジューリングで行う」ことを書く。解答例は「Hロボットの充電を最適なスケジューリングで行うため」で25字。

本文の根拠

〔NWH システムの概要〕(3) 管理・制御部の変更

H ロボットの位置を把握し，H ロボット同士の衝突を避けるために，一時停止とその解除を指示する。

表2 H ロボット

読み取ったマーカの情報，作業結果，動画，バッテリ残量などのデータを送信する。

一時停止を指示するのは，H ロボット同士の衝突を避けるためである。衝突しそうかどうかは，各 H ロボットがどこを走っているかが分かれば判断できる。管理・制御部の変更で，H ロボットの位置を把握して一時停止とその解除を指示するとしている。

位置は，H ロボットが送信する「読み取ったマーカの情報」から分かる。マーカは走行路の停止位置と分岐位置に設けられているので，最後に読み取ったマーカで走行路上の位置が特定できる。バッテリ残量や作業結果は，衝突回避の判断には使わない。

15字なので「Hロボットの位置情報」（10字）と書けば足りる。

本文の根拠

〔開発項目の検討結果〕(4) 稼働管理

H ロボットによるピッキングの失敗率が低くなるように，AI による画像認識を利用して改善させる。

〔NWH システムの概要〕(4) 稼働管理

また，全体としてピッキングの失敗率を下げるように管理する。

収集・蓄積するデータは，商品をつかんだり持ち上げたりするのに要した時間，失敗した回数，ピッキングの状況の動画である。本文は，これらを使ってピッキングの失敗率が低くなるように AI による画像認識を利用して改善させるとしている。1台の H ロボットのデータでは事例が限られるが，全ての H ロボットのデータを集めれば，失敗しやすい商品やつかみ方などの問題点を多くの事例から見つけて改善できる。

稼働管理でも「全体としてピッキングの失敗率を下げるように管理する」としている。講評は，“問題点を見つける”とだけ書いた解答があったとしている。データは問題点を見つけるだけでなく，それを改善するために使われる。

40字で「多くの H ロボットのデータを用いる」ことと「ピッキングの問題点を改善する」ことの両方を書く。解答例は「多くのHロボットのデータを用いてピッキングの問題点を改善するため」で32字。

採点講評（IPA）

設問3(4)は，正答率が高かったが，“問題点を見つける”とだけを解答した受験者が見受けられた。ピッキングを行うときに得たデータは，問題点を改善するために利用されていることに気付いてほしかった。映像も含めた各種データを収集・蓄積してAIで処理することの意味を考えてほしい。