freeeの開発情報ポータルサイト

安定した開発を続けるサイトビジットのRails活用術

こんにちは、DevBrandingのellyです。10月1日に配信した「freee Tech Night 〜安定した開発を続けるサイトビジットのRails活用術」の様子をご紹介します。

サイトビジット社は2021年4月にfreeeの子会社としてグループにジョインしました。『資格スクエア』や『NINJA SIGN by freee』を開発しているサイトビジット社は、サーバーサイドのフレームワークにRuby on Railsを採用しています。

テストカバレッジ96%・ほぼ毎日各ライブラリのupdateを実施・専業のデザイナーなしでのUI構築など、限られたエンジニアの中でどのようにして高速にかつ安全に開発を進めているのか、開発の組織や文化についてお話してもらいました。

f:id:freee_developers:20211026104353p:plain
登壇者集合写真

yokozawa: 写真右上。エンジニアとしてインターンをしていたサイトビジットに2016年に正社員としてジョイン。エンジニアチームのマネージャー。

watakumi: 写真左上。サイトビジットに2020年に新卒入社。NINJA SIGN by freee担当のエンジニア。メソッドやクラスの命名に関心がある。

のぶじゃす (@noblejasper): 写真右下。ラジオパーソナリティ、2017年に中途入社。mixi、ソーシャルゲーム企業でソフトウェアエンジニアを経験し freee に。入社後はエンジニア→エンジニア採用担当→エンジニアと DevBranding を担当。しゃべりたがり。声が大きい。

「リーガル×テクノロジー」で社会のインフラになる

簡単に会社の紹介をお願いします。

yokozawa:私たちの会社はビジョンとしては「リーガル×テクノロジー」で社会のインフラになるというビジョンを持ってサービスを提供しています。現在は資格スクエア、リーガルエンジン、NINJA SIGN by freee(以下NINJA SIGN)の3つのサービスを提供しています。

弁護士や行政書士、司法書士など法律に関わる方に向けて、まずは資格スクエアで教育の部分を担い、そこで資格を取った人がリーガルエンジンを利用して就職、就職した先でNINJA SIGN by freeeを実務で使ってもらうというように、いろんなところでサイトビジットのサービスを使ってもらえたらいいなと考えています。

士業の方の実務・教育・就職を一気通貫でサポートするというサービスを提供しているんですね。開発はどんな体制でやっているんですか?

エンジニア組織全体では約20人で、基本的にはNINJA SIGNを担当しているエンジニアが多いです。NINJA SIGN内では2~5人のチームが5つあり、契約の締結に関わるチームだったり、契約書を管理するチームだったりで、ドメインごとに分かれています。

毎日bundle updateを実施

タイトルにもあるような「安定した開発」のためのポイントはどんなところでしょうか?

yokozawa:bundle updateを毎日やっているということと、テストカバレッジ96%を維持しているところは自分の中でもお気に入りのポイントです。

登壇者写真
とても楽しそうに話すyokozawaさん。そのおかげで終始和やかな雰囲気でした。

bundle updateに関しては、毎日gemの更新のPRをみんなでレビューしてマージするという形でやっています。メジャーアップデートに近い場合は、マージするのは避けて別でチケットを作っておいて、本当にリリースできるのかを別途精査しています。その別チケットも基本的にクリアになって減っていっています。

未対応のgem update案件は担当をどのように割り振っているんですか?

yokozawa:仕組みがあるわけではないです。6割は事業ロードマップの中でチームに割り振られている大きなタスクに取り組んで、4割はミーティングや事業側からの緊急依頼のためにバッファをとっている感じで、気になる人がやるくらいのふわっとしたルールになっています。

それでもちゃんと減ってるのはすごいですね。未対応のチケットに取り組むモチベーションってどういうところにあるんですか?

watakumi:やっぱり最新のものを使い続けるっていうのはエンジニアとして幸せというか、自分もそれに貢献できるっていうところがモチベーションになるんじゃないかなと思います。

yokozawa:あまり自慢する人がいなくて(笑)クールにやっている人が多いです。

テストカバレッジ96%を維持

テストカバレッジを上げるポイントはどういうところですか?

yokozawa:最初のほうは、レビューするときに「あれ、テストは?書いてないですね」っていうコミュニケーションが多かったですね。今は特に何も言わないけどテストがとりあえず入っているような感じになっていて、テストって当たり前にあるよねっていう空気感になっていると思います。

「障害対応や緊急対応でテストまでは書ききれないけど一刻も早くリリースしたい」みたいな場面はどうするんですか?

yokozawa:そういうときはテスト書けとはさすがに言えないので(笑)修正箇所について既存のテストを通っていることを確認した上で、hotfixで出した後にテストを書くようなチケットを作って、そっちで対応してマージするっていう形でやっているので、やっぱりテストとコードはセットであるようなイメージですね。

定期的にカバレッジが下がった、上がったみたいなのを振り返る会議体や制度があるわけではなくて、「テスト書くでしょ」みたいな空気感、文化の勝利みたいなところがありますね。ローンチ前からずっとテストを書いていたので、自然とこういう文化になっていったんだと思います。

watakumi:重要な機能の処理でエラーが起きたときに全部slackに通知がくるようになっていて、それがあるおかげでアクシデントが起こったときにも誰かが早く気付けてすぐに解決できるっていうフローになっているのは安定した開発のポイントかなと思います。監視ツールを使っているものもあれば、直接結果をログとして流しているようなものもあります。

登壇者写真
ポケモン好きのwatakumiさん(登壇中もゲンガーが見切れている)

基本的に平日に使われることが多いサービスだと思いますが、深夜や休日に障害の通知がきたらどのように対応しているんですか?

watakumi:夜中はいまのところ起きていないのでやっぱり安定してるんだなって思います(笑)

yokozawa:たしかに起こされたことはないですね(笑)

watakumi:仮に障害があったとしても特に当番は決まっていなくて、気づいた人がまず動き出して起きていることを発信するとみんなが集まってくれるって感じですね。

みんな自分事化しているんですね。

watakumi:こういうことが起きたときはみんなで対応しよう、というのが日々の振り返りでも会話されているので、そういう風土や文化になっていると思います。

yokozawa:障害があったら、どのように改善して何を学んだかをチーム全体で共有するというのはかなり意識してやっています。

Rails Wayに乗った開発を続けるためのコツ

サイトビジットのプロダクトはRails Wayにきちんと乗って開発しているというのが結構特徴的だと思いますが、そのコツや気を付けている部分などを教えてください。

watakumi:そもそもRails自体がMVCでモデル、コントローラ、ビューでできているフレームワークなので、現行のコードでもコントローラはなるべく薄くしてモデルに責務を寄せていて、それを崩さないようにしています。

社内でRails 警察みたいな人がいるんですか?(笑)

watakumi:警察みたいな人はいなくて(笑)、どちらかというと結構素直な人が多いのでいまあるコードってこういうルールで書かれているからこれを崩さないようにしようと、自然にRails Wayに安定的にのれているのかと思います。

Rails Wayに表記されてない曖昧な部分はどう決めてるんですか?

watakumi:個人の主張で決める人はいなくて、「こういう場合みなさんならどういう風に書きますか?」とSlackで投げかけてNINJA SIGNではこうしようとみんなで決めるというのが基本の流れです。

ある程度大きなプロダクトでMVC 作っているとサービスクラスを作りたくなると思うのですが、それをあまり作ってないみたいな話も聞きました。

watakumi:もちろんサービスクラス自体は存在していて、実装のスピードを意識すると一度サービスクラスに置いちゃおうということはあるんですが、ただその後にアクションはできていて、こういうサービスクラスがあるというのを誰かが議題に挙げて、こういう責務に分けられそうだからこういうモデルに落とし込もうという議論がPRやSlackで投げかけられて改善されていきます。

違う機能を作っているときにすでにあるサービスクラスを使うとなった場合、影響範囲分からないからやめようみたいな話にはならないんですか?

watakumi:もちろんそういうリスクを考慮した議論もあるんですが、テストを書いてるのである程度担保されている前提で落としどころを見つけられていると思います。

Slackやミーティングで全員で議論できる状態が作れているからこそ、影響範囲も整理できるということなんですね。良いチームですね。

サイトビジットの開発文化

みんなで同じ方向を向く秘訣やポイントみたいなものはありますか?

watakumi:コミュニケーションの活発さはうちの文化なのかなというふうに改めて認識しました。絶対こっちが正しいって強く押すというよりはみんなで合意形成した方がいいよねっていうスタンスの人が多いです。

yokozawa:主張する人はもちろんいますが(笑)お互いに話し合って無理にそれを押し通そうみたいな人は1人もいないですね。

サイトビジットの開発文化を明文化する中で賞賛、感謝、相手へのリスペクトみたいなものを伝えたりしています。何かすぐに頭ごなしに否定するのは止めようとか、チャレンジングな失敗はむしろ賞賛されるべきだよねとか、こういうチームがいいなぁというのは話したりしてますね。

watakumi:yokozawaさんのプッシュがかなりあるし、それによって得られるメリットもみんな実感してて、いまの文化につながっているんだと思います。

freeeにジョインすることで生まれるシナジー

freeeグループにジョインして今後やっていきたいと考えていることはありますか?

yokozawa:契約と会計ってやっぱり密接で、契約書には料金が記載されていて、契約書がないとBtoBのやりとりは成立しないので、その辺のシナジーは活かしながら、いままで僕たちがリーチできなかった顧客層にリーチしていきたいと思っています。

スモールビジネスのバックオフィスの担当者はいろんな業務を兼務してる方が多いので、freeeとNINJA SIGNを使って法務も会計も全部効率化できるようなプロダクトにしていきたいと思っています。

watakumi:僕はプロダクトの成長といった観点ではないのですが、freeeのエンジニアのみなさんとぜひ交流していきたいというふうに思っていて、いろんな開発経験とかを聞いて、freeeの知見をNINJA SIGNの成長に繋げていきたいなと思っています。

freeeのエンジニアとサイトビジットのエンジニアで交流会したいですね!

yokozawa:いいですね、BBQしましょう!

イベントの本編はここまでです。この後は「アフタートーク」でお互いの企業、エンジニア組織の理解をさらに深めました。

▶次回freee Tech Night

10/29(金)「freee流、クレジットカードのマイクロサービス設計・構築術」というテーマでお送りします。 freeeがクレジットカードの発行会社となるためにどんな設計をしどのように実装しているのか。そして「そもそもマイクロサービスってどうやって作るんだ?」という状態から、マイクロサービスの分け方、SNS/SQSでの非同期のサービス間通信やモノレポの導入などfreee内でも新しいチャレンジにどのように取り組んだのかお話を聞いていきます。

freee-tech-night.connpass.com

▶今回のイベントのアーカイブ(録画)


www.youtube.com