応用情報技術者 2024年 春期 午後 問10
テレワーク環境下のサービスマネジメントに関する次の記述を読んで、設問に答えよ。
E社は、東京に本社があり、全国に3か所の営業所をもつ、従業員約200名の保険代理店である。E社には、保険商品の販売や顧客サポートを行う営業部、入出金処理や伝票処理を行う経理部、情報システムの開発と運用を行う情報システム部などの部署がある。営業部の従業員(以下、営業員という)は、営業先に出向いて業務を行うことが多く、その際の顧客サポートの質の向上が課題となっている。
E社の従業員には、ノートPCが一人1台貸与され、一部の営業員には、ノートPCとは別にタブレット端末が貸与されている。ノートPCやタブレット端末(以下、これらを社内デバイスという)では、本社内に設置しているサーバのアプリケーションソフトウェア(以下、業務アプリという)と、電子メール送受信やスケジュール管理を行うことができるグループウェア(以下、業務アプリとグループウェアを合わせて社内IT環境という)の利用が可能である。社内デバイスは、社外から社内IT環境へのネットワーク接続は行えない。
E社の情報システム部には、開発課と運用課がある。開発課は、各部署が利用する社内IT環境の企画・開発を行う。運用課は、管理者のF課長、運用業務の取りまとめを行う主任及び数名の運用担当者で構成され、サーバなどのIT機器の管理だけでなく、次のITサービスを提供している。
・社内IT環境の運用
・従業員からの問合せやインシデントの対応を受け付けるサービスデスク
〔社内IT環境とサービスマネジメントの概要〕
現在の社内IT環境とサービスマネジメントの概要を次に示す。
・営業員は、社内IT環境から営業活動に必要なデータを、社内でタブレット端末にダウンロードし、営業先ではタブレット端末をスタンドアロンで使用している。
・社内デバイスのOSを対象に、セキュリティ修正プログラムを含むOSバージョンのアップデート(以下、OSパッチという)を実施している。
・OSパッチを適用するには、社内デバイスのシステム設定で自動適用と手動適用のいずれか一方を設定する必要がある。現在は手動適用に設定している。
・OSパッチを適用すると、社内デバイスで業務アプリを正常に利用できなくなるおそれがある。そこで、OSパッチの展開管理に責任をもつ運用課は、OSパッチが公開されると、まず、開発課にOSパッチを適用した社内デバイスでテストを行い、業務アプリを正常に利用できることを確認するように依頼する。業務アプリを正常に利用できることを確認後、運用課から、従業員に社内デバイスを操作してOSパッチを手動適用するように依頼する。
・従業員からの問合せやインシデントに対応するために、従業員が使っている社内デバイスの操作が必要な場合がある。サービスデスクは、従業員が社内デバイスを利用している場所が本社のときは対面でサポートを行い、営業所のときは電話でサポートを行っている。ただし、サービスデスクでは、電話でのサポートは時間が掛かるという問題を抱えている。
・サービスデスクだけでインシデントをタイムリーに解決できない場合、開発課への a を行うことがある。
〔テレワーク環境の構築の計画〕
営業部の課題を解決するため、全ての営業員にタブレット端末を貸与し、社外からインターネットを介して社内 IT環境に接続可能なテレワーク環境を、開発課が構築し、運用課が運用することになった。なお、テレワーク環境は、当初はタブレット端末だけの利用とするが、社会情勢の変化を受けて在宅勤務などで、ノート PCにも今後利用を拡大する予定である。
テレワーク環境では、サービスデスクは、社外でタブレット端末を使う営業員からの問合せやインシデントに、営業所の場合と同様に、電話によるサポートで対応する。
〔テレワーク環境の運用の準備〕
F 課長は、テレワーク環境の運用の準備に着手した。
テレワーク環境の利用開始直後は、営業員から問合せが多発するとやインシデントの発生が想定された。F 課長は、テレワーク環境の利用開始から安定稼働になるまでの間は、開発課による初期サポートが必要と判断し、開発課に依頼して初期サポート窓口を開発課に設けることを計画した。ただし、開発課による初期サポートの実施中は、問合せ先及びインシデントの連絡先を営業員自身が判断し、テレワーク環境については初期サポート窓口に、その他についてはサービスデスクに対応を依頼することとなる。F課長は、利用開始後のテレワーク環境に関する問合せとインシデントの対応が b ことで、テレワーク環境の安定稼働の余地と考えた。また、初期サポート窓口の設置は、テレワーク環境の利用開始後から4週間を目安とし、テレワーク環境に関する問合せとインシデントの対応が b ことを初期サポートの終了基準とし、終了基準を満たすまで、初期サポート窓口を継続する。
サービスデスクは本来、機能的にSPOC (Single Point of Contact) とするのが望ましい。そこで、F課長は、①SPOCを実現する時期の判断のために、テレワーク環境の問合せ対応に関して、初期サポートが終了するまでに開発部から c ことも初期サポートの終了基準として設けるべきであると考えた。F課長は、これらの計画について営業部と開発部に説明して了承を得た。
次に、F課長は、タブレット端末をもつ営業員が増え、又は社外での利用機会が拡大すること、及び今後ノートPCを利用した在宅勤務が予定されていることから、社内デバイスの利用状況の管理を効率的に行う必要があると考えた。そこで、現状の人手による管理に代えて、社内デバイスの利用状況を統合的に管理することができるツール(以下、統合管理ツールという)を導入することにした。F課長は、G主任に統合管理ツールの調査を指示し、G主任は、統合管理ツールの機能と概要を表1にまとめた。

G主任は、調査結果をF課長に説明した。F課長は、現在実施しているOSパッチの手動適用では、従業員がOSパッチの適用のタイミングをコントロールできてしまうことから、OSパッチの適用に不確実さがあることを問題視していた。F課長は、パッチ適用機能を使うことで、展開管理としてOSパッチを確実に適用できると考えた。F課長は、パッチ適用機能の実現には、テスト済みのOSパッチを配信用サーバに登録する手順の追加が必要であることを主任に指摘し、検討するように指示した。そこで、F課長は、テレワーク環境の利用開始時点では、統合管理ツールのパッチ適用以外の機能を使用し、②現在、サービスデスクで行っているサポートの問題を解決することにした。
〔パッチ適用機能の使用〕
テレワーク環境の構築が完了し、営業員によるテレワーク環境の利用が開始された。初期サポート窓口での対応は、終了基準を満たして、計画どおり4週間で終了した。テレワーク環境はおおむね好評で、営業員のタブレット端末の利用頻度が上がり、タブレット端末による営業活動への効果が向上していた。一方で、以前から、営業部では、運用課からの指示がないにもかかわらずOSパッチを手動適用したり、指示したにもかかわらず手動適用を忘れたりして、社内デバイスで業務アプリを正常に利用できないというインシデントが発生しており、現在も営業活動に影響が出ていた。
この状況を受けて、F課長は、“今後のインシデント発生を防止するという問題管理の視点から有効である”だけでなく、展開管理の視点からも有効である”と考えて、早期に③パッチ適用機能の使用を開始することにし、G主任にその後の検討状況の報告を求めた。G主任は、展開管理の手順の検討結果を報告し、F課長は了承した。aG主任は、パッチ適用機能を実現するためには、現在、手動適用の運用をしている社内デバイスの設定を変更する準備作業が必要となることを報告した。報告を受けたF課長は、準備が整い次第、パッチ適用機能を使用することを決定した。
設問1:
本文中のaに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:アセスメント
イ:エスカレーション
ウ:ガバナンス
エ:コミットメント
模範解答
a:イ
解説
解答の論理構成
- 文脈の把握
- 【問題文】では、サービスデスクが対応し切れない場合の流れとして
「サービスデスクだけでインシデントをタイムリーに解決できない場合、開発課への a を行うことがある。」
と記載されています。
- 【問題文】では、サービスデスクが対応し切れない場合の流れとして
- ITサービスマネジメント(ITSM)の用語確認
- サービスデスクで解決できないインシデントを上位組織や専門部署へ引き継ぐ行為は、ITIL などで「エスカレーション」と呼ばれます。
- 解答群との照合
- ア:アセスメント … 評価・査定
- イ:エスカレーション … 引き上げ・上位への対応依頼
- ウ:ガバナンス … 統治・管理
- エ:コミットメント … 約束・コミット
上記のうち、サービスデスクが解決できないインシデントを「開発課へ持ち上げる」行為を表す語は「エスカレーション」です。
- 結論
よって a に入る適切な字句は「イ:エスカレーション」となります。
誤りやすいポイント
- 「アセスメント」「ガバナンス」などカタカナ用語の意味を曖昧に覚えていると選択を誤りやすいです。
- “コミットメント”を「依頼」や「引き渡し」と誤解し、引継ぎ行為と結び付けてしまうケースがあります。
- サービスデスクに関する ITIL 用語を体系的に覚えておらず、現場感覚で選んでしまうと失点につながります。
FAQ
Q: エスカレーションには種類がありますか?
A: はい。運用ルールに基づく「機能的エスカレーション(専門部署へ)」と「階層的エスカレーション(管理職へ)」が代表的です。
A: はい。運用ルールに基づく「機能的エスカレーション(専門部署へ)」と「階層的エスカレーション(管理職へ)」が代表的です。
Q: エスカレーション判断の基準はどのように決めるべきですか?
A: サービスレベル目標(SLA)やインシデントの影響度・緊急度を元に、時間や条件を明記した運用手順書で定義します。
A: サービスレベル目標(SLA)やインシデントの影響度・緊急度を元に、時間や条件を明記した運用手順書で定義します。
Q: エスカレーション後のフォローアップは必要ですか?
A: 必要です。サービスデスクは進捗を追跡し、解決後にナレッジ化して再発防止や対応時間短縮に役立てます。
A: 必要です。サービスデスクは進捗を追跡し、解決後にナレッジ化して再発防止や対応時間短縮に役立てます。
関連キーワード: インシデント管理, サービスデスク, SPOC, SLA, ITIL
設問2:〔テレワーク環境の運用の準備〕について答えよ。
(1)本文中のbに入れる内容を15字以内で答えよ。
模範解答
b:「収束した状態になる」
または
「サービスデスクだけでできる」
または
「定常状態に落ち着く」
解説
解答の論理構成
-
現状認識
【問題文】では、テレワーク環境の立ち上げ直後は「営業員から問合せが多発するとやインシデントの発生が想定された」とあります。つまり、当初は問い合わせ・インシデントが多く、サービスデスク単独では処理しきれない状況です。 -
初期サポート窓口の目的
同じ段落に「開発課に依頼して初期サポート窓口を開発課に設ける」と記載されており、問い合わせが多い期間はサービスデスクと開発課の二本立てで対応する設計です。 -
終了基準の条件設定
F課長は「初期サポート窓口の設置は…テレワーク環境に関する問合せとインシデントの対応が b ことを初期サポートの終了基準」としています。ここでいう終了基準は「通常運用に戻しても支障がない状態」を示します。 -
「通常運用」とは
【問題文】冒頭でサービスデスクの望ましい姿として「機能的にSPOC (Single Point of Contact) とするのが望ましい」と明示されています。したがって、初期サポート終了後は“サービスデスクのみ”で問い合わせ・インシデントが処理できる=件数が落ち着き、対応も安定している状態が求められます。 -
結論
以上から b には「対応が収束し、サービスデスクだけで通常対応できる安定状態」を表す語句が入ります。模範解答例にある
「収束した状態になる」
が最も端的で適切です。
誤りやすいポイント
- 「問い合わせゼロ」や「インシデントが発生しない」など、過度に理想的な状態を想定してしまう。実際は“収束”が目標であって、完全消滅ではありません。
- SPOC の説明に引きずられて “窓口を一本化する”という表現をそのまま入れると、[b] が「一本化すること」と読めて不自然になります。
- 終了基準=4週間と早合点し、日数や期間を直接答えてしまう。日数はあくまでも目安であって、条件そのものではない点に注意が必要です。
FAQ
Q: 「収束した状態」と「サービスデスクだけでできる」はどう違いますか?
A: 意味合いは同じです。「収束した状態」は件数・内容とも落ち着いたことを示し、「サービスデスクだけでできる」は組織体制の観点から安定したことを示しています。試験ではどちらも意図を満たす同義語として許容されています。
A: 意味合いは同じです。「収束した状態」は件数・内容とも落ち着いたことを示し、「サービスデスクだけでできる」は組織体制の観点から安定したことを示しています。試験ではどちらも意図を満たす同義語として許容されています。
Q: なぜ“安定稼働”ではなく“収束”が採用されるのですか?
A: “安定稼働”はシステム全体を指す広い表現で、問合せ/インシデントというサポート領域の状態を直接示していません。“収束”はサポート工数が通常レベルに戻る具体的な指標を表すため、より適切です。
A: “安定稼働”はシステム全体を指す広い表現で、問合せ/インシデントというサポート領域の状態を直接示していません。“収束”はサポート工数が通常レベルに戻る具体的な指標を表すため、より適切です。
Q: SPOC の実現時期と [b] には因果関係がありますか?
A: あります。[b] の状態になって初めて初期サポートが終了し、その後に「SPOC を実現する時期の判断」のための情報が開発課から提供されます。
A: あります。[b] の状態になって初めて初期サポートが終了し、その後に「SPOC を実現する時期の判断」のための情報が開発課から提供されます。
関連キーワード: インシデント, SPOC, 問題管理, サービスデスク, 展開管理
設問2:〔テレワーク環境の運用の準備〕について答えよ。
(2)本文中の下線①とすることのメリットは何か。営業員にとってのメリットを25字以内で答えよ。
模範解答
営業員による問合せ先の判断が不要になること
解説
解答の論理構成
- 現状の問題点
・問題文には「開発課による初期サポートの実施中は、問合せ先及びインシデントの連絡先を営業員自身が判断し、テレワーク環境については初期サポート窓口に、その他についてはサービスデスクに対応を依頼することとなる。」とあり、営業員が毎回「どこに連絡すべきか」を判断しなければならない状況が示されています。 - 目指す姿(下線①)
・同じく問題文で「サービスデスクは本来、機能的にSPOC (Single Point of Contact) とするのが望ましい。」と述べられています。SPOCとは問合せ窓口を一本化し、利用者が迷わず対応を依頼できる形です。 - メリットの整理
・SPOCが実現すると、営業員は「テレワークかその他か」を区別せず、常に同じ窓口へ連絡すればよくなります。 - 結論
・以上より、下線①を実施することで得られる営業員側のメリットは「問合せ先を自分で判断する手間がなくなる」ことです。
誤りやすいポイント
- 「SPOC=サービスデスク一本化」だけに注目し、利用者(営業員)の負担軽減という視点を忘れる。
- インシデント解決の迅速化をメリットに挙げ、営業員が窓口選択で迷わなくなる点を記載しない。
- サービスデスク側の運用効率をメリットに書いてしまい、設問が求める「営業員にとって」の観点を外す。
FAQ
Q: なぜ営業員の判断負荷が問題になるのですか?
A: 営業員は本来の業務である顧客対応が中心です。窓口選択で迷う時間は業務効率を下げ、対応遅延にもつながるためです。
A: 営業員は本来の業務である顧客対応が中心です。窓口選択で迷う時間は業務効率を下げ、対応遅延にもつながるためです。
Q: SPOCが実現するとサービスデスクの負荷は増えませんか?
A: 一時的に増える可能性はありますが、窓口分散による重複対応や連絡漏れが減り、結果的に全体最適が期待できます。
A: 一時的に増える可能性はありますが、窓口分散による重複対応や連絡漏れが減り、結果的に全体最適が期待できます。
Q: 初期サポート終了後にSPOCへ戻すタイミングはどう決まりますか?
A: 問題文の「初期サポートが終了するまでに開発部から c ことも初期サポートの終了基準」という条件を満たし、安定稼働が確認できた時点です。
A: 問題文の「初期サポートが終了するまでに開発部から c ことも初期サポートの終了基準」という条件を満たし、安定稼働が確認できた時点です。
関連キーワード: SPOC, インシデント管理, サービスデスク, 問合せ窓口, 運用効率
設問2:〔テレワーク環境の運用の準備〕について答えよ。
(3)本文中のcに入れる内容を25字以内で答えよ。
模範解答
c:「初期サポート内容の引継ぎが完了している」
または
「初期サポート窓口での対応内容の確認が完了している」
解説
解答の論理構成
-
問題文の該当箇所
“F課長は、①SPOCを実現する時期の判断のために、テレワーク環境の問合せ対応に関して、初期サポートが終了するまでに開発部から c ことも初期サポートの終了基準として設けるべきであると考えた。”
─ ここでは「SPOC(Single Point of Contact)」に一本化するため、初期サポート窓口(開発課)からサービスデスク(運用課)への知識や対応手順の移譲が必須であると読み取れます。 -
SPOC の成立条件
・SPOC実現には「問合せ窓口を一か所に統合し、必要な対応ノウハウを共有している」ことが不可欠です。
・従って、初期サポートを担当していた開発課が蓄積した対応内容を、恒常窓口であるサービスデスクへ確実に渡す必要があります。 -
文脈上求められる情報
“初期サポートが終了するまでに開発部から c こと” とあるため、c には「開発部(=開発課)→運用課(サービスデスク)へどのような状態になっているか」を示す語句が入るはずです。 -
結論
上記から、c には「初期サポート窓口で扱った内容がサービスデスクへ完全に渡されている状態」を表す文言が入るのが自然です。
→ 解答例:「初期サポート内容の引継ぎが完了している」
誤りやすいポイント
- 「開発部からの報告書提出」など成果物に着目しすぎ、SPOC が目的である点を忘れる。
- 「問い合わせ件数が減少している」など量的指標を入れてしまい、F課長が求めた“終了基準”の本質(窓口統合の準備完了)とずれる。
- 主語を運用課にしてしまい “開発部から” を落とすことで文意が不整合になる。
FAQ
Q: “SPOCを実現する時期の判断” とありますが、SPOC自体はいつ実装する計画なのですか?
A: 初期サポート終了後、引継ぎが完了しサービスデスクのみで対応可能になった時点で実装します。終了基準を満たすかどうかで時期を判断します。
A: 初期サポート終了後、引継ぎが完了しサービスデスクのみで対応可能になった時点で実装します。終了基準を満たすかどうかで時期を判断します。
Q: “終了基準” は複数あるようですが、どれが一番重要ですか?
A: 「テレワーク環境の問合せとインシデントの対応が b こと」と「開発部から c こと」の両方が満たされて初期サポート終了となります。どちらが欠けても終了できません。
A: 「テレワーク環境の問合せとインシデントの対応が b こと」と「開発部から c こと」の両方が満たされて初期サポート終了となります。どちらが欠けても終了できません。
Q: なぜ “開発部” ではなく “運用課” が窓口一本化を担当するのですか?
A: 運用課のサービスデスクが日常的な問合せ窓口として機能しており、SPOC の常設部門となるためです。開発課はプロジェクト主体であり、恒常業務には向きません。
A: 運用課のサービスデスクが日常的な問合せ窓口として機能しており、SPOC の常設部門となるためです。開発課はプロジェクト主体であり、恒常業務には向きません。
関連キーワード: SPOC, インシデント管理, 問合せ窓口, 初期サポート, 引継ぎ
設問2:〔テレワーク環境の運用の準備〕について答えよ。
(4)本文中の下線②の問題と解決方法は何か。問題を25字以内で答えよ。解決方法は表1中の機能に対応する項番の数字を答えよ。
模範解答
問題:電話によるサポートは時間が掛かること
解決方法:3
解説
解答の論理構成
-
問題の特定
【問題文】には、サービスデスクの課題として
「サービスデスクでは、電話でのサポートは時間が掛かるという問題を抱えている。」
と明記されています。下線②が示す「現在、サービスデスクで行っているサポートの問題」はこの部分です。 -
解決策候補の抽出
表1の統合管理ツールの機能を見ると、
・項番「3」「リモート操作」―「統合管理ツールから社内デバイスをリモートで操作したり、ロックして使用できないようにしたりすることができる。」
が、電話に頼らず端末を直接操作できる手段になります。 -
問題と機能の対応付け
電話越しに口頭説明で操作を促すより、リモート操作で画面を共有しながら対応すれば時間短縮が可能です。したがって、
・問題:電話によるサポートは時間が掛かること
・解決方法:表1「3」リモート操作
の組合せが妥当となります。
誤りやすいポイント
- 「操作ログ管理(項番2)」と混同しやすい
ログ取得は“原因究明”には有効ですが、リアルタイム支援の時間短縮には直結しません。 - 「パッチ適用(項番4)」を選んでしまう
下線②は“サポートの問題”であり、OSパッチ展開の効率化ではない点に注意が必要です。 - 問題文の別の課題(OSパッチの不確実さ、SPOCの実現など)と取り違えるミス
FAQ
Q: リモート操作機能はセキュリティ面で問題にならないのですか?
A: 統合管理ツール上で権限管理を行い、操作ログも併せて取得することで不正操作の抑止が可能です。
A: 統合管理ツール上で権限管理を行い、操作ログも併せて取得することで不正操作の抑止が可能です。
Q: 電話サポートを完全にやめても良いのですか?
A: 障害やネットワーク断でリモート接続できないケースも想定されるため、電話や対面はバックアップ手段として残すのが一般的です。
A: 障害やネットワーク断でリモート接続できないケースも想定されるため、電話や対面はバックアップ手段として残すのが一般的です。
Q: なぜSPOCを実現するより先にリモート操作を導入するのですか?
A: 問合せ窓口の一本化(SPOC)は運用体制の問題ですが、リモート操作はツール導入だけで即効性があり、電話対応の負荷を早期に下げられるからです。
A: 問合せ窓口の一本化(SPOC)は運用体制の問題ですが、リモート操作はツール導入だけで即効性があり、電話対応の負荷を早期に下げられるからです。
関連キーワード: リモート操作, サービスデスク, インシデント対応, 統合管理ツール, 問題管理
設問3:
本文中の下線③について、運用部が下線③の対策を採る理由を、展開管理の視点から30字以内で答えよ。
模範解答
OSパッチの適用のタイミングをコントロールできるから
解説
解答の論理構成
-
現状の問題点
- 運用課は「現在実施しているOSパッチの手動適用では、従業員がOSパッチの適用のタイミングをコントロールできてしまう」ことを問題視しています。
- このため「OSパッチの適用に不確実さがある」と明記されています。
-
パッチ適用機能の導入意図
- 「パッチ適用機能を使うことで、展開管理としてOSパッチを確実に適用できると考えた」とあり、運用部が下線③の対策(自動展開)を採る動機が説明されています。
-
展開管理の視点
- 展開管理では、全端末に対し“いつ”“どの順番で”パッチを適用するかを一元的に制御し、バージョンのばらつきを防ぐことが求められます。
- 手動適用のままだと個々の従業員が適用時期をばらばらに決めてしまい、展開計画が成立しません。
-
結論
- よって、模範解答「OSパッチの適用のタイミングをコントロールできるから」は、上記引用により裏付けられます。
誤りやすいポイント
- 「問題管理の視点から有効」という記述だけに着目し、展開管理の理由を答え忘れる。
- “リモート操作”機能を使えば十分と考え、パッチ適用機能の目的を取り違える。
- 「タイミング」ではなく「パッチの選定」や「適用可否のテスト」と答えてしまう。
- 手動適用=利用者任せだが、あえて“自動なら利用者の負担が減る”とだけ書き、展開管理の観点を示さない。
FAQ
Q: 展開管理とパッチ管理は同じ意味ですか?
A: 重なる部分がありますが、展開管理はソフトウェアや設定変更を組織全体に計画的に配布・適用するプロセス全般を指し、パッチ管理はその中で特に修正プログラムの適用に焦点を当てた活動です。
A: 重なる部分がありますが、展開管理はソフトウェアや設定変更を組織全体に計画的に配布・適用するプロセス全般を指し、パッチ管理はその中で特に修正プログラムの適用に焦点を当てた活動です。
Q: 自動適用にすると業務アプリが動かなくなるリスクは?
A: 本文では「テスト済みのOSパッチを配信用サーバに登録する手順の追加」で検証済みのみを展開するため、互換性確認を運用プロセスに組み込みリスクを抑えます。
A: 本文では「テスト済みのOSパッチを配信用サーバに登録する手順の追加」で検証済みのみを展開するため、互換性確認を運用プロセスに組み込みリスクを抑えます。
Q: 手動適用を続けながら確実性を上げる方法はないのでしょうか?
A: 手動を残す限り適用タイミングのばらつきは避けられません。統合管理ツールの自動展開へ切り替えることで、一括スケジュール・強制適用が可能になり、展開管理の目的を達成できます。
A: 手動を残す限り適用タイミングのばらつきは避けられません。統合管理ツールの自動展開へ切り替えることで、一括スケジュール・強制適用が可能になり、展開管理の目的を達成できます。
関連キーワード: パッチ管理, 展開管理, リモート操作, インシデント管理, テレワーク


