1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

【ポエム】私はこうやってリモートワークをしています。リモートワークの推進の難しさを実体験から語りたい。

1
Last updated at Posted at 2020-03-24

最近リモートワークの導入や成功ノウハウなどの勉強会(オンライン)に積極的に参加しています。
私自身も、リモートワークがメインでの活動やフリーランス事業を行っています。

TL;DR

  • リモートワークを導入する時はスモールスタートのやり方を考えてみる
  • リモートワークを運用する時は「オンサイトでやってること(主にムダ)」をチャットツールに全部持ってきましょう。
  • 自己管理ができなくて辛みを感じる人は、自分なりの気分転換の方法を作りましょう。

なるべく短めにまとめる努力をしていますが、書いている私自身が読む気を失うぐらいとても長い記事になりますので、必要な部分だけ切り出して読むのが良いかと思います。

  • ここで触れること
    • リモートワークの実践例、また失敗例
    • リモートワークの推進アプローチの考え方
  • ここで触れないこと
    • リモートワークを取り入れ方
    • リモートワークのメリット・デメリット

なぜこの記事を書いたか?

リモートワークは選択肢の一つと定義した上で、選択肢を奪われる事を少しでも減らしたいという思いで書いています。

本題

誤解が発生しないように、冗長な表現を意識しています。
ムダをなくし効率化するのがエンジニアの美学の一つ(と、私は認識しているの)ですが、ことドキュメント類では読み手側に手抜きと思わせる表現になりかねないためです。

リモートワークを導入するのは意外と簡単

社内的な問題が解決すれば**(これがとても難しい)**リモートワークの恩恵を受ける事ができます。
社内各部の問題もあるので具体例が示せませんが、社内業務を全部リモートにするのではなく、リモートでも出来る仕事とそうでない仕事を切り分ける事で業務効率化の可能性を検討してみるのも良いかと思っています。

スモールスタートですべての問題は解消できない

スモールスタートで運用時に注意が必要です。
実際にフルリモートに移行すると、スモールスタートでは見えなかった問題が大小発生します。
これを織り込んだ上で運用しないと、スモールスタートで大丈夫だったはず、とならないです。

例えば、リモートワークの導入初期あるあるで、稼働がなかったから休日同然の扱いをされる事があります(私にも実際にありました)。
うち、仕様待ち・判断待ち、あるいは指示待ちの時間もあったのですが、リモートワークが原因でないものもリモートワークの問題として取り上げられる事があります。
これはスモールスタートで不慣れな段階ではあまり問題にされにくいようです。

とはいえ、監視体制を作るのはバッドノウハウです。
単純に負荷が増え、リモートワークの良さが薄まります。
大事なのは、管理職の人間がすべて面倒を見なければならない状態をなくして負荷を下げることです。

リモートにすべきではない業務

まず最初に、何でもかんでもリモートワークにするのは反対です。
エンジニア的に言うと、不慣れな言語やライブラリを採用する事で開発が遅れるぐらいなら、技術的負債を抱えてもプロジェクトを推進する方が良いのと同じで、リモートワークも慣れ・不慣れの面が大きいです。

たとえばツールの不慣れなら、運用システムを刷新した頃のように使い続ければ解消する問題ですし、リモートワークのため業務フロー自体を見直す必要があるものもあります。
また、自宅で仕事が捗らない(マインドコントロール・物理的環境)場合は外出した方が(出社の有無問わず)効率が上がる事もあります。

とはいえ、この見極めは大変難しく、いったんやってみてうまく行かなかったら引き戻す、という判断フェーズはあっていいと思います。

それでもリモートワークにしてほしい

エンジニアの皆さんがリモートワークを良しとしていない、という事を念頭に置きつつ、リモートワークでないとパフォーマンスが発揮しにくい人(非エンジニア含む)が居る事も確かです。

ここからは他の誰かの話ではなく、私の話にフォーカスします。

オンサイトの環境に縛られるのがとてもつらい

これは私事ではあるのですが、職場の空調環境が私にあっていないため、パフォーマンスを発揮できない事があります。
有り体に言えば、オフィスの空調は私にとって強い眠気を誘発します。

が、他の人にとっては快適であるため、ただ単純に上げたり下げたりすればよい、という話にはなりません。

睡眠弱者にとってコアタイムは無価値あるいは苦痛の時間

ここでいう睡眠弱者とは、眠りを自由にコントロールする事が難しい人を指します。
海外出張による時差や、睡眠障害(無呼吸症候群など)を持っている人にとってはパフォーマンスを発揮しやすい時間とそうでない時間があります。
シエスタの有用性を提唱したいわけではありませんが、シエスタが必要な人も居る事は明記しておきます。

仮眠室のない職場が多く、また昼休憩時間とはいえ周囲が忙しなく仕事をしている環境で堂々寝る度胸はなく、とはいえパフォーマンスを高めるため嫌々仕方なくトイレの個室を1時間貸しきってただひたすらに寝る、なんて事はしたくないわけです。

孤独解消にコミュニティドリブン

リモートに慣れると感覚が薄くなるのですが、仕事は一人でやるものではありません。
リモートワークで成果主義が成功しやすい=一人で成果を上げる努力をする、というように考えられるケースがありますが、基本的にはチャットツール等によりコミュニケーションを行っています。
ぶっちゃけ、オンラインゲームのチーム戦とやってる事は同じです。

それでも孤独を感じる事はあります。
他に解消する方法として、技術者コミュニティに貢献してみたりQiitaだとポエム駆動開発してみるのも面白いかもしれません。

余談

という名のトラブルシューティング。

職場コミュニケーションには「ムダ」が必要

リモートでのコミュニケーションがつらい、と感じる方は、オンサイトでのMTGの時と何が違うのかも考えてみると良いです。
社内回線が許せば、常時zoomなどで相互に状況を配信しておき、互いに顔が見える状況で業務をするという手もあります。
カメラが使えない、音声を拾ってほしくないなどの状況もあるかと思いますので、そこは適宜設定の上で実施しましょう。
ただし、前提としてお互いに監視をしないというルールを設ける必要があります。
こういった取り組み自体に否定的な考え方を持つ人も一定数居る事を理解した上で運用しましょう。強制ではありません。

コミュニケーションツールに慣れよう

コミュニケーションエラーをリモートワークの問題点として挙げる方がいらっしゃいます。
新人時代に上司に質問しようとして席まで行くと「今忙しいから後にしてくれ」と待ち惚けの時間があり、「終わったら行くから」とご配慮いただくのも心苦しく、また落ち着いた頃を見計らっても「ごめん、忘れてた」というやり取りがあった頃を考えると、リモートワークがコミュニケーションエラーを促進しているとはとても思えません。
どちらかというと、対話コミュニケーションとチャットコミュニケーションの違いでは?と思います。
今現在社会人の若い子たちはSNS(チャットコミュニケーション)の世代でもありますから、リモートワークの目的以外でもチャットコミュニケーションを学ぶ機会とするのも良いのではないかと思います。

リモートワークのノウハウを共有しよう

ベストプラクティスばかりじゃなく、バッドノウハウでもいいんです。
極端な話、発信する情報が間違っていてもいいと思います。
(誤った情報を意図的に発信するのは例外)

どうやってリモートワークを成功させたか、という話も貴社では出来るが弊社には当てはまらない、なんて事は絶対にあるはずです。
他社で出来て自社で出来ない事はあるし、逆に自社の例がすべての他社にとってベストであるはずがないです。

どのやり方が自社に合っているのか、まずは知識を得ましょう。
得た知識を自社で展開、活用する事を検討しましょう。
効果がありそうなら、どんどん導入・運用していきましょう。

どんどん業務を良くしていく、その一環としてリモートワークを選べれば良いな、と思います。

参考・推奨文献

これは私的に、許可を得たりしていないので恐縮ですが、筆を執るにあたり実体験以外で参考にしました。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?