直線距離約1,000km、東京と福岡を結ぶリモートスクラムの話

まえがき

こんにちは、ヤフーSREエンジニアの高岡です。

今日で「Yahoo! JAPAN Tech Advent Calendar 2018」14日目、いよいよクリスマスも目前に見えてきましたね。今日はスクラム開発についてちょっとお話させていただければと思います。

普段私は福岡の天神にあるオフィスでプラットフォーム開発の仕事をしています。担当しているプラットフォームは、普段みなさんの目に触れることはありませんが、社内外の様々な方に利用されています。

そのため、ユースケースを想定し実際のユーザーさんにヒアリングする仮説検証も非常に大事になってきます。さらに、私たちのチームは開発手法としてスクラムを取り入れています。スクラムでは生産性を高めるために、チーム内でのコミュニケーションを非常に重視しています。ですので、プロダクトオーナー(以下、PO)は東京でユーザーの課題集めに奔走し、スクラムチームはユーザーが多い東京に集まって仕事をしているはずです。

しかし不思議なことに、開発チームの一員である私は天神オフィスからこの記事をお届けしております。

そう、私たちのチームはPOが東京・開発チームとスクラムマスター(以下、SM)が天神という、直線距離約1,000kmにおよぶ距離を跨いで、毎日お仕事をしています。さらに、開発チームのそれぞれもリモートワークの制度を活用して勤務しているため、自宅・天神オフィス・東京オフィスの3点間での仕事が時に発生しています。

前置きが長くなりましたが、こういったリモートスクラムの導入と工夫を事例ベースで紹介していきますので、みなさんのスクラム開発の生産性向上の一助となれば幸いです。

リモートスクラムにおける課題と対応

導入初期：Slackと作業ログによる非同期コミュニケーション

はじめにやったこと

天神チームが始動した当初は、誰もリモートスクラムはおろかスクラム開発の経験すら乏しい状態でした。さらに、POが不在かつ不定期に開発チームの誰かが自宅からリモートワークを実施する状況です。

そんな中まずは現場にあるものだけを使って、どうにか工夫して始めたのが下記のような取り組みです。

- フリースペースの共有モニタを利用してモブプロを実施
- 実施した内容は再現性を持たせるために、社内Wikiに実行コマンドごと記載
- 問題が発生したらSlackでPOに相談

まずは、スキルセットの全く異なる開発メンバーが仕事を進める上で、短中期的に見て手戻りが少なくなる方法であるモブプログラミングを導入しました。そして、実施した内容を他の開発メンバーが再現できるように、作業の流れとその時の議論内容および実装した概要がわかるように、それを社内wikiに記録するようにしました。

これによって、開発者それぞれの視点がチームに還元されるようになり、例えば当初は各開発者が様々な書き方をしていたShellScriptも、誰もが一定以上の品質を担保して素早く書けるようになり、開発手戻りも低下していきました。

発生した課題

しかし、スクラム的な働き方は改善されていくにもかかわらず、リモートワークの課題は中々解消が進みませんでした。

- POとのコミュニケーションのオーバーヘッドが増大
- リモートワーカとのコミュニケーションが取れない

基本的にPOとのコミュニケーションは、Slackベースの非同期コミュニケーションを用いていました。しかし、スクラム開発を始めたばかりということもあり、日々POに確認したいことが山積みな状態でした。

そんな中でも、特にPOとのコミュニケーションは強化していかなければならないと、以下のような取り組みを主に行っていきました。

行った工夫

- 非同期コミュニケーションの強化
  - 即時性の低いPO相談はSlackでテキストベースで共有
    - 伝わらないと思ったらホワイトボードに書き出して、写真を撮って共有
    - 共有の回答を待っている間は別のタスクを実施しておけばOK
  - 即時性の高いPO相談はSlackでビデオ会議の要求を伝える
    - １時間程度以内に対応できる場合は指定の時間にSlackを通して会話
    - できない場合はそのまま同期的なチャットコミュニケーションを開始

非同期コミュニケーションと同期コミュニケーションの使い分けを簡単に工夫しました。

POとコミュニケーションを取る際に、即時で相談しなければスプリントに深刻な影響を及ぼす可能性があるものについては、Slackでメンションを飛ばしてビデオ会議による同期コミュニケーション、あるいはリアルタイムチャットによる半同期コミュニケーションを取りました。

対して、即時性が求められない内容については基本的には即時の返信は求めずに、Slack上に相談内容を書き出して返答を待つ形式を取りました。返信を待つ時間は待ち時間になってしまうように感じられるかもしれませんが、スプリントでは最終日でもない限り他に進められるタスクが十分にあるはずなので、それを進めておけばよいといった感じです。

ただし、どうしても慣れない分野の業務になると、文章化ができずに口頭での説明を行いたくなります。そこで、文脈の説明をしたい場合は社内wikiに書き残していた作業ログを添付したり、ホワイトボードに図を書き出して、それをSlackに投稿して説明を補うようにしていました。

基本的に会話ベースの同期コミュニケーションは最も楽なコミュニケーション方法です。

ですが、参加する全員が会話中に等しく時間を消費する、会話を通してわかったつもりになってしまい、後日ログがないので忘れてしまうといったデメリットも存在しています。ですので、これを踏まえて本当に同期的なコミュニケーションが必要かをその都度考える必要がありました。

現在：大型TVモニタと常設テレビ会議室システム、Slack画面共有とVisual Studio Live Shareによる同期コミュニケーション

いましていること

さて、導入当初は課題が山積みだった天神チームですが、現在では更に工夫や技術の導入を行い課題を解決していっています。

- POとのコミュニケーションは常設テレビで毎朝実施
- Slack会話用にUSBカメラとマイクスピーカーの導入
- Visual Studio Live Share を利用したモブプロ

当初大きな課題だったPOとのコミュニケーションの課題を解決するために、常設テレビ会議室システムと大型TVモニタを導入しました。

これによって、POからはチームの働き方が常に見える、チームは相談可能なタイミングが判断しやすくなる効果を得ました。とはいえ、これらを利用してすべてを同期的なコミュニケーションにしてしまうと、かえってコミュニケーションコストが高くなるため、
通常時はマイクの電源をお互いに落としておいて、必要なときにだけマイクをオンにして会話を行うようにしています。

不思議なもので、たとえ無音であろうと画面を通して相手の姿や表情が認識できると、お互いの心理的な距離が非常に狭まる効果も得られました。

次に、リモートワーカとのモブプログラミング時の工夫です。

まず、Slack利用時にオフィスとリモートワーカが多対1の状況になると、リモートワーカ側ではSlackを通して何も聞き取れなくという問題がありました。これを解消するために会議室用のマイクスピーカーを導入して、集音性を高めて極力意識せずにお互いが会話できる状況にしました。そしてUSBカメラを接続して、会話に参加している全員がリモートワーカ側に見えるようにしました。

さらに、リモートでモブプログラミングを実施できるように、Visual Studio Live Shareを利用したコーディングを行うようにしました。

これをプログラミング以外のセレモニーの議事録等にも利用したところ非常に効果があり、議論の進行中に議事を確認しながら発言することで、論点のずれに自ら気づくことができたり、リモートワーカが聞き取れない状況に陥った時に、タイプすることでオフィス側がすぐ対応できるようになり、どこに居てもスクラムチーム内でコミュニケーションが格段に取りやすくなりました。

発生している課題

しかし、日々改善を取り組もうというスクラムの文化が根付いてきてしまったのか、工夫や技術の導入を行って前進すると、更に改善するための課題が浮かんできました。

- スクラムボード(物理)の追加導入障壁が高い
- リモートワーカが依然として多人数コミュニケーションに入りづらい

リモートスクラムではPOと開発チームがスクラムボードを共有できるようにするため、JIRAによる管理を行っています。

毎日のようにPOと開発チームが触るものだからこそ、電子化することで状況の共有は非常に行いやすくなりました。しかし、これには副作用があり、スクラムチームの意識がカンバンは電子化して共有しなければという方向に向いてしまう可能性があります。私たちのチームは残念ながらこの意識に多少なりとも支配される傾向がありました。

また、リモートワークをする場合、理想を言えばどこに誰が居ようと同じようにコミュニケーションを取れるのが望ましいです。

しかし、Slackの場合は常設のTV会議システムとの共存が難しく、東京-天神間はTV会議を使いつつ、そこに追加でSlackの画面を投影する構成を取っていました。この場合、東京-天神のオフィスにいる人からは全員が見渡せる状況になりますが、リモートワーカからはSlackを起動している人しか見えず、USBカメラを使った場合もTV会議システムのカメラと、USBカメラの位置取りに苦労するためあまり使われなくなってきました。

行っている工夫

- 物理カンバンの導入
- Microsoft Lensの活用

さて、こうした課題に対してまず行ったのは、レトロスペクティブで出たTryを物理カンバンに掲示することでした。

このような日々の業務の中で意識に入れるべきだが、スプリント中に更新が行われることが少ないものは物理カンバンにして、PO、リモートワーカにも見えるようにカメラに映るように配置しました。これによって、レトロスペクティブでTryがなんであったかを忘れるといった事態は発生しなくなり、一定の効果が出ました。

リモートスクラムを行う場合、他拠点で情報を共有するからとすべてを電子化しようとしがちですがその必要はありません。

電子化すべきカンバンは、スクラムボード等の触れる頻度が高いものかつスクラムの多くの人が操作するものに留めておき、その他のカンバンは物理での管理にして、カメラに映るように配置しておけば問題ありません。

また、カメラに映らないほどカンバンが増えてきた場合、はみ出したものはMicrosoftLens等のホワイトボードモードを利用して写真にして、日常よく使うSlackのスレッドに貼り付けておくようにしておけば、ふとした時にある程度目に入る状態になります。

ちなみに私たちのチームでは、プロダクトバックログアイテムとスクラムボードはJIRAで管理し、後はすべて物理カンバンにするか、物理的に書き出したものを写真にしてSlackで管理しています。

テレビ会議室システムとSlackの共存はまさにいま試行錯誤中の課題です。カメラの置き場の工夫や様々なアプリケーションを試している最中ですが、中々難しくこれだという方法に出会えていない状態です。しかし、今後リモートワークを行う頻度は増えていくでしょうし、なるべく早く良い方法を見つけなければなと日々考えております。

おわりに

みなさん、ざっと説明してきましたがいかがでしたでしょうか。

実はここに記載した内容は、今年4月から11月までの約半年間の変化です。

人によって早い遅いの感じ方はあるにせよ、課題を可視化して工夫していけば半年でここまで変化させられることができてしまうのです。リモートスクラムであろうと、スクラムの3本柱に照らし合わせて検査・透明性・適応を続けていけば、きっとスクラムチームはリモートの課題を物ともしない生産性を得られるのだと思います。

たしかに、通常のスクラムに比べてリモートスクラムのほうが導入の障壁は高いかもしれません。ですが、リモートスクラムだから無理だ、難しいと身構えずに、リモートスクラムであっても考え方はスクラムと何も変わらないのだと捉えていれば、きっとリモートスクラムの改善も楽しめると私は思います。

雑多な文章でお送りいたしましたが、ぜひみなさんのリモートスクラムの一助になることができれば。