どうもこんにちは。デジタルトランスフォーメーション(DX)事業本部エンジニアの石井です。
先日行われた、Kaigi on Rails 2021 で「事業に向き合い続けたい私は、それでもRailsを使い続ける」というタイトルで発表させていただきました。
スライドはこちらです:
改めてブログの方でも簡単に内容について触れたいと思います。
スタートアップでスキルコレクターになった話
このセクションは「私、手段を目的化しちゃっていました😇」という懺悔タイムになります。
私は元々フロントエンドエンジニアとしてキャリアをスタートしました。そして今から8年ほど前、知り合いが起業するということで創業メンバーとしてスタートアップにジョイン、そこで初めてRuby on Railsを始めとしたバックエンド開発も担当するようになりました。
当時、同じく創業メンバーとしてジョインしてくれたCTOがとにかくスキルフルだったこともあり、日々レビューをもらいながらRailsでバックエンドの機能開発ができるようになっていきました。新しいことがどんどん学べる環境で、とにかく楽しかったのを鮮明に覚えています。
そしてRails以外にも「AWS、もっと触れるようになりたい！」「Go、Swift、Kotlin、何でも触ってみたい！！」と闇雲に新しい技術をキャッチアップして、スキルの引き出しを増やそうとしていました。後先考えずに、メンバーの誰も使ったことのない技術を採用して悦に浸っていたこともありました。ごめんなさい。
2名体制のスモールチームでやっていた期間が長く、合意を取るハードルがあまり高くなかったため、「意識の高いエンジニアであれば新しい技術を採用して当たり前」ぐらいに考えていたと思います。
技術を使って事業上の課題を解決することに向き合っていきたいという話
このセクションでは
- 自分がエンジニアとして成すべきこと、目的からブレずに意思決定していくことが大事だと気づいた
- 私は「ただ技術をマスターすることではなく、技術を使って事業上の課題を解決すること」こそがエンジニアの役割だと定義し、それを軸に技術選定やキャリアの意思決定をするようになった
というお話をしました。
もちろん「新しい技術を学ぶ必要なんてないし、使う必要もない」などと主張したいわけではありません。
エンジニアとして新しい技術は積極的に触って、「その技術はどういった課題を解決するために生まれたのか？」「既存の何の技術をリプレイスし得る技術なのか？」など、その特徴やエッセンスを習慣的にインプットすることはとても大切だと思います。下地がないと技術選定なんて絶対できません。
私は採用業務に関わることも多く、カジュアル面談をさせて頂くこともあるのですが、「Goが好きなんで実務でも使いたいんです」や「とりあえず今はバックエンドメインでやっているんで、次はフロントエンドやインフラも触れる環境に行きたいです」のようなニュアンスの事をおっしゃる方も少なくありません。その気持ちはめちゃめちゃ分かりますし、私もそうでした。
特定の技術を軸として働くフリーランスや技術顧問であればそういった働き方も一つの選択だと思います。しかし事業と技術の相性が常にある以上、事業特性を無視してエンジニアの嗜好で特定技術を導入することは事業としてもエンジニアとしても不幸になります。
私の場合はスタートアップや新規事業に関わることがキャリアの大半だったため、「ユーザに価値を届ける or DIE」な環境下で「早くリリースし、早くユーザからのフィードバックを受けて学習し、改善する」という状態を達成し続けることが求められていたのだと改めて気づきました。今、自分が開発しているプロダクトが事業にとってどういうインパクトを与えるのかを理解し、その目的の達成のために最適な技術を常に選定すべきだったのです。
そしてスタートアップ時代も言語化できるほど解像度は高くなかったのですが、振り返ってみると当時も漠然とそのことは意識できていたのだと思います。事業にとってコアとなるプロダクトの開発では自分は常にRailsを使っていたことに気づいたのです。
このように、エンジニアとして自分は技術を使って事業上の課題を解決していくのだと認識することで、技術選定やキャリアの方向性で大きくブレることなく意思決定ができるようになったと思います。
事業を成長させるための武器としてRails最高では？でも辛みもあるのでは？という話
このセクションでは「実はRailsが強力な武器だった」と改めて気づいた私が思う、Railsの好きな所、辛い所についてお話しました。私が0→1開発ばかりをやってきたということもあって意見に偏りがあるとは思います。
Railsの好きな所
レールが用意されており、事業として本来やるべきコアな機能開発に集中することができるのがRailsの良い所なのではないかと思っています。
- 良い意味で枯れている
- ActiveRecord is 最高
- エコシステム(Gem)の充実
- 「こういう機能つくるならこのGem使うでしょ」となる
Railsの辛い所
Railsを使う場合、やはりフロントエンドまわりで悩むことが多いのではないでしょうか？
- ユーザの目が肥えてリッチなアプリケーションが標準みたいになってきている
- ReactやVueを使うのが近年のフロントエンドのデファクトスタンダードのように感じるが、Railsは別路線を突っ走ろうとしている雰囲気がある
- Hotwireのようなソリューションもあるが、ReactやVueと比較すると情報量やユーザ数は少なく、何かハマった時に辛そう
Railsとモダンな技術を良いとこ取りを試みた、直近のプロジェクトの話
最後に私が現在担当している新規事業での考え方や技術スタックについて簡単にご紹介しました。特に「Railsを使いたいけど、フロントエンドまわりが悩ましい...」と考えている方に何かしらの参考になればと思ってお話しました。
今回のプロジェクトでは事業目標を高速に達成し続けるために
- なるべく事業に必要なコアな機能開発に集中したい
- コアじゃないことであまり悩みたくない、ノンコアな機能開発はなるべく楽をしたい
- リッチなフロントエンド開発に耐えられるような構成にしたい
といった部分を特に大切にしたいと考えていました。
この考え方と現チームメンバーの得意な技術スタックをベースに技術選定をしています。実際の技術スタックに関してはスライドの方を参照してください。
話が逸れて混乱を招くと思い、今回は開発の詳細に踏み込んだ話は一切していません。機会があればGraphQLやAuth0の話なんかもしたいですね。
ちなみにこれは余談なのですが、以前、同僚が「なぜこのプロジェクトでこの技術を使うのか」といった技術選定の背景を「成功/失敗の判定要件」とともにドキュメントにまとめていたのが非常に良いなと思いました。こういった意思決定を後で振り返って、学びに変えられるようにしていきたいです。
[番外編] 今回のスライド作成について
今回のスライドはSlidevというものを使って作成してみました。
公式のREADMEに言われるがままにセットアップして、サンプルのスライドをローカルで確認できるようになるまでで5分もかからなかったと思います。すべてマークダウンで書けるし、必要に応じて直接HTMLやCSSも書けます。VercelやNetlifyを使ってシュっとデプロイできるし、PDFにエクスポートもできます。
とても開発体験が良かったので、もしLTなどする機会がある方はぜひ使ってみてください！ただし、 Slidev is still under heavy development.と書かれているので覚悟を持ってご利用ください。
今回作ったスライドの実装はこちら。
まとめ
私はこれまでの経験を経て、エンジニアの役割とは「ただ技術をマスターすることではなく、技術を使って事業上の課題を解決すること」だと考えました。事業で最速で成果を出すために私は今Railsを採用しているし、目的をしっかり理解した上で敢えて部分的にレールから外れる意思決定もしています。
もし事業に貢献して成果を出すことが求められているのに、闇雲に新しい技術をマスターしようとしていたら一旦立ち止まって考えてみてほしいです。そしてどうしても新しい技術使いたい欲が抑えられない場合はこちらで私がやっているように、OSS開発をするのがオススメです！
今回のトークが皆さんにとってのエンジニアの役割を考えるきっかけになれば幸いです。Kaigi on Railsの運営スタッフの皆様や当日遊びに来てくださった皆様、本当にありがとうございました！
今回の登壇内容を受けてSpeeeに興味が出たよという方がいらっしゃいましたら、募集中の職種をチェックしてみてください！
