タイミーのRailsアプリをシニアなエンジニアが採点したらだいぶ辛口だった

この記事はTimee Advent Calendar 2023シリーズ 1の1日目の記事です。

はじめに

こんにちは、タイミーでバックエンドエンジニアをしている須貝（@sugaishun）です。昨年は弊社でアドベントカレンダーに取り組んだか覚えていないのですが、今年はなぜかいきなり3トラックで臨むということで、非常に勢いがあるなと思いました。量と勢いで攻めていくところが弊社らしいなと感じています。全て完走できると良いですね。

さて私はその中のひとつのトップバッターということで、タイミーのRailsアプリケーションについて弊社のシニアなエンジニアたちと雑談した内容を座談会風にお伝えできればと思います。事の発端は弊社Slackのバックエンドエンジニアが集まるチャンネルで「タイミーのRailsアプリケーションの健康度はどのくらいなのか？」という会話をしたことでした。その時の私の感想は「人によってけっこう基準が違うなあ」といったものでしたが、改めて話を聞いてみると自分の中で発見がありました。参加者は以下のとおりです。

参加者プロフィール

難波さん（@kyo_nanba）

シニアバックエンドエンジニア
ファッションEC系スタートアップの開発責任者やメドピア株式会社のGMなどを経て2022年にタイミーに入社。プラットフォームチームの立ち上げやフィーチャーチームとのコミュニケーション設計に取り組み、直近では会社の技術戦略と現場の技術的ロードマップを接続する役割を担う傍らRailsアプリケーションの設計やリアーキテクチャに関わっている。

神速さん（@sinsoku_listy）

バックエンドエンジニア
2022年11月入社。CTO室に所属し、Railsアプリケーションの開発効率を向上するために型（RBS）の導入やCIの実行速度の改善などの施策に取り組んでいる。

須貝（@sugaishun）

バックエンドエンジニア
2022年1月入社。スポットワークシステム領域でエンジニアとして活動。Ruby on Rails ChapterのChapter Leadも務める。Leadとついているが偉いわけではない。好きな言葉は「容赦ないリファクタリング」

では、ここからが本編です。

タイミーのRailsアプリは60点

須貝：以前SlackでタイミーのRailsアプリケーションが健康かどうかという話をしたと思うんですけど、ここでは健康＝アプリケーションの保守性が高い状態ということにして話をしていきたいと考えています。難波さんはけっこう厳し目の評価をしていたと思うんですけど、主観で構わないので今のタイミーのRailsアプリケーションを100点満点で点数をつけるなら何点くらいなんですか？

難波：60点くらいですかね。

須貝：やっぱりけっこう厳しい。

神速：高専だと赤点ギリギリですね。

難波：不可ではない、という感じです。入った当初の印象は60点くらいでこの1年で色々取り組んできて65点になったかな、というイメージです。タイミーはプロダクトとしては成長できているし、頻繁に障害が起きているわけでもない。世の中に価値を提供できているのでその点では合格だとは思います。

ただ、ここから上を目指していくためには、まだ我々は合格ラインのギリギリ上くらいなんだぞ、と。そういう想いも込めてこの点数にしています。

須貝：具体的にどの辺りが伸びしろだと考えているんですか？

難波：ひとつはSentryのアラートですね。僕が考えるヘルシーなプロダクト組織だったら基本的にはSentryのアラートは鳴らないし、鳴ったらみんながそれを直すべき対象だと思ってできるだけ直す。で、直したらちゃんとresolveして、というのができるようになったらもっと点数が上がるかなと思います。
もうひとつはスロークエリが管理できていない。スロークエリが出ているということはユーザー体験に直結することなので、バッチ処理などであればまた話は別ですけど、現在はきちんと管理できていないのは課題ですね。
最後は自動テストの信頼性です。テストが全部パスしているということは本番にデプロイしても大丈夫ですよねという状態を期待しているんですが、テストがパスしているから大丈夫とはあまり思えない。

須貝：たしかにテストの信頼性は僕も課題に感じています。テストカバレッジ自体は低くはない*1んですけど、仕様のカバレッジが高いかというとちょっと不安なんですよね。
反対に良い点は何でしょうか？

難波：システムがモノリスでやっていけているところは良いところだと思います。マイクロサービスと比べるとモノリス *2のほうが保守性が高いと思っているので。
あとはアプリケーションの保守性に直結するわけではないんですが、CIが速いことでしょうか。CIが速いイコール何かあったらすぐわかるので色々なトライもしやすい。結果的に保守性に寄与する良いところだと思います。

須貝：CIは今何分くらいでしたっけ？

神速：デプロイまで含めると12〜13分くらいですかね。CIだけで見ると8、9分くらいだと思います。

難波：最後にもうひとつ、github-flowで運用できていることも良い点だと思います。いわゆるgit-flowのようにreleaseブランチ的なものを用意して、QAしてmainブランチにマージしてデプロイというのもそれはそれで良いやり方だとは思います。ただ、mainブランチにマージしたら即デプロイというgithub-flowはコードの品質をみんなが信頼していないとできないことだと思います。

カナリアリリースが普通、みたいなチームを目指したい

須貝：神速さんは100点満点で点数をつけるなら何点くらいですか？

神速：45とか50点ですかね。

須貝：だいぶ低いですね（笑）

神速：自分の中での100点となるとGitHub社みたいにバンバン本番にデプロイして、カナリアリリースも当たり前で、みたいな組織です。さらにテストコードもRails本体のリポジトリと同じレベルのクオリティで書く。それが私の中の理想で、それと比べたら今は45点くらいかなと。

須貝：デプロイの話が出てくるあたりが面白いですね。神速さんらしいといいますか。

神速：これは私がインフラもやっているからとかではなく、顧客へ価値をいかに早く届けるかですとか、障害が起きた時もいかに早く直すかというのを大事にしていて、デプロイが大事だと思っているのが根底にあります。

須貝：神速さんはどういう状態が健康と考えていますか？

神速：健康さでいうとまず、RubyとRailsの最新のバージョンを使うことです。あとはこれに付随して、RubyとRailsを最新のバージョンにするためにgemのバージョンを上げ続ける運用があるか。dependabotの整備などもこれにあたります。
あとはテストコードがあるとかレビューをしている、とかでしょうか。難波さんに比べてだいぶ基準が低いんですけど（笑）

須貝：これは過去に経験してきた現場によって基準は変わってきそうですよね。テストを書いているとかレビューしているとか、自分は当たり前だろうと思うんですけど勉強会などで他社のエンジニアと話すと「テストないです」「レビューもないです」というのは普通に耳にします。

神速：ただそこを基準にするよりはもっと上を見たいですね。カナリアリリースが普通、みたいなチームを目指したい。

須貝：タイミーの良いところは？

神速：難波さんが挙げてくださった以外だと、CIでRailsのedgeを使ってテストを走らせているのはレアなのでそこは良いところです。それに付随して弊社のエンジニアがRailsの最新機能を教えてくれる、みたいな福利厚生がある。
後はRBSのような最新機能を導入することにみんなポジティブで、止める人がいない。やってみようという空気があるのは良い点です。

須貝：やっていきのある人が多いですよね。だから一回やってみましょうという文化がある。逆に伸びしろは？

神速：さっきデプロイ時間の話がありましたけど、私はもっと速くしたい。今はデプロイまでの時間が長いと思っています。
Railsアプリの話でいうと、難波さんと同じでテストの書き方とか保守性はもうちょっと考えたいですね。バグがあったらバグを再現するテストを書くとか。機能を追加する時も既存のテストに手を入れるのではなく、テストを追加してカバレッジを高めるような考え方は広まってほしいとは思います。

須貝：パフォーマンスの自動テストはちょっと難しそうですね。

神速：でもたとえばコミットログに残すとかはできそうですけどね。パフォーマンスのテストは増やさないにしても、Rails本体でもパフォーマンスを計測してコミットメッセージに残したり、SQLのEXPLAINの内容を貼ったりとできることはあります。「私が速くなったと思うから」ではなくて根拠はほしい。
他の伸びしろを挙げるならレビューの仕方ですかね。「良さそう」でapproveではなく、パフォーマンスや保守性まで考慮したレビューがほしい。それを気にする人が増えてほしいです。ただ良いレビューをする方法を私が教育したいかというとそれは難しいな、という気持ちがあります。

難波：その気持ちはよくわかります（笑）。

須貝：課題感はあるけど自分が率先してやりたいわけではないという。そういったものはRailsに限らず社内にはいくらでもありますよね。
ここまででタイミーでの開発の良いところや伸びしろについて語ってきましたが将来的にこうなっていてほしいというイメージを伺えますか？

難波：なかなかすぐに実現するのは難しいと思うんですけど、良い設計のシステムにしていきたいですね。例えばRSpecのcontextがわかりやすいんですけど、contextが多重に入れ子になっている時はテストコードの問題というよりはテスト対象クラスの複雑性の問題なんですよね。責務が適切に分解されていないのがテストコードに表出してしまうという。そういうことが起きないようなアプリケーション設計になっていってほしいなと思っています。

須貝：頑張ります。だいたいChapter Leadの僕に返ってくる話ですね。

神速：ただジュニアなエンジニアが頑張っても難しいところはあるので、できる人が教えてあげる環境は何かしら作らないといけないですよね。

難波：そうしたほうが良いというのはすごくわかります。それでいうと今タイミーでは各Squad（チーム）が独立して開発できることを良しとしていて、そこと先輩が教えて知識を伝搬していくことを両方満たそうとすると各Squadに最低一人はミドル〜シニアレベルのエンジニアがいる必要が出てくる。それはけっこう難しいですよね。

須貝：なのでシニアなエンジニアの方、ぜひ弊社に来てくださいという。ちょっとオチがついたっぽい感じになったので今回はこの辺にしておきましょうか。