スタートアップで戦い抜いてきたRailsアプリをどう直す？　既存Railsアプリを攻略する時にCTOが見ているポイント

STORES株式会社 CTO・藤村氏の自己紹介

藤村大介氏：「既存Railsアプリ攻略法」というタイトルで、CTOが何をやっているのか、何を見ているのか、何を考えているのかをお話ししようと思います。

自己紹介です。藤村大介と申します。あらためてよろしくお願いします。僕は2008年ぐらいから、バックエンドでRailsを書くのを中心にソフトウェアエンジニアとして仕事をしていて、フロントエンドも同じぐらいずっとやっていた感じです。それからだんだんマネジメントっぽい仕事をやっていく中で、経営の仕事をやるようになったというキャリアです。

エンジニアとしては、Railsエンジニアと言っていいんじゃないかなと思います。書いたものとして『WEB+DB PRESS』という雑誌で「プログラミングで名前はどう付ければいいの？」という話を書いたり、その発表をしたりしました。

ほかにも会社でPoscastをやっていて、技術やそれ以外のことについて話しているので、ぜひ聞いてみてください。僕も苦手なんですが、文字起こしもあるので聞くのが苦手な人は、よかったら文字起こしも見てみてください。

プログラマーとして、代表作というかそこそこ作ったOSSで言うと、Haskellのやつとか、Goのやつとか、Haskellのやつとかで、Rubyがないなということに資料を作りながら気づきました。

お店のデジタルをまるっとサポートする「STORES」

STORESという会社で働いています。STORESは「Just for Fun」というミッションを掲げていて、「こういうものを作りたい」とか「かっこいいから世に出したい」とか、自分たちの情熱で一生懸命プロダクトを作ったり、サービスを提供したりしている人たちや、作ったものがもっと世の中に増えてほしい。そういう人たちを応援したいということで、いろいろなプロダクトを作っています。

プロダクトとして、何をやりたいかというと、中小、個人など、小さめの規模のお店をやる時のツールです。いろいろとあると思うんですよ。（スライドを示して）ここに書いてあるようにいろいろとあると思うんですが、お店をやるにあたって必要なデジタルで、必要なツールを全部まるっとSTORESで引き受けたいという感じでたくさんのプロダクトを作っています。

既存Railsアプリを改善する時に見ていること・やっていること

みなさんもそうだと思いますが、Railsで仕事をしているとrails newを自分でするより既存のアプリケーションを触ることのほうが多いと思うんですよね。僕もちょうどSTORESに新しく加わったプロダクトをRailsアプリで改善するという仕事をしていました。目指すのは「プロダクト開発のアジリティを上げて、スムーズにお客さんに価値を提供し続ける」というところなんですが、その時に何をやればいいんだろう？　みたいなところ。

というか、どういう観点で何を見て、何を目指して、どういうことをやればいいんだろう、というところを実際に僕はここ1年ぐらいやっていたので、ベテランと言っていいぐらいの経験になってしまったエンジニアであり、経営幹部という立場でいろいろな観点からものを見ていて議論しているというところで、どうやっているのかを話そうと思います。

裏テーマというか、実際のところこういうところもあるよねというので言うと、僕はPMI（Post Merger Integration）をやっていたんですね。あとでお話ししますが、「PMI」と言われた時にCTOでかつコードを書く人は何を考えているんだろうというところもちょっとスパイスとしてお話しできればなと思っています。

最近は先ほどお話ししたPMIというやつをやっていたんですよ。PMIは何かというと、Post Merger Integrationといって、要はM＆Aで企業の統合ですね。異なるプロダクトの統合、組織の統合、経営の統合とか。ほかにもバックオフィスなどメチャクチャいろいろあるんですが、全体をいい感じにして1つのチームになるプロセスと言われています。

優先順位は気にせず、既存Railsアプリを手当たり次第修正した

先ほどチラッとお話ししたのですが、2021年の夏にSHOP FORCEという会社が、当時heyという名前だった今のSTORESにジョインしてくれました。僕も中目黒のSHOP FORCEのオフィスに出社し始めました。これは記事があるのであとで読んでみてもらえればと思います。

これは初めてSHOP FORCEのオフィスに僕が物理的に行った時ですね。ジョインしたばかりの会社のオフィスに初めて行ってみなさんと会うということで、すごい緊張しつつも良いプロダクトや良いチームになるといいなと、わりと楽観的な気持ちで、緊張しながら呼び鈴を押したのをけっこう懐かしく覚えています。

中目黒のオフィスに行くようになってから、プロダクト状況の理解など、アクションプランがいろいろありました。スタートアップで戦い抜いてきたRailsのアプリケーションなので当然課題はいろいろありましたが、いったん優先順位を無視して手当たり次第に直そうと思いました。

「Low Hanging Fruits」という言葉が使われることがあるんですが、簡単にもぎ取れる果物がメチャクチャあるので、とりあえずそれを収穫しまくったあとで、中長期的な優先順位を考えようと思いました。ビジネスフレームワークのOODA Loopみたいなものになるのかもしれないですね。

優先順位は気にせずに手当たり次第に直すといっても、観察とか方向決定とかがあったはずなんですよね。いったい何を見て何のために何をしたのかというところを今回お話しできればなと思います。

$ rake routesをじっと眺めてURLの雰囲気をざっくりつかむ

ということであらためて「既存Railsのアプリ攻略法　CTOが見ること・やること・考えること　あるいはスタートアップPMI戦記 Rails編」ということで藤村からお話しします。よろしくお願いします。

まずは全体の概要。規模感、雰囲気、全体像をつかもうと思います。

最初にやったもの。これは順不同なんですが、初期にやったのが$ rake routesですね。これをやるとエンドポイントに何があるのかとか、URLの設計の雰囲気がどうなっているのかがけっこうわかる。

やることはもう単純で、$ rake routesをじっと眺める。テキストファイルに落として「うーん」と見る。見ているとわかるのが、量とどんなカテゴリがあるのかというところですね。エンドポイントが意外とあるねとか、APIの部分とRailsのView、HTMLで返している部分はどれぐらい分かれているのか、とか。なんかちょっとよくわからないやつがどれぐらいあるのかもわかります。

あとはクオリティもけっこうわかります。APIのバージョニングはどうなっているのか。「1、2、3、4、5。0もあるね」とか「4まであるのか」みたいな。そういうのもわかってくるし、Railsで書いているのでみなさんリソースの設計が好きだと思うんですけど、好き好きとかもあるし、クオリティもあるしでいろいろ見えてくる。「これはけっこうバッチで更新しているね」みたいなレコードがわかってくるんですね。

$ rake statsで何がどのくらいあるのかをざっくりつかむ

次が$ rake statsで、これは何がどのくらいあるのかをざっくりつかむ点で便利ですね。同じくやることは「じっと眺める」です。わかるのがモデルがいくつあるのか。モデルはRailsアプリの規模感を測る上で一番わかりやすい指標じゃないですか。だいたい500を超えるとけっこう気合が入ってくるなという感じですかね。

あとはテストがどれくらい書かれているか。$ rake statsを使ってCode to Test Ratioでコードに対してテストがどれぐらいあるかがわかるんですよ。大きなカバレッジみたいな雰囲気がなんとなくわかる。ほかにもシステム、リクエスト、ユニットテストでそれぞれどういう分量で作っているのかでテストの設計の方向性とかもわかってくるわけです。

あとはJavaScriptの量がどのくらいかというところで、フロントエンドをどれぐらい作り込んでいるのかがわかる。また、Railsは標準で提供されるもの以外のディレクトリ、つまりMVCとかhelpersとかworkersとか以外のものがどのぐらいあるかでオブジェクト指向設計をどれぐらいやるつもりがあったのかもわかります。あとは非同期処理をどれぐらいやっているのか。これもそれぞれ重要かもしれないですね。

Gemfileやpackage.jsonを眺めてどんなライブラリが使われているのか把握する

概要の理解という面だと、引き続きGemfileやpackage.jsonを眺めるというのもけっこうおもしろいです。どんなライブラリが使われているかを把握するのと、ライブラリの選球眼やノリみたいなものを理解できるので便利かと思います。最初に見るのはdeviseが使われているかですね。認証まわりのやり方がこれで変わってくるので最初に見ます。

あとは、設計に踏み込むタイプのGemと言っているんですが、Railsのレールに乗って素朴に作っているか、それともフレームワークに近い設計思想があるタイプのライブラリを使っているかを見ますね。punditとかcancancanとかそういう感じじゃないでしょうか。

ほかにはライブラリのアップデートを見て、アップデートが大変そうなやつは何があるかなと見積りをしたり、使われているファイル保存系のライブラリを見たりします。（スライドに）「Paperclipだと“おっ”となる」と書いてありますが、Paperclipだったので「おっ！」となったことがあります。あとは知らないGemがあるかとか、あるならそれは何なのかとか。メンテナンスが止まっちゃってるやつはあるか見ますね。

モデルの行数・モデルのテストの行数で重要なモデル、大きなモデルを把握する

次がモデルの行数。それぞれのモデルが何行あるかという話ですね。これはけっこうおもしろくて、重要なモデルや大きいモデルが何なのかというのが、把握できる系と、どういうところに力点が置かれたプロダクトなのかもわかってくるところがあります。これはgit ls-filesをソートすると順番に並ぶので、なんとかなるみたいなところがあって、やってみるとわかります。

多くのことをやっているモデルは何かとか、すさまじく大きいやつは何かとか。だいたいuser.rbは大きいですが、user.rbぐらい大きいやつはどれか。こういうのを見ると、だいたいわかってくると思います。

次もだいたい一緒ですが、モデルのテストの行数。これも同じように、モデルの大きさ、規模感みたいなものがわかるかなと思います。重要なもの、複雑なものもわかってきます。「テストケースが多いと、なんか重要なんだろうな」みたいにわかってくる感じですかね。

user.rbを見てコードのスタイルを把握する

次におもしろいのがuser.rbですね。user.rbを見ると、そのリポジトリで書かれた典型的なコードがどういうものかがだいたいわかるんですよ。見ていると仕様、実装の理解がけっこう進むと思います。これも気になるところがありますが、そういうのを捨てて無になって、1度流し読みするといろいろなことがわかります。

user.rbはだいたいお手入れが行き届いているんですよ。みんなきれいにしているので、そのリポジトリで書かれた典型的な良いコードはどういうスタイルなのかがわかると思います。

実装の観察と理解への情報はconfig/initializers/に詰まっている

次におもしろいのがconfig/initializers/の下ですね。これの目的は、実装の観察と理解ですが、ちょっと観点は違っていてここにはいろいろなものが眠っているんですよ。なのでこれも同じく無になって1度読む。ミドルウェアは何が使われているのか、外部のAPIはどことつながっているのか、みたいなことはだいたいここに詰まっています。

あとはクレデンシャルの扱い方で環境変数を入れているのどうか、KMSを使っているのかどうかもわかるので、そこらへんの扱い方の癖を通してDevOps的なところの練度とか、雰囲気がつかめてくると思います。

スタイルの理解とコードクオリティはコードの質感で理解する

あとは、コードの質感。これもざっくり言っているのですが、なんとなくいろいろなコードを気ままに読んでみる。そうすると、どういうスタイルでコードが書いてあるのかがわかるし、気ままにランダムに読んでいると可読性とか修正容易性とかセキュリティのために直すべきところとか、一般的なコードクオリティというところに関して肌感覚がつかめてくるんじゃないかなと思います。

気にすべきなのは、コードフォーマットが揃っているかどうか。これはあとで話しますが、けっこう重要だなと思っています。

あとは、典型的なRubyらしくて読みやすいコードが書かれているか、evalとかsendとかmethod_missingとかの大胆な技術がどう使われているか、というのもけっこう重要かなと思います。

オンボーディングコスト削減に必要な開発環境の確認

あとは開発環境もけっこう重要です。新たにチームメンバーが加わる時のオンボーディングのコストはどれぐらいになるんだろう？　これを減らすために何かあるかな？　というところの発見が重要だと思っています。

ミドルウェアがどれくらいのdocker-composeで動くのかとか、seeds.rbで開発に使えるデータがきちんと作られるのかも、ドキュメントどおりに作れるか見るんですね。作りながら見るんですが、だいたいそうはなっていないのでこれは片っ端から考えずに直すというのをやったりします。

テストとCIで品質保証とデリバリーの練度を把握

次が概要の理解で、テストとCIです。品質保証やデリバリーの練度がどうなっているかというところと、改善方針を考えるための材料集めが目的です。

それがそもそもあるのか・ないのかというところが、一番重要。あった時は、実行時間がほどほどの長さになっているのか（を見ます）。30分を超えていればけっこうがんばっているねという感じだと思うんですね。あとはどれぐらい安定しているか。Flakyなテストがどこにあるのかとか、Retryをどれぐらいかけているんだろうとか。

あとは「CIが通ったらアプリケーションがちゃんと動きます」と言える自信度はどれぐらいなんだろうというところもけっこう重要だと思っています。CIではコードを見てもわからないので、もともといたメンバーに聞くのが一番正確かなと思います。

リリース手順・サイクルをチェックする

あとはリリース手順やサイクルがどうなっているか。可能な限り自動的に高頻度でリリースしたいんですよ。そうしたほうが障害も少ないし、お客さんに価値を届けるスピードも速いし、エンジニアは楽なのでそのほうが絶対にいいんですね。そのためにリリース手順が自動化されているか（を見ます）。

自動化されていてもされていなくてもリリースサイクルが明文化されているか、随時（リリース）じゃないかというところですね。明文化されている場合、リリース手順が明確になっているか。できれば自動化してほしいですが、その場合と手順は明確か。あとは頻度がどれくらいかというところを見ていきます。

監視状況を確認して運用改善につなぐ

最後に、概要の理解というところで監視をどうしているのかを見ます。これは最後に書いたスライドなので超内容が薄いですが、運用で改善する点はあるのかを確認します。あと、運用中はいろいろあるのでパフォーマンスはどれぐらいなのかというところで、どういうボトルネックがあるのか、「今遅いところはあるのかな」というところも見ますね。

今回は、パフォーマンスチューニングの話はぜんぜんしていませんが、それもメチャクチャやったのですごく重要です。まずはとにかくAPMをグリグリと片っ端から見て回る。Datadog、New Relic、Scoutなどいろいろ入っていると思いますが、もし入っていなかったら絶対にすぐに入れるというのが重要かなと思います。

あとは、AWSとかGCPとかクラウドサービスベンダーの各社のログを行き当たりばったりいろいろなところを眺めるというのもけっこういいのかなと思います。

こんな感じのことをやると概要がなんとなくわかって、Railsアプリがどう動いているのかがわかってくるんですよ。「じゃあそろそろ直しますか」というところに行きたいんですけど、その前にちょっとお話ししたいことがあります。

（次回へつづく）