はじめに

こんにちわ！
最近、自身のチームメンバーからも相談があったのですが、
自身の質問のタイミングが遅いことに課題を感じていると思っている人は意外と多いようです。

ここでよくある、
「30分時間が経って、わからなければ質問する」をルールを作って運用する中で、
違和感を感じることがありました。
その違和感について、色々と考えてみました！

結論

先に結論を書きますが、
違和感の正体は「状況の見える化が出来ていない」ことを
「質問が遅い」と言ってしまっているがために、
効果的な対策になっていないのではないかと感じていたことです。

今回は「状況の見える化」をするために
分報(つぶやき報告)を活用できないかという観点でこの記事を書いています。

また、弊社では複数プロジェクトを横断するチームも多く、
分報がなかなか活用されないという課題がありました。
そこで、個人単位ではなくプロジェクト単位で分報チャンネルを作ることで、
分報の活用度が上がったことについても触れてます！

もし、同じような課題を持っていれば、読んでみてください！

違和感について

まず違和感を覚えたところとして、以下の様に考えてました。

本人が課題として質問が遅いと感じているのであれば、
30分考えたら質問をするというルールというのは
少なくとも本人にとっては、
そんな簡単な話じゃないのではないか？と。

これはもしかすると、
「良い仕事をしよう！」とおもっているからこそ、
余計出来なくなるのかもしれないですね。

ちなみに僕はoutput超苦手マンなので、
この記事を書いているときも、
こんなもんで良いかという事ができず、何度も書き直しています。
自分の中の最高の状態でoutputしたくなっちゃうんですよねー。。。

時間経過時点で質問する難しさ(煩わしさ？)

例えば30分考えたらわからなかったら質問するとして、

なんかエラーが出た。

とりあえずエラーで調べて見る
- それっぽい答えが書いているサイトをようやく見つけた！(この時点で、25分経過)
やってみる(60分経過)
- 違った or できなかった。
- 質問する。

なんで、30分で質問していないの？
といわれて、モヤモヤ

みたいなこともよく起こると思っています。

25分経過タイミングで「質問」するとなると
自分ではこれっぽいというの見つけたんだけどなー.となって、
教えてほしいですと、言いづらい状況になっていることもあり、
質問のタイミングをコントロールするのは結構難しい話ではないのかなと。

30分考えたら必ず質問するというのちゃんとやってみると、
今度は質問の質が低いと言われてしまうというような、
ジレンマもあったりするのではないかと思いました。

詰まっているタイミングのステータス変化の目まぐるしさ

「詰まっている」は「詰まっている」でも、
ステータスは頻繁に変わっています。
同じところで、30分詰まっているわけではなく、
10分毎に一歩ずつ進んでいるときって、質問しづらいですよね。
けど実は10分毎に進んでいる一歩がゴールとは全く別の方向を向いていることもあります。

本人にとって、「まだ質問のときじゃない」
質問される側としては「早く質問した方がよいのでは」という状況が出来上がります。

「質問が遅い」のではなく、「状況の見える化が出来ていない」のでは？

おそらくこれは「質問」という言葉を使っているのが問題ではないかと考えました。
「質問が遅い」という言葉で課題を定義していますが、
その課題感はもしかすると、「質問が遅い」ことではなく、
「状況の見える化が出来ていない」ということに感じているのではと。

「状況の見える化が出来ていない」という課題に対して、
質問を早くするという解決策を取った場合に、
質問しづらい状況が生まれ、どうして質問が遅いのだろうと、
悩んでしまうのかもしれませんね。

質問ではなく、
「いまこのエラーが出ていて、ついさっきこれじゃないかという記事を見つけたので、
　一旦ためしてみます！」
と状況を伝えておけば、もし全く違う方向に進んでいた場合は先輩からもフォローできそうですね。

つぶやき(分報、timesチャンネル)の推奨

では、「◯分考えたら、質問 OR 状況を報告する」というルールにすればよいのか
とも思いましたが、報告となると、

結構ちゃんときれいに書かないといけない
間違ってたらだめ。
上長に向け、わかりやすく整理されている必要がある。

のような印象を僕は持ってしまいます。

今回の話は日々の朝会や、進捗確認MTG ”以外”のタイミングで
報告をするというところなので、ちょうど今調べている内容を
無駄なく時系列でうまくまとめて、現在の状況を報告するというのは
時間がかかる、もしくは整理がむずかしいという状況もあると思うのです。

例えば

Aをやっていてエラーが出た。
原因を探っていると、今回の対応箇所でないBの部分が根本原因だと分かった。
修正方法を探っているときに30分経過したので報告する。
本人「今Bをこのように修正しようとしていて、修正方法を調べています！」
先輩「まって、なんでBを修正してるの？」

となってしまうので、
結局のところ、経緯などもまとめる必要が出てきたりします。

また僕の場合、
Aの根本原因がBであるかどうかの確信がない場合は
とりあえず、Bが根本原因かどうかだけでも確かめてから報告しようとしたり。
(思ったよりその確かめるだけがすぐに終わらなかったり・・・)

そこで僕は報告よりもさらに、
つぶやきがもっとも適しているのではないかと思います。
誰かに報告するのではなく、見えるところでつぶやくのです。
つぶやくだけなので、敬語である必要はないし、きれいにまとまっている必要もないです。

こういったつぶやきでの報告を日報ならぬ分報と呼ばれています。
分単位で報告するからですね。

分報についてのやり方などは軽く後述してますが、
具体的には以下を参考にしていただければと思います！
https://hybridwork.cybozu.co.jp/articles/times-lp

つぶやき(分報)での状況共有の例

例えば、

10:00 実行してみた。
あ、以下エラー出た。
とりあえず調査開始する
　　ERROR:hogehogehogehoge…
10:25: https:www.example.com
それっぽい解決策が書いてある修正してみる。
10:40: ↑やってみたけど別のエラーになった。このエラーを調べる。
10:50: https:www.example.com
なんか同じ原因ぽいこと書いてるサイト出てきたけど、
そもそも今回のシステム的には関係ない話な気がする。
けど、一応やってみる。
11:00 やっぱりうまくいかない。他の情報も見てみる。
11:15 よくわからん。

↓

11:20 @上長
お疲れ様です。
先程からエラーが出ていて、上記つぶやきのような形で調査をおこなっていたのですが、
原因特定出来ずでして・・・

みたいなイメージです。

これができていれば、
最初の実行時のエラーから、1時間以上経っていたとしても
「状況の見える化」ができているので、
「質問が遅い！」とは言われないのではないでしょうか。

つぶやき(分報、timesチャンネル)の心理的安全性を高く保つ

つぶやきの心理的安全性を高く保てないと
なかなかつぶやく事ができないという状況が発生してしまうと思います。
そこで、つぶやきは見ている人、発信する人ともに、
以下の共通認識を持つことが大事だと思っています。

ステータスが変わる毎につぶやく。
つぶやきは必ずリアクションを求めているわけではないので、リアクションがなくても問題ない
リアクションが必要な場合はメンションをつけて明確にリアクションを求める
つぶやきは情報整理されていない状態でつぶやかれるものなので、つぶやきの情報自体に気づいたことがあれば、サポートするが、つぶやき自体の文章や、情報整理については指摘しない。
- サポートする側がつぶやいていることを理解しようとするために、質問するのは問題ない。
  - 良い例：◯ hogehogeってfugafugaしてpiyopiyoしたときのことかな？
    悪い例：✗ hogehogeはfugafugaしてpiyopiyoしたときってと書かないと伝わらないよ。

プロジェクトを横断するチームでの分報チャンネルの活用について

弊社では、チーム全員が同じプロジェクトに入っていないということもしばしばあり、
どうしても各メンバーが、それぞれ異なる複数のプロジェクトの掛け持ちという状態が発生します。

私のチームで、メンバーや僕自身も含めて分報チャンネルが
なかなか活用できないという課題を感じています。

メンバーとも会話した結果、

自身のプロジェクトの人たちが見ていないとあんまり意味がないように思える。
関わっているプロジェクトのすべての人を自身の分報チャンネルに参加してもらうと、今つぶやく内容のプロジェクトに関係ない人にも通知が行くのが気になる。
プロジェクトを知らない人に勘違いさせないよう、最低限整理された情報で投稿しようという意識になる。

などなどが分報の活用の障害の一因となっているようです。

そこで、以前私が担当しているプロジェクトで、

実装者のステータスを把握、理解できていない。
実装者間で相談、決定してしまっていた。

という課題が発生したことがあり、
その際にプロジェクト用の分報チャンネルをつくって、そこにつぶやいてもらうことにしました。

そのチャンネルではメンバーが全員参加しており、全員がそのチャンネルでつぶやく様にしました。
全員となると多いと思われるかもですが、
つぶやくのは開発者に限っていて、おおくて5人程度でしたので、
そこまで他の人のつぶやきが邪魔になるみたいなのは起きませんでした。
(これ以上多い場合はもう少し分割してもよいかもですね。)
そして、何か起きたら、つぶやく。というのを続けてもらいました。

チャンネルを見ている人が関係者のみになったというのもあるのか、
個人の分報ではあまり流れなかった、現在の状況というのがつぶやきでリアルタイムで見えるようになり、
いままで、メンバー間の相談で決まっていたことの情報、その経緯も見えるようにもなりました。

その他にも以下のようなメリットが発生したと思っています。

前まで質問はメンションで宛先がついていることが多かったのですが、
まだ質問にするに至らない状態のつぶやきでも、メンバーで分かる人がいればサポートに入ったりと、コミュニケーションの活発化も起こった
朝会の中で進捗を確認するのですが、
分報のつぶやきを見ることで具体的な内容を知ることができた。

結構うまく分報を運用出来た例ではないかなと思っています。
もし、個人の分報チャンネルをつくってはみたものの、
同じような課題を持っている場合は、
プロジェクト毎に分報チャンネルをつくって運用してみてはいかがでしょうか。

余談：リアクションでつぶやく

本題とは関係ないのですが、
質問以外にもつぶやく場面が有効な場面はあると思ってます。
例えば返信とかですが、返信自体に時間がかかるものがあります。
その場合、その人に対して、返信としては書かず、独り言の様に書くという手です。

例えば、

A: 〇〇の△△ってどうなってるんだっけ？
僕：これ、ちゃんと覚えてないけど、△△って✗✗だったような気が。ちょっと見てみます！

「ちょっと見てみます！」は返信として記載していますが、その前の文は完全に独り言です。
なのでたとえ、間違っていても良いのです。
「ちょっと見てみます!」だけでも良いのでは？となるかもしれませんが、
もしかすると、この後に

A: あ、そうだ✗✗だわ！ありがとう！

と返事が来るかもしれません。
独り言であれば正確でない情報でも伝えやすく、
素早く返事がしやすい時もあると思います。

最近この方法でつぶやくパターンは、
X(旧Twitter)の引用リツイートの近い感覚でやっていることに気が付きました。

引用リツイートってリプライとは違って、post主に対して語り掛けるような書き方にはならないですよね。
でも相手には通知が行く。そして鍵垢でない限りは他の人も見る事ができる。
まさにそのイメージで使っているんだなと思いました。

もちろんこの場合も相手とつぶやきである、共通認識ができているとよいとおもいます！
明示的につぶやきであることを記載する場合は、
「自分メモ：今の対応完了後に確認する。」
のように自分に向けてメモをしているようにみせると、
勘違いされるということを避けることができますね。

まとめ

分報については、いろいろなところで目にするので、
エンジニア界隈では割と浸透しているのかなと思っています。

今回は分報(timesチャンネル)の活用法について、
「質問が遅い」という課題に対して、つぶやきで解決出来ないか
という視点でこの記事を書いてみました！

「◯分経ったら質問する」ルールが有効な場合も、もちろんあると思います。
すべての人に同じルールをノータイムで課す前に質問が遅いという課題の本質に対して、
この対策が有効かどうかというところは一旦考えてみても良いかもしれません。

個人で「質問がおそい」ことを課題として感じている場合は、

「質問が遅い」という課題感は「状況が見える化ができていない」という課題感ではないか。
「状況の見える化出来ていない」という課題にたいしてのアプローチを「つぶやく」ことで解決できないか。

というのも考えてみてはいかがでしょうか。

また、複数案件を抱えるチーム内で課題感を感じている場合は

プロジェクトで、分報チャンネルをつくってみる
と各メンバーが自由に投稿のしやすい状況ができるかもです。

以上です！ご一読ありがとうございました！