平成30年度 秋期 午後Ⅰ

本文の根拠

表2 注2

バッチ処理の最終工程では，それぞれのシステムで使用するデータのフルバックアップを磁気テープに記録している。磁気テープは，システムが稼働している当該サーバ室に保管している。

〔サービス継続計画の検討〕

本社サーバ室から財務会計システムのフルバックアップデータを取り寄せて，データの復元と復元後の確認を行う。

〔被災時の事業継続計画の検討〕

工場は被災した 2 日後から稼働可能である。サーバ室を含む本社は約 1 週間使用できず，全面復旧までには数週間必要である。

磁気テープの置き場所に目を留める。「システムが稼働している当該サーバ室に保管している」とあるので，財務会計システムのバックアップは本社サーバ室にある。サーバと同じ部屋である。

想定しているのは関東地区の大規模地震で，本社サーバ室ごと被災する。サーバもテープも同時に失う。

ところがサービス継続計画は「本社サーバ室からフルバックアップデータを取り寄せて」復元する組立てになっている。取り寄せる先が使えないのだから，この計画は成り立たない。本社は約1週間使用できない。

40字。解答例は「本社サーバ室が被災するとバックアップを含むデータを喪失する。」で29字。「本社が被災する」だけでなく，バックアップまで一緒に失われる点を書く。

採点講評（IPA）

設問1(1)は，バックアップデータの運用に着目していない誤った解答が多く，正答率が低かった。災害発生時にバックアップデータを喪失するリスクを特定し，対策として遠隔地保存が有効であることを理解してほしい。

本文の根拠

表2 注2

磁気テープは，システムが稼働している当該サーバ室に保管している。

〔サービス継続計画の検討〕

BCP 発動から，業務再開フェーズとなるまでの間に，関西地区の支社サーバ室の生産管理サーバとストレージに財務会計システムの稼働環境を整える。

被災するのは関東地区で，関西地区の支社サーバ室は無事である。復旧作業もそこで行う計画になっている。

だから，磁気テープのコピーを関西地区の支社サーバ室にも置いておく。本社が使えなくても，手元にあるテープから復元できる。

同じインシデントで本番とバックアップの両方を失わないよう，離れた場所に置く——災害対策の基本形で，本問では設問3(2)の連絡表でも同じ考え方が出てくる。

35字。解答例は「バックアップの磁気テープのコピーを関西地区のサーバ室にも保管する。」で32字。「遠隔地に保管する」だけでも筋は通るが，本文に関西地区の支社サーバ室という具体的な場所があるので，そこまで書く。

本文の根拠

表2

生産管理システム：8:30〜9:00，9:00〜18:00，18:00〜18:30，18:30〜翌日 1:00。財務会計システム：8:30〜9:00，9:00〜20:00，20:00〜20:30，20:30〜翌日 2:00。

〔サービス継続計画の検討〕

業務再開フェーズでの生産管理システムと財務会計システムの運用は，生産管理システムのオンライン起動処理，オンライン処理及びオンライン停止処理を行った後に，財務会計システムのオンライン起動処理，オンライン処理及びオンライン停止処理を行う。その後，生産管理システムのバッチ処理に続いて財務会計システムのバッチ処理を行う。

まず表2から，オンライン処理以外の所要時間を拾う。オンライン起動処理は両システムとも30分，オンライン停止処理も両システムとも30分。バッチ処理は生産管理が18:30から翌1:00で6時間30分，財務会計が20:30から翌2:00で5時間30分。

開始時刻は前から順に積む。

生産管理のオンライン処理が16:00に終わる → オンライン停止処理30分で16:30 → 財務会計のオンライン起動処理30分で17:00。

開始時刻は17:00。

終了時刻は後ろから戻す。翌日も同じ13:00に生産管理のオンライン処理を始めるので，その30分前の12:30までにオンライン起動処理を始められる状態にしておく必要がある。12:30から逆に引く。

財務会計のバッチ処理 5時間30分 → 7:00

生産管理のバッチ処理 6時間30分 → 0:30

財務会計のオンライン停止処理 30分 → 0:00

終了時刻は0:00（24:00）。

順に並べると，17:00〜24:00がオンライン処理，24:00〜0:30が停止処理，0:30〜7:00が生産管理のバッチ処理，7:00〜12:30が財務会計のバッチ処理となり，翌日の12:30にちょうど間に合う。バッチ処理の順番が「生産管理→財務会計」と決まっているので，入れ替えて計算しないこと。

本文の根拠

表3

財務会計業務：RTO 2，RPO 前日の終業時点，RLO 25.0。

表1 注2

財務会計業務では，財務会計端末からオンライン処理で会計伝票を入力し，会計データベース（以下，会計 DB という）を更新している。

いまのRPOは「前日の終業時点」である。ここまでしか戻せないということは，当日オンライン処理で入力した会計伝票は，障害が起きるとすべて消える。

RPOを障害発生時点にできれば，当日入力したぶんもそのまま残る。

利用者にとっての利点を聞かれているので，システム側の話ではなく，財務部の人が何をせずに済むかで答える。消えた伝票は誰かが入れ直さなければならないので，その再入力が要らなくなる。

40字。解答例は「オンライン処理で入力した障害発生時点までの会計伝票の再入力が不要になる。」で35字。

採点講評（IPA）

設問2(1)は，正答率が高かった。RPOを前日の終業時点から障害発生時点とすることによる業務運用上の利点については，理解されているようであった。

本文の根拠

表2 注1

生産管理システムでは，DB 更新ログを生産管理システムのストレージに記録している。同様に，財務会計システムでは，DB 更新ログを財務会計システムのストレージに記録している。

〔財務会計システムの運用の検討〕

障害発生直前までの DB 更新ログの情報を用いて，会計 DB を回復する。

〔サービス継続計画の検討〕

関西地区にある生産管理システムのストレージには現在余裕があり，必要な容量を確保可能である。

回復の手順は，フルバックアップで当日のオンライン起動処理直前まで戻し，そこからDB更新ログで障害発生直前まで進める，というものである。この後半にはDB更新ログが要る。

ところがDB更新ログは財務会計システムのストレージ，つまり本社サーバ室にある。本社が被災すればログも失われる。磁気テープを関西地区に置いても，そこから先を埋める材料が無く，結局前日の終業時点までしか戻せない。

対策は，DB更新ログを関西地区の生産管理サーバのストレージにも書くことである。ストレージには余裕があると本文が断っている。設問が「オンライン処理で変更する内容」と指定しているのは，DB更新ログを取るのがオンライン処理だからである。

35字。解答例は「DB更新ログを支社の生産管理サーバのストレージにも取得する。」で30字。「にも」が要点で，本社側の記録をやめるわけではない。

本文の根拠

〔訓練の実施〕

連絡表に記載されていたのは，担当者が複数の場合はその担当者の代表者 1 名であり，代表者の電話番号が最新化されていなかった。

〔訓練の実施〕

連絡表の内容を見直し

判明した問題点は2つある。代表者1名しか載っていないことと，その電話番号が古かったことである。

後者への手当ては，下線（イ）に続けて「定期的に連絡先が最新かどうかを確認することにした」と本文に書いてある。つまり下線（イ）の「内容を見直し」が受け持つのは前者のほうである。

代表者1名だけだと，その人に繋がらなければそこで止まる。訓練で財務部の担当者への連絡に想定以上の時間が掛かったのもこれが理由である。だから複数の担当者の連絡先を載せる。

30字。解答例は「複数の担当者の連絡先を登録するように変更する。」で23字。電話番号の最新化を書くと，直後の一文と重なってしまう。

本文の根拠

〔訓練の実施〕

最新の連絡表の情報は，本社ファイルサーバに保存し，連絡表を各部門に配付することになっている。

図1

支社（関西地区）のサーバ室には，生産管理システム（生産管理サーバとストレージ，ストレージ内に生産計画 DB）が置かれ，同じ LAN に運用端末と，共有ファイルシステムである支社ファイルサーバが接続されている。

図1 注記2

共有ファイルシステムは，情報を共有するために利用するシステムであり，生産管理端末，財務会計端末及び運用端末から利用できる。

設問が「図1中の装置を活用して」と限っているので，新しい機器を足す答えは外れる。図1にある共有ファイルシステムを数えると，本社ファイルサーバと支社ファイルサーバの2つがある。

最新の連絡表は本社ファイルサーバにしか無い。本社が被災すれば読めない。訓練でまさにこれが起きた。

支社ファイルサーバは関西地区にあるので被災しない。ここにも保存しておけば，本社が使えなくても参照できる。しかも注記2のとおり，共有ファイルシステムは各端末から利用できる。

40字。解答例は「最新の連絡表の情報を支社ファイルサーバにも保存し，被災時でも参照可能にする。」で37字。設問1(2)の磁気テープと同じで，同じインシデントでまとめて失わない場所に置く，という考え方である。

採点講評（IPA）

設問3(2)は，正答率が高かった。連絡表などの文書を含む重要な情報を同じインシデントで同時に被災しない場所に保存することについては，理解されているようであった。

本文の根拠

表1 システム運用課

PG を稼働環境にデプロイする場合は，LB の設定変更によって，社員 PC からの受注管理サービスに対する要求振分け先を Sorry サーバに変更し，全ての AP サーバのサービスを停止する。

表2 AP展開ツール

受注管理サービスの利用に影響を与えないように，振分け先の AP サーバを LB で制限し，稼働環境の AP サーバ 1 台ごとに PG を順次デプロイする。

表2 AP展開ツール

データベースのテーブル定義変更などの場合は，保守作業時間帯を設けて受注管理サービスを停止させる必要があるので，変更内容に応じて，使用可否を判断する。

従来のやり方では，全てのAPサーバを止めて，社員PCからの要求をSorryサーバへ向けていた。つまりデプロイのたびに受注管理サービスが止まる。

AP展開ツールは1台ずつ順に入れ替える。1号機を入れ替えている間は2号機と3号機が要求を受けるので，サービスは動いたままである。

ただし常にそうとは限らない。表2の但し書きのとおり，データベースのテーブル定義変更などでは，結局サービスを止める必要がある。だから「停止しなくて済む場合がある」と幅をもたせて書く。

40字。解答例は「稼働環境にデプロイするときにサービスを停止しなくて済む場合がある。」で32字。

設問が除外している「要望の実現」「反復的な開発」「作業ミスの防止・品質向上」は，いずれも本文に書いてある狙いである。残るのはサービスを止めずに済むという点になる。

本文の根拠

〔受注管理サービスのインシデント発生と対応〕

プログラムの不具合によって，DB サーバの在庫管理ファイルの一部に誤りが発生しており，在庫管理ファイルの誤り修正作業が必要であることが判明した。

表3 手順5

手順5（閉塞の解除）：LB の要求振分け先の設定を変更し，LB から AP サーバ 1 号機に対する閉塞を解除する。

在庫管理ファイルの誤りは，プログラムの不具合が生んだものである。だから不具合のあるプログラムが動いたままファイルだけ直しても，同じ不具合がまた誤りを作る。先に直すべきはプログラムのほうである。

手順の面からも説明できる。AP展開ツールは手順5で閉塞を解除する。ファイル修正のためにLBを閉塞してから，あとでAP展開ツールを走らせると，ツールが閉塞を解除してしまい，APサーバからDBサーバへの通信が起きる。「通信が発生しない状態で行う必要がある」という条件が崩れる。

30字。解答例は「プログラムの不具合によって再度誤りが発生してしまうから」で26字。閉塞の解除に着目して「AP展開ツールによってLBの閉塞解除が行われるから」と書いてもよい。

採点講評（IPA）

設問2(1)は，正答率が高かった。プログラムを稼働環境にデプロイする前にファイルの修正作業を実施すると起きるおそれのある問題点については，理解されているようであった。

本文の根拠

〔ツールによるデプロイの自動化〕

東京本社の 22 時は欧州支社では 14 時であり，業務に影響を与えるので，PG を稼働環境にデプロイする時間帯を変更してほしい。

〔ツールによるデプロイの自動化〕

欧州支社の 1 時間の休憩時間帯の開始時刻に当たる東京本社の 20 時に作業の開始を前倒しする案を検討した。

〔受注管理サービスのインシデント発生と対応〕

10 月 4 日（木）20 時から，不具合を修正したプログラムについて AP 展開ツールを使用して稼働環境にデプロイする作業を開始し，20 時 30 分に完了した。その後，在庫管理ファイルの誤り修正作業を開始し，20 時 50 分に完了した。

時差を押さえる。東京の22時は欧州の14時で，欧州支社は業務のまっただ中である。東京の20時なら欧州の12時で，1時間の休憩時間帯が始まる時刻に当たる。

今回の作業はAP展開ツールによるデプロイだけではない。そのあとにLBを閉塞して在庫管理ファイルを直すので，その間はサービスが使えない。22時に始めれば，欧州の利用者が業務をしている最中にサービスを止めることになる。

実際の記録を見ると，20時開始で20時50分に完了している。欧州時間の12時から12時50分で，休憩時間帯の中に収まった。

40字。解答例は「欧州支社のサービス利用者が利用中の時間帯であり，業務に影響があるから」で33字。「欧州支社に配慮して」だけでは，なぜ20時なのかが言えていない。時差と休憩時間帯に触れる。

本文の根拠

図1 注3

新規システム開発のテスト及び適応保守で修正したプログラムのテストを行う。

図1 注4

プログラムの不具合対応などの是正保守で修正したプログラムのテストを行う。

表1 システム運用課

稼働環境の維持・運用だけでなく，システム開発課が円滑にテストできる開発環境・保守環境を維持するために，次に示す作業を行う。

〔受注管理サービスのインシデント発生と対応〕

売上プログラム及び共通プログラムに不具合があることが判明した。

テスト用サーバには開発環境と保守環境の2つがあり，役割が分かれている。開発環境は適応保守のテスト用，保守環境は是正保守のテスト用である。

今回のインシデント対応は不具合の修正なので是正保守に当たり，テストは保守環境で行われた。つまり修正後の売上プログラムと共通プログラムは保守環境にしか入っていない。

一方，業務ルールの変更は適応保守なので，そのテストは開発環境で行う。開発環境の共通プログラムは，不具合を直す前の古いままである。このままでは正しいテストができない。

そこでシステム運用課は，修正済みの売上プログラムと共通プログラムを開発環境にもデプロイする。デプロイは表1のとおりシステム運用課の役割で，ソースコードの修正やテストはシステム開発課の役割である。設問が「システム運用課が」と限っているので，そこを踏み外さない。

40字。解答例は「売上プログラムと共通プログラムをテスト用サーバの開発環境にデプロイする。」で35字。

採点講評（IPA）

設問3(1)は，システム運用課の役割に着目していない解答が多く，正答率が低かった。ソースコードの修正やテストなどシステム開発課が実施すべき内容を書いた誤った解答が多かった。

本文の根拠

〔受注管理サービスの変更〕

受注管理サービスの変更について，システム開発課で調査した結果，請求プログラム及び共通プログラムの修正が必要であることが分かった。

〔受注管理サービスのインシデント発生と対応〕

売上プログラム及び共通プログラムに不具合があることが判明した。

2つの変更で修正対象を並べると，業務ルール変更が「請求プログラムと共通プログラム」，インシデント対応が「売上プログラムと共通プログラム」である。共通プログラムが両方に出てくる。

業務ルール変更のソースコード修正は，10月3日に承認された時点ですでに終わっていた。その後10月4日に，共通プログラムの不具合修正が稼働環境へ入った。つまり業務ルール変更用の共通プログラムには，その不具合修正が入っていない。

このままデプロイすると，10月4日に直したはずの不具合が稼働環境に戻る。だから不具合修正の内容を取り込む。

25字。解答例は「共通プログラムの不具合修正内容を反映すること」で22字。

本文の根拠

表1 システム開発課

新規に作成した PG の誤りを検出するためのテストのほか，PG を更新したことによって想定外の影響が出ていないかどうかを確認するためのテストなどを行う。

表1はシステム開発課が行うテストを2種類に分けている。新しく作った部分の誤りを見つけるテストと，更新したことで想定外の影響が出ていないかを確かめるテストである。

共通プログラムは，業務ルール変更のために直したところへ，さらに不具合修正を取り込んだ。共通プログラムは請求プログラムからも売上プログラムからも使われるので，一方の修正が他方の動きを変えていないとは言い切れない。

だから足すのは後者のテストである。不具合が直っているかを確かめるだけでは，取り込んだことで他が壊れていないかは分からない。

40字。解答例は「不具合を修正することによって，想定外の影響が出ていないかどうかを確認する。」で36字。

採点講評（IPA）

設問3(3)は，不具合を修正することによって想定外の影響が出ていないかどうかを確認する趣旨の内容を期待したが，不具合の修正確認だけを指摘する誤った解答が多かった。問の表に整理されているシステム開発課とシステム運用課の役割を理解して，解答を導き出してほしい。

本文の根拠

表2 段階的取扱い

インシデントがタイプ2又はタイプ3に該当する場合は，サービスデスクが回答期限を定めて技術課に解決を依頼する。これを，機能的エスカレーションという。

〔エスカレーションの手順における問題点とその改善策〕

技術課の技術者の回答期限が迫っている場合，サービスデスクは技術者に回答を督促していた。しかし，技術者からの解決手順の指示又は解決の結果の回答が回答期限に遅れることがあった。

〔エスカレーションの手順における問題点とその改善策〕

エスカレーション先は，顧客に対するサービス責任者である S 氏とし，インシデント対応の手順“解決”に関与することによって，組織的なインシデント対応を行うことにした。

すでにあるのは機能的エスカレーション，つまり技術課へ解決を依頼する動きである。足りないのは横ではなく上へ上げる動きで，ここに入るのは権限のある人へ上げる階層的エスカレーションである。

サービスデスクが技術者を督促しても効かないのは，技術者の側が変更作業を優先していて，インシデント対応を後回しにしているからである。同じ立場からの督促では順番が変わらない。

本文は「S氏とし，インシデント対応の手順“解決”に関与することによって」と，S氏が何をするかまで示している。S氏から技術課に対して，このインシデント対応を優先してもらうよう働きかける，というのが具体的な中身になる。

30字。解答例は「技術課に対してインシデント対応を優先してもらうための依頼」で27字。「S氏へのエスカレーション」とだけ書くと，上げた先で何が起きるのかが言えていない。

採点講評（IPA）

設問1(1)は，正答率が低かった。解決目標時間を達成できないおそれがある場合に必要な段階的取扱い（エスカレーション）について，理解していないと思われる解答が多く見られた。また，具体的な記述を求めたにもかかわらず，本文中の記載を抜き出しただけの誤った解答も見られた。

本文の根拠

〔エスカレーションの手順における問題点とその改善策〕

IT インフラ群の変更作業を計画的に実施していることから，サービスデスクからインシデントの解決の依頼を受けた場合に，解決手順の指示，技術者自身での解決を後回しにしてしまうことがある。

〔エスカレーションの手順における問題点とその改善策〕

技術者は，毎日始業時に当日の作業計画を策定し，作業を計画的に実施していた。

後回しになる理由は，技術者のヒアリングにはっきり出ている。変更作業を計画的に実施しているからである。

インシデントはいつ来るか分からないので，始業時に立てた作業計画には入っていない。計画した変更作業で1日が埋まっていれば，割り込みで来たインシデント対応は押し出される。悪意でも怠慢でもなく，計画の作り方から来ている。

だから課長が調べるべきは，作業計画にインシデント対応のための時間が取ってあるかどうかである。取っていなければ，回答期限を守れという要請だけでは変わらない。

40字。解答例は「作業計画策定のときに想定されるインシデント対応の作業時間を確保していること」で36字。

本文の根拠

〔タイプ1の比率向上への取組〕

二つ目は，IT インフラ群の使用状況を可視化している“ダッシュボード”の機能拡充のような，サービスを変更した際に発生するインシデントであり，タイプ 3 全体の 3 割程度を占めていた。これらはサービス変更後の短期間に集中して発生する。

〔タイプ1の比率向上への取組〕

サービスデスクにおいては，インシデントの再発に備えて，タイプ 2 及びタイプ 3 のインシデントが解決した後に，インシデントの解決手順をノウハウ DB に登録し，技術課に登録内容の確認を依頼する。

ヒアリングでは，サービスデスクで解決できるものが2種類に分けられている。再発性のあるもの（半数以上）と，サービスを変更した際に発生するもの（3割程度）である。

1つ目は，1つ目の提案が拾う。解決したあとに手順を登録しておけば，2回目以降はサービスデスクで対応できる。

2つ目は同じやり方では間に合わない。「サービス変更後の短期間に集中して発生する」ので，起きてから登録していては，登録が終わるころには集中する時期が過ぎている。先回りするしかない。

だから技術課が，サービスを変更する前に，想定されるインシデントの解決手順をあらかじめ登録しておく。

30字。解答例は「サービスを変更した際に想定されるインシデントの解決手順」で26字。「想定される」が肝で，まだ起きていないものを先に用意するところが1つ目との違いである。

採点講評（IPA）

設問2(1)は，ヒアリング結果を的確に分析できていない解答が多かった。サービスデスクで解決できるインシデントの比率向上のために，ヒアリング結果から判明したインシデント発生の傾向に対して，どのような取組が適切かを考察してほしい。

本文の根拠

表1

タイプ2：サービスデスクがノウハウ DB だけではインシデントを解決できない場合，技術課に解決を依頼する。

〔タイプ1の比率向上への取組〕

S 氏は，解決時間について，タイプ1がタイプ2及びタイプ3に比べて短い点に着目し，“タイプ 1 の比率が増加すれば，インシデントの平均解決時間は短くなる”と考えた。

〔エスカレーションの手順における問題点とその改善策〕

IT インフラ群の変更作業を計画的に実施していることから，サービスデスクからインシデントの解決の依頼を受けた場合に，解決手順の指示，技術者自身での解決を後回しにしてしまうことがある。

タイプ1が増えるということは，タイプ2とタイプ3が減るということである。タイプ2とタイプ3は，どちらも技術課に解決の依頼が来るものである。

つまり技術課へ回ってくる件数そのものが減る。技術者は計画した変更作業に集中でき，割り込みで後回しが起きる状況も和らぐ。

提案を実行するには技術者が解決手順を文書化する手間が要るが，それは1件につき一度だけで，以後の同種のインシデントは技術課の手を離れる。差し引きで負担が軽くなる，というのが同意した理由である。

40字。解答例は「技術課が行うインシデント対応の作業負荷が低減するから」で25字。

採点講評（IPA）

設問2(2)は，正答率が高かった。サービスデスクで解決できるインシデントの比率向上が，機能的エスカレーション先の業務効率化に資することは理解されているようであった。

本文の根拠

〔サービスデスクの業務拡大〕

サービス利用者からの変更要求の頻度は高く，内容的に失敗するリスクが低い作業である。

〔サービスデスクの業務拡大〕

今後，サービスデスクで変更要求の処理を行えるようにするには，変更管理プロセスに従って，IaaS 事業部として事前に認可を受ける必要がある。

〔インシデント対応の概要〕

インシデントの解決手順をノウハウ DB に追加する場合，及び既存の解決手順に問題点又は改善点があってノウハウ DB を更新する場合は，サービスデスクではなく，内容の妥当性が判別でき専門知識がある技術課が対応する。

本文が挙げる3つの条件——頻度が高い，失敗するリスクが低い，事前に認可を受ける——は，標準変更の要件そのものである。標準変更にすれば，あらかじめ承認された手順に従うので，そのつど変更審査会にかける必要がなくなる。

では誰が手順を作るか。本文の分担では，手順の妥当性を判別できるのは専門知識のある技術課で，サービスデスクではない。ノウハウDBの登録が技術課の役目になっているのと同じ理屈である。

したがって技術課が実施すべきは，サービスデスクがそのまま実施できる形に標準変更の手順を整えることである。

40字。解答例は「サービスデスクで実施できるように標準変更の手順を整備する。」で28字。「誰が使う手順か」を落とさない。

本文の根拠

〔サービスデスクの業務拡大〕

変更要求は，A 社の変更管理プロセスに従って，週 1 回実施している社内の変更審査会の前日までに申請が必要であり，変更審査会で承認を受けてから，翌日以降に行う作業である。

〔サービスデスクの業務拡大〕

サービスデスクで行う変更要求の処理は，優先度“低”として行うことにした。

表2 優先度の割当て

優先度によって解決目標時間が定められている（優先度“高”：2 時間，優先度“中”：4 時間，優先度“低”：8 時間）。

いまの流れを日数で追う。変更審査会は週1回で，その前日までに申請し，承認を受けてから翌日以降に作業する。申請のタイミングによっては1週間以上待つことになる。

サービスデスクで処理できるようになれば，審査会を待たない。優先度“低”として扱われるので解決目標時間は8時間。サービスデスクの受付時間帯は平日9〜17時の8時間なので，依頼した当日か翌営業日には終わる。

顧客にとっての利点は，依頼してから実施されるまでの期間が短くなることである。

30字。解答例は「変更要求の依頼から実施までの期間が短くなる。」で22字。解決目標時間から逆算して「1営業日以内となる」と具体的に書いてもよい。