はじめに
こんにちは。プラットフォーム事業本部メンバーシップサービス部の松下 (@_kentaro_m) です。DMMのサービス全体で利用されるアカウント基盤システムの開発を担当しています。
先日まで六本木と金沢の2拠点で分かれて開発しているチーム内で輪読会を行っていました。私自身、社内外の勉強会に参加することはあっても、これまで運営を行ったことはなかったので、今回が手探りの状態で輪読会の準備から進行までを担当した初めての会になりました。
チーム内の勉強会という小規模なものですが、実際にやってみると様々な学びを得ました。そこで本記事では、輪読会の準備から実施までの流れと実際に運営を行って得た学びをお伝えしたいと思います。
輪読会を始めた経緯
所属部署でチームメンバー向けの教育プランの策定から実践までを体験してみようという趣旨の募集が行われました。
私はこれまで開発業務がほとんどで教育にかかわる機会が少なかったこともあり、面白そうだと感じて参加を決めました。
他のチームでは以下の形式でチームメンバーの教育が行われていました。
- 業務で使用している技術のLT会
- エラー監視の勉強会
- Value Stream Mapping作成の勉強会
私の所属するチームでは、チームメンバーの意見から輪読会が選ばれました。
輪読会開催の準備を行う
輪読会開催にあたり、輪読本の選定と輪読会の開催方針に関して、資料を作成してチームの同意をとりました。また、当日のタイムスケジュールと要約シートの作成もあわせて行いました。
輪読本の選定
輪読する本の選定は以下の流れで行いました。
- 読みたい本の候補をチームメンバーから受け付ける
- Polly (Slackで簡単なアンケートをとれるアプリ) で投票を実施する
- 投票数が一番多かったカイゼン・ジャーニーに決定
アンケートを実施した様子
開催方針の決定
開催方針の決定のために、輪読会の目的と進行方法の共有を行いました。
- 輪読会の目的
- なぜ輪読会を行うのかを共有した
- 今回はカイゼン・ジャーニーで紹介されているアジャイル開発のノウハウの理解を深めつつ、開発にどのように活かせるかを考えることが狙い
- 進行方法
- 輪読会の開催日時や必要な準備、当日の進行を共有した
- 今回ははじめての運営なので社内や他社での実施を紹介して、チームメンバーから意見をもらった
チームメンバーに共有した輪読会の資料
事前に輪読会について調べたところ、以下のやり方で実施されているケースが多いようでした。
- 参加者は当日までに指定された範囲を読んでくる
- 発表担当者は指定された範囲の要約や自身の解釈をまとめる
- 当日は発表担当者が準備してきた内容を話し、参加者で議論する
輪読会開催にあたって、重視したのは継続です。
今回はチームメンバーの教育が目的なので、輪読会を継続して開催したいという主催者の思いがありました。上記のやり方では準備が多すぎて、立ち行かなくなる不安があったので、その場で読んで、まとめて、発表するスタイルで行うことにしました。”とりあえず本を持ってくればなんとかなる”点にメリットを感じての採用です。
タイムスケジュールと要約シートの作成
輪読会の当日に備えて、読書や議論の時間を示すタイムスケジュールを作りました。
また、内容の要約や自分の考えをまとめるために、Compass Pointという手法をベースにしたテンプレートを準備しました。
Compass Pointとはあるトピックに関して、4つの視点から意見を出しながら、自らの考えを明らかにするための手法です。
この手法では、考えを出すまでのプロセスをチームメンバー同士で見ることができるので、メンバーがどのような点に着目しているのかがひと目で分かります。
c.f. Compass Points | Project Zero
今回はカイゼン・ジャーニーで紹介されているプラクティスをチームの開発に活かすために、どうすれば実現できるか、現状のものをさらに良くするためにはどうすべきかという点を考えてもらうことにしました。
輪読会を開催するも、輪読する意味を問われる…
もくもくと本を読むチームメンバー
輪読会当日は2拠点をテレビ会議システムで接続して、下記の時間配分で進行していきました。
- 読書時間: 20分
- 要約及び考えをまとめる：15分
- 発表及び質問：15分
初回はうまくいきませんでした。各自が発表した内容から質問や討論が生まれることを期待していましたが、質問も討論もなしで淡々と発表して、時間が来て終わるという中途半端な形になりました。
輪読会終了後に一人で振り返りつつ、チームメンバーにも輪読会運営について意見を求めました。
その結果、4つの問題点が挙げられました。全体的な意見としては個人作業が多く、グループで読書するメリットが活かしきれていないという声が目立ちました。
- 個人作業の時間が多く、集まる必要性がない
- 読書20分とまとめる15分で、輪読会の半分以上の時間は1人作業していた
- 本を読んでいる間の長い沈黙が辛い
- 参加者同士の議論がなく、集まる必要性がない
- 自分がまとめたものを順番に発表
- 発表したものに対して、議論が生まれることはなかった
- 本に要約が載っているので、再度まとめる必要がない
- カイゼン・ジャーニーは1話ごとにアジャイル開発の手法を1つ取り上げている
- 前半は主人公が学んだ手法がストーリーで紹介、後半はその手法の解説という構成
- Compass Point自体、まとめる量が多くて辛い
- 選定した本を読みたいという熱意が不足していた
- 投票で選定された本は少数派の意見が反映されていない
- 読まされている感が強い
フィードバックを受けて、輪読会のやり方を変える
初回開催の結果を見て、このままのやり方で継続するのは難しいと考え、やり方を変えることにしました。先に挙げられた良くない点を解消するために下記の対策を取り入れました。
- 要約・考えをまとめるのをやめて、気づきを書いてもらう
- 議論する機会を増やす
要約・考えをまとめるのをやめて、気づきを書いてもらう
カイゼン・ジャーニーは1話ごとにプラクティスの解説があるので、Compass Pointをまとめるのはやめました。その代わりに本を読んで得た「気づき」をオンライン共同編集ツールのDraw.ioで準備したページに付箋で貼ってもらうことにしました。
ここで言う気づきとは、本を読んでみて共感したことや疑問に思ったこと、チームでも活かせそうなことを指しています。
気づきを書いてもらった狙いとしては、以下の2点がありました。
- 形にこだわらずに思ったことを書いてもらことで意見を出すハードルを下げる
- カイゼン・ジャーニーのストーリーやプラクティスと普段の開発のやり方を結びつけて考える
これらを実施したことで、意見を出すハードルが下がり、現状を振り返ることで今後何をしたら良いのかという議論が活発になりました。
議論する機会を増やす
輪読会の様子2: 議論の模様
輪読会の様子3: 金沢と六本木でテレビ会議を繋いで実施
個人作業時間の長さによって生まれていた不満の解消には、輪読会の中でチームメンバーが話す機会を増やしました。
チームメンバーを拠点別に2チームに分けて、輪読会ごとに各チームの議論を仕切るファシリテーターを指名しました。議論するテーマは本を読んで得た「気づき」をチームの開発に活かすための方法を見つけることに設定し、チーム内議論と他チームへの結果共有を複数回繰り返す形式にしました。
輪読会の進め方を変更したあとのタイムスケジュールは以下の通りです。
- 個人で気づきを出す
- 各チームで類似した気づきをまとめる (グルーピング)
- 各チームで出た気づきをファシリテーターが他チームに共有
- 各チームで気づきを1つ選び実現方法を考える
- 各チームで出た実現方法をファシリテーターが他チームに共有
進め方の変更により、本の理解を深めるよりも、本をきっかけにして普段の開発の振り返りに重きを置けるようになりました。
スクラム開発を2年経験しているメンバーからすると、本の序盤のプラクティスは知っている項目が多く、開発手法の振り返りの方向に会を持っていけたのは結果的に好評でした。
輪読会を主催して学んだこと
輪読会を継続して運営するために大事な6つのことを学びました。下記ではそれぞれの項目に関して、今回取り組んだことと感じたことを紹介します。
- 参加へのハードルを下げる
- 目的の設定が大事
- 参加者の知識レベルを考慮する
- タイムスケジュールを組む
- 議論が生まれる工夫をする
- 参加者の意見に耳を傾ける
参加のハードルを下げる
- 参加者の負担が増える事前準備をなくす
- 参加者は事前準備なしで本を持ってくれば参加できる状態にする
- 読書やまとめなどすべての作業を輪読会で行う
- 輪読会の読書時間で読み切れる自信がない人はあらかじめ読んでくる
資料などの事前準備は、参加者の負担が増えるので避けるようにしました。気軽に参加できる仕組みにすることで、継続的に参加者を集めることができると考えました。
目的の設定と共有が大事
- 主催者と参加者が同じ方向を向いて活動できるように、様々な意見を取り入れて目的の設定を行った
- 輪読会の方針を作成した時や輪読会の冒頭で目的を随時共有した
目的は、参加者が輪読に取り組む意味合いです。本についての理解を深めることや扱われているトピックについて議論したいという気持ちがそれにあたると考えます。目的の認識が参加者間でずれてしまっていては、期待した結果が得られない可能性が高まるので、はじめに認識を合わせておくのが良いと思います。
参加者の知識レベルを考慮する
- 参加者の知識レベルを事前に調べて、理解重視にするか議論重視にするかを決める
知識レベルと輪読会の内容が乖離していると、難しくて内容についていけないか、簡単すぎてつまらないという理由で参加者が離れてしまうことが考えられます。理解重視であれば、要約や解説に重きを置き、議論重視であれば、参加者同士で話をすることに多くの時間を割くのが良いと思います。
メリハリのあるタイムスケジュールを組む
- 読書や議論に何分使うかを決めて、輪読会のはじめに共有する
- タイマーを使用して、時間厳守で進行する
時間を守ることは非常に大事です。だらだらやってしまうと、参加者の気持ちが緩んでしまいます。 スケジュールの共有と時間厳守を意識して、目的を達成できるように進行していきましょう。
参加者間で議論が生まれる工夫をする
- 意見をまとめるシートを準備
- 付箋を使用し、気軽に書ける環境を整備
- 話しやすい人数のチームを作る
- 今回は1チームMAX4人に設定
- ファシリテーターを交代制にする
- 議論の状況を共有する
- 他チームの意見を自チームでも考えてみる
- 議論が発散しないようにする
- 1回で答えを出すのではなく、発表と議論を繰り返し答えを出していく
議論が生まれやすくするためには、意見を出しやすい環境と結論に導くための促しを行うことが大切だと感じました。環境作りに関しては、話しやすい環境を作るのが大事だと思います。参加者同士の関係性によってはアイスブレイクを実施しても良いと考えました。促しについてはまずは段階を踏んで考えていき、最後に結論を出す形で進行していくほうが、より練られたアイデアが出ると思います。
参加者の意見に耳を傾ける
- 参加者と連絡を取れるSlackチャンネルを準備する
- 参加者の意見を輪読会に反映する
はじめから完璧な運営を行うのは難しいので、参加者の意見を聞く手段を設けて、継続して改善していくことが大切です。主催者だけでなく、参加者も一緒になって皆で輪読会を作っていく姿勢が大切だと感じました。
さいごに
輪読会を1ヶ月 (5回) 実施後に参加者にアンケートを取りました。その結果、内容や運営には8割方満足しているという嬉しい回答を得ました。さらに議論から生まれた開発の改善点を実際の業務に取り入れる事例もいくつか出てきて、実りのある輪読会になったように思います。
もともと、チームメンバーの教育のために始めた輪読会でしたが、一番学びがあったのは主催した私でした。最初の運営の躓きから持ち直せたのは、チームメンバーの率直な意見があったからだと考えます。
今回得た学びの多くは輪読会に限らず、様々な勉強会の運営でも使えるものが多いと思います。今後も勉強会に意欲的に取り組んでいきたいです。