dely Tech Blog

クラシル・TRILLを運営するdely株式会社の開発ブログです

クラシル開発体制の変化と「クラシルサーバーサイドMTG」という取り組み

こんにちは、開発部の高橋です。

2020年10月頃から「クラシルサーバーサイドMTG」と呼ばれる、クラシルのサーバーサイド内で定期的に集まって話しあう取り組みを行っています。

今回はこの取り組みの経緯や取り組み方などについてご紹介します。

経緯

クラシルサーバーサイドMTGを始めた経緯に話すには、まずクラシルの開発体制の変化について説明する必要があります。

開発体制変化の内容や意図などに関して知りたい方は、以下の記事を読んでもらえると分かりやすいかと思います。

blog.tsubotax.com

クラシルの開発体制は左の集中型組織での開発から、2020年4月頃に右のSquad体制と呼ばれる職能横断的な開発体制に変化しました。

この体制変化により、元々は職能別に決定されていた座席や目標設定などがSquad別に決定され、業務時間のコミュニケーションの大半はSquad内で行われる形になりました。

これにはプロダクト開発という面で見ると、解決したい課題に対する把握や深い議論でき、チームワークが発揮しやすいというメリットがあると思います。


しかしながら、この開発体制の変化によって発生した課題もあります。

Squad体制化されたことにより座席も離れ、以前より職能別チームとしての感覚が薄れたことで、サーバーサイド同士のコミュニケーションが以前にも増して減ったと自分は感じていました。

これにより、サーバーサイド同士でお互いが何をやっていかを把握しづらくなったり、

各々が抱えている課題を相談しづらくなったりしているのではないかという危機感が芽生えました。

そこで他のサーバーサイドにも聞いてみたところ共感を得られたのでやってみようということで始めた、というのが大まかな経緯です。

開催方法

現状では、サーバーサイドメンバーがそれぞれトピックを持ち寄って、そのトピックについて30分という時間の中で話し合う形で行っています。

持ち寄り方としては、週に1回トピックを投稿するためのSlackスレッドを用意し、そこに書き込んでもらう方式にしてます。

(ただ、この方式だと新しく参画したメンバーが過去のログを追いにくいなど課題が出始めているため、別の方法を検討中です。)

スレッドの様子(モザイクばかりになってしまった...)

投稿フォーマットは自由で、情報共有ツールで書いてそのURLを共有するパターンもあれば、スレッドに内容を直接書くようなパターンもあります。

話す順番はスレッドをトピックに書き込んだ順番にしており、

もし全員話しきれなかった場合は、次回は話せなかった人から優先的に話すというルールにしています。

話すトピックに関して

  • 設計・実装など技術的な話題
  • プロダクトの方針や施策的な話題
  • プロジェクトの進め方などの話題
  • その他困っていること・話しておきたいこと

など、トピックに関しては開発やチームに関することであれば何でもOKとしてます。

実際に話されたトピックの例を外に出せる範囲で紹介すると、例えば以下のようなものがありました。

  • 各Squadの今後のロードマップの話
  • 新機能のDB設計で困っている話
  • 参加した技術イベントで得た知見共有
  • 古の実装について有識者に聞く
  • Pull Requestレビュールールに関する相談
  • プライベートでグラフデータベース触ってみた話
  • 発生した障害に対する振り返り
  • リファクタリングの方針相談
  • Railsに追加された新機能について話す
  • など

やってみた所感

始めてから今4〜5ヶ月ほど経ちましたが、新たな課題は発生しつつも今の所うまくいっているように見えます。

以前よりも各々の状況を把握しやすくなりましたし、サーバーサイド内で相談しやすい雰囲気づくりに貢献できてるかなと思ってます。

とはいえ自分の感想だけだと単なる自己満足になってしまうので、他のサーバーサイドメンバーにも感想を聞いてみました。

  • 各自のやっていることが可視化される
  • 各自の課題に感じていることが可視化される
  • 週一で相談できる場があるという安心感
  • サーバーサイドエンジニア同士でコミュニケーションを取る機会になり、それ以外の場面でも相談しやすくなる
  • Squad体制になってから参画した身としてはこのMTGがあったおかげで馴染めた
  • 全員の意見を聞きたい軽い提案や相談がしやすい(全員のスケジュールを別途抑えるのはハードル高いので)
  • ここで各Squadの共有がされる場合が多いので、PRレビュー時のコンテキストの理解がしやすい

新たに生まれた課題

現在クラシルは各種エンジニアを大募集中で、それに伴ってサーバーサイドエンジニアの人数も急拡大しています。

これによって30分という時間だと相談しきれなかったり、MTG話せないメンバーなどもでてきてしまっているなどの問題も発生しています。

かといって単にMTGの時間を延ばせばよいかというと、必然的に30分のときよりも消費コストに対するパフォーマンスが落ちやすくなってしまうため悩ましいところです。

ここに関しては正直まだ模索中で、メンバーと相談しつつ改善できたらよいと思っています。

終わりに

先にも書きましたが、クラシルではサーバーサイドを始めエンジニア・デザイナーを絶賛募集中です!

興味があれば是非以下を覗いてみてもらえると嬉しいです!

https://join-us.dely.jpjoin-us.dely.jp