一人では読み進めるのが辛い「SRE本」社内輪読会のススメ

株式会社ビズリーチで、SREエンジニアとして勤務しているmassです。2017年4月に入社してから、HRMOSというサービスのAWSのインフラを管理したり、アーキテクチャの設計・構築をしたりしています。

今回は、技術的な話ではなく、昨年11月に開始した社内輪読会と、そこで得られたものをご紹介したいと思います。

発端

輪読会を始めたきっかけは、2017/08月に発売されたSite Reliability Engineering(以下、SRE本)という書籍でした。

この本を知っている方も多いかも知れませんが、本の紹介にある通り、 Site Reliability Engineering(Googleで培われたシステム管理とサービス運用の方法論) についてまとめられた本です。

今回の記事ではSite Reliability Engineeringについて深堀はしないため、簡単な紹介にとどめます。 とても良い本なので、まだ読んでない方、特に何らかのプロダクト開発に携わっている方にお勧めします。

話を戻すと、SRE本を購入して読み進めていくうちに、素晴らしい本であると思いつつも、以下の2点の気持ちが出てきました。

  • そこそこのボリュームがあり、一人で全ての章を読み切るのは辛そう
  • チームメンバーと共に読むことで、チームにとって良い効果がありそう

さらに、周囲のメンバーが、本に出てくる用語(エラーバジェットやポストモーテム)を使い始めているので、実はみんなひっそりと読んでいそうということもわかりました。

この時点で輪読会を開いて見ようかなという気持ちが湧いてきて、slackで提案してみました。

slack2

slackのキャプチャを貼り続けても良いのですが、それだけで埋まってしまいそうなので、結論だけいうと、めでたくSRE本の輪読会を開催することになりました :tada:

進め方を決める

輪読会を開くにあたって、周囲のメンバーから色々とアドバイスや質問が出てきました。以下が、実際に挙げられた質問の一部です。

  • 業務時間にやるの?やらないの?
  • 目的を持つの?持たないの?
  • どう読み進めて行くの?先頭から読むの?
  • 本を朗読するの?それとも概要をまとめて発表するの?

slackでカジュアルにやり取りしていたためか、チーム内外で声が上がってきて非常にありがたかったです。

まず、勉強会・輪読会用のレポジトリをGitHubに用意して、資料等を管理するスタイルで進めることにしました。 github_1

ルールを決める

次に必要最低限のルールを決めました。ルールは輪読会をスムーズに行えるようにするもので、それ以上の目的はありません。

基本ルール

  • 輪読会用のGitHubレポジトリで資料管理をする
  • スプレッドシートで章の一覧を作成し、担当したい章に名前を記入する
  • 週に一回、木曜日の16時〜17時に開催する

SRE本の輪読会では、本の性質を踏まえ、上記に加え、以下のルールを儲けることになりました。

  • 先頭から読むのではなく章単位で、好きなところを選ぶ
  • 章の担当者は、担当章を読み、概要をまとめて輪読会時に発表する

目的を持つ

  • 開発効率・品質向上に向けた意識向上
  • 開発効率・品質向上に向けた施策検討及び実施

経過

参加人数

  • 開催当初 5~10名 yousu1
  • 現在 15〜30名 yousu2

行ったこと

  • 輪読会スタートしたので、開催時間・場所・進め方など手探り
  • 社内で輪読会を宣伝したりして、他部署からの参戦も :tada:
  • 輪読会とはスタイルを変えて、参加者の困りごと(issue)をGitHubのissueに起票して、解決策を議論する会を特別会として開催
  • 年末に輪読会のアンケートを実施 :memo:
  • 年明けからslackの機能を利用してremoteでの参戦も開始

得たもの

  • 共通言語

DDD(Domain Driven Development)で言われるユビキタス言語に近いものを感じました。例を挙げると、トイル、ページャー、エラーバジェットなどですが、小さな会話のやり取りが積み重なり、共通言語が生まれたなと感じました。

  • 視野の共有

同じチームにいても、見ている世界やゴールを揃えるために、大なり小なりコストを支払っていると思います。

輪読会では、議論をすることで視点の違いなどが無意識のうちに共有され、お互いが見ている世界を知る良いきっかけとなったと感じました。

  • チームの壁を超えたやり取り

当初は所属しているチームメンバーだけでスタートした輪読会ですが、他のチームも参加してきて、参加者の職種も多様性が出てきました。(SRE、開発者、DBA、QA、セキュリティ、インフラなど)

他チームの良い事例を真似したり、アドバイスをもらえたりなど、良いサイクルが生まれたと感じました。

生まれたもの

いくつか詳しく紹介したいのですが、ここではそれぞれについて簡単な説明だけ載せます。 詳細を知りたい方は、是非SRE本を読んでください。重ねて言いますが、とても良い本なので!

ポストモーテムとは、直訳すると、事後分析・事後検証

インシデントとその影響度、緩和や解消のためのアクション、根本原因、インシデントの再発防止策を記録するもの

インシデントから学びを得るための定式化されたプロセス

輪読会は、これらのポストモーテムのうち、良いポストモーテムを輪読し、学びを得る場所

まとめ

現在はSRE本を読み終えて、別の本を読み進めていますが、輪読会の参加者はほぼ変わらず、複数のチームが参加しています。

輪読会を行うことで、同じ本でも一人で読むより、知識を深められ、かつ、チームに実際に導入する仕組みや制度を作ることができました。正直、一人で読み進めるよりも完全に旨味しかなかったので、今後はチームで読んだ方がいいかも、と感じた本は輪読会を提案しようと思いました。

また、輪読会を開くにあたり、強く意識していたのは、ハードルは低くルールはなるべく作らない 、という部分でした。 この二点を意識したことが、多種多様なメンバーの参加につながり、半年を越えた継続的な開催にも繋げられたと思います。

現在はk8s勉強会も開催しており、こちらもスモールスタートで開始しましたが、社内で利用している箇所が少ない技術といううこともあり、手探り感があって非常に面白いです。

開始した動機そのものは、冒頭に書いた通り、チームメンバーで読んだ方が面白そう、一人で読むの辛そう、など本当に小さなものでしたが、予想以上に得られるものが多かったです。

今回、技術的なtopicではなく、SRE本の紹介でもなく、あえて輪読会そのものを記事のテーマに選んだ理由は、輪読会やってみたいなと考えている人の背中を押せたらなと思ったからなので、記事を見て、輪読会やってみようと考えてくれた方がいたら幸いです。