こんにちは。今回Classi developers Advent Calendar 2022の16日目を担当します、すずまさです。
今年新卒入社して7月中旬まで研修を受けており、その後配属されて約5ヶ月チーム開発を続けてきました。
学生時代にも友達と作品を作ったり、エンジニアとしてバイトをしたりとチーム開発の経験はありましたが、そこでは得られなかった学びがたくさんありました。
その中でも今回は、「チーム開発との向き合い方」に絞って学びを書いていきます。
疑う姿勢を持つ
Googleのソフトウェアエンジニアリングの中に「目隠しを特定せよ」という節があります。
ある問題に初めてアプローチする際に、既にその問題と何年も戦っている人々の一団がいるのを発見することがしばしばあるだろう。そのような人々は、非常に長い間その問題に浸かっていたために「目隠し」を装着している。
この節では、無垢な人ほど目隠しの存在を発見でき、質問して改善していけると書いてあります。
私は社内勉強会でこの本を読み、チーム参加後に新卒に求められる役割のうちの一つはこれだと思い、意識していました。
しかし、わかった気になっていたものの、私は最初、この「目隠しの特定」ができていませんでした。
具体例を挙げると、下記のような部分をスルーしていました。
- M1 Macだと環境構築が大変なリポジトリ
- 煩雑で面倒なリリースフロー
- 微妙な変数名やコード設計
- アップデートされずに放置されている古いライブラリ
全てに共通しているのは、面倒だったり理解に時間かかるなとは感じつつも、そういうものかと受け入れていたことです。
例えばM1 Macの環境構築では、ドキュメントでわかりづらい部分があればその都度追記、修正等できていました。しかし、構築が面倒になっている根本原因に関しては直そうとは思わず、「M1 Macだと大変なんだな」と思うだけで終わっていました。 コードに関しても、自分がまだ経験不足ということもあり、「ちょっと違和感あるけどついこの前レビュー通ったやつだしこれでいいのだろう」と疑ってすらいませんでした。
自分が目隠しの特定ができていないなと気づいたのは、チームの体制が変わり、他チームから新しく人が入ってきてからでした。 その人が入ってきてからは、上記に挙げたものがどんどん改善されていき、それを間近で見て自分がいかにできていなかったかを痛感しました。
思うに、私には疑う姿勢が足りていませんでした。早くチーム内のルールや知識を吸収しようと躍起になった結果、既存のものに対して考えたり疑問を持つことを疎かにしてしまい、チーム内の「目隠し」も一緒に吸収していたのだと思います。
改善アクションを間近で見続けるうちに意識も変わり、最近はちょっとでも違和感を覚えたら疑問の声をあげたり、すぐに改善できそうならその場でやってしまうといった行動ができるようになってきました。
改善点をスルーしていたことはかなり反省していますが、一度やって後悔した経験はもう忘れないと思いますし、良い学びになりました。
細かい箇所でも指摘する
上述したのはそもそも疑問すら持っていなかったものでしたが、今回のは気付いていたのに声をあげられなかったケースです。
「ここちょっと気になるけど…まぁ時間かかるし大変だろうからいいか」という具合に、声を上げられなかったことがありました。
例えばPRのdescriptionです。 仕様書をしっかり読み込まないと何をやっているのかわからないものや、チーム外の人が見たら理解できなさそうな説明などを、指摘せずにそのままapproveしていました。
その時の私は、細かいところばかり指摘するのは揚げ足とりになるかと思い、言い出せずにいました。
しかし、そもそも「細かい」と思っていること自体が誤りかもしれません。指摘せずに放置することで他のメンバーにも伝播していき、悪い文化として定着してしまう可能性もあります。 「細かい」と思っている指摘でも、チームにとっては十分プラスになる素晴らしい働きなのだと、考えを改めました。
これができるようになったのは、typoを指摘しているチームメンバーを見たのがきっかけでした。 その内容は "ESLint" と "EsLint" くらいの違いでしたが、その方は「こういうものであっても正式名称で書かないことですれ違いが起きることもあるし、正式名称で書くようにする癖をつけた方がいい」と語っており、それに私も影響されました。
また、そのチームメンバーが細かいと思っていた指摘を進んでしてくれたおかげで、小さな指摘でも遠慮せずに言う文化が醸成されつつあるのを感じています。 特にPRのdescriptionに関してはそれが顕著で、「descriptionのここを直してほしい」というレビューを最近はよく見かけるようになりました。
ペアプロのやりすぎには注意
チームに入ってから一ヶ月ほど、私は入社時期が近いチームメンバーとペアプロをかなりやっていました。 丸一日ペアプロし続けることもざらにありました。
やっていた時は、ずっと喋りながら作業しているのでチームに入りたてでも孤立感が全くないですし、お互いの弱点をフォローしながら一緒に開発できて体験が良いと感じていました。
ですが、長時間ペアプロに没頭しすぎたことで失敗もありました。
ある時、面倒見のよい先輩とのミーティング中に「最近timesチャンネルの流量が減って心配していた」と言われ、そこで初めて孤立化が進んでいたことに気付きました。 （timesチャンネルとは、Slackの個人用分報チャンネルのことで、Twitterのように自由に呟ける場所です。）
同時に、下記のようなアドバイスをいただきました。
- ペアプロは一日ずっとじゃなくてコアタイムを設けてやった方が良い
- ペアプロは集中できるメリットはあるけど、周りの状況が見えづらくなってサイロ化しやすいから注意
確かに、周りの状況が見えづらくなるデメリットは当時も感じていました。 ずっと喋りながらやっているので、並行して何かをやる余裕がなく、必要な時以外Slackはあまり見られませんし当然他の人との会話も減っていました。
ペアプロに没頭した我々からすれば孤立を感じていなかったとしても、チームからは孤立気味になっていたのかもしれません。
報連相はやりすぎてもいい
今いるチームでは、Slackの流量が多い人がチームに加わってから劇的に会話が増えました。
下記は、その人がチームに加わる前のチームチャンネルのSlackアナリティクスです。
そして、下記がその人がチームに加わった後です。
投稿したメンバー数は減っているにも関わらず、投稿されたメッセージ数は 2,928 → 6,631 と、2倍以上増加しています。
これは、Slackの流量が多い人が加わったことにより、つられて他の人のSlackの粒度が上がったのが理由だと思います。 それまでは3行以上のまとまった文章が流れることもしばしばあったのですが、最近は短文での連投がかなり多いです。
これにより報連相がしやすくなりました。
今までは短文連投が少なかった上に、チャンネル参加者が多いこともあり、通知がうるさくないかなどを気にして纏まった文章を送りがちでした。 しかし最近は、ちょっと気になったことや雑談のような内容でも以前と比べて気軽に投稿できるようになっているのを感じます。 チームメンバーが何をやっているかの様子が前よりもくっきり見えるようになってきました。
共有事項や作業の実況、相談などが以前と比べて明らかに増えており、前よりも断然仕事がしやすくなりました。
ただそれでも、いまだに報連相が足りていないという趣旨の会話がされることがあります。 そういったことから、報連相は過剰にやるくらいの気持ちでやった方がいいなと学びました。
リモート下でのコミュニケーションについては他にも何度か記事になっています。 是非併せてご覧ください。
まとめ
学びの多くに共通して思うのは、勇気が足りなかったということです。 既存のものを疑って批判するのも、細かい指摘をするのも、投稿量の少ないチャンネルでたくさん投稿するのも、どれも私にとっては少し勇気が必要なことでした。
今回振り返ってみて、文化にすぐ順応するのではなく、最初に少し勇気を出して自分から良い文化を築けるようになりたいと思いました。
ここまで読んでいただきましてありがとうございます。
Advent Calendarの次回は id:ic_lifewood さんです。
