全角住所の入力問題
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、賑やかし役の辰巳です。よろしくお願いします。
今回のタイトルですが、何で住所は全角じゃないとダメなの?現場のオペレーターが泣かされる業務システムの妙な仕様5選というところで、
早速ではあるんですが、5選というところで、鴨志田の方で確認できているので、一つずつ読んでいきたいと思います。
一つ目が全角で入力しろと言われるというところなんですが、島田さん、これ解説いただいてもよろしいでしょうか。
これですね、最近は結構見なくなってきつつあるんですけど、みんな経験あると思うんですよね。
特に住所とかですね、番地とかの数字を半分角で入れると、それは通らないとエラーになって、もう一回全角に直して入れさせられるという、そんな仕様になったりしますよね。
ありましたね。
あるよね。あれってデータを送られてきたサーバーの方で全角に直してしまえばいいっていうのが一つあるのと、
それがですね、ユーザーとしないデータが入ってしまうという危険があるのであれば、
その入力画面の方でユーザーが入れた瞬間に全角に直してしまえばいいと思うんですけど、
そういうこともしないで、半角のまま通しておいてエラーにして直させるというのはすごい不親切ですよね。
確かに、いわゆるバリデーションというところで、入力したけれどもあれこれ違いますよというメッセージが出ることによって、
ユーザー目線で考えたときには非常にストレスフルになる。
これ話ずれちゃうかもしれないんですけど、データベースに保存するにはやっぱり全角で入ってた方が良いってことなんですか、そもそもなんですが。
それはシステムの設計者のポリシー次第なんだけど、基本的にはどっちかにしておくべきなんですよね。
全角だったりが半角だったりするといろいろと取り回しが難しいので、自分が設計するときなんかは必ずデータベースには全角で入れさせておいて、
出力するときにどうしてもラベル印刷とかで半角にしないと溢れちゃうというときには、その段階でまた半角に変換して出すみたいな。
格納するときは全角にして、出力するときは必要に応じて半角に変えるとか、そんな処理をやったりしますけども、どっちかに統一しておいた方が良いですね。
なるほど、データベース的には統一しておきたいが、それを入力で強要するのではなく、プログラム挟んで処理してしまえば揃うのにっていう話ですね。
そうそう、そうですよ。
それが考慮されていない。確かに1ユーザーとして使うときもやっぱり遭遇しますからね。半角じゃないとダメとか、全角じゃないとダメとか、確かにあったなって思いますね。
シンプルな文字もそうですけど、記号とか数字とかも結構大変ですよね。法律ちゃんとさせておかないと、システム設計段階で。
そうね。
既存のシステムから移管するっていう時になった時も、データ側でごちゃごちゃになっていることって結構多々あって、それを新システムに移管しようってなった時に、どれがどれでどう直せばいいのかっていうところから考えるので、結構それもそうですね。
これは我々目線になってしまうんですけど、現場目線でそこ、結構フワッとしている状態からカッチリ決まることによって、先ほど話したバリエーションがあることによっては面倒くさくなっちゃうかもしれないですね。
最近あれも文字コードがUTF-8ってなって、いろんな難しい漢字とかも登録できるようになったんですけど、昔はそれも非常にシビアな、使える漢字は少なかったので、ハッシュボタンとか通らなかったんですよね。
そうなんですか。
そうそう。そういうのもね、それはさすがに勝手に直したらダメだな。今は全部出て通るようになったので、その辺の問題は解決されたんですよね。
じゃあ前はしご高でエラーになってた高橋さんは普通の高橋さんに変換され、書き直されそうですか。
書き直せって言われてた。
それだったらサイト版とかがいろいろ出そうですね。めちゃめちゃあるから。
そうですね。
ありがとうございます。次行ってもよろしいでしょうか。
はい。
縦長スクロールの課題
次いただいているのが2つ目、縦長永遠スクロールというところで、これからは画面が縦に長いのかなと思うんですが、こちら竜見さんお伺いしてもよろしいでしょうか。
はい。例えばですけど、LPみたいに入力するフォームが少なかったりする場合は問題ないと思うんですけど、業務システムとかってマスターデータっていうものがあって、
例えばですけど、不動産とかで言ったら物件の情報とかで面積だとか立地だとか、建物の材質だとかいろいろあると思うんですけど、それを30項目ぐらい入れることになるんですよね。
それがタイトルと入力する内容が2行とかになってしまったりすると、延々と続くじゃないですか、下に。
確かに不動産の情報、例えば不動産だと思うんですけど、すごい長いですもんね。
長いですし、過去やったシステムでも相当な数があったんで、じゃあこれどうしようかねってなったときにやることとしては延々とスクロールをなくすために、まず文字数を極力見れるサイズで小さくする。
で、隙間をガンガン埋めていくっていうのが必要になってくるんですね。最悪タブで分けるとか、そういうやり方は全然あると思うんですけど。
確かに考えてみたら、それこそLPとか目につきやすいっていうことと、業務のしやすいっていうのは全然別のこと。
全く別ですね。
業務のしやすさを考えると、いちいちスクロールするような仕様だと、なかなかしんどくなってくるっていうところですよね。
極論もっというと、キーボードだけで完結したいんですよね、業務、システム。
なるほど。
マウスに手をかけたくない。そこの移動がめんどくさいところだと思います。
カタカタカタって入力して、タブ、カタカタカタって入力して、タブ、で、入力しろったらエンターっていう風にも、それだけでやりたいんですよね。
島田さん、そのためにはどういうところを気をつけたらいいみたいなのが他にあったりします?
そうですね。基本的にガンガンに詰めていく。一画面で済むように詰めていくんですけど。
お客さんは結構気軽に、この欄を上にやってとか、こっちを下にやってとかって言われるんですよ、最後の最後に。
それが非常に厳しいですよね、我々としては。
だから詰めるのは詰めるんだけど、あらかじめワイヤーフレームっていうんですけど、絵ですね。絵の段階でそれをよくお客さんと確認して作り込んでいかないと、後から直すの結構大変ですね、これね。
大変だね。
実装する前にイメージ図とかでちゃんと共有しておいて、この形でいきますって言った方が、おそらく現場の方にもイメージしやすいような形で共有することによって、効率的に業務システムの開発ができるのではないかっていうところですね。
あと細かいところで言うと、これは初めにおっしゃっていただかないと実装しないんだけど、タブで移動したときに飛ばしてほしいっていうところもあるんだよね。
飛ばしてほしいというのは、例えば。
タブで入力カートルを移動していくときに、重要なところだけいつも入れるところはもう決まってるんだと。
新規登録のときに入れたいところはこの6項目しかないので、30項目もあるんだけど、6項目ぐらいしか入れないので、それ以外のところはタブで押しても通過してほしいっていうときがあるんですよね。
新規登録とかですよね。
それだけ入っていれば新規登録できるからっていうときにそういうことするんだけど、それは初めに言っておいてもらわないと後から作るのはちょっと大変、ちょっとめんどくさい。
でもあれですよね。先ほどワイヤーフレームでっていうのが回答になるのかなと思うんですけど、確かに最初の段階でシステム全体的なことを考えてると、
画面こうして実際の使用感みたいなところまで考えていないってされてこないから、なかなか後々になってしまいがちな項目な気がしますね。
そうそうそう。本当にこの画面に関しては早めに言ってもらわないと、でも住所の割り方、住所1,2とかビル名とか、その辺どう分けるのかっていうのを後で増やしてほしいって言われると結構大変なんだよね。
細かい事いうと郵便番号、日本では7桁ですけど、前3桁と後ろ4桁で分けるのか、配布もつけるのかっていう。
その辺も自分もお客さんと話すときはここを後から変えられないんで、よく見てくださいって言うんだけど、結構見落とすんでね。
そこはある程度経験があるので、後々大変になるっていうことが見えているので、こちらから提案できるっていうところですかね。お客さんとしては絶対後回しになっちゃいそうですもんね。
そうそう、まあね。
文字化けとCSVの問題
ありがとうございます。次行きたいと思います。3つ目、文字化けするCSVというところで、こちらの解説してもよろしいでしょうか。
文字化け問題っていうのがありまして、昨日かな、自分も作業してたらメールで集めて、それを出力、Googleのシステムでやってて、Gmailの機能でやっててCSVに出力したら、Excelで開くと文字化けするんですよね。
それはしょうがないんですけど、Googleはユニバーサルのインターナショナルな会社なんで、文字コードはUTF-8っていうので出すんですよね。
それはまあいいっちゃいいんだけど、日本の会社の業務システムだったら、だいたいですね、それ出してどうするかっていうとExcelで加工するんですよね。Excelで開いて加工するのはもう間違いないので、CSVをUTF-8で出すと文字化けしちゃうんですよね。
ちみもうりょう(魑魅魍魎)みたいな難しい漢字がガーッと並んで出るわけですよ。
うつとかそうですね。
うつみたいなやつね。
見たこともないような複雑な漢字が出てくるんだけど、あれはもうサーバーの方で文字コード変換して、シフトジスっていう日本語が得意な文字コードで変換してから出せばいい話なんですよね。
お客さんから特別にUTF-8で出してほしいって言われない限りはですね、業務システムの開発会社の方でおもんばかって文字コードを変換してあげるっていうのがあるべき姿かなと思いますよ。お客さんにそんなことは気にしたことないと思うんで。
ありがとうございます。これそもそもの話ですけど、現状業務システムに触り始めた当初、CSVとExcelって何が違うんだろうっていうぐらいCSVでいじるってことはほぼなくてExcelっていうイメージなんですけど、これはやっぱりCSVで使ったほうが取り回し的には良かったりはするんですか?どうなんでしょう?
CSVでなんで出すかっていうと、他のアプリケーションとか他のシステムに取り込みやすいからなんですよね。
ファイルサイズも軽いんですよね、Excelで。
ファイルサイズも軽いし、フォーマットも単純なんで、メモ帳でも開いて中身確認できたりするんでね。
Excelで開くからセル上で見えるようになってるだけで、カンマ区切りで改行してるだけなんですよね。
なるほどですね。
CSVはそうですね。
だから他のアプリケーションで読み込ませたりするっていう時にはCSVのほうがいいんだけど、そうじゃないExcelでも毎回部署で今月の売上一覧みたいな感じでExcelで出力しては壁に貼ってるとかっていうそんな使い方するんだければ、初めからExcelで出せばいいんですよね。
私が設計してるシステムはだいたいExcelで出してますね。CSVはトラブルになるんで嫌なんですよ。
エンジニアはCSVで出したいからね。
そうですよね。
あとUTF-8で出したいからね。
今の話聞くとそうでしょうね。CSVのほうが取り回しよくバグも少ないっていうところだという感じっぽいですもんね。
Excelはバージョンの違いとかもあったりして。
ちょっとトラブルとかあるんでね。お客さんの中にはですね、このパソコンはまだExcel 97なんだよとかっていうとんでもないのがあったりするんで。
いつの時代の話かね。
拡張子がXがついてないんだよみたいな。
怖い話ですね。
ありがとうございますよ。次行ってもよろしいでしょうか。
4つ目。数字が左寄せだったりカンマがなかったりというところで、これは辰巳さんお伺いしてもよろしいですか。
これは多分Excel由来の話だったりすると思うんですけど。
半角数字とかを打つたりすると右寄りになると思うんですよ。
普通の文字とかテキストだと左寄りになったりする。
入力仕様の問題
もちろん設定変更することによって中央寄せだったり左寄せだったりとか。
ただ先ほど数字っていう話出てきたと思うんですけど。
その数字って大体円の通貨の話であれば3桁区切りでカンマが入るべきだったりするんですけど、
それが入ってたりなかったりみたいな問題の話かなというふうに思って。
それがバラバラっていうところだったりするという認識であってますかね、島田さん。どうでしょう。
そうですね。数字にもいろいろとあるんだけど、さっき辰巳さんが言ってた。
お金に関する数字は基本的に右寄せでないと桁がずれちゃうんで、すごい見にくいですよね。
あとそういう量を表すのもやっぱり右寄せでないとおかしいんだけど、
逆にコードとかね、真ん中寄せなのかな。センター寄せなのがいいのかな。商品コードとかね。同じ数字でもね。
指番号とかは別に右寄せである必要は特にないかもしれない。
右寄せの必要はない。基本的には文字列として意味がある数字に関しては、
左寄せか桁が固定されるんだったら真ん中。
そういうふうにシステム全体で決めた方がいいんだよね。とにかくね。
それが統一されてないとベンダーの人としてはすごいストレスになるっていうか、
なんか気持ち悪いな、汚いな、みたいな。
入力したと思ったら自動でカンマが入ってくれる仕様なのか、自分で打たないといけないのかわからないんで、
自動で入ってくれると分かっておらず、カンマを入れたらなんかカンマだぶっちゃったみたいなことを思ったりする。
ああ、なるほど。
今ってどうしてるの?皆さんのやってるシステムって、数字入れたらカーソルが離れた瞬間にカンマ入れてる?
大体それでやる。フロント側で。
そうしないと。それもよくあって、カンマが入らないで登録させようとすると、
結構経理のシステムとかで100万とか単位になってくると分からないんだよね。
だからカーソルが離れた瞬間にカンマ入れるっていうのは良いことなのにちょっとひと手間かかるよね。
そうですね。めちゃめちゃ大変じゃないですけれども、工夫というか、ちゃんとそれで統一しておくって必要があります。
確かにそこら辺の勝手が分かってないと見栄えばっかり意識したUIというか作りになりそうな部分ではありますよね。
あんまり話は膨らまなかったですが、次行ってもよろしいでしょうか。
はい、じゃあ次行きたいと思います。じゃあ5つ目、最後ですね。
入力終盤でマスターにないから登録できないということで、こちらの説明を島田さんいただいてもよろしいでしょうか。
これですね、例えばですね、商品の新規登録をしていくっていう作業があったとして、登録していってですね、何十項目、何百項目っていうデータを入れていくと。
画像とかも入れたりしてね。最後の最後にですね、これはどこのカテゴリーに、商品カテゴリーに含まれるのかということで登録しようと思うと、
そのカテゴリーがないと、自分が登録したカテゴリーがないということがあったりするわけですよ。
カテゴリーマスターにね、初めに登録しなきゃいけなかったみたいな。
いうことになって、もう全部やり直しとかっていうことになるシステムがたまにあるんですよね。
だからまあそこら辺はやっぱり経験豊富なエンジニアとか設計者だと、その場で入れたものは新規登録できると。
今まであったカテゴリーからも選べるし、新規で手打ちすると、それは新しいカテゴリーとして登録できるとか。
そういうふうにしておいたほうがいいと思うんだよね。
そこをどっちなのかを感じさせないぐらいのUIだと、多分完璧なのかと思いますね。
そうね。入力もできるプルダウンみたいなね。
初めちょっと打つと、絞り込まれてね。
ありますね。
選択することもできるし、新規で手で打つとそれも通るっていうような、そんなこともできると思うんだけど。
表現に揺らぎがちょっと出ちゃうと怖いかなとは思いますけど、設計の思想としてはとてもいいのかな。
そう、揺らぎが出るので。揺らぎわかりますかね。
パッと来ないですね、揺らぎ。
例えば「うちあわせ」って書くとすると、5文字の打ち合わせ。
なるほど、そういうことですね。
2文字の打ち合わせにもできるじゃないですか。
例えばそれですね、人によって書き方が異なってきちゃうことを表記揺れとか。
表記揺れですね。
そういう意味では、マスターに登録できる人はもう本当に管理者だけっていう思想もあるんだけど、
それにしてもなんか下書きできるとか、下書きで保存しておけるとかなんかしておかないと、
せっかく何十項目も出たやつがね、全部おじゃんになってしまったらさすがにかわいそうですね。
表記揺れはそれこそ、これ簡単なやつなんですけど、
Googleフォームで例えばアンケートとか問題とかを出したときに、
答えをあらかじめ設定しておくっていうのが多分先ほどのマスターの話だと思うんですけど、
それがちょっと違ったり、シフトが入ってしまったりとかしたら、
バツになるけど内容は合ってるじゃんみたいなことは確かにあったなっていうのを思い出しましたね。
それは回答と入力したものの揺れっていうか、完全にマッチしない場合でも正解のことがあるっていうことですね。
日本語は多いかもしれないです。
ふりがなとかね、やっぱりあるからね。
なるほど、では今までオペレーターが流される業務システムの妙な仕様5選というところで、
一つ目全角で入力しろと言われる。
二つ目縦長永遠スクロール。
三つ目文字化けするCSV。
四つ数字が左寄せだったりカンマがなかったり。
五つ目入力終盤でマスターに無いから登録できないというところを挙げていただきましたが、
これはでも確かに実際に割と複雑な業務システムっていうものの経験がないと、
確かにスルーしちゃいがちだろうなっていうところを聞いてて思ったんですが、
しばらくその認識で合ってますかね。
カテゴリーマスターの重要性
そうですね。システムって作り始める前に要件定義とかっていうのを作って、
これをやるんだったらおいくら万円ですよってことを三つ文章書いて合意を得てからスタートするんだけど、
このレベルの話って割と要件定義に書かれてなかったりするんですよね。
お客さんとしては例えば金額、金額を右寄せ当たり前でしょって思っても、
そんなことは要件定義にないので、要件定義に出てこないんですよね、このぐらいのレベルの話っていうのは。
だから経験豊富な会社に頼むとこの辺は当たり前に作ってしまうので、
要は経験豊富な開発会社にお願いしてくださいという話ですね。
ありがとうございます。ぜひここはどうなんだろうみたいなことがありましたら、気軽にプラムザにお問い合わせいただければと思います。
今回はこの辺りでよろしいでしょうか。
はい、大丈夫です。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
ありがとうございました。
