RailsをPdM視点で見てみた

Transcript

1. RailsをPdM視点で見てみた @nyo_taro
2. 自己紹介 井上 翔太朗(@nyo_taro) セールステックのPM/EM 特徴 ・JOB理論/DDD ・好きなエディタはVSCode ・コーヒーは最近浅煎りの酸味系 @nyo_taro
3. 前提：今回の話のきっかけ バックボーンがエンジニアであり現在はPdM/EMというエンジニアではあるけれども開 発からはすこし離れた状態にあります。 Railsというものを、エンジニアからではなく現在の立場の視点で見たときにどう見え るのかというのJOB理論をベースに考えてみました。 @nyo_taro
4. 前提：今回の話 主に私の調べた内容と知識を元にしているので、あくまで1つの視点と解釈として見て いただければと思います。 @nyo_taro
5. 今日の発表で話すこと 開発者はどんな課題をもっていたのか？ RailsはどのようなJOBを完了させたのか？ @nyo_taro
6. JOBとは 「ある特定の状況で人が達成しようとする進歩」 雇用者はゴールに向かって進歩しようとしている。 @nyo_taro
7. JOB理論とは何か？ 「JOB理論（Jobs To Be Done、JTBD）は、顧客が課題を解決するためにプロダクトを 『雇う』 @nyo_taro
8. Railsの基本理念 設定より規約 (COC): Convention over Configuration 同じことを繰り返さない（DRY）: Don't Repeat Yourself @nyo_taro
9. ここからは開発者に対してRailsを提供する視点で見て いきます。 @nyo_taro
10. 当時の状況(一部のみ) 1990年代初頭：CGI、PHPなどスクリプト言語を使って手動でコードを書く 2000年：Strutsの登場 Javaベースの大規模なWebアプリケーション開発に適していたが設定が煩雑 で、XMLファイルの記述に多くの時間がかかる 2002年：ASP.NETなどのフレームワークの登場 企業向けに広く使われた。Windowsサーバーとの統合が強力なため、 Microsoftの技術スタックに依存した企業での採用されていた。 2004年：Ruby on Railsの登場 @nyo_taro
11. 開発者が達成したいJOB 良質で価値あるアプリケーションを素早く構築したい @nyo_taro
12. 開発者が達成したいJOBへの障害 大量の設定ファイルの作成 毎回のライブラリの選択 手作業でのCRUD操作などの実装 @nyo_taro
13. DHHはどのような視点でRailsを開発したのか？ @nyo_taro
14. DHHの考え1 生物はConfiguration（設定）をいじりまくるのではなく、Convention（規約）をその まま援用している。いろいろ設定を変えてうまくいくものだけ拾い出すより、きちんと 動く設定を少しずつ変えるほうがうまくいくんだ。 https://gihyo.jp/dev/serial/01/alpha-geek/0006 @nyo_taro
15. DHHの考え2 コーディング規約にまつわる長年の争いを考えてみてください。 「括弧をどこに置く」 などといったキマリにみんなが従えば、コードは読みやすく、整形されたものになる でしょう。ただし通常、これはあまりうまく機能しません。規約に従うことで得られ るメリットが、全然魅力的ではないからです。チームのコードが整形されることなん て、プログラマ個人の「自由」に比べたらぜんぜん重要じゃないわけですよ。 https://kdmsnr.com/translations/interview-with-dhh/ @nyo_taro
16. DHHの考え3 データベースの主キーがどのような形式で記述されているかなんて、誰が気にするでし ょうか? 「id」 、 「postId」 、 「posts_id」 、または「pid」のいずれであっても、本当に重要 なのでしょうか? これは、繰り返し検討する価値のある決定でしょうか? いいえ。 https://postd.cc/rails-doctrine/ @nyo_taro
17. 「良質で価値あるアプリケーションを素早く構築」の 達成のために何を解決したのか？ @nyo_taro
18. 機能的な変化(機能的JOB) 設定作業の簡素化: 膨大な設定ファイルを必要とする従来のフレームワークに対し、デフォルトの規約に 従うことで、手動での設定作業を最小限に抑えた 開発者の意思決定負担を軽減: 開発者が毎回同じ設定や選択を行う必要がなく、無駄な意思決定の負担を減らし、重 要な部分に集中できるようにした @nyo_taro
19. 気持ちの変化(感情的なJOB) 早期の成功体験の提供 Rails哲学には、開発者の幸福という概念も含まれている 開発者が複雑で煩雑な作業から解放され、クリエイティブで楽しい部分に集中できる 環境を提供されるように作られた @nyo_taro
20. 社会的な変化(社会的なJOB) オープンソースのコミュニティ RailsWorld、Kaigi on Railsなどのコミュニティという活発な共通基盤を持つことで他の 開発者と共通の知識や経験を共有することができる @nyo_taro
21. ここから実際の過去のバージョンごとの解決していっ たことを見ていきます。※ 時間余れば @nyo_taro
22. Rails 1.x: 迅速なプロトタイピングの実現 開発者のジョブ 問題: 複雑な設定やインフラ整備が時間を要し、迅速なアプリケーション立ち上げ が困難。 Railsの解決策 解決方法: 「設定より規約」 （Convention over Configuration）の導入。 成果: プロジェクトを素早く開始し、短時間でプロトタイプが作成可能に。 @nyo_taro
23. Rails 2.x: RESTfulアーキテクチャの導入 開発者のジョブ 問題: リソースの管理が不統一で、API開発が煩雑。 Railsの解決策 解決方法: RESTfulアーキテクチャの標準化。 成果: 統一されたAPI設計が容易に。 @nyo_taro
24. Rails 3.x: モジュール化とメンテナンスの向上 開発者のジョブ 問題: プラグインの管理が難しく、依存関係の問題が発生。 Railsの解決策 解決方法: プラグインからGemへの移行、ActiveRecordの強化。 成果: メンテナンス性と依存関係管理の向上。 @nyo_taro
25. Rails 4.x: モダンなAPI開発とリアルタイム機能のサポ ート 開発者のジョブ 問題: リアルタイム機能のサポート不足とAPI開発の手間。 Railsの解決策 解決方法: ActionController::Live によるリアルタイム機能とAPIモードのサポー ト。 成果: リアルタイム機能と軽量なAPI開発のサポート。 @nyo_taro
26. Rails 5.x: WebSocketとリアルタイム通信の簡素化 開発者のジョブ 問題: WebSocketのサポートが不十分でリアルタイム性に欠ける。 Railsの解決策 解決方法: ActionCable の導入。 成果: リアルタイム通信の統合とAPI開発の強化。 @nyo_taro
27. Rails 6.x: スケーラブルなアーキテクチャのサポート 開発者のジョブ 問題: マイクロサービス化やスケールアウトの困難さ。 Railsの解決策 解決方法: Zeitwerk やマルチデータベースのサポート。 成果: スケーラブルな設計とマイクロサービス化の視野を拡大。 @nyo_taro
28. Rails 7.x: No-JSフロントエンドとTurboの導入 開発者のジョブ 問題: フロントエンド技術の複雑化。 Railsの解決策 解決方法: Turbo と Stimulus の導入。 成果: JavaScriptの依存を減らし、簡単なインタラクティブUI構築が可能に。 @nyo_taro
29. 参考リンク 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