$shibayu36->blog;

クラスター株式会社のソフトウェアエンジニアです。エンジニアリングや読書などについて書いています。

改善提案の議論をテキストで非同期に行う - リモートワークに合わせた提案方法を探る

最近はリモートワークが主体で、みんなで集まっての同期的コミュニケーションがやりづらくなり、他の人の非言語情報を受け取ることも困難になった。その結果として、自分がチームで改善提案をした時に、周りの人からコメントを受け取る、提案に対する温度感を探るということが難しくなった。

改善提案にこのような課題があったので、リモートワークに合わせた方法を探り、まず改善提案の議論をテキストで非同期に行うというやり方を行ったので紹介する。その過程で自分が作った提案のテンプレートも共有するので、参考にしてもらえると嬉しい。

課題: 現在の働き方でも改善提案に対するフィードバックをもらいやすくしたい

もう一度課題をまとめる。

自分がチームの改善提案をした時は、チーム内の意見や反応を見ながら、より改善提案をブラッシュアップして実施したいと考えている。つまり開発フローなどチームの改善提案でもコードレビューと同様、コメントをもらってより良いものにしていきたい。

これまでオフィスで働いていた時は、提案をして言葉による反応が少なかったとしても

  • 表情、相槌、体の向きなどの非言語情報から情報をキャッチする。コメントしたそうにしている人には発言を促す
  • 別の時間で手が空いてそうな人を見つけたら、2分ほど改善案についての雑談をしてみる

という手法で、提案に対するフィードバックを受け取っていた。

ただしこの手法は全員が同じ空間で働いていることが前提となっていたため、リモートワーク主体となるとフィードバックが受け取りにくくなった*1。この状態を改善したい。

解決案: 改善提案のテキスト会場を用意し、思いついた時にフィードバックを送りやすくする

以上の問題は、リモートワークとなり雑談とミーティングの中間の同期的コミュニケーションが難しくなったことで発生していると考えている。だが、その解決のためにリモートワーク下でも同期的な会話を増やすというのは悪手だと考えた。

そこで、議論を非同期でやりやすくするために、改善提案するときはテキストで全員が書き込める会場(例: ScrapboxやNotion)を用意することにした。これはチームメンバーが思いついた時にすぐフィードバックを書き込むことができ、さらにそれに対して他の人がコメントを返しやすくなることを狙っている。

改善提案の会場作りには、意見が出やすいように以下のような形式にしてみた。

ご意見コーナーは下に用意しています。LGTMだけでも嬉しいです。ラインコメントで意見もらっても可。

## 目的や課題意識

## 改善案

## ご意見募集
* LGTMコーナー
    *
* もっと良くなるアイデアあれば
    *
* その他なんでもご意見どうぞ
    *

## 実施後の感想コーナー

## ふりかえり

この形式の工夫点としては

  • 改善提案はHowを書いてしまう傾向が多い。しかし重要なのはWhyなので、最初に「目的や課題意識」を書くようにする
  • フィードバックやフォロワーシップが生まれやすい形式にする
    • ご意見募集では、ポジティブだけどコメントがない人も「LGTMコーナー」に名前を書くだけで意見表明をできるようにする
    • より良いものにブラッシュアップしていこうという機運を高めるために、「もっと良くなるアイデア」コーナーを用意
    • なんでも気軽に意見を書きやすくするように「その他なんでもご意見どうぞ」という自由記述欄は用意
  • 改善は「まずやってみる」が大事だが、それを後からふりかえり、チームの学びとしなければ効果が半減してしまう。そこでふりかえりコーナーもテンプレートに用意してしまう

例えばこの形式でSlack のチャンネルがbot だらけになっていることを改善したいと提案した例は以下の通りである。

f:id:shiba_yu36:20210425232327p:plain

この形式でやってみた感想としては

  • LGTMコーナーなど気軽に感情をフィードバックするコーナーがあることで、今まで表情など非言語情報で受け取っていた温度感を、テキストとして受け取れるようになった
  • 会場にみんなで書き込む方式にすることで、例えば提案をブログや日記のような場所で書き別の場所でフィードバックをもらう方式よりも、フィードバックが生まれやすく感じた
  • テキストでフィードバックをもらえるため、意見を出し切った状態から最後の最後に同期的コミュニケーションを使って少ない時間で合意しやすくなった

参考: 課題意識までのパターン

上記形式は、解決の一案がある形式だった。しかし課題意識がテキストに起こされるだけでもチームにとっては学習になることが多い。そこで課題意識までのパターンも用意してみている。こちらは協力者を集めて、チームとして問題解決をしようという機運を高めやすくなるようなテンプレートにしてみている。

## 課題意識

## 協力者募集
協力してやってくれる人募集。同じ課題意識あったという表明だけでも。

## ご意見募集
* 解決アイデアコーナー
    * 
* 何でもご意見コーナー
    * 

## 実施後の感想コーナー

## ふりかえり

まとめ

今回はリモートワークに合わせた提案方法を探り、まずは改善提案の議論をみんなで書き込めるテキスト会場を用意し非同期に行うという方法をやってみたので紹介した。簡単なテンプレートも用意したので参考にして欲しい。

Slack の改善例以外にもコードレビューのフローやGitHubでのタスク管理方法などいくつかこの手法で改善提案をした。その経験からこの提案方法はリモートワークでなくなって全員がオフィスで働いていたとしても透明性高く議論ができる点で良いと考えている。今後元のようにオフィスに集まりやすくなったとしても活用していきたい。

本当はこのテンプレートを使うことで、自分からだけでなくチーム全体からどんどん改善提案が出るという状況にしたい。しかし、まだ道半ばでその状況にできていないと感じる。チームメンバーそれぞれから改善提案が出されやすくするには、また複数の課題を解決する必要があると感じるので、課題を探し解決していきたい。

*1:実際にはオフィスで働いている時も、拠点が違う人の声は受け取りづらくなるという問題があった

PostgreSQLのSSL接続の様子を観察する

遊びでNode.jsのprismaからherokuのPostgreSQLのDBへ接続しようとしたら、error: no pg_hba.conf entryというエラーが出て困ってしまった。ちょっと調べてみると、herokuのPostgreSQLのFreeなプランはSSL通信を自己署名証明書を使っているためエラーになってしまっているということがわかった。これについては遊びで使っていたこともあるのでNode.js, PostgreSQL error: no pg_hba.conf entry for host - Stack Overflowとかを見ながら一旦rejectUnauthorized=falseを設定することで回避した(参考)。

この件で、そもそもPostgreSQLSSL接続の様子をちょっと見てみたいなと思ったので、軽く調査したのをメモしておく。

そもそも証明書はどうなってる?

以下のコマンドで確認できる。

$ openssl s_client -starttls postgres -connect <domain>:5432 -showcerts
CONNECTED(00000005)
depth=0 CN = ip-10-0-69-188.ec2.internal
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = ip-10-0-69-188.ec2.internal
verify return:1
---
Certificate chain
 0 s:CN = ip-10-0-69-188.ec2.internal
   i:CN = ip-10-0-69-188.ec2.internal
...

これをみるとherokuのFreeのPostgreSQLはEC2が提供しているself signed certificateを使っている(というかDNSを見てみると普通にEC2に接続しようとする)。このため、証明書のチェック部分でエラーとなり、接続できていなかったことがわかる。

どうやってSSL通信に変わっている?

https://www.postgresql.org/docs/current/protocol-flow.html#id-1.10.5.7.11 を見ると、クライアントからStartupMessageより前にSSLRequestを送り、サーバからSが帰ってきたらSSL通信になると書いてある。これを元にWiresharkをみてみると

4番目のパケットでSSLRequestを送っている。 f:id:shiba_yu36:20210425151950p:plain

6番目のパケットでSが返ってきている。 f:id:shiba_yu36:20210425152121p:plain

それ以降、TLSv1.3のClient Helloが送られ、SSL通信が始まっていることが分かる。

オフィスでの仕事で何が生まれていたか a.k.a リモートワーク時代でも取り戻したいもの

この一年、オフィスのオフラインでの仕事から、一気にリモートワークのオンラインでの仕事に切り替わった。その中で色々困っていることが共有されているが、特に雑談がしづらくなったというデメリットを見かけることが多い。

そこで今回は、リモートワーク時代でもオフィス時代のメリットを享受するためのヒントを得るために、オフィスの仕事で何が生まれていたかを少しだけ掘り下げて考えてみたい。

僕はオフィス時代では次の3つが生まれていたと考えていて、リモートワーク時代でも取り戻したいと考えている。

  • 偶然のアイデアの発見
  • 複数人が勢いで何かをやっていく熱量
  • 自然な知見の横展開

偶然のアイデアの発見

  • オフィス時代ではその辺で会話していたら、それを周りで聞きつけた人が別職種・別チーム問わずやってきて、簡易ブレストみたいになることがあった。それにより新しい機能アイデアとか、ちょっとした改善アイデアが偶然発見されたりしていた
  • 出張して来た人と雑に話していたときも、実はこういうこと困ってるんですね〜から、それシュッと改善できますよ、みたいな話に発展することがある

今は「能動的に話に行く」ことはオンラインツールで出来るのだけど、「受動的に気になることが聞こえてきたので会話をしに行く」みたいなのは実現出来てないので、この問題が起こってそうに見える。

複数人が勢いで何かをやっていく熱量

  • オフィス時代では、会話していたら熱量が上がってきて、2~3時間くらいで複数人でガッと取り組むことで、何か動くものが出来るということがあった
  • オンラインで、熱量が上がってきて勢いで作る、ということが中々起こりづらく感じる

コミュニケーションツールでの解決ではなく、強制20%ルールといったやり方を使い、数人で取り組めるゆとりの時間で解決する、みたいな方法もあるかもしれない。

自然な知見の横展開

  • ランチや休憩スペースで偶然居合わせた人と、最近こういうことをチームでやっているとか、こういうこと困ってるみたいな話から、自然と知見が横展開されていた
  • あとこれわからない!!みたいな相談をチーム内でしていたら、周りで聞いていた別チームの人がやってきて教えてくれることもあった
  • それ以外でも、仕事とは直接は関係ない疑問(例えば自作ツールでうまくいかない!とか)みたいな話を、詳しそうな人をちょっと捕まえて話すみたいなことが出来ていた

オンラインになって、おりゃっと突撃するのがしにくくなったり、偶然居合わせるということがなくなったりすることで起きてきている問題だろうか?話しかけても良いかどうかを非言語情報から察知できなくなったことも要因かもしれない。

仕事以外の会話がしやすい雑相談Slackチャンネルやグループみたいなものがあってもいいかも。

まとめ

今回はオフィス時代のメリットを少しだけ深掘りすることで、リモートワーク時代でも取り戻したいものについて考えてみた。このように深掘りすれば、単純に「リモートワークでも雑談を増やそう」以外だけでなく、組織構造などを変えることでアイデアを発見しやすくしたり、スクラム開発など開発フロー面で対策を取ることで熱量を起こすといった別の対策も考えられるだろう。個人的にはリモートワークをせざるを得ない状況になることにより、場所の制約から解放されるチャンスが生まれていると思うので、どんどんリモートワークでもいい感じに働ける工夫をしていきたい。