RailsをPdM視点で見てみた

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

参考リンク 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

RailsをPdM視点で見てみた

RailsをPdM視点で見てみた

nyo_taro

More Decks by nyo_taro

Featured

Transcript