リモートワークも4年を超えました。某ウイルスの影響で、急遽、リモートワーク（テレワーク）になった人も多いのではないでしょうか。そこで、4年間のリモートワークのノウハウを共有しようと思います。
ただ、現在、記事を書く時間が取れなくて、思い付いたものだけしか書いていません。意識せずに普通にやってるようなこともあるはずなので、それは時間が取れた時にあらためて書くことにします。
基礎情報
きっかけ
メンバー全員に子どもがいるので、仕事の合間に子どもの世話をできるようにと考えました。また、遠距離に住んでいるソフトウェアエンジニアを採用するという目論見もありました。
三姉妹のシングルファーザーとして、同じシングルファーザー、シングルマザー、ワーキングマザー、ワーキングファーザーが子育てをしながら仕事をする時のロールモデルを作りたいという思いもあります。なかなか難しのですが…
期間
最後に勤めた会社はITベンチャーで、自転車でオフィスに出社していました。シングルファーザーなので、定時前に子どもの保育園のお迎えに行って、晩ご飯を作って食べさせて、夜また仕事をするというスタイルでした。
退職後はフリーランスとなり、その後、ビジネスパートナーと共に起業しました。法人になって4年目、フリーランスの時期を含めると4年以上が経過しています。
業務内容
webシステムとスマートフォンアプリの開発がメインです。ふわっとした相談を動くシステムに落とし込むことを得意としていて、要件定義、設計、実装、保守と、上流から下流までカバーできます。
社外のソフトウェアエンジニアに開発を依頼して、マネジメントだけを行うこともあります。
形態
福岡市内にオフィスがあります。メンバーは市内と市外に住んでいて、オフィスには出社してもいいよ、としています。市外メンバーは、以前は宮崎県にすんでいました。
（そこで、就労規則の勤務場所を「自由」と書いて役所に提出したところ、前例がないからとひと悶着ありました…）
別の会社のメンバーと「リモートチーム」を組んでいるプロジェクトもあります。一時期は、東京、京都、福岡、宮崎の4拠点のチームで開発をしていました。
こちらから開発を依頼する開発パートナーも県外に住んでいます。また、福岡市内のソフトウェアエンジニアに依頼する時にも、物理的に顔を合わせることはありません。
複数のクライアントもすべて県外の企業です。相談を受ける時やプロジェクトの初期に1度だけ物理的に挨拶をするケースが多いです。
リモートワークのポイント
ポイントは、おそらくたくさんあるのですが、今ぱっと思い付いたものだけを書いておきます。
タスクを細かく明確に
タスクは細かいほうがいいですね。完了したタイミングで進捗報告をする場合、大きなタスクだと、いつまで経っても進捗率が変化しません。
また、どうなったら完了なのかを明確にしておきます。例えば「〜の調査」ではなく「〜を実現する」という感じです。
Backlogでプロジェクト管理をすることが多いので、その管理方法を少しだけ紹介します。
まず、タスクを登録する時に、タスク名を動詞で終わるようにします。「〜を〜にする」「〜を作成する」という感じですね。そうすると、どうなったら完了なのか分かりやすくなります。クライアントにも、そうやって登録してくださいとお願いしています。
タスクはマイルストーンで区切ります。マイルストーンも大きくなりすぎないようにします。Backlogの有料プランでマイルストーンを作ると、バーンダウンチャートが使えるようになります。個人的にバーンダウンチャートが大好きです。ひと目でプロジェクトが納期に間に合うかどうか判断できるのが良いですね。
この辺は、作業の見積もりなども入ってくるので、その手法も含め、また別の記事で説明したいと思います。
状況を把握する
いきなり賛否分かれそうですが、仕事の状況だけでなく、メンバーの体調や気分も（少なくとも対面で把握できる程度には）把握しておきたいと思っています。
体調や気分でパフォーマンスが変動するのはプロ失格だという経営者もいます。それはそれで良いのですが、僕はその人とは一緒に仕事をしたくないですね。不調時に最低限のパフォーマンスを出せることが大切だと思います。
昔、ニコニコカレンダーという手法があったのですが、まだやってる組織はありますか？こういうの好きなんです。
別プロジェクトのメンバーとは、毎週ビデオチャットで1 on 1という名の雑談をしたりします。
自分の状況を他のメンバーに知らせるには、もともと「分報」に近い形でSlackの自室に投稿していました。これは、強制するのも微妙だし、できる人とできない人の差が大きいのが難点です。
悩んでいることを呟いていると、メンバーからアドバイスや関連情報をもらえることも。
曖昧さの排除
リモートワークだとSlackなどのテキストチャットを中心にコミュニケーションを取ることになります。そうすると、検討中の情報なのか、確定した情報なのか分からなくなることがあるのです。そこで、オンラインのドキュメントに、検討中の情報と確定した情報（確定日と意思決定者も）をまとめておきます。
ミーティングなどの予定を決める時に、間違いがないように気をつけます。そのコツとしては、相手から「12日にお願いします」または「火曜日にお願いします」と送られてきた時に、「承知しました」ではなく「12日（火）ですね。承知しました」と返すようにします。日にちと曜日を組み合わせて確認することで、双方の勘違いを防ぐことができます。
メールやSlackでメッセージを送る時に、何度も読み返してから送信するようにしています。Slackで1行送る時にも、数回は読み返します。そして、どちらとも取れるような表現があれば、修正してから送ります。
最後に、ダラダラやり取りが続いて焦点がボケてしまわないように、オープンクエスチョンではなくクローズドクエスチョンを使います。つまり、「〜はどうしますか？」と聞かずに、「〜はこうしますか？もしくは、こうしますか？」と相手に選択肢を与えます。実は、選択肢は頑張って考えなくてもよくて、この質問形式にするだけでも相手から適切な返答が返ってきやすくなります。
早めのアウトプット
タスクが完了してからではなくて、早めに見せられる状態に仕上げて、マネージャーやクライアントにいったん見てもらいます。完了してから修正するよりも、途中で軌道修正するほうがコストが低いからです。
ソフトウェア開発では、例えば画面デザインのドキュメントを見せて何も言われなくても、実際に動くものを見せるとダメ出しされるということが多々あります。ソフトウェアエンジニアはドキュメントから動くものを想像するスキルが高いのですが、マネージャーやクライアントはそうではありません。また、忙しくてドキュメントをチェックしてないというケースもあります。
プロトタイプが動いている様子を動画にして共有したところ、好評でした。リアルタイムでデモを見せるのではなくて、いつでも確認ができる動画にしておくのは有効だと思います。
テキストチャットのコツ
テキストチャットのリテラシーが高いリモートチームであれば、メッセージの受信は受け手の責任としてしまったほうが良いです。これは、時間外であるとかその他の事情で送り手が連絡するのを躊躇するのを防ぐためです。とりあえず、状況を考えずに何でも共有し、受け手が通知のオンとオフを選択するようにします。リモートワークでは、情報不足が一番怖いです。
一方で、リテラシーの低いチームには、いろいろあると思いますが、とりあえずひとつだけコツを挙げます。送り手は、1投稿で内容を把握できるメッセージを送ってください。それから、挨拶はいりません。
例えば、このようなメッセージはよろしくないです。
saru: @taro おつかれさまです！
taro: どうしました？
saru: 共有ドライブに資料をアップしたのでご確認ください。
メンションがついたメッセージで、デスクトップやスマホに通知が来ますが、そこで今見るのかどうかを判断します。ですから、上の例のように「おつかれさまです」だけだと、強制的に反応せざるを得なくなってしまうのです。
saru: @taro 共有ドライブに資料をアップしたのでご確認ください。
これだけで良いです。時間がある時に資料を確認します。
リモートワークの課題
課題もいろいろあると思いますが、ぱっと思い付いたものだけ。
職種とスキルセットが限定される
ソフトウェアエンジニアはリモートワークと相性が良いのですが、どうしてもリモートでは仕事ができない職種も存在します。（ただ、紙の書類に印鑑を押すために出社しなければなならいというのは、なんとかなるんじゃないかと思いますが）
また、ソフトウェアエンジニアとしてのスキルと、リモートワークのスキルは別だと考えています。開発スキルの高いエンジニアがリモートワークに合っているとは限りません。リモートワークのスキルを高める（教育をする）ノウハウがあればいいなと思っています。
フォローがしづらい
ミスをしたメンバーを励ます、といったことがやりづらいです。どれくらい落ち込んでいるかが見えないので。
それにより、ミスや問題点を指摘する時に強く言えないということになります。逆に、リモートで強く言い過ぎるマネージャーは、もう少し考えたほうがいい気がします。
仕事をしすぎる
特にソフトウェアエンジニアだと多いと思うのですが、時間が区切られていないと延々と仕事をしてしまいます。
仕事の進捗は、Backlogで適切に管理していれば把握できるわけですから、マネージャーが気をつけるべきは、その進捗を出すために働きすぎていないかどうかです。健康面も気になりますが、休まず仕事をして実績を作ると、それ以降の行程の見積もりが破綻するという問題も生じます。
不健康になりがち
自宅で仕事をしていると、歩かなくなりますし、食事が不適切になることもあります。これは、本人がなんとかするしかない気がします。Slackで健康チャネルとか作るといいかもしれませんね。
それと、これはよく言われますが、椅子は良いものを使ったほうがいいです。
ツールなど
これも、ざっくり。詳しくはこちらを参考にしてください。Chromebookと書いていますが、macやWindowsでも使えます。
上の記事では個人利用のものも多いのであれこれ書いていますが、下に挙げているのはクライアントに利用してもらうために定番のものが多いです。
プロジェクト管理
Backlogを使うことが多いです。バーンダウンチャート大好きです。
情報共有
G Suiteを契約しています。これだけで、大抵のことは解決します。
コミュニケーション
Slackが定番になりましたね。プロジェクト単位なので、メンバーの多い企業のような問題にはまだ出会っていません。
ビデオチャットは、Zoomを使っています。有料プランなので、録画して見返すことができます。
スピーカーはこのシリーズがおすすめです。会議室に複数人集まった時に全方向の声を拾ってくれます。スピーカーもマイクも音がクリアで気に入っています。（オフィスにあるのはこのシリーズだと思うのですが、この型番なのか自信ありません…）
最後に
今回はかんたんなノウハウ紹介でした。もっといろいろ出てくると思うので、時間が空いたらまとめてみたいですね。
こんな感じでリモートチームでの開発経験が長いので、遠方からのお仕事待ってます。要件定義から設計までとか、マネジメントだけとかでも大丈夫です。
履歴書を載せておきます。
スシが食べたい。
コメント