リブセンスVPoEの中野(etsxxx)です。
私はこれまでWorking Out Loud(WOL)というコミュニケーションスタイルを、所属した2チームで実践してきました。最初のチームでは7年、次のチームでは1年ほど運用しています。
最近、他のチームからも取り入れてみたいと相談されることがあったので、改めてWOLについて振り返りをしてみようと思い、この記事を書いています。
WOLとは？
Working Out Loud(WOL)については、この記事が丁寧で分かりやすく、そして私たちがやっていることはWOLと呼ぶのだと認識した内容となっていますので、まずはこちらをお読みください。
WOLについてすごくざっくり説明すると:
WOLとは、Slackなどのチャットツールに今考えていること、悩んでいること、これからやろうとしていることを、どんどん書き込みながら仕事をするスタイルのことです。乱暴にまとめれば、独り言を奨励するスタイルです。
これはプライベートなTwitterアカウントをイメージしたら分かりやすいでしょうか。実際、私たちは「Tweet歓迎」という表現もしております。
WOLはリモートワークがあたりまえとなった2023年において、とても相性の良い考え方だと私は思っています。
多くのメリットは先ほどの記事に書かれていますのでぜひお読みください。時短のために3行にまとめるなら、以下のような感じでしょうか。
- 仕事の初期段階でフィードバックを受けられ、手戻りが減る
- 思考の過程が記録され、アウトプットの理解の助けとなり、チーム全体の学びにもなる
- チーム外からも適時アドバイスを受けられるようになる
上記の記事にないマネージャーの視点でのメリットも書き足しておきましょう。
WOLを実践するチームには、以下のようなメリットがあります。
- メンバーの状態を把握しやすくなり、進捗確認や育成・サポートがしやすくなる
- ミーティングで情報交換する必要が減り、時短になる
- メンバー相互の協力が増え、自分がマネジメントしたりフォローしたりする必要がどんどん少なくなる
- 情報が時間とセットで記録されるため、振り返りに際して具体的な情報源となる
ここまでメリットを述べましたが、デメリットもあります。それについても経験に基づいてこの記事で振り返っていこうと思います。
予め断り書きをしておきますが、私はWOLを気に入っていますが、どんなチームにもWOLが向いているという気はありません。リブセンスとしてもWOLを実践しているチームは少数派であり、会社として推奨しているとは言いません。私の感覚では、以下のようなチームは、本記事で書いているようなWOLは不向き・チームに合わせた工夫が必要な気がする、と思っています。
- ミーティングや商談など、対面コミュニケーションが多いチーム
- 全員テキストチャットが苦手で、チャットで会話が発生しにくい
- あまりにも人数が多すぎる
- メンバーの得意な自然言語がバラバラで、コンテキストが複雑な会話を把握するのに時間がかかる
この記事は推薦記事ではなく、私およびWOLを実践したチームの経験を振り返り、まとめるものです。
導入の経緯
ここでは歴史的な話をするだけなので、時短する人は読み飛ばしてもらっても大丈夫です。
1チーム目: WOLの原体験
私が最初にWOLを実践したチームはインフラグループで、2015年末頃のことです。当時はリブセンスもリアル出社が普通で、オフィスが複数あるので事業横断部署であるインフラグループはそれぞれのオフィスに散り散りに席を持って仕事をしていました。
そのため、チームメンバーとテキストチャットでコミュニケーションを取るのはごく自然の流れでした。隣の人と話をするときにも、他の人にも伝わるようにテキストで会話するのが自然でした。全く声で会話していない静かな状態から、突然インフラエンジニアたちが爆笑し始めることは、オフィスの日常茶飯事でした。
そんなときなので、やたらと独り言、悩み事をチャットに書き込みまくる文化が生まれてきました。物理的に姿が見えないので、個々人が何をしているか共有する発言も増えていきました。元々チャットしまくるメンバーが多かったこと、チャットをメモのように使うメンバーが多かったこともそれを加速しています。新しいメンバーにもテキストチャットを推奨しました。これが最初のチームでのWOLの始まりです。
このチームでの働き方の片鱗は、以下のブログ記事にも滲み出ています。
qiita.com made.livesense.co.jp
この通り、このとき私たちは何も『導入』はしていません。自然発生の文化でした。そして、WOLという言葉も知りませんでした。後に前述のブログを読んで、「これ俺らがやってることじゃん」という話になり、後から『WOLやってます』と言い始めた形です。
2チーム目: 意図を持って始めたWOL
2022年、私はひょんなことでマッハバイトの開発グループのマネージャーとなり、その際には意図を持ってWOLをチームに導入しました。
この頃はまだコロナ禍であり、フルリモートワークの状況で、コミュニケーションの希薄化が懸念されていた頃です。また、別の理由でチームには暗い雰囲気が蔓延していたため、空気を変え、チームメンバーにマッハバイト開発グループに所属することに自信を持ってもらうために、WOLというスタイルを導入しました。
ちなみに、当時のマッハバイトの開発グループも決して会話が少ないチームではありません。しかし、前述のインフラグループにいた私にとっては物足りなく感じたので、WOLというスタイルを導入したという経緯です。
WOLの導入を振り返る
意図を持ってWOLを導入したマッハバイト開発グループについて、ここではその振り返りをしていきます。以後、このグループおよびこのグループに仕事上関わりあう人々をひっくるめて、単に『チーム』と呼称します。
導入前の課題感
私がチームにジョインした当初、チームに抱いた課題感は以下でした。
- チームメンバーそれぞれが何をやっているのか見えにくい。サイロ化・分業化が進んでいる印象。
- もやもやとした会話が少ない。途中の議論が見えにくく、決定したところから共有がある。
いずれも悪気がないことはとても分かります。チームよりも小さな単位・・・例えば同じプロジェクトに関わる人々で境界を定義し、その小さな単位の外の人の手間を取らせたくない、邪魔をしたくないという善意から来ているのでしょう。実際、以前はチャットが汚れたり気が散るのが嫌だから、「雑談は別のチャンネルでやってほしい」「スレッドを使ってほしい」などの要望をもらったこともありました。
そんな”綺麗なチャット”をするチームに、私は一体感という面で物足りなさを感じました。さらにリモートワークによる孤立の状況が悪影響していることも感じられました。当時は「受託開発感がある」なんて言葉も聞かれていました。
実際にWOL導入初期にやったこと
この課題感の解決法として私は、小さな単位での境界をなくし、会話のハードルをとことん下げ、様々な事柄が未決定の状態で行われる会話量を増やそうと考えました。決定前の様々な情報がどんどん流れ込み、決定までの議論に誰でも入れる混沌とした状態を作りたかったのです。「制御されたカオスを作ろう」と私は言っていました。そのためにやること、それがWOLのスタイルの導入でした。
WOLというと、 times-xxx という個人のチャンネルを作って独り言をいうスタイルを推奨しているところもあります。ですが、私の仕掛けたWOLのスタイルは、1チーム目のインフラグループのスタイル＝1つのチャンネルでWOLをするスタイルです。
チャンネル削減
WOL導入前のチームには、目的別・組織別のチャンネルが多数ありました。エンジニアの関係するチャンネルだけで33チャンネルありました。おそらくプライベートチャンネルもたくさんあったことでしょう。まさにサイロです。
細かく分ける理由もそのメリットも分かりますが、私はWOLのために細かなチャンネルの廃止とまとめを呼びかけました。
最終的には、チームの中心となるチャンネルが1つに定まりました。
これはメールでいうinbox、TwitterでいうHomeを定めた状態です。チャンネルを減らすと、そのチャンネルだけを見れば最新情報が得られるようになります。
さらには、会話を始めるときに困ることも減ります。Slackで誰かと会話を始めるときに、どのチャンネルで話しかけようか悩んだことはありませんか？単一のHomeが決まると、とりあえずそこで話しかけたら良いので、息を吸って吐くような自然な会話の開始となります。
そのシンプルさは、チーム内だけでなく、チーム外にも効きます。他のチームの人が話しかけるときも、そのチャンネルで話しかけたら良いことが認知され、会話しやすくなったという声が増えて行きました。
これだけでチームの会話量は格段に増えていきました。
times-xxx というWOLスタイルを選ばないのは、このような背景からです。
会話量を増やすための行動
チャンネル削減と同時に『Slackチャンネル発言数ランキング社内1位を目指す』とチームに宣言しました。
Slackには統計機能があるため、チャンネルごとの発言数ランキングを見ることができます。このランキングを時々チャンネルに共有するようにして、発言量の目標を示唆していました。統計機能が見られないSlackの場合は、ぜひ、管理者に閲覧権限の解放をお願いしましょう。
ちなみに、このチームはチャンネル統合前は発言場所が散り散りだったので、ランクはかなり低い状態からスタートでした。ライバルとなる社内1位のチャンネルは、以前からWOLを実践しているインフラグループのチャンネルでしたw
その目標達成のために以下のようなことを奨励し続けました。
- 業務に無関係な会話もすること
- 独り言を増やすこと
- 「あー」とか「うー」という書き込みが理想だと伝えること
私ももちろん独り言を増やしましたし、会話に絡むことも意識的に増やしていました。余談ながら、この間も私はインフラグループのチャンネルでも会話しまくってたので、感覚としてはこれまでの2倍発言してる感じでしたw
「あー」とか「うー」とかって何？って思われそうなので、補足しておきますw
チャットに書くときに「誰かに伝わるように書く」のはまだチャットのハードルが高い状態だと私は考えています。理想としては、意味不明な独り言すら書いて、周りが興味を示して質問してから会話が始まる状態です。
このくらいまでチャットに書き込むハードルが下がると、ありとあらゆる思考がチャットに垂れ流されて、他の人が介入する余地が生まれます。まさに問題で詰まる前の早い段階で協力を求める状態、手戻りが少ない状態の実現です。
その状態のテキストは、将来的には「どういう経緯でそれを選んだのか」調べるときに検索可能な資産になるので、一石二鳥だったりします。
最終的にSlackチャンネル発言数ランキング社内1位を取ったのは、6ヶ月ほど経過したときでした。
一人あたりの発言量も3倍以上になっているのは印象的ですね。
その間にチーム外からもチャンネルのフォロワーが増え、時々会話に絡んでくれるような状況が生まれていきました。まさに狙い通りの状態になったと思います。
WOL導入前後の比較
ざっくりと、WOL導入前後の比較をまとめます。
- 会話の始め方
- before: 目的別のチャンネルに書き込む。コミュニケーションしたい相手がいるチャンネルを選ぶ。雑談は雑談専用チャンネルに書く。どこに書くか迷うこともある。
- after: 業務も雑談もどんな話題でも、同じチャンネルに書き込む。内容による区別はないので迷わない。
- 読むのに必要な労力
- before:目的別チャンネルに数件なので見逃さない。同じ話題はスレッドにまとめることを推奨。自分に無関係な話題のスレッドは開かなければ良いので、自分に関係する業務の把握が楽。
- after: ごちゃごちゃと同じチャンネルに書き込まれて、全部読んでいかないと意味が通じないこともある。無関係な話題すら読む必要がある。自分に関係ない業務の会話も強制的に読むことになる。
- 得られる情報量
- before: 読む人の興味次第で取捨選択ができる。あるいは発言者が誰に伝えたいか絞り込む。
- after: 自然と幅広い情報を把握することになる。
WOL導入後の方が時代に逆行、退化している印象を受ける方もいるのではないでしょうか？それについては否定しません。私の仕掛けたWOLのスタイルとは、どちらかと言えばチームに業務と関係のないコミュニケーションを強制し、チームの密な関係性を構築するためのものと言えます。
私が気をつけていたこと
ここでは私がWOL運用で気をつけていたことをまとめます。『私が』であり、チームのルールにしてはいません。
積極的に絡みに行く
誰かが悩みを書き込んでいるときには、わからない内容でも一緒になって会話していました。
些細な発言がその人の助けとなることがありますし、悩んでいる本人も、人に説明をする中で悩みを自己解決する事があるからです。積極的にラバーダックになるということですね。
読み落としを責めない
WOLが根付き始めると、すごい速度でチャンネルにメッセージが流れてきます。会話も異なる話題が入り乱れ始めます。誰でも、読み落とします。
他のコミュニケーションにも通じる話ですが、チャットに書いたことを知らなかった人がいても、責めないように気をつけていました。そのメッセージに何らかの反応がなければ、むしろ伝わってないのが普通というふうに考えていました。そういうこともあるよね、と、寛大に捉えていました。
そうしないと、あなたも読み落として責められることになります。お互いさまでいましょう。
よみおとしたっていいじゃないか、にんげんだもの。
長文をなるべく送らない
めちゃくちゃ更新速度の速いチャンネルに長文が放り込まれると、皆すぐに把握できずに時が停止します。ザ・ワールド。そんなときに、人によっては読んで理解することを後回しにしてしまいます。(経験則)
なるべくするっと理解できる簡潔な文章を心がけていました。
大事なメッセージは目立たせる
大事なメッセージでは、メンションを恐れずに使いました。そうしないと流れてしまいます。
太字とか装飾とか絵文字とかも使いました。あえて長文で書くのもありです。前後にハイフンだけのメッセージを送って区切りを入れたりするのも話の切れ目がわかりやすくなります。コードブロックを使ってまとめを書いたり、ピン留めしたり、リマインダーに仕込んだりするのも効果的に思っています。
スレッドが嫌いなことを言い続ける
ルール化はしたくないので強制はせず、私個人の意見として、スレッドが嫌いなことを明言し続けていました。
理由はシンプルで、スレッド内の発言はスレッド外の人から見えにくいからです。せっかく大声で叫んでも、そこが閉じた部屋の中では声は届きません。何クリックか操作しないとスレッドを読めないのも不便です。せっかくチャンネルをまとめたのに、セミプライベートなチャンネルを作っちゃうのは勿体無いです。発言はなるべく、チャンネルの本線のタイムラインに並べて、多くの人に見えるようにしてほしいのです。
しかし、スレッドにまとまることのメリットは分かるので、要所要所で使うことは大事だと思っています。
スレッドを使わないと、会話は並列で複数の話題が同時進行するようになっていきます。カオスですよね。最初は読みにくいのですが、慣れてくると普通に読めるし、発言者も気をつけるようになりますので、意外と何とかなるというのが経験則です。
集中したい時は、チャットを見ないで良いと伝える
チャンネルの流れが速くなると、Slackを見続けて集中できないことも増えます。チャットツールなので、すぐに反応しないと罪悪感を抱く人もいるでしょう。
そのため、集中したい時は見なくていいとメンバーには伝えています。集中したい時は「集中するのでチャット見ない」ってことを書き込んでもらうようにすると、他のメンバーがその人から反応がないことに疑問を抱かなくなるのでより良いです。
せっかくの非同期コミュニケーションツールなので、リアルタイムを求めないことは大事だと思っています。
WOLをやっていての悩みとデメリット
集中力を削いでしまう
集中しようとしても、チャットが気になってしまいます。ミーティング中にもチャットを見ちゃう、会話しちゃうこともザラです。
面接しているときに笑いを誘う会話が繰り広げられているときは地獄でした。
WOLが苦手な人もいる
WOLがしっくり来なくて、発言が少ない人は一定数必ずいます。会話の最中に割り込むのが苦手な人、独り言の発信が苦手な人、人が多すぎて尻込みする人、色々います。そのため、1on1でSlackで話したいことが話せているか確認するようにしていました。
そんな人たちもコミュニケーションが取りやすいように、ルールや運用を変えられるところは適宜変えるようにしていました。ちなみに私はプライベートチャンネルも禁止してません。そちらで話しかけてくる人もいますし、それで良いと思います。
ちなみに、会話中に「〜が入力しています」が何回も表示されるときは、割り込んでいいよと声をかけるようにしていました。
これまたちなみに、WOLに限った話では全くありませんが、強い言葉を使いがちな人もいると思います。コミュニケーション量が増えるとトラブルの発生確率も増えますので、このような人には別の場所で注意をしておくと良いでしょう。
システム通知を流すかどうか
GitHubの何らかのイベント通知とか、アラートの系統とか、同じチャンネルに流すかどうかはいつも悩むポイントです。
あまりにシステム通知が多いと会話の邪魔になります。でも、まとめることで見逃さないメリット、システム通知から派生して会話が発生するメリットもあります。通知の発生頻度などを考慮して、柔軟にチャンネルを分けるかどうか判断するのが良いと思います。
1日休んだ後の地獄
1日休んでまるっとチャンネルを見ないと、とんでもない量の未読が溜まります。これを後追いしようとすると、午前中が消えたりします。複数の会話が同時進行していてコンテキストが複雑なこともあるので、真剣に読む必要があったりします。
私は未読が貯まることが嫌で、休みの日でもチャンネルを読んでいたりします。
一時期、休んだ人向けに3行まとめを残してあげようってトライアルが行われたこともありましたが、まとめることが難しすぎてすぐに廃れましたｗ
チームメンバーの声
この記事を書く前に匿名のアンケートを取ってみたので、私以外のメンバーの声を紹介しようと思います。
WOLを続けたいか
有効票8
- Yes: 7
- No: 0
- どちらでもない: 1
良かったこと
- 誰が何をやっているのかわかる
- 気軽に発言しやすい
- 口頭だと理解しにくいタイプなので、テキストなのが嬉しい
- リブセンスはドキュメントをきっちり書く文化ではないが、テキストになっていることで暗黙知にならず後から探せる
- 会話の総量が増え、カジュアルに相談が展開されることが増えた
- 問題解決までのスピードが上がった
- リモートワークの昨今で、寂しさを感じにくい
悪かったこと・変えたいこと
- Slackの閲覧時間が激増した
- 集中したい時にメンション以外は無視するようになった
- 情報が埋もれやすい。ピン留めとかドキュメント化を意識したい
- 見逃している情報がありそう
- コンテクストが飛ぶので人によっては追いにくいかも。Slack以外のコミュニケーションも意識したい。
- WOLが苦手な人もいると思うので、フォローが必要と思っている
- 業務と関係ない話題の雑談も増えているので、皆のやる気を削いでいないか心配
アンケートの感想
概ね予想通りの回答でした。どちらかと言うと、チャンネルを統合したWOLのスタイルはやめたいって人もいると思ってましたが、概ね好感だったことに驚いたくらいです。
興味深かったのは、明確に悪影響しているのは、Slackに集中力を削がれているという一点だけだったことです。あとは可能性の心配、他者への配慮の意見でした。他者を気遣える良いチームだな、と思ったことを述べておきます。
悪い点で述べられてる心配ごとはまさにその通りと思っており、だからこそ私のやっているWOLのスタイルはどのチームにもお勧めするわけではない、というところに繋がっています。もしこの記事を参考にWOLを導入しようとするチームがあれば、自分たちにあったスタイルに修正・変更して導入してみてください。
おわりに
私が新チームにジョインして1年という時間が経過したことを契機に、そのチームでの取り組みを記事にまとめてみようと思い立ちました。その1つがこのWOLの取り組みでした。
コロナ禍のリモートワークに各社が試行錯誤していた時期に向いている記事を、オフィス回帰が進んでいるこの時期にアップして、社内外の皆さんに「間が悪いなぁ」と思われていそうには感じますｗ ただ、取り組み始めたばかりの事を記事にするのは憚られますし、うまくいっていない事を「私はこういう意図でこの発言をしているんだ」って記事にするのもどうかなぁという気持ちがあり、一定の結果が出たこの時期になってしまいました。弊社のエンジニア採用広報チームには申し訳ない。
さて、こんなWOLを実践する2チームは、コロナ禍に関係なく今もWOLを実践しています。WOLのメリットはこの記事の中で多く述べたとおりであり、特にテキスト化の恩恵は、時間が経つごとに増していくものだと思っています。
そんなチームに興味があったら、ぜひカジュアルにお話しましょう。
最後に、本記事ではChrome拡張『Slack icons & names masking』に全面的にお世話になりました。今後も利用します、ありがとうございます！
