こんにちは、株式会社キャスターでCTOを担当しています、福田です。

株式会社キャスターはオンライン秘書サービスを主な事業として展開しており、100名以上の従業員全員がフルリモートで働いています。

エンジニアチームもその例外ではなく、当然全員がリモートワーカーで、各自が自分の好きな場所に住み、集中できる環境でコーディングに勤しみ、必要に応じてオンラインで活発に議論しながらモノづくりをしています。

このブログで伝えたいこと

そんな我々エンジニアチームは、自分たちにとって働きやすい環境は何かを追求するため、日々新しい取り組みを実験として試しながら、リモートエンジニアリングに最適なツールやルール作りに取り組んでいます。

今回のこのブログでは、そんな我々が、日々愛用しているツールや、リモートワークをする上で気をつけていることや組織のルールの一部をここで紹介させていただこうと思っています。

この記事を読んだ皆さんが、一人でも多くリモートワークって思ったよりも簡単そう、ウチにも取り入れてみようかな？と思ってもらえることを祈っています。

リモートワークで欠かせないツール群

Slackのオンライン通話機能

エンジニアであればもちろん、Slackを知らない人はいないと思います。

しかしながら、意外とSlackの通話機能(画面共有機能)を使っている人は少ないのではないでしょうか。

意外と知られていないですが、このSlackの通話機能、本当に便利です。

通話機能はSlackの画面右上にある受話器のマークをクリックすることで利用可能です。

無料版では1対1の通話のみですが、有料版ではグループ内全員での通話も可能です。
Skypeと同じように画面共有したり、カメラで顔を写しながら通話も可能です。

便利ポイント1) 画面共有を受けている側がペンで自由にマーキングできる

コードレビューなどをしていると、「このif文だけど…」とか言ったように、レビューしている側がコードの該当箇所を指し示す場合が多いと思います。

これをリモートでやる場合、Skypeなどの画面共有機能では、レビューされる側が画面を共有しつつ進めるため、レビューしている側がうまく該当のコードの場所を指定できず結構もどかしい思いをすることがあります。（もちろん、129行目の…とか言えばいいんですが、結構面倒くさいですよね。）

このもどかしさを解決してくれるのが、Slackで画面共有をした時に使える、画面上でのマーキング機能です。

この機能は、簡単に言うと画面を共有されている側が、共有画面に対して自由にペンで印を書くことができ、共有している側に伝えたい該当箇所を簡単に明示的に指し示すことのできる機能です。

ちょっと伝わりにくいかもしれませんが、下の画像のように、共有画面に対してペンで印を書くことができ、それが共有している人に対して、リアルタイムに見えます。

この機能を使うことで、レビューしている側が、コードの該当箇所を簡単に指し示すことができ、同じ場所でディスプレイを共有しながらコードレビューをしているのと全く遜色ないUXで、レビューを実施できます。

便利ポイント2) 画面共有している相手に対して、PCの操作権限を与えられる

ペアプログラミングをしていると、ちょっと相手のPCを借りて、代わりにコードを書くといったシーンも多くあると思います。

Slackには、画面共有をしている相手に、画面の操作権限を与えることもできます。

使い方は簡単で、画面の共有時の下のミニパネルに表示される、矢印のポインタのアイコンをクリックすることで、相手に操作権限を与えることができます。

この機能を使うことで、あたかも同じ場所で相手のキーボードを一時的に借りて、コードを書くといったことがとても簡単にできます。

ペンタブレットとオンラインホワイトボード

同じ場所で仕事をしていると、ホワイトボードを使って、図を描きながらディスカッションしたり、付箋を貼ったりしてブレストを行うことも多いと思います。

僕もホワイトボードは大好きなので、オンラインでなんとかホワイトボード的なファシリティを実現できないか常々考えていました。

そこで行き着いた答えが、realtime boardというクラウドのホワイトボードサービスと、ペンタブレットの組み合わせです。

ペンタブレットはワコムの一番安いタブレットを使用しており、弊社のプロパーエンジニアには基本全員に支給しています。

このペンタブレットを用いて、realtime boardに図を書くとこんな感じになります。(書かれている図は完全なデタラメなので、軽く流してくださいw)

最初は慣れが必要ですが、慣れると結構スラスラと図が書けるようになってきます。

もちろんこの画面をSlackの画面共有をもちいて共有しても良いですし、同時に書き込みしたい場合は、編集用のURLを共有したり、特定のユーザーにのみ編集権限を与えることもできます。
また付箋を貼りながら、全員でブレストすると言ったことも可能です。

このツールを使えば、オンラインで図を使ってさらっと説明したい！というもどかしさを、解消してくれるはずです。

ノイズキャンセリングイヤホン (できればBluetooth接続)

これは、チーム作業というより集中するためのガジェットですが、場所を選ばす仕事ができるというのがリモートワークの最大の利点なので、時として雑音がうるさい場合もあります。

私はこれを解消するため、BoseのQuietControl 30というBluetooth接続可能なノイズキャンセリングイヤホンを用いています。

このノイズキャンセリングイヤホンですが、驚くほど性能がよく、喫茶店など騒がしい場所でも一瞬で静寂に包まれます。

さらにどの程度ノイズキャンセリングするか？を簡単に調整できるので、少し人の話す声が聞こえたほうが良い場合も柔軟に調整できます。

そして、Bluetooth接続であることが購入後感じた意外なメリットで、私は考え事をしながら部屋の中をぐるぐる移動したり、あるいはMeeting中も割りとウロウロと動きながら思考を整理して話すほうが、論理的な判断ができることが多く、イヤホンをつけたまま会議中に自由に動けることが非常に大きなメリットになっています。(こうやって、Meeting中でも自由にぐるぐる動いて会話できるのもリモートワークの会議の良いところだと思っています。オフラインの会議でやっていたら怪しいですからねw )

リモートワークする上で気をつけているルール

リモートワークはオンサイトで全員が集まって仕事をするのと違って、常にお互いの顔や動きが見えているわけではないので、ともするとチームの一体感が損なわれてしまう可能性があります。

ここでは我々キャスターのエンジニアチームが、常々意識している組織運営のルールなどを記載していきます。

すぐ隣りにいる感覚でオンラインで会話する

先にお伝えしたとおり、リモートワークは個人が自分の好きな場所で仕事ができるというメリットがありますが、一方で全員で集まって作業する機会はほぼないため、メンバーが孤独感を感じたり、悩みを抱えたまま共有できないと言った事態が起こりがちです。

そこで、もちろんチャット上での頻繁なコミュニケーションは欠かせませんが、それだけでなく、私や他のチームメンバー同士で、すぐ隣りの席にいる感覚で話しかけてほしいと伝えています。

具体的に、私が心がけているのは、どんなに短い時間でも1日1回は各メンバーと直接会話する時間を設けるようにすることと、チャットで伝えにくい場合は、即座に通話と画面共有に切り替えることなどです。

また、Slack上でメンバーからのメッセージがあった場合は、独り言のような場合であっても、私は必ず反応するようにしています。(Slackはスタンプで簡単に反応できるから良いですね。)

また、緊急時やスピード感が求められる作業の場合は、オンラインで繋いだまま作業を進め、必要なときにいつでも話しかけられる環境を作ることも行います。

リモートワークは、とても孤独なイメージを持たれる方も多いと思いますが、弊社の場合は決してそんなことはなく、会議室の予約が必要ないことや、話しかけるタイミングもチャット上でメンションすれば良いだけなので、オンサイトに居るより、むしろコミュニケーションが取りやすい環境にあるとも言えると思います。

互いの立場を尊重し、感謝の気持ちを伝える

リモートワークの場合、相手の表情が見えにくく、感情が伝わりにくいという欠点があります。

これを解消するため、上で述べたように声を通じてのコミュニケーションをするように意識していますが、常に声でコミュニケーションをするわけではないので、やはりオンサイトでの作業と比べると感情は伝わりにくい部分はあります。

とくに、何もコミュニケーションがない状態だと、人間の心理的に不安になり相手に対して疑心暗鬼になってしまうという側面は少なからずあると思います。

それを克服するためには、相手のことを強く信頼する、相手の良い面を積極的に見つけ出す、相手の立場を尊重するといった、精神的な土台が必要です。

その土台の上に必要なのは、相手に対しての感謝や敬意の気持ちや、失敗をしてしまった場合の謝罪の気持ちをテキスト・メッセージで伝えることです。

例えば、私は、Pull Requestのレビューをする際、もちろん修正すべき点はコメントしますが、その一方で、設計上優れているな思う点を見つけて、コメントで伝えるようにしています。

また、頑張って対応してくださった場合には、Slackで感謝の言葉を伝えるように心がけますし、年齢に関係なく相手の意見が正しい場合は自分の過ちを認め、相手の立場を尊重するようにしています。

こうすることで、ともすると血の通わない無機質で乾燥した状態になりがちなフルリモートワークな組織においても、正しく血液が循環するようになり、躍動感のある組織に育つようになってきます。

感謝の言葉は組織という生命体において、非常に大切な栄養素です。 栄養素を耐えさせぬよう、しっかりと与えることを意識すると良いと思います。

仕事の成果を作業時間ではなく純粋なアウトプットで見る

リモートワークは、オンサイトでの作業と異なり、基本的に相手が何をしているか常に状況を把握できるわけではありません。（ただ、オンサイトであっても、本質的には把握するのは難しく、貴方の部下もディスプレイの向こうでコードを書くふりをしてYoutubeを見ているだけかもしれませんw）

よって、メンバーが真面目に仕事をしているかどうか？ は作業をした結果のアウトプットでしか計ることができません。

一方、私は本質的にエンジニアリングはリラックスしたフロー状態から生まれる瞬発力（パッとした瞬間のひらめき）が大事だと思っているので、8時間、眉間にしわを寄せたまま仕事をして欲しいことは全く望んでおらず、自分の好きな場所で、ときには景色を眺めたり散歩しながら、アイデアに思いを巡らせ、閃いたアイデアを一気にコードに落とす、集中力の緩急があって全くかまわないと思っています。

結論から言うと、エンジニアの仕事の良し悪しは、そもそもオンサイトであっても時間で測ってはダメで、本質的に出されたアウトプットで測られるべきと考えています。

では、この仕事の良し悪しを正しく評価するために必要なことはなにか？　それは、当たり前ですが、マネジメントやリーダー層が成果物の品質を正しく評価できる技術的感性を損なわないことだと思います。

悪しき風習として聞いた話ですが、エンジニアリングの生産性を書いたコードの行数で測ると言った、にわかに信じがたい都市伝説のようなメトリックスを置いているところも実際にあるようです。

そのコードは、得体の知れないコードのコピペかもしれませんし、単なる大量のrequire (import) 文だけかもしれません。あるいは、Loop文をなくして、アセンブラのように1行ずつコマンドを書けば無限に行数を増やせます。
マネジメント層がメンバーに対して、そんな表面的な評価しかできないようであれば、会社の技術基盤は遠くない将来、確実に足元から崩壊するでしょう。

少し話はそれてしまいましたが、コードの品質の良さや仕事の良し悪しは、そういった無機質なメトリックスだけで評価するのは限界があり、特にオブジェクト指向におけるクラスの責務が適切かどうか？などは、業務知識が乏しく、錆びた技術力しかないエンジニアでは正当に評価できません。

私も、キャスターの技術責任者として、メンバーの仕事の良し悪しを正しく評価できるように、自分自身の物差しである技術力に狂いが出ぬよう、週末や業務時間外を中心に、コードを書く時間を嗜むようにしています。

こうすることで、Pull Requestのレビューをする際も、設計上の危ない点や良い点を直感的に感じることができます。　またメンバーがちゃんと仕事をしているかどうか？を判断できるようになります。
リモートワークの組織の場合、マネジメント層であっても、こういったエンジニアの感性を常に研ぎ澄ませておく努力が必要だと思います。

リモートワークをちょっとだけ試してみる

以上長くなりましたが、リモートワークを前提とした開発チームとして、私達が普段良く使っているツールや運営のルールについて、一部になりますが綴らせていただきました。

この記事を読んで一人でも多くの人がリモートワークを試してみようかな？と思ってくれることを心から祈っています。　最初は色々と慣れも必要だと思うので、最初は自分の所属する小さなチームで週に1回だけリモートワークの日を試してみるとかでも良いと思います。
1人で集中して作業できることで、思わぬ良いアイデアが浮かぶことも多いと思います。

どうしても1人だと不安な場合は、Slackの通話機能を常時接続でやってみるのも良いと思います。

ただし、チームメンバーの一部だけが、リモートワークするといったことはオススメしません。
なぜなら、オンサイトチームとリモートのメンバー間で情報の格差が生まれ、チームの意思統一にズレが発生し始めるためです。

やるなら思い切ってチームメンバー全員でリモートワークするようにすると良いと思います。

リモートワークはオンサイトで仕事をする場合と多くの点において勝手が異なるので、最初は慣れるまで時間がかかるかもしれません。

ただし慣れると、都内の地獄のような通勤から解放され、各自が好きな場所で自由に仕事ができるので、本当に良いワークスタイルだと思います。

通勤というスタイルを継続したまま満員電車の苦しみから解放されるのは難しいですが、リモートワークの課題はツールや運営ルールで解決できることが多いです。

皆さまが快適なエンジニアリングライフを送れるよう、この記事の内容が少しでもお役に立つことを願って、この記事を締めくくりたいと思います。

最後まで読んでくださりありがとうございました。