つよい組織には、知識を共有する文化が必要です。 それは、読んだ本にもいえるのでははないでしょうか。 ただし、情報は多いほどいいというわけではありません。 書籍情報の共有にも、何らかのガイドラインが必要でしょう。 DevOps部では、本を三つに分類します:
- 推薦図書
- 閉架書庫行き
- 経典
このリポジトリでは、書籍情報はまず Issue として入ってきます。 本を読み終え、ここに登録するときには、最初に Issue を検索してください。
推薦図書のリストは、きちんとメンテナンスしてゆけば、それ自体がコミュニティの財産となります。 「推薦図書」は以下のように運用しましょう:
- Issue 登録開始
- Description に推薦理由と輪読をはじめるための最低人数を書く
- 自身を Assign し、輪読をはじめたい意思を表明する
- 他のメンバーは、興味があれば各自を Assign する
- Assignee が最低人数に達したら、Project を作って輪読をはじめる
あなたが読んだ本の中には「読み終えたものの、推薦するには至らない」ものがあるかもしれません。 これも、推薦図書と重みの違いがわかるようにしたうえで共有するとよいでしょう。 読んだ本という分母が大きいほど、分子—推薦図書—の信頼性が高まるからです。 「閉架書庫行き」は以下のように運用しましょう:
- Issue 登録開始
- 概要を書く
- 推薦には至らなかった理由を書いて Close
もし自分が推薦したい書籍が既に「閉架書庫行き」になっていたときには、Issue を再 Openし、 「推薦図書」の手順2から始めればよいでしょう。
私たちの運が良ければ、コミュニティの拠り所となる本に出会えるかもしれません。 そのような本を「経典」として定めれば、コミュニティ内で意見の相違が生じたときの指針として役立てることができます。 「経典」の認定基準は、ゆっくり整備していきましょう。
手にとってから読み終えるまで、仕事と結びつかない本もあるでしょう。
そのような本はここでの共有には適しませんが、Slack の #random などでフロー情報として共有するのは良い考えです。
たまに、「これはだめだ」という本もあります。 そのような感想を社内に流すのはあまり良い考えではありません。非難文化につながる可能性があるからです。 そもそも、購入時にきちんと選定しなかった自分にも責任があるでしょう。 その本が「だめ」な理由を自信を持って説明できるのならば、出版社のレビュー欄に投稿するのが適切でしょう。