UNIX的なアレ

UNIX的なこととかいろいろ

リモートでの働き方を考える

リモートワークの可否に関しては様々な意見がありすでに国内でも導入している企業は増えてきています。実際に働き方改革の取り組みとしても実際に上げられています。

テレワーク推進に向けた政府の取組について

とはいえ、実際にリモートワークで成果を出すのは今まで通りの時間管理を前提としている業務の考え方では難しく、挙げ句の果てにはこういった管理方法すら出てきてしまうのが現状です。

japan.cnet.com

時間管理をしたほうが効率のあがる業務なのであればこのマネジメントの考え方は1つの手法としてあるのかもしれませんが、正直なところ非常にナンセンスな管理方法だと思います。

高度プロフェッショナル制

そして実際に導入が検討をされている高度プロフェッショナル制ですが、これは成果に対する評価が賃金であるということが前提となっています。しかし時間管理が染み付いているワークスタイルだとやはりどうしてもコンフリクトしてしまいます。

そのためこの制度を悪用することが懸念された結果、残業代ゼロ法案と揶揄されていたりもします。実際に業務に対する正しい評価がされない環境であればそうなる可能性はあるため、法的な制度以上に企業側の人材評価に対する見直しも必要となってきます。

その上で業務内容を改めて整理し、現代の仕事内容に合わせたワークスタイルを定義しなおす必要があります。

business.nikkeibp.co.jp

リモートの向き・不向き

業務内容は大きく以下の3つに分類できます。

  1. プロジェクト型
  2. 依頼対応型
  3. ルーチン型

この3つの業務種別の配分次第でリモートの向き・不向きがあります。

特にこの中でリモートに向いているのはプロジェクト型で、ある程度まとまった期間でのアウトプットに対して評価をするというスタイルです。そう考えると業務設計に幅ができ、実際に多様性のある働き方ができます。

業務設計

リモートワークはどうしても一つの特別な働き方として捉えられがちで、リモートでの働き方に最適化したツールの導入などの話に寄りがちです。そのため業務設計を見直すことなく、現在の仕事を新しく導入したツールや手法論などで解決しようとするわけですが、多くの場合それでは解決しません。また、現在行われている一般的な手法(時間管理など)はリモートワークの思想と相反するので、そういった考え方は一旦取り除く必要があります。

リモートワークだとメンバーが管理できないということは、仮に出社をしていたとしても正しい評価をくだせていないということが上げられます。そのため、リモートで働いている人であろうが社内で働いている人であろうが、顔を合わせていることによるバイアスを除き、正しく業務に対する評価をできていることが大事です。

自チームでのリモートワークのやり方

それぞれのメンバー同士で以下のそれぞれの項目を求めることが大事だと思っています。

  • Expectation(期待)
  • Consensus(コンセンサス)
  • Share&Review(共有・レビュー)

この3つを行うことを前提に定められた期間でのタスクを設計します。これはただツールを導入するだけでこの項目は達成できません。また時間をかけてチーム内にカルチャーを作っていく必要があるため、片手間で実施することは難しいです。そのためこの項目を遂行するための担当者がいたほうがスムーズに実施できます。

Expectation(期待)

これは、同じチームに属している人同士がお互いに期待をしてもいい仕事内容ということになります。それは、技術的な得意分野だったり、いままで作ってきたシステムの担当分野だったりそういったものを含みます。お互いに期待をしてもいい内容というのがわかっている時点で、タスクの振り分けが明確になりお互いの進捗についても納得感が生まれます。

Consensus(コンセンサス)

決められた期間でこなすべきタスクの量や内容がお互いにコンセンサスがとれている状態を指します。これはただ与えられた業務で実施することは難しいため、改めてチーム内で仕事を分解し個々にアサインをする必要があります。また個々のタスクに関して、お互いにどういったタスクを持っているかが見えていることが重要な点として上げられます。

また、コンセンサスは期待をベースにその都度作り上げる必要があります。誰もが仕事だけをして生きているわけではありませんし、休暇もとるし家庭の事情もあります。そのため事前の期待を踏まえた上で、この期間ではここまでのアウトプットが限界というコンセンサスをとっておくことが大事です。

Share&Review(共有・レビュー)

個々の仕事について共有をしレビューします。タスクそれぞれの精度に関してはコードレビューなどを通じてされていることが前提となっているためここでは含みません。予め実施する予定の期間に定められたタスクの量が適切だったか、タスクの粒感は適切だったかなどのレビューを行います。

実績への評価

定期的にお互いの業務をレビューし合うため、そのレビュー内容が個々の評価になるようになっているのがベストです。査定などは半年〜1年くらいで行われることが多いと思いますが、この定期的なレビューがログに残っていることで半期単位での評価でもその内容が使うことができます。

評価にはOKRが使われることが多いと思いますが、Key Resultの効果測定になるくらいしっかりとしたレビューの結果が残っていることがベストです。

スクラムとリモートワーク

上記の業務設計とスクラムでの仕事の進め方の相性が非常に良いので、結果的に自チームではスクラムと組み合わせて実施をしています。コンセンサスをとるためのスプリント計画だったり、レビューのための振り返りなどスクラムでやるべき会議体と非常に似ています。

また、大事なことは1度業務を設計したからといってそれ以降は勝手にチームが回っていくなんてことはありえません。常に問題点があればそれをお互いでシェアし改善に取り組んでいく必要があります。そのため、振り返りの会議の際はプロダクトだけでなくチーム運営の問題点などについてもシェアをするようにします。

このあたりのスクラムの運営方法に関してはこちらの取材でお話させていただきました。

gihyo.jp

会議体や報告フローなど

これは、リモートでもオフィスにいても同じようなフローで行われる方が望ましいです。どちらかのステータスが特殊なものとして扱われてしまうことで情報の偏りが生じてしまいますし、その時点でワークしづらくなります。

そのため自分がみているチームでは朝会などは会社にいてもいなくてもすべてHangout上で行うようにしています。そうやって実施することで、Hangoutでコミュニケーションをとることが特殊じゃなくなり顔を合わせても合わせなくても同じコミュニケーションをとれるようになっていきます。

使用しているツール

リモートワークを推進するためのツールはいろいろとありますが、最終的には使い方次第です。またリモートのときにしか使わないツールだと普段から使っていないためつかっていてしっくり来ないということも実際にありました。結果的に自チームで使っているツールは以下の3つです。

おそらくこの3点セットは同じ業界の人はほぼ同じセットで導入されているはずで大きな差はないと思います。特殊なツールを導入せずとも、基本的なツールだけで十分に回せます。またそれぞれのツールがスマホからまともに使えるため、出先で使いたいときも問題なく使うことができます。Sneekなども導入したことありましたが、正直いまいちワークしませんでした。

最後に

リモートでの働き方に憧れる人・導入してみたいチームなどはたくさんいると思います。しかしながら、リモートで働くということはそれ相応の結果に対する責任が伴います。

また働き方の多様化における銀の弾丸ではありません。当然、それなりの業務設計をやり直す必要はありますし、業務における向き・不向きもあります。一方で、リモートというワークスタイルが増えることで多様性を生むことができるのも事実なので、一つの選択肢として考えてみるのも良いと思います。