📝

自分がTimes チャンネルを利用するときに気をつけていること8つ

2024/03/01に公開

Slack での Times チャンネル運用を続けて5〜6年経ちますが、他の人のチャンネルの運用を見ていると「もうちょっとこうしたらよいのになー」と思いつつも、times チャンネルの使い方は人それぞれという思いもあるのでアドバイス的なことは何もしてやり過ごしてきました。

しかし、コツのようなものは共有しておいて誰かの害になることはないだろうし、せっかくなのでここで共有しておきたいと思います。

改めてTimesチャンネルとは

Times チャンネルは「分報」とも呼ばれています。要するに１日単位で作業を報告するのが「日報」であれば、分単位（今現在）の状況を報告するのが「分報」＝「Timesチャンネル」という考え方です。

Times チャンネルのメリットとしては以下のような点があると考えています。

頭の中にある考えを言語化することで、思考が自然に整理される。
今つまづいていることに周りに気づいてもらえる（そして運が良ければサポートしてもらえる）
過去につまづいたことや実施した作業が残っているので、ノウハウとして再利用できる。

個人的には以下のブログ記事を読んだことが Times チャンネルの運用を始めるキッカケでした。

一方 Times チャンネルに否定的な意見をときどき見かけますが、たまたま運がよかったのか、個人的な観測範囲では Times チャンネルが元となったトラブルに遭遇したことはありません。

基本的(?)なルール

あまり明言されてきていないですが、 Times チャンネルは以下が基本ルールとなっているように思います。

Slackチャンネルが相手に見える・見えない関わらずに、誰かを傷つけたり攻撃するようなことは書かない
セキュリティ的に問題ある情報は書かない
政治や宗教に対する個人的な意見は書かない
Times チャンネルへの参加はメンバーの自由であり、決して強制しない

気を付けていること

1.後で見たときに思考の過程を追えるように、思考過程を言葉で書く

Times チャンネルは、なにか有益な情報をアウトプットする場というだけではなく、自分の「今」の気持ち・状況を吐き出して整理したり共有するための場でもあると考えています。

例えば、以下のようなつぶやきをしてたりします。

これからとりかかろうとしている課題
今なんとなく気になっていること
作業中のメモ
なにかに行き詰まっている場合は、そのポイント
etc.

思考過程を書き出すことで、自分の思考を客観的に見つめ直すことができ、思わぬ方向から解決方法がひらめくこともあります。

行動と結果だけではなく、その行動に至った経緯・思考などの内面に関する様子も言語化しておくと、あとから情報をたどるときに役にたつことがあります。

2.「こんなこと書いたらどう思われるだろう？」とは考えない

たとえば、「間違ったことを書いたら無知な人と思われないだろうか？」とか「周りに”こんなことも知らないのか？”とか思われないだろうか？」というような気持ちを捨てて、「わからないのはしょうがない」と開き直るようにしています。

特にリモートだと、わからないことを「わからない」と発信しないと、外からみたときにその人が「わかっているけどやらない」のか「わかっていない」のかわからず接し方に困ってしまい、無駄にストレスを与えることにもなると思っています。（自分がわりとそうです）

はっきり「わからない」と発信することは周りの人のそのストレスを取り除くことにもなるし、周りからのサポートを得られる可能性もあるので自分と周り双方にとってプラスになると思っています。

ちなみに、自分のTimesチャンネルをわからんで検索すると発言が38件ありました。(1年6ヶ月経過時点)

3.実行したコマンドを貼る

手元で何か作業したにはそのコマンドを Slack に貼り付けるようにしています。その理由は。

後日同じ作業をするときにそのままコピペできる。
後で見返すことでオペレーションのミスに気がつくことがある。
チームメンバーに具体的手順を教えるときに、該当スレッドのURLを示すだけで済む。

数ヶ月前に以下の記事を読んで、首がもげるほど同意する気持ちでいっぱいでした。

4.エラーメッセージはテキストを貼る

エラーメッセージについて調べるときは、できるだけそのエラーメッセージをそのままテキストとして貼り付けます。

理由は、後日同じようなエラーメッセージに遭遇したときに検索できるようにするためです。
場合によってはスクショを貼り付けたほうが状況がわかりやすい場合があり、そのときはスクショを貼り付けますが、それとは別にテキストでエラーメッセージを貼り付けるようにしています。

１画面に収まらないくらい長いテキストは、コードブロックではなく Text snippet として貼り付けるようにします。

そうすることでクリックでテキストが開閉できるようになるので、長過ぎるコードブロックによって流れを追いかけづらくなるのを防げます。

5.ソースコードは GitHub の permalink を貼る

コード上で問題の箇所を見つけたり、コードリーディングのメモを取るときには GitHub の permalink を貼るようにしています。

そうすると、Slack 側で GitHub との連携が有効になっていると該当行を Slack 上で確認できるので、GitHub と Slack の間を行き来する手間を減らすことができます。

6.他のチャンネルの話題を引用するときは link を貼る

他のチャンネルの話題を引用する場合や、逆に Times チャンネルに投稿した内容を別のチャンネルで言及する場合には、その文言や画像をコピペするのではなく、その投稿やスレッドの link URL を貼って直接そこに異動できるように導線を設けるようにします。

そうすることで、対象の投稿を検索して探すという二度手間を防ぐことができます。

場合によっては、関連するスレッド同士を行き来できるように双方向にリンクを貼る場合もあります。

7.あとから書いていた内容が間違っていたことに気づいても消さない

Times に思いつくまま投稿していると、あとで見返したときに間違っていたことに気づくことがあります。
このとき、間違った内容を投稿してしまったことが恥ずかしい、あるいは、間違った情報が残ってしまうことに抵抗があるという理由でそれを後から消したりする方もいます。

しかし、個人的にはそのような過去の間違いについて、上書きしたり無かったことして削除することはせず、別の投稿として「それは間違だった」と言及するようにしています。

その理由として、将来同じような間違いを犯す可能性があるからです。未来の自分が同じような間違いを犯そうとしたとき、何がどう間違っていたかというのが分かる状態になっていると、別のもっとよい解決法が後から見つかったりするケースも稀にあります。

8.議論する内容と場所(チャンネル)が適切か意識する

ときに、Timesチャンネルで発した一言がキッカケとなって、現在開発中のアプリケーションの仕様を考え直す必要がでてくるようなケースもあります。そのような場面を認識したらTimesチャンネルでそのまま議論を続けるのではなく、メンバー全員が参加している適切なチャンネルに誘導して議論を続けます。

議論が最後まで終了したあとに気づいたという場合も、議論した内容・結果のサマリと議論の流れを追うためのURLを添えてメンバー全員が参加しているチャンネルに投稿します。

「大前提」に書いたとおり、Timesチャンネルには自分が仕事で関わるメンバー全員がJoinしているわけではありません。また、Joinしているメンバーも全ての投稿に目を通していることを期待してはいけません。

一部の人だけが参加しているチャンネルで一部の人だけで話を進めてしまうと、思いもよらない箇所に影響があることが後でわかって手戻りの原因となったり、重要な決定を行う場から参加させてもらえなかった疎外感などから関係がギクシャクしてしまう、ということにもつながると考えています。

また、リモート特有ですがテキストコミュニケーションではうまく伝えられない状況ということもあり、場合によってはHuddleによる音声や画面共有を交えた通話に移行することもあります。

その場合でも、会話した内容のサマリや決まったことは Slack 上に残すようにしてHuddleでの会話に参加していない人がどのような会話があったのかが追えるようにします。また、そうすることで後でどのような会話があったのかが自分自身でふりかえることもできます。

さいごに

ここ数年　Times　チャンネルを運用していて、意識してやっていることを列挙してみました。

Times チャンネルの運用はコロナ禍に入るちょっと前から行っていましたが、コロナ禍に入り仕事がリモートワーク中心の生活になったことで生活の一部になってしまいました。
そうして Times チャンネルの運用を続ける中で、自分がうまくいったこと・いかなかったことを少しづつ改善して続けてきたことが上記のような事です。

この記事が誰かの参考になったら幸いです。