社内で最初のリモート正社員の苦闘（1.5y経過）

はじめに

このpostはIT地方エンジニア Advent Calendar 2018 15日目の記事です。

adventar.org

想定する読者

以下のような読み手の方に楽しんでいただけることを想定して書きました。

  • リモートワークにチャレンジできるチャンスがあるが、躊躇している
    • 一人一人に最適な解は違いますが、何かの励みになれば
  • リモートメンバーを抱えていてマネジメントに困っている
    • 私がメンバーとしてうまくいったこと、うまくいかなかったことが参考になれば。
  • リモートワークをしているが、キャリアパスに不安がある
    • 一応メンバーからリーダに昇格しました。リモートでもなんとかなるという励みになれば。
  • リモートワーク？なにそれ？たべれるの？
    • リモートワークを本当にやってる人もいるんだよ。

想定しない読者

逆に以下のような読み手の方の期待にお応えするのは難しいと思います。

  • リモートワークで悠々自適田舎ライフを満喫したい
    • 私が知りたいです
  • 社内にリモートワークの制度を作りたい
    • 制度を上から押し付けたらうまくいかないと思っています。やりたい人がその人なりにやって、自ら制度になることがおすすめです。
  • 地方でキャリアの選択肢が詰んでる
    • 私も詰んでましたが、偶然知り合いがいてなんとかなりました。再現性は謎です。

前提条件

会社について

  • 非IT企業
  • オフィスは東京
  • ITプロダクトは基本的に外注して作っていたが、近年新規事業を中心に内製化を進めている

個人について

  • ソフトウェアエンジニア（web中心）
  • 就職〜6年半は東京でエンジニアとしてSIer、web事業会社に所属
  • 結婚し、妻の実家近く（長野県）に移住し、地元のSI企業に勤めたのち、リモートワークで現職に

どのようにして最初のリモート正社員になったか

経緯

当時のチーム

前提条件に書いた通り、私が現在所属している会社はIT企業ではありません。 ITを使った新規事業を立ち上げるも、ITベンダーに丸投げになってしまいプロダクトを成長させることができずにいました。
そんな状況に危機感を持ち、IT系出身の事業責任者を引っ張ってきて、新規事業を任せました。
その事業責任者は、プロダクトを改善するためには強い内製チームが必要であることをよく理解しており、気心の知れた優秀なエンジニアを最初に一名正社員として採用しました。（この正社員一名は私の最初のリモート上司になります。）
当然一名では足りず、業務委託でフリーランスのエンジニア数名も平行して採用して、内製チームを作り上げました。 正社員一名＋衛兵チームで開発の最初の波を乗り切りつつ、事業責任者は正社員のエンジニアの採用を模索していました。
採用はwantedlyを中心にしたリファラルに特に力を入れていました。

この時採用をサポートしていたのが、私が東京のweb事業会社に在籍していたときに人事で同僚だった人でした。
その方はフリーの人事コンサルタントとして活躍していて、このチームの採用のwantedlyの記事をfacebookでシェアしていました。
そのシェアされた記事が私と現職の最初の出会いでした。

当時の私

私は当時地元のSI企業に勤めていましたが、東京のweb事業会社から転職した自分としては、スピード感や事業の成長といった側面で物足りなさを感じていました。
とはいえ、地元のIT企業は選択肢も少なく、キャリアに思い悩んでいました。

そんな中、現職の求人のwantedly記事と出会いました。
普段ならwantedlyの記事を開いて中身をみることもないのですが、

  • 知り合いがかなり具体的に紹介していたこと
  • その会社（現職）について、東京のweb事業会社時代に関わりがあったこと

が重なり中身を覗いて見ました。 内容を読むと、新規事業のグロースを支えるエンジニアを募集していて、JD的にも自分のスキルセットとマッチしていて、以前の経験から得られた業界知識も活かせそうであることが判りました。
チームが必要としていた人材像とマッチし、かつ自分が仕事に求めていたスピード感や事業の成長という部分がハマる。こんなスイートスポットを逃してしまってはいけないと思い、私はすぐにその記事をシェアしていた人にメッセージを送りました。

先週○○さんがFacebook にpostしていた××社のエンジニアの募集に興味があって連絡させてもらいました。 もしリモートでの勤務が前提でも大丈夫であれば、一度お話を伺ってみたいと思っています。 よろしければ確認していただけないでしょうか？

互いにリスクを取る

すぐに返信があり、数日後事業責任者とハングアウトで面接を行いました。
業界の話で盛り上がりつつ、技術的なバックグラウンドについてもかなり突っ込んで聞かれました。後からわかったのですが、この事業責任者はもともとプログラマでした。
話の流れで、「じゃあ後はテックリードと役員とそれぞれ面接してもらいますね。まだわからないけど、私としてはもう採用でOKです。」と言われ、すっかり気をよくしました。
ところが数日後、改めて事業責任者からこんな連絡がきました。

私としては全然OKなんだけど、リモートでの採用の実績もないし、会社としてはかなり難しい感じになってます。正社員ではなく、業務委託という形ではダメでしょうか？

チームとしては採用したいけど、会社としてその後のキャリアも含めて何も保証することはできない、ということでした。
私としてはその会社がリモートで採用した実績がないことも知っていたので、会社側の事情も理解できました。しかしこのチャンスを逃してしまってはこの先キャリアの選択肢が減ることはあっても増やすことはできないと考え、以下のような提案をしました。

では3ヶ月間業務委託として雇ってください。それでリモートでも成果が出せると会社で判断してもらえたら正社員として雇ってください。

会社としてリモートで正社員を雇うというリスクを負うことに対して、自分も一時的にフリーになるリスクを踏む形で提案しました。
結果としてこの提案を受け入れてもらい、業務委託の3ヶ月を経て正社員として採用されました。

なぜうまくいったか

一般的な解

リモートであれオンサイトであれ、求人に応募する場合は自分のスキルセットや志向がそのポジションにマッチすることが前提です。
当然リモートワークの求人数はそうでない求人数に比べると格段に少ないので、私もリモートワークの求人の中から自分にあったポジションを探そうとしていたら、もっと苦労していたと思います。
その意味では、自分自身のシーズと採用する側のニーズがマッチする求人と巡り合ったということが一番の要因だと思います。

不確実要素をいくつ受け入れるか

採用する側としては一度にたくさんの不確実要素を受け入れるのが難しいという課題があります。
例えば求職者をチームのメンバーとして採用する場合、「年齢（≒のびしろ） × スキル × 業務知識」のような複数のディメンジョンを考慮して採用をするのが一般的です。
「この人は別の業界から来るから業務知識は少ないけど、若くてのびしろもあるし、エッジの効いたスキルを持っている」など、仮に一つのディメンジョンが採用の基準に到達していなくても、他のディメンジョンでカバーできると思います。 これを、採用する側もされる側もリモート未経験とう状況に適用すると、かなり難しい状況になるのが想像できると思います。
幸い私は、年齢はチーム内で比較的若く、面接の結果スキルセットは問題なく、業界知識はある程度あり、かつ紹介者から性格についてもある程度問題ないという事前のインプットをしてもらっていました。
これらの要素が重なり、採用する側として受け入れなくてはいけない不確実要素が「リモートワークである」という一点のみに絞ることができました。 その不確実要素についても、正社員として雇用する前に業務委託としてトライアルすることにより事前に潰すことができました。

採用する側、される側のどちらかがリモートワーク未経験という場合は、いかに事前に不確実要素を抑えられるか、これが重要だと思います。

人に依存する部分も大きい

採用する側がリモートに対して寛容であることは前提です。
特に直接の上司となるリーダやマネージャが、過去リモートワークでの失敗体験などを抱えている場合は難しいと思います。
その意味で、リモートワークでの人材募集をしていないポジションにリモートとして応募する場合は中の人といかに繋がれるかが勝負になります。 （私の場合も、正面からwantedlyに応募していれば書類で弾かれたと思います。）
もし中の人とつながることができたら、次のようなことを確認してみると良いと思います。

  • リーダー・マネージャはリモートワークに対してポジティブか、ネガティブか
  • そのチームは会社の現在のメインストリームか、あるいは今後メインストリームになる可能性がどのくらいあるか
  • 経営層はオープンなマインドをもっているか

正社員として所属する場合、チームが解散した場合には他のチームに異動になることがほとんどです。
特にこれまでリモートワークが採用されていない会社の場合、チームを出ると社内で風当たりがきつくなることがあります。 そこで、チーム内でリモートワークを受け入れられるか、そもそもそのチームは安定的に仕事を続けられるか、そして経営層はこれまでなかった働き方に寛容であるか、ということが重要になります。

私の場合、リーダ・マネージャについてはリモートワークに対してかなりポジティブであることは事前情報としてキャッチアップしており、業務委託期間に2番目、3番目を確認しました。
正直なところ、今もまだメインストリームにはなっていませんが、なんとか同じチームで継続して働けているので、そこまで大きく見誤ったわけではなさそうです。

マネジメントされる側としてのリモートメンバー

私が業務委託として入場したタイミングで、件の正社員のエンジニアがリーダーとして私の上司になりました。
最初はオンボーディングのため1週間オンサイトに出社し、その後は2週間に一度水曜〜金曜出社するというリズムです。
単純に考えると4週のうち6営業日出社していることになっています。

マネジメントされる側としては基本的には良いメンバーシップ、フォロワーシップを発揮するということにフォーカスすることが大事だと考えています。
リモートから良いメンバーシップ、フォロワーシップを発揮するために特に気をつけて実践していたことを以下に書いていきます。

出退勤

基本的にはslackで朝作業を開始するタイミング、お昼で席外すタイミング、仕事を終えるタイミングでslackでつぶやきます。
毎日同じリズムで仕事をすることで、マネジメントする側に安心感を与えることができます。
リーダーや他のオンサイトメンバーから見たときに、毎日同じくらいの時間に情報がpushされてくると、それだけでチームの一体感が生まれます。

これは一見簡単なことのようですが、忙しくなったり仕事へのモチベーションが下がったるなど、不調になるとついつぶやくのを忘れるようになってしまいます。
特にリーダーになってから思うのですが、メンバーごとのルーティン作業の質や量に変化があったときには、何かしらの合図だと考えられます。
リモートで顔を合わせないからこそ、自分でも気付きにくい自身の変化を周りにpushする方法としても、出退勤の合図はとても役立ちます。

少し古いツールですが、私たちのチームではこのツールを使っています。

blog.masuidrive.jp

朝会

毎日の朝会には、ビデオチャットで参加しています。
ここでメンバーシップとして重要なことは、いくつかあります。

  • 朝会の前に、前日の日報を見直して喋ることを準備する
  • 簡潔に、はっきりと喋る
  • 自分のタスクに関連するメンバーの表情や雰囲気を読み取る
  • よく聞こえなかったり、多少情報が欠落しても気にしない
  • それでも知りたいことがあるときには、容赦なく他の人の話を遮って聞く
  • 朝会の後に自分が喋ったことをslackで再度共有する

事前準備に関しては結構重要です。
丸腰でいくと「なんか色々やってました」のような報告になってしまいがちです。
オンサイトの場合は「あれ、昨日あの作業やってたよね？」のようなフォローが相互になされるのですが、それがないリモートメンバーは自分のことは自分で伝えるしかありません。
「どんなことでハマったか」「誰とやりとりして時間を使ったか」など、その人の1日が想像できるような報告が望ましいです。

また、どんなに頑張っても、1:Nのビデオチャットではリアル対話の70%くらいの情報量をゲットするのが限界です。
2~3割くらいは聞こえなくても気にしないおおらかさが必要です。
それでも「ここだけは」という部分に関して、文脈や誰かが喋っているかなど気にせずズケズケと聞くことが大切です。その姿勢がリーダーや他のメンバーに安心感を与えてくれます。

日報

基本的にリーダからは毎日ソースコードがコミットされることが一番見えやすい進捗です。
しかし現実の仕事の中では調整や思考に費やす時間もかなりの割合を占めると思います。
隣で仕事をしていれば、「あーいまハマってるな」とか「こいつ今完全に充電（twitter）してんな」とかわかるのですが、リモートだとその塩梅をどのように伝えるかが難しくなります。

当初私はこんな感じで毎日メールでリーダーに日報を送っていました。

・XXXXXXXXXXXX（案件名）
→先方と仕様について調整済み。明日実装完了し、prお送りします

・YYYYYYYYYYYYY（案件名）
　YYYY抽出条件の変更：完了
　htmlへの変数埋め込み：完了
　メールのレイアウト修正：完了
　単体テスト：作業中

これの良い点は日報を書くためにタスクをきちんとこなすことができる点です。
そのために、日報は1日の終わりに書くのではなく、作業しながら書くことがおすすめです。
メールでもslackでもテキストエディタでもよいのですが、下書きとして朝から「これから一時間でこのタスクやろう」と決めて1時間ごとに日報をアップデートします。
そうすると自分の1日のリズムもわかるようになるし、夕方1日何したかを思い出すような無駄な時間を無くすことができます。

ペアプロなど

チームではペア（モブ）プロ、ペア（モブ）運用作業を取り入れ、チーム内でのスキルの平準化を進めています。
最近のビデオチャットツールでは、どれでも画面共有機能があるので基本的にはリモートでも問題なく参加することができます。
ただ、モブプロのモデレータ側の場合にオンサイトの温度感に乗り遅れることがあります。
特に自分の不得意分野であったり、slackなどの通知がうるさいとオンサイトに比べて集中しにくい状況になります。
この解決策はまだ見つけられていないので、リモートモブプロのライフハックをお持ちの方に是非聞いてみたいです。

マネジメントする側としてのリモートリーダー

チームに入ってから1年弱が経過する頃、件のリーダーが退職することになりました。
その時点でチームには私を含めて4名の正社員が在籍しており、その中で一番早くjoinした私がチームのリーダーを引き継ぐことになりました。 チームでは当時スクラム開発を導入しており、私もそれを引き継ぐ形でスクラムをベースにしたチームのリーダーになりました。 スクラムを引継ぐ難しいポイントやリモートスクラムについては、別記事にしようと思います。

リモート面接

私がリーダーになると同時に、業務委託メンバーの退場、正社員メンバーの配置換えが行われ、最初の仕事としてチームメンバーを集める必要がありました。
特に最初は業務委託メンバーを採用するため、毎日レジュメに目を通し、毎週面接を行いました。 とにかく早急にメンバーを採用する必要があったため、先方の都合に合わせて面接のスケジュールを組み、結果的に私がリモートで面接をする機会が増えました。

面接スタイル

面接は毎回オンサイト側に来社してもらい、面接対象のエンジニア、そのエージェント、私（リモート）、チームメンバー1名の合計4人で行いました。
面接の流れは、私がプロダクト、技術スタック、実際にお願いする業務の説明を行い、先方のエンジニアに自己紹介をしてもらい、そこから質疑応答というスタンダードな流れで行いました。
このようなスタイルの面接は他に行っている会社がないのか、エージェントの方が驚くことが多かったです。
ここでもいくつかtipsがありますのでご紹介します。

tips

  • チームメンバーのマシン以外に、ビデオチャット用のマシンを1台用意する
  • たいていレジュメはその場で手渡されるので、事前に入手して開いておく
  • 難しい名前の読み方の場合、ビデオチャットで聞き取れないことがあるので、事前にわかれば聞く。最悪わからない場合でも動揺しないように心の準備をしておく
  • ホワイトボードを使って何か説明してもらうタイプの面接内容の場合は、事前に何パターンかイメージを膨らませておくとディテールが見えなくても動揺しない
  • オンサイトの場合でも事前に質問したいポイントを絞っておくことが重要だが、リモートの場合会話がターン制になるので、タイミングを逃さないためにも事前の質問事項の作り込みは重要になる

朝会のところでも触れましたが、どうしても細かい部分で聞き取れなかったり読み取れないことがあります。そこで、実際に交わされる対話のイメージをどこまで事前に膨らませておけるかがとても重要になります。 また、マシンなどハード面の準備はできる限り万全を期しておかないと、相手に悪い印象を与えてしまいます。逆にリモートでもスムーズな面接が実施できると、働き方の多様性をアピールできる良いチャンスになります。
また、今後の取り組みとしては、面接相手のエンジニアの方、エージェント、チームメンバーも含めて全員ビデオチャットで環境を揃えて面接ができるとよりスムーズな面接ができるのでは、と考えています。

情報共有

問題があることに気づかなかった

リモートメンバーのときには、リーダーに自分の情報をpushすること、朝会でチームの情報をpullすることで、オンサイトのチームリーダーがhubとなり情報を共有することができていました。
リーダーになってしばらくの間、私はその前提がよくわかっておらず、メンバーのときと同様に自分の情報は一日に数回push、朝会でチームの情報をpullしていました。
程なくして、これまでhubとなっていたリーダーの役割がなくなったことにより、メンバー間でお互いがやっている仕事、チーム外の情報などが全く把握できなくなりました。

ツールでは解決できず、悪循環に

この状態になって、初めて情報を共有するということに対して能動的に考えて働きかける必要性に気づきました。
最初にTrelloを取り入れました。朝会で各メンバーがTrelloに登録済みの当日の行動計画を共有し、翌日に進捗状況を共有をすることで、デイリーで作業状況を把握することが狙いでした。
しかしTrelloは2週間ほども持たずに形骸化してしまい、実作業とTrelloとの乖離が大きくなってしまいました。
状況をお互いに共有しても、その状況をより良くするためにチームとして何も改善することができなかったためです。
実際に積極的に情報を共有してくれるメンバーがいても、その情報をチーム全体としてプロダクトやプロセスを改善するために役立てる方法がわからず、そういった状況が情報共有へのモチベーションを下げていました。

何のために情報を共有するのか

転機となったのは、メンバーの入れ替えでした。
前任のリーダーがまだ在籍した頃チームから退場した業務委託メンバーが、縁あって戻ってきてくれたことをきっかけに過去と現在のギャップを客観的に、かつ前向きに共有してくれました。
これをきっかけに、「前を向いて改善するための情報共有」の仕組みをチーム作ることに注力し始めました。
まずはそれまで2週間だったスクラムのスプリントを1週間に縮めふりかえりの頻度を高めました。 また、この時期に参加したアジャイルの勉強会で「ふりかえりの問題のひとつは、ふりかえりをやるまで各メンバーが問題を抱え込んでしまうことだ」という話に感銘を受け、朝会でも問題点を抽出できるように工夫を加えたりしました。
この頃になると、朝会のファシリテートは基本的にリモート側の私が行い、自然に私が情報を積極的に集めに行くようになっていました。

更にその後、認定スクラム研修を受講するなど、スクラムをベースにした開発プロセスの改善を繰り返し、現在では朝、昼、夕方の1日3回、あくまでも積極的なメンバー間での情報共有の場を設けるようになりました。
その場では、各自の状況を共有しハマっていることがあれば「ペアプロでやっつけよう」などの改善策をその場で考えて実施できるようになりました。
情報共有から改善へとつながるポジティブなフィードバックループを作ることで、物理的な距離を意識しなくても、お互いが考えていることや実際に行っている作業が見えるまでに情報が同期されるようになったのです。

まとめ

長文になってしまいました。
書いている最中に気づいたのですが、リモートとして最もハードルが高いのは、やはり最初にチームにjoinするフェーズなのだと思います。
それ以降のメンバーとして、リーダーとしてという話は、リモートでもオンサイトでも本質的にはあまり変わらず、そこを押さえた上でコミュニケーションチャンネルをどう確立するか、という問題なのだと思いました。

リモートワークがすでに文化として根付いている組織であれば別ですが、これからリモートワークを導入するのであれば、制度を先に決めないことをおすすめします。
リモートで働くメンバーや、そのメンバーを擁するチーム、そのチームのプロダクトなど、状況によって必要な仕組みは変わっていくと思います。
その変化の中でポジティブなフィードバックループを生み出す仕組みというのは事前に決められるものではなく、失敗を繰り返しながら当事者が自発的に作り上げていくものだと思います。

リモートワーカーの皆様や、これからリモートワークにチャレンジする方の励みに少しでもなれば幸いです。