私は2021年に新卒でwebエンジニアとして今の会社に入社しました。
そんな私が社内で輪読会を企画しながら一つの技術書を読破しました。
それによって気づいたことがメリットでメリット含めていくつかあったのでまとめていきたいと思います。
目次
私は輪読会を開催する時点でちょうど入社から1年ほど経過していました。
その頃は自分の「引き出しの少なさ」に悩んでいました。
特にレビューをする時や、リファクタリング作業ではこの「技術の引き出し」がいかにあるかが大事だと考えています。
つまり、いかに設計やコーディングの段階選択肢を持ち、根拠を持って実装方法を選ぶかが大切なのですが当時の私にはその力がありませんでした…
自分の引き出しをもっと増やせる方法はないのか考えた中で、私が選んだのが「輪読会」でした。
今回私が引き出しを増やすために選んだ技術書は「クリーンアーキテクチャ」です。
この小難しい本を読み切るためにはなるべく負担を感じない方法で輪読会を進めていく必要がありました。
「そもそも輪読会ってどう進めていけば良いの?」
と思い調べてみたら以下のような言葉が様々なサイトで引用されていました。
人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。
https://www.weblio.jp/content/%E8%BC%AA%E8%AA%AD%E4%BC%9A
つまり、一つの本をみんなで読んでそれについてディスカッションするということを「輪読会」と呼ぶみたいです。
そこで私たちは、なるべくシンプルに
(当日までに)軽く内容を読む→担当者がまとめる→(当日)→まとめてきた内容を共有→それについて話し合う
というサイクルで輪読会を進めていきました。
本の内容をまとめるために利用するツールは参加者全員が見れるものなら何を使っても問題ないと思います。
私達は社内で導入しているconfluenceを使って社内の誰でも見れる場所に公開しています。
特に上記のようなサイクルの中で「担当者がまとめる」という部分では下記のようなテンプレートに沿って概要、キーワード、感想・疑問まで埋めてきてもらってそれを発表してもらいました。
概要 | キーワード | 感想・疑問 | 当日記入スペース |
---|---|---|---|
本の内容をまとめる | 大事だと思ったキーワード | 単純な感想、理解できなかったところ | 当日話した議事録 |
ざっくりと進め方決まって次は開催頻度や担当など細かいことを決める必要があったのですが、この細かい進め方に関しては進めながら負担がないように微調整していきました。
最終的には以下のような進め方が私たちにはあっていたので理由とともに説明していきます。
輪読会を開催していて、開催のスパンはなるべく短くした方がメンバーからも好評でした。
理由としては、前回の内容を忘れないということと、担当を忘れる心配がないという部分が大きかったです。
具体的には週に3回というペースで開催していたのですが、これが週に1回だと土日を挟んでしまうので内容や担当を忘れてしまう懸念があったのでなるべくスパンを短く開催することでこれを防いでいました。
また、開催スパンを長くすると必然的に扱う量も多くなり1回欠席してしまうとキャッチアップが大変になるというのもスパンを短く設定した理由と一つです。
開催のスパンを短くするため細かい単位で区切る必要があるということもそうですが、一番はディスカッションするときに範囲が小さいと一つの事象に対して深く議論できるという意味が大きいです。
また、準備する側も量が少ないので負担になりませんしその分深く調べることができるのも扱う量を小さくするべき理由の一つです。
輪読会は基本的に何回にも分けて長期間開催していくものですので、仕事やプライベートに合わせて柔軟にリスケをしたり、担当をずらしたりしていくことが大切です。
あまり堅苦しくなく進めていくことで輪読会へのハードルを下げていけば無理なく輪読会を続けることができます。
また、この章は読まなくていいよねという章はメンバーの意見を聞いて飛ばしたりと必ずしも最初から最後まで読まないという選択をすることでモチベーションを保つことがでます。
よく社内でも新卒同士や技術レベルが同じようなメンバーだけで輪読会を開催している場面をよく見かけますが、今考えるとそれは少し勿体無いなと思っています。
やはり、技術力が同じだと結局見えてるものも同じで深い議論に行かないことが多いですし学びも少ないです。
しかし、技術力や年次がバラバラなメンバーが集まれば様々な視点で議論が進みたくさんの知識をインプットすることができます。
これは一見技術力が高い人が輪読会に参加する必要がないように見えますが、技術力が高い人にもメリットがあります。
技術力が高い人も普段一緒に仕事をしているメンバーが成長したら自分も楽ですし、自分の技術や経験を言語化する良い機会として活用できるかもしれません。
私が社内で輪読会を実施してみて気づいた、メリット、デメリットがあったのでこれからはそれを紹介できたらと思います。
- 技術力が向上する
- 無理なく難しい技術書を読むことができる
- 共通言語ができる
- 周囲にアピールができる
- (仕事の環境によっては)会社のリソースを使うことができる
技術力が向上する
これは当たり前の話ですが、今まで読んだことがない、昔読んだけど内容覚えてない技術書を読む輪読会に参加することが多いと思うので輪読会を通して新しい知識を身につけることができるので個人個人の技術力が向上します。
また、一人で技術書を読んで理解するよりも複数人でディスカッションしながら読んでいるので理解度が深まります。
技術書は抽象的な記述がされている部分があってなかなか理解に苦しむ部分があると思います。
私の場合は、そんな時でも、自分はこう解釈した。こういう解釈もあるのでは?自分達が開発しているシステムに当てはめると…などさまざまな解釈の仕方や、実際の業務に当てはめた解釈もしていくことができるのでより実践的な知識を身につけることができていました。
無理なく技術書を読むことができる
分厚く、難しい技術書はやはりスラスラ読めるわけではないので途中で読むのをやめてしまったり、そもそも読まずに積読になってしまっている方が多いのではないかと思います。
この技術書を読まなくなってしまう理由の(個人的)2大巨頭「難しくて途中で読む気がなくなる」「読むのが面倒くさくて読まなくなってしまう」という状況を生み出しにくいのが輪読会のメリットでもあります。
難しい内容でも自分なりの解釈を持ってディスカッションすることで輪読会参加者と理解を深めて読み進めていくことができます。
最悪自分が読まなくても担当者が概要をまとめてきているので技術書の大筋は参加しているだけで把握することができます。
個人的には難しい内容をみんなで話し合って難敵を倒していく感じが結構好きでした(笑)
共通言語ができる
これは個人的に社内で輪読会を開催する最大のメリットなのかなと思っていますが、輪読会を通してレビューや普段の会話で共通言語ができるというのは業務効率化という面でとても役に立っているなと感じました。
それまでエンジニアをやっていて、言葉の定義やコーディングしている上で大事にしている価値観が人によって違うためコミュニケーションする上で齟齬が生じることが多いなと感じていました。
しかし、輪読会を通して一つの基準を再認識することでレビューをするときに同じ視座で話し合いをすることができるようになりました。
周囲にアピールができる
輪読会を開催していると、社内の方から「あいつはこの技術について勉強しているんだな」と周囲に良くも悪くも知られていきます。
私の場合はこの勉強会が理由でクリーンアーキテクチャを採用したプロジェクトのレビューをお願いされることがありました。
このように社内で輪読会を開催していると輪読会で知った内容をすぐに業務で使うことができる可能性が高くなるというのもメリットの一つだと思いますし、社内で輪読会を開催しているからこそ得ることができた機会だと思います。
(仕事の環境によっては)会社のリソースを使うことができる
これは職場環境に左右されるかなとは思うのですが、最近の企業では書籍代を会社負担で出してくれていたり、業務に還元できることであれば業務時間を少し使って勉強することが許されている企業も多いように思います。
技術書はそこそこ良い値段がするものも多いですし、個人で買うには躊躇ってしまうことも多いかもしれません。そんなときにせっかく会社が用意してくれている機会は有効に活用していくべきでしょう。
そして輪読会で身につけた技術を会社のプロダクトに還元していくことができれば、全員win-winですよね。
- モチベーションの維持
- 時間がかかる
- 時間を合わせることが難しい
- 実際に手を動かすわけではない
モチベーションの維持
メリットの中で、技術書が読破しやすいという部分を挙げたのですがそれは一人で読むのと比べてという話で、人間ですのでどうしてもモチベーションが下がってしまう期間はあります。
それは本業のタスクが忙しいだったり、段々と事前準備がめんどくさくなってきたり、輪読会の期間が伸びて中だるみしてしまうなど、さまざまな理由があると思います。
しかし、これらのほとんどは運営で解決できるのでメンバーと話し合って少しでも楽しく輪読会を続けていくにはどうすべきか話し合ってみると良いかもしれません。
効率的な輪読会の進め方は上部でも解説しているので参考にしてみてください。
時間がかかる
個人で読むのと比べて輪読会では足並みを揃えて進行していかなければならないので、「時間がかかる」というのは個人で技術書を読むのと比べて唯一のデメリットかもしれません。
途中で輪読会の進捗にもどかしさを感じてしまう場面もあるかもしれませんが、輪読会には上記で述べたようにメリットもたくさんあるので個人では得ることのできないメリットにフォーカスして輪読会を楽しんでみると良いかもしれません。
時間を合わせることが難しい
輪読会を開催するときに皆が直面する問題だと思います。エンジニアだと、開発は午前中にやりたいから輪読会は午後にしてほしいという人もいますし、午前中に輪読会を開催して頭を働かせてから仕事を始めたいなど仕事スタイルが違うので最適な開催時間を選択するのは難しいです。
しかし、ここも輪読会の開催時間を短くして負担にならないようにするなど運営面で改善できることがあると思うので少しずつ改善していくのが良いかと思います。
実際に手を動かすわけではない
これは輪読会のデメリットと言っていいのかわかりませんが、今回輪読会を開催してみて課題だと感じた部分です。輪読会は所詮本を読んでいるだけなので実際に手を動かしてみんなで開発するようなことは基本的にしません。しかしそれでは本当にその技術を身につけたとは言えないですよね…
ですので本当にその技術を理解するためにはその輪読会の中で実際に手を動かしてコーディングしてみたり、輪読会開催後すぐにプロダクトに技術を取り入れるなど実際に手を動かすことが必要になります。
ですので私が次輪読会を運営するならば、手を動かす環境とセットで進めていく方が良いのかなと考えたりしています。
ここまで輪読会のあれこれを語ってきましたが、総じて輪読会はメリットだらけでどのエンジニアにもおすすめだと思います。
身近に輪読会が開催されていたら参加するのも良いですし、なかったら自分で企画してみてはいかがでしょうか?