eternalharvest
commented
4 years ago @tao-s
4636 にも書かせていただきましたが、フリガナのオプション化が管理画面で選択できるようになれば私も嬉しいです。
オートコンプリートも多くのブラウザで効かないと思うので、カナが必須項目になっていることは日本人であっても手間に思うと思いますし、コンバージョン率の低下を少なからず招いているのではと思います。フォームをオートコンプリートで入力して次の画面へ進もうとしたら、バリデーションでエラーになって・・・と考えるとそれで注文するのがめんどくさくなる人がいても不思議ではありません。
また、ヤマト運輸、佐川急便、西濃運輸、福山通運の送り状連携システムを構築した経験からいうと、カナはそもそも必要ではないです。外部のロジスティクスサービス等ではどうか、残念ながら私には経験がないので分かりません。
デメリット
もし海外展開を考えている企業が EC-Cube を採用することを考えるとすれば、カナや姓・名の個別フィールド項目は１つのデメリットになると思います。Symfony のマルチロケール対応のおかげで、EC-Cube を複数言語でサポートするようにすること事態はそれほど難しいわけではないかもしれませんが、カナに相当する概念は日本以外の国では皆無です。
ApplePay は最近になってカナに対応しましたが、標準化されすでにいくつかのベンダーが実装・出荷しているために仕様の変更が難しくなってしまった PaymentRequest API の方は、そもそもカナは愚か「姓」と「名」のフィールドが別に存在しません。いろいろな国や地域で、複雑な要件があり「姓」と「名」という名前のパーツも普遍的な概念ではないので、フルネームだけでシンプルな方がいいという意見もあります。
話が少し脱線してしまいましたが、送り状発行システム等が「姓」と「名」を個別の必須フィールドとして要求していますし、日本では多くのシステムがこのような仕様になっていますから、すくなくとも日本国内の要件としては「姓」と「名」のフィールドが別に存在することは正しいと思います。国際化という点においては社会全体での意識の改革が必要かもしれません。
メリット
カナがあることでもし恩恵があるとすれば、CRM や CTI 等で電話での顧客対応する際に難しい名前を読み間違えずに済むという点が挙げられます。実際問題として昨今では俗に言うキラキラネームの増加により電話や口頭で聞いてもどう変換してよいかわからず DB で検索できないという問題はあると思います。また、変換はできるけど異字体のため検索にヒットしないということもあるかもしれません。DB の COLLATION の設定によってはこの問題は発生しないかもしれませんが。
また、こだわりの強いお店が誰にも読めないような屋号を使用する場合も同様です、誰にも読めないような屋号がマーケティング上正しい戦略なのかは別として、実際にこのような問題はありえます。その場合、発音通りにソートできれば顧客名を日本語変換する方法がわからなくても日本人なら、アナログな手法でバイセクトできます。
とはいえ、キラキラネームを持った子どもたちが EC サイトの顧客としてどれだけいるのかは分かりませんし、今後も電話対応しないといけないショッピングサイトがどれだけあるのかといった実態も私には分かりません、私の想像の粋を出ない仮設です。仮にあったとしても電話番号で検索することがほとんどだと思われるので実際のサポート担当の方が、このような問題に遭遇する頻度というのは稀なのではないかと個人的には思います。
結論
私はいらないと思っています。
参考
参考までに、Google Chrome で下記サイトにアクセスして、商品の詳細ページで「BUY NOW」をクリックすると、PaymentRequest API の挙動を試せます。連絡先欄には、「姓」や「名」のフィールドが個別に存在しないこと、カナのフィールドが存在しないことがわかると思います。
nanasess
概要(Overview)
会員登録などでフリガナが必須項目となっているが、必須項目とすべきかどうかの意見が欲しいです。 と言うのも、英語で利用した際や日本語入力できない人が使った場合に必須となるとハードルが高いためです。 ロジ連携プラグイン等で必要とか外せない理由もあると思うので、その辺りを知りたいです。
期待する内容(Expect) or 要望 (Requirement)
できればフリガナは必須入力項目から外すか、管理画面で必須かどうか選択できる様にしたい。
環境 (environment)