この記事は BASE アドベントカレンダー2日目の記事です。
勉強会の隠れた課題「読書会のジレンマ」に立ち向かう
BASEでシニアエンジニアをしているプログラミングをするパンダです。
この記事では普通の社内読書会をレベルアップする方法を紹介します。自分の所属するチームでは2ヶ月に渡る勉強会でこの方法を実践した結果、参加者の全員が書籍の内容をしっかり学べたという手応えを感じています。実際に、チームメンバー全員から今までよりも効果的な読書会だったと感想を貰えました。
結論を先に書くと、その方法は自分たちが触っているレポジトリから書籍の内容に当てはまるところと、書籍の内容を実現できていないところを探して発表するというものです。つまり、本で得た知識をすぐに使うというアクティブラーニング志向の読書会です。
そもそも読書会というものは、課題の書籍を読んできてその感想を共有するやり方が一般的です。ただし、この方法はパッシブな読書体験であり、読み手のスキルによって知識の定着量に差が出てしまいます。なぜなら、技術本の読書会の目的はみんなの知識レベルを揃えることなのに、本を読みこなすためにはそれなりに事前知識やスキルが必要だからです。このことを私は「読書会のジレンマ」と呼んでいます。
読書会のジレンマは読書会に必ずついて回る課題なのに、読書会での学習効果は学習者自身の責めに帰せられるが故に大っぴらに語られることのない隠れた課題でもあります。この読書会のジレンマについて、以前ある勉強会の発表で触れたところ「うちの会社でもあります」と共感を得られました。そこでこの課題は普遍的なことだと思ったこと、勉強会の工夫によってこの課題の解決に一定の成果が出ていることから記事にして公開することにしました。
勉強会の隠れた課題が露見した瞬間
BASE 社内では読書会が盛んに行われています。あるプロジェクトが組成された後、プロジェクトの完遂までに1,2回ほどは各チームで読書会が開催されるように思います。もちろん業務時間内にです。
私が読書会のジレンマに気づいたのは、かつて自分が所属していたチームで読書会を開催した時でした。技術雑誌のある特集を教材として2回の短期的な勉強会を実施しました。
その方法は以下です。対象範囲を事前に読んで感想をドキュメンテーションツールに記述し、勉強会当日にそれを共有する。疑問が共有されれば、その場でその疑問をみんなで一緒に考えるというごくごく一般的なスタイルです。
読書会の開催後、短い教材の中から「実務に活かせる」とそのエッセンスを読み解いて翌週のプルリクエストに学んだ内容を反映したメンバーもいれば、「書かれている内容は理解したが、実務に活かせるイメージが湧かない」という感想を共有したメンバーもいました。
自分にとってこの言葉はショックでした。読書会の教材は実務に活かすためのものであり、「ここに書かれていることは今の自分たちのコードのここに活かせるな」と考えながら読むもので、それこそが実用書の価値というものです。
「内容はわかったけど、実務にどう活せばいいかわからない。」この言葉は自分に勉強会のあり方を再考させるきっかけとなりました。そして、次はこのフィードバックを活かした勉強会を開催しようと心に決めました。
チームのスキルレベルを揃えるための勉強会を開くために
そのチームは無事にプロジェクトを完遂して解散した後、全く異なるメンバーで新しいチームが組成されました。
チームメンバーには転職してきたばかりの方もいました。どのチームでも最初はそうなのですが、全員のスキルレベルが揃っていないが故に、開発初期のコードレビューでは「本当に届けたい機能、実現したい仕様」といった本質的な議論よりも「このときはこう書くのが一般的です」という表面的なレビューのコメントが増えていました。
開発の現場で学習のコストは見過ごされているように思います。実のところ勉強会というものは、事前の見積もりに含まれない隠れた教育・学習のコストです。つまり、「開発の期限は、開発者が不足しているスキルを補う時間を考慮していない」のです。これはアジャイル開発かどうかは無関係です。
少ない時間でチーム全員をある程度同じスキルレベルにまで手っ取り早く引き上げる手段を採用したいと思うのはごく自然なことです。この課題を解決するために、オブジェクト指向設計スタイルガイド の勉強会を開催することに決めました（この本の選定理由はスライド「軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう」をご覧ください）。
しかし、事前に読んで感想を共有するベーシックな勉強会のやり方では以前の二の舞になる可能性があります。前回の勉強会を反省した結果、そもそも勉強会には「読書会は参加者のスキルアップのために実施するのに、そもそも読み手のスキルレベルによって吸収量に差がある。その結果、学習効果は一様ではない」という勉強会のジレンマがあることに気づきました。
そこで、このジレンマを解消するためにアクティブラーニングな勉強会を実施する方法を考えました。
アクティブラーニング志向の勉強会で知識をすぐに活用する
アクティブラーニング志向の勉強会では各自の感想の共有を実施しません。代わりに以下の2点を勉強会で議論することにしました。
- 書籍の内容で理解できなかったこと、疑問に思ったことをメンバーに共有する。その内容が理解できるまで、疑問が解消するまで徹底的に議論する
- 書籍の内容と自分たちが開発しているレポジトリのコードを照らし合わせて、書籍の内容を実践出来ているところと出来ていないところを pick up して紹介する
勉強会の開催にあたり、まずチームメンバーに対して勉強会のコンセプトを共有しました。コンセプトはアクティブラーニング形式であることを表現したものです。
コンセプト
- 議論中心。知識をそのまま覚える暗記に加えて、なぜそれが有用なのか、あるいは不要なものがあるかを語り合う
- コードで実践！とにかく実践！新規実装でもリファクタでもすぐに実践する！
次に各回の進め方と事前に準備してもらうことを共有しました。
各回の進め方
- 各設計スタイルで理解できなかった点を共有してもらい、それについて議論する
- 「このスタイルを採用するメリットがわからない」とか
- 自分が気に入ったスタイルを反映しているプロダクションコードを最低1つ紹介してもらう
- 「スタイルを反映していないので、これからリファクタか改修したい」というコードでもOK
準備してもらうことは負担が大きくなりすぎないように設計しました。
準備してもらうこと
- 1章ごとに
- 疑問を持った設計スタイルを書いておいてもらう
- いくつでも
- 気に入ったスタイルが反映されている、もしくは反映されていない backend のコードを pick up してもらう
- 最低1つ
- 疑問を持った設計スタイルを書いておいてもらう
本を読む、コードを探す、本の知識でコードを批評する。この3ステップがアクティブラーニング志向の勉強会の構成要素です。
実際に参加メンバーが共有した内容はこちらです。「本番コードでの assert の使いどころ」や「getter でプロパティを検証していることは Allways Valid なドメインモデルではない」などかなり踏み込んだ疑問や指摘がされているのがわかります。実際にこのときの議論は盛り上がり、また建設的な内容になりました。
アクティブラーニング志向の勉強会の効果を振り返る
勉強会の開催以降、コードレビューでは「このときはこう書こう」という一般的な指摘がほとんどゼロになったため、実際に効果があったと言って良いでしょう。「ここは本に書いてましたよ」ということもほとんどありませんでした。
さらに、オブジェクト指向設計スタイルガイドは良書であるため、チーム全体の設計力も向上しました。
これらの結果は勉強会の目的通りだったので一安心しました。しかも、当初想定していた以上の成果を出すことが出来たのは自分にとって驚きでした。それは、参加メンバーからの勉強会に対するフィードバックの内容に表れています。
本文の質問をきっかけに心理的安全性を醸成
フィードバック1「書籍を読んで感じた疑問についてみんなに聞いて考えることで、書籍の内容をきちんと理解できた」
疑問に対しては誰か知ってる人が教えるというのではなく、みんなで一緒に考える雰囲気を作ることを意識していました。思わぬ効果として、何でも質問ウェルカムな雰囲気の中で自分が持つ疑問についてきちんと議論することで「自分はここで何を聞いてもいいんだ。わかってないやつだとバカにされないんだ」という心理的安全性が醸成されました。
チームでは勉強会が終わった後もこの雰囲気は継続しています。後日あるメンバーと1on1をしたところ「何を聞いてもみんな優しく答えてくれるので安心して働ける」と言って貰えたのでチームビルディングにも役立つことを体感しました。
スタイルの適応例探しから業務外のコードリーディングへ
フィードバック2「事前準備をする中で、今触っているレポジトリから本に関係するコードを探してくるので、書籍の内容の使用イメージがすぐに湧いた」
この点に関しては狙い通りです。さらなるフィードバックとして「普段開発している箇所以外から垣根をこえてコードのサンプルを探しに行くので、システムの中心的な部分など他のところでどんなクラスがあってどんな処理をしているのかを学ぶきっかけになった」と言って貰えました。
こちらも思わぬ効果です。実際、ある人はAというモジュールに対象のコードを探しにいき、ある人はBというモジュールに探しに行くとします。すると、それぞれの人はAモジュールとBモジュールのコードリーディングをして「こうだった」と発表をします。その知識は勉強会のメンバー全員に共有されるため、「ここは触ったことがないけどこういう作りになってるんだね」とみんなの視野が広がりました。
スタイルに従ってコーディングしたら、コードの良し悪しの言語化が上達した
フィードバック3「スタイルに従うことで自分の考えていることをうまく表現できるため、コーディング中に迷うことが減った」
このフィードバックには続きがあります。「それに加えて、スタイルの原理原則に従っていないコードの違和感に気づける上に、それがなぜ、どのように違和感があるのか説明ができるようになったのは大きな恩恵です。」
良いエンジニアはコードを書いている間も「本当にこの書き方がベストだろうか」と自分に問い続けています。スタイルガイド本を学ぶことでこのセルフレビューの質が上がりました。他の人が書いたコードに対する違和感を言語化してうまく説明することができるようになったため、コードレビューのスキルもアップしています。
まとめ
読書会の準備と内容を見直すことにより、冒頭の「本の内容はわかったけど、実務にどう活せばいいかわからない」という課題に対処できました。もちろん書籍が扱っている内容によるものの、この勉強会の方法自体は社内勉強会でも社外の人たちと集まって輪読する会でもそのまま適用できると思われます。
普通の勉強会をぜひ学習効果の高い勉強会にバージョンアップしていきましょう。
BASEではWebアプリケーションエンジニアを積極採用しています。興味のある方はぜひご応募ください。
