CAMPFIRE エンジニアチームが取り組んでいる課題とこれから

こんにちは、CAMPFIRE 採用担当の知花です！

5月13日に「エンジニアチームが取り組んでいる課題とこれから」をテーマにTech Talk #1を開催しました。

サービスの成長に伴う組織の拡大や、新型コロナウイルス感染拡大をきっかけとしたフルリモートワークへの移行など、この2、3年でCAMPFIREのエンジニアチームは様々な課題に直面し、試行錯誤を重ねながら今のチームを作り上げてきました。

そんなエンジニアチームが今取り組んでいる技術・組織課題やチームが目指している姿について生の情報を知ってもらいたいと思い、今回Tech Talkを開催しました。

登壇者紹介

2016年にCAMPFIRE入社後、サーバーサイドエンジニア、SRE、エンジニア&SREチームマネージャーを経て、2021年8月よりVPoE。現在は採用やマネジメント、アーキテクチャ設計、IT統制など幅広い領域に関わっている。趣味はギター。

エンジニアとして、コンテンツ配信サービス、イベントプラットフォームの開発に携わったのち、2021年12月にCAMPFIRE入社。よりよいプロダクトを作るためのアーキテクチャとチームカルチャーが最近の関心事。趣味は登山。三児の父。

2019年5月にTOMOSHIBIを事業譲受してCAMPFIREに入社。フルスタックで開発することを目指しているが、最近はサーバーサイドの開発の方が好き。 2020年11月からリードエンジニアとしてふさわしくなるために頑張っている。子供が可愛い。

2021年5月にCAMPFIRE入社。これまではWordPressなどを使ったWEBサイトの制作を3年ほど経験し、CAMPFIREに入社してからはRailsで開発を行っている。最近の趣味はダイヤモンドアート。

サービスの規模が大きくなってきた時の悩み

ーCAMPFIREは今年で11年を迎え、サービス規模も拡大してきました。サービスが成長していく過程で今課題となっていることは何かありますでしょうか？

生沼：サービスの規模が大きくなるに伴い、開発者の人数が増えたことによる「デプロイ待ち」が発生してるというのは一つ課題だと思います。
そこはエンジニアチームとしても、SREチームとしても、まだ解消されたわけではないというのが実情だと思うので、この辺は悩みですね。

岩崎：エンジニアの数もだいぶ増えましたもんね。最初に僕が入った時は3、4人くらいしかエンジニアがいなかったんですが、今は正社員と業務委託合わせて30人くらいはいます。
なので日々のデプロイ渋滞問題は、大きなテーマだと思いますね。

それらへの解決策として、マイクロサービス化に最近は取り組んでいます。
今まではモノレポなので、どうしても1つのリポジトリに対して、全ての開発者がブランチ切って作業を行っていたのでそれが原因でデプロイ待ちが発生してました。
最近は徐々にマイクロサービス化を進めていて、今まで1個のアプリケーションに複数のサービスが同居してるような構成だったものを、各サービスを別リポジトリに徐々に切り出していく動きを進めてます。

新規開発と運用、リファクタリングのバランスをどう取るか

ーCAMPFIREではどのように開発とリファクタリングのバランスを取っているのでしょうか？

小川：この点に関しては、CAMPFIREではある程度取り組みが進んでいて、進め方としてはチームでカンバンボードを使って、各メンバーの業務を可視化しています。

進行中のタスクに上限を設けて、これ以上増えていたらしんどい状況になっているというアラートと捉えて、別メンバーがサポートするという対策をしています。それによって、ある程度ゆとりを持って開発ができる体制にしています。マネージャー的な立ち位置で見ると、ある程度の流量制限ができるわけなんですね。

機能開発というのはもちろんサービスを成長させるために重要なのですが、一方でその（機能開発の）流量をある程度絞って、その分を必ずリファクリングにアサインするっていう形でやってますね。
今のところそれがかなりワークしていると思います。

岩崎：CAMPFIREのリファクタリングの仕組みについては、最初は1週間に1回リファクタタスクをしようみたいな運用でやっていた時期もあったんですが、それだとうまくいかなかったんですよね。
例えば毎週金曜とかで決めてもなんだかんだ、自分の業務を優先しちゃうので。

そこで、カンバンボードを作って、みんな常に1個は何かしらリファクタタスクを持っている状態にしてやると、割とうまくいきました。
ちゃんと1個のタスクとして、可視化することで今はワークしてるのかなと思います。

インシデント対応のベストプラクティスとは

ーインシデントは避けられないものだと思うのですが、発生した時にどう対応するかはすごく大事ですよね。CAMPFIREでインシデントが発生した時の対応の流れや考え方について話していただけますでしょうか。

小川：(インシデントが起きたときは)まずはみんな深呼吸して落ち着きましょうっていうところですかね。例えば当事者だと自責の念にかられて変な動きをしちゃったり、あとはみんながあわてて同じエラーログを寄ってたかって見てたりとか、そういうことになると非効率でおかしなことになっちゃうので。

全体を見る采配役的な人がリードして、対応メンバーにそれぞれ役割を振ったりすれば、調査はある程度おまかせしつつで対処できると思うので、まずは落ち着くということが基本として大事なのはすごく思います。

岩崎：僕もインシデントは発生するものだと思ってるので、いかに発生してからの復旧を早くできるかとか、しっかりポストモーテムを書いて組織的に学習していけるか、みたいなところが大事かなとは思いますね。

生沼：「インシデントを起こしてしまった」でおしまいじゃなくて、CAMPFIREでは、「なんで起きたんだっけ？」みたいな振り返りをポストモーテムで必ずやっているんですが、これはすごいいい文化だなと思います

そしてそれについて「できれば皆さんコメントしてくださいね」という呼びかけもあるのですが、そういうのもすごくいいなと思います。
なかなかコメントがつかない時もあるんですけど、それでも多分みんなそれを見て、「こういうことがあったんだな」とか「何を意識したらいいんだろう」みたいなことを考えてると思います。それは絶対必要なことだと思いますし、今後も続けるべきことだと思います。

あとはそのインシデントを起こした人を責めないことが大事だと思っていて、その人個人がどうというよりも「チームとして再発防止のためにどうすれば良いか？」という考え方は大事にしたいです。

東：「責めない」で言うと、ほんとに前やったインシデントで「ナイストライ！」みたいな声かけがありましたよね。CAMPFIREのそういうところはすごくいい文化だなと思います。

フルリモート下でのエンジニアコミュニケーション

ーCAMPFIREでは2020年2月にフルリモートワークになってからもう2年以上も経過しており、ノウハウも溜まってきている中で課題もあるかと思います。特にプロダクト開発部は全国から勤務している人も多いですよね。エンジニアチームではフルリモートでどのようにコミュニケーションを取っていますか？

東：リモートなので、コミュニケーションをとるのは正直なところ、少し難しいなと感じています。話す機会が毎朝のスタンドアップのみになるので、個人的にはもう少し話したいのが本音です。半年ぐらい前に岩崎さんが2on1を企画してくれて、それはすごい良かったなと思いましたね。2on1だからこその話題の展開や、雑談や情報交換含めてそこで色々話せました。

小川：私自身フルモート環境の入社は初めてだったので、不安があったのですが、個人的には割とスッと入っていけたなっていう感じがしました。
オンボーディングの取り組みの一つにテレフォンショッキング*というのがあって、私はそれで馴染めたところがすごくありました

エンジニアチームのテレフォンショッキングとは？*コミュニケーション活性化を目的とした取り組みです入社後、約2ヶ月間メンターが新メンバーの人柄、趣味、経験などを鑑みて相性の良さそうなメンバーをMTGに招待し、招待されたメンバーが次回のゲストを決めています。雑談をしつつ、コミュニケーションの接点を作っています。（趣味や共通点などで盛り上がることが多いです）

他の取り組みとしては、デイリースタンドアップのなかで、今業務で取り組んでいることだけでなく、最近の良かったことなどを雑談形式で話しています。今後はもっとそういったコミュニケーションの場を増やしていきたいと思っています。

岩崎：みんなでこの業務を何時間やろうとか、みんなで勉強会やろうみたいなアプローチは割と聞くのですが、それだと結局大人数でのコミュニケーションになってしまうので、そんなに喋れなかったりするじゃないですか。なので私はリモートの場合だと、より少人数での密なコミュニケーションの頻度を増やしていくことが大事になると感じています。

エンジニア組織にカルチャーをどう浸透させるか

ーエンジニアチームとしてカルチャー醸成は重要なテーマの一つだと思いますが、どのような意図でどのような取り組みをしていますか？

小川：カルチャーを醸成するにあたって、エンジニアチームとしてのミッションの定義は大事だなと思っています。ミッションは、我々がエンジニアとしてどうサービスを作っていくか迷ったり、分からなくなったときに立ち返る言葉だと思っていて、「会社のミッション」と「エンジニアとして働く自分」の関わりを日々意識するための指針になります。ちょうど今、エンジニアチームとしてのミッションを作っている最中で、作りながら改めてそこは大事な部分だと感じています。

また、(一般的にエンジニアとしての良き習慣として)技術書を読んだり、日々の開発で学んだりしたことをエンジニアブログや登談等でアウトプットしていく流れは奨励していきたいと思っています。特にエンジニアブログはどんどん発信していきたいです。通常の業務に流されがちなところでもあるので、メンバーとの相談の時間を設けながら一緒に書いていくというところから始めています。

東：私が入社した時は勉強会のみの運用だったと記憶していますが、小川さんが入社されてから読書会*ができたり、積極的にブログで発信したりすごくいい流れになってきてますよね。

エンジニアチームの読書会とは？*参加希望者で事前に指定の本の特定範囲を読んだ上で、感想・気付き・疑問点等を共有し合うことで多様な観点から知見を獲得することを目的とした勉強会。

岩崎：僕は元々SREチームのマネージャーをやっていたのですが、SRE文化の浸透みたいな文脈で考えたときにも、急に外から持ってきて、じゃあこれでって言っても難しいんですよね。
なぜそれをやるのか？という説明であったり、そのまま持ってくるんじゃなくて今の組織に噛み合うようにアレンジした形で適用することもすごく大事なことだと思ってます。

カルチャーって他社で成功しているものをそのまま持ってきても、そのまま上手くいくわけではないですよね。
カルチャー醸成って自然とボトムアップでできていくべきものなんじゃないかという考え方もありつつ、そうは言っても最初は上からアクションを起こさないとなにも始まらないのでは、というようなことをこの数年葛藤しているところです。