会計チームで債権周りの開発をしている hachi (@hachiblog)です。自分は 2022年4月 に関西拠点初めてのfreee会計チームのメンバーとして入社しました。会計チームは現状 3〜4人の小さいチームがいくつかあるようなチーム構成になっています。今後関西にも会計チームのメンバーは増えると思いますが、今はその中のひとりとして東京のメンバーと仕事をしています。
自分以外のメンバーは東京にいるなかで３ヶ月仕事をしてきて、「コミュニケーションハンデがある中でよくやってくれている」とお褒めの言葉を頂いたので、自分が気をつけていることや自分が自然にやっていることで良かったことを言語化してみました。 関西拠点勤務とは言いつつ、東京のメンバーと働くのがメインなのでフルリモートに近い働き方になっています。自分と同じように働き方がリモート勤務である会社に転職したり新卒入社した人の参考になれば嬉しいです。
前提と感謝
もちろんここからは自分がやったこと、頑張ったことを書くわけですが前提としてオンボーディングがスムーズだったのはチームや会社の仕組みの力が大きかったと思います。 freee は誰に話しかけても親切に答えてくれますし、普段一緒に仕事をするメンバーも相談したいと言ったらすぐビデオ会議つなげてくれたり Slack で爆速返信くれたりとすぐ解決できました。freee ではオンボーディング時の 1on1 の頻度を増やしていたり、Onboarding Partner というメンターがついたりと仕組みとして新しく入った人をサポートする環境が整っているなぁと感じました。
そのうえでプラスアルファ自分が頑張ったことでより早くチームに馴染んで成果出せたよ！という話を今回はしたいです。
ここ3ヶ月の成果
書ける範囲で書くと以下のようなことをやっていました。自分としては入社3ヶ月にしてはいろんなアウトプットをしていて、チームへの貢献もできていると思っています。
- 開発環境のセットアップとドキュメント更新
- 債権周りの新機能開発
- freee 会計の債権周りの一部リファクタリング
- freee 会計の債権周りの大きなリファクタリング方針提案
- rspec の速度改善や速度改善しやすくなる変更、ドキュメント作成
- その他開発環境改善
基本的な考え方
入社してすぐかつフルリモート勤務ですぐ活躍するために重要なのはとにかく自分に入ってくる・自分からでていく情報量をできるだけ早く増やすことだと思っています。「入社してすぐ」、「関西拠点で東京のメンバーとはたらく」ことはコミュニケーション上どのようなハンデを生むでしょうか？
入社してすぐのメンバーが負うハンデ
入社してすぐのメンバーと既存メンバーとの一番の差は共有している情報量の差です。このとき、一般的に社内情報が入社したメンバーに足りていないことに目が行きがちですが、それよりも入社したメンバーにとって重要なのは「自分の情報が社内に全く流通していない」ことです。
自分は何ができて何ができないのか、今の課題と将来やりたいことはなんなのか、なにが好きでなにが嫌いなのか。これらの情報がないと、上長が仕事を振るうえでタスクのミスマッチが発生してしまうので難しいタスクは振りづらいですし、他のメンバーからしても情報が少ないと話のネタが少ないので話しかけづらかったりします。結果的に自分の仕事は簡単なものに限定され、仕事がしづらくなります。チームメンバーとして早くバリューを出すためにはこの状況を早く脱する必要があると言えます。
地方拠点にいながら東京のメンバーと働くハンデ
一方、関西拠点にいることは東京のメンバーとどのような差分が生まれるでしょうか？
自分は東京にいるメンバーと仕事をするため、「いざとなったらオフラインで話そう」ができないのは少しハンデに感じました。また、地方拠点でなくても全社的な働き方がリモート出勤ベースのときに入社する場合、以下のようなハンデがあります。
- 小さいことを話しかけて聞けない
- カジュアルな相談がしづらい
- 進行状況を共有しづらい
- ビデオ会議でも仕事の話メインになるので人間味が薄くなる
- 雑談によるセレンディピティや他チームとの交流が起こりづらい
いくつか挙げましたが、フルリモートで生じる問題は結局コミュニケーションの問題です。物理的距離があるために、コミュニケーションの手段が限定され、同期的コミュニケーションが激減し、情報の次元が減ります。ここで情報の次元が減ると言っているのは、五感のうち視覚と聴覚しか使えなくなることはもちろん、視覚的にもチャット＋ビデオ会議 で写っている顔しか情報が得られず、リアルで会うことによる多面的な情報が受け取れなくなることも含んでいます。ランチを一緒に食べたりするのも情報の一つと言えます。
情報は情報を呼びこむ
さて、２つの属性から生じるハンデを補うのが最初に書いた「とにかく自分に入ってくる・自分からでていく情報量をできるだけ早く増やす」という戦略なのですが、「できるだけ早く」とあえて書いています。 なぜかというと、情報は情報を呼び込む性質があるためです。
自分の興味や仕事でやっていること、やった改善を自分から発信すると、反応が返ってきます。共感や感謝が返ってきたり、付加情報が返ってきたり、それ自体が間違っている場合は訂正された情報が返ってきたりします。また、周りの情報を吸収すると、新しいアイデアや興味が自分から湧いてきます。
少しコストはかかりますが、できるだけ早く社内情報をキャッチアップし、自分の情報を多く開示することによって周りから受け取れる情報量が増え、自分に適した情報も入ってきやすくなります。この状態を早くつくるのが重要だと考えています。
以下では情報のインプットとアウトプットを増やす具体的な戦術を書いていきます。
インプット
「インプットを増やす」と書きましたが、個人的にインプットで重要なのは「逃さない」ことだと思っています。逃さないとはどういうことかというと、わからないことをわからないままにしないということです。
わからないことは放置すると厄介です。関係なさそうだからいいやと放置しておくといざ関係するようになったときに改めて聞くことに自分は抵抗がありますし、相手もわかっている前提で話してきます。freee だと略語や社内だけで通じる単語が少なくないですし、プロジェクトの途中で参加するとなぜこのプロジェクトをやるのかが理解できなかったりします。わからないことは日々湧いてくると思ったほうがいいでしょう。
わからないことへの対処
わからないことをわかるには「自分で調べる」と「誰かに聞く」の二つの方法がありますが、入社してすぐの場合は後者のほうが期待値的には圧倒的にコストが低い場合が多いです。既存メンバーだと知ってて当然のことが多いので、答える側もコスト低く答えられます。
また、聞くというのはインプットとアウトプット両方の役目を果たしており、自分が知らなくて興味を持っていることが、他のメンバーに伝わり一石二鳥です。
とはいえ聞きづらいタイミングも存在します。自分は人に聞くときには以下のことを気をつけています。
すぐ聞く
わからないことが生じたら、基本的に「すぐ聞く」のが一番の解決策です。前提を説明し直す必要もないですし、その場ですぐに答えてもらえるなら話を少し中断するだけで済みます。最初のうちはわからないことは日々増えるのですぐに解決しないと手に負えなくなります。例えば自分が常に一緒に仕事をしているチームでのミーティングや、関わっているプロジェクトのミーティングなどはぜひそうすべきです。中断してでも自分が情報をキャッチアップすることはチームの開発速度を上げることに貢献します。
また、仕事をしているときに疑問に思ったことや、他の人が社内チャットで発信している内容で疑問に思うこともあるでしょう。そのときでもすぐ聞く方がよいです。回答が複雑になりそうなら ビデオ会議 で聞くのも有効ですが、基本的にチームの Slack にメッセージで聞くのがよいと思います。物理的に会えると隣の席の人にすぐ聞けますが、その人の作業を中断してしまうというデメリットが生じます。Slack で聞けば非同期コミュニケーションで答えてもらえるのでここは Slack で聞くほうが生産性という点でも良いです。
ストックする
すぐ聞けないタイミングもあります。例えば自分が仕事していて疑問に思ったけど今やっていることには関係ないことであったり、チームのミーティングでも議論がとても白熱していて聞きづらそうな雰囲気のときだってあります。
その場合でも放置をしてはいけません。疑問に思ったことは必ずストックしておきましょう。方法はおまかせします。疑問リストを作ってもいいですし、日報に書いてもいいです。自分は作業メモに書いておき、 #疑問 のようなタグを最後につけて、あとから追えるようにしています。
そうすることで、後で slack で聞いたり、上長との 1on1 で聞くタイミングができたときに聞いたりできます。疑問に思ったことはあとからだと忘れがちなので絶対にメモしておきましょう。
魚の釣り方を聞く
有名な格言で、「人に魚を与えれば一日で食べてしまうが、魚の釣り方を教えれば一生食べれる」的なやつがあります。これを情報を得る側として意識しておくとより良い情報が得られます。調べてもわからず、聞いたら一瞬でわかったような情報は特に出どころを確認しておくとみんな幸せになれます。
特に社内情報だと暗黙知になってしまっている情報もあります。情報を受け取ったときに出どころを聞いて暗黙知っぽかったらドキュメントを書くようにすると自分のアウトプットにもできるので有効です。
わからないこと以外のインプットTips
わからないことへ対応するだけでかなり情報を得ることができますが、それ以外にもインプットでやるといいことがいくつかあるので紹介します
入っている Slack チャンネルを増やす
Slack はエンジニアの基本コミュニケーションツールなので色んな情報が流れています。 freee だととりあえずいろんなチームの雑談チャンネルに入っておくと、色んな情報が入ってきて便利です。これは社内向けですが、個人的おすすめは #times_kusa という :kusa: リアクションがついたメッセージが流れて来るチャンネルで、思わぬチャンネルが見つかる事があって面白いです。
上長や気になるメンバーのカレンダーを見てみる
freee はカレンダーが共有されているので、社内の動向や社内で起きているイベントを探し出すにはとてもいいです。直属の上長や２つ上の上長のカレンダーを見たり、ミーティングに紐付いている議事録を読んでみると新しい発見があったりすると思います。
アウトプット
アウトプットの How で重要なのは何でもこまめに共有することです。リモートでない場合も重要ですが、リモートだと特に自分から発信しないとその人の仕事の進捗やその人自身が見えてこないです。本当にくだらないことでも共有することをおすすめします。入社３ヶ月で自分がやった具体的なアウトプットを例に挙げつつ Tips 風にポイントを書きます。
times（分報チャンネル） は作らない
times チャンネルといって個人の分報用に slack チャンネルを作っている人は多いと思います。自分も一時期作っていました。ただこれは個人の自由なんですが、今の自分の考えでは times チャンネルは作らないほうがいいと思っています。times は自分が気軽につぶやけるというメリットはありますが、デメリットも多いです。以下に３つデメリットを書きます。
１つ目は伝わる範囲が限定されてしまうことです。社内で有名な人でその発言が有益だとわかっている人なら、times に多くの人が入ってくれると思いますが、一介の新入社員が作った times に入ってくれる人がどれだけいるでしょうか。自分が所属しているチームの人や自分のメンターは入ってくれると思いますが、それならチームの slack チャンネルに書いたほうがよいです。
２つ目は誰に向けて書いているのかがわかりにくくなってしまうことです。times に書くと書いた人の気持ちとしても、自分のつぶやきとして書いてしまいますが、そういうつぶやきは他人が反応しづらいことが多いです。もちろん発信することで自分の状況を伝えることはできますが、コミュニケーションを生み出すという点で times 内でのつぶやきはちょっと損をしていると思っています。
３つ目に議論になった場合に知識の分断が起こりやすくなることです。 times に書いた何気ない疑問が意外と組織で重要な点で、議論に発展することはあります。そのようなときに議論になりそうだからチームチャンネルに移ろうという話になることは殆どありません。他のメンバーからすると、どこで話されていたのかわからず急に話が進んでしまっているように見えるでしょう。これはよいことではありません。
times チャンネルは用法用量を守ればゆるく閉じた楽しいチャンネルになるのですが、そこの加減がかなり難しいと個人的には感じています。それよりは自分のことを知ってもらったり、仕事の進捗を共有したりするためにチームのチャンネルに投稿する方が考えることが減るので何倍も楽です。
自分個人のつぶやきや考えをチームのチャンネルに投稿していいのだろうかと躊躇することもあると思いますが、それ自体が意外と重要な議論に発展したり、自分の人となりを伝えておくことでチームでお互いに仕事をしやすくなることは多いです。あまりにプライベートな投稿を連続でするのは控えたほうがいいと思いますが、仕事に少しでも関連していたり、プライベートなことをたまにつぶやくぐらいなら圧倒的にチームチャンネルに投稿する方がいいと思います。このブログもチームチャンネルにつぶやいたからこそ生まれました。
先日 Developers Hub に投稿された 自分が大切にしている Working Out Loud という考え方 - freee Developers Hub という plant さんの記事にも少し共通している部分があって頷きながら読んでいました。
社内ドキュメントを書く
新入社員だと、知らない社内情報が多いです。これはハンデだと最初の方に書きましたが、チャンスでもあります。既存メンバーが当たり前だと思っていることは当たり前ではなく暗黙知になっていることは往々にしてあります。それを社内ドキュメントとして公開すると自分のアウトプットにもなりますし、自分のあとに入社した人のキャッチアップも早くなるのでとてもいいです。自分は開発環境のセットアップで躓いたところや言葉が足りてなさそうなところを補完したり、古くて間違っていた記載を直したりしました。
なんでも首を突っ込んでみる
参加自由のイベントだったり、アンケート回答だったり、社内の活動では別に参加しなくてもいいよという扱いのものは多いです。こういうものにも積極的に参加するとよいでしょう。そのようなイベントの場合普段一緒に仕事しない人もたくさんいるはずです。物理的に出社しているとそのような人とも話す機会がありますが、リモートだとほとんどないのでこういう機会を積極的に活用しましよう。
リモート勤務におけるアウトプットは自分のイメージを他メンバーに伝える重要なプロセス
アウトプットのやりかたで重要なのは何でもこまめに共有することだと書きましたが、なぜこまめに共有することが大事なのでしょうか。もちろん仕事をする上で報連相は大事だといいますが、オンライン上でのコミュニケーションではこまめに共有することは仕事の報連相以上に意味があることだと私は考えています。
冒頭でリモートだと情報の次元が下がるという話をしました。情報の次元が下がると、普通に仕事しているだけでは仕事の報告をするときに仕事の情報しか伝わらなくなります。
当然じゃないかと思われるかもしれませんが、物理的に出社して仕事の報告や相談をする場合、その人の話し方や挙動や前後の雑談などで仕事以外のその人自身の情報も伝わってきます。リモートだとそのような情報は頑張って伝えるしかありません。そのため、自分の興味あることや考えていること、疑問に思っていることをこれでもかと伝えることで、自分以外のメンバーに自分のイメージや考え方をやっと伝えることができます。そのため何でもこまめに共有することがリモートだとより重要な意味を持っていると考えています。
3ヶ月働いてできた次の目標
チームメンバーの協力もあり、３ヶ月でかなり社内の情報をキャッチアップできましたし、同時に自分のアウトプットも３ヶ月にしてはいいペースで出せたと思っています。これからも社内での自分を介する情報流通量は増やしていくことを心がけつつ、今後社内ではより積極的にチームに貢献するアウトプットを出したいです。また、これを社外にも適用してエンジニアコミュニティに対しての貢献もしていけたらと思っています。
結局いちばん重要なのは楽しむこと
さて、ここまで私のインプットやアウトプットの考え方や具体的方法を書いてきましたが、これらを参考にする際はぜひ自分が興味を持てるか、面白いかを重視するようにしてください。「なんでも首を突っ込んでみる」と書きましたが興味ないことに首を突っ込んでも迷惑なだけです。ちょっとでも面白そうだなと思ったら尻込みせずに何でも吸収し、発信する姿勢を持つことが重要だということが伝わっていると嬉しいです。
最後になりましたが、 freee では一緒に開発してくれるエンジニアを募集しています！（特に関西に来てくれると僕が嬉しいです） ぜひ話を聞きに来てください！
※iOSDCトークンはこちらです。#世話を焼いていくスタイル
