在宅勤務を可能にするために必要な条件を考えてみる。

ここ数日、在宅勤務について何人かの人と話す機会があったのですが、大体「人によっては可能だけれど、一般的には…」とか、「個人的には賛成ですが…」のようになんとなくもにょもにょした結論に至ることが多かったです。

私自身は個人的には可能だと思っているし、実際に何度か自宅で勤務して特に問題なく過ごせたと感じています。たとえばこれを展開したとしても、いまのチームなら可能だと考えています。ただ、なぜ可能なのかをきちんと説明したことがなかったので、改めて考えてみたいと思います。

WFH

前提条件

私がここで想定する「在宅勤務」とは、すべての勤務を在宅で行うのではなく「必要に応じて出社し、必要がない場合には在宅勤務を可能とする」ケースです。全日在宅勤務も可能だと思うのですが、Planning meeting / Backlog grooming等に関しては、出社して顔を合わせた方が効率が良いと考えるからですが、このあたりは後述します。

在宅勤務をするために必要なこと

自宅で開発をする環境が整っていること

これは基本的なことですが、自宅で作業を行うにあたって様々な設定や困難が伴うケースでは難しいです。幸い、今のチームでは必要に応じてVPNクライアントの設定されたモバイルPCを配布してもらっています。また、私の場合、Androidアプリの開発をメインに行っていましたが、リソース(ソースコード)は Git上 に、ドキュメント類もIntraのWeb上にあるので、あとは自宅にPCに Android Studio 1.0+ をインストールし、 “gradlew build” のコマンド一つで開発を開始することができました。
Gitの導入が大きかったなあというのが実感です。会社で開発した内容をリモートブランチに commit しておけば、そのまま自宅でも開発を再開できるし、その反対もまた然り、という感じでした。

レビューに関してはPull requestを送り、Githubと同じような感じで、レビュー後問題なければQAブランチにmerge、そのタイミングでJenkins上ですべてのテストが実行され、成功すれば、Hockey Appにバイナリがアップロードされるので、そのバイナリでQAエンジニアがQAを行う、というフローなので、オフィスにいる必要はほとんどありません。

タスクが明確になっていること。その妥当性について理解を得られること

恐らく、在宅勤務を認めがたいと感じている(特に管理者側)の意識としては、在宅の場合、下記の2つが大きなポイントではないかと感じます。

  1. 自宅にいるとき何をしているのかわからない
  2. 成果が出せているのかがわからない

これを解決するのがいわゆる「見える化」ですが、これは Scrum というか Planning meeting / Backlog grooming と JIRA のタスクボードです。

基本的に JIRA にすべてのタスクをチケット化し、ステータスをまめに変更することで1の問題は解決できます。
また Scrumーーーというといろいろツッコミがあるので、スクラム風なやりかたをとりいれている私たちのチームでは、Backlog grooming でバックログにあるチケットの洗い出し、仕様の確認からStory point の設定までを行います。その後、Planning meeting において、PDMの優先順位付けを元に、Sprint days x 7.5h(もしくは5h)から会議、有休消化などの作業不可能時間をマイナスした時間を作業可能時間として、その時間で作業可能なタスクを割り当てます。

理論上は、見積もりが正確ならば、すべてのタスクがSprint終了までに完遂されれば、作業可能な時間をすべて仕事についやしていたと言えます。逆に言えば、タスクが終わらなかった場合、さぼっていたか、見積もったタスクの時間が足りなかったかのどちらかとなります。

ではどうやって見積もりを正確にするか。以前研修で言われた印象的な言葉が、タスクの見積もりをするときに”Do not overestimate” です。特に日本人は、終わらないことを気にするあまり、バッファを多く取りがちですがそうすると余った時間が無駄になってしまいます。Over-estimate / Under-estimate どちらも望ましくありません。

これを解決するのが Planning / backlog における Planning poker と振り返りにおける Velocity の確認です。各自が勝手に見積もりした場合、疑わしいと感じられますが、可能であれば管理者も交えて、すべてのエンジニアが合議、納得の上でStory pointを確定し、そのタスクをこなしていくことで、見積もりの精度は上がっていきます。
Velocityを確認すれば、たとえば毎Sprint タスクが完遂されていて、かつVelocityに変化がなければSprintのStory pointをもう少し増やすことを検討できるし、逆にタスクが完遂されていなければ見積もり時間が少なすぎるということが見えてきます。いずれにせよ、繰り返していくことと合議することで、2の問題もクリアできます。

最初に、すべての期間を在宅で過ごすのではなく、Planning / Backlog は出社すべきだと考えるのは、この合議をより正確にするためと、なんだかんだで顔を合わせて話すことはチームの強さに影響するのではないかなと感じているからです。状況によっては Skypeのビデオチャット経由でも問題ないとは思いますが、可能ならばその場でアレコレやりとりした方が効率がよいかなと思います。

まとめ

もちろん私はすべてのエンジニアが在宅勤務をすべきだと思っているわけではありません。たとえば設計フェーズにエンジニアが深く関わるケースでは、PDMや他チームとの折衝など、オフィスにいる方が望ましいケースもあります。また、エンジニアのスキルが足りない場合や、傑出したメンバーがいる場合はその人のそばにいることで得られるものは計り知れません。実際私自身も、チームのエンジニアからたくさんのことを学ぶことができました。

ただ、必要に応じて自宅からの勤務も無理なく行えるのであれば、行っても良い、という選択肢があれば、ワーキングマザーや要介護者を抱える人の支援のためだけでなく、普通のエンジニアにとっても時間の使い方や効率の面からもプラスが多いのではないかと感じています。評価の枠組みや個人の適性など、実際のところは人それぞれ、現場にもよるのだと思いますが。

ともあれ、オフィスでワイワイ仕事をした方が生産性が上がる人もいれば、静かな環境の方が圧倒的に仕事がはかどる、という人もいるでしょう(実際、うちのチームはそういう人が多かったので、オフィスにいてもDaily huddle以外誰とも話さない日があったりしました/笑)。その人にあった働き方がもう少し気軽に認められるようになれば、それぞれもっと働きやすくなるのではないかなと思います。