こんにちは。GoQSystemで技術顧問をしております、@hiro_yです。
GoQSystemでは毎週Tech meetupと称して技術系勉強会を開催しています。ここしばらくは輪読会を実施していたのですが、取り組みとして気を付けておかないとせっかくの時間がもったいないな…と感じたので、いくつかポイントを示します。
ちなみに今読んでいる書籍は、改訂新版『良いコード／悪いコードで学ぶ設計入門』です。
意見や感想を持つこと、表明すること
今回の輪読会では、事前に書籍を参加者がそれぞれ読んでくること、毎回章ごとに担当者を決めるので、その担当者がサマリーを用意して発表すること、というルールでやっています。（皆の前で情報をまとめて発表する練習も兼ねています。）
サマリーを作るとなると、よくも悪くも、書籍の内容をそのまままとめたものになってしまいがちです。しかしそれは読めばわかる内容なので、実際に読んでみて、どう感じたかを担当者は語ってほしい。それが議論の起点になるからです。
書籍を読んだとき、誰しも何かしら意見や感想を持つものではないでしょうか。「すごくわかる」でも「自分はそうは思わない」でも、「何を言っているのかわからない」でも何でもいいのです。
書籍に書かれていることはあくまでその著者の立場からの文章です。書籍に書かれていることを、金科玉条のように扱いすぎてはいけません。
参加者がそれぞれ意見や感想を表明し、お互いの視点で話し合うことこそ、輪読会の意味、醍醐味だと思うのです。そうしないと、一人で読むのと何も変わらなくなってしまう。皆で読むからこそ、多面的・多角的に書籍の内容と向き合えるのではないでしょうか。
適切なファシリテーションが必要なこと
とは言っても、放っておいてもなかなか意見や感想は出てきません。今回の場合だと、私が内容について補足したり（歴史的経緯や、他のプログラミング言語の様子とか）、意見を言ってから皆に意見や感想を聞いたりしています。
促してもなかなか出てこないことも多かったり、特定の参加者しか発言しなくなってしまうこともあるので、全員に何かしら話してもらう工夫が必要です。
あとは聞き方ですね。「どうですか？」だと漠然としすぎてしまうので、トピックを絞った方が話しやすいです。具体的な事例（普段扱っているコードとか）に置き換えて話すと、盛り上がることが多いですね。担当者がそのような例を持ち出してくれると、話が弾みます。
わからないときはわからないと言っていいこと
そうして意見や感想を募ると、なかなか「何を言っているかわからなかった」とは言いづらいかもしれません。しかしそれもまた一つの感想なので、できるだけ表明してほしいと思います。そうすると、どの部分がわからなかったのか、その理由は何なのかを考えられるようになりますし、皆でサポートできます。
輪読会の目的として、参加する皆のレベルや視線を揃えていきたいというのもあったりするのです。知識的な部分はもちろん、「書籍に書かれていたあのやり方」が話として通じるようになると仕事がとても捗ります。だからこそ、わからないときは素直に言いましょう。せっかく皆で読んだはずなのに理解していない人がいる、という残念な状況は避けたいところです。
最後に
輪読会にはいろいろなやり方があると思いますし、参加者や題材である書籍によって適したやり方が違う部分も多々あるでしょう。しかしせっかく皆で一冊の本を読むのですから、一人で読むのとは違う体験をできるようにしたいですね。
学習のきっかけとしてだけではなく、理解の深化や共有につながる体験として設計・実施できるようにしていきたいところです。
