非同期コミュニケーションの難しさ
はい、kameiです。 yykamei's Podcastをやっていきます。今回のトピックは、非同期コミュニケーションは人類には早すぎる、です。
風邪をひいてしまいました。 昨日、アジャイルチームによる目標づくりガイドブック20分ダイジェストとOSTというイベントが
クリエーションラインさんのところで開催されていて、本当は参加予定だったんですけど、なくなくキャンセルせざるを得ませんでした。
これめちゃくちゃ行きたかったんですよね。 アジャイルチームによる目標づくりガイドブックという本が出まして、小田中さんが書かれたやつですね。
これを持ってサインでもしてもらおうかなって思ってたんですけど、いけなくて残念ですね。この本買ったんですけど、実は予約もしてたことをすっかり忘れて、
Xかなんかでこれが発売されましたみたいなのを見て、そうか、すれば買わなきゃなって言って予約してたことを忘れて買っちゃって、その後に予約してたやつが届いて、
今この本2冊あるんですよね。2冊あってちょうどいいから、1冊サインでもらえばいいんじゃないかなって思ってたんですけど、残念ですね。
おかさわらさんっていう人がいて、私の元上司なんですけど、彼も参加してたみたいで、確かに寄稿していて、Xを今日とか見てみるとサインしたみたいなのが書いてあって、いいなって思ってますね。
ということで、今日は非同期コミュニケーションですね。
非同期のコミュニケーションの難しさを感じることが2つありまして、1つは非同期のSlackでの議論、もう1つが非同期のGitHubでのコードレビューですね。
まず非同期のSlackでの議論についてですね。Slackでの議論って結構頻繁に発生すると思うし、予定外というか急に発生するし、思いもかけないタイミングで発生するんですよね。
もうやめた方がいいって思ってますね。やめるのは難しいと思うんですけど、できれば長引かせない方がいいなとは思っています。
なんでそう思うかというと、非同期コミュニケーションって終わりがないんですよね。
終わりがなくて、いつまでもそのコンテキストを引きずってずるずる議論が伸びると。とにかく伸びると。
だんだん本質からずれていって、そういえばこれこうなんでしたっけみたいなのが出てきたりして、
あとはSlackって比較的パブリック、いろんな人が一応入れる状態になっているのであれば、
さらに別のメンバーが入っていって、話が行って、やっぱり本質からずれがちだと思うんですよね。
別に途中で入った人が悪いってわけじゃなくて、どうしてもいろんな人が加わることによって本質から外れると思ってるんですよと。
それでいいのかもしれないんですけど、個人的にはもやもやすぎますね。
あと、これ良くないと思っているのが、テキストに残っているからいいじゃんっていう意見ってありますよね。
テキストに残っているからいいじゃんっていうので、小籍代わりになるみたいな。
それはそうかもしれないんですけど、でもそれを免財布にして、その議論が始まったSlackのスレッドのURLだけ出してここで話しました。
例えばそれでGitHubでプルリクエストとかでこれみたいな感じでやるわけですよ。
それを見てめちゃくちゃスレッドが長すぎて、結局じゃあなんでこのプルリクに至ったのみたいなのがよく分からなかったりするんですよね。
本当に意外と一旦言わないは残るかもしれないですけど、サクッという結論にはたどり着けないですよね。
そもそもSlackって多分フロー型のコミュニケーションツールって言われていると思うので、そんなに小籍みたいに言われても困るよなみたいな。
それだったら普通にミーティングして議事録取った方がいいんじゃないかっていう感じはしますよね。
そういえば前職でもSlackでのコミュニケーションって発生して、圧倒的な量のスレッドっていうのが結構起こるんですよね。
それに圧倒されて結構いつもイライラしていたなっていうのは思い出すわけですよ。
イライラする理由はまずそのSlackのスレッド全部読まなきゃいけないっていうことだし、
あと読んでも時間に追われてるからそんなに精査するように読むってことですよね。
できるわけないので結局あんまりよくわかんないなみたいな感じになってイライラしてましたね。
当時は本当にそのイライラをうまく言語化できなかったんですけど、今ようやくわかりましたね。
非同期でのコミュニケーションはとにかくスループットが長い。結論になかなかたどり着かない。
途中から議論に加わろうと思ってもそこまでの流れのコンテキストがあるのでなかなか議論には参加できないでしょう。
最初に見てるだけになっちゃうと。
結論としては長いコミュニケーションになるんだったらサクッと同期的にやった方がいいし、
というかスラックのスレッドでそれだけ長くやれるってことはお前ら暇じゃねえかっていうことだと思うんですよね。
だったらさっさとハドル開けっていうことなんじゃないかなって思うわけですよね。
コードレビューの問題点
あとコードレビューですね。ギターでのコードレビューの話。
これはもう本当によく言われてることかなというか、私も去年口頭でのレビューにした方がいいんじゃないのみたいな話を登壇したことあるんですけど、
改めて本当にそうだなって思った次第です。
GitHubのツールの問題なのかどうなのかわかんないですけど、コードレビューって簡単に環状面の問題に行き着くんですよね。
というのも変更を行ったオーサーというのがいて、あとはそのレビューするレビュアーというのがいるんですよね。
なんかもうこの時点で二項対立じゃないですかっていう感じで。
さらに二項対立なだけじゃなくて、変更を行っているオーサーってもう書いた時点で良いと思ってるんですよ。
良かれと思っているわけですよね。
それに対してこれはこうなんじゃないのっていう時点でもうバトルの構図になるのは避けられないんですよ。
そこを大人同士だったらオーサーは気に入らないって思っててもしょうがないなって言ってやることもあるし、
レビュアーも気に入らないって思ってても向こうがすごい激しく主張するからしょうがないなって言ってやるみたいな。
もちろんオーサーの変更があまりにも要求から逸脱しているとか、セキュリティ上の問題があるだとか、
そもそもこれやったらバグになるよねみたいなのだったら絶対にレビュアーは止めないといけないんですけど、
割とそうじゃないレビューってよくあると思っていて、
むしろその明らかなバグ、明らかな要求逸脱みたいなコードが書かれることってそんなにないと思うんですよね。
それはチームとか組織の成熟度によると思うんですけど。
前職はどちらかというとそんなに、あんまり言いたくはないですけど、今の組織よりは成熟はしてないとは思うんですけど、
でもそういったところでもそんなに逸脱しているコードってのなかったと思うんですよね。
そういう状況にもかかわらず、レビュアーとレビューイーでバトルが起きる理由って、
やっぱりもう好みの問題だとか、スタンスの違いとか流派の違いみたいなところに行き着くわけですよね。
どうしてもバトルになるのは避けられない。コードレビューはもうそういう宿命なんじゃないかなって思うんですよね。
ひどきコミュニケーションは、さっきのスラックのところでも言った通り、スループットが超長いっていう特性もあるので、
バトルの構図になるとどうしても負の感情を抱えて、スループットが長い上に負の感情を抱える時間も長くなって、
これは本当に人間性に欠けますよね。XPの価値にあるやつですよ、人間性。
これが損なわれるから本当に良くないなと。
コードレビューの中でのひどきコミュニケーションで、じゃあお互いの中間を取ってここは度胸するのはどうかみたいなことを片方が言っても、
それは結局大阪あるいはレビュアに対する挑戦になっちゃって、どうしても接中案を取りづらいんですよね。
そういう時ってじゃあ第三者が入ればいいんじゃないかってなるんですけど、議論がヒートアップしている時って第三者入りづらくないですか?というか無理なんですよね。
あんまりやめた方がいいぐらいのんですよね。
そんな感じで結局コードレビューもひどきでやるのは非常に大変だなっていうところで、
さっき挙げた通り、去年私が登壇した口頭でのレビューがいいんじゃないかというところに行き着くわけですね。
議論の未来への提案
今日の出来事について言えば、私がそこを察知して口頭でやりましょうよって言えればよかったんですけど、そこを失敗してしまいました。
そんな感じでやっていくと、ひどきでの議論とかコードレビューとか、とにかくひどきのコミュニケーションっていうのは私は人類に早すぎるんじゃないかなって思っちゃうわけですよね。
GitLabっていう会社がそこを究極に突き詰めていったようですけど、それはそういう組織もあるのかもしれないですけど、
同じタイムゾーンで生きてたら別にひどきでやる必要なくないですかっていう感じはあるんですよね。
もちろんひどきでのコミュニケーションを全部なくせとかそういうわけではないんですけど、特に議論みたいな、コードレビューもある意味議論だと思っていて、
そういうのって頻繁にピンポンゲームが行われたら、もうそれって同期的なコミュニケーションとほぼ変わらないから、
だったら口頭で喋ってサクッと結論書いて終わりみたいにした方がいいんじゃないかなって思う今日の出来事ですね。
ということで今回は、ひどきのコミュニケーションは人類には早すぎるということで終わりたいと思います。
それではまた。
