Methodology note

問い合わせフォームは「送れた」だけでは十分じゃない。

MeasureSiftが日本語フォームを同条件で測る理由。

現在のステータス: この記事は測定方法を説明するMethodology Noteです。まだBenchmarkの実測結果、順位、勝者は掲載していません。

問い合わせフォームを選ぶとき、多くの記事では「料金」「デザイン」「機能数」「使いやすさ」が比較されます。

もちろん、それらも大切です。

でも、会社の問い合わせフォームとして使うなら、もっと手前に確認しておきたいことがあります。

入力された情報が、ちゃんと送られ、ちゃんと保存されるのか。

MeasureSiftでは、ここを実際に測っていきます。

「フォームを送信できた」だけでは分からない

画面上で「送信完了」と表示されても、それだけでは十分ではありません。

たとえば、日本語の会社名は正しく保存されたのか。改行を含む問い合わせ本文は途中で変わっていないか。Unicodeや記号は欠けていないか。入力途中で値を変更した場合、古い値ではなく最後に表示されていた値が保存されたか。

必須項目やメールアドレスの検証は意図した通りに動いたか。そして、同じ内容をもう一度送信した場合、フォーム側ではどう扱われるのか。

こうした挙動は、サービス紹介ページを読んでいるだけでは分かりません。だからMeasureSiftでは、実際に同じ条件を与えて観測します。

比較条件をそろえる

フォームサービスを比較するとき、サービスごとに都合のいい条件を与えてしまえば、公平な比較にはなりません。

そこでMeasureSiftでは、各サービスに同じ意味を持つフォームを用意します。

基本となる項目の意味をそろえたうえで、日本語入力、必須項目、メールアドレス検証、文字コード、長文、改行、重複送信などを同じ考え方で確認します。

サービス固有の仕様がある場合、それを無理に「不正解」と決めつけることもしません。たとえば電話番号を自動で整形するサービスがあれば、「元の文字列と違うから失格」ではなく、それが仕様として説明され、一貫して動作しているかを分けて記録します。

速ければ優秀、ではない

送信速度が速くても、入力内容が壊れていたら業務用フォームとしては困ります。

逆に、不正なメールアドレスや同意なしの送信を正しくブロックしたサービスを、「送信成功率が低い」と評価するのもおかしい。

MeasureSiftでは、単純な成功回数だけを見るのではなく、そのテストケースで期待した結果になったかを見ます。

正常な入力なら正常に届く。不正な入力なら正しく止まる。そして保存された情報が壊れていない。この三つを分けて観測することで、数字だけでは見えないフォームの挙動を残していきます。

一度測って終わりにしない

MeasureSiftが作りたいのは、その時点だけのランキングではありません。

サービスは更新されます。料金プランも変わります。入力画面も変わります。以前は問題なかった処理が変わる可能性もあります。

だから同じ条件を継続的に測り、過去の結果も消さずに残します。「今どちらが良いか」だけでなく、以前と比べて何が変わったのか。 ここまで追えるデータベースにすることが目標です。

アフィリエイト報酬でBenchmarkを変えない

MeasureSiftでは、アフィリエイトプログラムの有無や報酬額をBenchmarkの評価材料にはしません。

収益化と測定は分離します。将来、紹介リンクが含まれる記事ではそのことを明示しますが、報酬が高いサービスだから測定結果を良くする、ということはしません。

比較の元になるのは、実際に観測したデータです。

まだ「一番おすすめ」は決めない

現時点では、まだこのBenchmarkの実測結果を公開していません。

したがって、この記事で「このフォームサービスが一番」と結論づけることもしません。

MeasureSiftでは、まず条件を固定し、テストし、結果を保存し、その結果から言える範囲だけを記事にします。

測っていないことは、測ったことにしない。

少ないデータから、大きな結論を作らない。

そして結果が変わったら、その変化も残す。そんな比較サイトを作っていきます。

今後、実際のBenchmarkデータが揃い次第、各サービスの測定結果、失敗したケース、データ保存時の挙動、過去結果からの変化まで順次公開します。