リモートワークはとても難しいという話をしてきました

"Agile Japan 2017 京都サテライト", "KANJAVA PARTY 2017" で、『リモートチームの道具箱』というタイトルのセッションでお話をさせていただきました。

connpass.com

kanjava.connpass.com

リモートワークに取り組んでいるチームで仕事をして3年目になりますが、リモートワークは難しいなーというのを常々思っています。

世の中はどちらかというと、リモートワークという素晴らしい取り組みをどんどん推進しようという流れに向いています。リモートワークの推進には僕も賛同するのですが、一方で、「難しさ」の部分があまりクローズアップされません。このまま、導入だけが先行してしまうと、結局「やっぱりリモートワークなんて止めたほうがいいのでは」となってしまう恐れがあって、それを懸念しています。

リモートワークは上手に使いこなせば、柔軟な働き方が促進される良い取り組みだと思います。だからこそ、「難しさ」の部分と向き合って、うまく付き合っていこう、というのを今回のセッションではお話しました。

人類はピラミッド建築の時代から、対面でチームワークをする取り組みは長年に渡って経験しており、それなりに知見も対処法も知っています。リモートワークは、たかだが数十年くらいの歴史で、知見も技術もまだ未熟です。だからこそ、その未熟さと向き合いながら取り組んでいく必要があるのです。

スライドはこちらに公開しました。

ありがたいことに、セッションハッシュタグがトレンド入りしていたので、そちらもまとめました。

togetter.com

セッション中にご紹介した書籍です。

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

異文化理解力――相手と自分の真意がわかる ビジネスパーソン必須の教養

あなたとわたしの感じ方は違う - リモートワークと異文化理解力

リモートワークは難しい。 在宅を基本とするリモートワークは働き方の多様性という意味で非常に有効だ。

すべての勤務が在宅でなくても、家族の介護や、自身の都合などで任意の日に在宅で仕事ができるだけでも、大きなメリットがある。

働きたいと思っている人が、オフィスに縛られること無く、家庭や個人の事情と両立しながら働くことができるし、チームとしてもメンバーが働けなくなることで生じるリスクを少なからず軽減することができる。

とはいえ、リモートワークは難しいのである。 リモートワークに取り組んでいたいくつかの企業が、その取り組みを断念した、というニュースもちらほら耳にするようになった。

なにがそんなに難しいのか。その要因の大きな部分に、コミュニケーションの難しさがあると思われる。 リモートワークだと、チャットやメールなどのテキストでのコミュニケーションが主流となる。ここに大きな難しさがある。

「毛づくろいの会話」

我々人間は、主に会話によってコミュニケーションをとる。 会話は、単なる言葉のやり取りだけにとどまらず、声の抑揚やお互いの仕草、表情など、非常に多くの情報を伴い、やりとりがなされる。

つまり、対面の会話 > 電話 > 文字 の順に、やりとりされる情報量が減っていくということである。 例えば、わたしが同僚にある依頼をした際に、「わかりました。やっておきます」という回答がなされたとする。言葉の意味としては、相手はわたしの依頼を承諾してくれたようである。 この時、同僚はどのような表情をしているか。笑顔なら、快く引き受けてくれたのであろうし、渋い顔をしていたら、不本意ながら引き受けたということになるだろう。あるいは、声の抑揚によってそういった機微を読み取ることができるかもしれない。文字だけでは伝わらない情報が、こうしてやりとりされているのである。

言葉の受け取り方ひとつとっても、わたしたちには個性がある。まったく同じコミュニケーションのやりとりについて、それをどうとも思わない人もいれば、不快だと思う人もいる。 Aさんに物事をお願いするときと、Bさんにお願いするときとで、わたしたちは無意識に依頼についての言い回しを使い分けているようなところがあるはずである。

わたしたちは、こういった「コミュニケーションの機微」のようなものを探り合いながら、信頼を深め、距離を縮めていく。 「昨日アイドルのライブに行ってこう思った」とか「このような映画がおもしろかった」といったなにげない会話を繰り返しながら、そのときどきの表情や声の抑揚といった感情的なシグナルを受け取りつつ、わたしたちは相手に対する理解を深めるのである。これは、猿の毛づくろいに似ており、「毛づくろいの会話」と呼ばれたりするものだ。

異文化に見る、コミュニケーション特性への理解

さきほど「コミュニケーションの機微」という表現を用いた。これをもう少し具体的に考えてみよう。

『異文化理解力』という本がある。これは、それぞれの国の文化的な特性が、コミュニケーションに影響を与え、阻害する要因となる。それをお互い理解して、円滑なコミュニケーションを取るために、どういった軸で相手を理解すればよいかを示した本である。

例えば、わたしたち日本人からすれば、欧米人は物事をはっきり主張する。相手からみれば、日本人は何を考えているかよくわからぬ、といった文化的特性によるすれ違いを説明している。これはあくまでも相対的な尺度である。日本人からみたら欧米人ははっきり物事を言うが、欧米の中でも相対感はあって、アメリカ人はネガティブ・フィードバックは比較的オブラートに包むが、フランス人はネガティブ・フィードバックでも率直である、というような見方をする。

この本では、文化的な特性によって差異が出る軸はビジネスおいて以下の8項目であるとされている。

  • コミュニケーション
    • ローコンテクストvsハイコンテクスト
  • 評価
    • 直接的なネガティブ・フィードバックvs間接的なネガティブ・フィードバック
  • 説得
    • 原理優先vs応用優先
  • リード
    • 平等主義vs階層主義
  • 決断
  • 信頼
    • タスクベースvs関係ベース
  • 見解の相違
    • 対立型vs対立回避型  
  • スケジューリング
    • 直線的な時間vs柔軟な時間

具体的な各項目の言及については書籍を読んでいただくとして、これらの軸による文化的な捉え方の差異が「コミュニケーションの機微」にあたるのではないかと思う。

これらの特性の違いは、欧米やアジアといった文明圏の差異ほどではないせよ、個人の性格によっても異なる。 成果物のレビューに対して、率直な意見を好む人もいれば、遠回しな意見を好む人もいる。こういった個人間の特性の違いは、文明圏同士の差異ほど明らかではないため、なんとなく「テキストコミュニケーションは難しい」といった感覚のようなもので単純に捉えられてしまうのだろうと思う。

本来、オフィスで顔を合わせて仕事をしていれば、こういった差異は「毛づくろいの会話」によって比較的容易に埋まる。ただ、リモートワークのコミュニケーションでは、前述の通りテキストが主軸となるために情報量が不足し、この差異が埋まりづらいのである。

「毛づくろいの会話」の機会を増やせればよいが、それが難しいのであれば、まずは上記8項目におけるメンバー間の個性をマッピングし、相互理解の手助けとしてみてはどうか。

とにかく、まずはコミュニケーションを深めるための相互理解の手がかりを得ることが、リモートワーク成功の秘訣であろうと思っている。

気になる人はぜひ一度この書籍を一読して、コミュニケーションにおける他者の理解の物差しを増やしていただければと思う。

カンバン術の「えきすぱあと」ヴァル研究所さん見学記

ぼくが所属しているMackerel開発チームはスクラムで開発を行っている。最近チームの人数も増え、開発のエンジニアだけでなく、セールスメンバーも増員され、そういった職種の仕事のやり方も改善していきたい、という機運が高まっていた。

そこで、開発チームだけでなく、総務や営業など会社の全部門でカンバンを採用しているという噂のヴァル研究所さんにオフィス見学に行くことに。ヴァル研究所さんとは勉強会コミュニティで双方複数のメンバー間で交流があり、約2時間半の見学会を開催していただくことになった(相談すれば気軽に受け入れてくれるので皆さんもぜひ)。

オフィスに到着すると、まずはPepperくんが出迎えてくれる。

f:id:daiksy:20170307165306j:plain

ヴァル研さんといえば「駅すぱあと」最初に案内された部屋には、壁一面に時刻表が埋め尽くされていた。

f:id:daiksy:20170307171403j:plain

オフィスに入ってまず驚くのは、目に入るあらゆるところに、カンバンやKPTボードなどが配置されており、仕事のあらゆる物事が見える化されていることだ。ニコニコカレンダーでチームメンバーのメンタルが可視化されていたり、ワークフローやそのリードタイムがひと目でわかるようになっていたり。

圧巻のその様子はぼくの拙い文章よりも、こちらのスライドを見ていただくのが良いと思う。

どの部署も、徹底的に改善と工夫が繰り返されており、個性的である。これを自分たちの仕事に取り入れようと思っても、いきなりすべてを真似するのは無理なので、まずは何から始めればよいのか迷ってしまう。 (実際にどこから始めたら良いかは前述のスライドに書いてあります)

立ち寄る部署それぞれで質問をたくさんしていたら、予定時間をオーバーしてしまったのだが、どの職種の方とても丁寧に質問に答えてくださった。

ヴァル研さんは以前、はてなの京都オフィスでの勉強会に来てくださったことがあって、そのときに登壇してくださった方と再会できたのが個人的にとても嬉しかった。

daiksy.hatenablog.jp

この記事のDSLの「その後」を軽い立ち話ではあったが聞かせてもらったりした。

印象的だったのは、社員の皆さんがとても前向きで、職場を楽しくしようという工夫が随所に見られたことである。 『ジョイ・インク』で書かれているような「全社員が仕事に喜びを感じられる環境を作る」ということがまさに体現されていて、やっぱり仕事はできるだけ楽しく、前向きにやれるような環境を作りたいな、と思わされた。

ジョイ・インク 役職も部署もない全員主役のマネジメント

ジョイ・インク 役職も部署もない全員主役のマネジメント

見学会を終えた翌日、さっそくMackerelのセールスチームがカンバンを改造している。半年後に我々のカイゼンの結果をぜひ今度はヴァル研の皆さんに見に来ていただきたい。

ScalaMatsuriでA会場の司会をやっていました

f:id:daiksy:20170225110609j:plain

今年のScalaMatsuriにスタッフとしてお手伝いさせてもらい、当日のA会場の司会ローテーションを担当しました。

f:id:daiksy:20170226090808j:plain

去年からに引き続いてのスタッフ参加だったのですが、今年は仕事が忙しかったなどもあって準備段階ではあまりお手伝いできませんでした。関西からの参加ですが、去年はリモートである程度準備もお手伝いできたので、来年はもう少しなにか貢献したいなと思っています。

今年は、去年以上に国際カンファレンスとしてのクオリティもあがり、すばらしいカンファレンスになったと思います。

去年はリアクティブや関数プログラミングなど、「現在のScala」をどう応用していくか、という話題が中心でしたが、今年はDottyscala.metaなど、「未来のScala」についてたくさん話しが聞けて、個人的にはとても興奮しました。

EPFLのFelixさんのDottyのトークで、偶然かっこいい写真が撮れたところご本人にfavもらえてうれしかったです。(小並感

SlackでKPT用botを仕込んでみた - リモートチームのKPTテクニック -

ぼくたちの開発チームは、現在1スプリント2週間のスクラムチームとして活動している。スプリントの最後には振り返りを実施しているが、そこではおなじみのKPTを採用している。

参考: 情報マネジメント用語辞典:KPT(けいぴーてぃー) - ITmedia エンタープライズ

チームは複数拠点にメンバーが分散しているリモートチームで、振り返り会はテレビ会議を使って行われるので、KPTのやり方にもそれなりの工夫が必要となる。

Googleスプレッドシートを使ったKPT

通常のKPTでは、大きな模造紙やホワイトボードに、Keep、Problem、Tryの領域を定め、そこにそれぞれの内容について書かれた付箋紙を貼っていく。他の人が書いた付箋の内容が呼び水となって、他の人が別の課題を思いついたりもするので、全員が揃って付箋を次々に貼っていく、というスタイルが良いとされている。

メンバーが複数拠点にまたがっているリモートチームだと、少し事情が異なる。まず、模造紙と付箋紙、という物理的なメディアでの運用が難しい。拠点それぞれでKPT用ボードを使うと、それをどうやってマージしようか、という問題がある。

そこで、Googleスプレッドシートを使ってKPTボードを運用することにした。

daiksy.hatenablog.jp

以前こちらのエントリでも書いたが、Googleスプレッドシートを使ったリモート振り返りはうまく機能する。ログインしている他のユーザの編集状況がリアルタイムに反映されるので、ひとつのKPTボードにメンバーが次々と付箋紙を貼っていく様子をオンライン上で再現できるのである。

スプリント中のKPTをどう拾い上げるか

スプリント最後の振り返り会は、最初の15分で皆に一斉にスプレッドシートKPTを記入してもらうところからはじまる。しばらくこのやり方を続けていたが、次第に、スプリント中にKPTに書こうと思いついたことがあっても、振り返り会当日になると忘れてしまう、という課題がもちあがった。

全員が同一拠点で仕事をしているチームなら、解決方法は造作もない。開発チームが仕事をしている部屋の壁に模造紙を貼り、スプリント中に思いついたらここにどんどん付箋を貼れるようにすればよいだけだ。ところが、リモートチームだと少し事情は異なる。

KPT用のスプレッドシートを事前に作っておき、スプリント中そこに思いつき次第書き込めば良いではないか、と思われるだろうが、実際にやってみるとこれは難しい。

課題を思いついて、ブラウザを開き、スプレッドシートのURLを打ち込むか、ブックマークから探し出すかしてスプレッドシートにアクセスし、そこに内容を書く。壁の模造紙に付箋を書くことに比べると、実に面倒な手順だ。KPTを思いついても、スプレッドシートにアクセスするの面倒だし、後にするか、と思っているうちにやはり忘れてしまう。

もっと気軽にKPTを書き込める仕組みが必要なのだ。

SlackにKPTbotを仕込んだ

どのツールを使えば最も気軽にKPTを書けるか。いろいろ考えた末、Slackを使うことにした。リモートチームとして、我々は日常的にSlackを使ってコミュニケーションしている。Slackであれば、仕事中に常にアプリが立ち上がっているので、気軽に書きやすいだろう。

仕組みは実に単純。SlackのOutgoing Webhooksで、Google App Scriptに投稿内容を飛ばす。Slack上では、予め “K:"、"P:"、"T:” などのプレフィックスをルールとして決めておいて、そのプレフィックスに応じて、投稿内容をスプレッドシートのそれぞれの列に転記するのである。

転記が成功したら、Google App Scriptが成功した旨をSlackに返信する。

f:id:daiksy:20170218122519p:plain

こちらが、その様子。

KPT投稿には、Slackに専用チャンネルを用意して、他の議論と混ざらないようにしている。 定時が近づくと、普段コミュニケーションに使っているチャンネルに、リマインダーが現れ、KPTチャンネルに誘導したりもしている。

f:id:daiksy:20170218122658p:plain

まだ運用をはじめて日は浅いが、今のところ活発に日々投稿されているので、試みとしてはうまくいっているように思う。

2016年の振り返り

2016年もあとわずか。今年の振り返りを簡単に。

仕事

8月からMackerel開発チームのサブディレクターになった。 また、今年ははてなインターン実行委員長をやった。

hatenacorp.jp

今年は普段勉強会やアウトプットに使っているリソースのほとんどを、仕事やインターン準備にあてていたな、という感覚があった。 来年はこのあたりのバランスをもう少し変えていけるといいなと思っている。

勉強会 & カンファレンス

主催・スタッフ・登壇としてかかわったのは以下のもの。Scala関連がほとんどである。Scala関西Summit と ScalaMatsuriという大きなイベントにかかわれた。来年のScalaMatsuriのスタッフにいちおう名前が入っているが、今回はあまり手伝えていないのでこれから当日に向けてやっていきたい。

あと、福岡はまた絶対に行きたい。

Scala Matsuri 2016

2016.scalamatsuri.org

第3回 関西IT系インフラ勉強会

kansai-itinfra.connpass.com

DevLOVE関西 リモートワークの現場の知恵

devlove-kansai.doorkeeper.jp

Scala福岡

scala.connpass.com

speakerdeck.com

第3回 Scala関西勉強会

connpass.com

Scala関西 Summit

summit.scala-kansai.org

はてな×BizReach合同Scala勉強会

takezoe.hatenablog.com

DevLOVE関西 ビブリオバトルであの人のおすすめの本を知ろう

devlove-kansai.doorkeeper.jp

合同勉強会 大都会岡山 2016 Winter

gbdaitokai.connpass.com

speakerdeck.com

おもしろイベント

シン・ゴジラ飲み会

daiksy.hatenablog.jp

シン・ゴジラを10回観た、とか行ってたらギルドワークスの市谷さんと意気投合して、ゴジラ飲み会しようぜ、ということになった。 そうしたら、日経BPの記者さんから取材させてほしいと申し出があり、その記者さんを交えて和知でゴジラについて語りまくった。

我々の飲み会の様子がなんらかの記事になることはなかったが、その記者さんがてがけていた本が出ている。

とにかくゴジラに関するあらゆる場所に取材に行かれていたようだ。人生何が起きるかわからないものだなーと思った不思議な出来事だった。

その他アウトプット

はてなスタッフアドベントカレンダー

daiksy.hatenablog.jp

はてなディレクターアドベントカレンダー

daiksy.hatenablog.jp

Web+DB Press vol.96 Scala関西Summitイベントレポート

WEB+DB PRESS Vol.96

WEB+DB PRESS Vol.96

ライブ & フェス

4月5日 tricot CLUB QUATTRO


tricot『節約家』MV

6月15日 ストレイテナー BIGCAT


ストレイテナー「シーグラス」ミュージックビデオ(Dir:大久保拓朗)

7月2~3日 京都大作戦

www.sound-c.co.jp

8月27~28日 Rushball

RUSH BALL 2016 -2016.8.27-28@泉大津フェニックス-

9月29日 the HIATUS Zepp Namba


the HIATUS - Bonfire(Music Video)

10月10日 the HIATUS Billborad Live Osaka


the HIATUS - Clone(Music Video)

11月26日 toe BIGCAT


TOE LIVE AT THE REGENT: Goodbye

12月20日 MONOEYES なんばHatch


MONOEYES - Get Up(Music Video)

12月28日 RADIO CRAZY

radiocrazy.fm

来年はライジング行くぞ!!!!!

嫌われない勇気

※ベストセラーになった書籍『嫌われる勇気』からタイトルをもじっただけで、その書籍とこのエントリの内容に関連はありません

このエントリは、はてなディレクターアドベントカレンダー16日目の記事です。

advent.hatenablog.com

サブディレクターという仕事

ぼくはMackerel というプロダクトの開発チームに所属しています。これまで、2年弱アプリケーションエンジニアとして仕事をしてきましたが、今年からチームのサブディレクターに就任しました。

サブディレクターということで、厳密にはディレクターではありません。チームのメインディレクションは、ディレクターのid:Songmuに権限があります。

Mackerelチームは、はてなの中でもかなりの大所帯で、エンジニア、デザイナ、セールス、マーケティングと多用な職種の人が在籍しています。ロケーションも東京と京都、愛知(自宅からのリモート勤務)と多岐に渡っているため、ディレクター1人ですべてを差配するのは難しくなってきました。そこでぼくが、サブディレクターとしてディレクターを補佐しながら、主に自分自身も勤務する京都側のメンバーの取りまとめなどをやっています。

Mackerelの開発には乱暴に分けると2つの軸があります。チーム主導で行う継続的な開発と、他社さんとの共同開発です。前者は、我々開発チームがプロダクトの現状や市場の状況・ニーズなどから優先度を決め、自発的に開発を行っていきます。後者は、例えば先日リリースしたTwilio連携などのように、他社のサービスとのコラボレーション機能の開発で、これは連携先の企業と共同して進めることになります。

タイミングによっては、このような他社との共同開発が並行で複数動くこともあり、こういった場合ディレクターのid:Songmuと、サブディレクターのぼくとで分担して開発の舵取りをしたりします。

また、Mackerelチームでは開発手法として、スクラムを採用していますが、専任のスクラムマスターがいません。かわりに、スプリント計画に対する決定権や責任はid:Songmuが持ち、振り返りや日常のスクラム的な行事の推進はぼくが勤める、というようにスクラムマスターの役割を分担していたりもします。

そういうわけで、サブディレクターという何をやってるのか字面だけではわかりにくい職ではありますが、ぼくの仕事は、

といったところになります。あとはプロダクト開発にも直接かかわっていて、一部の機能開発でコードを書くこともしています。

仕事相手に嫌われてはいけない

こういった仕事を進めるにあたって、最近重視していることがあります。それは「嫌われない」ことを意識する、というもの。

若い頃、当時勤めていた会社の上司から、「お前はもっと人に嫌われることを怖がらないようにしないといけない」ということをよく言われました。仕事は仲良しこよしのグループではないので、馴れ合う場ではない。自分の主張すべきことはきっちり主張せねばならず、「こんなことを発言したら嫌われるのではないか」「もっと他人に対していい顔をしたい」というようなことは仕事を阻害する要因となる、といったニュアンスでしょうか。異論の余地なく正しい指導だと思います。

ただ、ぼくはこの「嫌われる」という表現にずっと違和感を持っていました。もちろん仕事で他者との衝突を必要以上に恐れてはいけないし、異なる意見をぶつけあうことで新しい発想にたどり着くことがある、というのは理解できるのですが、「嫌われて」しまってはいけないのではないか。

チームビルディングを語るうえで、最近「心理的安全」という言葉をよく目にするようになりました。

これについて詳しく書かれている『チームが機能するとはどういうことか』という書籍から定義を引用します。

心理的安全」とは関連のある考えや感情について人々が気兼ねなく発言できる雰囲気をさす。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

これは「心理的安全」が存在しないチームを想像するとわかりやすいです。メンバーのミスを強く叱責するようなことが続くと、そのメンバーが叱責を恐れてミスを報告しなくなってしまう。メンバーが、「このような質問をしたらチームメイトから自分が未熟で能力が低いと思われるのではないか」と心配して質問ができなくなる。これらは、「心理的安全」がチームに存在しないために起きる問題です。

心理的安全」が保証されているチームでは、自分が発言することによって、叱られたり、不利になったりすることを心配する必要がありません。ミスの要因や、業務に対する理解不足の表明は、チームの仕事を前進するための重要なインプットとして扱われます。

ぼくがかつて上司に言われた「嫌われる」という言葉の違和感は、まさにこれについての懸念です。

他人から嫌われてしまうと、周りは自分に対して率直に接してくれません。相談もされず、自分のあずかり知らぬところで物事が進んでいる、というようなよくない状況に陥ります。メンバーや、協業先企業の担当者の人たちが、常に安心して自分に報告や相談をもちかけてくれる状況が前提としてあってはじめて、自分の主張や意見をぶつけ合うことができるのだと思います。

普通に仕事をしていて、他人に対して悪意をもって接している人などいません。お互いの主張や利益に対して、前向きに一生懸命取り組んだ結果としてのすれ違いがあるだけです。そのすれ違いを解消するために、嫌われる覚悟をもって物事を進めたり、主張を退けたりするメリットなどどこにもないと思うのです。

ぼくがサブディレクターとして仕事を進めるにあたって、最近気をつけているのが、こうした心理的に安全な雰囲気作りです。

心理的安全は自分への不利益を心配する、という状況だけに限りません。新しくお付き合いがはじまった相手先企業の担当者さんと、まだお互いの人となりがわからずに気軽に接することができない、という場合も同様です。そういった場合は、可能な限りチャットツールなどを使ったり、ときには雑談を交えつつコミュニケーションをすることで、仕様についての相談や不具合の報告などをできるだけ気軽に伝え合える雰囲気づくりを作るよう心がけています。

今のところその心がけが、仕事を前進させるために有効に作用している実感を持っています。

長々とおつきあいありがとうございました。明日はCTOのid:motemenです!