社内RDBMSコミュニティ活動で読書会をやってみた

はじめに

KCS部DSREチームのromです。

KCS部は、KADOKAWAグループ向けプライベートクラウド(以下KCS)を提供しており、主な利用者は株式会社ドワンゴがサービスを提供している「ニコニコ」です。 私の所属しているDSREチームでは、MySQLやRedis，Elasticsearch/KibanaといったDatastore関連のミドルウェアをマネージドサービスとして、KADOKAWAのグループ会社に提供しています。

今回は、MySQLのマネージドサービスであるRDB基盤で、社内RDBMSコミュニティを立ち上げ、RDB基盤運用チームとRDB基盤利用者の皆さんで一緒に読書会を行ったことについて紹介します。

RDB基盤とは

RDB基盤とは、KCSがKADOKAWAグループ向けに提供しているMySQLのマネージドサービスです。 構成は以下の通りです。

• バージョン：MySQL 5.7系
• MySQL数（概算）：500
• masterの総データ量：3TB

DSREチームによって全て構築・運用されています。 詳細は、がんばらないDBaaSの作り方 を参照ください。

背景

昨年（2020年）曽根壮大さんを招いて、RDB基盤利用者の方向けにRDBMS相談会を実施しました。 この時に、曽根壮大さんに以下のコメントをいただきました。

早速1ヶ月の感想を簡単に述べると 意外と横のつながりは弱い という点ですね。プロダクトを横断した基盤チームがあるものの、基盤チームが受け身であり、また各プロダクションのエンジニアもまた基盤チームなどを梃子として活用できてないなと感じます。 （中略） 決断するのは各人、各チームですることになるとしても、ディスカッションから生まれるアイディアは大事です。

私達RDB基盤は、このコメントを受け止め、話し合い、以下の課題があると考えました。

• RDB基盤運用とRDB基盤利用者の連携が弱い
• RDB基盤利用者間でRDBMSに関する交流の場が少ない
• RDB基盤運用のRDB基盤の利用のされ方のドメイン知識が少ない
• RDB基盤運用のRDBMSに関する知識が不足している

RDB基盤運用とRDB基盤利用者の連携が弱い

RDB基盤運用とRDB基盤利用者が信頼関係の元で連携することはとても良い効果を生み出すと考えています。 お互い気軽に質問や相談ができると、問題に対して一緒に悩み立ち向かえるようになります。 また、お互いの専門性を学び合い、個々の専門性を生かして連携して仕事をよりよく前に進めることができるようになると考えています。

しかし、現実は、RDB基盤とRDB基盤利用者とで一緒に議論をした時間や作業をした時間はあまりない状況でした。 また、RDB基盤上で実施されているプロジェクトについて、RDB基盤側は把握していない状況でした。 お互いの相互理解はあまりなく、一緒に仕事をする機会も少ない状況でした。

RDB基盤利用者間でRDBMSに関する交流の場が少ない

技術交流ができる場としては、技術全般についてのエンジニアLTやエンジニア用Slackチャンネル、各種言語やミドルウェアのSlackチャンネルなどがあります。 しかし、RDBMSに関する知見共有や相談の場はあまりない状況でした。

昨年のRDBMS相談会においてRDB基盤利用者の方の課題を伺う中で、共通の課題を持っていることがわかりました。 チーム間で同じ問題を抱えているが、それを共有してディスカッションする場があまりない状況とその必要性を認識しました。

RDB基盤運用のRDB基盤の利用のされ方のドメイン知識が少ない

RDB基盤運用は、中途や新卒でRDB基盤に所属したメンバーが多数で、ドワンゴのアプリケーション開発を行なっていた経歴がある方は少ない状況でした。

RDB基盤で動いているMySQLがどのような利用のされ方をしているのかについてわからず、アプリケーションエンジニアの方と話す際に、ドメイン知識を共有できていない状況でした。

改善のために私達ができること

これらの課題を改善するために、現状のRDB基盤ができることを考えました。

DBAのようなDBに関する深い知識のある人がいれば、勉強会や相談会を実施ができたかもしれません。 ただ、現在のRDB基盤メンバーは、そこまでの深い知識を持つ人はいませんでした。

そこで、現状まずできることとしては以下を考え、行うことにしました。

• RDB基盤運用とRDB基盤利用者の皆さんで読書会を実施すること
• SlackのRDBMSコミュニティチャンネルを作成し運用すること

RDB基盤運用とRDB基盤利用者の皆さんで読書会を実施すること

読書会であれば、専門的な深い知識を必要とせず実施できます。 また、RDB基盤メンバーが、RDBMSについて利用者の方と共に学ぶことができ、 書籍の内容をネタとしたディスカッションから社内のRDBMSの利用のされ方などのドメイン知識も学べます。 利用者の方にとっても、ディスカッションによって利用者間で交流ができます。

SlackのRDBMSコミュニティチャンネルを作成し運用すること

SlackのRDBMSコミュニティチャンネルがあれば、社内のどなたでも参加でき、継続してRDB基盤と利用者の方、利用者の方同士で交流できます。 また、読書会などのイベントを開催し、実況チャンネルとしても活用できます。

ただ、Slackチャンネルは、作成するだけでは意味がありません。 多くの方に参加いただくことと、何より、盛り上がっていることが大切です。 このことを作成当初から意識するようにしていました。

読書会

実施形式

• 毎週1時間オンラインで半年間実施
• 聞き専参加OK
• 流れ
  • 今週のRDBMS関連ニュース
    • RDBMSコミュニティチャンネルでも共有する
  • 書籍「失敗から学ぶRDBの正しい歩き方」を担当制で1章分読む
    • 担当者は、はじめに簡単な自己紹介をする。自分の関係しているサービスについて話す。
    • 気になったところなどで止めてワイワイ議論しながら読み進める
    • 実況は、RDBMSコミュニティチャンネルで行う
    • 短い章は、2章分まとめて読む
  • 議事録をとり、結果をRDBMSコミュニティチャンネルで共有する

苦労したことや工夫したこと

無言時間の解消

序盤は盛り上がったものの中盤あたりからだんだん発言をしていただく方が少なくなってきました。 司会者が質問を投げかけても誰の反応しない無言の時間が発生するようになりました。 司会者はもちろん、聞いている方もきつい時間です。

読書会として毎週1時間という貴重な時間で参加していただいています。 せっかく参加していただいているのですから、1時間という限られた時間をいっぱいに使い、書籍だけでは手に入らない、ディスカッションから得られる知見や発見を提供したいと思っています。 そのためには、無言の時間は無くさなければなりません。

これを改善するために、以下を行うようにしました。

• 最初にアイスブレークとして、今週のRDBMSニュースを話す
• 参加者の方に指名をして質問を投げかけ声を出してもらう
• あらかじめ知り合いに質問をすることを伝えておく
• 相手が発言しているときは相槌を意識的にする

これらのおかげもあって、無言時間は、完全解決とはいきませんが改善していきました。

読書会に参加できなかった方でも楽しめるように

読書会に参加できなかった方でも、RDBMSコミュニティチャンネルを見ることで楽しめることを意識していました。 具体的には、毎回読書会後に、議事録や今週のRDBMSニュースをRDBMSコミュニティチャンネルで共有しました。

読書会の議事録

今週のRDBMSニュース

読書会のはじめの時間に一週間のRDBMS関連のニュースをまとめて共有する時間を設けていました。 形式は、以下の通りです。

• 話題
  • Twitterなどで話題になったことについて紹介
• 企業/団体のブログやニュース
  • 企業/団体のブログ記事やニュースについて紹介
  • 書籍や勉強会などの紹介
• 個人ブログ
  • 個人のブログ記事について紹介
• ピックアップ
  • 上記であげた中から1つ選択して、それをタネとして利用者のみなさんと話す

今週のRDBMSニュース

その週の話題については、お世話になっているブログや書籍の著者やRDBMS系の勉強会の参加者などをTwitterでフォローして話題を追っていました。 RDBMS関連のブログ記事は、気になる記事があればそのブログサイトをSlackのRSSフィードに登録して、RDB基盤メンバー共有のチャンネルに更新情報が流れるようにして収集していました。 また、RDB基盤メンバーにも協力をお願いして、ニュースや興味深いブログ記事があればSlackのRSSフィードに登録してもらい、更新情報を追えるようにしていました。

特別会の実施

半年という長い期間であったので、どうしても、マンネリ化してしまいます。 そこで、中盤あたりで、書籍を読むのではなくて、RDB基盤の裏側の設計やRDB基盤で現在開発していることついて話す会を設けました。

参加していただけた方からは、こんな機能があることを知らなかったという声やここが使いづらいので改善した方が良いという意見をいただき、大変参考になりました。 RDB基盤としても、RDB基盤で提供している機能が意外と知られていないとわかり、積極的にRDB基盤機能の紹介を行なうべきであると認識しました。

ディスカッションするように進行する

書籍を読むことは、一人でもできます。 読書会を開いて複数人で貴重な時間を同じ時間と場所を共有して行なっているのですから、 書籍を読むだけでは得られない、価値を提供するべきだと考えていました。

それを実現するために、以下を意識して、ディスカッションを誘導するように進行していました。

• 自分が読んで疑問に思ったことをメモしておいて皆さんに伺う
• 書籍に関連する事象が社内に存在しないか、経験したことがあるか問いかける

1つ目の「自分が読んで疑問に思ったことをメモしておいて皆さんに伺う」は、 自分が疑問に思うことは他の人も疑問に思うの精神に従い、 疑問点を共有して考えることによって参加者みんなの理解を深めるためです。

2つ目の「書籍に関連する事象が社内に存在しないか、経験したことがあるか問いかける」は、 社内でのRDBMSの利用のされ方を伺い、ドメイン知識について学ぶためです。 また、社内でのRDBMSの利用のされ方を学び、知見を利用者間で共有する意図もあります。

結果

読書会実施後にアンケートを実施したところ、9割以上の方から満足したという回答をいただきました。 今回読んだ「失敗から学ぶRDBの正しい歩き方」についても、 「いくつか今の仕事で身をもって感じているアンチパターンがあり、今後の設計に役立てたいと思う」という好評の意見をいただきました。 また、この試みを良く受け止めていただける方、応援していただける方、改善のための意見をくださる方が多数いらっしゃいました。 大変感謝しています。

課題としては、参加者の負担があると参加しづらいこと、実施する時間帯が遅い時間であり参加しにくいこと、話す人が固定化してしまって参加するのにプレッシャーがあることがわかりました。 今後、社内のコミュニティ活動としてイベントを実施する際は、参加者の負担の少ない形で実施するように意識する必要があると認識できました。

今後

最近、RDBMSコミュニティチャンネルにRDB基盤利用者の方からのMySQLに関する相談がありコミュニティの皆さんと一緒に問題について考えることができています。 また、毎週のRDBMSニュースに反応を頂けて交流できています。

さらに、最近、RDB基盤利用者の方から要望をいただき、社内サービスとしてオンラインスキーママイグレーションサービスをリリースしました。 これは、要望を頂いたRDB基盤利用者の方と一緒にサービス化を行いました。 このようにRDB基盤利用者の方と一緒に仕事をする機会も増えてきています。 半年ほど継続して活動をしてきた効果が少し出始めているのかもしれません。

今後もRDBMSコミュニティを活性化させるために、継続して何か面白いことを行なっていこうと考えています。

私達RDB基盤は、RDBMSに関する場を提供していきます。 MySQLのマネージドサービスはもちろん、今後は、RDBMSに関する交流の場も盛り上げていきます。

最後に、一緒に働ける仲間も募集しています。 興味のある方は採用サイトをご確認の上ご応募お待ちしています。