Zenn
📖

社内で開催した技術書輪読会の振り返り

2022/11/11に公開
#
技術書
#
輪読会
#
データ指向アプリケーションデザイン
idea

概要

社内で開催した技術書輪読会が16回目にて終わりを迎えたので、自身のためにも本記事で振り返りを行っていきます。

輪読会の書籍に採用した書籍は、以下となります。

データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理

私自身が輪読会を企画・開催・運営していくことは初めてです。
当初に期待していた通りには進行できませんでしたが、進行できなかった問題から反省点や改善点を見出すことができた良い機会でした。

問題点

途中から自分を含めた参加者が2人で輪読会を開催していくこととなってしまいました。

残った参加者はバックエンドを本業としないモバイルアプリエンジニア（私）と入社したばかりの新人エンジニアでした。

そのため、経験に基づいて、書籍内に関連した深い内容を話せる環境を作ることができませんでした。

輪読会を開催しようと思った背景

今回の輪読会を開催しようと思った背景として、主に以下の2つが挙げられます。

  • 社内での技術的な知識の共有を促進したい
  • 輪読会を通じて、異なるプロジェクトに携わる開発者との交流機会を設けたい

複数のプロジェクトが進行している弊社では、プロジェクトを超えた技術的な知識の共有が少ないと感じていました。

また、プロジェクトを超えた開発者同士の交流は、今年に入ってからどんどん減ってきていました。

別のプロジェクトにいるすごい技術や経験を持った開発者たちとの何気ない雑談から知識の共有をしたいという思いがあります。
その一方で、プロジェクトの多忙によって業務時間内に雑談をする余裕がなかったり、業務時間中は雑談はせずに業務に集中したい開発者もいます。

そこで、輪読会という時間を設けて、社内の技術的な知識の共有を促進するとともに、異なるプロジェクトに携わる開発者との交流機会を設けようと思いました。

残念だったこと

輪読会を通じて、異なるプロジェクトに携わる開発者との交流機会を設けたい

私自身は上記の目的を叶えることができましたが、同じプロジェクトで開発しているモバイルアプリ開発やフロントエンド開発側からは参加者を募ることができませんでした。

そのため、社内全体的にはモバイルアプリ開発者の私と日々同じプロジェクトで開発するバックエンド開発者というグループとなりました。

書籍の選定理由

冒頭で触れた輪読会に採用した書籍「データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理」を選定した理由は以下となります。

注: 参加希望者は書籍を会社経費で購入することができました。

企画した輪読会の形式と進め方

輪読会の開催周期は毎週に設定し、開催日時は私含めて合計6名の参加希望者から調整さん上でアンケートを取って決めました。

曜日：毎週火曜日
時間：8:00 ~ 9:00

なぜ朝に開催することにしたか

個人的な理由ですが、企画者である私自身が家庭内の状況で業務終了後の夜にVCができる環境を作れないためです。

また、朝に開催する輪読会で技術的な議論を行うことで、脳がウォームアップされた状態で業務を開始することができ、その日は午前中から生産性の高い動きができるメリットも期待しました。

輪読会の進め方

輪読会に継続して毎回参加してもらうために最も重要視したことは、「継続した参加へのハードルを下げること」でした。

各週ごとに担当者を決めて、読む範囲の内容をまとめて発表するような典型的な輪読会の形式では、参加者の負担は大きく、継続した参加を行ってもらうことが難しいと判断しました。

私が今回の輪読会で導入した進め方は、以下のようになります。

  • 各週で読む範囲を15-30ページ程にすること（読む範囲の難易度や章の構成により変動する）
  • 読む範囲を各自で事前に読み、社内共有ノートに分からなかったこと、気づいたこと、調べて分かったをまとめること
  • 輪読会当日に、各自でまとめた内容を皆で共有し、理解できなかったことを補完し合うこと

ちなみに、弊社ではフルリモートワークのため、朝起きてすぐにPC開いて輪読会に参加することができます。

起きたこと

初回と2回目は全員が参加してくれましたが、3回目から一人の参加者が寝坊して欠席し始め、ポツポツと参加者が減っていきました。

そして、6回目からは私ともう一人の新人エンジニアだけとなりました。

反省点

  • 事前に満場一致で決めた開催曜日と時間でしたが、早朝に開催して継続した参加を促すことは難しいこと
  • 分厚い書籍のために開催回数が多かったこと
    • 「定期的に興味関心が移り変わるエンジニアにとって、長期間一つのものに継続して関心をもって取り組むことを求めることは難しい」という声を聞きました
  • 任意参加だったため、欠席し始めた人に一人一人声がけを遠慮したこと

今後やっていきたいこと

  • 社内の業務時間で行えるように働きかけること
    • これができればベスト
      • メリットを上層部にアピールする必要がある
      • 全員参加の場合、普遍的・全般的な書籍を選定する必要があり、面白みがないものになる可能性がある
  • 開催回数がそれほど多くならない書籍を選定すること
    • 開催回数が4-8回（1~2ヶ月）になる書籍を選定すべか
  • 何かしらの理由で欠席した人には、雑談の中でフォローアップを入れてあげる
  • 開催途中で無名アンケートを取り、フィードバックをもらって改善していくこと

ある程度の参加強制力も持たせるために以下のような制約も課すことも考えなければいけないと思っています。

  • 最低でも半分以上の開催には出席することを義務化する
    • 最終的に開催の半分以上に出席できなかった場合には何かしらの罰を与える
      • 例
        • 自分の好きな技術や関心のある技術について、全員の前で発表する
        • 次回の輪読会の企画し、開催する（運営は他の人も協力する）
GitHubで編集を提案

Discussion