microCMSでは、業務中の時間を使って輪読会を実施しています。
この記事ではmicroCMSではどのように輪読会を実施しているのか？実際どんな効果があったのか？を紹介します。
輪読会の実施方法
2022年末頃から輪読会を開始し、当記事までの間で5冊（+1ドキュメント）を読みました。
任意参加という形で行なっています。
実施方法などはその時々によって微妙に異なるのですが、基本的には毎朝30分間実施し、
- 最初の15分ほどで読めるところまで読み進める
- 後半の15分で気になる部分を議論する
という方法で進めました。
この方法は、1日に読み進める量が多くはないですが、休暇などで参加できないメンバーがいたとしても復帰しやすいというメリットがありました。
時間内で本を読むので、プライベートの時間ではその他の勉強や趣味に時間を当てられますし、この「仕事で使う技術を仕事中にも学べる」というのはとても良い環境だと感じます。
毎回Notionに記録を行い、どんなことを話しているのかが参加していない他のメンバーにも伝わるようにしました。
microCMSには「オープンでいよう」というバリューがあり、このように直接参加していなくても議事録をみて話されている内容について知れるようになっています。
バリュー
輪読会の議事録をNotionで読んだ日毎に管理しています。
やってみた効果
具体的な内容については、次節「実際に読んだ本」で紹介しますが、読んだ本が実際にプロダクトに反映されているというのが率直な効果です。
その時々のチームの課題や興味に合わせた本を読んでいる印象があります。
例えば「実用Go言語」はまさにmicroCMSがNode.jsからGoに移行されはじめたタイミングで実施されました。
他にも「単体テストの考え方/使い方」はテストコードが書かれ始め、さらに品質向上を計るタイミングで実施されています。
実際に学んだ内容を業務に反映できているのがとても良かったと思います。
個人的には、その本を社内で読んでいるということを会社全体に周知できるのも輪読会の良いところかなと感じています。
microCMSの輪読会は任意参加となっており、その本を読みたいメンバーが集まり実施されます。
開発陣以外のメンバーなど参加しないメンバーも出てくるのですが、
そのメンバーに対して開発陣がHOTだと感じていることを輪読会を通じて伝えられることは大きなメリットです。
例えば「Webアプリケーションアクセシビリティ――今日から始める現場からの改善」の輪読会を行なった際には、実際にWebアクセシビリティの改善が進められました。
Webアクセシビリティなどは実際に意識されにくいものに当時はなってしまっていたのですが、Webアクセシビリティの啓蒙となり、実際に開発時にはアクセシビリティの改善のタスクが生まれていきました。
実際に読んだ本（ドキュメント）
実際にどのような本（一部ドキュメント）を読んだのかご紹介します。
紹介する本はどれも輪読会の題材として素晴らしい書籍でしたのでおすすめです。
実用Go言語
Node.jsからGo移行がされはじめたタイミングで読みました。
言語移行のペインとなることとして、実際に全員の開発メンバーが移行に関わるわけではないというのが挙げられます。当然Node.jsのコードで新規開発・メンテもする必要がありGoのプロダクションコードに触る機会が少ないメンバーがいました。
その隙間を埋めてくれたのが当書籍です。
実用Go言語では、Goの文化やプロダクトでGoを扱う上での設計・テスト・エラーなどなど、なかなか個人開発などでは意識できないことが紹介されており、まさにGoをプロダクトで扱う上で実用的な書籍だと感じました。
実際にmicroCMSのコードも実用Go言語で紹介されているようなベストプラクティスを一部踏襲されたようなコードベースとなっています。
輪読会はこの本で紹介されているtipsを実際のmicroCMSのプロダクトコードを参照しながら、輪読会参加メンバーで本の内容について理解を深めるという方法で行いました。
普段APIを開発するだけでは触ることがないプロダクトの根幹の設計について話すことができたので、とても良かったと感じています。
React Document
こちらは書籍ではありませんが、Reactドキュメントを読みました。当時はBeta版として、一新されたばかりのドキュメントだったと記憶しています。
以前のドキュメントと比較して、Reactのベストプラクティスないし思想がドキュメントに反映されていると感じました。
microCMSではフロントエンドでも課題を抱えており、具体的には useEffect が乱用されており、stateの管理にも課題を抱えていました。
Reactドキュメントを読むことで、改めてReactのデータフロー・コンポーネントの原則などをチームで見直すきっかけとなりました。
フロントエンドもバックエンド同様、アーキテクチャを含めた改善が進められており、Reactドキュメントを読みことでメンバーの目線を合わせられたのは良かったと思います。
Webアプリケーションアクセシビリティ ――今日から始める現場からの改善
アクセシビリティについての意識をチームで高める目的で当書籍を読みました。
こちらの書籍はWebアプリケーションのアクセシビリティに関わるのであれば一読することをお勧めします。
実際に章ごとに、microCMSのプロダクトをみながら問題のある箇所や実装などについて話ながら輪読会を進めました。
これを機に、コンポーネントの修正が行われたり、新規開発でキーボード操作の観点が加えられたり、プロダクトのWebアクセシビリティの意識が変わった書籍だったと思います。
フロントエンド開発のためのテスト入門 今からでも知っておきたい自動テスト戦略の必須知識
フロントエンドのアーキテクチャの刷新に合わせて、フロントエンド側でもユニットテストが書かれるようになったタイミングで当書籍を読みました。
当時はテストコードが全く書かれていなかったという背景もあり、ユニットテストの追加などを探り探り行なっていました。
この書籍では、フロントエンドのテストの考え方から、ユニットテスト・コンポーネントのインテグレーションテスト・E2Eテストなど幅広く「どのテスト」で「何」を担保するのかがを考えながら輪読会を実施することができました。
実際に現在のmicroCMSではユニットテストも、PlaywrightによるE2Eテストも定期実行されています。
フロントエンドテストの全体像を把握し、プロダクトのフロントエンドテストを見直す良いきっかけになりました。
単体テストの考え方/使い方
前述の「フロントエンド開発のためのテスト入門」と合わせて、当書籍を読んだのがとても良いチョイスだったと感じました。
当書籍は「単体テスト」というテーマで書かれていますが、実際にはインテグレーションテストなどを含めたプロダクトのテスト全体に関わる内容になっています。
どのように単体テストを書くのか？だけでなく、単体テストを書かないことについても触れられています。
microCMSはもともとテストが不足している中で、単体テスト中心にテストの導入が進められていったと言う背景があります。
その中で一度「単体テスト」はどうあるべきなのか？をチームメンバーで考えられる良い機会だったと感じています。
フロントエンドの話で言うと、「フロントエンド開発のためのテスト入門」でツールとフロントエンドテストの世界の全体感を知り、
「単体テストの考え方/使い方」の内容をどのようにフロントエンドに落とし込めるかと言う観点で議論がされていました（実際に当てはまらない部分もありましたが、議論のベースとして有意義でした）。
GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ
最後にこちらは技術書ではありませんが、GitLab本を読みました。
こちらは、開発メンバーだけではなく他のバックオフィスメンバーなども含めた全社で行いました。
当書籍はGitLabはリモートで働く上でのハンドブックを公開しており、当書籍はそれを抜粋・翻訳したものとなります。
microCMSは全メンバーがフルリモートでの勤務をしており、働き方を見直す意味でも当書籍の輪読会を行いました。
実際にメンバーで話していると、それぞれが働き方に課題を持っていることがわかり、リモートならでの働き方の難しさを再度感じました。
この輪読会を機に「リモート推進チーム」と言うチームが作られ、私自身も開発業と兼務ではありますが所属するようになりました。
実施に輪読会や日々の業務の中で出てくる課題などをあげ、改善を進めています。
具体的には雑談（書籍内で言うところのインフォーマルコミュニケーション）の充実やテキストコミュニケーションやタスク管理などの課題に対して取り組んでいます。
最後に
microCMSの輪読会の取り組みを紹介しました。
microCMSはフルリモートと言うこともあり、もしかしたら淡々とプログラム書いて、タスクを行なっていると言うイメージがされやすいのですが、
実際には時にはこのような輪読会などの取り組みを通じて、課題や興味のある技術について話ながらワイワイ仕事をしています。
紹介した書籍はどれも学ぶになるものばかりなので、ぜひ輪読会の参考にしてみてください。
Discussion