BALES CLOUD TEAMのMTG非同期化への取り組み

スマートキャンプでBALES CLOUDというSaaSを開発をしている井上です。社内では師匠と呼ばれています。 BALES CLOUDはスクラムで開発をしているのですが、自分達のスクラムイベントは同期的な動きが求められるようなイベントが多くありました。タスクの難易度によってはスクラムイベント + 突発的な相談MTGで開発時間が削られて開発が進まないなどの課題もでてきていました。

そこで現在は非同期でドキュメントを元に会議や議論をする形に一部を移行する取り組みをしております。
なので今回はどのような考えでこの活動をしたかや、得たものや失ったものについて共有できればと思います。

前提
非同期を考えた理由
当時のMTGについて
目指した状態
何を非同期にするか？
実際にやった非同期の活動
実際に運用した朝会記事の構成
非同期化の失敗
非同期で得たものと失ったもの
感想
今後

前提

同期と非同期の考え方

同期と非同期のコミュニケーションは以下のように分けて考えています。

同期：同じ時間を共有したコミュニケーション（例：MTG、1on1）
非同期：異なる時間でのコミュニケーション（例：Slack、メール）

どちらも良し悪しがあるため、チームとの相性を見つつ生産性を高める方法を取ることができればそれで良いと考えてみます。

記事内で伝えたいこと

この記事を通じて自分達と同様に同期のコミュニケーションしかしていなかった人たちが非同期という活動をする際に少しでも参考になればなと考えています。そのため、これが最高の働き方だ！という話をするわけではなく自分達にとって良かったことや悪かったことを伝えていきます。

記事内でふれないこと

この記事に置いて生産性という言葉を多く使いますが、どのようにして生産性を計測しているかはそれだけで大きなテーマなのでここでは話しません。 ※ そのうちFour Keysの取り組みなどご紹介する記事で話していきたいと思います。

非同期を考えた理由

開発チームで議論すべきテーマや問題が多かった時期に1週間のスケジュールのほとんどがMTGなっている時期もありました。チームとしては必要なMTGと考え取り組んでいましたが、開発時間もとりたいとも思っていました。この解決手段がなにか無いかと考えたときに技術顧問のよしおり(@yoshiori)さんからLaunchableの働き方を教えていただき、自分達なりに一部の要素を取り入れられないか？と考えました。

https://speakerdeck.com/yoshiori/enziniaringu-x-us-hai-wai-tofalsekoraboresiyon

当時のMTGについて

スクラムイベントの固定されたMTGや相談や仕様詰めの時間1on1などもあり、多い週だと1週間で下記のようにMTGが発生している状態でした。

リファインメント: 3時間
朝会(デイリースクラム): 1.5時間(30分×5)
スプリントレビュー: 1時間
スプリントプランニング: 2時間
レトロスペクティブ： 1時間
突発的なMTG: 2時間
横断的なチームビルディング: 1時間
1on1: 1時間(30分×2)

合計で12.5時間程MTGをしており、稼働時間のおよそ3割はMTGをしている状態でした。

目指した状態

理想としてはチームビルディングや1on1など関係性を向上するMTGや障害などの緊急対応以外は非同期に移行していける状態を作ることでした。これは同期が必要なMTG以外はドキュメントで完結することと書くという文化を根付かせたいと考えました。

自分も過去に開発しているなかでMTGでの会話で意思決定したものが多くあり、口頭だけで文章としてはどこにも残っていない状態でした。

今から考えると、MTGをせずともドキュメントでの確認で済む内容もあったかと思います。このようなことをなくしていく意味でも、ドキュメントを書く文化があれば、決定の背景などを今の人が知ることができたなと感じていました。そのような考えから、ドキュメントを書くという文化の醸成を目指したというのもあります。

何を非同期にするか？

これはとても悩みました。悩んだ中でやったのは非同期にしてはいけないMTGを考えました。

ブレストなどの考えを発散するMTG
障害対応などの緊急性が高いMTG
1on1やチームビルディングなどの時間を共有するのが大事なMTG

これ以外を考えたとときに良さそうかなと考えたのが朝会の非同期化でした。朝会は、報告・共有がメインであることから、非同期化するには適していると考えました。報告や共有は議論が発生せず、定型的なやり取りで済むことが多いためです。ただ、相談などのやり取りが発生する会話も朝会で行っていたので、そのあたりは非同期化する際の課題となりそうでしたが、むしろ非同期化の課題として向き合うには程よいレベルのものだと考え直しました。

実際にやった非同期の活動

まずは行なう理由や目指す状態、最初の取り組むべき点をチーム全体に共有し、自分主導で進めました。そのなかで実際にやったことの一部をご紹介します。

Notionを使う

非同期をやるうえでとても重要だったのがNotionを活用することでした。ドキュメントでコミュニケーションを取るうえでドキュメントの書きやすさ・読みやすさに加えてコメントや質問をしやすいかはとても重要でした。そのなかでNotionは書きやすく、Databaseなどを上手く使えば情報の集約や整理などもしやすくリアルタイムでの同時編集も可能なのでドキュメントで会話するのにとても合っていました。

AsanaからNotionへのタスク移行

今まではAsanaでタスクの管理をしていましたが、Notionうえでコミュニケーションを取るうえでも情報はできる限りNotionに集める必要がありました。そのためにAsanaからNotionへのタスク移行しました。幸いNotionはimport機能があったので必要なタスクだけ移行するのはそこまで手間になりませんでした。

朝会記事の作成と運用ルールの作成

朝会を非同期化するために、朝会の内容を書き込む「朝会記事」を作成しました。この記事では、メンバーが日々の報告や連絡を書き込んで、朝会の内容を共有します。具体的な朝会記事の運用ルールとしては以下のようなルールにしました。

朝会開始時刻の10:00~には報告・相談内容を書き終えてる状態にする
12:00までには記事の確認を終えてチェックボックスに✓をつける
相談内容があればメンション付きでコメントする

定期的に振り返リの設定

非同期での共有は慣れておらず課題が多く出る可能性があるため、チームとしてはできる限り早く変化に適応する必要がありました。そのため1週間で課題の収集や改善の実施を行なうことで多くの改善をしていきました。具体的に実施した改善は以下の通りです。

相談がしにくいので相談ルールを決める
予定の把握がしにくいのでカレンダードキュメント内に追加する
Sprintアイテムが見にくいので記事に埋め込む
朝会で確認していた前SprintからのTry（KPTで出た改善内容）を確認する場がなくなり、忘れがちなので記事内の目に付く場所におく

今回の朝会の非同期化を通じて、自分達が朝会という場で多くの確認や共有をしていたことがよくわかりました。

実際に運用した朝会記事の構成

チームの休み・フレックスカレンダー

チームメンバーの休みやフレックス予定がGoogleカレンダーと言ったり来たりだったので、記事上にカレンダーを作成して確認可能にしました。

Try確認

チームが課題を改善していくうえでレトロスペクティブで設定したTryの実施は重要だと考えています。ただ、非同期になると朝会で確認していたTryを確認しなくなり、Tryを忘れる問題が起こってしまいました。このためTryをしっかりNotionのDatabaseで管理し記事に埋め込むことで、自然と確認できるようにしました。

これによりTry実施のオーナーが不在の場合などもチームで気づいて実施するような動きができるようになりました。

タスク進捗確認

スプリントのタスク一覧を表示してそれぞれ進捗や詳細を記載していく場所です。タスクもNotion Databaseで管理しており、今スプリントのタスクを表示しています。メンバーはこれらのタスクの細かい進捗や状況のみを共有してチームの認識をあわせました。

相談内容チェック

記事のなかでどこに相談をかけばいいかや、相談内容を見落とすことなどがあったので相談専用の場所を作成しました。相談内容はNotion Databaseで管理しており、チームが相談事があると投稿して記事内に表示されるようになっています。こちらも完了した相談内容は表示されません。

POレビュー日・リリース日の調整

スプリントのタスクのなかでPO Review日・リリース日に該当するアイテムを表示しています。 BALES CLOUDチームではPO Reviewとリリース日の目標日をPlanningで設定するようにしておりそこを過ぎたものは調整するために使用しています。

ディスカバリーバックログ

PM側の企画の進捗状況を報告します。エンジニア側でもPMの動きを知ることでお互いがサポートできる状態を作っていくためにこのような場所を設けています。

その他共有事項

タスク以外で採用関連だったり、社員共通の連絡事項を共有したりします。

記事の確認チェック

非同期では誰が記事を確認し終えてるかがわからないため記事を読んで確認したらチェックを入れてもらうようにしました。これにより誰が読み終えてるかがわかるようになりました。

非同期化の失敗

非同期化はすべて上手く言ったわけではありませんでした。そのなかで失敗した事例を一部ご紹介します。

問題1: 朝会内容の想定誤り

朝会での当時の想定は左の内容で動き出しましたが現実は右のようにやることがかなり多くありました。

これらを整理するために書き込む場所を分けたり一部をNotionのDatabaseを作成しそちらに移行したりなどを行い解決していきました。

問題2: 必要な情報が集められていなかった

朝会では想定以上の共有事項があったことがわかりましたがこれらの情報を同期のときはただ話すだけではなく共通の画面などを見ながら話していました。これは全員が同じ情報を取得していると考えると、これを補わないとそれぞれが上手く情報を取得してくることを強いることになり、情報量の差でコミュニケーションの齟齬が発生していました。これの解決のために朝会のDocにそれぞれの休みやフレックスを記載するカレンダーやSprintのタスクなどをNotionのDDatabaseからとってきて表示するようにしました。

問題3: 緊急性と発散する内容のコミュニケーション

ドキュメント内の会話のなかで緊急性が高いまたは発散する内容のコミュニケーションの場合はすぐに返答が欲しいときなどがありました。このようなときは別途Slackするのかなどのルールが決まっていなかったので動きにくいとの意見がありました。

この問題から緊急度と会話の発散性によってNotionに書くだけやNotionに書いたうえでSlackするなど用途によって使い分けるようにし、その時のルールとして下記の図のように対応することに決めました。

非同期で得たものと失ったもの

非同期の活動の一部をご紹介しましたがすべてが良かったわけではなく得たものと失ったものがありました。

どちらもやらなければ気づけいない部分もあり、振り返ると挑戦して良かったなと感じています。また、失ったものと書いていますが別の形で解決する手段もあるというのがとてもいい気づきでした。

非同期で得たもの

時間

これは明示的に朝会分の時間増えたことにより、チーム全員が動きやすかったり考える時間ができました。個人的にも時間ができることにより余裕をもって作業を進めることができるようになりました。

考える間

ドキュメントで非同期でやりとりすることによりリアルタイム性は失われましたが 1つ１つの確認事項や相談事項に対してしっかり考えて回答できるようになりました。対面だとその場で答えなければなりませんが、非同期であれば少し調べたりなどしてゆっくり回答ができるようになるのは良い点でした。

情報整理力

非同期のためにはNotionを使用してのドキュメント文化を作る必要がありましたが、その際に前提となる情報や背景をしっかり書くことが求められたのでこれらは自分たちが何を気にしていて最低限どんな情報があれば進めるかを定義できたいい内容でした。

ドキュメントで会話する

これは大きく動きとして変わったところです。今まで自分たちはドキュメントを会議のために作っていましたが、非同期からはドキュメント上で議論するために作っていた。これは書き方や何を話したいかなども整理され、自分たちのコミュニケーションの幅を広げる良い活動になりました。

時間がある価値を認識する

定性的ではありますが、チーム全体として時間ができることによって考える時間や作業時間が増えたという感想があった自分たちが得たのは朝会の時間だけだったが、それでも生産性があがり考える時間を増やすことへの価値はとても高いものだと感じた。

同期で得ていたものを理解する

自分達が同期のコミュニケーションで知らず知らずのうちに人柄を認識したりその日の体調や気分を会話のトーンから情報を得たりなどMTGの役割以上に情報を得ていたことに気づけたのは収穫でした。

議論や質問内容が自然とドキュメントにログとして残る

自分達が非同期化をすることで議論などの内容が残り、当時どのような議論をしていたかなどが検索可能になりました。これにより会議をする ⇒ ドキュメントを書くではなくコミュニケーションをとったものがそのまま残せるようになりました。

非同期で失ったもの

チームで同じ時間共有し過ごす総量

朝会はアイスブレイクしてから自然と話していましたが、同じ時間を共有して同じ情報をもらって雑談することはチームビルディングの一部になっていました。これをなくすことによりチームが共有した同じ時間の総量が減ったことを認識していませんでした。

リアルタイムな返答

実際に緊急対応などは別途MTGの予定を入れるなどしなければ迅速に動けなくなるなど、朝会のおかげでできていたことを補完する動きが必要になりました。

失ったものへのアクション

チームで同じ時間を共有し過ごす総量

朝会がチームビルディングにつながるコミュニケーションを一部補っていたことがわかったので明示的にチームビルディングの時間をとることにしました。あくまでドキュメントでやるのは作業に必要な報告・共有の業務でチームを良くするための活動は別途するという形にすることでチーム感が薄くなったという意見は薄くなりました。