Slide 1

Slide 1 text

RailsをPdM視点で見てみた @nyo_taro

Slide 2

Slide 2 text

自己紹介 井上 翔太朗(@nyo_taro) セールステックのPM/EM 特徴 ・JOB理論/DDD ・好きなエディタはVSCode ・コーヒーは最近浅煎りの酸味系 @nyo_taro

Slide 3

Slide 3 text

前提:今回の話のきっかけ バックボーンがエンジニアであり現在はPdM/EMというエンジニアではあるけれども開 発からはすこし離れた状態にあります。 Railsというものを、エンジニアからではなく現在の立場の視点で見たときにどう見え るのかというのJOB理論をベースに考えてみました。 @nyo_taro

Slide 4

Slide 4 text

前提:今回の話 主に私の調べた内容と知識を元にしているので、あくまで1つの視点と解釈として見て いただければと思います。 @nyo_taro

Slide 5

Slide 5 text

今日の発表で話すこと 開発者はどんな課題をもっていたのか? RailsはどのようなJOBを完了させたのか? @nyo_taro

Slide 6

Slide 6 text

JOBとは 「ある特定の状況で人が達成しようとする進歩」 雇用者はゴールに向かって進歩しようとしている。 @nyo_taro

Slide 7

Slide 7 text

JOB理論とは何か? 「JOB理論(Jobs To Be Done、JTBD)は、顧客が課題を解決するためにプロダクトを 『雇う』 @nyo_taro

Slide 8

Slide 8 text

Railsの基本理念 設定より規約 (COC): Convention over Configuration 同じことを繰り返さない(DRY): Don't Repeat Yourself @nyo_taro

Slide 9

Slide 9 text

ここからは開発者に対してRailsを提供する視点で見て いきます。 @nyo_taro

Slide 10

Slide 10 text

当時の状況(一部のみ) 1990年代初頭:CGI、PHPなどスクリプト言語を使って手動でコードを書く 2000年:Strutsの登場 Javaベースの大規模なWebアプリケーション開発に適していたが設定が煩雑 で、XMLファイルの記述に多くの時間がかかる 2002年:ASP.NETなどのフレームワークの登場 企業向けに広く使われた。Windowsサーバーとの統合が強力なため、 Microsoftの技術スタックに依存した企業での採用されていた。 2004年:Ruby on Railsの登場 @nyo_taro

Slide 11

Slide 11 text

開発者が達成したいJOB 良質で価値あるアプリケーションを素早く構築したい @nyo_taro

Slide 12

Slide 12 text

開発者が達成したいJOBへの障害 大量の設定ファイルの作成 毎回のライブラリの選択 手作業でのCRUD操作などの実装 @nyo_taro

Slide 13

Slide 13 text

DHHはどのような視点でRailsを開発したのか? @nyo_taro

Slide 14

Slide 14 text

DHHの考え1 生物はConfiguration(設定)をいじりまくるのではなく、Convention(規約)をその まま援用している。いろいろ設定を変えてうまくいくものだけ拾い出すより、きちんと 動く設定を少しずつ変えるほうがうまくいくんだ。 https://gihyo.jp/dev/serial/01/alpha-geek/0006 @nyo_taro

Slide 15

Slide 15 text

DHHの考え2 コーディング規約にまつわる長年の争いを考えてみてください。 「括弧をどこに置く」 などといったキマリにみんなが従えば、コードは読みやすく、整形されたものになる でしょう。ただし通常、これはあまりうまく機能しません。規約に従うことで得られ るメリットが、全然魅力的ではないからです。チームのコードが整形されることなん て、プログラマ個人の「自由」に比べたらぜんぜん重要じゃないわけですよ。 https://kdmsnr.com/translations/interview-with-dhh/ @nyo_taro

Slide 16

Slide 16 text

DHHの考え3 データベースの主キーがどのような形式で記述されているかなんて、誰が気にするでし ょうか? 「id」 、 「postId」 、 「posts_id」 、または「pid」のいずれであっても、本当に重要 なのでしょうか? これは、繰り返し検討する価値のある決定でしょうか? いいえ。 https://postd.cc/rails-doctrine/ @nyo_taro

Slide 17

Slide 17 text

「良質で価値あるアプリケーションを素早く構築」の 達成のために何を解決したのか? @nyo_taro

Slide 18

Slide 18 text

機能的な変化(機能的JOB) 設定作業の簡素化: 膨大な設定ファイルを必要とする従来のフレームワークに対し、デフォルトの規約に 従うことで、手動での設定作業を最小限に抑えた 開発者の意思決定負担を軽減: 開発者が毎回同じ設定や選択を行う必要がなく、無駄な意思決定の負担を減らし、重 要な部分に集中できるようにした @nyo_taro

Slide 19

Slide 19 text

気持ちの変化(感情的なJOB) 早期の成功体験の提供 Rails哲学には、開発者の幸福という概念も含まれている 開発者が複雑で煩雑な作業から解放され、クリエイティブで楽しい部分に集中できる 環境を提供されるように作られた @nyo_taro

Slide 20

Slide 20 text

社会的な変化(社会的なJOB) オープンソースのコミュニティ RailsWorld、Kaigi on Railsなどのコミュニティという活発な共通基盤を持つことで他の 開発者と共通の知識や経験を共有することができる @nyo_taro

Slide 21

Slide 21 text

ここから実際の過去のバージョンごとの解決していっ たことを見ていきます。※ 時間余れば @nyo_taro

Slide 22

Slide 22 text

Rails 1.x: 迅速なプロトタイピングの実現 開発者のジョブ 問題: 複雑な設定やインフラ整備が時間を要し、迅速なアプリケーション立ち上げ が困難。 Railsの解決策 解決方法: 「設定より規約」 (Convention over Configuration)の導入。 成果: プロジェクトを素早く開始し、短時間でプロトタイプが作成可能に。 @nyo_taro

Slide 23

Slide 23 text

Rails 2.x: RESTfulアーキテクチャの導入 開発者のジョブ 問題: リソースの管理が不統一で、API開発が煩雑。 Railsの解決策 解決方法: RESTfulアーキテクチャの標準化。 成果: 統一されたAPI設計が容易に。 @nyo_taro

Slide 24

Slide 24 text

Rails 3.x: モジュール化とメンテナンスの向上 開発者のジョブ 問題: プラグインの管理が難しく、依存関係の問題が発生。 Railsの解決策 解決方法: プラグインからGemへの移行、ActiveRecordの強化。 成果: メンテナンス性と依存関係管理の向上。 @nyo_taro

Slide 25

Slide 25 text

Rails 4.x: モダンなAPI開発とリアルタイム機能のサポ ート 開発者のジョブ 問題: リアルタイム機能のサポート不足とAPI開発の手間。 Railsの解決策 解決方法: ActionController::Live によるリアルタイム機能とAPIモードのサポー ト。 成果: リアルタイム機能と軽量なAPI開発のサポート。 @nyo_taro

Slide 26

Slide 26 text

Rails 5.x: WebSocketとリアルタイム通信の簡素化 開発者のジョブ 問題: WebSocketのサポートが不十分でリアルタイム性に欠ける。 Railsの解決策 解決方法: ActionCable の導入。 成果: リアルタイム通信の統合とAPI開発の強化。 @nyo_taro

Slide 27

Slide 27 text

Rails 6.x: スケーラブルなアーキテクチャのサポート 開発者のジョブ 問題: マイクロサービス化やスケールアウトの困難さ。 Railsの解決策 解決方法: Zeitwerk やマルチデータベースのサポート。 成果: スケーラブルな設計とマイクロサービス化の視野を拡大。 @nyo_taro

Slide 28

Slide 28 text

Rails 7.x: No-JSフロントエンドとTurboの導入 開発者のジョブ 問題: フロントエンド技術の複雑化。 Railsの解決策 解決方法: Turbo と Stimulus の導入。 成果: JavaScriptの依存を減らし、簡単なインタラクティブUI構築が可能に。 @nyo_taro

Slide 29

Slide 29 text

参考リンク 1. https://rubyonrails.org/doctrine 2. https://kdmsnr.com/translations/interview-with-dhh/ 3. https://www.nityesh.com/dhh-rails-promise 4. https://www.publickey1.jp/blog/24/ruby_on_railsdhhruby_on_rails_the_documentary_ 1.html 5. https://blog.tai2.net/rails_is_omakase.html @nyo_taro