ローカルワークスでは「リフォマ」というプロダクト開発のため、エンジニアを募集しています。以前の記事ではリフォマの開発体制などをご紹介しましたが、今回は「Hotwire導入」というテーマに絞って、エンジニアに語っていただきました。リフォマでどのように開発が行われているか、ご参考になれば幸いです。

※リフォマというプロダクト自体の解説については、以前に書いた記事をご覧ください。

リフォマでは現在Hotwire導入のプロジェクトが動いています。本記事では簡単にではありますが、導入プロジェクトについてご紹介させていただければと思います。

Hotwireの概要

Rails開発者であれば、Hotwireという言葉を聞いたことがある人は多いのではないでしょうか。その反面、それが何であるかということを知ってる人は意外に多くないかもしれません。優れた紹介記事が豊富にあるので詳細はそちらに譲りますが、Railsというバックエンドなフレームワークに重きを置いて、モダンなWebアプリケーションを構築する為の一連のライブラリ群です。（ちなみに、HotwireはRailsの文脈で語られる事が多いですが、Laravel、Djangoのような環境でも利用できます）

ReactやVueに代表されるフロントの代表的なフレームワーク = モダンなWebアプリケーション開発という認識に対する一種のアンチテーゼ的な所を出発点としたものと言えるかも知れません。

と言っても分かりにくいと思いますので、サンプルアプリケーションを提示したいと思います。

https://www.hotrails.dev/quotes

Railsを含む既存のバックエンドのフレームワークのみでは、実装に手間が必要そうな表現を、Hotwireを導入することで、簡単に実現することができます。

Hotwire導入はリフォマの最適解

ユーザビリティ向上を目指す

リフォマは、PFM(プロダクトマーケットフィット)過程ではありますが、アプリケーションを利用するステークホルダーは、ローカルワークスの管理者、リフォームの施主、施工店、及び保険代理店担当者と多様です。利用者のペルソナに応じたユーザビリティや要求速度といった、システム要件以外の機能面を改善し、操作性に優れたアプリケーションを提供することで各利用者の満足度を高めていきたいと考えています。

満足度について具体的な話をすると、施工店には、案件紹介から商談、施工、完工と一連のフローをリフォマを使って管理報告をしていただいています。しかしながら、施工店にとっては、施主にリフォームを届けるというのが彼らの価値提供の部分で、リフォマでの作業は必要ではあるが、得意ではないと感じている部分もあるかもしれません。施工店の職人がより価値の部分に注力できるようになるという観点及び、リフォマを継続して利用してもらうという理由からもユーザビリティの改善による満足度向上も重要になってきています。

Hotwire導入の理由

Hotwireの概要で述べたように、表現力や高速なレスポンスというとSPAを選択する事が一般的になってきている印象もありますが、人員的なリソースから、フロント、バックという2つのアプリケーションを作成、保守する事は難しいかもしれません。実際、ローカルワークスのエンジニアは、モダンなフロントエンド開発も経験している、フルスタックなRails開発者集団ではありますが、バックエンド開発により強い興味を持つ人材が多い気がしています。フロント開発過多になると、エンジニアとしての志向にミスマッチが生じてしまう可能性もあるかもしれません。

また、リフォマのコアコンピタンスは、施主と施工店のマッチングにあり、それらの機能はRailsのテンプレートエンジンを利用した、素早い開発とリリースが重要になってきます。アプリケーションの性格上、フロントとバックエンドを明確に区別してしまい、MVCとしてのRailsフレームワークを利用しない事は、メリットよりも開発コストの方が増えてしまう可能性があるのも気になりました。

更に、外部開発パートナーとしてRubyの開発に深い知見があり、Hotwireを推していく宣言をしている株式会社万葉のエンジニアがリフォマ開発に参画しており、Hotwire導入の中心としてプロジェクトを引っ張っていってくれる事も導入検討にあたりプラスに作用しました。

まさにHotwire導入はリフォマにおける最適解だったわけです。

コミュニケーションツールとしてGatherというバーチャルオフィスサービスを導入してみました。ミーティングやペアプロをGatherで開催しています。

Hotwire導入のプロセス

Rails7へのアップグレード

Hotwire導入にRails7であることは必須要件ではありませんが、リフォマでは比較的早い2022年の6月頃の時期には、Hotwire導入以前に、Rails7へのアップグレードを完了しました。Rails7ではフロント回りのエコシステムが刷新され、リフォマでもそれに追随したこともあり、簡単な作業ではありませんでしたが、Hotwire導入中にRails7へのアップグレードプロジェクトが走るというあまり理想的ではないマルチタスクを避けられて、良かったと思います。

導入は小さくスタート

リフォマの開発スタイルはアジャイルを取り入れており、Hotwireの導入もアジャイルの開発スタイルに則り進めました。まずは極々小さな範囲でなおかつ失敗しても影響度が低いと考えられる社内向けの管理画面に適用する事を決定しました。知見が溜まった段階で、変更の影響度が高い場所に広く適用していくという戦略です。

具体例として、Turbo drive (旧 Turbo links) に関しては、Hotwireを導入したものの、サイト全体でturboによるリクエストを一律無効としました。そして、Turboによるリクエストを有効化したい場所はホワイトリスト方式で有効化しています。またTurbo frame, Turbo streamに関しては手始めに管理者が頻繁に入力する金額入力フォーム群に適用することにしました。

現在Hotwire導入プロジェクトは道半ばであり、前述の言葉で表現すると知見を溜めている段階です。ここで簡単ではありますが、苦労した箇所や現在の課題を共有致します。

• フレームワーク側の不具合

Hotwireは比較的新しいライブラリの為、不具合を自分で踏むことがあるかもしれません。

これは筆者が悪いのですが、古いバージョンを利用していたために、500エラーに対して正しい画面が描写されないということがありましたが、最新のバージョンでは解消されていました。Railsのような枯れたフレームワークであれば、ネット上に既に情報が溢れており、躓きやすい箇所で、同じ轍を踏むという事は比較的避けられます。しかしながらHotwireに関しては、ネット情報はそもそも少なく充分ではありません。そのためライブラリのコードを確認したり、公式レポジトリのissue履歴を見に行ったりすることも時には必要になります。

ポジティブに考えれば、Hotwireに対してより深い知識を持てるチャンスだということも言えます。自分でライブラリの構造を紐解いて実装にチャレンジしたい人には黎明期の現在がベストではないでしょうか。

• Turbo Driveの一律有効化は難しい

これは旧Turbolinks時代から言えることですが、Turbo Driveを一律有効にするのは実装やテストのコストの観点から難しく、一旦は保留にしてホワイトリスト方式にしています。しかしながら、ホワイト方式で増やしていくことはいずれ破綻することは目に見えているため、どこかの段階で全適用を前提とした対策を実施する必要があります。

成果と今後の取り組み

Hotwireを導入した社内向けの管理画面をカスタマーサクセス部に利用してもらった結果、ポジティブな反応が返ってきました。データ入力フォームのTurbo frame化は、より多くの箇所に適用して欲しいという依頼がありました。入力の速度向上とタイプミスが減り、生産性の向上が見込めるとのことです。

重要なデータを日々入力する必要がある業務の場合、Hotwireを利用しフレーム単位で画面を変更することは、非常に有効でした。Hotwire導入の目的でもあった、システム要件以外の機能面を改善し、操作性に優れたアプリケーションを提供することで各利用者の満足度を高める事を実現出来ている気がします。

ローカルワークス社員の近藤武彦さん。Hotwireを使った機能をカスタマーサクセス部に展開されています。

今後、Hotwireの導入に対する知見が高まった所で、より多くのステークホルダーが利用する機能においても開発を行っていきたいと考えています。

ローカルワークスでは、RubyやHotwireで開発をされている方を募集しています。今すぐの転職を考えていなくても構いませんので、ご興味をお持ちの方は求人からカジュアル面談にご応募ください！