若手から見たリモートワーク時代のチームビルディング

2020 年 4 月にコロナの影響による緊急事態宣言が発令されて久しい今日この頃ですが、多くの会社でリモートワークが余儀なくされ働き方が大きく変わりました。

DeNA がリモートワーク可能な体制へと迅速に切り替えていく中で、私自身リモートワークによる業務が9割以上を占めました。私や私の所属するチームだけでなく日本中でも働くことに対する考え方が大きく変わるタイミングだったのではないでしょうか。（DeNAでは緊急事態宣言が発令される前には全社的にリモートワークがすでに可能なレベルにまで整備され、とてもスピーディーにリモートワークへと移行できました。制度や勤務体制など様々な整備をしてくださったことにとても感謝しています。）

その中で、私たちがチームのコミュニケーションや課題を改善するためにどう工夫したのかをお伝えすることで読んでくださる方のチームのチームビルディングの一助にして欲しいと願っています。チームがどのような変遷を経て、現在リモートワークでも生産性を落とさず日々チームを強固に、そして業務を推進してきたかを本記事は執筆しています。

自己紹介遅れました。DeSCヘルスケアシステム部の赤木です。
2019 年新卒で、現在は kencom×ほけんチームで保険事業に関わるエンジニアをしています。

本記事で伝えたいこと

若手目線でのチームの課題とその解決のためにチームで一丸となって取り組んだこと

本記事で伝えないこと

技術を使って生産性を高めるとか、自動化するみたいな話はしません。

技術を絡めて開発の生産性を高める話は DeNA Techcon 2021 にてチームの先輩が発表するのでそちらを楽しみにお待ちください。

こんな方に読んで欲しい

リモートワークでのチームビルディングを課題に考えているマネージャーやシニア
チームビルディングに興味のある新卒や若手

チームの背景

kencom×ほけんは 2019 年 6 月にリリースされたサービスで、まだまだ若いプロジェクトです。チームの若さにコロナの影響が相まってkencom×ほけんチームのプロダクトのロードマップや人材は流動的に変化していました。例えば、チームの開発陣は2020 年 3 月から 2020 年 12 月の間に 8人が開発者チームに出入りしていますし、この半年はプロダクトのロードマップが中々確定させられず時には1週間や隔週で変わることもありました。

そんな状況なので、開発陣はその時々で目指すべき方向性を企画側とすり合わせる必要があったり、私自身も含めてチームに新しい人材が入ると on-boarding のための時間を作る必要があったり、MTGが大量に発生していました。オフラインであればホワイトボードや、直接同じ画面を見ながら指差しでも伝えられますが、オンラインでは他者との小さい作業の積み重ねで時間がかかったり、ストレスが溜まったりするものです。

サーバーサイドチームを見てみると私が4月、2020年新卒が7月、他のチームからの異動の方2名が10月からkencom×ほけんチームに加入しています。半年で半分以上のメンバーは新規メンバーになっています。

リモートワークが推奨されている中で、リモート環境においてもチームビルディングを成功に導き、高い生産性を目指すことが必要でした。

取り組み一覧

私のチームがどんな取り組みでチームビルディングを行ってきたかを詳細に説明する前に、まずはやったことの中でも本記事で紹介する施策をまとめてお見せします。

取り組みが実施されているタイミングは色をつけています。色の濃さはチームとして生産性を高めたり、コミュニケーションをとる中で良い影響を与えた度合いが大きければ大きいほど濃くしています。

ここからは時系列に沿って話をしていきます。まずは2020年4月です。私がチームに加入したばかりの時期で、コロナによってほぼ全ての人がリモートワークをしていた頃の話からです。

1. オンラインホワイトボード Jamboard の導入（2020年4月）

kencom×ほけんのチームではアジャイル開発を取り入れていますが、KPT(Keep Problem Try)のフレームワークを使用して、スプリントの最後に活動の振り返りを行っています。

※ KPT … 良かったこと（Keep）、課題（Problem）、課題に対するアクション(Try) を整理するためのフレームワーク

オフラインで振り返りを行っていたころは、物理的なホワイトボードにKeepとProblemの付箋を貼って進めていました。振り返り終了時には写真を撮って、記録を残していました。オフラインでの振り返りが当たり前のチームが全員リモートワークへと移行する中で、KPTをオンラインで完結させるための方法が必要でした。

そこで、当時DeNA社内でも盛り上がりを見せていた、 Google Jamboard という、オンラインホワイトボードのツールを導入しました。Jamboard を利用したKPTの良かったところは主に以下です。

議論が活性化した
画像を貼れて、ワイワイガヤガヤ感を出せる
Problem（課題）から Try（課題へのアクション）への導線がスムーズになる

私は物理的な付箋を使用してKPTを実践していた時期がありますが、Jamboard を使用している時の方が議論の活性化を感じます。オフラインでのKPTでは付箋の内容をグルーピングする時間や付箋を読む時間などで時間がすぐに過ぎていきます。また、文字が小さいと読み返すことも困難です。Jamboard はオンラインでリアルタイムに付箋を読みながらでもグルーピングがしやすく、参加者は付箋の内容に集中することができます。また画像（slackのスタンプ画像）を貼ることで、より感謝を伝えたり喜びを共有したりできます。手軽に付箋やコメント、画像を貼ることができるので付箋の内容を理解したり、議論するための時間を増やすことができます。

上記では Jamboard の良い点をお伝えしましたが、物理的なホワイトボードに劣る点もあります。

フリーハンドでの記入が難しい

自由にグルーピングしたり、記述することが難しい場合があるのでファシリテーターの負担が増えるのは注意点です。

kencom×ほけんのエンジニアチームによるKPTのうち Keep の Jamboard の画像を皆さんに共有します。

KPTにおいて最も大切な点はチームが課題（Problem）に感じていることに対しアクション（Try）を実行するサイクルを継続的に回していくことです。その点において、物理的なホワイトボードと付箋を使おうが、オンライン上でのホワイトボードと付箋を使おうがkencom×ほけんのチームは改善サイクルを回せています。

どんなチームでも振り返りに Jamboard を使用すれば良いというわけではなくて、参加者が当事者意識を持って Keep や Problem を挙げられるチームである必要があります。kencom×ほけんのチームは私が加入する以前までは開発経験が豊富なシニアメンバーが多数を占めていました。働き方がオフラインからオンラインへ変わってもこれまで同様にプロとして当事者意識を持って振り返りを実施できました。オフラインの時と同様に振り返りを実施できた要因の一つだと思います。

【オフラインの時と同様以上にチームの課題を継続的に改善するコツ】

・ KPT参加者が当事者意識を持って Keep や Problem を創出すること
・ KPT参加者が他の方の Keep や Problem を尊重する雰囲気が醸成されていること
・ スクラムマスター（KPTでのファシリテーター）が、 Problem を引き出し継続的に改善フローを回していくこと

オンラインでもチーム全員が同じ画面を見ながら Keep や Problem を振り返ることができるのは良いですね。

2. 企画+エンジニアのKPT（2020年4月）

日々の開発において、振り返りと改善が重要だということはすでに書きましたが、サービス開発・プロダクト開発という文脈において振り返りをエンジニアだけで完結させることは難しい場合があります。それは開発がサービスの企画やQAのプロセスと絡むからです。

2020年4月時点においてkencom×ほけんチームでは、 企画+エンジニアのKPT と エンジニアのKPT を実施していました。企画+エンジニアのKPTは日々の開発において、エンジニアチームだけでは見つからない Keep や Problem へと対応するために必要なKPTです。テックリードやプロダクトオーナー、QAの担当者などそれぞれの職種から代表者が集まってチーム全体の振り返りをします。それぞれの KPT は1時間30分かけて行われます。

ちなみに私（若手エンジニア）は担当者ではなく任意での参加者でした。任意の参加者はKPTに参加せずに、KPTの後に付箋がまとまったホワイトボードや Try がまとまった資料をみるだけでも大丈夫な参加者です。担当者と同様に Keep や Problem を記述することも可能です。

私はチームに加入した当時、企画+エンジニアの KPT は必要ないのでは？と思っていました。理由は以下です。

企画+エンジニアで振り返る内容とエンジニアで振り返る内容は多少重複する
任意の参加者と言いつつ大体全員参加するので、サービス・プロダクト開発のためのチーム全体時間をブロックする時間が長い（1時間30分 × 参加者の人数）

重複する内容があるにもかかわらず、チームのほとんど全員が参加するので無駄が多くなっていると感じていたのですが、私は任意（見る専用）での参加だったので、まぁいいかと思っていました。しかも他の作業をしながらの参加だったので、実際にはKPT後にまとめられる資料を見るだけでも理解するためには十分でした（今思うと、見るだけの KPT に参加していたことを無責任だったと後悔しています）。

企画+エンジニアのKPTは任意の参加者がほとんどが参加する状況で、参加者が多く全てを振り返るための時間が足りないこと、チーム全体の手をブロックすることが課題になっていました。

最終的に企画+エンジニアのKPTは2020年7月を最後に取りやめることになりました。その理由については、次の 作業集中日の設置 にて話します。

3. 作業集中日の設置（2020年7月）

私はチームに加入してから、毎週のように細々とある MTG に疑問を感じるようになっていました。加入当時は on-boarding や新しく加入した時の研修が多いのが原因かと思っていたのですが、加入から数ヶ月経過してもその疑問は拭えませんでした。そのうちの一つに先ほど説明した企画+エンジニアのKPTもあげられます。

単純に MTG をなくせば良いと思っているわけではありません。必要な MTG はもちろんあります。ただ、毎日 MTG があって作業に集中できる日がなかったことが課題でした。作業に集中できないと開発が遅くなり、副次的にキャッチアップしたい案件の把握や、slackで意見を言い合う時間を作ることが難しくなることが問題です。

本施策を実施するに至るきっかけの一因となったのは、 2020年7月の KPT で私が挙げた、たった1枚の Problem でした。

前々から集中日を増やそうという雰囲気はあったのですが、根本的な解決につながるものはなく、心の底から作業日を確保したいという思いから書いた1枚でした。

チームの仲間が賛同してくれて、中には 4 日は欲しいというメンバーも現れました。kencom×ほけんチームのKPTでは気軽に書いたことでも本気で改善するために、グループリーダーがとことん深く掘り下げます。KPT の時間で収まりきらないような Problem に関しては別途 Try のための時間を必要なメンバーに声をかけてどんどん推進してくださいます。

仲間の賛同や Try によって集中日を作る取り組みが加速し、MTGを精査して縮めたり、無くしたりできないかグループリーダーが取りまとめることになりました。企画+エンジニアのKPTが2020年7月を境に取りやめることになったのもその一部です。

書いて共有して終わるだけの KPT なら正直あまり気が乗らない(というよりやる意味ない)のですが、こうやって気軽に発言したことや書いたことでチームメンバーが賛同したり議論したり、メンバーの雰囲気を知れたりする中で、チームの課題が具体的に改善されるので若手としては安心でき信頼できます（余談ではありますがDeNAには DeNA Quality として掲げる5つの指針があります。そのうちの透明性と発言責任はこの KPT の活動を通して体現されていることが分かります）。

最終的に、MTGの精査と、月・火は作業集中日として可能な限りMTGを入れないこと、金曜日に MTG をまとめることになりました。現在は 2.5 ~ 3.5日ぐらいは作業集中日が取れるぐらいの感覚になってきました。

月・火が作業集中日として確保されていることで以前よりも自身のスケジュール管理が安定することで、それ以外の曜日に MTG が細々と発生しても資料の把握や前もって疑問点を残すための時間を作れるようになりました。事前に準備することで MTG 中の様々な職域の方とのコミュニケーションがスムーズに進むようになったと感じます。また、作業集中日があることでそれ以外の曜日に私から企画の方との MTG も設定しやすくなりました。

kencom×ほけんのチームではオンラインでの業務に関するコミュニケーションは作業集中日の設置によってそれ以外の日に気軽に設定できるようになりました。

【オンラインでも業務のコミュニケーションを気軽にできるようにするコツ】

・チーム全体が作業に集中できる時間を作る
・作業集中日以外はMTGの時間を気軽に抑えられるようにチームの意識を合わせる

4. MTG資料の先読み（2020年7月）

作業集中日を作るために金曜日にまとめた MTG のうちの1つに企画の方がチーム全体に企画やイベントの進捗を共有するMTGがあります。プロダクトとして目指す方向性をチーム全員ですり合わせる重要なMTGです。私は チームの目指す方向をすり合わせるMTGにも課題 を感じていました。

このMTGでは、MTG中に資料を読み上げながら説明する運用になっていました。読み上げでの説明だったので時間がかかることや参加者が資料を理解した状態でMTGを進められているのか不明な点が課題だと思っていました。

そこでその解決策としてMTG資料の先読みのための施策が2020年7月から実施されるきっかけとなった KPT での1枚の Problem があります。

訴えたかったことは、形だけの MTG であればしなくて良いということです。そのような MTG に当事者意識が生まれるわけないですし、チーム全員が同じ方向を向けているのかどうか怪しいですから。

この Problem から出た Try として 「前もって資料を読んで、既読の印 or コメントを記述」 をすることになりました。2020年7月のことでした。

ただ、正直、前もって資料を読むことを義務にして行う MTG は成り立たないと思っていました。学生の時までの感覚でいえば、先読みしてくる人たちとの付き合いが自分にはなかったからです。

が、期待をかなり良い意味で裏切られ、資料の先読み&コメントは想像以上に定着しました。チームのメンバーって真面目で好きだなぁと思うと同時に、他の方のコメントを読んで思考が深いなぁと改めてチームの仲間を尊敬しました。これはオンラインならではの解決方法だと感じます。本来理解しているかどうかとか、MTG はオフラインならその場で発言したりとか近くの人に気楽に聞くことができます。オンラインではそれは難しいですが、そのぶんコメントしておけば準備する側は前もって資料や資料のリンクを準備することができて、MTGの時に無駄な時間なく話を前に進めることができます。

この施策がうまくいった理由は、 資料を準備する側のメリットと、参加者のメリットがあること と チームのトップが大号令 をかけたことだと思います。

まず、 資料を準備する側のメリットと、参加者のメリットがあること についてです。

資料を準備する側のメリット

資料が読まれていることが視覚的にわかる

参加者のメリット

MTGの質の向上（前もって質問を考える時間があるので、調べればわかることを聞かずに済む）
多様な観点からの気づきを得る（他の方のコメントを見て、違う視点からのコメントができる）
事業状況を把握できる（特に新卒や若手はビジネス経験が浅いので、事前に資料を読み込む時間が必要）

準備する側と参加者の双方にモチベーションの向上が見込める点が良い運用になっていました。

次に チームのトップが大号令 をかけたことについてです

これまでの慣習を変えるときは苦痛が伴いますが、チーム全体で方向を合わせて推進していくために、エンジニアチームの長と企画チームの長が号令をかけて進めてくださいました。チームのトップが、まずやってみてから少しずつ調整してチームに合わせていくという思想をもっているので迅速にチームの方向を合わせて改善を進めていけます。

この施策によって、毎週 1h かかっていたMTGが 0.5h で終わるようになりました。単純に短くなっただけでなく、他の施策によって少しあいた隙間の時間に以前よりも企画の資料を読む時間を増やすことができたことで理解が深まり、コメントをしっかり残せるようになりました。

【オンラインでもチームの目指す方向を定めて改善のフローを継続的に回すコツ】

・ 振り返りでチームの意見を継続的に吸い取ること
・ チームのトップが号令をかけて進めること
・ 改善したいことが一側面だけのメリットになっていないこと

さて、ここまでは緊急事態宣言を受けてリモートワークへと急に体制変更を余儀なくされた数ヶ月のチーム全体の話をしてきました。たった数ヶ月の間ですが、日々の工夫で同じことをしていてもチーム全体での意識のすり合わせや、チーム内でのコミュニケーションのあり方を見つめ直すことができます。

次はチーム全体の話からエンジニアチームに焦点を絞って話を進めていくことにします。

5. Daily Scrum で今日の一言コーナー（2020年4月）

どんなエンジニアチームでも朝会や、Daily Scrum と呼ばれる日々の共有会のようなMTGがあるのではないでしょうか。kencom×ほけんのエンジニアチームでも例に漏れず Daily Scrum があります。リモートワークで最も影響を受けやすいのは日常的に発生する Daily Scrum ではないでしょうか。

毎日あるにもかかわらず、一歩間違えば無機質で進捗を共有するだけの会になり、チームビルディングもへったくれもありません。日々の Daily Scrum に kencom×ほけんのエンジニアチームはどう向き合ってきたかを話します。

現在、チームの Daily Scrum では前半に各々の進捗を共有し、後半は毎回異なる人が担当で一言の話題を提供します。

元々、 Daily Scrum にて一言のコーナーはありませんでしたが、全員がリモートワークになったタイミングで、チーム内での会話の減少に対応するために開始しました。私がチームに加入してすぐのタイミングだったのでどんな話をすれば良いのか正直不安でしたし、直接会ったことのある人の方が少ない中で自分の趣味嗜好をどのぐらい出しても大丈夫なのか心配でした。ですが蓋を開けてみたら、これがまぁめっちゃ盛り上がります。いろんなネタで盛り上がりますが以下はそのほんの一部分です。

漫画
結婚式
ピアノ生演奏
家系図を辿る
競馬
家のお披露目
etc

改めて見直すとすごい幅です。Daily Scrum には20歳台の若手がいれば、40歳台のシニアメンバーもいます。

凝った資料を作る必要はなく、即興で何か話すでも大丈夫という前提ではありましたが、スライドを用意してくる人が多数です。みんな好きなことは熱弁したくなるんですね。そこに年齢や役職の差は存在しませんし、もはや一言でもありません。

エンジニアは口語的なコミュニケーションと比べて、テキストでのコミュニケーションを得意とします。オンラインでの一言コーナーは担当者以外は声をあまり出さない分チャットがかなり盛り上がります。

私はこの Daily Scrum の一言コーナーの良かった点は リモートで1回もまだ会ったことのないチームメンバーの人となりを知る機会ができて相談しやすい状態を形成できた ことです。Daily Scrum の前半部分でスケジュールや、結合テストの共有や、いつでも直接テキスト上で相談できるようになったことによって、ちょっとしたコミュニケーションで変わる開発のヒヤリハットを防ぎやすくなったと思います。

【オンラインでもチームメンバー同士が信頼関係を築くためのコミュニケーションをするコツ】

・日常的にチームがコミュニケーションを取る場を作る（1日10分あれば十分に足りる）
・年齢・役職関係なく同じ空間・同じ役割を平等に担当してコミュニケーションする

これは少し余談ですが、最近はエンジニア以外の職種の人も発表してくれる機会が出てきました。エンジニアチームの Daily Scrum ではありますが、これからエンジニアとチーム全体とのコミュニケーションもさらに活発になっていくことを期待しています！

6. 新卒の自走環境整備（2020年7月）

2020年3月、私が新卒2年目でkencom×ほけんチームに加入した当時、チームに面識のある人がほとんどおらずリモートワークで顔が見えない状況でもあったため心理的安全性を十分に担保できていませんでした。また、大きいとは言えないまでも20人以上いるチームのメンバーとコミュニケーションをとる必要があります。

正直、チーム内で色んな人との壁を感じていました。

新卒2年目の私でさえそのような状況だったので、配属予定の新卒は初めての職場、そしてリモートワークという状況において心理的安全性を保つことはさらに困難です。チーム全体としても新卒に限らず新しく入ってくるメンバーの心理的安全性をどのように担保するのかが課題でした。

新卒一名の配属を予定していたサーバーサイドチームでは、この課題を解決するために以下のような方針を決めました。

[ゴール]

メンティーが自走できる状態。1人でやり切ることではなく、自分の引き出しを使って必要な人やツールを頼りながら様々な局面に対応できる状態を作ること。

[方針]

コミュニケーション機会の創出によってメンティーの心理的安全性を高めつつ、メンティー自身で課題を解決するためのコミュニケーションハードルを下げること

[具体的なアクション]

開発以外のことも含めてなんでも聞けるチャンネルの活用
毎日サーバーサイドチームだけのDaily Scrumの実施
隔週金曜に出社して、業務のことを一切考えずにお互いのことを知るための時間を設ける

具体的なアクションの内、隔週金曜の取り組みはコロナの影響によって出社できなくなったため、ほとんど形骸化してしまいましたが、とにかくコミュニケーションの接点を増やすことを意識した取り組みにしました。

kencom×ほけんチームに配属された新卒は二人とも自走している状態を現在作れていますが、特に近くで動きが見えていたサーバーサイドチームの新卒は、外部協力会社とのコミュニケーションや、kencom×ほけんアプリユーザにデライトを届ける機能をリリース(本番環境へのデプロイも)することができています。サーバーサイドチームが設定していたメンティーが自走できる状態は作れていると思います。特に、1人でやることにこだわらず、周囲と相談しながら進められていることがリモート環境下でも発揮されているポイントが良いです。

新卒本人に心理的安全性を保つことができた要因を聞いたものをいくつかまとめます。

timesチャンネルで発言しまくれたこと
困ったらdev-helpチャンネル（kencom×ほけんチームで開発に限らず何でも相談できるように設けられたslackのチャンネル）を使えたこと
Daily Scrum 一言コーナーでメンバーの雰囲気を知れて和んだこと
サーバーチームの人たちが優しかったこと（良かった。）
サーバーチームの Daily Scrum があったこと
同じチームに同期や1つ上の先輩（私）がいたこと
メンターとの1on1が週1であったこと

timesチャンネル(slack上でtwitterのように気軽につぶやくことが出来る文化)を作成するきっかけは前出のKPTでの新卒本人のProblemに対するTryでした。また、Daily Scrumの一言コーナーも前出の取り組みだったりで、サーバーチームで考えたアクション以外にもチーム全体で新卒の自走環境をサポートできたのではないかと思います。

【オンラインでもチームに加入するメンバーが早くチームに馴染むために重要なコツ】

・ コミュニケーションを複数の場所で取る機会を作ること
・ コミュニケーションを取る相手が幅広い年代を網羅していること
・ 新卒・若手・シニアそれぞれの目線でリモートワークでのコミュニケーションのあり方についてチーム全員で対話する雰囲気を作ること

皆さんのチームのオンラインコミュニケーションの様子はどうですか？壁を感じてはいませんか？

まとめ

本記事ではコロナの影響を受けながらも2020年4月からの約半年で、kencom×ほけんチームがリモートワークでチームの課題に向き合い、どのようにチームビルディングをしてきたかを若手なりの目線で話しました。

私はチームビルディングのために 若手は上長やチームに素直に意見を共有して全員でより良い意見へと昇華すること、そして 上長は若手の意見に対してとことん向き合い解決すべき課題を一緒に探しアクションを移譲すること ができると良いと思います。

若手は経験の浅さから来る多少短絡的な意見を言いがちかもしれませんが、私は若手という立場を存分に生かしてストレートに意見を言って、周囲の先輩方が都度本質的な課題を深く紐解いてくれるというチームの雰囲気が好きです。ストレートに隠さず発言できる状態を保ち、かつ、視座の高い意見を新卒や若手が言えるチームになれば新卒や若手に限らず、チームとしても、会社としても資産だと私は思います。

ぜひチームの方に共有していただき、あなたのチームのチームビルディングに生きると嬉しいです。長い間読んでいただきありがとうございました。