2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
藤村大介氏:「既存Railsアプリ攻略法」というタイトルで、CTOが何をやっているのか、何を見ているのか、何を考えているのかをお話ししようと思います。
自己紹介です。藤村大介と申します。あらためてよろしくお願いします。僕は2008年ぐらいから、バックエンドでRailsを書くのを中心にソフトウェアエンジニアとして仕事をしていて、フロントエンドも同じぐらいずっとやっていた感じです。それからだんだんマネジメントっぽい仕事をやっていく中で、経営の仕事をやるようになったというキャリアです。
エンジニアとしては、Railsエンジニアと言っていいんじゃないかなと思います。書いたものとして『WEB+DB PRESS』という雑誌で「プログラミングで名前はどう付ければいいの?」という話を書いたり、その発表をしたりしました。
ほかにも会社でPoscastをやっていて、技術やそれ以外のことについて話しているので、ぜひ聞いてみてください。僕も苦手なんですが、文字起こしもあるので聞くのが苦手な人は、よかったら文字起こしも見てみてください。
プログラマーとして、代表作というかそこそこ作ったOSSで言うと、Haskellのやつとか、Goのやつとか、Haskellのやつとかで、Rubyがないなということに資料を作りながら気づきました。
STORESという会社で働いています。STORESは「Just for Fun」というミッションを掲げていて、「こういうものを作りたい」とか「かっこいいから世に出したい」とか、自分たちの情熱で一生懸命プロダクトを作ったり、サービスを提供したりしている人たちや、作ったものがもっと世の中に増えてほしい。そういう人たちを応援したいということで、いろいろなプロダクトを作っています。
プロダクトとして、何をやりたいかというと、中小、個人など、小さめの規模のお店をやる時のツールです。いろいろとあると思うんですよ。(スライドを示して)ここに書いてあるようにいろいろとあると思うんですが、お店をやるにあたって必要なデジタルで、必要なツールを全部まるっとSTORESで引き受けたいという感じでたくさんのプロダクトを作っています。
みなさんもそうだと思いますが、Railsで仕事をしているとrails newを自分でするより既存のアプリケーションを触ることのほうが多いと思うんですよね。僕もちょうどSTORESに新しく加わったプロダクトをRailsアプリで改善するという仕事をしていました。目指すのは「プロダクト開発のアジリティを上げて、スムーズにお客さんに価値を提供し続ける」というところなんですが、その時に何をやればいいんだろう? みたいなところ。
というか、どういう観点で何を見て、何を目指して、どういうことをやればいいんだろう、というところを実際に僕はここ1年ぐらいやっていたので、ベテランと言っていいぐらいの経験になってしまったエンジニアであり、経営幹部という立場でいろいろな観点からものを見ていて議論しているというところで、どうやっているのかを話そうと思います。
裏テーマというか、実際のところこういうところもあるよねというので言うと、僕はPMI(Post Merger Integration)をやっていたんですね。あとでお話ししますが、「PMI」と言われた時にCTOでかつコードを書く人は何を考えているんだろうというところもちょっとスパイスとしてお話しできればなと思っています。
最近は先ほどお話ししたPMIというやつをやっていたんですよ。PMIは何かというと、Post Merger Integrationといって、要はM&Aで企業の統合ですね。異なるプロダクトの統合、組織の統合、経営の統合とか。ほかにもバックオフィスなどメチャクチャいろいろあるんですが、全体をいい感じにして1つのチームになるプロセスと言われています。
先ほどチラッとお話ししたのですが、2021年の夏にSHOP FORCEという会社が、当時heyという名前だった今のSTORESにジョインしてくれました。僕も中目黒のSHOP FORCEのオフィスに出社し始めました。これは記事があるのであとで読んでみてもらえればと思います。
これは初めてSHOP FORCEのオフィスに僕が物理的に行った時ですね。ジョインしたばかりの会社のオフィスに初めて行ってみなさんと会うということで、すごい緊張しつつも良いプロダクトや良いチームになるといいなと、わりと楽観的な気持ちで、緊張しながら呼び鈴を押したのをけっこう懐かしく覚えています。
中目黒のオフィスに行くようになってから、プロダクト状況の理解など、アクションプランがいろいろありました。スタートアップで戦い抜いてきたRailsのアプリケーションなので当然課題はいろいろありましたが、いったん優先順位を無視して手当たり次第に直そうと思いました。
「Low Hanging Fruits」という言葉が使われることがあるんですが、簡単にもぎ取れる果物がメチャクチャあるので、とりあえずそれを収穫しまくったあとで、中長期的な優先順位を考えようと思いました。ビジネスフレームワークのOODA Loopみたいなものになるのかもしれないですね。
優先順位は気にせずに手当たり次第に直すといっても、観察とか方向決定とかがあったはずなんですよね。いったい何を見て何のために何をしたのかというところを今回お話しできればなと思います。
ということであらためて「既存Railsのアプリ攻略法 CTOが見ること・やること・考えること あるいはスタートアップPMI戦記 Rails編」ということで藤村からお話しします。よろしくお願いします。
まずは全体の概要。規模感、雰囲気、全体像をつかもうと思います。
最初にやったもの。これは順不同なんですが、初期にやったのが$ rake routesですね。これをやるとエンドポイントに何があるのかとか、URLの設計の雰囲気がどうなっているのかがけっこうわかる。
やることはもう単純で、$ rake routesをじっと眺める。テキストファイルに落として「うーん」と見る。見ているとわかるのが、量とどんなカテゴリがあるのかというところですね。エンドポイントが意外とあるねとか、APIの部分とRailsのView、HTMLで返している部分はどれぐらい分かれているのか、とか。なんかちょっとよくわからないやつがどれぐらいあるのかもわかります。
あとはクオリティもけっこうわかります。APIのバージョニングはどうなっているのか。「1、2、3、4、5。0もあるね」とか「4まであるのか」みたいな。そういうのもわかってくるし、Railsで書いているのでみなさんリソースの設計が好きだと思うんですけど、好き好きとかもあるし、クオリティもあるしでいろいろ見えてくる。「これはけっこうバッチで更新しているね」みたいなレコードがわかってくるんですね。
次が$ rake statsで、これは何がどのくらいあるのかをざっくりつかむ点で便利ですね。同じくやることは「じっと眺める」です。わかるのがモデルがいくつあるのか。モデルはRailsアプリの規模感を測る上で一番わかりやすい指標じゃないですか。だいたい500を超えるとけっこう気合が入ってくるなという感じですかね。
あとはテストがどれくらい書かれているか。$ rake statsを使ってCode to Test Ratioでコードに対してテストがどれぐらいあるかがわかるんですよ。大きなカバレッジみたいな雰囲気がなんとなくわかる。ほかにもシステム、リクエスト、ユニットテストでそれぞれどういう分量で作っているのかでテストの設計の方向性とかもわかってくるわけです。
あとはJavaScriptの量がどのくらいかというところで、フロントエンドをどれぐらい作り込んでいるのかがわかる。また、Railsは標準で提供されるもの以外のディレクトリ、つまりMVCとかhelpersとかworkersとか以外のものがどのぐらいあるかでオブジェクト指向設計をどれぐらいやるつもりがあったのかもわかります。あとは非同期処理をどれぐらいやっているのか。これもそれぞれ重要かもしれないですね。
概要の理解という面だと、引き続きGemfileやpackage.jsonを眺めるというのもけっこうおもしろいです。どんなライブラリが使われているかを把握するのと、ライブラリの選球眼やノリみたいなものを理解できるので便利かと思います。最初に見るのはdeviseが使われているかですね。認証まわりのやり方がこれで変わってくるので最初に見ます。
あとは、設計に踏み込むタイプのGemと言っているんですが、Railsのレールに乗って素朴に作っているか、それともフレームワークに近い設計思想があるタイプのライブラリを使っているかを見ますね。punditとかcancancanとかそういう感じじゃないでしょうか。
ほかにはライブラリのアップデートを見て、アップデートが大変そうなやつは何があるかなと見積りをしたり、使われているファイル保存系のライブラリを見たりします。(スライドに)「Paperclipだと“おっ”となる」と書いてありますが、Paperclipだったので「おっ!」となったことがあります。あとは知らないGemがあるかとか、あるならそれは何なのかとか。メンテナンスが止まっちゃってるやつはあるか見ますね。
次がモデルの行数。それぞれのモデルが何行あるかという話ですね。これはけっこうおもしろくて、重要なモデルや大きいモデルが何なのかというのが、把握できる系と、どういうところに力点が置かれたプロダクトなのかもわかってくるところがあります。これはgit ls-filesをソートすると順番に並ぶので、なんとかなるみたいなところがあって、やってみるとわかります。
多くのことをやっているモデルは何かとか、すさまじく大きいやつは何かとか。だいたいuser.rbは大きいですが、user.rbぐらい大きいやつはどれか。こういうのを見ると、だいたいわかってくると思います。
次もだいたい一緒ですが、モデルのテストの行数。これも同じように、モデルの大きさ、規模感みたいなものがわかるかなと思います。重要なもの、複雑なものもわかってきます。「テストケースが多いと、なんか重要なんだろうな」みたいにわかってくる感じですかね。
次におもしろいのがuser.rbですね。user.rbを見ると、そのリポジトリで書かれた典型的なコードがどういうものかがだいたいわかるんですよ。見ていると仕様、実装の理解がけっこう進むと思います。これも気になるところがありますが、そういうのを捨てて無になって、1度流し読みするといろいろなことがわかります。
user.rbはだいたいお手入れが行き届いているんですよ。みんなきれいにしているので、そのリポジトリで書かれた典型的な良いコードはどういうスタイルなのかがわかると思います。
次におもしろいのがconfig/initializers/の下ですね。これの目的は、実装の観察と理解ですが、ちょっと観点は違っていてここにはいろいろなものが眠っているんですよ。なのでこれも同じく無になって1度読む。ミドルウェアは何が使われているのか、外部のAPIはどことつながっているのか、みたいなことはだいたいここに詰まっています。
あとはクレデンシャルの扱い方で環境変数を入れているのどうか、KMSを使っているのかどうかもわかるので、そこらへんの扱い方の癖を通してDevOps的なところの練度とか、雰囲気がつかめてくると思います。
あとは、コードの質感。これもざっくり言っているのですが、なんとなくいろいろなコードを気ままに読んでみる。そうすると、どういうスタイルでコードが書いてあるのかがわかるし、気ままにランダムに読んでいると可読性とか修正容易性とかセキュリティのために直すべきところとか、一般的なコードクオリティというところに関して肌感覚がつかめてくるんじゃないかなと思います。
気にすべきなのは、コードフォーマットが揃っているかどうか。これはあとで話しますが、けっこう重要だなと思っています。
あとは、典型的なRubyらしくて読みやすいコードが書かれているか、evalとかsendとかmethod_missingとかの大胆な技術がどう使われているか、というのもけっこう重要かなと思います。
あとは開発環境もけっこう重要です。新たにチームメンバーが加わる時のオンボーディングのコストはどれぐらいになるんだろう? これを減らすために何かあるかな? というところの発見が重要だと思っています。
ミドルウェアがどれくらいのdocker-composeで動くのかとか、seeds.rbで開発に使えるデータがきちんと作られるのかも、ドキュメントどおりに作れるか見るんですね。作りながら見るんですが、だいたいそうはなっていないのでこれは片っ端から考えずに直すというのをやったりします。
次が概要の理解で、テストとCIです。品質保証やデリバリーの練度がどうなっているかというところと、改善方針を考えるための材料集めが目的です。
それがそもそもあるのか・ないのかというところが、一番重要。あった時は、実行時間がほどほどの長さになっているのか(を見ます)。30分を超えていればけっこうがんばっているねという感じだと思うんですね。あとはどれぐらい安定しているか。Flakyなテストがどこにあるのかとか、Retryをどれぐらいかけているんだろうとか。
あとは「CIが通ったらアプリケーションがちゃんと動きます」と言える自信度はどれぐらいなんだろうというところもけっこう重要だと思っています。CIではコードを見てもわからないので、もともといたメンバーに聞くのが一番正確かなと思います。
あとはリリース手順やサイクルがどうなっているか。可能な限り自動的に高頻度でリリースしたいんですよ。そうしたほうが障害も少ないし、お客さんに価値を届けるスピードも速いし、エンジニアは楽なのでそのほうが絶対にいいんですね。そのためにリリース手順が自動化されているか(を見ます)。
自動化されていてもされていなくてもリリースサイクルが明文化されているか、随時(リリース)じゃないかというところですね。明文化されている場合、リリース手順が明確になっているか。できれば自動化してほしいですが、その場合と手順は明確か。あとは頻度がどれくらいかというところを見ていきます。
最後に、概要の理解というところで監視をどうしているのかを見ます。これは最後に書いたスライドなので超内容が薄いですが、運用で改善する点はあるのかを確認します。あと、運用中はいろいろあるのでパフォーマンスはどれぐらいなのかというところで、どういうボトルネックがあるのか、「今遅いところはあるのかな」というところも見ますね。
今回は、パフォーマンスチューニングの話はぜんぜんしていませんが、それもメチャクチャやったのですごく重要です。まずはとにかくAPMをグリグリと片っ端から見て回る。Datadog、New Relic、Scoutなどいろいろ入っていると思いますが、もし入っていなかったら絶対にすぐに入れるというのが重要かなと思います。
あとは、AWSとかGCPとかクラウドサービスベンダーの各社のログを行き当たりばったりいろいろなところを眺めるというのもけっこういいのかなと思います。
こんな感じのことをやると概要がなんとなくわかって、Railsアプリがどう動いているのかがわかってくるんですよ。「じゃあそろそろ直しますか」というところに行きたいんですけど、その前にちょっとお話ししたいことがあります。
(次回へつづく)
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには