こんにちは、ECナビ事業本部エンジニアの yukimine です。

2ヶ月程前にデザインパターンをチームで学んで得たものという記事がありましたがご覧いただけましたでしょうか。
Zucks Affiliate事業本部が、@t_wadaさんと読書会を行ってチームでの共通言語が増えたという記事です。

ECナビ事業本部でも、ベテランから新卒まで様々なエンジニアが、@t_wadaさんに設計・実装を相談をさせていただいたり、ペアプロをさせていただいたりしています。

本記事では、@t_wadaさんとECナビ事業本部の取り組みの一つ、 プログラマが知るべき97のこと読書会 で取り入れている 4つの工夫 について、ご紹介させていただきます。

4つの工夫とは

事前準備なし
アクションにつなげる
エンジニア席の横で開催
SlackのPublicチャンネルで議事録を残す

です。

デザインパターンをチームで学んで得たものの二番煎じ感満載ではありますが、この読書会によってECナビ事業本部も チームの共通言語 や チーム共通のネクストアクション （読書会で学んだ内容をどう行動に落としこむか）を持つことができました。

プログラマが知るべき97のことってどんな本？という方はこちら
www.oreilly.co.jp

まずはじめに

増刷おめでとうございます！

『プログラマが知るべき97のこと』（通称「きのこ本」）の増刷が決定いたしました。たくさんの方にお読み頂き、本当に嬉しいです。ありがとうございます。 #97prog_ja #きのこ本 https://t.co/BRFIImTM4E
— Takuto Wada (@t_wada) 2016年6月8日

（増刷時の修正項目には読書会の中で見つかったものも含まれているとか・・・）

「知見の共有」に読書会を使う

そもそもなぜ、 チームで読書会 をやっているのかをご紹介します。

ECナビ事業本部には様々なキャリアを持ったエンジニアが所属しています。
経験してきた業界（SI系やゲーム系など）や年数も様々です。

そういった中で、プログラマが知るべき97のことという共通知識を付けることはもちろん、本の内容を題材にした各自の知見を共有することを大きな目的としています。

今回はプログラマが知るべき97のことを選んだのは 監修者直々の解説を受けられる ことも理由の1つです。プログラマが知るべき97のことは@t_wadaさんが監修されています。
監修者直々の解説を受けられる稀有な機会ということで選びました。

読書会の流れ

読書会は次のような流れ（時間配分）で進めています。

読書タイム（10分）
@t_wadaさんの解説（30分）
質問タイム、ECナビ事業本部のアクションを決める（20分）

14. コードレビュー を読んだときのSlackの会話を交えながらご紹介します。
（Slackは議事録も兼ねているため、文体が乱れている箇所もあるかと思いますが、ご了承ください。）

流れ1「読書タイム」

1回の読書会で読むエッセイは 2エッセイ です。
ECナビ事業本部のエンジニアが、任意の1エッセイをリクエストし、@t_wadaさんがそれにあった 合わせて読みたいエッセイ を選んでくださいます。
この時点で読書会の価値を感じますね。

Slackの様子
f:id:yuk4420:20160727000650p:plain

流れ2「@t_wadaさんの解説」

@t_wadaさんがエッセイについて、著者の背景や本に書かれていない事例、編集時のコラムを付け加えて解説してくださいます。

@t_wadaさんの解説（の議事録）
f:id:yuk4420:20160727000637p:plain

流れ3「質問タイム、ECナビ事業本部のアクションを決める」

エッセイに関する質問や、ECナビ事業本部としてどのような行動に落としこむかを話し合います。

ECナビ事業本部のアクション
f:id:yuk4420:20160727000702p:plain

1 は実際にGitHubのPullRequestで使われており、2 はGitHub Templateを採用する等、読書会から生まれた共通のアクションがECナビ事業本部には多数あります。

読書会の工夫とは？

冒頭で、読書会の工夫を紹介すると書きましたが、実は「読書会の流れ」の中で全て紹介済みです。
工夫といっても、気を張る必要なくルーチン化できるものばかりを取り入れているからです。

ここからは改めてその工夫を取り上げてみます。

工夫1「事前準備なし」

事前に予習する必要はありません。
その場で読んで、疑問に思った箇所はすぐ@t_wadaさんや周りのエンジニアに聞くことができます。

きのこ本の特徴として、1エッセイが見開き2ページで収まっているので、予習なしでも読書会が円滑に進みます。

@t_wadaさんからコメントをいただきました。

@t_wadaさんからのコメント

読書会に何回か参加できなくても、会に復帰しやすい本を選ぶと、読書会が継続しやすくなりますね。
読書会を継続するのが目的になってしまうと本末転倒ではあるけれども、多くの社内読書会は、仕事が忙しい日に参加できずに脱落していく人が多くなってしまうものなので、1,2回参加できなくとも普通に戻れる構造の本を選ぶと、特に読書会の文化がまだ根付いていないうちは続けやすくなるなと改めて感じました。
シーケンシャルに読んでいかなければならない本は、読書会というフォーマットにはあまり向かないのかなとも思います。

工夫2「エンジニア席の横で開催」

プログラマが知るべき97のこと読書会の開催場所は、ECナビ事業本部エンジニア席の横で行われます。

これにより 作業で手が離せないエンジニアも耳で参加することができます 。

移動コスト（それくらい惜しむなよと言われそうですが、やっぱりない方がいいですよね）も削減できて楽です。

読書会開催の目的（なぜやっているのか）からも、 参加しやすい環境 は良いと思います。

実際の様子 f:id:yuk4420:20160726235805j:plain

工夫3「SlackのPublicチャンネルで議事録を残す」

先ほどからスクリーンショットを貼っていますが、この読書会用に #97things というSlackのPublicチャンネルがあります。

使われ方は、 議事録 を始め、 @t_wadaさんがエッセイに関する参考URLを貼ってくださったり 、 読書会に参加していないエンジニアから反応があったり 、様々です。

Slackのチャンネルで、この読書会があることを知って、参加するようになったエンジニアもいます。

工夫4「アクションに繋げる」

先ほど14番目のエッセイ、コードレビューから生まれたアクションをSlackのスクリーンショットでご紹介しました。

同じように、いくつものアクションが、毎週この読書会から生まれ、実際に適用されたり、GitHub Issueにあげられたりしています。

私事ですが、一人で技術書を読んだり、読書会に参加したりした後、

「いい話だなー」

と思うことは多々あれど、実際に行動に落とし込むことは少ないです。
それどころか、翌月には、

「あの本の内容、なんだっけなー」

と思っている始末です。

チームにとって、もちろん個人にとっても よいこと をチームの共通アクションにできる。
ECナビ事業本部にとって、この読書会はそんな存在です。

参考までに、この読書会から生まれたアクションをいくつかご紹介します。

エッセイ名	アクション	アクションの恩恵
06. リファクタリングの際に注意すべきこと	試行プログラミングを取り入れてみる	手軽に取り組める。実際にmergeされなくても、既存のシステムを深く知る機会になる。
10. ツールの選択は慎重に	自分たちが使っているライブラリのアップデート情報収集を自動化する	自分たちが使っているツールのバグによるリスクを回避できる。
14. コードレビュー	レビュアーは、これから見ようと思っているPRに :eyes:（アイコン）をつける	「レビューされず放置されているわけじゃないよ」「見てるよ」をレビューイに手軽に伝えられる
64. プロのプログラマとは？	中間地点でのレビューポイント（設計時など）を作る	手戻りが少なくなる。余裕を持ってレビューができる（リリース前に設計の指摘を受けて焦らないなど）。
92. 顧客の言葉はそのまま受け取らない	顧客（ディレクターなども含む）の言葉を同じ抽象度で復唱するだけでなく、会話に「要するに」「具体的には」という言葉を盛り込み、抽象度の上げ下げも取り入れる	認識のずれを減らせる。