どうも、FORTE（フォルテ）と申します。COVID_19、いわゆる新型コロナウイルス感染症によって、リモートワーク（テレワーク）を中心としたオンラインでの活動が急激に増えたと思います。折しも私が勤めている会社では、創業時からフルリモートを働き方を推奨しているため、オンラインで働くということに対しては免疫がありました。そのため、この章ではリモートワークの経験がある程度ある視点で書かれています。初めてリモートワークしてみた的な内容はきっと他の人が書いてくれると思うので、基本的な話はそちらを御覧ください。
さて、私は2020年の1月から新規に発足するチームに参加することになりました。リモートワークで新規チームの立ち上げから参加するのは初めてだったので、そこでいろいろと工夫してみた内容と結果をオンラインでの仕事生活として「リモートワークでの新チーム構築」を紹介いたします。
なお、私が勤めている会社はいわゆるSaaSを提供するシステム開発会社なので、ここで解説する内容はITエンジニアがリモートワークで新規チームを作ってみた、という内容になります。
チームの発足としては普通の始まり方だったと思います。上司にあたるCTOからチームに求められる存在意義を説明してもらいました。その上で自分たちがどうするか?どうしていきたいか?というのを会話していきました。
これらはすべてオンライン、リモートで会話しています。社内ではZoom、Slack通話で二極化していますが、エンジニアにはSlack通話が人気です。これは社内の会話基盤がSlackであるからアプリの切り替えなくすぐ会話に移れること、Slack通話のペン機能が非常に優秀であることがポイントとなっています。
アジェンダや議事録はすべてオンラインドキュメントサービスで管理しています。弊社ではいくつかのサービスを併用する形になってしまっていますが、ずっと使っているからという感じでいまはDocBaseがメインとなっています。Slack通話であればこのDocBaseのドキュメントに手書きのペンでアレコレと指し示しながら会話ができますし、DocBase自体の共用編集機能によって会話しながら手空きの人が議事録を取ったり、追記したりできます。このあたりは正直、オフラインで打ち合わせをするよりスムーズである気がします。会議室を取ったり、場所移動したり、ホワイトボードマーカーが出ない!替えはどこ!?という無駄な時間を過ごさなくて済みます。
チームのタスクはすべてチケット管理をしており、スクラムのバックログの仕組みを真似て優先順位をつけたものを上から取ってこなしていく開発スタイルでした。厳密なスクラムを適用した開発はしていませんでしたが、いくつかのセレモニーを取り入れていました。
ここまでが基本的な業務スタイルです。ここからは特筆すべき重要事項について解説していきます。
当たり前のように思えるかもしれませんが、新しいチームが発足したときは「我々のチームがなにを目的としたチームなのか？」ということを確認しましょう。多くのケースで上司から説明があると思いますが、それだけでは不十分です。というのも説明をどう受け取ったかの解釈がメンバーによって違います。必ずメンバー各々の言葉で認識を確認しましょう。このとき次のような質問をすると効果的です。
- 我々はなんのためのチームか？
- 最も優先度が高いのはなにか？
- やらないことはなにか？
- ステークホルダーは誰か？
自分で答えると答えがすぐ出るのでやる意味を実感しづらいと思いますが、これをチームで確認するとバラバラになることが多いです。この認識がバラバラになっていると日々の業務で意見やタスクの優先順位のすれ違いが頻発し、ストレスフルになります。逆にこの認識を合わせておくとチームとしてスムーズに業務を開始できます。
最後のステークホルダーというのはチームのタスクに関して判断する責任を持つ人になります。チームとしてどのタスクをやるのか、どれからやっていくのか、状況が変わったときに続けるのか止めるのかあたりの判断します。スクラムでいえばプロダクトオーナーにあたるわけですが、この役割を持っている人の認識がチームの中でバラバラだとタスクの判断基準がバラバラになってしまい、これまたストレスフルな日々となってしまいます。迷ったときは誰の判断基準に従うべきなのかを必ず確認しておいて、チームの認識を合わせておきましょう。
なお、この考えをプラクティスとしてまとめたものとして「インセプションデッキ」が有名です。必ずしもこのインセプションデッキをすべて作る必要はありません。その要素を抽出して必要な部分を実施するのもおすすめです。
インセプションデッキについては名著アジャイルサムライのテンプレートがおすすめです。
これはリモートワークだから、というよりは新しいチームだからという側面が強いです。しかし、今までオフラインで作業していたチームが突然オンラインに変わったのように、環境の変化をきっかけに行うのもおすすめです。これまではオフラインで顔を突き合わせていれば表情や態度の変化でわかっていたことがオンラインでは、それが難しくなるケースがあります。特にテキストでのやり取りが増えると、口頭では意思の疎通ができていた（と思っていた）のに情報量が変わることで意思の疎通ができなくなったと感じることが多くなります。
そこで明示的に自己開示を行いました。これもいくつかの方法があるのですが、私のチームではドラッカー風エクササイズを試してみました。ドラッカー風エクササイズはチームメンバーが個々に以下の質問に答えそれをチームに共有することで自己開示を行います。
- 自分は何が得意なのか？
- 自分はどういうふうに仕事をするか？
- 自分が大切に思う価値は何か？
- チームメンバーは自分にどんな成果を期待できるか？
これは自分が抱く自分への期待感、他人が抱く自分への期待感をすり合わせることで認識の齟齬をなくす仕組みです。さらにこういった自己開示は自分の言葉で行うこと、つまり口に出して行うことが大事です。オンラインだとつい文章で共有しがちですが、テキストより肉声のほうが温度感が伝わりますし、文章だと余計な情報が削ぎ落とされてしまい開示した自己が正しく伝わらないことがあります。また喋ることで自分が認知していなかった想いや感情に気づくことがあります。
そのため、記録用に文章に残しても良いですが、必ず音声で説明するようにしましょう。
ITエンジニア向けの自己開示の一種類として、スキルの共有を行うのも効果的です。これは「スキルマップ」というアクティビティで共有します。開発対象のシステムやサービス、プロダクトに関係する言語やフレームワーク、ライブラリ、スキルなどを縦軸に取り、横軸にはメンバーの名前を書いた表を作成します。この表には凡例として◎（チョットデキル）、○（完全に理解した）、△（支援がアレばできる）、−（ナニモワカラナイ）、空欄（未経験、知らない）を用います。さらに横に↑（やりたい）、↓（やりたくない）をつけると効果的です。これにより、得意だけどやりたくない（他に学びたいことがある）、苦手だけど克服したい、といった想いを伝えることが可能になります。
チーム（や会社組織、プロダクト）の状況によっては、得意だけどやりたくないことをお願いすることがあるでしょう。このスキルマップがアレばそのときに「申し訳ないけどお願い」「次のタスクはやりたいと言っていた内容にするから」と一言かけてあげることが可能になります。些細なことに思いますが、この一言が顔が見えないオンラインでは重要な一言になります。
その場合はいくつか取れる方針があります。ですが、無理やり参加させるのは止めましょう。乗り気ではない、というのも自己開示の一つです。それを尊重できないのでは自己開示を行う意味がありません。ダブルスタンダートにならないように客観的に自分たちの行動を見るようにしましょう。
乗り気じゃないメンバーに対しては、そのメンバーを外して行うのが良いでしょう。もちろん結果は必ず共有するようにします。さらに、あとからやりたくなったらもう一度やることを厭わないようにします。乗り気じゃない理由は様々であり、それらに対して対応していく方法もありますが、単純に放っておいて欲しい場合もありますので深入りが逆効果になる場合もあります。必要があれば向こうから声をかけてくる（またできればそうして欲しいと個人的には思う）のでそれを待つ方が良いかと思います。
オンラインという側面から工夫したポイントをお伝えします。
新しいチームではスプリントを1週間で回しました。1週間にした狙いは新規チームであるがため、課題、課題への対応、良い点、想定外の事態、過不足、見えているもの／見えていないものなどに対して早めの気づきと共有を行いたかったのです。
1週間スプリントによって、5回の朝会と1回のスプリントレトロスペクティブ（ふりかえり）を行います。ここで実際にタスクを行ってみての気づきや共有を行います。朝会では主にタスク内容や進捗からの気づきを得たり、共有したりします。進捗が遅れている、進んでいるのであればそれは何故か？タスクの粒度や内容は適切か？やる前とやったあとではタスクに対して情報がアップデートされているはずです。そこから来る気付きがないか確認しましょう。
特にオンラインに慣れていない場合、想定したより進捗が出ていない、または出すぎている場合があります。特に集中できないから残業してまで挽回していたら要注意です。無理が必要な時期ではないのに無理していても長続きしません。進捗を犠牲にしてでも、定時時間内で想定したアウトプットが出せるようにすることを優先しましょう。
ふりかえりではタスクの進捗の他にスプリントゴールに対する成果も確認します。このスプリントは予定どおり進んだのか、進みが悪かったのか、何が問題で、良かったことはなにか？さらにメンバーの言葉で印象に残ったことを喋ってもらうようにします。これは自己開示の項目でも伝えたとおり、文章以上の情報量を得たいため音声で喋ってもらいます。
オンラインでもふりかえりのフレームワークは機能します。実際KPT、YWTのどちらも試しましたが、音声通話とドキュメントを共有編集することで十分ふりかえりをすることができました。オンラインの場合、身振り手振りが伝わりづらいのでファシリテーターは誰が喋っているのか、誰に喋ってもらうのかはきっちりと分けた方がスムーズに進みます。特にオンラインだと会議室など場所の時間制限がないため、ズルズルとやりがちです。タイムキープはしっかりと行い、だらけないようにメリハリをつけることを意識しましょう。
メリハリをつけるポイントとして、オンラインではふりかえり前のアイスブレイクが非常に重要です。オフラインでふりかえりを行う場合、会議室に移動したり、執務室内の壁などに移動して行うでしょう。この移動によって作業ではなく、これからふりかえりを行うというふうにスイッチが切り替わります。しかし、オンラインでは作業していたパソコンそのままでふりかえりを行うことになるため、頭が切り替わりづらくなります。これによりふりかえりに集中できなかったり、内職をしてしまうことで振り返りも作業もどちらも中途半端になってしまう可能性があります。
これを防ぐためにふりかえりの冒頭5分くらいで、アイスブレイクになるようなアクティビティを行うことをおすすめします。体を動かすようなものは難しいですが、何かを喋ったり、書き込んだりするようなアクティビティはオンラインでも可能です。私はHappiness radar（ハピネスレーダー）というアクティビティを好んでやっていました。オンラインでやりやすく、簡単なわりに頭を切り替える効果が高いアクティビティだと感じたからです。
Happiness radarは顔文字や図をひとつ書いて今の気持ちを表すアクティビティです。例えば晴れマークを描けば機嫌が良い、△を描けばイマイチのようなイメージです。日本語の場合は漢字一文字でも面白いでしょう。図を書いたらそれについて一言で説明します。オンラインで実施する場合、多種多様な絵文字を使うことができます。私はふりかえりを記録するオンラインドキュメントとは別にSlackにスレッドを立ててそこにメンバーが一つずつ絵文字を投稿していました。これがまた人によって絵文字を選ぶセンスが違うため、非常に面白いものになります。
それだけで会話が弾み頭を切り替える良いきっかけになるため、Happiness radarを始めとしたアイスプレイクのためのアクティビティはオンラインでのふりかえりにおいて特におすすめです。
オンラインでのチームビルディングとして特に意識したほうが良いと実感したことを紹介します。並べて見るとオフラインでも重要なことばかりですね。オンラインもオフラインも本当に重要なとこは変わりません。きちんと基本を抑えていくのが重要です。
オンラインでのリモートワークとなると、メンバーや会社の人と話すきっかけが無くなったり、黙々と作業に集中することが増えるので会話をすることが少なくなります。そのため、意識して会話することが重要になります。会話が少なくなるとメンバー間の意思疎通に齟齬が出たり、雑談がきっかけで発覚していた課題やチームでのやりたいことなどが埋もれていきます。
また普段から人と話さなくても大丈夫と思っていても、一度チームや組織で集まって話してみると「会話が足りないね」「話せてよかった」となることがあります。実際に私の会社でも同様のことがありました。そのため、普段から意識して会話をするくらいがちょうど良いと思います。会話する方法としては次の方法があります。
- 音声雑談チャンネル
- オンラインオフィス
- ペア・モブ作業
音声雑談チャンネルはSlackなどのチャットツールに音声雑談をするチャンネルとして用意します。テキスト用の雑談チャンネルでは流速が早くて音声会話用の投稿が流れてしまうので専用のチャンネルを用意すると良いでしょう。ちなみに私はよくこのチャンネルを使っていますが、社内ではあまり人気がありません。まぁ仕事中に雑談するのってなかなか難しいのでそんなものだと思います。
オンラインオフィスは様々なサービスで提供されていますが、だいたいは会社で提供されると思いますのでそれを利用すると良いでしょう。会社で提供されなかったら好きなサービスでやれば良いと思いますが、セキュリティや管理に手間がかからない（本職の作業に影響がでない）ようにしましょう。
ペア・モブ作業は会話しつつ作業を進められる最もオススメの仕組みです。別にひとつのタスクを複数人でやらなくても、それぞれのタスクをやりながら音声通話を繋いでいるだけでもふとした瞬間に「ちょっと雑談いいすか？」のように雑談がしやすくなります。また難しい作業のときはすぐにペア・モブ作業に移行することでチーム全体のスループットを上げることができます。
オンラインでの作業では会話することが少なくなったり、ちょっと画面見せて〜と具体的な進捗を確認する機会が少なくなりがちです。そのため、最初から進捗を確認しやすいようにタスクの完了条件を厳密に定義しておきましょう。さらにチーム内で確認しておくと認識の齟齬が少なくなるので、コミュニケーションもスムーズになります。タスクの完了条件はタスク管理してるところに一緒に書きましょう。多くはチケット管理にしていると思うので、チケットに書いておくと良いでしょう。
また、完了条件は朝会で確認すると良いです。明確な条件というのは誰にとって明確か、というのは非常に重要です。一人では明確だと思っていてもチームに伝わらなければチームにとって明確とは言えません。タスクの分割時や朝会、タスクに着手するときに確認すると齟齬の発生を抑えられ、最新の情報を適用しやすくなります。
この1ヶ月、2ヶ月でリモートワークになった人は多いのではないでしょうか。リモートワークが良い、悪いではなく与えられた状況で求められる成果を可能な限り出していく、無理な場合は次善策を講じるのがプロだと思います。
そんな中で新しいチームを立ち上げに参加するという機会に恵まれて、いままで自分が学んできた様々なものを出し切れた、と思っています。結果的にそのチームはもう解散してしまったのですが、それはチームに問題があったのではなく外的な要因でした。その外的な要因を防げなかった、という意味では反省点なのですが、会社組織としては正しい選択だったと思います。なので、反省半分、仕方なし半分といった感じです。
COVID_19によって劇的な環境変化が起こりましたが、この先も同様に変化が起きていきます。感染が一段落し元とは異なる日常に戻る変化、感染が長期化しゲームルールが一変してしまうこともあるでしょう。そんな中で今回の経験はこれからも新しいチームを作れる、やっていけるという自信につながるものにできました。この経験と私が得られた自信が少しでも今の変化に戸惑っている、悩んでいる方の一助になれば幸いです。
お互いにもっとうまくできるやり方を探し求め、分かち合い、見出していきましょう。でもあんまり深刻に受け止めすぎないで。楽しみながら。