令和元年度 秋期 午後Ⅰ

本文の根拠

冒頭

SD では，問合せに対する初回回答を 3 時間以内（SD の営業時間外となる場合は，翌営業日の 12 時まで）に返信することを社内サービス目標値として定めている。

表3 項番3

項番3：9/12（木）10:44，ネットワーク障害によるサービス利用不可，9/12（木）13:24（160 分），技術課，9/12（木）16:46。

表3 項番7

項番7：9/26（木）18:10，PC とスキャナが接続できない，9/27（金）11:55（175 分），技術課，9/30（月）16:44。

社内サービス目標値は3時間，つまり180分以内である。表3の経過時間を並べると，24分，13分，160分，17分，21分，13分，175分。

多くは20分前後で終わっているのに，160分と175分の2件だけが飛び抜けている。どちらも180分に迫っていて，あと少しで未達になるところだった。「達成が危ぶまれた事象」はこの2件を指す。

共通点を探すと，どちらもエスカレーション先が技術課である。同じくエスカレーションしていても，データ課の項番1は24分，項番4は17分で短い。問題は段階的取扱いそのものではなく，技術課に回した場合に限って長くなるところにある。

40字。解答例は「エスカレーション先が技術課の場合，初回回答までの経過時間が長い。」で31字。

採点講評（IPA）

設問1(1)は，社内サービス目標値の内容を正しく捉えられており，正答率が高かった。

本文の根拠

〔SD の改善〕

エスカレーション先に要請し，スキャナの障害かどうかを SD で切り分けて対応することができる手順書を整備するなどの改善策を策定した。

表2 手順④

④データの処理：③で収集したデータを改善に役立てるために，サービス目標値や KPI がどの程度達成できたかが分かるように加工する。

KPIは改善策が効いているかどうかを測る指標なので，まず改善策の中身を押さえる。「スキャナの障害かどうかをSDで切り分けて対応できる手順書を整備する」，つまり技術課へ回さずSDだけで片付けられる問合せを増やす取組である。

この取組が進んだかどうかは，技術課にエスカレーションせずに完了した問合せの割合で分かる。割合が上がれば手順書が使われている。

初回回答時間そのものを指標にしたくなるが，それは社内サービス目標値であり，設問が「サービス目標値は除く」と断っている。目標の値ではなく，その目標を達成するための活動が回っているかを測るのがKPIである。

40字。解答例は「エスカレーション先の技術課に依頼することなく，対応完了となった問合せの割合」で36字。

採点講評（IPA）

設問1(2)及び設問2ではKPIを求めたが，正答率は低かった。“目標を達成するための活動が適切に実施されていることを表す指標”を設定し，継続的改善を推進してほしい。

本文の根拠

〔SD の改善〕

毎日の営業終了時点で，受付日を含めた経過日数が 4 営業日目の問合せで，かつ，

表3 注3

完了日時欄で，“対応中”とは初回回答後から対応完了前までを示し，“受付”とは受付後から初回回答前までを示している。

抽出したいのは「まだ終わっていない問合せ」である。表3の完了日時欄に入りうる値を確かめると，完了した日時か，“対応中”か，“受付”の3種類である。

終わっていないのは“対応中”と“受付”の両方である。“受付”は初回回答すらまだの状態なので，むしろこちらのほうが危うい。片方だけ書くと，項番8のような問合せが抽出から漏れる。

設問が「表3中の字句を用いて」と指定しているので，“受付”“対応中”という語をそのまま使う。

20字。解答例は「完了日時欄が“受付”又は“対応中”」で18字。

採点講評（IPA）

設問1(3)は，完了日時欄が“対応中”とだけ記載する誤った解答が多かった。本文から条件を確実に抽出してほしかった。

本文の根拠

〔SD の改善〕

今回の SD の改善は，A 社に実施した顧客アンケートをきっかけとして取り組むことができた。今後も，定期的に現状を把握して表2の改善プロセスが回るよう

〔サービスの利用状況〕

F 事業部は，これまで顧客に対してアンケート調査を実施していなかったので

部長の言葉の中に答えが入っている。「顧客アンケートをきっかけとして取り組むことができた」「今後も，定期的に現状を把握して」の2つである。

F事業部はこれまでアンケートを実施しておらず，今回もA社からの相談があって1回だけ行ったにすぎない。きっかけが偶然のままでは，改善プロセスは次に回らない。

だから，そのきっかけを定期的に作る。アンケートを定期的に実施する，というのが対策案になる。

20字。解答例は「定期的な顧客アンケート調査の実施」で16字。「定期的」を落とすと，今回と同じ一度きりの話になってしまう。

本文の根拠

〔FAQ 掲載方法の改善〕

J 氏が調査した結果，問合せの約 10％が FAQ に掲載している内容であることが分かった。

〔FAQ 掲載方法の改善〕

FAQ の構成，掲載方法及び回答内容を見直すことによって，FAQ の検索性を高め，より多くの利用者が自ら疑問を解決できるよう改善を行った。

改善前の状態が「問合せの約10％がFAQに掲載している内容」と数字で押さえてある。これがベースラインになるので，同じものさしで測ればよい。

FAQの検索性が上がれば，FAQを見れば済むのにSDへ聞いてしまう人が減る。つまりこの10％が下がる。KPIは，SDへの問合せ総件数に占めるFAQ掲載内容の件数の割合であり，その減り具合を見る。

問合せの総件数だけを指標にすると，利用者が増えれば件数も増えるので，改善したかどうかが分からなくなる。割合で見るのはこのためである。

40字。解答例は「SDへの問合せ総件数に占めるFAQに掲載されている問合せ件数の割合の減少率」で37字。

本文の根拠

冒頭

平日 9:00〜16:00 に送信された名刺の画像情報について，送信後 60 分以内で顧客 DB に登録すると案内している。

表1 項番3

項番3（本サービス）：朝 9 時台と夕方 16 時直前に送信した名刺の画像については，スマートフォンで参照できるまでに 1 時間近くの時間が掛かる。

カタログ目標値は「送信後60分以内」である。表1の本サービスに関する意見を，この60分と突き合わせる。

項番1は「とても早くて便利」で，目標に対して余裕がある。項番2は氏名の誤登録の話で，時間とは関係がない。

項番3だけが「1時間近く」と言っている。まだ60分を超えてはいないが，あと少しで超える。しかも朝9時台と夕方16時直前という特定の時間帯に偏っている。これが「達成が危ぶまれる事象」に当たる。

本文の根拠

表1 項番3

朝 9 時台と夕方 16 時直前に送信した名刺の画像については，スマートフォンで参照できるまでに 1 時間近くの時間が掛かる。

冒頭

送信後 60 分以内で顧客 DB に登録すると案内している

〔本サービスの改善〕

データ課では，カタログ目標値を達成するために，数年前から午前中だけ要員を増強して運営し，目標値を全て達成してきた。

測る区間は，カタログ目標値がそのまま決めている。名刺画像の送信から顧客DBへの登録までである。

問題は分け方のほうにある。利用者の声は「朝9時台」「夕方16時直前」と特定の時間帯に偏っている。1日の平均で見ると，多くの時間帯が速いので薄まってしまい，この2つの山が消える。だから時間帯ごとに分けて平均を出す。

データ課が把握していたのは「午前中の作業量が多い」ことまでで，午前中に要員を増やす対策もそこから出ている。だが夕方16時直前は午前中ではない。件数の多い時間帯と，待ち時間が長い時間帯が一致していない可能性がある，というのがこの分析の狙いである。

40字。解答例は「名刺画像の送信から顧客DBに登録されるまでの時間帯別の平均待ち時間」で33字。「9時台の件数」のように件数だけを数えても，待たされているかどうかは分からない。

採点講評（IPA）

設問3(2)は，正答率が低かった。“9時台の件数”など全体の傾向を分析できない誤った解答が多かった。データの分析によって把握すべき情報について解答してほしかった。

本文の根拠

表1 注記1

ソフトウェアを PC に導入すると，導入日が構成情報の一部として記録され，削除した場合は，削除日が記録される。再度，当該ソフトウェアを PC に導入した場合は，最新の導入日が上書きされ，削除日の情報は削除される。

表1 注記1

項番 3 及び項番 4 は，導入実績のあるソフトウェアの数だけ存在する。

〔RPA ツールの導入〕

RPA ツールの利用が不要になった利用者は，各自で RPA ツールを削除する。

構成情報は「導入実績のある」ソフトウェアの数だけ存在する。つまり削除しても構成情報そのものは消えずに残る。社内ソフト名がRPAツールの構成情報を数えるだけでは，すでに削除した人のぶんまで含まれてしまう。本文にも「利用が不要になった利用者は，各自でRPAツールを削除する」とあり，削除する人は実際に出る。

入っているかどうかを分けるのは削除日である。削除すれば削除日が記録され，入れ直せば削除日の情報が消えて導入日が上書きされる。つまり削除日が空かどうかが，いま入っているかどうかを表す。

35字。解答例は「導入日が記録され，かつ，削除日が記録されていない件数を調べる。」で30字。削除日に触れないと，過去に一度でも入れた人の数になってしまう。

採点講評（IPA）

設問1は，構成情報を用いた調査方法として，構成情報の記録方法を理解して解答してほしかった。削除日を意識できていない誤った解答が多かった。

本文の根拠

図1 注2

PC を購入したときに，会社名及び PC 管理番号が記載された備品シールを PC に貼付する。

表1 項番1

項番1（PC）：PC 管理番号，MAC アドレス，従業員番号。

棚卸しは，PCに貼ってある備品シールとCMDBを突き合わせる作業である。だから答えは，シール側にも書かれているものに限られる。

シールに記載されているのは会社名とPC管理番号だけ。一方CMDBの情報種別がPCの構成情報には，PC管理番号・MACアドレス・従業員番号がある。両方にあるのはPC管理番号だけなので，これが照合の鍵になる。

MACアドレスも従業員番号も，シールを見ただけでは分からない。現物と突き合わせられない項目は棚卸しに使えない。

10字。解答例は「PC管理番号」で6字。

採点講評（IPA）

設問2(1)は，正答率が高かった。棚卸しに必要な構成情報については理解されているようであった。

本文の根拠

〔RPA ツールの導入〕

RPA ツールは PC ごとにライセンスが必要である。第 1 段階で必要となる数のライセンスを購入する。

〔RPA ツールの導入〕

RPA ツールを利用する場合は，P 社のファイルサーバから，販売部の従業員自ら RPA ツールをダウンロードして，PC に RPA ツールを導入する。

〔PC の構成監査〕

S 氏は，RPA ツールの導入に向けて，RPA ツールのライセンス購入数の棚卸しも必要と考えた。

ライセンスはPCごとに必要で，購入したのは第1段階に必要な数だけである。ところが導入するのは従業員自身で，ファイルサーバからダウンロードして各自で入れる。情報システム部が途中で数を止める仕組みがない。

つまり，購入したライセンス数を超えてRPAツールが入る可能性がある。放っておくとライセンス違反になる。

そこで，設問1で求めた「現在利用可能なRPAツールの数」と，購入したライセンス数を突き合わせる作業を構成監査に足す。数えるものが「現在利用可能な数」であることが，設問1とつながっている。

40字。解答例は「現在利用可能なRPAツール登録数がライセンス購入数以内であることを確認する。」で37字。ライセンス購入数と比べるところまで書かないと，何を確かめたのかが言えていない。

採点講評（IPA）

設問2(2)は，ライセンス購入数に関わる構成監査のチェック内容として，ライセンス数を意識できていない誤った解答が多かった。ライセンス管理について，しっかり認識してほしい。

本文の根拠

〔RPA ツールの導入〕

RPA ツールでシナリオを実行すると，PC 管理番号，RPA ツール版番号，シナリオ名，シナリオ実行日時が RPA ツールのログとして出力される。

ログに出るのは4項目である。PC管理番号，RPAツール版番号，シナリオ名，シナリオ実行日時。この中から必要なものを選ぶ。

確認したいのは「各PCのRPAツールとポータル掲載シナリオが継続的に利用されていること」なので，3つに分解できる。

各PCの，に当たるのがPC管理番号。ポータル掲載シナリオかどうかを見るのがシナリオ名。継続的かどうかを見るのがシナリオ実行日時。

残るRPAツール版番号は，どの版が動いたかを示すだけで，使われ続けているかどうかには関わらない。設問が「全て挙げ」と言っているので，要るものは漏らさず，要らないものは入れない。

40字。解答例は「PC管理番号，シナリオ名，シナリオ実行日時」で21字。

採点講評（IPA）

設問3(1)(b)のポータル掲載シナリオの活用には，ログの分析が必要であるが，ログの出力だけを指摘する誤った解答が多かった。

本文の根拠

〔RPA ツールの導入〕

情報システム部の従業員が，シナリオの作成を行う。作成したシナリオは社内ポータルサイトに掲載する。

〔RPA ツールの導入〕

PC 管理番号，RPA ツール版番号，シナリオ名，シナリオ実行日時が RPA ツールのログとして出力される。

「幅広く有効活用されている」を2つに分けて考える。

幅広く，は何人が使っているかである。シナリオごとに，実行したPC管理番号が何種類あるかを数えれば分かる。

有効活用，は使い続けられているかである。シナリオ実行日時を見る。

大事なのは，シナリオごとに集計する点である。全体の実行回数だけを数えると，1つのシナリオを1人が何度も回している場合と，多くのシナリオが多くの人に使われている場合を区別できない。誰にも使われていないシナリオが埋もれてしまう。

40字。解答例は「ポータル掲載シナリオごとに，PC管理番号の数，シナリオ実行日時を調べる。」で35字。ログを出力する，では調べたことにならない。出ているログをどう束ねるかまで書く。

採点講評（IPA）

設問3(1)(b)のポータル掲載シナリオの活用には，ログの分析が必要であるが，ログの出力だけを指摘する誤った解答が多かった。

本文の根拠

〔RPA ツールの導入〕

S 氏は，変更審査会の指示事項に従って，第 1 段階の利用者数の目標を 20 人と計画した。

表2

導入済み：あり 22，なし 10。未導入：あり 0，なし 8。

表2 注2

PC から収集した RPA ツールのログが存在する場合，“あり”に計上する。

目標は「利用者数20人」であって，導入した人数ではない。表2のどこを読むかがここで決まる。

利用状況が「あり」なのは，導入済みの22人と未導入の0人で，合わせて22人である。注2のとおり，実際にRPAツールのログが残っている人だけが「あり」に入るので，これが使っている人の数になる。

22人は目標の20人を上回っているので，計画どおりと言える。

導入済みは22＋10で32人いるが，そのうち10人はログが無く，入れただけで使っていない。導入数で見ると達成しているように見えて実態を取り違える。

40字。解答例は「RPAツール利用者の実績は22人で，利用者目標の20人を達成しているから」で35字。実績と目標の両方の数字を入れる。

採点講評（IPA）

設問3(2)は，正答率が高かった。具体的な利用者目標と具体的な利用者の実績については理解されているようであった。

本文の根拠

冒頭

各チームは，チームリーダと数名のオペレータで構成され，それぞれ数社の顧客のシステムを運用している。

〔チーム b で発生したインシデント〕

再起動作業はオペレータ 1 名によって実施される。

表1 項番4

運用監視画面には“S102 が正常”と表示されていたにもかかわらず，オペレータは“S101 が正常”と錯覚した。

起きたのは見間違いである。作業をしていたのは1名だけなので，間違いに気づく人が誰もいなかった。

設問が言う「チームの特性」は，チームがチームリーダと数名のオペレータで成り立っていることである。つまり人が他にもいる。

そこで，項番4の確認だけは1人に任せず，複数のオペレータで見る。方策①は対象サーバ数が多くて作業量が増えるため見送られ，方策②は手順を足す策なので，方策③はチームという体制のほうを使う策になる。

40字。解答例は「項番4で“S101が正常”と表示されていることを複数のオペレータが確認する。」で37字。どの手順を，誰が，というところまで書く。

採点講評（IPA）

設問1は，正答率が高かった。設問にある“チームの特性を生かして”という前提は，正しく理解されているようであった。

本文の根拠

表2

チーム a：0，8，8，27，59，86，70。チーム b：1，2，3，15，29，44，65。

表2

全チーム平均：0.2，3.8，4.0，10.0，30.0，40.0，50。

表2 注3

チーム稼働率は，就業時間に占める顧客対応作業に充てられる時間の割合を表し

まず対象のチームを絞る。チーム稼働率が全チーム平均の50％を超えるのは，チームa（70％）とチームb（65％）の2つである。

次に，この2チームに共通し，かつ平均を上回っている数字を表2から探す。ヒヤリハットの合計はaが86，bが44で，どちらも平均の40.0を上回る。他のチームはc38，d22，e10でいずれも平均以下なので，稼働率の高い2チームだけの特徴になっている。

インシデントの合計で見るとaは8で平均4.0を上回るが，bは3で下回るため共通しない。ヒヤリハットの合計が答えになる。

30字。解答例は「ヒヤリハットの合計件数が全チーム平均より多い。」で23字。

「臨時の作業依頼が多い」はすでに1つ目に書かれている稼働率が高くなる原因なので，2つ目に同じ種類のことを書いてはいけない。設問が求めているのは，稼働率が高いことの結果として表2に現れている特徴である。

採点講評（IPA）

設問2(1)は，チーム稼働率が高いことによる特徴ではなく，チーム稼働率が高くなる原因を述べた誤った解答が多かった。

本文の根拠

表2

チーム c：0，5，5，5，33，38，45。

表2 注2

ヒヤリハットは，顧客業務又はシステムの運用監視業務に影響を与える可能性があった作業の場合は危険，そのほかの場合は軽微と分類している。

インシデントの合計を大きい順に並べると，a が8，c が5，b と d が3，e が1。上位2チームはa とc である。前問の a・b とは組合せが違うので，そのまま引きずらないこと。

この2チームのヒヤリハットを，項目ごとに平均と比べる。

危険：a は27で平均10.0を上回るが，c は5で下回る。共通しない。

合計：a は86で平均40.0を上回るが，c は38で下回る。共通しない。

軽微：a は59，c は33で，どちらも平均30.0を上回る。ここだけが共通する。

30字。解答例は「軽微のヒヤリハット発生件数が全チーム平均より多い。」で25字。

危険なヒヤリハットが多いチームがインシデントを起こす，と考えたくなるが，表2の数字はそうなっていない。あくまで表から読み取れる共通点を答える。

採点講評（IPA）

設問2(2)は，正答率が低かった。上位2チームに共通する傾向を抽出できない誤った解答や，発生傾向ではなく発生原因の傾向を述べた誤った解答が多かった。

本文の根拠

〔パレート図の作成による分析〕

Y 氏は，ヒューマンエラー事象の削減に向けて，ヒューマンエラー事象の原因に着目し，パレート図を用いて分析することによって，改善すべき対象を特定することにした。

図2

（i）データの分類項目を決定する。

本文が「ヒューマンエラー事象の原因に着目し」と書いている。分類項目はここから決まる。図1の9種類の原因である。

表3はチーム別かつ原因別に集計してあるので，チーム名称を分類項目にすることもできる。だが目的は改善すべき対象を特定することで，チームを特定しても「どのチームが多いか」が分かるだけで手の打ちようがない。原因が分かれば，その原因に効く対策を選べる。

20字。解答例は「ヒューマンエラー事象の原因」で13字。

本文の根拠

図2

（iii）分類項目ごとにデータ数の合計を求める。（iv）データ数の合計が大きい順に項目を並べて，棒グラフにする。

手順(iii)で分類項目ごとのデータ数の合計を求め，それを手順(iv)で棒グラフにする。したがって棒の高さは，手順(iii)で求めた値そのものである。

ここでのデータはヒューマンエラー事象なので，縦軸はその合計件数になる。

20字。解答例は「ヒューマンエラー事象の合計件数」で15字。累積比率は手順(v)(vi)で折れ線にするものなので，棒グラフの縦軸ではない。

本文の根拠

表3

合計：46，67，38，16，11，25，5，6，6，総合計 220。

図2

（v）データ数の合計の累積を求め，全体のデータ数に対する百分率を計算し，累積比率（％）とする。

表3の合計行を原因別に大きい順へ並べ替える。②67，①46，③38，⑥25，④16，⑤11，⑧6，⑨6，⑦5。総合計は220。

累積して比率を出す。

② 67 → 67 ÷ 220 ＝ 30％

①まで 113 → 51％

③まで 151 → 69％

⑥まで 176 → 80％

④まで 192 → 87％

⑥を加えたところでちょうど80％に届く。したがって特定するのは②①③⑥の4つである。

分類項目は原因なので，答えも①〜⑨の記号で答える。チームのa〜eで答えると，前問で決めた分類項目と食い違う。

採点講評（IPA）

設問3(3)は，“チームに着目”した誤った解答が多かった。問題管理で重要な原因を抽出するときに利用できるパレート図の技法を理解して，改善活動に活用してほしい。

本文の根拠

〔ヒューマンエラーの状況〕

サービス運用部は，2018 年度に発生したヒューマンエラー事象の合計件数の半減を目指した改善活動を行うことにした。

表3

合計：46，67，38，16，11，25，5，6，6，総合計 220。

何件減らせばよいかと，どこから減らすのかを分けて考える。

減らすべき件数は，全体220件の半分で110件である。

減らす先は，前問で特定した②①③⑥に限る。その合計は 67 ＋ 46 ＋ 38 ＋ 25 ＝ 176件。

176件のうち110件を減らすので，110 ÷ 176 ＝ 0.625。62.5％を四捨五入して63％。

分母を220にすると50％という答えになるが，それでは「改善対象とした分類項目の合計件数の何％か」という問いに答えていない。改善の手を入れるのは176件のほうなので，そこを分母に取る。