リモートワークが出来る理由、出来ない理由 Vol.1

ビジネス

SIOSのDX Product & Integrationチームでマーケティングを担当している村田です。

今回は4月にRed Hat社と共催で行いましたRed Hat Ansible Automation Webinarにて使用したコンテンツよりリモートワークが出来る理由、出来ない理由、その中でRed Hat Ansible Automationがどのような効果をもたらすことができるのか?をご紹介します。

この記事を執筆している8月20日の時点の日本の状況は新型コロナウイルスの影響が続いており、第二波が発生していることから再度警戒を強めている中での内容となります。今後、再度緊急事態宣言が行われた場合、このままリモートでの業務が求められる場合、様々な課題が現在のビジネスには有ると思います。この記事が課題を持たれている方に対して、少しでも気づきや参考になってもらえたらと思います。

新型コロナウイルスによるビジネス上のリスク

新型コロナウイルスの猛威が続き感染者が増加していく場合、事業を継続するにあたり次のリスクに備えてITの投資をしなければいけません。

事業所閉鎖のリスク

ひとつは事業所閉鎖のリスクです。職場にて感染者が発生した場合、消毒を行い濃厚接触者を隔離して待機させるという手段が今では取られているのが一般的な流れだと思います。しかし、事業所で大規模なクラスターが発生した場合は事業所を一時的に閉鎖しなければならない状況が発生する可能性があります。

これがITの運用現場であれば事業所が閉鎖される、または担当者がクラスターで全員出社できない状況が発生した場合は、ビジネス自体が止まることを意味します。

リモート作業のリスク

次に、事業所に赴かないでも済むようにとリモートワークを取り入れる企業が増加し、現在では打ち合わせもオンラインミーティングで行われるなど、かなり浸透してきている状況だと感じています。

ただし、リモートワークを阻害する要因として、”人”と”もの”に依存してしまう状態があるとリモートワークで対応出来ず、事業所への出社を行わなければならない状況が発生してしまいます。

運用現場のリモートワークを妨げる要因

今回はIT運用の現場にフォーカスを当てて、リモートワークを妨げる要因にはなにがあるのかを見てましょう。

運用現場の課題としてよく耳にしたこととして多かったのが、人や場所に依存している状況にあるためリモートワークに切り替えられないという理由でした。この課題では、もともと運用は事業所で行うことが前提で新型コロナウイルスの発生前であれば事業所に行く事が当たり前であったので問題はありませんでした。

しかし、現在のWithコロナ、Afterコロナを考えると事業所に行かずにIT運用が回るようにしなければならないため、根本から見直さなければならない所が多く出てきます。

人や場所に依存した運用

サーバールームに入室して実機を操作しなければいけない、社内ネットワークからでないと接続できないといった作業を行う上での制限や手順書・目視確認を前提に組まれた運用では作業者と管理者がペアで組んで作業を見守るという運用方法での限界というところがリモートワークによる運用を阻害する要因になりえるかと考えられます。

会社組織や制度

運用するシステムが部門ごとプロジェクトごとに異なり、その運用方法もそれぞれで異なる場合、使用するツールが異なるために一部のシステムではリモートでの運用に対応できても、別のシステムは現地で作業しなければならないなどの状況を引き起こす場合があります。また、そもそもで作業用のPCが持ち出しできない場合やネットワーク接続が制限されているためにリモート作業が出来ないと場合もあります。

このような制約以外にも、経営者や管理者がリモートでの業務に理解が乏しく、従業員がサボるのではないか?監視をしなければ気がすまないという理由から出社を求めリモートワーク自体を認めないことも多く見受けられます。(従業員が健康であることはなにより大事ではないでしょうか、その上でビジネスを衰退させないためにどうすればよいのか、何を変えられるのかを考えたいものです。)

セキュリティ

前述の項目でも記載しましたが、企業のセキュリティが足かせになり社内ネットワークへの接続やクラウドサービスへの接続が制限されることがあります。セキュリティを緩和すればリスクは増加することになるため一概に接続を開放すればよいとはならないのがセキュリティです。

必要な人が必要な場所にアクセスできるように管理する、そして問題が発生しても最小限に留められるようにセキュリティ設計を見直す事が必要になります。

また、事業所での運用にて目にしてきたのが共有のID、パスワードを使い回す文化、そして共有PCの利用です。この運用は事業所等のローカルでの運用では問題なく使えていたかもしれません、しかしクラウドを活用し始めた時に、この運用は大きなリスクになることは想像がつくと思います。共有で使い回すから個々に適切に権限を与え、管理するという方法に切り替えなければいけません。

リモートワークを可能にする運用とは?

リモートワークを可能にするためにはどのような状態であれば良いのか、これは各社の状況毎に異なるものですが、次に上げる項目をクリアすることで実現が近づくのではないかと思います。

人に依存しない、仕組み化された運用

IT運用が人に依存している状況、また人が場所に依存している状況下ではリモートワークを取り入れる際に足かせになる事項が多数出てきます。特定の人材に依存している場合、その人が事業所に行けない状況が発生する場合にリスクとなります。チームでカバーする体制が取られていれば良いですが、そのためにも属人化を排除して誰でも同じように運用を行える仕組みづくりが重要になります。

また、人の手を介在させる、意思を介在されることで必然的に人員は必要になるため、自動化ができる範囲は極力自動化を浸透させ、単一障害点をなくすことでシステムのダウンを防止し人が手を動かすケースを削減していくことができます。

どこからでも対応できる環境整備

リモートワークに対応するには、システムが外部から安全にアクセスが出来る状況が求められます。セキュリティやガバナンスが配慮されリスクの無い接続を行うための環境準備が必要になります。

この時に実行履歴・権限管理や証跡管理が適切に行われていないと、システムが今どのような状態なのかが把握できない場合や過剰に行き過ぎる場合には運用者の行動が信用できないと管理職の方が行動の方を監視し始めたりと悪い方向に流れてしまう懸念があります。

万が一のリスク対応

新型コロナウイルスの影響が続く中、最悪のシナリオとしてもし従業員に感染者が発生し、事業所が封鎖されるような状況に陥った場合、そこにシステム障害が発生したときを想定してみてください。

あなたが取れる手は何がありますか?

このような状況が発生したとしても運用を止めないためにも、1箇所でのサイト運用は非常にリスクとなるため、2箇所以上で運用が出来る環境が求められます。この環境を実現するレプリケーションの設計やバックアップの取得は重要な項目になると考えています。


Vol.2では、Ansible Automationがどのようなリモートワークでの課題に対して効果を発揮できるのかを説明しています。

リモートワークが出来る理由、出来ない理由 Vol.2

Red Hat Ansible Automation