Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.0 フリガナは必須? #3872

Open
tao-s opened this issue Sep 20, 2018 · 4 comments
Open

4.0 フリガナは必須? #3872

tao-s opened this issue Sep 20, 2018 · 4 comments
Labels
improvement 機能改善
Milestone

Comments

@tao-s
Copy link
Contributor

tao-s commented Sep 20, 2018

概要(Overview)

会員登録などでフリガナが必須項目となっているが、必須項目とすべきかどうかの意見が欲しいです。
と言うのも、英語で利用した際や日本語入力できない人が使った場合に必須となるとハードルが高いためです。
ロジ連携プラグイン等で必要とか外せない理由もあると思うので、その辺りを知りたいです。

期待する内容(Expect) or 要望 (Requirement)

できればフリガナは必須入力項目から外すか、管理画面で必須かどうか選択できる様にしたい。

環境 (environment)

  • EC-CUBE: 4.0.0
@okazy okazy added this to the 4.0 milestone Oct 1, 2018
@chihiro-adachi chihiro-adachi modified the milestones: 4.0, 4.0.x Oct 10, 2018
@eternalharvest
Copy link
Contributor

eternalharvest commented Aug 10, 2020

@tao-s

#4636 にも書かせていただきましたが、フリガナのオプション化が管理画面で選択できるようになれば私も嬉しいです。

オートコンプリートも多くのブラウザで効かないと思うので、カナが必須項目になっていることは日本人であっても手間に思うと思いますし、コンバージョン率の低下を少なからず招いているのではと思います。フォームをオートコンプリートで入力して次の画面へ進もうとしたら、バリデーションでエラーになって・・・と考えるとそれで注文するのがめんどくさくなる人がいても不思議ではありません。

また、ヤマト運輸、佐川急便、西濃運輸、福山通運の送り状連携システムを構築した経験からいうと、カナはそもそも必要ではないです。外部のロジスティクスサービス等ではどうか、残念ながら私には経験がないので分かりません。

デメリット

もし海外展開を考えている企業が EC-Cube を採用することを考えるとすれば、カナや姓・名の個別フィールド項目は1つのデメリットになると思います。Symfony のマルチロケール対応のおかげで、EC-Cube を複数言語でサポートするようにすること事態はそれほど難しいわけではないかもしれませんが、カナに相当する概念は日本以外の国では皆無です。

ApplePay は最近になってカナに対応しましたが、標準化されすでにいくつかのベンダーが実装・出荷しているために仕様の変更が難しくなってしまった PaymentRequest API の方は、そもそもカナは愚か「姓」と「名」のフィールドが別に存在しません。いろいろな国や地域で、複雑な要件があり「姓」と「名」という名前のパーツも普遍的な概念ではないので、フルネームだけでシンプルな方がいいという意見もあります。

話が少し脱線してしまいましたが、送り状発行システム等が「姓」と「名」を個別の必須フィールドとして要求していますし、日本では多くのシステムがこのような仕様になっていますから、すくなくとも日本国内の要件としては「姓」と「名」のフィールドが別に存在することは正しいと思います。国際化という点においては社会全体での意識の改革が必要かもしれません。

メリット

カナがあることでもし恩恵があるとすれば、CRM や CTI 等で電話での顧客対応する際に難しい名前を読み間違えずに済むという点が挙げられます。実際問題として昨今では俗に言うキラキラネームの増加により電話や口頭で聞いてもどう変換してよいかわからず DB で検索できないという問題はあると思います。また、変換はできるけど異字体のため検索にヒットしないということもあるかもしれません。DB の COLLATION の設定によってはこの問題は発生しないかもしれませんが。

また、こだわりの強いお店が誰にも読めないような屋号を使用する場合も同様です、誰にも読めないような屋号がマーケティング上正しい戦略なのかは別として、実際にこのような問題はありえます。その場合、発音通りにソートできれば顧客名を日本語変換する方法がわからなくても日本人なら、アナログな手法でバイセクトできます。

とはいえ、キラキラネームを持った子どもたちが EC サイトの顧客としてどれだけいるのかは分かりませんし、今後も電話対応しないといけないショッピングサイトがどれだけあるのかといった実態も私には分かりません、私の想像の粋を出ない仮設です。仮にあったとしても電話番号で検索することがほとんどだと思われるので実際のサポート担当の方が、このような問題に遭遇する頻度というのは稀なのではないかと個人的には思います。

結論

私はいらないと思っています。

参考

参考までに、Google Chrome で下記サイトにアクセスして、商品の詳細ページで「BUY NOW」をクリックすると、PaymentRequest API の挙動を試せます。連絡先欄には、「姓」や「名」のフィールドが個別に存在しないこと、カナのフィールドが存在しないことがわかると思います。

https://polykart.store/

@nanasess
Copy link
Contributor

下位互換の観点から、デフォルト必須、管理画面から無効化できるようにするのがベターかなと思います。
4.0 では変更できないと思うので、4.1 以降で検討になりますかね。
(とはいえ、多くのユーザーから熱烈に強い要望を出す or どなたかが PR 出すようにしないと、優先順位が下がって採用されない結果になってしまうと思います)

3系→4系バージョンアップの際に要望出していたのですが、個人的には個人情報のフィールドは、 OpenID Connect として標準化されている Basic Standard Claim に合わせて、カナ姓名は拡張フィールドとしておくのが良いと思います
http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html#StandardClaims

@eternalharvest
Copy link
Contributor

@nanasess
確かに、管理画面から無効化できるようにするのがベターですよね。

実際に ApplePay の実装で困っているのでカナ無効化に関しては時間があるときに PR 書いてみようかと思います。
ちなみに、ターゲットブランチはどこに向ければ良いでしょうか?

@nanasess
Copy link
Contributor

@eternalharvest まだ4.1以降のブランチは作成されていないので、とり急ぎは 4.0 ブランチで大丈夫ですね。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement 機能改善
Projects
None yet
Development

No branches or pull requests

6 participants