リモート環境でも同じように楽しくやりたい！（前編）　〜2020年度Coaching チームのリモートふん闘記〜

こんにちは、 自分が入社した時に憧れた先達がいなくなって寂しき中も、自身はもうすぐ Quipper 2年生をそつ業しようとしている、危うげな Quipper web エンジニアの @motorollerscalatron です。

stay home と言われて久しいですが、今回はそんな中でも私のいる ToC Coaching チーム が、どのように今までやっていたプラクティスをリモート主体の会社生活でも再現しようとしているかをブログ記事にしてみました。

お断りのようなもの

普通の我々の Product Blog では、対象読者をわりかし最初のほうできちんと定義していますが、今回に関しては明確にしていません。

表題の件に関して、結論から言うと、「正解」を私たちはいまだに見つけられずにいます。

wantedly では 弊社 @akane-suzuki568 により3月頃に に Quipper流のSTAY HOME の記事を掲載させていただいておりましたが、 その後も業務をうまく継続できるよう、様々な試行錯誤を続けています。

暦の上でいうと、私たちの提供する教育サービスは、一般的な小中高の学年が上がる３月、４月を見越して戦略が打たれるので年度の変わり目は、組織変更を含めて、もっとも目まぐるしい時期のひとつです。 今年度は、全世界的な生活スタイル・経済の変化がほぼ同じタイミングで起きたこともあり、 私たち自身も、かつてない感情の渦の中で、年度の切替を迎えました。

そもそもテレワークなど前提になかったような業種でも急激にリモートワークの取り入れを余儀なくされている中、今までの Quipper Product Team Blog の流れの中でせっかく一つの記事を書くのなら、 ここは一つ、「リモートワークの TIPS○○選」とするよりも、会社の中の、例えばひとつのチームがどう動いてきたかを、書いてみたくて、筆を取りました。

そういった中でも、私たちが今まで通りやろうとしてきたことを どうやってトライしているのか、を少しお見せするような形になります。

目次

今回は少し長めな文章になるので、前編・後編としました。

- - - (前編) - - -
1. かつてない勤務スタイルで迎えた季節
1.1 そもそも、Quipper での「リモートで業務をする」とはなんだったのか
1.2 リモートで新メンバーを迎え、試行錯誤で新しいスタイルを見つけていく
1.3 学んだこと

- - (後編、次投稿で公開予定) - -

2. リモートでいつものプラクティスを続ける
2.1 リモートでのモブプログラミング
2.2 リモートでのオンボーディング

3. 共有 slack と snippet という救い
3.1 slack で直接業務にかかわらないことも話す
3.2 issue では内省的と思ったら、 snippet に

1. かつてない勤務スタイルで迎えた季節

1.1 そもそも、Quipper での「リモートで業務をする」とはなんだったのか

Quipper ではこれまででも、リモートワーク制度は、裁量労働と組み合わさって、多様な働き方で最大限の力を発揮してもらうために選択肢としてとり入れられていました。 自分自身のケースで言うと、リモートそのものについては、私は会社に入って最初の開発が、リモート勤務が主である @tricknotes さんとのペア作業だったので、(リモートの 実務的なTIPS は同氏から伝授されるという嬉しい buff を享受しつつ)リモート作業を前提としてプロダクト開発業務を進めていく、ということを当たり前のようにしてとらえられていました。

今期においてはそのオプションであったリモート業務がデフォルトであり、避けられない状態になった３月においても、「それしか手段がない」ことによる不便さはあるものの、自分には業務自体には今までと比べてもそれほど制約を設けられる実感がないと感じました。（自分はそのころちょうど納期となるもののリリースが間近である程度夢中になっていたので無頓着だったかもしれない、と今は思っています）。

1.2 リモートで新メンバーを迎え、試行錯誤で新しいスタイルを見つけていく

ただ、やはり4月になると、鈍い自分も、それなりの異変のようなものを感じるようになりました。

まず、事前の公開はあったものの、年度切り替えの時点で ToC 領域という開発チームが、複数のサブドメイン領域に分かれ、私自身はそのうちの1つの、Coaching チームという個別指導系のサービス領域を特化するチームへの配属となりました。

チームでのプロダクト開発では、チーム編成の切り口を変えたこともあり、 今までより多くの方が MTG に join するようになりました。 具体的には、多くても10人レベルだったものが、ときに30人程度になったりするものもありました。 その内訳も、様々でした。Quipper の社内で異動をしてチームに 加わった方、自粛期間に入ったタイミングの入社で、普段のような出社して周囲に挨拶もする機会すらなしに加わった方、もともと存在したチームの後継チームとしてそのまま残ったメンバー。

上の要領でドメインごとに分化した新しいチーム群には、昨年度とは違う配慮があります。それは、デザイナーや、Native開発のメンバーも、ドメイン別で担当に入ってもらっている、ということです。これはよりプロダクトの完成度と開発効率を高めるために変更されたものでした。

セレモニーにより多くの役割のメンバーが関わり始めた

そんな中で、各 MTG は改めて参加メンバーを更新して会議体は定義したもの、セレモニーは今まで通りのものを最初は行っていました。

たとえば、朝のデイリースクラムは、前身となる ToC チームの時代からやっています。新メンバーになり、さっそく、このセレモニーの中でも今まで業務をオフラインでほとんど一緒にやってこなかった人たちと一緒にオンラインミーティングで初顔合わせをしてすぐに一緒の枠の中で進捗報告をしていく形になりました。 いつもやっていたはずのセレモニー(sprint planning, refinement など)のひとつひとつの中でも、思うようにカンバンを整理するのに、苦労し始めました。

少し落ち着いて考えてみると、「新しいものの開発」「人数が増えている」なんていう観点では既に 昨年、当時の Engineering Manager @ohbarye による 新メンバーが多い大型プロジェクトでの不確実性との戦い方 の形ですでに組織としては経験済みではあったのです。

ましてや、会議体は、比較的今まで通りのものを継承していました。

ですが、メンバーが新しいとなんとなく朝会がぎこちない、ということは言いづらいこともあるもの。

そんな中でも スプリントの終わりには KPT というセレモニーがあります。 始まったばかりのsprintの終わりでは、さっそく、皆がボードに問題を共有する形になりました。

_{図１：チーム結成まもない5月始め頃のKPTから。ツールも、試行錯誤でこの時だけ miro を使っている}

このKPTには web 開発のメンバーのほか、 native devs、 デザイナー、 Product Manager というすべての関係者が集結して書き出しました。期初であったこともあり、早速いろいろなレベルの問題提起があり、 私たち自身も立ち向かうその気持ちは嘘ではなかったことが、今ふりかえっても、ひしひしと感じられます。

KPTでの提案をもとに既存のスタイルを調整してみる

そんな中、音声と画面の共有という限られた表現の帯域の中での進捗共有の場合には、ちょっとした調整が効果を持ってきそうだとわかりました：

• (以前までは）今まで思い思いのフォーマットで共有docを開いて書き込んだ「昨日」「今日」「気になったこと」を読み上げていた代わりに(しばらくして)アサインされた issue との対応が明確なカンバンを直接見ながら自分の進捗を伝えるようにした。(図2)

_{図2：今まではフォーマットが安定しにくいgoogle document(上)だったが、セレモニーではカンバンだけを直接見るようにした(下)}

ほかにも、

• カンバンのレーンの構成や、その中での issue の動かし方のルールを調整 ( WIP 制限、ラベルの付け方、 DONE にした issue の最終処分 など)
• 参加者全員が参加する必要のある部と一部のメンバーだけが残る部を考え、なるべく関係が薄くなった段階で該当メンバーを開放していく
• 初期の体制上関係者として参加者として呼んでいてあっても、必要に応じてメンバー自身が各自判断して定期 MTG から抜けていく

などの工夫を通じて、より新しいメンバーがフォーカスを持ち、短時間で共通の話題に向かって問題解決をする方向に切り替えていくようにしました。

ほかにもいくつか変化はあったものの、 私たちにはチーム開発環境のヘルスチェックを行う KPTというツールがあったおかげで、 感じ取った異変をその都度問題へと切り出し、前からやっているチーム開発手法を皆で良い方向に少しずつ軌道修正していくことで、いくぶん解決へと導いていけている気がします。

1.3 学んだこと

前節のように、時間をかけて最適解に近づけていった話は、デイリースクラムの話 に限ったことではありません。

一般法則、というほどにわかったことはそれほど多くないのですが、以下のようなことがらがわかってきたと思っています。

1. オフライン 時期にやっていた事柄は、オンライン でも共通認識を持ちやすい
2. オンラインでのMTGは、空気感的なものを伝えにくい一方で、参加者ターゲットが明確かつ参加自体は（会議室リソース確保の点から）敷居が低くなり、 今までとは別の形で会議が進化しやすくなる
3. リモート MTG というと 身構えてしまう が、 ちょっとした meet への 意識変革 を行うことで、オフラインのような ささいな文脈も伝達可能 である

1 は、もともとリモートになるとコミュニケーションの難易度が増すというのは容易に想像がつくと思いますが、話題とその展開の順序のある程度わかっているMTG、そもそも次に何について話すかがわかっている MTGは、そうでない場合より話しやすくなる、というのは体験を通して改めて強化された印象の一つでした。もともと通信状況などによって音や映像が途切れたりも時には避けられない中で、前もって向かう先がわかっていれば、たとえ復旧に時間がかかってもその時間の中で答えを考えたり、などもできます。

2 にかんしては、ちょっと面白くて、私自身はリモートになるにあたって、コミュニケーションの帯域が狭くなるMTGについては「オフラインの時と比べてなんでもやりにくくなる」と短絡的に推測していたものでした。ですが、実際にKPTなどで話題に上がった時に少しききだしてみると、MTGによっては google 上で予定を作るだけでいい、という手軽さから、以前よりMTGがしやすくなった、という人もありました。反面、メンバーによっては、今までのオフィス空間を家庭のどこかにそのままどこかに持ち込む必要があり、ノイズのないスペース自体を確保することが難しくなる、などの問題はあり、完全な シャットダウンは難しかったりするのですが、ミュートや映像の ON / OFF を組み合わせて対応すれば、大きな人数の会議でさえも、会議室やディスプレイ投影などの手間がいらなくて実は楽なのかもしれない・・？という面も感じられてきています。

3 にかんしては、さじ加減が難しい時もあるのですが、ちょっとできるかきいてみるのは損はない！と思って、 自分の外のチームの人を「雑に」メンションして既存の meet に誘ったり、新しい meet を作って話しませんか、と流れを制御すると、ちいさなすれ違いも解消できたりして伝わりやすくなることがわかりました。「これだけのために meet で呼ぶのも・・」と躊躇する感覚も依然あるのですが、「一旦おいておく」ことで後でまた文脈を含めて思い出すよりも、早めに補足をしてみると結果的にコストが少ないことが経験上わかってきたという印象です。

上で、意識改革、といってしまいましたが、ちょっとした価値判断の発想をちょっと変えてみる、とも言えるかもしれません。いくつか例を示させてください。

下のケース(図３)は、開発メンバーの @motorollerscalatron と @mpls104 が 開発途中で改めて認識した PM @kosuke-uetakeへの確認事項を確認しているようすです。

PM は調整ごとでいろいろな関係者でひっぱりだこで忙しくなる傾向があり、対して web devs はある程度の人数がいると、手の空いている側のメンバーで早くできる部分を、と PM への連絡は後にまとめてしまうこともあります(もちろん、その判断が正しい場合もあります)。しかし、特にオンラインの静的な情報のみでしか案件 issue を見ていない時間が続いていると、いきなり slack 上でふられてもまったくテキストの意味をとらえにくかったり、するものです。このときは、開発側での決断スピードとの秤(はかり)にかけて思い切って meet で呼び出しています。

_{図３：PMのような忙しい立場の人であろうと、勇気を持ってmeetに誘い込もうとしている様子。話はつながっているが、「共通でいじるファイルの仕様」など、提案の根拠までを誤解ないように説明するとなると、やはり meet の出番、と思ったのでした。}

また、 1対1 であっても、お互い都合が良さそうであれば、短時間であることを宣言しつつ、 meet をやってもよさそうです。次の例(図４)では、別チームからの質問を受けて質問詳細を slack で聞き出す前に meet を提案しているケースです。この場合は、質問は一時期は同チームで仕事をしていて今はデータ分野のチームで活躍している @reizist が、かつての在籍チームへ投げこんでいる感じです。たまたま見ていたチームメンバー、 @motorollerscalatron のようなもの、が珍しくキャッチできて反応できている例です。このときは、きいてみると @reizist が解決したかった内容に対する直接的な回答を得られたものではなかったものの、issue で書いてある内容の真意を一緒に紐解いたり、関連部分の動きをひと通り話してみることで、質問と次アクションの解像度を上げることができました。

_{図４：カジュアルに担当チームあてに受けた問合せを拾って覚えているうちにと思うくらいならその場でmeetで説明してしまおうとしている様子}

「雑に」というのは実は難しいさじ加減ではありますが、リモートになって意外とみな慣れてきているようです。

これは私なりの推測ですが、いくつかのツールの試験導入が、既存のコミュニケーションの使い方を少しずついいほうに補正してくれていったのではないかと思っています。

例えば、リモートにちょうど移行する時期には、 sneek.io というツールを試していました。こちらは UI もなかなかお洒落で、もともとはメンバーの一部の中で流行っていたものを、チームを大きくして１ヶ月ほど実験導入していったもので、起動しておけば各メンバーの稼働状況が見られて、しかも特定のメンバーに話しかけたい場合はそのメンバーをクリックすれば 1vs1 のコールができる、という面白いものでした。もちろん、同じ会議ツールではご存知の Zoom を使っていたこともあります。

今回は、メインのビデオチャットツールとして採用するにはいたらなかったものの、違うツール体験も経たことで、かつてオフィスでオフラインでしていたようなカジュアルな相談のようなものを、程よい温度感の「ちょっと meetしませんか？」の形で実現できたのかも、しれません。

私たちはやはり、「オフライン以前に築いていたもの」が少なくともあったおかげでそこから今に必要なものを調整していけている感じがします。 そして、この形の展開は、Quipper のプロダクト開発チームにネガティブ・ポジティブどちらであっても些細な違和感からオープンな場で声に出していける土壌があったことが大前提にあったからこそ可能だったと思います。

_{図５：5月後半のKPT の 「KEEP」から。少しずつ TRY した内容に対して、いろいろなメンバーがよかった点を再認識していっているように見えます。}

次のブログでは、この流れにもとづいて、 新しい組織の中で行ったモブプロやオンボーディングについて、 書いて行こうと思います。

お楽しみに。