RIZAP、Kaigi on Railsにも初参戦！  

Railsを扱うエンジニアが集まる年次イベント、「Kaigi on Rails」が今年10月、東京・浅草で初めてオフライン開催されました。  

積極的にカンファレンスへの参加しているわれわれRIZAPももちろん参戦！ 

ここでは会期中に開催された数々の講演（セッション）の中から、新卒メンバーたちがとくに印象に残ったセッションの感想をまとめました！  

※RIZAPはKaigi on Railsのスポンサー  

＞＞＞＞関連記事  
RIZAP がKaigi on Rails 2023にも初参戦！【現場レポート】はこちら 

大杉貫剛の感想まとめ 

①HTTPリクエストを手で書いて学ぶ ファイルアップロードの仕組み 

【セッションの主な内容】 

ファイルアップロードを行う際に、サーバーとブラウザ間で行われているHTTPについてのセッションです。本セッションのゴールとしては、ファイルアップロードの処理を抽象化して理解できるようになることでした。 

アジェンダは主に以下の三つ。 

1. ファイルの理解 

ファイルのデータ型をまずは理解する。ファイルはバイナリ型であり、多くのバイナリは初めにマジックナンバーがついている。このマジックナンバーをサーバーが解釈することによってアップロードができる。 

2. POSTメソッドを使ったアップロード 

本セッションでは前提として、POSTを使ったファイルアップロードの形式は、HTMLのform要素に絞って考える。 

「＆」と「＝」を特殊文字列として認識し、ファイルをアップロードする。ただ、ファイル名に「＆」や「＝」が存在していた場合、エラーとなるためBase64という技術がある。Base64ではバイナリをテキストに変更することで、ファイル名の「＆」や「＝」を誤って認識させることを避けられる。 

3. PUTメソッドを使ったアップロード 

PUTメソッドでは、オブジェクトストレージを使ってアップロードすることになる。 事前にオブジェクトストレージを用意しておき、その中身を変更するのでPUTメソッドを使う。 今回は一例として、content-rangeによる再開可能なアップロードが紹介された。 どこまでアップロードできるのかを知り、続きから始めるためにcontent-rangeを使っており、これにより再開可能を実現する。 

実際に会場ではデモンストレーションが行われ、270バイトのものを90バイトまでしかアップロードできない状況で、90バイト×３回再開可能なアップロードする様子が見られた。 

【感想】  

ファイルアップロードを行う際に、サーバーとブラウザ間で行われているHTTPについてのセッションでした。 とくに印象的だったのは、POSTメソッドを使ったアップロードの内容でした。 

概要部分でも紹介しましたが、基本的にファイルを認識する方法は、受け取ったバイト列に対して「＆」と「＝」を認識して、Hash形式でnameとvalueのペアにするというものです。そのためファイル名に「＆」や「＝」が存在していたら、ファイル名の「＆」や「＝」を認識して区切ってしまうので、期待していたnameとvalueは得られません。 

これを解決するのがエンコードであり、その代表例としてBase64エンコードがあることを理解できました。私自身も、Railsを使って初めてファイルアップロードに挑戦した時、なぜかはわからないけれどBase64を用いるとできるという経験があったのですが、今回HTTPの仕組みを含めて、初めてその理由を学べました。 

総じて、今回のセッションではアプリケーションにとって身近なアップロードについて、実際にブラウザとサーバーの間でどういったことが行われているのかを理解できました。実際、RIZAPの研修でも「コードの裏で何が起こっているのかを徹底的に理解することが重要」という考えがあり、今回のセッションでもそうした裏側の挙動を深掘ることができました。 

②事業の試行錯誤を支える、コードを捨てやすくしてシステムをシンプルに保つ設計と工夫 

 【セッションの主な内容】 

新規事業を立ち上げてアプリケーションを作る0→1の段階で開発者が考えるべきことについて、 zuckey さん（登壇者）の視点で語られたセッションです。 

セッションの結論から言えば、「アプリケーションを作る際には、削除することを想定して機能を作成・追加せよ」ということ。 実際にスピーカーがプロダクト開発の案件を任された際に直面した例をもとに、その重要性を説いていました。 

その例は以下の通り。 

• たとえば、クライアントから「部署ごとで見たい情報が異なるため、新しいデータを閲覧するための機能を追加したい」と言われたとする。これはデータベースにカラムを追加すれば単純に希望を反映できるが、その後結局あまり使用しないとクライアントから申し出があれば、それは技術的負債となり削除する必要性に迫られる。 

この時カラムを削除する場合は、付随してカラムに関連したコードの削除が必要となり、ファイルごとに削除箇所の見落としを完全に防ぐのは極めて困難である。 

• こうした事態に陥らないように、テーブルを別で作成し関連づけるべきである。テーブル作成であれば、ディレクトリごとの管理になるため、削除したい場合にはディレクトリごと削除すれば機能をそのままなくすことができるというメリットがある。 

【感想】  

セッションを聞いて研修時に「役割範囲を明確にせよ」とよく言われていたことを思い出しました。 

たとえば、controllerファイルでUser.allとクエリを発行してDBとやりとりを行う中で、viewファイルにもUser.findと書いてしまったことがありました。これではファイルごとの役割やcontroller, viewの役割を理解できていない未熟なプロダクトだと言わざるを得ません。 

今回の「機能の削除を前提としたアプリ開発の要点」は、こうした役割をきちんと理解できて初めて実践できるものだと感じました。 

事業部の視点では削除するだけだと思っていることもエンジニア視点で見れば難解なことがある。そういったお互いの視点を持ち合わせながら活躍できる人材になるため、今後は本セッションでの学びを意識しながら業務にあたっていきたいと感じました。 

③Railsアプリにパスワードレス認証を導入した知見 

【セッションの主な内容】 

パスワードレス認証として話題のパスキーを導入した話でした。 

アジェンダは以下の三つ。 

1. パスキーとは何か 

パスキーとはパスワードを使わない、WebAuthnの拡張のこと。認証機（たとえばスマホなど）を使用してWebで行う認証のことで、指紋認証などが代表例として挙げられる。 

実際にユーザーはパスワード等を入力しないために便利であり、ユーザーの生体認証などを用いるためセキュリティー面でも安心というメリットを持つ。 

2. パスキーの導入方法 

導入ステップは登録と認証の２ステップある。 

登録については、まずサーバーにアクセスしランダムに生成したトークンを返す。このトークンを返却する仕様を自作して実装するのは困難なので、Railsにおいてはgem（https://github.com/cedarcode/webauthn-ruby）が用意されている。これがRailsの大きな強みである。サーバーで生成されたトークンをもとにデバイスでトークンを生成し、そのトークンをサーバーサイドに送り返し保存しておくことで登録できる。 

3. パスキー導入時の注意点 

 導入時の注意点として、発展途上のgemであるために起こる問題が挙げられていた。たとえばuserHandleがuser.idとなっているようなgemのレベルによってパラメータ名が異なっていることがある。そのため最新の状態を都度チェックするようにすることが重要。 

【感想】  

ちょうど自分がパスワード認証やGoogle認証といった認証機能の実装を学んでいる段階だったので、さらに先端の認証機能についても学べればというモチベーションで参加しました。 

セッションを聞き、Railsには本当に便利なライブラリが数多く用意されていると改めて感じました。 

セキュリティーについて学べば学ぶほどに、自作した認証機能ではどうしても脆弱（ぜいじゃく）性を拭いきれないことを痛感したのですが、Railsでは今回のwebauthnやgoogle認証のためのomniauth-google-oauth2などのgemが用意されているおかげで簡単にセキュアなアプリケーション開発できます。 

ただ、そうしたgemに頼りっぱなしになるのではなく、自分自身でもきちんとgemについて調べ、実装する時には信頼できるgemであるかなどを吟味する必要があるなと感じました。その意味で、今回のようにライブラリについての最新の知見を得られるカンファレンスに参加することは、非常に大切なことだと感じました。 

高城友梨香の感想まとめ 

①自分の道具を自作してつくる喜びを体感しよう、Railsで。 〜4年続いたPodcastを実例に〜 

【セッションの主な内容】 

スピーカーはTakuya Mukohira さん。 

「業務外でもコードを書きたいけど作りたいものがない」という状態だったところから、サイドプロジェクトで使う道具を自分で作り改善することを通じて、楽しみながら技術的な成長と作る喜びを得られたという経験談です。 

その中で、Takuyaさんが開発されたpodcastを軸に話してくださいました。 

Podcastとは、音声や動画などのデータをインターネット上に公開するサービスです。 

Takuyaさんは過去にいくつかアプリ制作を行ってきたものの、あまり続かなかったそうですが、podcastでは３年連続毎週更新を達成したとのこと。背景として、podcastを趣味としても開発業務としても、バランスよく楽しめていたからと挙げていました。また、音声配信を自作したためログも取れるようになったそうです。 

【感想】  

私もRailsアプリを自作したいと思っているめ、このセッションは絶対見に行こうと決めていました。また、 Takuya Mukohiraさんは私と同じ高専出身ということもあり、楽しみに していたセッションの一つです。 

Takuya MukohiraさんはPodcastの毎週更新を３年連続で達成できた理由として、「自分の道具を自分で作り改善し続けていたこと」を挙げていました。 

「今までさまざまなアプリを作成したが、自分自身でも使いたいと思うアプリでない限り、放置してしまう」ともおっしゃっていて、自分自身でも触りたい、利用したいと思うものを作成することで、作る喜びが感じられ、それがその後の生産性にも関わるのだと実感しました。セッションを聴いて、私自身も自分が利用したいと思うようなものづくりをしたいと強く思いました。 

②ペアプロしようぜ 〜3人で登壇!? 楽しくて速いペアプロ/モブプロ開発〜 

【セッションの主な内容】 

本セッションでは、スピーカーの皆さんがモブプロ・ペアプロのよさをお話ししてくださり、本格的なやり方も実践形式で教えてくださいました。 

ペアプロよりソロプロのほうが開発速度に関しては速くなりますが、開発のレビューや修正などを行ううえで、結果的にペアプロのほうが作業工数は減るという内容でした。 

また、ソロプロの辛かったランキングとして、「１位：レビューが終わらない問題」、「２位：属人化」、「３位：新メンバーがキャッチアップしにくい」が挙げられていましたが、こうした課題をペアプロ・モブプロは解決できる、というお話でした。 

次にペアプロ・モブプロの課題に直面し、それを解決した方法を教えてくださいました。 

一つ目課題：始め方がわからない→解決：スラックの画面共有を使用した 

二つ目課題：迷走しがち→解決：開始前に方針を書き出す 

三つ目課題：疲労コンパイラー→解決：こまめに休憩（１時間経過したら10分） 

四つ目課題：いつ交代するかわからない→解決：時間制で交代 

五つ目課題：ドライバーが全て行ってしまう→解決：主役はナビゲーター 

【感想】  

ペアプロという開発手法があると聞いたことはありましたが、自分で行ったことはもちろん、実際に行っているのを見たこともなかったので、今回のセッションはとても楽しみにしていました。 
ドライバーが一人に対してナビゲーターが二人という実践形式の発表もしてくれて、見ていても飽きない、面白い内容でした。 

とくに印象に残ったのは、「ドライバーが主軸となってしまう」という課題に関してです。 
ここではペアプロの主人公はナビゲーターとされていて、ドライバーはナビに言われた通りのコードを一度書いてから、それに対して意見を述べるという段階を踏んでいました。 
確かに、ドライバーが自分自身で考えたコードを書き続けると、ペアプロの意味をなしません。ここではナビゲーターが主人公になることにより、全ての人がコードに対しての責任を持つ環境が得られていました。 

また、全ての人がコードに対してのレビューを行うことで全員の理解が一致し、レビュー依頼からマージまで30分で終わらせていたのがすごかったです！ 
これを機に、自分でもペアプロに取り組んでみたいです。 

ペアプロでは、最初に方法の規約を確立させることが、のちの効率アップに大いにつながることも学べました。むやみに始めるのではなく、一つ一つの順序を気にしながら行おうと思いました。 

また、RIZAPで行っているエンジニア育成プログラムにペアプロを導入するのも面白そうだと感じました。 

大塚和哉の感想まとめ 

①Hotwire的な設計を追求して「Web紙芝居」に行き着いた話  

 【セッションの主な内容】 

株式会社万葉で社長を務められている大場さんのセッションです。 会社としてもHotwireを推しており、Turbo Handbookの日本語翻訳サイトも公開されています。 今回は大場さんがHotwireを使っていく中で発見した、性質や設計指針についてのお話です。  

まず、画面更新設計のアプローチは大きく分けて二つあると述べられています。  

1. 部品的アプローチ  

2. 画面的アプローチ  

部品的アプローチは画面を「部分的に更新する」処理を書くことです。  

一方で画面的アプローチは「部分的に変更された結果画面」へ遷移することです。この遷移が紙芝居のようだということで、今回の題材にもなっている「Web紙芝居」とも呼んでいます。  

基本的にオブジェクト指向に慣れているエンジニアとしては、部品的アプローチを考えがちです。というのも、ソフトウエア設計では「責務の分離」、いわゆる「SOLIDの原則」が良い設計とされているからです。しかし、部品的アプローチとHotwireの相性はそこまで良くないと大場さんは述べています。  

では、なぜ部品的アプローチとHotwireと相性が良くないのか、それはアプリの制御がクライアント寄りになってしまうからです。画面の一部分を更新しようとする場合、SPAであればDOMを使用してクライアントサイドで処理し、MPAはサーバーサイドで都度完成したHTMLとJSを返します。 

しかし、HotwireはあくまでもMPAの延長です。コンポーネント指向（SPA的な考え方）で画面更新を設計してしまうと、画面の状態をサーバーサイドは把握していないので、クライアントサイドで状態に合わせた処理を行う必要があり、その分JSの記述量も増していきます。 

そうなると、Rails側（サーバーサイド）とクライアントサイドで処理を二重管理しなくてはなりません。これを解決するためにSPAがあるので、じゃあ結局SPAでいいじゃん！と挫折してしまうところに「ちょっと待った」をかけるのが大場さんです。  

画面的アプローチでは、画面の状態ごとにURLを用意することで、画面の状態をサーバーサイドが常に把握できるようにします。あとはTurboを活用してHTMLを差し替えれば、サーバーサイドで制御していても、SPAのようなきれいな見た目を作るのです。  

改めて、Web紙芝居とは画面的アプローチのことであり、「サーバーサイドに画面状態を全て伝えて全て制御させる設計指針のこと」です。  

【感想】  

RailsはRails 7から本格的に触り始めたということもありturbo-links自体はあまり触ったことがなかったのですが、Railsエンジニアたちからの悪評は伺っていました。実際私はフロントエンドはSPAが基本になっているので、あまりMPAを使うことはないのですが、MPAでSPAライクなページを作るのは大変そうだということが容易に想像できます（というか、大変だからこそのSPAですし…）。 

実のところ、このテクを使えるのは古典的なアプリケーションだけのようですが、それでも設計指針の一つとして参考にする余地は大いにあると思われます。現場のエンジニアいわく、社内でも現在RailsのViewを使っている箇所があるようで、そういったところにはぜひ取り入れてみたいとのことでした。 

Rails7から新たに導入されたHotwire、あまりキャッチアップできていなかったので、今後の開発にとても有用なセッションだったと実感しています！  

 ②Fat Modelを解消するためのCQRSアーキテクチャ  

 【セッションの主な内容】 

株式会社YOUTRUSTに勤められている寺井さんによるセッションです。  

Fat Model / Fat Controllerとは、モデルやコントローラが多くの責務やロジックを抱えることにより、コードが肥大化して、可読性やメンテナンス性が低くなってしまう問題のことを指します。今回はこの問題をCQRSと呼ばれるアーキテクチャを活用し、YOUTRUSTではどのように解決しているのかというお話です。  

CQRS（Command Query Responsibility Segregation）は、文字通り更新（Command）と参照（Query）の責務を分離するアーキテクチャのことです。YOUTRUSTでは、ここへさらにUseCaseと呼ばれるものを追加しています。UseCaseとは、コントローラの更新系アクション（create、update、destroy）から呼び出され、自身は複数のCommandを呼び出す役割を担っています。  

たとえば今回使用されたサンプルコードでは、以下のように責務が割り振られていました。  

• Command  
  責務：データの更新が行われること  

• Query
  責務：結果をHTTPレスポンスとして返すこと  

• UseCase  
  責務：Commandを呼び出すこと  

このようにCommand、Query、UseCaseの責務をそれぞれ明確化させてコードを切り出すことによって、コントローラやモデルの肥大化を防いでいるそうです。  

【感想】  

Fat Model / Fat ControllerはRailsに限らずMVCモデルを学習した人なら誰もが１度は通る問題だと思います。どこにロジックを寄せるかは色々なやり方があると思いますが、たとえばDHHの手法としては、基本的なCRUDアクションを主に使うことでコントローラを細かく切り出しており、これはRailsの良さを最大限生かしていると思います。 

しかし、どの開発環境でもそれがベストプラクティスとは限りません。わざわざコントローラを分ける必要があるほどのロジック量じゃなかったり、CRUDだけでは再現できなそうなロジックもあったりします。初心者の私としては、どれを参考にFat Model / Fat Controllerを解消すべきか、自分の中で明確な答えが出ていません。 

そんな中で、今回のようなアーキテクチャは、一つの方針として非常に参考になりました。自社でも同様のアーキテクチャが使えるかは定かではありませんが、アーキテクチャの選択肢を増やすことで、今後の開発を柔軟に進められると思っています！  

余談ですが、CRUDをベースにした設計は別セッションのSimplicity on Rails -- RDB, REST and Rubyでも紹介があったので、こちらも合わせて今後の参考にしたいと思います！  

③Multiple Databasesを用いて2つのRailsプロジェクトを統合する  

 【セッションの主な内容】 

ピクシブ株式会社のimadokiさんによるセッションです。 

ピクシブ株式会社では、自社サービスであるpixivコミックと姉妹サイトのpixivノベルの機能の統合をRailsのMultiple Databases機能を用いて進めています。  

今回の統合の経緯としては、 pixivコミック / pixivノベルはそれぞれ別サービスとして稼働してきたものの、マンガ作品はライトノベルを原作としているものが多いため、マンガ好きの人には原作を、小説好きにはコミカライズ作品も読んでほしいとの思いがあったからだそうです。  

タイトルにもある通り、プロジェクトの統合はRailsのMultiple Databasesを使用して行われますが、この機能を使う理由としては、以下の３点を挙げています。  

• pixivノベルは本来pixivコミックのクローンから作られたもので、似たような機能が多い  
• pixivノベルの専門チームがおらず、pixivコミックチームだけではメンテナンスやリファクタリングが行き届かない  
• 一つのRailsプロジェクトに統合することでメンテナンスがしやすくなる  

大本は同じサービスであったこと、そして今後の管理コストも考慮して、 Multiple Databasesによる統合が採択されたようです。  

統合の進め方としては、まずpixivノベルのDBスキーマをコミックへ移し、次にpixivノベルのモデルをコミックに移植、最後に実装を移植するという流れになります。 

全体的な注意点としては、pixivノベルを稼働させたまま機能を移していくという点です。これには素早く機能を提供すること、そしてビックバンリリースを回避する狙いがあります。 

たとえば、DBスキーマを移す工程では、 pixivノベルのものを正として管理し、 pixivコミック側ではpixivノベルのスキーマデータをコピーして作業を進めたそうです。他にも移行の際の工夫点として以下のようなものが挙げられていました。  

• DBスキーマ  
• pixivコミック側でマイグレーションを実行する際はdb:migrate:primaryを使う（ノベルに関するマイグレーションまで実行されることを防ぐため）  
• モデル  
• pixivノベル用のモデルはNovelというモジュールを作成してまとめる （同じ名前のモデルがpixivコミック上に存在し、見分けるため）  

【感想】   

私自身pixivサービスのユーザーなので、今回は統合がユーザーへの思いを踏まえたものであったことに感動しました。 

また、いくつかのサービスがRailsで動いていることは初耳でしたし、クローンで派生したサービスがあるということも驚きでした。別サービスとして稼働している二つの大きな自社サービスを統合するというプロジェクトはなかなか経験できないことですし、聞くこともあまりないので、非常に興味深い内容です。 

双方のサービスを稼働させつつ統合を進めることで、ユーザー体験を損なわせない。統合理由からその進め方まで、ユーザーファーストである姿勢も見習っていきたいです。