技術選択とRailsの功績
何を基準に技術選択するかがWebエンジニア界隈で話題だ。
昨年は技術選択に関わってきたし、過去成功事例も失敗事例も経験してきた身として徒然書き連ねてみる。
まず個人開発や単に技術者としての責務しか負わないならシンプルに技術的な視点だけで、個人の嗜好だけ考えれば良いと思う。
だが、自分が事業に責任を持ってる立場だと判断は難しくなる。
その技術選択をした結果、事業が成功するか、しないかを基準にすると組織課題まで考慮せざるを得ないからだ。
たとえばボードゲームで、大量の弱い駒で戦う場合と、少数の強い駒で戦う場合で勝利への戦略は異なってくる。
強い駒があるときしか通用しない戦略で負けたとして、「駒が悪い」「弱い駒しかないデッキの問題だ」とは言えないだろう。
その戦略を選ぶなら「どうやって弱い駒を強い駒にするか」「どうやって強い駒を集めるか」も含めて考えるべきだし、弱い駒を大量に集める戦略もそれで勝てるなら正解の1つだ。
「ここから先は組織課題だよね」「エンジニアとしてはこれが最善の技術選択だよね」という線引きは、もちろんエンジニアの責務の範囲内では正しい。
しかしたとえばCTOなど事業にまで責任ある立場になるとそうならない。
そして依頼された立場として誠実に振る舞うなら、たとえ自分が事業に責務を負っていなくても、そこを全く考慮しないのは難しいだろう。
雑談のテーマとして「技術選択するなら何を選ぶか」と話に上がることはあるが、「エンジニアとしてなら絶対選ばないし、それを採用してる現場も選ばないけど、事業に責任持ってる立場ならRailsは割とありなんじゃないかと思う」と答えていたことがある。
なのでRailsを軸に話を進めていきたいと思う。
Railsが廃れて失われたもの
2010年代後半ごろから明確にRailsが技術選択されることが減り、別言語で開発されることが増えていった。
Rails wayから梯子を外されたものたちは新たな道筋を探し、特にDDDが流行っていった。
そういったサービスを両手で数えるぐらい見てきたが、その選択が成功したと感じられるサービスはほとんどない。
「DDDで開発された結果メンテができなくなって１年でリプレースします」
「Railsで開発すれば１日でできるようなものも、１週間かかります」
「テストコード書きづらいのでテストコード書きません」
もちろんこれはDDDへの無理解が大きなファクタを占めているとは感じる。
ドメインモデル貧血症になっていたり、ただディレクトリ構成を真似しただけだったり、トリレンマが適切に考慮されていなかったり。
しかし色々な組織で「うまくできない」ならもはや属人的な問題といえないだろうし、結果としてそれが１年でリプレースする未来につながるのであれば技術選択として失敗なのは間違いない。
Railsが与えてくれたもの
「3ヶ月でエンジニア転職」といったスクールが流行り、さまざまなスクールでRailsが教えられている。
自分もスクールで教えたことがあるが、個人的に思ったのが「Railsは誰が描いても似たようなコードになる」ということだ。
プログラミングができるようになるというより、書き方を覚えるだけで良いからこそ、スクールにとっては都合が良い。
DBのことよく知らなくても言われた通り書けばなんか動くし、手順通りにHerokuにデプロイすればサービスはできる。
正直いちエンジニアとしては、こうして表面だけのエンジニアが大量に放出されるのはどうかと思う。
しかしそんなRailsが流行ったからこそ、未経験ですら即戦力となり、ある程度の保守性を担保し続けられたとも感じられる。
DDDは書く人によって10点にも90点にもなるが、Railsは誰が書いても70点のコードになるイメージだ。
戦略を練る立場としてはこれほど良い特性はない。
※ Railsでコードがぐちゃぐちゃになって失敗したからDDDにした！って例も見ますが、DDDでぐちゃぐちゃにならないように書くのはもっと難しいのでは難しいのでは思ってます。ただDDDを学習する過程で設計手法について学び、副次的にコードが綺麗になることはあると思います。
Railsを選ぶべきか
しかし現在Railsを技術選択すべきかというと、正直怪しく感じる。
多くの人が選ぶ技術選択をしないと短期的にはよくてもすぐに時代の流れに遅れ限界が来る。
技術的にも将来性があり、Railsの特性を持つ選択肢があれば、それに越したことはない。
最近だとBlitz.jsがポストRailsで一瞬話題になった。
しかしあれは単にフロントエンドとバックエンドが結合されているだけで、本当にRailsが与えてくれたものではなかった。
私がRailsが他と差をつけていると感じる要素はActiveRecordとFactoryBotだ。
ActiveRecordはDBへのリクエストがシームレスすぎてコントロールしづらいし、純粋なドメイン知識とインフラの知識が混合してしまうという批判もわかる。
しかし逆に言えばそこをよしなにフレームワーク側がやってくれるからこそ、誰が書いても品質にブレがないとも言える。
またRailsは実DBを使ったテストが簡単に書けるため、テストが書きやすい。MemoryRepositoryをDIしたり、mockする、みたいな方法は確かに純粋で綺麗だが、テストのための実装が必要になることで都合の良いテストばかりになってしまったり、「面倒だからテストが書かない」のような意思決定をされがちだ。
なのでDBのレコードの変化を追うテストのほうが結果として意味のあるテストが充実しやすいと実体験として感じる。
Railsに変わるフレームワークは
下記記事にもあるようにHybrid Renderingが洗練されてきて、フロントエンドとバックエンドは区別することなく書けるようになってきた。
特にRemixの書き味は個人的に気に入っており、今後広まってほしいと思う。
しかし先にも書いた通り大事なのはActiveRecordとFactoryBotの代替だ。
たとえばTypeScriptのORMはprisma.jsが独占的である。
しかしあれがやってることはほぼクエリに型をつけるだけであり、ライブラリの思想的にもFeaturesを見てもActiveRecordの責務まで担うつもりはないだろう。
個人的にはActiveRecordとFactoryを作る優れたprisma generatorが出たら世界は大きく変わると思っており、期待したいところだ。
RedwoodJsはまだまだ期待値には届かないものの、思想としては近そうなので定期的にウォッチしている。ただこうしたFWは技術選択する立場の人が好むようなものではないので、流行らなそうだとは思う。
（他にもLaravelなどもしかしたら良い代替案はあるかもしれないが、詳しく知っているわけではないのでこれ以上の言及は避けておく）
この記事が気に入ったらサポートをしてみませんか？