書いたら長くなった…けど、何らかの議論のネタなりになればということで、とりあえず放流する。
「テレワーク」というと、なかなか魅惑なパワーワードだが、ちょっとアタマを巡らせると、かなり大変であることがわかる。
大変といっても、実は文章の読み替えをやったり考え方を柔軟にしたりということをできれば、あんまりハードルにならないのかもしれないが、考えないといけないことをとりあえずざっと書いてみた。
とりあえず、一つの思考実験的に書いたものなので、考え違いや抜け漏れあるかもしれないが、そこはご容赦を。
1. 制度面の課題
テレワークというと、オフィスにいなくても仕事が出来る、とポジティブに考える人が多いが、会社の就業規則などの面を考慮すると、結構な難事が出てくる懸念がある。
とはいえ、（最初に結論を書いてしまうが）何のための業務で、どんな成果を期待するのか？が明らかになれば、下記の話は（本質的には）問題にならないことが多い。むしろ問題にする人がいるとしたら、「既存ルールの整合性をどのように取るのか」ということを考えなければいけない人であろうと考える。
1.1. 就業場所に関する規則
こんなこと書くと、「また昭和かよ」と言われそうだが、別に平成の早いうちでもこういう話はいくらでも出てきていたので、昭和だの平成だの令和だのというようにくくらないでほしい。
基本、テレワークのような就業場所にとらわれない働き方を前提に出来るのは、最低限3つの前提を満たす必要がある、と考えてほしい。
- 特定の就業場所に行かなくても遂行可能な業務であること
- 就業規則等で、特定の場所以外での業務遂行を認めていること
- 顧客との契約上、特定の場所以外での業務遂行を認められていること
個々の業務特性を考慮すると、さらに条件は細分化されるが、とりあえずざっくり上記3つについては、「最低限」押さえておかないといけない、と私とかは考える。
1.2. テレワークに係る費用負担
テレワークは、インターネットのような安価かつリーズナブルな通信帯域を「誰もが」利用しうる状況になって、はじめて可能になった就労形態とも言えるが、そこにかかる費用を（たとえ少額とはいえ）労働者の持ち出しにしてよいのか？という議論が出てくる懸念はある。そこは、光熱費なども同じことが言える。
1.3. 労働時間の算定に関する課題
「8:30～17:00勤務」とか、固定的な労働時間帯を設定し、そこは業務専念すべし、という話になってくると、結構ややこしい。そもそも「その労働時間帯は適正であるか？」とか、「何を根拠にそう決まっているか」という話も出てくる。
1.4. 勤怠管理および評価に関する規則
これは、労働者当人というよりは、管理者が「どう評価すればいいのか」という話に帰着する。
労働時間については、「一定時間、適切に手を動かしていれば必ず成果が出る」という思想に基づいたものであると考えられるため、そういう考え方がフィットしないような業務であれば、そもそも勤怠管理という考え方をあらためる必要があると考える。
「プロセスもきっちり評価する」という話であっても、「そのプロセスをどう遂行しているのか」がわかればよい話であり、それを時間だけで評価すると、どうしても評価結果が歪む可能性がある。
1.5. まとめ～制度ありきでテレワークを難しくするのではなく、何のためにどういう制度を敷くか？を考えよう
会社における制度は、会社がその社会的使命を果たすために、構成員に求める行動を明文化したものである。
管理のため云々という話はあるだろうが、じゃあその管理は何のためか？というのを考えていくと、最終的にはその会社が何のために業務を行っているのか？に行き着くはず。
個人事業主や構成員の数が少ない会社の場合は、こういう制度をがらっと変えて周知、というのももしかしたら難しくないのかもしれないし、場合によっては明文化も（法令が求めるもの以外は）なされなくてもうまくいくのかもしれない。しかし、構成員（社員）が多くなればなるほど、こういう制度をきちんと決定の上で周知・遵守を促さないと、だいたいの場合はうまく動かない。
しかし、そのために（業務によってはできるはずの）テレワークをしない／させないというのは、非常に残念な結果を招く。
技術的課題はあるものの、可能であれば制度面をきっちり整備して、可能な業務ではテレワークを（ある程度）認める、というように舵を切るのもアリなはずだ。
2. 技術的課題
制度的な課題をクリアしても、次は技術的な課題がある。
オンプレミスを主体とした社内システムや業務システムを持っている会社の場合、テレワークを実施することで、インターネットの出入り口に設置・稼働している機器の負荷が逼迫する可能性がある。
2.1 何がテレワークを阻害するのか？
特に昨今、DaaS（Desktop as a Service）をパブリッククラウドではなくオンプレで（社内ネットワークに）構成している場合には、そのような社内ネットワークを構成している機器の負荷は、設計時のものを超える懸念がある。
- (1) RDPによる画面転送に起因したトラフィック
ここは、当然だが会社からのアウトバウンドが増える。
- 音声系トラフィック
ここは、何を使うかによって、トラフィックの増え方が変わる。
- 動画系トラフィック
ここも、何を使うかによって、トラフィックの増え方が変わる。
1はしょうがないとしても、2,3は問題になりうる。
個人的には、以下の2つの条件が同時に満たされてしまった時に、問題は顕在化しうる、と考える。
- オンライン会議系の外部サービス（例：WebEx、Zoom、Microsoft Teams）をオンプレDaaSもしくは社内に設置したPCで使う
- 社内で構成したオンプレDaaSもしくはPCをRDP経由で「社外から」使う
この2つが場合は、音声系や動画系の情報が、HTTPS経由でDaaSなど社内に入ってきたあとに、RDPトラフィックに乗って社外（利用者のところ）に出ていく。
発生する通信は、社内から普通に利用する時の倍程度（インバウンドとアウトバウンド）の想定。音声だけならばまだしも、資料の画像や動画などが乗ってくると、かなりクる。
あと、オンライン会議を多くの人が使うようになると、今度はアウトバウンドのTCPセッションの数が問題になりうる。普通にStatelessなWebアクセスが大半だったりする分には全然OKで、通常のようにF2Fで打ち合わせを行うなどであればいいのだが、オンライン会議がマジョリティになると、今度はTCPセッションが膨大になる。
このあたり、何の考慮もしていなかったりすると、利用者数が万単位になった瞬間に詰む。まぁ、普通は万単位の利用者がいる場合には、Proxyなどはロードバランサ使って適度に振り分けるはずだが、オンライン会議は基本数十分とか1時間とかセッション張りっぱなしというのもザラである。
トラフィック量（帯域）の話以外だと、テレワークの場合は、プロトコルの限界や、トラフィックをさばく機器の性能問題は、多分トラフィック量よりも先に限界が見えてくる、と思う。
2.2 本質的な技術的課題：会社の環境がすべてのボトルネックになる
他の要因もあるのかもしれないが、何をするにも一旦会社の中に収容され、会社の外に出ていく。管理はしやすいかもしれないが、管理のしやすさと引き換えに、多くのユーザにとって利用しづらい環境（業務アプリケーションを満足に利用できないなど）を実現してしまう。
2.3. とりあえずの解決策の案：せめてオンライン会議くらいは会社を経由させるな
オンライン会議のサービスは、（当然だが）外部のサービスであることが大半だ。
だったら、家から直接使ってもいいのではないか？と考える。
それが出来ない場合は、会社の設備を増強するしかないわけだが、それにも限界がある上に、直接外部のサービスを使ったほうが効率はよい。
もちろん、持ち出し出来ない資料（でも投影は可）を、会議で使うこともあるだろう。この場合は、会議運営を行うホストのみが社内システムに入る形にし、参加者は直接オンライン会議サービスに接続させる、というのでよいのではないか。あとはホストの権限で、ファイルを見せることはできても共有出来ないようなしくみを使う（例えば、ファイル共有機能を無効にする）ことで、ある程度の対処は可能だ。投影内容を写真に取られたらどうする？的な話はあるだろうけど、テレワークを実施させる以上、常につきまとうリスクだ。
完全には難しい場合には、オンライン会議系のトラフィックは、別のNWから外に出す、というのもあるかもしれないが、NW構成が面倒になるだけな気もするので、オススメは最初から会社を経由させない、というもの。
3. テレワークに係るセキュリティ
あまりセキュリティの話はしたくないのだがｗ、オレ自身にそういう属性がついてしまっているので、とりあえずざっと書いておく。
3.1 ソリューションありきで考えない
昨今、「これ使えばテレワークバッチリ！」と煽っているソリューションやツールが多いが（個人的には、Tea○Vie○er使えばバッチリ！と言ってるところがあって、こけそうになったｗ）、ソリューションやツールはあくまで「業務を補助する道具」である。
もちろん、ないよりはあったほうがいいが、そのソリューションを導入したら何が出来て何ができないか、何は制御できるか？という話を、後述する3.2のところでリスクを考える時に、細かく見ていく必要がある。
自分とこに必要なものが何か？をきちんと押さえておくことが重要である。それこそ「監査できること」なども、要件に含めておく必要があるが、これは別にテレワークに限った話でもないか。
3.2 自分のところにとっての「テレワークを認めることによるリスク」を考えよう
テレワークを認めることによって、どのようなリスクが発生するのか？を認識しよう。
1,2で「いけるね」となっても、ここがダメだとそもそもテレワーク難しいね、になってしまう。
3.3 リスクに応じた情報の機密性、完全性、可用性の確保を考える
ある程度リスクを考えることができれば、あとはそのリスクに応じて対処を行うことを考えよう。
- 仕事場以外で仕事をするからといって、情報をお気軽に持ち出されては非常に困る。
- 仕事場以外で会議（オンライン会議）をする時に、大丈夫なしくみがあるか
3.4 リスクが現実になってしまった時の対応プランを考えよう
これは別に、あらためて考えるというよりは、既存のプランがきちんと発動するかどうか？を確認する話と考えてもらえればよい。
何か起こってしまった時に、事象を追跡できるようにする、という話もこの中に含まれる。
裏を返すと、テレワークに必要なツールは、ユーザの行動を（後追いであっても）追跡できるものが望ましい、ということになる。
4. まとめ～テレワークを実施したいのであれば、制度と技術とセキュリティの3面から！
少し長くなったが、最終的に述べたいのは以下の5つ。
- テレワークを出来る土壌があるならば、テレワークを認めてもよいのではないか
- テレワークを認めてもよいのであれば、認める根拠を制度化すべき
- テレワークを実施するにあたっての技術的な課題を考慮のこと
- セキュリティ関連の話は、リスクもあわせて考慮のこと
- 最終的にテレワークを認めるかどうか？は、上記1～4を勘案の上、総合的に判断すること
とはいえ、テレワークやらなくても考えないといけないことも「かなりあるはず」なので、備えをきっちり出来ているところであれば、見た目ほどの作業は発生しない…と思いたい。
…結構長くなったな…。
