はじめに
開発部の高江洲です。普段は沖縄でリモートワークをしています。夏真っ盛りということでキャンプを始めようと計画しましたが、台風で流れてお預けになってしまいました。まだまだ夏は長いのでリベンジします！
さて、以前弊社 VPoE の小川の記事でゆるい社内読書会のすゝめで紹介したとおり、ロコガイドでは社内読書会を行っています。
今回は継続的に実施して学びのあったことについて書いていきたいと思います。
社内読書会の進め方・読んできた本
ゆるい社内読書会のすゝめの中で紹介している「事前に感想を書く読書会」のスタイルで続けています。期間は1週ごとで、事前に決めていた章まで読み、開催日までにグーグルドキュメントに感想を書いて当日は1人ずつ感想を共有するといった感じです。
これまでは以下のような本を読んできました。
これらを見ても分かる通り、読む人によって理解度に個人差が出やすいアーキテクチャや設計に関する本を対象としてきました。
続けてきて学びのあったこと
読書会を続けてきた中で私自身が良いと思った、学びのあったことを3つ紹介します。
本を1冊しっかりと読み切れる
アーキテクチャや設計に関する本はボリュームが多く、内容も難しいため、なかなか読み進まないことがあります。また翻訳本が多く原著との言い回しの違いで理解しずらい場合もあります。 読書会における私の読み方は以下のようにしています。
- ざっと対象の章を一気に読み切る
- 概要を理解するイメージでざっと読みすすめる
- その際、気になるところやわからなかったところにマーカーで線を引く
- 1で線を引いてた箇所を振り返りながら感想を書く
- 仕事で使っている技術や関連の比較をメインに振り返り感想を書く
- わからなかったところはわからなかったとだけ書く
- 読書会当日はみんなの感想を聞いて内容の理解を深める
- 2でわからなかったことを質問する
- 他の人の感想を聞いてその改めて本を振り返る
1,2,3を行うことで実質、約3回ほど読んでるので1人で読むよりも理解度が上がっている実感があります。
現状のコードベースに対する議論
読書会中に「トクバイというサービスの場合は...」や「Railsを使った場合は...」などの会話がよくあります。読書会を通して新しい設計手法を学んだタイミングで、自分たちが扱っているコードベースを踏まえて議論ができるのは既存の実装の理解につながるとともに改善にも繋がっています。
例えば、RailsではActiveRecordが中心的なものとして存在し、主にDBのテーブルとActiveRecordのモデルという対の関係で設計することが多いと思います。トクバイでは過去の経緯やサービスの仕様の複雑さなど外部要因もありますが、単純にそういったRails wayに則って開発するのが難しい箇所が出てきました。
そこでコードベースの一部にDDDやクリーンアーキテクチャの実装を取り入れ始めています。一般的な設計論をチームで理解し、それをどう既存のサービスに取り入れ改善できるかを考えるのに、読書会がその一役を担う事ができています。
実際の改善の取り組みについては過去の記事があるのでご興味のある方は読んでいただけたらと思います。
技術的負債に立ち向かう ③ロコガイドの現在地編
他チームとの共有の場になる
現在ロコガイドでは事業部やグループでチームが分かれています。チームは分かれていますが、トクバイのサービス開発を行う場合、1つのメインリポジトリで開発することが多いです。読書会を通して共通理解を深めることができ、コミュニケーションを取る場にも繋がっていると感じてます。
読書会にはインフラ基盤やモバイルアプリを専門にしているメンバーが参加することもあります。「インフラ観点ではこのような設計にしてほしい」など、担当領域の異なるメンバーで本のテーマについて会話することができ、学びがあります。
また、ロコガイドではエンジニアメンバーの経験年数など世代の幅が広いので、本が書かれている当時の歴史話が始まったりとざっくばらんに雑談の場にもなったりします。
おわりに
読書会により、1人で技術書を読むのに比べて1つの本から得られる情報量やインプットが圧倒的に増えているなと実感しています。
今後も続けていけたらと思っていますが、ロコガイドで継続できている要因の1つとして、ファシリテータの存在があります。ロコガイドではVPoEの小川がその役を担っていますが、もし社内で読書会を行う場合はファシリテーターを 1人置くことをおすすめします。
最後に、ロコガイドでは読書会や日々の業務を通して技術のインプットを積極的に行い、サービス開発したい方を募集しています。ぜひご興味ある方のご連絡お待ちしております。
