おはようございます。読書メーター開発チームの荻野です。本記事では、トリスタの提供する読書メーターというサービスと、それを開発するチームについて紹介していきます。

読書メーターとは

読書メーター ( https://bookmeter.com ) は、「読んだ/読んでる/積読/読みたい」といった読書管理や、書籍への感想投稿を通して、ほかの読書家とコミュニケーションができるサービスです。読書SNSとしてはユーザの活発さが特徴で、感想やつぶやきを投稿するとすぐにリアクションがつくので、使っていてとても楽しいサービスです。感想投稿数も国内最大級なので、読書好きでしたら是非使ってみてください。

サービス形態としては、Web（PC/スマートフォン）とアプリ（iOS/Android）のほか、BOOK☆WALKERなどの電子書店にAPIを介した書籍レビューの提供も行っております。

これから紹介する読書メーター開発チームは、サーバサイド全般（Web/アプリ向けAPI/外部向けAPIなど）の開発を行っています。

プロダクトの特徴

読書メーターは誕生から10年経つ、それなりに歴史のあるサービスですが、ここ数年で大半のアーキテクチャがリプレースされています。現在はほぼすべてのアーキテクチャがAWSで稼働しており、リソースのCRUDを行うPlay Framework（Scala）バックエンドと、Web/API/管理ツールとして稼働する各種Railsフロントエンドが中心のアプリケーションとなっています。WebのクライアントサイドにはVue.jsを採用しています。

細部は簡略化していますが、おおまかな構成は以下のようになっています。

読書メーターチームは少人数なため、なるべくインフラの保守コストをかけないように、使えるところは極力フルマネージドサービスを利用しています。各Webサーバの管理にはElastic Beanstalkを採用しており、自動的にEC2インスタンスの死活管理やスケーリングが行われています。定時バッチはCloudWatchイベントがトリガーとなってLambda経由でSQSへキューイングを行い、バックエンドWorkerがそれを処理します。WorkerもElastic Beanstalkで立てられているので、スケーラブルです。図中で唯一フルマネージドでないものはEC2上に立てられたRDB(MySQL)ですが、アプリケーションのリプレース作業の大半が完了しつつあるため、近い将来RDSへ移行予定です。

今回はイントロダクションということで意図的に省略した箇所もありますが、今後の記事でテーマを分けつつアーキテクチャ構成を紹介していきたいと思います。

チームの方針

スクラム

基本的な開発フローはスクラムに則りつつ、楽しく開発しています。

1スプリント1週間で、スプリント内のタスクの管理はホワイトボードで行っています。ホワイトボード内の横軸は曜日で区切り、ストーリー（赤付箋）とそれに対応するタスク（黄付箋）をそこに並べています。 タスク付箋は、着手中の場合は各メンバーに対応する『すみっコ』のマグネットを付け、完了したタスクには緑のシールを貼る、という方法で状態管理しています。直感的にわかりやすくてたいへん便利です。1週間のスプリント単位だけでなく、1日単位でも計画・実行・ベロシティ計測・振り返りを行うことで、日々生産性向上に努めています。

その他、追加タスクは青付箋として貼ることで計画と実作業の差分を振り返りやすくしたり、突発作業やメンバーの休みを手のひら型の付箋で貼ったり、様々なアイデアがこのホワイトボードに取り入れられています。チーム開発について実践していることも、今後記事にしていきたいと思います。

ペアプロ・モブプロ

生産性向上・属人性排除を目的として、ペアプログラミング・モブプログラミングも積極的に行っています。設計段階で共同作業をすることでコードレビュー時の手戻りを減らしたり、メンバー同士で知見を共有することで属人性が排除されたりと大いに役立っています。

上記写真のように、ホワイトボードの手前に4Kディスプレイと作業スペースを設けているため、「この作業複雑なので一緒にやりましょう」「その作業やったことないので、ペアでやろう」という感じで気軽に声をかけてペアプロ・モブプロを行っています。

作業内容によっては個人作業も多いですが、その場合も高頻度にSlackおよび口頭でコミュニケーションをとりながら賑やかに開発を行っています。

属人性排除

チームでは、コーディング・インフラ・仕様調整・他チームとのやり取りなど、業務内容を問わず全員が作業可能な状態を常に心がけています。作業の前提知識・完了条件を全員が把握しているのはもちろんのこと、高頻度なコミュニケーションにより直近の作業に関する知見も全員が把握しているため、誰かが急に休んでもチームは回る状態が維持できていると思います。

作業時間

弊社のエンジニアは基本的に裁量労働ですが、前述のようにコミュニケーションを駆使して生産性を上げていくという合意のもと、チーム内では一日4時間は勤務時間を合わせ、その時間内にスプリント内のタスクをこなすようにしています。それ以外の時間は、各自で書籍を読んだり新しい技術を触ったりなど、自己研鑽に充てています。このような働き方は日々改善を続けるうちに生まれたもので、メンバーが変われば、都度そのチームで良いパフォーマンスが出せるように改善を続けていきます。

文化

読書メーター開発チームに限らずトリスタ全体で言えることですが、どのメンバーでもやりたいことはどんどん実践していける環境があります。

また、トリスタのエンジニアの大半はドワンゴのエンジニアでもあるため、ドワンゴのエンジニア文化がそのまま存在します。活発なドワンゴSlackにも参加していますし、ドワンゴ社内ハッカソンなどにも参加しています。読書メーターチームそのものは小規模なチームではありますが、ドワンゴ内の他チームのアーキテクチャはよく参考にしていますし、様々な技術に詳しいエンジニアが揃っているため、気軽に相談もできます。個人的には、エンジニアとしては非常に良い環境だと思います。

まとめ

ざっくりとですが、読書メーター開発チームの紹介をしました。今回書けなかった情報は、今後詳しく記事にしていきたいと思います。

読書メーター開発チームでは、一緒に楽しくチーム開発できるメンバーを募集しています。

採用情報