事業に向き合い続けたい私は、それでもRailsを使い続ける

こちらの発表内容です。
https://kaigionrails.org/2021/talks/danimal141/

Transcript

1. 事業に向き合い続けたい私は、 それでもRails を使い続ける @danimal141 Kaigi on Rails 2021
2. 今回、私はこういう話をするために来ました
3. エンジニアの責任とは「ただ技術をマスターすることではな く、技術を使って事業上の課題を解決すること」ではないか
4. それを達成するための武器として、Rails って最高では？
5. Rails ですべての課題を解決できるわけではない モダンな技術の力も借りてコトに向き合っていきたいすね
6. 自己紹介 @danimal141 フロントエンドエンジニアとしてキャリアスタート ベンチャー -> ソシャゲの会社 -> (7 年ぐらい) 創業メンバーとしてスタートアップへ -> ( 今ここ) Speee 0 →1 開発が多め、エンジニア採用関連の仕事もやりがち ( 得意) 自分が一生懸命書いたコードを何のためらいもなく削除することッ！ エンジニア歴10 年ぐらい Rails 歴は8 年ぐらい 今日のスライドはこちらから見れます！ https://bit.ly/3EboMEG
7. アジェンダ スタートアップでスキルコレクターになった話 技術を使って事業上の課題を解決することに向き合っていきたいという話 事業を成長させるための武器としてRails 最高では？でも辛みもあるのでは？という話 Rails とモダンな技術を良いとこ取りを試みた、直近のプロジェクトの話 まとめ
8. スタートアップでスキルコレクターになった話
9. 突然なんですけど
10. エンジニアの方なら一度はこんなこと考えたことない ですか？ 最近はGo やRust が流行ってるらしいから使ってみたいなぁ サーバサイドKotlin とかめっちゃイケてませんか？ このままでいいのか、モダンな技術を習得して変化しないといけないんじゃないか…
11. わかる
12. めちゃめちゃわかる
13. 過去の技術選定 ( 特にスタートアップ時代) 振り返り 受託開発なのを良いことに 1 ミリも使ったことないのに急にGo でAPI 実装しちゃう 受託開発なのを良いことに 発表されたばかりのSwift でiOS 開発しちゃう 社内のデータ分析基盤を作るためのデータ収集コマンドが急にKotlin で実装されちゃった もちろんそれぞれ、それなりの理由はあったのですが、「モダンだからひとまず使ってみたい、知らない技術 をキャッチアップしたい」というモチベーション駆動技術選定だったことは否めないと思っています。 I’m a skill collector!
14. もやっとポイント やはりエンジニアならモダンな技術を使いたい！マスターしたい！! 「達人プログラマーなら毎年少なくとも一つの言語を学習します」 -> 本当に？ 自分が一番得意な技術がオワコンって言われていてツライ！！ あれ、そもそもなんでそんなに新しい技術マスターしたいんだっけ？マスターして何するんだっけ？ 使ったとして自分以外、誰か嬉しいんだっけ？ 🧑‍💻 それって事業に貢献できるの？ユーザの役に立つの？ 🧑‍💻 チームのエンジニア全員、その技術覚えないといけないけど、大丈夫そ？ 🧑‍💻 今後、チーム拡大する時、採用大丈夫そ？ 技術選定 is 難しい…
15. 何を軸に考えればええんや… 技術との向き合い方に迷走する
16. 技術を使って事業上の課題を解決することに向き合っ ていきたいという話
17. そもそも技術選定って何のためにするんだっけ？ 世の中やユーザのニーズは日々変化するし、早くリリースして、早くユーザのフィードバックを得て改善し ていく必要がある Done is better than perfect… 特にスタートアップの場合、「ユーザに価値を届ける or DIE 」 これを達成し続けられる状態にできるかどうか スタートアップや0 →1 開発をメインでやってきた私の場合
18. エンジニアの責任とは「ただ技術をマスターすることではな く、技術を使って事業上の課題を解決すること」ではないか
19. 事業を成長させるための武器としてRails 最高では？で も辛みもあるのでは？という話
20. ここで気づいてしまいましたッ！
21. Rails って良くないですか？
22. 過去の技術選定 ( 特にスタートアップ時代) 振り返りv2 確かに受託開発でモダンな技術を試しまくったりした 楽しかったなぁ🕺 社内のデータ分析基盤を作るためのデータ収集コマンドをKotlin で実装したこともあった 楽しかったなぁ🕺 でも、「なにかしらユーザに価値を届けたい」、「ユーザのためにプロダクトをとにかく高速に育てていき たい」、そういった場面では常にRails を採用してきた それが事業上の目的を達成するための最速、最良の選択だと思っていたから
23. Rails の好きな所 事業として本来やるべきコアな機能開発に集中することができる レールが用意されているので、「どういう構成で作ろう」、「どうやって作ろう」みたいな部分でそこ まで悩まない ActiveRecord is 最高 エコシステム(Gem) の充実 0 →1 開発に向いている まず動くものを作り、ユーザのフィードバックを受けながらプロダクトを高速に改善して育てていくス タイル
24. 一方で
25. Rails でこういう時ちょっと辛くないですか？ フロントエンドどうする問題 ユーザの目が肥えてリッチなアプリケーションが標準みたいになってきている 細かいサイクルで変化するフロントエンドのView をjQuery やBackbone.js で実現するのは厳しい ( 個人の 意見です) もちろんHotwire のようなソリューションもあるが、React やVue と比較すると情報量やユーザ数は少な く、何かハマった時ツラそう…
26. こういったRails のメリット、デメリットを踏まえて
27. Rails とモダンな技術を良いとこ取りを試みた、直近の プロジェクトの話
28. 直近のプロジェクトの話 不動産領域で新規プロダクトを開発しています！ ユーザと不動産会社の担当者がやり取りするチャットUI リアルタイム更新 toB 向け、toC 向けにそれぞれプロダクトを提供する 複雑な条件入力フォーム
29. 技術選定軸 なるべく事業に必要なコアな機能開発に集中したい コアじゃないことであまり悩みたくない、なるべく楽したい リッチなフロントエンド開発に耐えられるような構成にしたい
30. Backend Rails (API) Rails Way に乗ることで本来やるべきコアな機能開発に集中したい メンバーが使い慣れている GraphQL 不動産領域を扱っており「物件とそれに紐づく様々な情報」という関係性のデータ構造が多く、かつ肝 になる 型定義によるバリデーションがあり、フロントエンドでTypeScript を使う想定だったので相性が良い チャットでリアルタイム更新があり、Subscription が使えそう (GraphQL Pro を使っています) Auth0 認証、認可などアプリケーション上、必要だがプロダクトにとってコアではないものはできるだけショ ートカットしたい
31. Frontend (toB 、toC がある) React.js チャットUI のような複雑なView の開発が求められたのでReact かVue を使いたい メンバーが使い慣れている、TypeScript との親和性を考慮してReact TypeScript クリックやスクロールのように、ユーザ起点でのイベントが大量に発生するフロントエンドを中長期的 に生産性高く開発する上で必須と考えた
32. Infra あまり詳細触れないですが、開発生産性を高めるような技術を積極的に採用しています！ AWS Kubernetes Terraform
33. まとめ 自分の成すべきこと、目的からブレずに意思決定をするのが大切 エンジニアの役割とは「ただ技術をマスターすることではなく、技術を使って事業上の課題を解決するこ と」 皆様も自分なりのエンジニアの役割について考えてみてほしいです！ 事業の課題を解決していく上でRails ってやっぱり良いっすね、でも辛い時もあるっすね Rails の良さを活かしつつ、モダンな技術も採用して、コトに向き合って行きましょう💪😎 プロジェクトの具体的な話などはあまり詳しくお話できていないので、もし興味持ってくださった方はQA ブ ースでお待ちしております！ ただの雑談や家の売却や購入を検討されている方も大歓迎です🙋‍♂️