CTO 藤村がホストするPodcast、論より動くもの.fmの第13回を公開しました。今回は Kaigi on Rails のスポンサーブースでの公開収録で、CTO室に所属するhogelog、ShiaとKaigi on Railsのセッションについて話しました。
論より動くもの.fmはSpotifyとApple Podcastで配信しています。フォローしていただくと、新エピソード公開時には自動で配信されますので、ぜひフォローしてください。
テキストで読みたい方は下記からご覧ください。
みんながやっている既存Railsアプリの攻略法は？
藤村：論より動くもの.fmです。論より動くもの.fmは、STORES を運営するSTORES 株式会社のCTO藤村が技術や技術に関係ないことについてお話しするPodcastです。今日はKaigi on Rails 2022で発表した直後ということで、スポンサーブースで公開収録をしております。ゲストのみなさま、一言ずついただけますでしょうか？
hogelog：CTO室エンジニアのhogelogです。僕も今回登壇していて、明日2日目に登壇します。よろしくお願いします。
Shia：同じくCTO室エンジニアのシムです。ネット上ではShiaと呼ばれています。僕は先ほど登壇が終わって、やったなぁという感じです。よろしくお願いします。
藤村：まず、僕の発表はどうでしたか？
hogelog：すごくいい話でした。既存Railsアプリケーションがあったら何をしていくのかの部分は、あーそれ大事ですよね！って。エンジニアリングに閉じない、信頼関係が大事なんですよというところまで含めて、非常によかったですね。
Shia：あれはよかった。
藤村：Shiaさんはどうでしたか？
Shia：すげーいい話だったなという感想は一緒なんですけど。見たことがないアプリケーションに入っていくときって、言語化できていないけど、みんなが必ずとる行動があると思うんですよね。僕もそれがあって、藤村さんの話を聞きながら「ああこれもやってた」と思いました。それが言語化されて、一覧として見られるのがすごいなぁと。
藤村：僕の発表にはなかったけど、やっていることってありますか？データベースの話はしなかったんですよ。
hogelog：たしかに、普通のRailsのコードだったらデータベースの方を見たら大体モデルの関係も分かったりするんですよね。かつデータベースの方が一覧性のあるファイルにまとまってるのでわかりやすいことは多いですね。
藤村：あとは、モデルを見ると惑わされたりするじゃないですか。
hogelog：そうですね、モデルは色々書いてあるんで。最初に見るのはデータベースの方が楽だったりしますね。
Shia：レールからはずれているものが何なのかをとりあえず探しにいくことをよくしています。ライブラリー下のモンキーパッチみたいなフォルダがあるのかみたいなのを先に探す癖はあります。
藤村：たしかに。僕はappの下に何が生えているかめっちゃ見るなぁ。なんとかerみたいなのが、絶対生えているじゃないですか。
Shia：presenter、services、batchesとか。
藤村：そうそう。
hogelog：藤村さんの発表の中にあったんですけども、非同期実行の仕組みは色んな人たちの試行錯誤があって面白いなと。特に非同期実行の仕組みについてはRailsがデフォルトのレールにActiveJobを入れたのはちょっと後じゃないですか。だからそれよりも昔からあるRails系のアプリケーションだと、非同期実行に関して色々なやんちゃな物があったりして当時開発していた人の筋肉を感じられてすごい楽しいなーって。
藤村：「俺の考えた最強のリトライ機構」とかね。
hogelog：リトライ機構、バッチっぽい仕組みとか、色々あっていいですね。Sidekiqが生えているとかは普通って感じですけど。もっとやんちゃなものは、しばしばありますね。
Shia：それで言うと、servicesの下にいってみると、我々が考えるサービスとは何たるかがレポジトリごとに違うっていう。
hogelog：app/services以下はオッ！て気持ちになりますよね。
藤村：あと、Active Recordのコールバックも悩ましくて。僕は素直なコールバックの使い方が一番いいと思ってるんですよ。ハチャメチャな使い方をしているのも辛いし、コールバックをやめようとして頑張った設計にしているのも辛いし。これはみんな色んな意見がありそう。
hogelog：Active Recordのコールバックに関しては、個人的にはちょっと態度を決めかねていて、難しいですね。ちょうどいい分量だったり、用法用量を守って使う、あんまり使わないみたいなぐらいしか。
Shia：最初はみんな用法用量を守って使おうって気持ちでやるんですけど、1行1行メソッドで一個ずつ足していった結果、気付いたらダメになったケースがいっぱいあるんじゃないですか。
藤村：用法用量を守ってってプログラミングで言われているやつ、誰も守れてないですよね。
Shia：（笑）その通りだと思います。
hogelog：今まで普通に追加していたのを今日からもうダメって言われても困りますもんね。難しいなあって思います。
実はチート？！関係者がソフトウェア開発に対して理解が深い＆戦力の出し惜しみをしないが功を奏した
藤村：今回の僕の話、ちょっとチートなのは、関係者がソフトウェア開発に対して理解が深かったんですよね。みんなソフトウェアの話をするとよくわかってくれたので、ちょっとチートかなぁと思ったりしました。普通はもっと苦労するのかもしれないな。
hogelog：苦労してる人はもっと苦労してるんだろうなって思いますね。強固な相互理解と信頼関係を作る部分。関係者とコミュニケーションを頑張ってやった程度で打ち崩せるほどうちは簡単じゃないんだよ！みたいな人はいっぱいいると思う。
藤村：そうですね。
Shia：先ほど、藤村さんの発表の中であったツイートで
チームの技術力次第かなぁ…と思っていて、1人が改善しても、それを超える速度でn人が負債を積むチームだと改善しない。先に教育が必要だと思ってる。 #kaigionrails
— 神速 (@sinsoku_listy) 2022年10月21日
というのがあったのですが、その辺は大丈夫だったんですか？
藤村：それは全然なかったですね。みんなそうだよねっていうコードしか出てこなかったので、そこは楽でしたね。
hogelog：開発組織の中でちゃんとやらないとどうしようもできないよなていう内容で、基調講演の中で話されていたRailsのmainを使い続けるとかも。Railsアプリケーションのコードをいい感じにしていくのと、Railsのmainを使い続けるのは若干距離が遠いかもしれないけど、チームで取り組んでいかないとできないっていうのは、通じるものがあるなと思いました。
藤村：あと思ったのが、PMIをうまくいかせる秘訣として、卜部さんにチームに入ってもらうっていうのもありますよね。経営判断として。
hogelog：STORES が経営統合などに備えて、ファイヤーファイターみたいなチームを抱えていたという。
藤村：あとは、その戦力の出し惜しみをしなかったのは重要かなと。
Shia：初動の大切さですね。
hogelog：STORES にジョインして、これからシステムを改善していかなきゃいけないとなって、どうなるのかしら？と構えていたら、一番強い戦力を出してきたと。
Shia：それで言うと、初動でこれくらいの戦力を投入しなきゃいけないっていう判断はどうやって行われたんですか？
藤村：佐藤（裕介）さんと僕で話していて、戦力の出し惜しみをしないっていうのはわりとすぐにコンセンサスがとれた記憶がありますね。そもそもPMIは難しい、PMIは簡単にはうまくいかないっていう感覚がふたりともあったんですよ。失敗させないために、戦力を出し惜しみしないっていうのは話していた気がするな。多分、普通はもっとうまくいかないんですよ。
hogelog：今、本当に普通にちゃんと回ってますよね。
藤村：すごいいいチームになって、まじで心強いですね。
hogelog：技術的なところに課題があることが早めの段階でわかったことがよかったんですかね？
藤村：システムを触り始めて、内部品質の面では改善の余地がある。改善の余地というのは、よくできるって意味じゃなくて、改善すると事業的なインパクトが早めにあるし、1、2ヶ月がっつりやったら、すぐ回収できるだろうと。1、2ヶ月で損益分岐点を超えるなって感じがあったんですよね。なので、一旦内部品質の改善に卜部さんや僕も半分以上時間を使っていて、それに時間をかける判断をしましたね。
Shia：いい話だなぁ。
DX Criteriaをチェックリストとして使う
藤村：あとは小ネタ集みたいな、新しいRailsアプリを触る時のチェックリストみたいなのは作れそうな気がしましたね。
hogelog：もう少し進めると、そうなりそうですね。
藤村：大きいやつで、エンジニアリングの全体評価はCTO協会が作っているDX Criteriaっていうのがあって、あれを使えばよかったなって最初思ってました。使うのを忘れてましたね。
hogelog：確かに。デプロイサイクルを増やしていくとか書いてますよね。DX Criteria、便利なんですよね、ああそうだよねってことをまとめてくれているのでありがたい。
藤村：リスナーのみなさんで、これから経営統合などで技術的なデューデリジェンスを求められる方は使うといいと思いますね。
hogelog：照らし合わせてみていくのはいいですね。
Shia：hogelogさんが使うのは何回か見たことがあるんですけど、自分では見たことがなくて。どういう内容が載ってるんですか？
hogelog：めちゃくちゃわかりやすいところでいうと、デプロイ頻度とか。
藤村：インテグレーションテストが30分以内で完了するかとか。
hogelog：馴染みのある話じゃないですか。
藤村：APIがバージョン管理されているかとか。これ、便利ですよね。
hogelog：デプロイパイプライン的な話もめちゃくちゃ書いてますし。DX Criteria、ここに書いてることを全部完璧に行っていたら、かなり頑張ってやっている組織だなって感じですね。
藤村：これを守っているからといって事業がうまくいくわけではないっていうのが面白いところなんですけど。
hogelog：さすがに、プロダクトの価値を出す部分については言及していない。それはここじゃないもんなぁ。
Shia：全体的にこうしていくと、エンジニアリングの面では会社が破滅しないみたいな感じなんですかね。
hogelog：少なくとも、開発速度を上げることはできる。でも、もちろん誰も使わないサービスを高速で開発しても意味はないですしね。
藤村：アンチパターンがいっぱい載っていて。「自動テストが失敗したまま、そのコードが本番デプロイされることを許容している」とか。Tシャツにしたいような言葉ですよね。
hogelog：（笑）Tシャツいいですね。
藤村：そんな感じでそろそろ終わりましょうか。論より動くものfm Kaigi on Rails 出張スペシャル、ライブ収録をこの辺で終わりにしようと思います。みなさんありがとうございました！
hogelog / Shia：ありがとうございました！（完）
次回の更新をお楽しみに！
STORES では、Ruby、Railsが大好きなエンジニアを募集しています。あなたの既存アプリ攻略法を見せてください！
