nunulkのプログラミング徒然日記

毎日暇なのでプログラミングの話題について書きたいことがあれば書いていきます。

Slack の times チャンネルについて思うこと

はじめに

この記事について

X を見ていたら Slack の times チャンネル(分報)の話題で盛り上がっていて、はてブでも関連記事を読んでブコメしたりしたんですが、いくつか思うところがあったので、記事にしておきます。

times チャンネル(分報)とは

まず前提として、suin さんのこちらの記事が初出と思われるので、リンクを張っておきます。

Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 〜Problemが10分で解決するチャットを作ろう〜 - 株式会社クラフトマンソフトウェア

課題解決へのアクションが遅れてしまうという日報の弱点を克服するために、僕のチームでは「分報」という独自の取り組みをしている。

つまり、分報は日報のさらにタイムスパンの短いバージョンということです。

分報、ということなら Slack 以外でもやりようはあると思うので、本記事では主に times チャンネルについて書きます。というのは、私は、分報という仕組み(制度?)は素晴らしいと思うものの、それを Slack で運用しようとすると恩恵より弊害が大きいなと感じてやめた経緯があるからです。

分報の目的と効果

前述のとおり、課題解決へのアクションを最短にしよう、というのが分報の目的です。なので、素早く課題解決できる、というのが効果になり、それ以外はおまけだと思っています。

週報は言わずもがな、日報ですらも、課題解決のためのツールとしてはスピードが遅い、というのは個人的には賛同しますが、それでも、忙しいマネジャーであれば、1日の業務の終りにやっと少しのまとまった時間が取れる、みたいなこともあると思うので(そこまで忙しいのはマネジャーの能力としてそれはそれでどうなんだ、という気もしますが)、日報ならまぁいっかと思います。

とはいえ、ソフトウェア開発のチームであれば、朝会(デイリースタンドアップ)をやってるところも多いでしょうし、テキストによる日報の代わりに口頭で報告する形式が一般的かと思います。

たとえばスクラム開発におけるデイリースクラムでは、以下の3つを報告すると定めています。

  1. 昨日何に取り組んだか?
  2. 今日は何に取り組んでいるか?
  3. 障害となっている課題は何か?

デイリースクラムの目的は、チームがスプリント内のタスクを予定どおり終えるための調整で、各メンバーがその日一日にやり遂げることを明確にする、進捗に遅れがあれば遅れの原因を取り除く、ということを日次でやるわけです。

大事なポイントとしては、これは上司と部下のコミュニケーションではなく、チーム全体のコミュニケーションということです。週報や日報は、部下が上司に提出するもの、という扱いになっている組織が多いと思いますが(自分はもう何年もそういう文化の会社では働いていないので現代の一般的なスタイルがどうなっているかはよく分かりませんが)、これだと、情報の流通が制限されるので、仮にメンバーの中に課題解決の策を持っている人がいても、情報を持たないためにそこに関与できないという問題があります。なので、情報はできる限りオープンにして、解決策を持っている人がそれを提供できるようにしなければなりません。

上記3つのようなことをリアルタイムに書く場所があれば、分報は成立します。「Slack 以外でもやりようはある」と書きましたが、現状では Slack などのチャットツールが最適で、タスクに着手するときに「これから◯◯に取り組みます」、完了したら「◯◯を完了しました」、詰まったときに「◯◯のために詰まっています」と書き込むことで、リアルタイムかつ非同期にデイリースタンドアップのようなことができるわけです。

times チャンネルの恩恵と弊害

しかし、冒頭に上げた suin さんの記事に書かれている言葉を借りると、times チャンネルは「個室」です。個人的にはこれが諸悪の根源だと思っていて、人は個室を与えられると悪いことをするものです(主語がでかい)。times チャンネルはタバコ部屋じゃないか、という意見もあります。

タバコ部屋を知らない若い人のためにいちおう解説しておくと、昔は喫煙者が多かったので、会議のあとにみんなタバコを吸いに喫煙所に行くんですが、そこで会議の続きをやり、会議で決めたことをひっくり返すとか、会議で議題に出てないことをそこで決めたりとか、いってみれば非公式に意思決定をしちゃって、非喫煙者(少数派)がその意思決定に加われず、最悪知らされない、みたいな問題があって(こうやって言葉にすると大問題なんですが昔はよくありました笑)、そういう非公式な意思決定に至る議論を「タバコ部屋の議論」と揶揄しているわけです。なんのための会議なんだよ、と。

閑話休題

times チャンネルの使い方は会社や人によって様々で、目的が明文化されていて、それに従っているなら問題ないですし、自由に使ってどうぞ、というポリシーなのであれば、当然問題ないわけですが、それで治安が悪くなってしまうと、やっぱりやめましょうか、という流れになるので、難しいなぁと思うわけです。

times チャンネルがもたらす恩恵としては、

  1. 問題解決を即時に行える
  2. 雑談する場を提供できる
  3. ラバーダッキングできる

あたりだと思っています。

1 は上に書いた分報の目的に合致するのでメインの恩恵です。とくにジュニアの人が、詰まっていることを相談したいけどみんな忙しそうなので躊躇われるが、times チャンネルに書くのであれば心理的障壁が低いので書きやすい、みたいなときに有効かと思います。しかし、それよりももっと大きな恩恵があって、当人は問題と捉えていないが、別の人から見ると問題である、みたいなことがあったときそれに気づけるというのがあります。とくに私はフリーランスなので、業務委託で新しい現場に入ったとき、最初の3ヶ月くらいはどこでもこういう状態になります。プロダクトやチームへの理解度が低いと起こります。もちろん、できるだけはやくキャッチアップするためにドキュメントやソースコードを読むわけですが、それだけでは足りない部分も多く、times チャンネルにだらだらと書いたのを、古参の人に拾ってもらえたりするとめちゃくちゃ助かるわけです。

2 は雑談が職務遂行上必要かどうか人によって価値観が異なるかとも思いますが、やりたい人はやればいいし、やりたくない人はやらなくていいので、ほしい人に提供できるという点ではメリットになるでしょう。

個人的には 3 がいちばん大きくて、もともとのラバーダッキングは声に出して思考を整理する方法ですが、声よりは文字のほうがより効果が高いと感じていて、その点では Slack が最適と感じます。ラバーダッキングだけなら自分宛ての DM とか、最近だと ChatGPT を使うとか、もっというとローカルのテキストファイルでいいわけですが、times チャンネルを使えば、ラバーダッキングをしながら同時に 1 で挙げた「自分は問題と捉えていないが、別の人から見ると問題である」みたいなことに気づけることもあって、恩恵は大きいと感じます。

しかしながら弊害もあって、

  1. 問題解決が半密室で行われるため、times チャンネルにいない人に共有されずに進んでしまう
  2. ノイズの割合が増えてくるとミュートすることになり、恩恵が受けられなくなる
  3. 愚痴を書く人が多くなると治安が悪くなる

1 は、いわゆるタバコ部屋。基本的に times チャンネルは全員が見てなくてもいい前提で設計されていると思うので、問題解決のスピードが上がるメリットよりも情報が閉じることのデメリットが上回ると感じます。

2 は、仕事に関係ないニュース記事のリンクを大量に貼る人や、仕事に関係ないボットで遊んでる人なんかはノイズが多いと感じて、ミュートしてしまいます。無関係なことしか書かない人なら問題ないんですが、たまに仕事のことを書く人が困るんですよね。とくにジュニアの人がそれをすると、恩恵が受けられなくなる恐れがあります。私は、手の空いたときたまに見に行くようにしているので、多少タイムラグは出るものの、課題解決に一役買うことはできるんですが、人によってはそこまでやってられるかって思う人もいるでしょう。

3は、個人的にはこれがいちばん大きいと感じているんですが、組織に問題があるとどうしてもネガティブなことを書きたくなります。もちろん、課題解決を目指して書くわけですが、チームの大半は無関心あるいは現状維持を望んでいて、賛同してくれる少数の人たちだけで議論してしまい、結果的にチーム全体に波及せず、愚痴のような格好になって議論も中途半端、結果も出ない、残ったのは対立だけ、みたいなことがありました。このような組織の課題解決は時間がかかっても同期的に集まってやるほうがいいと思います。

ではどうすればいいか

現時点での個人的な結論なんですが、いまのところは以下のような感じに落ち着いています。

  1. times チャンネルは使わない(用意されても使わない、他の人のは1日2回くらいの頻度で巡回するにとどめる)
  2. 質問があればチームのチャンネルでする
  3. ラバーダッキングは DM でする
  4. 意思決定が times チャンネルで行われているのを見つけたら、チームのチャンネルでやってほしいと伝える

times 文化は好きで、雑談もしたいんですが、タイミングだったり内容だったりが合うことが割合的に高くないので、巡回頻度を落とすとタイムリーに話題についていけなくなり、必然的に雑談ができない状態になります。これはまぁ仕方ないですね。

課題解決については、タイムラグがあっても、もし times に解決できてない問題が放置されていて、それについてなにかコメントできる情報を自分が持っていれば、見に行ったタイミングでコメントすることはしようと思っています。

問題は、課題解決の場がどこにも用意されてない場合で、こちらから頼んで用意してもらえる(または参加させてもらえる)のであればいいんですが、業務委託が社員のグループと隔離され、情報も流れてこなければ意思決定の場に参加もできない、みたいな組織の場合どうしようもないので、間違ってそういうところに入ってしまった場合には諦めて契約更新しない、という選択を取るしかないかな、と思っています。あるていどは参画前の面談などで掴めるものの、入ってみないと実際のところは分からないこともあるので、難しいです。

おわりに

いくつかの組織で times チャンネルを使って、恩恵よりは弊害が大きいと感じたので上のような結論に至ってはいますが、うまくやっている(やれそうな)ところに入ったときにはもしかしたら使うかもしれません、いまのところはあんまりうまくやれるイメージができてないですが。

車の運転でもスピードを上げると比例して操作も難しくなるのと同様、ましてやそれをチームでやるとなると相当のスキルが求められると感じますし、問題解決のスピードと times チャンネルをうまく扱うスキルとのバランスを考えたとき、いまの自分のスキルでは扱えないというのが現時点での結論です。

個人的には、上に書いたようにデイリースタンドアップのような役割を期待してるんですが、それを他人にも求めるのは違うと思いますし、仮にそれができたとしても、タバコ部屋問題みたいなのはどうしても起こるので、ここまで書いてきて改めて難しいなぁと感じました。

理想的には、全員が同じ目的意識を持って、同じような運用方法ができるといいんだけど、と思いつつ、チームが人の集まりである以上、どうしてもブレは生じるので、そこを目指すのではなく、個々人がやりたいようにやってもなおチームの成果が出せるように、試行錯誤を続けるしかないな、という心境です。