STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

「Ruby on Rails の楽しみ方」への高橋会長のレビューコメント

Ruby

STORES エンジニアの morihirok です。

先日サポーターズさん主催の勉強会「技育CAMPアカデミア」にて、学生の皆様に向けてSTORES社が講義をさせていただきました。 テーマは「『なぜ今 Rails を学ぶべきなのか』Ruby on Rails から学ぶ Web アプリケーション開発実践」ということで Ruby と Ruby on Rails についていろいろな切り口からお話をさせていただきまして、私も「Ruby on Rails の楽しみ方」と題して Ruby on Rails がWebアプリケーション開発の歴史においてどのような意味を持ち、どのように学び、楽しむとよいかという話をさせていただきました。

speakerdeck.com

この話をするにあたり2000年代のWebアプリケーション開発について言及したかったのですが、自分自身当時まだWebアプリケーションエンジニアとして働いていなかったため、時代考証について一般社団法人 日本Rubyの会 代表理事 高橋征義さんにレビューを頂きました。おかげさまで濃度の高い資料となり、学生のみなさまにもそうでないみなさまにも楽しんでいただける内容になったと思います。本当にありがとうございました。

高橋会長からいただいたレビューコメントを全て資料に反映することはできなかったのですが、反映できなかった内容も含め全文が業界にとって価値あるものと感じたため、この場を借りて紹介させていただければと思います。

2000年代初頭のWeb開発は大変だったらしい

  • 本当にたいへんでした
    • というか、当時の「大規模（Webアプリケーション）開発」というのは、今で言うところの「あんまり大きくない（数カ月程度で作れる）Railsアプリ開発」程度だったような気がします
  • 当時の大変さ
    • サーバのリソース（＝マシン）がしょぼい
      • 当然ながら仮想化されてないので物理マシンと完全に紐ついている
      • 一台のマシンに複数のアプリを配置できても複数台のマシンに一つのアプリを載せる的なことは現実的ではなかった
    • 開発機もしょぼい
      • 実行速度もメモリもストレージも今と比べるとぜんぜんしょぼい
    • ネットワークがしょぼい（遅い）
    • クライアントマシンのスペックとブラウザがしょぼい
      • 現代のフロントエンド技術はこの2点が克服されているのが大きいはず
    • 言語がしょぼい
      • これは開発機がしょぼいのでリッチな言語処理系が動かない、という現実的な問題もあったはず
    • 要は人間や方法論の問題ではなくハードウェア的なリソースの制限があらゆるところで足を引っ張っていたのでは、という感想があります

「Domain-Driven Design」Eric Evans (2003)

  • これなんですが、この文脈でいうと「だんだんマシンや言語がリッチになってきた（≒オブジェクト指向言語とかも普通に使えるようになってきた）ので、その前提を踏まえればもっと設計と実装をシームレスにできるんでは？」という、従来の分析・設計・実装の流れを改善する提案だったような気がします
  • 詳しくは https://magazine.rubyist.net/articles/0063/0063-ForeWord.html をどうぞ
  • これに対してRailsは、もっとドラスティックに設計・実装を変える方向だったと言える気がします（※個人の見解です）
  • 合わせて書くと、DDD初出当時やそれ以前の開発方法論は、「既存のビジネスをどうやって機械化・自動化・電子化するか」みたいな方向が強く、そのために（既存の業務の）分析からはいる、という流れだったんじゃないかと思います
    • それに対して2000年代後半あたりから「Webだけでビジネスを作って儲ける」というのが生まれた気がします
      • 当然、Railsはこっち側のスタンスです
      • なお日本では2000年代前半からそれに先駆けてi-mode等のケータイビジネスのエコシステムというのが生まれていたのは実は重要だったのかもいう気はします（個人的にはそういうクローズドな囲い込みビジネスは好きじゃなかったのでほとんど関わってなかったのですが）
    • なのでそれ以前とそれ以後では開発方法論が大きく異なっているはずです

DHHがプロジェクト管理ツール「Basecamp」の開発にRubyを採用

  • ここでRubyの良さについて触れておくと、RubyはLisp族とかSmalltalkとかの「柔軟で便利な言語」の流れを汲みつつ、それらよりも「ふつう（≒CとかJavaとかに近い）っぽい見た目・処理系」だった、というのが大きいです
    • つまりRuby自体は新しいすごい機能があったわけではなく、言語おたくのMatzが先行する言語のいいところをいろいろつまみ食いしながら一つにまとめた、というのが大きいです
    • あと当然ながら後発の強みもあり、パッケージマネジメントシステムが早期に整備されたのも強みです
      • が、「早期」と言っても実質RubyGemsがまともに使えるようになったのはRails以降です

DHHはWebアプリケーション開発を大胆に抽象化した

  • これなんですが、逆になぜRails以外は大胆に抽象化できなかった（しなかった）かというと、サーバサイド開発（バックエンド開発）のリソースが大衆化（民主化、チープ化）されてなかった、というのも大きいかもです
    • そもそもproduction環境のDBと同じものを開発用クライアントマシンにインストールして使うのが一般的になったのが2000年代前半以降です
      • なぜならそれまではDBは有償だったので
        • 開発用の試用版とか開発用ライセンスとかはあった気がします
        • それでも社内の開発用サーバにインストール、みたいな感じで各自のローカル機にインストールするような雰囲気ではなかったです
      • PostgreSQLやMySQLを普通のproductionで使ってもいいかも？という雰囲気になってきたのがその頃です
    • そして開発用クライアントでLinux環境が手頃になってきたのもその頃です
      • coLinuxとかが流行ってました
    • またproduction環境についてはインフラエンジニアしか触れませんでした
      • デプロイはFTP/SFTP/rsyncあたりで、当然ながら手作業だったはず
    • あわせてDBもDBA（DBアドミニストレーター）が管理するのがめずらしくなかった
      • つまりDBマイグレーションを開発者が主導する、という発想の存在余地がなかった
    • そういう状況だと、GET /blogs/:id とか PUT /blogs/:id とかは実現が大変で、普通に実装すると/index.do?command=show_blog&id=123とか /blogs/update.php?blog_id=123 みたいになり、REST云々という発想にはなかなかならなかったのでした
      • 細かい話をすると、RailsにRESTが導入されたのは2.0以降です
      • 私は珍しくRails以前にRESTではしゃいでたREST勢だったのですが（日本では Webを支える技術 の山本陽平さんと他数名程度しかいなかった気がする…）、Railsが流行る前のRESTは単にWebのもととなるアーキテクチャスタイルというか、「ふつうのWebエコシステム全体」みたいなもので、それを個別のWebアプリケーションに適用されるもののように落とし込んだのはRailsの大きな功績（？）の一つです
  • つまり「開発者がコーディングから動作検証からDB管理からサーバの管理・デプロイまでを無双できる、その環境がある」という前提があって初めてRailsのような開発ができるわけで、これは当時としては野心的だったと言えそうです
    • 言い換えるとRailsみたいなのが出てきても「でもうちじゃ使えないよねえ」みたいな反応をされて終わり、みたいな感じです
      • 日本だと完全にこれでした
      • US等でも最初はおもちゃ扱いだったと思います
  • この辺りは今考えると、Railsは時代を先取りしていた感があります

RailsはDHHが強い思想で方向性を決めているフレームワーク

  • これもその通りなんですが、後ろのページの「もちろん大規模開発にも引き続き使われる」にもある通り、「強いこだわり」と「GitHub/Shopifyなどのふつうにでかいサービスでも使える利便性」が両立できている、そのバランス感覚がすごいなーというところです
    • このバランス感覚はDHH一人に帰属するところでもないはず

設定を明示的に書いて処理のマッピングを行うのではなく、規約を作ることで暗黙的に処理のマッピングが行われる仕組みにした

  • これは率直に言うとRubyの言語の表現力が（まだ）足りてないというせいもあると思うのですが、じゃあ他の（特に型とかの表現力が高い）言語でRailsみたいな爆速開発するためのフレームワークがあるかというとあんまりなさそうだなあ…という印象があります（※個人の感想です）
    • そういう「開発の瞬発力」みたいなのよりも「多人数でいろいろ開発しても破綻しない安定性・安全性」みたいなものを目指すのが多いとかなんですかね…？　他の事情は良く分かりませんが

DHHの考え方は仕事でも大事だったりする

  • 仕事をするうえでのDHHの参考にするべきところは、何よりも「DHHがめっちゃ稼いでいる・儲かってる（らしい）」ところですよね…
    • これで単に美しいだけとかたのしいだけとかだと（少なくとも仕事で開発するうえでは）説得力がないので
    • 「ビジネスでちゃんと成功する」というところからあくまでも軸足をずらさない、そういうpracticalなところがあるからこそ生まれる説得力というのはありそうに感じます

Rails のエコシステムに含まれていない技術は学びにくい

Railsは2025年においても、あくまでひとりで全てを行うことを指向している

  • 「ひとりで全てを行う」というか「ひとりでも全てを行える」、でしょうか（※資料反映済み）
    • 複数人数開発を否定しているわけではなく（そもそも37signalsが個人開発ではないはずなので）、複数人でも各自が全体を理解できてる、というのが理想だと思うので
  • 後ろに「マイクロサービス的分業の世界観」というのがありましたが、DHHはこの「分業」で壁を作ったり壁ができたりするのが嫌いで、この反発はRailsにも色濃く反映されてそうです
    • ここはDevOpsが登場する流れに通じるところがありますが、DHHは「じゃあ少人数でできるようにすればいいじゃん」の路線に行くところが独特です
      • 普通のDevOpsは人数を減らさずにうまいことやる路線かと思うので

資料に書いてないことについての補足コメント

  • 上で「多人数でいろいろ開発しても破綻しない安定性・安全性」と書きましたが、どうしても流行りの技術は開発者の人数も開発のためのリソースもいっぱいあるところから発信されることが多そう
    • そうじゃないと流行らない・流行りにくいので
    • あるいはSaaSとかの比較的大きなところが作る技術に乗っかって何か作る、みたいな技術とかが多そう
  • とはいえ普通の会社は人もリソースもいっぱいあるわけじゃない
  • Railsはそういう人やリソースが足りてないところで作られて・使われてきた、というのが強みの一つ
    • Railsが出てきた当時はそういう技術も多かった気がする
    • そういう時代の生き残り（サバイバー）的なところもある
      • 2020年代の現代でもその雰囲気を失ってないところは本当にやばい、すごい