モバイルアプリエンジニアの山下（@yamshta）です。
LCLでは今月から全社員を対象にしたフレックスタイム制のトライアル期間が始まりました。
エンジニアは以前からもフレックスに近い働き方が可能でしたが、いくつかの新しいルールが追加されました。
これまでの取り組みはこちらの記事でご紹介しています。
この変更から勤務時間を柔軟に偏らせたり、早い時間からオフィスで勤務できるようになったため、私も仕事を早く切り上げた日は、個人アプリ開発や書籍購入制度で買ってもらった本の読書に充てられるようになりました。
前置きが長くなってしまいましたが、今回は上の記事でさらっと触れられている輪読会の取り組みについてもう少し詳しく紹介させていただこうと思います。
輪読会を実施する目的
LCLのエンジニアチームで共有している、輪読会の目的は大きく分けて３つです。
- 読書文化の定着
- スキルアップ
- 技術的コミュケーション
具体的には以下の効果を期待しています。
- 一人で読むにはパワーが必要な本を全員で読みきる
- 分担して読むことで負担を減らせる
- 理解が難しい本を全員で理解する
- 普段触れていない分野が題材の場合でも、有識者の補足をもらえる
- 別の分野の視点から良いところ、悪いところなどの意見や議論ができる
- より実際に運用しているサービスに当てはめて考えやくすなる
- 触れたことのない分野を皆でキャッチアップ
- 全員が一度に知識をキャッチアップできるので属人化になりにくい
輪読会は一人読書と違い、全員で読み、理解して進めます。
これらの効果を期待しつつ、チームとしてコミュケーションを深めることでより働きやすい雰囲気がつくられたり、互いのモチベーションの維持や刺激になると考えています。
はじめ方
緩くなりすぎて形骸化しないように、最低限のルールを定義して実施しています。
- 2週に1回
- 曜日と時間は固定
- Google Calendarで共有
- 任意参加
- 担当は持ち回り
- 受け身のメンバーがでないようにするため
- 担当者は内容を事前把握しておくべきかどうかは随時検討
- 専門分野問わず誰でも参加してよい
- 寧ろ推奨
エンジニアチームでは、以前から毎週水曜日のランチ後に勉強会の時間を設けています。
流石に1週間の内に勉強会と輪読会を回すのは忙しいので、同じ枠を使い交代で開催するようにしました。
担当の持ち回りは、最初の週は題材を起案した人もしくは有識者が担い、メンバーが固まってきた段階で回すようにしています。
進め方
実際に輪読している内容を基に紹介します。
題材は『データベースパフォーマンスアップの教科書 基本原理編』にしました。
512ページの大型本です。私一人では絶対読みません。
この本を選択した背景としては、SQLのパフォーマンスを上げたいという共通課題があったからです。
具体的には、RailsやRedashでクエリを叩く機会が多く発生する中で、バックエンドに携わるエンジニア全員が少しずつ複雑なクエリも組めるようになっていました。しかし、テーブルやクエリの構成を意識していないため、レスポンスが遅く待ちが長いものが増えていました。また、遅いと感じていたものの原因や最適化方法がわからないため、そのまま運用され続けていました。
そこで全員がDBの仕組みから理解を深め、デバッグ方法や最適化の方法を知り、パフォーマンスが良いクエリを組むことができるようにこの本を選択しました。
次に具体的な進め方を紹介したいのですが、実は数回実施した上で進め方に課題が生まれたため改善を行いました。
始めた当初の進め方と現在の進め方を分けて紹介したいと思います。
始めた当初の進め方
- 担当者は章毎に持ち回り
- 進捗は1時間のうちに進めるところまで
- 担当者は音読する
- 適宜質問や議論をする
- 補足があるとチャットに流したりしている
数回の開催を経て出てきた課題
- 議論があまり生まれない
- 有識者から補足がある程度
- あまり頭に入らない
- 進んでるが理解できていない
- 飲み込む余韻がない
- 横文字を調べたり、補足のチャットをみたりしている間に話が進んでいて迷子になる
- ランチ後なので眠くなる
担当者が音読するやり方だと、流れを切りづらくコミュニケーションが発生しづらい雰囲気になっていました。
また、冗長的な表現が多く含まれていたり、いたるところで比喩表現が入ったりする本の場合、音読では効率が悪く理解しづらい読み方だと気づきました。
※このような読まれ方をする想定をしていないことを理解しており、それらの本に対して否定は一切しておりません
やはり意見を交わすことが大切であり、このまま進めても前述の効果が期待できなかったため改善案を考えました。
改善案
改善案として2つのルールを追加しました。
- 担当者が可能な限り要約をする
- 章単位で数分の議論タイムを設ける
担当者が可能な限り要約をする
担当者は事前に読んだ内容を要約、もしくは重要箇所の抜き出しをするようにしました。
もちろん、専門分野でなかったり、初見の場合は難しいです。そのため一読してよくわからなかった場合は直ぐに諦めてよいということにしています。
大切なのはわからない箇所をみつけることで、要約しようとするとわからないことがはっきりわかります。
これまでは理解に関係なく読み進めることで通り過ぎてしまったことが多々ありましたが、これにより全員で調べたり議論をすることで着実に理解できるようになりました。
章単位で数分の議論タイムを設ける
上のルールを加えたことにより要点が絞られ、議論がしやすくなりました。
1章に掛かる時間が圧倒的に短くなったため、具体的な内容のに置き換えてホワイトボードなどを用いて落とし込みをしています。
また、可能な限り自分たちが運営しているサービスの内容で例えることでイメージしやすくしています。
改善結果
新しいのルールを加えたことにより、議論中心で進められるようになりました。
当初のやり方では、いつもギリギリまで音読していましたが、逆に時間を余裕がでるようになりました。
おわりに
輪読会を始めたことにより、一人では手を付けにくい本を読むことができました。
議論の中で、運営しているサービスの内容で例えるのはとても理解しやすく、逆に仕様やその仕様にした経緯の理解も深まりました。
個々の読書も盛んになり、毎週数冊の本が購入されています。
私はこれまではあまり本を読む方ではありませんでしたが、書籍では情報や考え方などが一つにまとまっているため、キーワードや目次を覚えておくだけでも必要な情報を一括で探し出せるのが良いと改めて感じています。
次回は書籍購入制度で購入した本の管理方法についてご紹介できればと思います。
