『システム運用アンチパターン』で輪読会を通して知見共有ができた話

プロダクトエンジニアリング部の二宮です。

我々のプロダクトエンジニアリング部では「強い個人・最高のチームになることで価値創造を加速させ続ける」というビジョンを掲げています。そして、その「強い個人」を目指して、週に数時間程度、普段できないチャレンジングな技術の探索など、ある程度自由に時間を使うことが推奨されています。

その一つのやり方として、最近は社内で技術書の輪読会をすることが流行ってます（以前、LIFULLクリエイターズブログにも「"INSPIRED"の輪読会を通してふりかえるプロダクト開発」という記事も共有されています）。

今回は、2つのチーム合同で『システム運用アンチパターン』を読み終わり、その輪読会がなかなか好感触だったので紹介します。ある程度ベテランのエンジニアが持つ知識を身につけるとともに、本の内容に触発された議論も同時に行えたと思っています。

輪読会とは

まず、輪読会とはなにかに説明します。weblio辞書から引用します。

人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。

ちょっと話を先取りすると、個人で勉強するより「質問ができる」「その場で自分たちの文脈での議論ができる」などのメリットが感じられました。

輪読会の実施方法

輪読会には様々なやり方があるのですが、私たちが実際にどのように実施したのか紹介します。これ以外の方法を幅広く知りたい方は「輪読会のすゝめ。全8回の開催で学んだ失敗パターンと成功のコツ」などの記事が参考になると思います。

参加者

担当プロダクトが別の2つのチームが合同で行いました。人数は6人で、全員がソフトウェア開発がメインのエンジニアです。

本の選定

候補に挙がったのは次の3つの本です。

「主管システムに関わらず共通しているシステム運用の実務に関して学べそうな内容で、比較的短期間で読み終わりそう」という理由で『システム運用アンチパターン』を選びました。

重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。

本の内容もけっこう面白く、後述する「過去の失敗談をフラットに共有できた」「開発文化について考える機会となった」みたいな感触は、この本のテーマのおかげが大きかったんじゃないかと思います。

実施方法

「各章の担当者を決め、毎週輪読会の時間を取り、1章ずつ担当者が内容をまとめて発表する」というオーソドックスな方法で行いました。輪読会本編は前半で発表を聞きながら質問やコメントを表に書いていき、後半でそれを元に話をする形式です。

このように、「社内の文脈に置き換えるとどうなのか？」とか「実は本の内容と近い失敗をして後悔してるんだ」とか話が広がりました。

輪読会をやりながら、工夫して変えた点は2点あります。自分たちにとって輪読会ははじめての経験だったため、途中で一度振り返りの時間を用意していました。

輪読会の時間を15分に設定していたが、めちゃめちゃ駆け足になってしまったため30分に延長した
まとめ方は完全に自由だったが、「どこまでまとめればよいかが分からなくて大変じゃない？」「自分の経験も絡めた話もあったほうが面白そうだ」みたいな声が上がり、簡単な推奨フォーマットを用意した

フォーマットといっても、要約や章のポイントを箇条書きし、関連するエピソードや自分なりの解釈をコメントするという簡単なものです。

実施した実感

輪読会の後に振り返りでは、次のようなメリットが感じられたという意見が出ました。

本の内容に触発され、ベテランの過去の経験を聞くことができた。過去の失敗談をフラットに共有できた
他の人に説明する必要があるので、担当した章の内容を、分かったつもりにならずに理解できた
社内の開発文化について自分の立場から貢献できることはないか考える機会となった
共通認識ができて、その場で現状改善のアイデアの議論ができた
会話が弾んだ。単純に楽しかった

特にこの本の内容はネガティブさとポジティブさのバランスが絶妙だったと思います。例えば「第10章ブレントだけが知っている」には次のような話がありました。

意識しないとキーパーソン（『The Phoenix Project』の登場人物のブレント）に知識が集まる

情報を積極的に共有すればいい？→公開するだけでは興味を持てるわけではない

ひどいと誰も全体を見なくなる

私自身もそうだったことがあるように、「せっかく情報共有のドキュメントを書いたのにみんなが興味を持ってくれない」「組織文化がドキュメントの重要度を理解してない」という、自分自身のモチベーションを下げ、冷静な議論を妨げてしまう形で悩んでしまうことも多いと思います。

ただ、そのような失敗例を共有するだけでなく、「実はドキュメントだけでなく別のコミュニケーションの方法もあったんじゃないか」とか「情報共有を習慣づけするためにこういう方法もあったんじゃないか」という紹介があり、そこでポジティブで建設的な話に自然に繋がったように思います。

おそらくDevOpsやアジャイル手法の本は、特にエンジニア経験の違いに関わらず発展的な議論ができ、同様の感触が得られるものも多いんじゃないかと思ってます。特にベテランから若手へと、数々の失敗で学んだ暗黙知を共有するのにも役立つかもしれません。

そして次の輪読会へ

今回の輪読会では、きちんと本を最後まで読み終わり、2チーム合同の輪読会の形では解散ということになりました。

次に、自分たちのチームでは『仕事ではじめる機械学習』を読み始めています。自分たちはBigQueryにあるデータを扱うことが多く、機械学習も絡めたシステムを作れれば、より有用な機能を実装するチャンスを広げられると考えているためです。今度は本の内容に合わせて「全員が軽く事前に読んでいて、それぞれが気づいた点や質問したい点をまとめて発表する」という別のやり方で工夫しています。