📝

問い合わせフォームSaaSの HyperForm を使ってみた

2022/09/07に公開

form

hyperform

tech

HyperFormとの出会い

2022年5月、フォームを含むプロダクト(詳しくは後述)を作るためのアーキテクチャーに悩んでいました。
ある程度の構成はイメージできていたものの、フォーム部分をどう作ろうか、そもそも「ちゃんと」作るのめんどくさいなぁなどと逡巡していた時、ふとTwitterを見ると誰かのRTで以下の投稿が流れてきました。

注目したポイント

早速製品サイトを見てみたところ「これは使えそうだ」と思い、アカウントを作成してプロダクトに組み込んでみました。
特に注目したポイントは以下の３点です。

UX
一般的に簡便さを優先してフォームを作る場合はGoogle Formなどが使われますが、自サイトからGoogleのサイトに遷移する必要があったり、見た目のカスタマイズの幅があまりなかったり、ブランディングやUXの面で良いとは言えません。
しかしHyperFormはサイトのFormタグと連携させる仕組みなのでこの点を心配する必要はありませんでした。また、リダイレクトURLという項目によってフォームをsubmitした後は一度HyperFormsのサイトに遷移しますが、リダイレクトによって自動で自サイトに戻ってくることも可能です。
スパム対策や自動返信メールが付随機能として付いている
「フォームを作る」と聞くと「HTMLを書いてPost先のバックエンドを作るだけ」と思う人も少なからずいらっしゃるようですが、スパム対策や自動返信メールなど目に見えない機能や付帯機能を考えるとそのハードルはグッと上がります。
詳しくは開発者の方の投稿に記載されていますが、HyperFormはそれらの機能も一通り実装されています。
アカウントがなくてもファイルが送れる
これが最終的な決め手になったと思います。
HyperFormに出会うまではGoogle Formの使用を検討していました。しかしGoogle Formでファイルを送信する場合はフォームを記入する人もGoogleアカウントが必要という制限がありました。
今回のプロダクトは不特定多数がフォームを送信する際に画像も送信する要件だったため、ここをどう乗り越えようか悩んでいたところにHyperFormと出会い、採用することになりました。

実際のプロダクトへの導入

導入対象のプロダクトは問い合わせフォームというよりも、投稿フォームに近いイメージです。今回の記事に関係する技術的な要点だけピックアップすると以下のような流れになります。

ユーザーがフォームから投稿
Webhookで起動したAzure Functionsで投稿内容をDBにインサート、ファイルはBlobにアップロード(並行してGoogle Spreadsheetに生データをバックアップ)
コンテンツ管理者が投稿内容を承認すると一般ユーザー側のフロントエンドにも表示される

今回は新規サービスということもあり、最初からできる限りPaaS,SaaSを活用したクラウドネイティブなアーキテクチャを設計しました。そのようなマインドがあったため「イベントドリブン処理をしたい場合はAzure Functionsを使う」と同じような考え方で「フォームを実装するならHyperFormを使う」とすんなりと導入・実装できたと思っています。

使ってみてどうだったか

約３ヶ月の運用期間で1,314件のフォーム提出がありましたが１件も取りこぼしやエラーになることなく処理ができました。同じ機能を自分で実装していたら絶対取りこぼしやエラーを吐いてるだろうと、考えただけでガクブルです。

よかったポイント

記事冒頭の「注目したポイント」で挙げたような内容の恩恵が受けることができたのはもちろん、振り返ってみると追加で２点が評価ポイントでした。

手厚いサポート
スタートアップならではの素早いレスポンスが非常に印象に残っています。
バグに当たったこともありましたが、数日のうちに修正をおこなっていただいたり、「こんなことできますか？」という質問にも「現状ではできないのですぐ作ります！」といった具合に非常に柔軟かつスピーディに対応していただきました。
工数の削減
これがSaaSを使う大きな理由の1つだと思いますが、想像以上でした。
サービスを使い始めるためのライブラリのインストールや処理の追加は不要でformタグのaction属性にHyperFormのURLにするだけでOK。運用に乗ったら本当に何もする必要がありませんでした。

今後の改善に期待したいポイント

Webhook
他サービス連携機能として「Webhook」という項目があります。しかしここに連携先エンドポイントを入力すると指定したエンドポイントにトリガーされるものの、送られてくるリクエストのBodyがSlackに投稿するためのスキーマのJSONなので、ほとんどSlack通知専用という位置付けになっています。
私の場合はAzure FunctionsでSlack用のスキーマを解析してフォームから送信された項目と値を取り出す...という処理を実装してWebhook連携を実現しましたが、本来は必要ない処理を書くことになったという点では改善を希望するポイントです。
Slack連携は別で設けて、Webhookとして汎用的なKey-ValueのJSONで連携するような仕組みがあれば良いと思いました。

というのは過去の話でこの記事を書いた1週間後くらいにちゃんとしたWebhook機能がリリースされました！
(2022.09.21追記)

最後に

結構なベタ褒め記事になってしまいましたが、もちろんHyperFormから利益供与などは受けてません！（むしろお金払って使ってます）
サイト組み込み型の問い合わせSaaSの代表的なポジションを取れるよう今後の成長に期待しています。
グッドタイミングで素晴らしいプロダクトを出していただいた開発者の方々に感謝です。

GitHubで編集を提案