「みんなでやってみよう」の話
本記事はCAMPFIRE Advent Calendar 2024の3日目の記事です。
こんにちは。CAMPFIREでエンジニアリングマネージャーをしている小川です。
この記事では、複数チームで横断的に扱う課題について、意識的に「みんなでやってみよう」をした話を書いてみたいと思います。
課題感
CAMPFIREの開発チームではチーム規模の拡大にともない、いくつかの事業領域ごとにチームを分けています。こうした領域ごとのチーム分けは、それぞれが特定のドメインに集中できることで、認知負荷を下げ、また特定のドメインに対する深い知識を得やすくなるという点でとてもメリットのあるものです。
一方で、守備範囲のドメイン以外に対しての知識や関心がどうしても薄くなるというトレードオフがあります。CAMPFIREでも以下のような問題が見られるようになってきました。
ライブラリなどのバージョンアップや、エラーの対応など、チーム横断的な課題が特定のメンバーに偏りがちになる
あるいは、これらがボールとして浮きがちになり、手を付けられないまま時間が経過する
これらは長期的に見ると、特定のメンバー負荷増大や、課題の長期化などの弊害を招きうるものです。
というわけで対応ができないか考えてみることにしました。
原因はどこにあるのか
エラーの調査についてアンケートを取ってみたり、1on1でお話をしたりして、原因を探ってみました。
その中で気付いた点のひとつに「分からないから手を付けるのが後手になってしまう」というものがありました。たとえば、「バージョンアップをやってみたいけれど、どうしたらいいか分からないので、他の人にお任せしてしまう」など・・・。
総じて以下のような傾向がありそうでした
やりたい気持ちはある
しかし、どのように対応すればいいかが(全体的に / 部分的に)分からない
手を付けたとしても時間切れになりがちで、結果として手を付けないことが多くなってしまう
たとえば、Rubyのパッチバージョンアップ。
単純にバージョンアップをするだけであれば簡単でしょう。しかしながら、CAMPFIREの場合ですと、CIのイメージ更新を伴ったりなどの作業があり、分かっていればなんてことはないのですが、手順を知らないと少々手こずります。できるかな？と思って手をつけてみても、途中で行き詰まってお任せしてしまう、このような状況は、非常に勿体ないと言えます。
「みんなでやってみよう」をやってみた
その対応としてトライしてみたのが「みんなでやってみよう」です。モブプログラミングとは行かないものの、みんなで集まって、一緒に作業をしてみるというものです。
先述のRubyのパッチバージョンアップの機会があったので、みなさんと相談して、あえて一人での作業とはせず、以下のようにしてみんなを巻き込んで作業をやってみました
事前にnotionに手順をまとめておく
Google Meetで画面を共有しながら、バージョンアップ経験のあるメンバーがナビゲーター役となって、バージョンアップ未経験メンバーの作業をサポートする
作業をするメンバーは基本的に1人だが、興味あるメンバーにはチームを問わず集まってもらう
このバージョンアップ作業は比較的好評で、バージョンアップどうやるの？というメンバーにとって、作業イメージが湧くきっかけとなったようでした。
さて、このような試みは、別にRubyのバージョンアップに留まりません。
いろいろなパターンの「みんなでやってみよう」ができます。以下ではCAMPFIREでの試みをいくつかご紹介します
他言語処理系やフレームワーク、ライブラリのバージョンアップ
Rubyに限らず、Node.jsやRailsのパッチバージョンアップなどでも、みんなで集まってバージョンアップをしました。
意識的にやっていたのは、経験者を増やすことです。一度バージョンアップのドライバーをした人は、今度はナビゲーターとして、他の人がドライバーになってもらったりすることで、バージョンアップができる人を増やしていくようにしました。
共有バックログの調査・整理
社内には「ジョブ・バグボード」という、日々のエラーや課題をメンバーが書き留めておくnotionデータベースがあります。このデータベース、日々追加されるのはよいのですが、そこから実際の課題解決がなかなか進んでいかないという課題がありました。
大きな原因は、起票したメンバーが詳細にエラーの原因や対応内容を調査する時間がなかったりで、分かりづらいものになってしまっていたことでした。いざ、他メンバーがタスクとして取ろうとしてもそのキャッチアップや調査からになってしまうので、進めにくくなってしまっていたのです。
そのため、起票されたエラーや課題をみんなで集まって調査する時間を定期的に設けることにしました。
この時間を使って、ピックしたイシューに対してエラー内容の調査や、対応方針の整理を進めます。一人だとやや挫けそうなものでも、みんなで集まって話しているとなんとなく突破口が開けてくるものです。
そうして内容を読んで実装や修正をすればOKという区切りのいいところまで進めることで、手が空いたメンバーが着手しやすくなるようにしました。
「みんなでやってみて」どうだったか
「みんなでやってみよう」にしばらく取り組んでみて、以下のようなメリットを感じています。
属人化の軽減ができた
特定のメンバーしか分からない、のではなく、共有知化の促進をすることができました。全員とまでは言わずともある程度の数のメンバーで取り組めるようになったかと思います。併せて、特定メンバーへの負荷の集中も減らすことができました。
チームのサイロ化を防ぎ、横断を促進することができた
先述のように、チームの分化は他のチームとのやりとりの機会が減り、サイロ化を招く側面もあります。横断的な取り組みの機会があることで、チームを横断したコミュニケーションの機会の増加につなげることができました。
「みんなでやってみよう」の打ち手が増えた
最後に、困ったときに一人ないしは少人数で抱えず「みんなでやってみよう」の選択肢を増やすことができました。
これまでですと、ボールとして浮きがちであった横断的な課題に対して、効果的な解を提示することができました。
当初こそ意識的に声がけをしていましたが、選択肢として定着することで、特に全体にまたがる課題があるときには、各メンバーが自発的にみんなで集まって取り組む機会が増えてきたように感じます。
以上、CAMPFIREで取り組んだ「みんなでやってみよう」のご紹介でした。
ちょっとしたことですが、「みんなでやってみよう」は、横断的な課題が属人化する、あるいは放置されてしまうことに対して、一定の効果を収められたのではないかと考えています。
今後は中長期に向けて「みんなでやってみよう」を開発チーム全体として、もっと当たり前にすることができたらばと思っています。現状ですと、課題ベースで集まることが多いですが、ちょっとした知見の共有といったことも含めてもっとライトに取り組むことができれば、更に面白くなるのではないかと思っています。
今回ご紹介したCAMPFIREでのこの取り組みがなにかの参考になれば幸いです。