リモート勤務をするなら、Ramblingsチャンネルを作ろう

• Ramblings（つぶやき）: リモートチームのための個人ジャーナルチャンネル

• リモート勤務のチーム（2〜10人） では、各メンバーの名前を付けた個人用Ramblingsチャンネルをチームのチャットアプリに作成することを勧める
• Ramblingsチャンネルはチーム内の個人ジャーナルまたはマイクロブログのように機能し、チームの会話ルームを散らかさずに自然なコミュニケーションを促す
• 自由に考え、アイデア、日常、フィードバック、旅行写真などを投稿する場として使い、自然にメンバー同士の社会的なつながりを高めることが目的

• チャンネル運用方法

  • 各Ramblingsチャンネルは本人だけがトップレベルの投稿を作成でき、同僚はスレッド（返信）でのみ返答できる
  • すべてのRamblingsチャンネルはチャンネル一覧の下部にある_Ramblings_セクションにまとめ、**基本的にミュート（通知オフ）**にしておく
  • 他のメンバーが必ず読む必要はなく、自然にお互いの考えをのぞける場

• 運用のコツ: 主に週1〜3回ほど、短い更新を自由に書く

  • 現在のプロジェクトに関するアイデア
  • ブログ記事、ニュース記事、ユーザーフィードバックについての考え
  • 「もし〜なら？」型の新しい提案
  • 最近の旅行写真や趣味の共有
  • 問題解決の過程でのラバーダックデバッグ風の独り言の記録

• 実際の運用経験と効果

  • Obsidianチームで2年間実験した結果、**定例会議がなくても『ウォータークーラートーク（オフィスでの雑談）』**の役割を果たし、成功していた
  • 深い集中時間を確保しながら、同僚同士のつながりと創造的なアイデアの交流を自然に促進する
  • Ramblingsを通じて実際に機能アイデア、プロトタイプ、問題解決策など、さまざまな創造的成果が生まれた
  • 年1回のチームのオフラインミーティング以外では、Ramblingsチャンネルがチームの人間的なつながりとして機能し、メンバー間の絆の強化に役立つ

[GN⁺]

Hacker Newsの意見

• 2014年にCloudflareでDDoS対応業務をしていたとき、James（Jog）という同僚と多くの質問をやり取りしながら協業の経験を積んだ。「サーバーにログインする方法」「anycastとは何か」「これはどう対応したのか具体的に説明してほしい」といった質問を繰り返すうちに、こうした会話は新しい社員にも役立つはずだと感じた。オンボーディングに関する悩み、あまり知られていないワークフロー、理論的な概念など、さまざまな話題があった。そこで、こうした質問を社内の公開チャンネルに集め始め、最初は「Marek's Bitching」という名前で、不満や面倒な質問を実名で投げられる場を設けた。次第に多くの同僚が参加するようになり、社内でそれまで他のチャンネルでは扱いにくかった技術トピックや自由な議論、ちょっとした疑問、推測（例: Intelファームウェアのバグ検証）まで自然と集まり、大きな価値を生んだ。その後、名前を「Marek's technical corner」に変え、10年以上にわたって技術文化の中心的な役割を果たしている。このように自由に不平を言い、質問し、議論できる「自分のチャンネル」や、チーム別・拠点別の「rambling/bitching」チャンネルの存在が、組織内のコミュニケーションと成長にとくに役立つことを強調している

  • 自分がそのJames（Jog）本人であると明かす。当時は面白いやり取りが多く、楽しかった。その後、社内に内部ブログ文化もできて、みんなが実験や発見を自然に共有する流れが有益だったという意見を述べている。内部ブログを購読していると本当に学ぶことが多かったという感想
  • 著者の主張は理解できるが、管理者の立場から見ると、特定の個人を中心にしたQ&A形式は検索性や発見性の面で問題があり、新規入社者にその人物がプロジェクトの中心であるかのように見えてしまう点もよくないと考える。質問する場は必要だが、人名ではなくテーマベースのチャンネルへ議論を誘導すべきで、そのほうが効率的だと思う。誰かがランダムなチャンネル（例: #random、#general）で技術的な質問を投げるたびに、いつもプロジェクト別チャンネルへ誘導している。全員に関係する会話や情報は、最も適切なチャンネルに集まるようにする習慣が必要だと強調する
  • 自分たちの組織には自然発生した「Study Hall」というチャンネルがあり、ここでは技術的な質問も自由にでき、批判もないため、チーム内で生産的に運用されている。最も効率的なチャットチャンネルの一つだと感じた経験を共有する
  • 投稿で言及された「Marek's technical corner」は今でも残っており、いまも少しずつ活動が続いていることを知らせる
  • ちなみに、「Marek's technical corner」は今もなお存続しており、ときどき活発に使われている事実に触れている

• 投稿を読んで、リモートワーク環境では自発的な「rambling」の重要性を勧めたい。毎朝1時間ほど散歩して個人の時間を持つことは、通勤と家との境界を作ること、日課としての運動、散歩中に浮かぶ考えなどの点で価値が大きいと強調する

  • 子どもを学校へ送る時間が、実質的に似た役割を果たしていると感じる。可能なときは娘と一緒に犬の散歩をしながらバス停まで行き、以前は保育園まで往復45分歩いていた経験を語る
  • 完全リモートで働いていると、ときどき「なぜ自分は子どもの迎えに行かないのか、体調が悪いのでただ休むと連絡が途切れることもないし、渋滞で遅れることもないし、雑多な事情でいつも早く上がることもない」と自責してしまうことがある。どれも合理的な理由になりうるが、こういう話を毎日聞いているとおかしくもある。実際には自分は仕事に満足しており、べつに怠けて働きたいわけでもない
  • この方法が本当に効果があることを、自分の経験で証明できる。家で不安になったとき、30分ほど近所の公園を歩くだけで気分がずっと良くなる。どれだけ歩くかは問題ではなく、歩くこと自体から得られる解放感が大きいと強調する
  • 一日の中で最高の時間は、10時ごろに麦わら帽子をかぶり、服を脱いで近所を散歩しながら全身で日差しを浴びる時間だ。スマホも持たずに歩く自由さが本当に心地よい

• 自分も他のコメント投稿者たちに共感する部分はあるが、任意の「rambling」を公式に割り当てる方式は、むしろディストピア的だと感じる立場だ。こうしたチャンネルや場は自然に自生するのが最善で、思いついた瞬間に適切な同僚へ共有し、そこからグループチャットが徐々に大きくなり、さらに重要な話はチーム全体へ広がっていくものだと思う。こうした議論自体は健全で、リモートチームに必須かもしれないが、各チームが自律的にコミュニケーションの仕方を作っていくべきだと信じている。人為的な制度化は必要ないと見る

  • 「今週あなたは15回雑談しましたね」「最低が15回なんですよね？」「ええ、それが最低です。でもToddはもう37回も吐き出してますよ」「37回を本当に望んでいたなら、その数字を最低基準にすればよかったのでは？」という冗談で、量的基準を設けたときに起こりうる副作用を機知に富んで指摘している
  • この種の「センセーショナルなキャリア助言」は、意図が善意でも誇張や誤解を招きうることを経験的に共有する。しばしばジュニアが文章どおりに実践へ移すため、同僚やマネージャーがかえって混乱する場面も見てきた。だから自分のようなマネージャーは、Redditなどでこうした投稿が回ってきたときにざっと読んでおき、もしチームメンバーの誰かが急にそうした行動を始めても、その背景をすぐ把握して事前に状況を収める助けにしていた
  • 「チャンネル」という形はランダムすぎてあまり好きではない。以前の会社ではConfluenceで「Personal Space」を作って個人ブログのように考えを整理しており、今も新しい会社でそのやり方を続けている。コードのリファクタリングなど大きな決定を前に、英語で先に考えをまとめると、コーディングだけに没頭するよりはるかに明確になる。チームメンバーに自分の計画を共有し、フィードバックをもらうこともできる。また、新しいアルゴリズムや分析方法を考えるときには、LaTeX数式対応のブログソフトウェアを使ってアイデアを正式な数学表記に落とし込むことがあるが、英語で整理して数式へ移す過程で、誤りや誤った前提にも早めに気づける。このように半公開の場所へ文章を載せることが、ミスを減らし、考えをより構造化するのに大いに役立つと思う。組織全体のうち数人しか読まなくても構わないし、公開ボタンを押す前に十分考える時間を確保できるので、「思考の垂れ流し」より実質的に役立つアイデアを作れる
  • もしこうした活動が「雑談を割り当てられること」や「成果指標」になってしまうなら本当に最悪だという点に同意する。Obsidianでの事例は自然に思いついた実践であり、小さなチームとフラットな構造だったから可能だった。そして、投稿に「チャンネルは基本的にミュート状態で、誰にも読むことを強いない」と明記されている点のほうが重要だという意見
  • この文章には義務や強制、割り当てがあるとはまったく書かれていないと主張する。むしろ問題は、これほど価値の高い非公式チャンネルが「ほとんど決して」自然発生しないことだという

• 「雑談」チャンネルが普通のオフィスのウォータークーラートークに相当するという話に共感する。ただ現実には、多くのチームはすでに毎日の定例会議が予定に入っているため、雑談チャンネルが自然な必要から生まれるのではなく、「仕事上やるべきことがもう一つ増えた」と感じられる危険が大きく、実際にはうまく機能しない

  • 自分は雑談チャンネルを直接使ったことはないが、日常的にはかなり「雑談」をしている。むしろ一番面倒なのは定例ミーティングだ。デイリーのような会議では新しい内容はほとんどなく、すでに知っている話を繰り返すだけで時間の無駄になる。日常的に話すべきことは会議を待たずにすぐ共有する。また、非公式の集まりではスクラムマスターが「それは別のところでやろう」とアイデアの芽を摘まないので、自由な議論ができる
  • チームが自ら社会的相互作用の必要性を自覚してはじめて、この種のチャンネルに意味が出るかどうかは、チームの成熟度にかかっている。定例会議がそのままウォータークーラートークになるわけではないので、会議があっても自然な社会的交流を恋しく感じることは避けられない
  • 自分たちの完全分散チームでは、週2回、15〜30分間、仕事の話をしない「雑談ミーティング」を予定に入れている。これは非常に効果が大きいと感じる。Slackにも別の雑談チャンネルを維持しており、ほぼ一日中活発だ
  • コロナ以後にリモート企業で働いたが、毎日会議があっても雑談用の場が別にあるのは、むしろ良いアイデアだと感じる。自分たちはたいてい会議ではできるだけ話題を絞るようにしている
  • 最近は一日の30〜50%を会議に使っているので、誰かがいつも「それは別で話そう」「後でまた議論しよう」と繰り返している

• 自分たちのチームも気づかないうちに自然と別の「rambling」チャットルームを作っていた。メインのグループチャットでは「あまり賢くない」質問をしたり、不満を書いたりするのが気まずいため、マネージャーのいない第2のチャットルームを作り、見た目には何の問題もない些細な質問、答えを思い出せない手順、少しプロらしくない愚痴、サービス・ツール・プロセスへの即興的な批判など、本音を吐き出せるようにしている。メインチャットでは質問が解決されると、その後の会話は散漫だとして止められるが、この部屋では誰にも邪魔されず自由に入って話せる点が一番良い。こうした空間はチームに必須だと感じる

  • あえて「ばかげた質問」をよくする理由は、いつも誰かが空気を読んで言い出せない場合があるからであり、それがより深い議論につながることもあるためだ

• 懐疑的な立場として、こうしたチャンネルは結局読むものを増やすだけで、「チームコミュニケーションがうまくいっている」という印象だけが残ると考える。リモートチームの社会的結束を作ろうとする努力は良いが、自分にとって大きなストレスになる「チームコミュニケーションチェック」と混ぜるのは好ましくないと思う

  • ただし投稿では「チャンネルはミュートし、参加も期待しない」と明記されている点を指摘する
  • Slackの未読メッセージを、歯を磨いているときやティーメーカーを待っているときにさっと読むのが趣味だ。仕事をしたくないときには、「to-do」か「done/ignore」で素早く処理する、ある種の「仕事版Tinder」のように使っている
  • 本当にSlackでインボックスゼロを保っているのか気になる。それ自体が別の仕事になりそうな気がする

• ある種のリーダーは、チーム内コミュニケーションが自分の統制外にあると脅威を感じることがある。こうしたリーダーの下では、Slackのような場所で思いつきの意見を出すと、「協調を乱す人」や「注意散漫な人材」とレッテルを貼られかねない。実際には皆、ひらめきやアイデアを共有しているだけなのに、会社や文化によっては自由に会話すること自体が危険になりうる。そういうリーダーほどリモート環境に弱く、ひどい場合はSlackのDMまで検索して「問題人物」を探そうとする。可能ならこうした組織は早めに離れたほうがいいが、現実には簡単ではない

  • 自分の経験でも、公の場で質問したり問題提起したりすると、「ヒエラルキー」が極端に強い場所ではリーダーたちが神経質にそれを嫌い、活発にコミュニケーションする人を「問題児」扱いしていたと感じる。自分は後輩の手本になりたくて、わざとたくさん質問し、たくさん話し、リーダーが嫌う行動をより頻繁にした。その結果解雇されたが、その後はむしろ安堵と誇りを感じた
  • 前職では、マネージャーが人々のチャット、メール、その他のアカウントまでMITMソフトウェアやSSL stripなどさまざまな方法で密かに監視し、それを社内政治に利用していた事例を経験した。IT担当者にも必要な情報のフィードバックをもらい、自分が見たものが事実だと確認した。管理者は依頼すれば他人のメールまで閲覧でき、会話ログも簡単に収集していた。別の有名企業でも、チャット内容が原因で解雇された知人の事例を聞いたことがある。会社がソフトウェア、機器、ネットワークを提供しているなら、一言一句に慎重であるべきだという教訓だ
  • 「書き残すこと」は、ニュアンスや意味がより強く残り、いつでも監視されうるという点で、オフラインの会話よりはるかに気を遣う部分がある。実際、直接会ったときなら気まずい話もできるが、メッセンジャーやメールは一度残すと記録がずっと残るので負担が大きい。これは必ずしも「統制欲の強いCEO」に限らず、もっと一般的な感情のように思える

• 全体としてタイトルには同意するが、具体的な実践方法は自分の好みではない。最も適切なチャンネル群（チーム別、プロジェクト別、マネージャー別など）を一つ選んで、そこですぐ会話を始めればいいと思う。忙しいチャンネルは自然と独自のコミュニケーション文化を作るもので、仕事の話と一緒に、犬の散歩中に見つけた面白い物の写真も自由に混ぜられる。「スレッド」機能があるので管理もしやすい

  • 「スレッド」がその役割を本当によく果たしている。別のチャンネルを増やしすぎるのは、かえって混乱を招く。これは昔、小規模な会社でスレッド機能がなかった時代の習慣だと思う

• このやり方が、既存のオフトピックチャンネル（#generalなど）と何が違うのか気になる。特に2〜10人ほどの小規模組織なら、複数の「rambling」チャンネルを作らなくても、一つのオフトピックチャンネルで十分だと思う

  • 「Claude Codeを待っている間」という表現が、「コンパイル中の暇つぶし」という概念の新しい版のようで面白いと述べる
  • 実際には、2〜10個の個人別チャンネルに1〜3件ずつ投稿があるほうが、一か所に30件集まるより、むしろ管理しやすい。「何か重要なものを見落としているのではないか」という不安が減る。自分たちのチームにもオフトピックチャンネルはあるが、それぞれのramblingチャンネルのほうがもっと活発に使われている。既存の会話がもつれる危険も少なく、それぞれの思考の連続性もよく保たれる
  • むしろ、単一のオフトピックチャンネル一つに全員の会話を誘導するほうが、小規模チームでない限り負担はずっと少ないだろうという意見
  • 実質的にはSlackの#generalがこの役割を果たしているのではないか、という見方もある