本気でリモートワークを活用する組織が注意すべきオンラインコミュニケーションの指針6点

「わかる・・・わかるで、それ・・・リモートワークは難しいんやでぇ・・・」

デブサミ2018で、「リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく」というセッションを聞きながら、自分は何度もそう頷いてました。普段自分がなんとなーく感じていたことが、どんどん言語化されていく感触です。共感する内容が盛り沢山で、むっちゃ面白かったんですよ。

この記事では、はてなの粕谷さんのセッションを聞いて閃いた、リモートワークを円滑にすすめるためのオンラインコミュニケーションのコツみたいなものを、いくつか紹介したいと思います。

リモートワークバリバリ導入している組織でも、これからやってみようかなと思っている方々にも参考になる部分あるかと思いますので、気軽に読んでいただければと思います。

ほな、いってみよ。

　__
（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     ﾘﾓｰﾄﾜｰｸﾀﾞﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

講演内容

講演者は、株式会社はてなの、粕谷大輔（@daiksy）さん。

twitterのTLで、このアイコンを見たことがある人も多いんじゃないでしょうか！

リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく

ぼくがディレクターをつとめる、Mackerelというプロダクトの開発チームは、東京オフィス・京都オフィス・愛知にあるエンジニアの自宅の3拠点体制で、3年以上開発を続けています。日常的にリモートチームで開発をしているのですが、リモートワークはメリットばかりではありません。とてもとても、難しいのです。

このセッションでは、「リモートワークの難しさ」に焦点をあてます。
そしてそれでも僕たちがリモートワークを選択する理由やメリットは何なのか。
赤裸々にお話しようと思います。

講演資料：リモートワークは難しい / Developer Summit 2018 // Speaker Deck

セッション全部、ものすごい参考になるんですが一番印象に残ったスライドがこちら。

「結局は、リモートワークの難しさとは、ロケーションが異なる場所で働くことにより、同期的なコミュニケーションが難しいことが大半の原因。このコミュニケーションの難しさをいかに克服するか？ってことなんですよ」

なるほど納得、うん、そうか！

クラスメソッドも、結構昔からリモートワークは導入されています。ディズニーシーやメイドカフェやキッザニア東京で仕事してみた記事もあったり、まぁやりたい放題っすね。

自分も週に2〜3日はリモートで自宅なりそこらへんで仕事してます。仕事に支障がない限り働く場所についての制限は一切ありません。

最初、「なんでこんなんで仕事回るんや、この会社は・・・」と不思議に思ってたんですが、しばらく勤務しているうちに、このリモートワークをうまく運用するためのルールというか文化みたいなのがあるんだなぁと、なんとなくわかってきました。

そんなときに、この粕谷さんのセッションを聞いて、それらが一気に言語化されたのがこの記事です。会社の公式見解じゃなくて、あくまで入社半年そこそこの自分の主観ですが、おそらくあんまり外してないと思います。はい。

指針1「リモートワークの申請は、原則前日までにする」

これ、恐らくリモートワークの文化を支える上で一番重要なポイントです。

リモートワークは、場所に限らず好きなところで仕事をして良いのでちょっと意外と思われるかもしれませんが、これには理由があります。

自分が入社後、弊社、都元がむっちゃええことを言ってたので、それをそのまんま紹介します。

チーム全体への共有として、リモート当日申請が原則不可となっている経緯を私が知っている範囲で書いておきます。
リモート文化の発祥は、もともとAWSコンサル部（現AWS事業部）からの流れなんですが、チームに対して横田さん（社長）から「前日夜遅くまで飲み過ぎたから」とか「朝起きたら会社行くのダルかったから」とか「寝坊したから」みたいな理由でさせるためのリモートじゃないよね、という意図が共有されたことがあります。
リモートするのは全然構わないけど、やるならば前日までに計画的に実行してください、その方が効果的でしょう、ということです。

リモートワークを制度化し実践していく中で、一番重要な点は「自主性」かと思います。

出社して、忙しそうにしていたり電話でお客様に怒られたりしていれば周囲が察することもできますが、リモートワークだとそれが無理です。成果を出すのも自分だしアラートを出すのも自分です。そういう「自主性」と共に「計画性」がないと、リモートワークのメリットは享受できません。

そういったセルフマネジメントを意識するためにも、「リモートワークの前日までの申請」はあるべきだろうなぁと思ってます。これをルール化しておくだけでも、リモートワークにおける自主性を担保する必要条件になるんじゃないでしょうか。

逆に、リモートワークの当日申請は、基本的にはやんごとなき理由（電車が止まって動かないから途中の駅で仕事開始するとか、子供の面倒が急に必要になったから、等）が必要です。

指針2「質問投稿には全力で応答する」

クラスメソッドのチャット部屋には、「構築相談所」とか「技術相談所」という、日々の業務で悩んだ時に相談できる専用の部屋があります。ここの部屋のリアクションがアホみたいに早く、さらに濃い。

この部屋に常駐している人がいるわけではなく、あくまでボランティアベースのメンバーの善意なんですが、リモートワーク特有の「何か困ったことがあった時に疑問を解消しにくい・・・」というデメリットを、かなりな部分ここで払拭できているんじゃないかなぁと思います。

社内チャットの構築相談したときのレスの速さと充実度が、ほんと毎回すごい。やばい。変態。自分もはやく貢献できるようになりたいもんだよ。

— ハマコー (@hamako9999) 2018年2月20日

これだけ助けてもらってると、逆に誰かが質問投げた時、自分の知っている範囲であれば全力で返答したくなるんですよ。自然と。まだそこまでの域には全然達せてないんですが。

リモートワークって基本的には孤独なんですよね。でも、そういう質問したら答えてくれるという安心感をベースに、みんなで知識をシェアしようというペイ・フォワード的なサイクルがうまく回ると、組織力としてもリモートワークのデメリットの解消としても、非常に良いんじゃないかなぁと思います。

指針3「オンラインミーティングに向かない打ち合わせがあることを理解する」

チャットなど文字ベースのコミュニケーションを補うために、必ず必要になるのが、オンラインミーティング。クラスメソッドでは、オンラインミーティングはGoogleハングアウトを使っていてリモートワーク上必須のツールなんですが、このオンラインミーティングの超えられない壁を理解しておくことも重要です。

端的に言うと、ふわっとしたアイディアをみんなでこねくり回しながら形にまとめたりとか、人事上の重要なミーティングには、オンラインミーティングは適していません。

経験がある人はなんとなくわかると思うんですが、オンラインミーティングって「今が誰のターンか」がきちんと分かる形で進めないとやりにくいんですよね。対面に比べて情報量がすくないので、議題が明確でアジェンダがあってファシリテーターがいてゴールが見えているものがやりやすい。

逆にふわっとした投げかけや、そもそもの問いが曖昧だったりした場合、ビミョ～な空気が流れて、「え？俺、なんかいま、変なこと言った？みんな、もしかして怒ってる？」と、不安な気持ちになったりします。これ、自分、初期の頃にやらかしました。

後で、「まぁ、なりがちですね。気にしなくて良いですよ〜」とチームメンバーにフォローしてもらいましたが、やはり対面との使い分けは必要だなぁと感じた出来事です。

AWS事業部では、四半期ごとに人事に関わるミーティングがあるんですが、それも必ず対面で実施することになっています。マネージャーは、其のために東京オフィス以外の札幌、大阪、福岡への出張もやります。

リモートワークする上で、オンラインミーティングは必須のツールなんですが、その限界点は見極めておいて、対面が必須だと判断した場合は、相応のコストを払う覚悟が必要だと思います。

指針4「ある程度、少人数（4〜5人）の部屋を用意する」

特に入社したてだったり社歴が浅い人は、そこに大勢の人がいるとどうしても発言をためらってしまうものです。適当そうなキャラに見える自分も最初はそうでした。入ったばっかりの頃は70人からいるAWSチーム部屋に書き込むのは、それなりに緊張するんですよね。やっぱり。

なので、そういう大きめの部署単位の部屋じゃなく、4〜5名程度のよく顔を見知った人がいる部屋があると、発言のハードルが低くなって良かったりします。

AWS事業部のアーキテクトグループは、4人のサブチームに別れているのですが、それぐらいの人数のチャット部屋だと、「昨日見たアイカツ！が、やばかった。エルザ様泣けるで、これ・・・」とか、どうでも良い話がしやすいです。

最初のチャット書き込みのハードルを下げるには、意識してそういう部屋を作るのもありですね。

指針5「良いことがあったら過剰なまでにリアクションする」

AWS事業部は、AWS認定試験5種を全てコンプリートすることが求められます（むしろ、持ってないと人権が無い）。必然的に、メンバーも認定試験を受けてその結果をチャットで報告することがよくあるのですが、そのときの様子がこちら。

合格報告には過剰なまでにクラッカーが飛び交います。1日で二人合格したりすると、クラッカー50個ぐらい乱舞します。

はっきり言ってクラッカーに情報量は皆無だし、前のログが流れまくるんですが、なんかね、楽しいんですよこれ。自分はたいていクラッカーだけじゃなく、ビールとかケーキも混ぜます。前後がクラッカーだけでも、徹底して空気を読みません。

これに関連して、粕谷さんのセッションで印象に残ったスライドに、こんなのがあります。

この「少し大げさに感情表現を入れると良い」ってところは非常に納得するところであって、テキストコミュニケーションって、どうしてもフラット、もしくはちょっと不機嫌気味に伝わり気味なんですよね。なので、逆に良いことがあったときには、過剰なまでにどんどんパフパフやっておくと、わけの分からない一体感が生まれて良いんですよ。

ここらへん、多分に主観も入ってますが、自分は好きです。

指針6「雑談OKかNGかを部屋ごとに明示する」

これは、指針5とセットでおさえておくべきことなんですが、業務上必要となる連絡をする部屋と、雑談してログが流れるのを良しとする部屋はあらかじめわけておくべきです。

クラスメソッドでは、基本全ての部屋で雑談はOKなんですが、業務上の連絡事項がある部屋については雑談禁止と明示されてます。

• 全社業務連絡（必読）
• 佐久間オフィス共有（雑談禁止）
• 岩本町オフィス共有（雑談禁止）

「雑談のせいで、必要な情報ながれてもうたやんけぇ・・・」という不要な軋轢をうまないためにも、ここらへんは予め分けておいたほうが良いです。

まとめ「リモートワークという孤独を補完するコミュニケーションツールの使い方を模索し続けるべき」

ここまで書いてきて改めて思うのは、リモートワークを円滑にすすめるのに必要な事って、どういったツールを使うかとか、どんなルールが必要かという話ではなく、それをどう人間が活用するのかという魂の問題だってことです。

良いことがあった時のクラッカーも、「誰かが合格したら、一人一つのクラッカー投稿必須」とかルール化したとします。アホすぎワロタですよね。そんなもん、好きにしろと。ただ、みんながなんとなく意識することで空気は変わっていくんだと思います。

働き方改革の流れでリモートワークを取り入れる会社も増えてきていますが、リモートワークを組織になじませるためには、そういった有形無形のルールと文化を織り交ぜながらゆったり進んでいく覚悟がある程度必要なんじゃないでしょうか。

恐らくは、ツールとルールを用意しただけですぐに理想の運用ができるものではないと思います。

皆さんのリモートワークの取り組みの中で、今日のエントリが少しでも参考になれば幸いです。

それでは、今日はこのへんで。濱田（@hamako9999）でした。