こんにちは!
GiftX の五島(islands5) です。
普段は GIFTFUL というソーシャルギフトサービスの開発と運用/保守を行っています。
今回は開発チームで『Good Code, Bad Code』という本を輪読会し、輪読会から得られた成果と感想を共有していきたいと思います。
結論
- メンバーのバックグラウンドを知れる。
- 読んですぐ話すという習慣ができる。
- コードレビューが変わる。議論が増えた。
- こうしたい、ああしたいという未来の話ができる。
- 輪読会いいぞ
はじめに
今年の4月にサービスをローンチしてから、機能の追加やSEOを様々行ってきました。
サービスを運用・保守していく上で、チーム内でコードの品質に関する認識を揃えたいと思う機会も増えたので何か一工夫欲しいと思ったことがキッカケです。
現在のチームは業務委託のメンバーが多く、これまで関わったプロジェクトや開発してきた環境も異なります。
またメンバー全員がリモートワークということで、相互理解も進むいい方法はないかとぼんやり考えていました。
単発の勉強会的なものも考えましたが、なるべく継続して行いメンバーの意見も引き出せそうな方法ということで、輪読会を開催することにしました。
本を元にこれまで関わったプロジェクトや他の言語での開発経験も踏まえて議論を交わすことで、メンバーの設計・コーディングに関するポリシーや背景の理解、チーム全体のスキルアップを目指しました。
本の選定
これに関してはチームで最初の輪読会ということもあり、僕の主観で決めました。
コードの品質に関する本として有名なものは『リーダブルコード』です。
有名なので既読のメンバーがいたりして候補から外しました。
メンバーの国籍も異なるし、今後いろいろな現場についた時に話題にしやすいように海外でも出版されている本がいいのではという点、
せっかくなら読んだことない本の方が自分も楽しい!!という点を加味し『Good Code, Bad Code』にしました。
後半の理由が比重としては高かった気がしてます。
わんぱくな理由ですね。
輪読会のやり方
輪読会と言っても検索すれば様々な方法が見つかります。
こうゆう社内勉強会を計画したことがある方は経験があるかなと思いますが、
途中から「やるの?やらないの?」みたいな空気感が流れ出し、いつの間にか勉強会が消滅するということが往々にしてあります。
意識したのは 持続可能な輪読会 です。
弊チームでは今回以下の条件で開催しました。
- 紙の本 or pdf を事前にメンバーにヒアリングしてから送付
- 水、金のお昼から時間を決めて30分開催
- 業務時間内に読む時間を確保してもらうこと
- 輪読会のファシリテーションは毎回担当が変わる。順番で回す。
- 輪読会中に notion に主なトピックや雑談の内容、今後のコーディングにおいて取り込みたい考え方についてまとめる。
いくつかのルールは、メンバーと一緒に輪読会のやり方についてディスカッションを行い意見をもらって決めました。
1回の時間を長く取らずに本を触る頻度を高めるため、週に2日としたのは継続できている大きなファクターだと思います。
意見を下さりありがとうございました!!
ファシリテーションが毎回変わるのもよかったです。
緊張感の波がいい刺激になりますね。
業務時間内に組み込んだのも継続していくには重要だったと思います。
実施し始めてから追加されたルールもあります。
- 自分で読んでわかりにくかったところは飛ばすこと(輪読会の時に質問する)
- 開始3分くらいで前回の輪読会のおさらいから入ること(難しい話が続く部分があるため)
- Part が変わるタイミングでざっくり振り返りを行う週を設けること(本書は理論/実践/テストという大きなPart分けがあるため)
最後の振り返り週は出先に本を持っていけない時に偶然追加されたルールだったのですが、結構よかったなと思います。
内容を忘れそうなタイミングでさらっと振り返るタイミングが訪れるので、本の内容がより頭に残りやすくなったように感じます。
本のテーマとか、〜さんがこんな話してましたねーといった雑談を notion から拾ってきて振り返りました。
1on1 などで会の改善点を収集し負荷がなるべく上がらないように改善していきました。
ありがたいことに現在も続けられています。
進行をする上で意識したこと
ある程度記憶の補助になるように話題の広がりは意識しました。
過去関わったプロジェクトや言語もそれぞれバラバラなので、1節が終わるくらいのタイミングで話題を振ったり会の中で各人一回は話すタイミングがあるように心がけました。
輪読会のメンバーが最大 3名程度ということもあって、話が膨らむことも多かったです。
あと実際のサービスのコードにも言及するようにしました。
- この考えに則るとこの辺りはもっとこうした方がよさそうだね
- あの辺りはこの考えに則って実装されてるね
といったことを、本のテーマに沿って話題に出すようにしました。
個人的にはこうゆうアクティブな勉強会は5, 6名以下で行うのがひっかかったところを途中で止めたり、
発言する時のプレッシャーも少ないのでいいのではと思います。
輪読会をはじめて起こった変化
1, 2ヶ月くらい経過するとコードレビューのコメントが変わり始めました。
例えば
- このコメントを書くなら変数名をこう変更した方が想定が伝わるんじゃない?
- ここの if は早期リターンした方が読みやすそうだね
みたいなことです
もちろん前からやってたんですけど、個人の感覚として気持ちコメントしやすくなったように感じました。
それまでは揃っていなかった「コードの読みやすさ」みたいな抽象的な概念が、1冊の本を軸に「揃っていってるな〜」という感じがありました。
本の内容もなんですが、輪読会の時にサービスのコードの理想の状態について話す機会があるというのも大きかったです。
その後はインターフェースやモジュール、設計に関して議論することが増えました。
現在 issue を割り振る際に要件の詳細をPMからヒアリングしながら、チームでざっくりTODOに分解して見積もり、実装を依頼するのですが、
・issueAとissueBでは似たような処理を行いそう
・こんなモジュールが必要そう
・AとBはこんな感じでモジュールを触れるとよさそう
・ではそのモジュールはこんなインターフェースで実装しよう
・それはテストしやすそう
...
みたいな話がメンバー間でも起きるようになりました。
依頼された機能を実装して完了という視点が、より高い品質のコードを書き運用・保守を見据えた視点に変わった気がします。
あとは完全に本の影響ですが、「想定」とか「前提」という単語に敏感になります笑
その想定はこのメソッド名からだと伝わらないよ、その想定ってほんとにいるんだっけ!?みたいな感じです
共通フレーズみたいなものができました。
控えめに言ってもさいこーだ
結論と学び
早くいきたければ、一人で進め。遠くまで行きたければ、みんなで進め
1冊の本をみんなでじっくり読みこむというのは、１人で読み進めるのとは異なり、ペースは遅いかもしれません。
しかし、メンバーの開発経験や話を聞きながら本の内容をなぞるのは考え方に厚みをもたらしてくれます。
今回は自分も初見の本で進めたのですが、おそらく既読の本でも新しい発見がモリモリ出てくると思います。
チーム内でカジュアルに設計の議論や相談ができる空気を作るのにも効きました。
実はまだ最後の章が残っているのですが、一度振り返りの気持ちをまとめてみました。
参加してくれているメンバーのみんないつもありがとう!!
次はどんな本にしようかな
皆さんもぜひこの本がよかったよ〜などあれば、コメントください(´ω｀)
GiftX では現在フルコミで参加できるエンジニアを募集しています。
関心のある方はぜひこちらまでご連絡ください!
Discussion