非エンジニアがSaaSを導入する前に、必ず読んでほしい「データ」のお話

Ateam Group Manager ＆ Specialist Advent Calendar 2020の17日目は株式会社エイチームの@gonjyu121が担当します。

はじめに

最近、クラウドが一般化してSaaSが流行ってきているので、エンジニアが関わることなく、システムが導入、運用までされる事も増えていますよね。

実際、自由度が高くてカスタマイズができる使い勝手のよいSaaSも増えているので、昔だったらガッツリ開発工数をかけてフルスクラッチするようなシステムも、最近は入力項目を管理画面上からポチポチ自在に増やして、柔軟に帳票を作成できたりもします。

例えば、これは、とあるHR系SaaSの帳票作成画面です。

なるほど、WEBで自由にカスタマイズ出来ますね。これは初心者にもありがたいです。
そして、いつも人が足りない状態のエンジニアにとって、現場だけでシステム導入ができるようになるのは嬉しいことでもあります。

ただ、

「忙しいエンジニアに頼らず自分たちでシステム導入できる！」

という非エンジニアの現場サイドと、

「やりたいことはこれで実現できますよ！」

と売り込みに来るSaaSの営業だけで導入や運用が進むと、結果的になかなかひどい状態になっている事が多いのです。

特に何がひどい状態かというと、**「データ」**です。
蓋をあければデータの腐臭が漂っている・・・エンジニアからするとホラー映画さながら「キャー！」と叫びたくなるやつです。

今日はこの**「データ」について「非エンジニアにも分かりやすく説明してみる」**ということを試みたいと思います。

架空のケースで説明

では早速、具体的な例を使って説明をしていきます。
説明を分かりやすくするために、まずは架空の人物と、架空のSaaSを登場させましょう。もちろんフィクションです。登場する人物・団体・名称等は架空であり、実在のものとは関係ありません。

分かりやすくするために事例や人物を極端にしたら「こんなヘボいSaaS無い」「セキュリティは？」「さすがにこんな人いない」等など、いろいろツッコミどころが多くなりました。
が「言いたい事はこういうことかな？」と優しくお付き合い頂けると幸いです

とある管理セクションのスタッフHRさんは、従業員の安否確認の仕組みを整えるよう上司から依頼されたものの、困っていました。
調べたところ、システム導入が一般的のようですが、HRさんには不得意なIT分野です。

しかし、得意そうな人に相談しようにも、社内のエンジニアは売上利益を作る事業部門に引っ張りだこ。
情シス部門も、いわゆる一人情シスで、社内ネットワーク保守で手一杯です。

多忙なエンジニアに相談するのも気が引けますし、相談したとしても「優先度的にちょっと・・・」と後回しなってしまう事も多いので、なんとか自分達でやろうと思い、とりあえず安そうなSaaSの会社に連絡しました。
すると、連絡したSaaSの営業担当から

「御社もエンジニアは忙しいですよね。このサービスならなんと、非エンジニアの人でも複雑なシステムを作れちゃうんです。安否確認ももちろん含まれてます。」

と、まさに不安な部分をピンポイントで察してくれました。

さて、良さそうだということであれば、早速資料作成です。

• 導入と運用は現場でできる（エンジニアの工数はかからない）
• 導入後のコスト削減効果（運用工数など）
• しかも他の課題解決もできる（安否確認だけじゃない）
• 他社製品との比較表（とっても安い！）

などの資料をSaaSの営業担当にも手伝ってもらいながら、経営陣にプレゼンしたところ、反対の意見は出ず、導入の承認が降り、トントン拍子に進みました。
そして、安否確認はもちろん、他にもいろいろな事に使える、カスタマイズ豊富なSaaSが導入されました。

いろいろできるシステムですが、まずは主目的である安否確認システムを用意していきましょう。
緊急時の連絡先名簿を作るために、社員に入力してもらう画面を作りました。

【イメージ図】

以下、説明用に短縮すると、つまりはこういうことです。

氏名	住所	電話番号	メールアドレス	性別
記述式テキスト	記述式テキスト	記述式テキスト	記述式テキスト	記述式テキスト

本当なら、労務管理系のシステムにほぼあるデータなので、連動させられるのですが、今回のHRさん、同じ管理セクションでも、労務と部署が違っており、他システムとの連携を想像できませんでした。
元々システムも詳しくない上に、日々忙しい自部署の課題解決で頭がいっぱいなので、思いつかなくても仕方ありません。

HRさんにとっては不得意なシステムですが、SaaSの営業担当に聞きながら、なんとかこの入力画面を作って、URLを社員に渡して

「ここに入力してくださいね」

と案内しました。
本当にエンジニアに相談せずに用意できましたね。ちょっと感動です！
そして1人目が登録してくれました。こんな感じで登録されました。

氏名	住所	電話番号	メールアドレス	性別
山田 太郎	愛知県名古屋市◯区◯町1-22メゾン◯107号	09009876543	[e-mail]	男性

よしよし、いい感じです。
このまま運用に載せます。すると二人目が

何が問題なのか、ここでピンとくるのはまだマシですが、HRさん、何も思いませんでした。
同じ人っぽいですが、これだとシステムは「重複」であることを判断できません。
放置すると当然こうなります。

この山田さん、たぶんわざとですね。悪意を感じます（笑）
しかし、これもシステムからは同じ人と判定できません。

この辺で、データリテラシーがある方からは

「もうわかったから、この腐臭のするデータに蓋をして俺を遠ざけてくれ」

と言われる事うけあいだと思います。
HRさんにも、そろそろ気付いて欲しいんですが、残念ながらこのまま見過ごされてしまいました。

わかる人から見ると、思わず吐き気のするデータです。

• 山田さん、調子に乗って4行も登録しちゃってますね・・・
• そして実質2人目と思われる5行目のササキさんは、住所に郵便番号を入れてしまい、そこから1個ずつ入力がずれてしまっています。

さて、そろそろ「何が言いたいんだよ怒」という人がいるかもしれないので、ここらで「何に気付いてほしいか」「どうアクションしてほしいか」を一つずつ解説してみましょう。
少々長くなりますがお付き合い下さい。

あとで扱いやすいデータにする

ではまず、一番わかり易い「性別」から。
こういったデータが集まった状態で、あとで上司から

「今、うち、男性って何人いるんだっけ」

と言われたとしましょう。データを見てみます。

氏名	…	性別
山田 太郎	…	男性
山田太郎	…	男
山田　太郎	…	man
ﾔﾏﾀﾞﾀﾛｳ	…	性別
ササキジロウ	…	[e-mail]
鈴木花子（スズキハナコ）	…	女

ここでは一旦、山田さんは本当に別々の人だったと仮定します（同姓同名の社員が何人かいるかもしれない！）
その上で性別を見ていくと、4人目は何を思ったか間違って項目名を入れてしまってるし、5人目は一個ずれててメールアドレスになってしまっているので不明です。6人目は女性です。
ということで、男性のデータは「男性」「男」「man」つまり、このデータから欲しい回答は「3人」ということになります。

しかしこのデータを「男性」で検索しても1件しか引っかからないですよね。グラフにするとこうなります。

グラフにする必要無いでしょ！というツッコミは一旦置いといて・・・
HRさん「男性」で検索したところ、1件しか出なかったので、1件で報告しました。

上司から「違うんじゃない？」と言われたので、
「え？おかしいな、じゃあ「男」で検索してみよう」　すると、「男性」と「男」の2件が引っかかりました。

この例のような6件程度であれば、データを目視で見ればわかるので、上司も気付きます。しかし、社員が1000人、1万人となってくると、上司もいちいちデータを見る時間は無いので、担当者の間違った報告を信じる事になりがちです。

かなり極端な事例ですが、ここで言いたい問題は「使えないデータ」になってしまっている、ということです。

言いかえると、大事なのは**「どんなデータにしておけば、あとで扱いやすいか」**ということなのです。
扱いやすい状態とは、期待するデータ「のみ」が入っている状態です。
後々、集計や分析作業をする時に、どんなデータになっておけば良いかを想像してみると分かりやすいのかもしれません。

今回の事例である「性別」についての「期待するデータ」とは何か、を考えると「男性」と「女性」の2種類です。
ということは、この2種類以外は入力させないようにしなければならないんです。

アナログな対策に走ってはいけない

HRさん、中のデータがおかしい事がわかったので、手動で整理したり、分からないところは本人にヒアリングして、やっときちんとしたものを提出できました。しかし、その作業をする中で湧き上がってきたのは、

システムを入れたのに、なんでこんな面倒なことになるのー（泣）ただでさえ通常業務で忙しいのに！

という思いです。
そこで手を打ちました。

入力する社員に「ここは『男性』か『女性』を入れて下さい」と、口頭でも伝えて、メールでも伝えよう。
そして新入社員の上司にもお願いしておこう。

ところが、新しく入社する社員への伝達が漏れていたり、そもそも聞いてなかったり、意識が薄かったりで徹底されませんでした。最近のビジネス現場では、ビジネスチャットのみで完結するような（メールを使わない）社員も増えていますが、そんなことは知らないHRさん、

「言ったのになんで出来ないんだ、メールちゃんとチェックしてよ（イライラ）」

ただ、HRさん、そこは大人として我慢して、どうしたらいいか考えました。

「そうだ、入力欄に注意書きをすれば、入力する時に絶対見てもらえるじゃないかな！」

自信満々のHRさん。
ただ、残念ながら、注意文を見落としたり、気にせず入力したり、は発生し、表記は結果的に統一されません。

「こんなに丁寧にしてあげてるのに！言ってもできないし、注意文もよく見ないし、社会人としてどうなんだ！（怒）」

とイライラを通り越して怒りに変わってしまいました。

人の「意識」に頼る方法は不安定

こういった対応をシステム業界では**「運用でカバー」**と言ったりします。
その名の通り、システム的にカバーするのではなく、人の運用、マンパワーでカバーする方法です。
しかし「人」は誰しも、忘れたり注意散漫になったり別の事で頭がいっぱいだったり、その時々で不安定なものです。

また、組織が大きくなり人や事業が増えたりすると、自然にルールや働き方も複雑になるので、以前は少人数で出来ていた事も状況が変化して難しくなったりします。逆にHRさんからも事業側のことがどんどん分からなくなってきています。
元々不安定な「人」の意識や注意が、組織が大きくなるとますます不安定になっていきます。
「やらない」というより**「やれない」**状態になってくるんですね。

ただ、この変化は分かりにくいので、どちらかというとお互い**「やってくれない」「分かってくれない」**になっていきます。
今回も、何も解決しないまま、お互いの関係性だけ悪化して終わってしまいました💦

こうした不幸を生まないためにも・・・

対策を打つ場合は、「人」や「意識」「注意」等の不安定なものに頼る方法ではなく、いつ誰がどんな状態でも、安定して結果が出る方法を考えねばなりません。それにはシステムを単に入れるだけではなく活用する力が必要です。

システムを用意する側が**「データを整える仕事をしなくてはいけない」**という発想になりましょう。

マスタ選択と入力必須

さぁ、具体的に一つ一つ解いていきましょう！

この「性別」のような場合は「別のマスタを作り、そのマスタからドロップダウンリスト（プルダウン）で呼び出せるようにできないか」を考えてみます。
入力項目のカスタマイズができるSaaSでは、別でマスタを作れる画面も用意されていることが多く、今回もこの機能が搭載されていたので利用する事にしましょう。

まず、性別、というマスタを作り、データとしては2つ登録します。

性別マスタ
男性
女性

そして、入力フォームを性別マスタからのドロップダウンリストにします。

氏名	住所	電話番号	メールアドレス	性別
記述式テキスト	記述式テキスト	記述式テキスト	記述式テキスト	ドロップダウンリスト(性別マスタ)

こうすることで、男性と女性しか選べなくなります。
更にその入力欄は「必須」とすれば完璧です。

これで、入力者による表記ブレがなくなり、先程の「男性」は何人いるのか、という依頼に対しても、3人と正確な値を出せます。
さっそく実装してみたところ、4行目の人も「性別」が選べなくなり、5行目の人も「メールアドレス」を入れられないので、本当の値が入力され、5人という情報が取得できました。

氏名	…	旧性別	新性別
山田 太郎	…	男性	男性
山田太郎	…	男	男性
山田　太郎	…	man	男性
ﾔﾏﾀﾞﾀﾛｳ	…	性別	男性
ササキジロウ	…	[e-mail]	男性
鈴木花子（スズキハナコ）	…	女	女性

前回のアナログ対応では啓蒙し続ける手間も発生し、且つどれだけやっても保証されませんでした。更に、増えれば増えるほど、データを手動で整理したりする作業も発生するので、HRさんは、その都度イライラしたり怒ったりしてしまいました。
しかし、このようにちょっと工夫するだけで「勝手に」キレイなデータが溜まっていく事になります。

途中でマスタが変わると過去のデータは？

ちなみに、マスタを作る場合は「途中でマスタを変えた場合、過去のデータがどうなるのか」を調べておいた方がよいです。
どういうことか説明するために、もう少し具体的な内部のデータを想像してみましょう。
実は、マスタ作成画面には内部的にIDが付与されていることが多いんです。こんな感じですね。

| 性別ID | 性別マスタ |
|-----------|------------|------------|------------|
| 1 | 男性 |
| 2 | 女性 |

そして、この場合、実際にデータとして格納されている値は

氏名	…	性別ID
山田 太郎	…	1
山田太郎	…	1
山田　太郎	…	1

となっていることが殆どです。
もちろん、画面に1と出てきても、何のことか分からないので、表示する直前に

ここに入ってる1番は性別マスタの1番だから、表示上は「男性」と表示する

みたいな具合に変換されて表示されるので、ぱっと見、気付くことはないです。
なんでこんな面倒なことをやっているかというと、マスタを変更したい時があるからです。
例えば、運用している途中で「性別は一文字の方がわかりやすい」となり、マスタ名を編集したとします。

| 性別ID | 旧性別マスタ|➡ |新性別マスタ|
|-----------|------------|------------|------------|------------|
| 1 | 男性|➡ | 男 |
| 2 | 女性|➡ | 女 |

もしIDを使わなかった場合、今までの入力は「男性」のままなのに、新しい入力は「男」になり、データ的には合計で4種類になってしまいます。

氏名	性別
山田 太郎	男性
山田 花子	女性
新しい男性	男
新しい女性	女

これでは、せっかくマスタ化したのに「男性は何人いるのか」という依頼に、「1人」という間違った結果を返す事になりますよね。
しかし、IDで登録されていれば、データとして格納されている「ID」には変更が無いので、2種類のままとなり、

氏名	性別
山田 太郎	1
山田 花子	2
新しい男性	1
新しい女性	2

その上で、表示する時は変換後の文字だけが変わるので、過去のものも含めて一度に変わってくれます。

氏名	性別
山田 太郎	男
山田 花子	女
新しい男性	男
新しい女性	女

これで安心して分析できますね。

逆に、過去のものはそのままにして、未来のものだけ変えたい、という要望が発生するような種類のデータもあります。
以下は、定期的な予定を登録していたが、変更が入ったので、今までの状態はそのままにしておきつつ、今後の予定を変更したい、という場面で出てくるダイアログですね。

こういった、過去分を維持しておきたいケースもあります。その場合は、値そのものが変わる方がいいでしょう。

つまり何が言いたいかというと、マスタ作成機能がついていても、中身がどのように実装されているか、その仕様が格納するデータの特色に合っているかが大事だ、ということです。注意しながら作りましょう。

多くのSaaSの場合、わかりにくい「ID」は隠蔽されている事が多いし、マニュアルにはそこまで詳しく書かれてない事もあります。
しかし、このように運用の途中で値を変えたいということはよくあるので、途中で変える可能性も予測して、もしそれが発生した時に過去のデータがどのような挙動になるのか、事前に検証しておくのが一番確実でしょう。

バリデーションチェック

次にメールアドレスを見てみましょう。

「強い地震があった。多分大丈夫だが『不安な社員は自宅待機でも良い』と通知をしたいので、この文面を社員のメールアドレスに一斉送信してくれないか？」

ついに安否確認システムの本領発揮です。
早速、社員に一斉メールを出しましたが、送れたのは1件です。

氏名	…	メールアドレス	送信可否
山田 太郎	…	[e-mail]	◯
山田太郎	…	$\normalsize{[e-mail]}$	☓
山田　太郎	…	＜[e-mail]＞	☓
ﾔﾏﾀﾞﾀﾛｳ	…		☓
ササキジロウ	…	090098876543	☓
鈴木花子（スズキハナコ）	…	持ってません	☓

• 2行目は全角文字（2バイト文字とも言う）のため送れない。
• 3行目は、＜＞が半角であればメアドの形式的には合っている。惜しい。
• 4行目は無記入なので送れない。この場合、メール以外の連絡方法が必要。
• 5行目は回答が一つずれているので電話番号が入っている。送れない。
• 6行目は日本語なので送れない。

営業担当を当てにしすぎない

ところがHRさん、全角と半角の違いはもちろん、送れなかった原因はよく分かりません。

「なんで送られないの？このシステムおかしいんじゃない？」

とSaaSの営業担当に連絡しました。
すると営業担当から、

「申し訳ございません。運用後の不明点はサービスセンターにお問い合わせ下さい。」

と言われ、サービスセンターの番号を案内されました。

「あれ、営業担当が気に入ってたのに、なんか冷たい対応・・・」

SaaS側の事情として、もちろん解約はされたくありませんが、導入時のハードルに比べると解約のリスクの方が低いので、優秀な営業担当は次のお客さんの獲得に工数を割いていました。獲得のノルマもありますから、一旦導入してくれたお客さんにはあまり工数をかけられません。「担当」は外れませんが、対応は全てサービスセンターにまわされてしまいました。

苦手な分野だと不安が大きい分、導入時はつい**「担当者の良し悪し」で選んでしまいがちですが、結局使うのはサービスです。担当者に期待しても後でがっかりするかもしれない事は事前に念頭に置いておき、人ではなく「製品の良し悪し」**で選びましょう。

さてHRさん、対応に不満はありましたが、いろいろ言っても仕方ありません。サービスセンターに電話しました。

「少々お待ち下さい・・・こちらの環境でテストしたところ、存在するメールアドレスであれば問題無く送信できますね。正しいメールアドレスですか？」

電話越しに読み上げても「全角／半角」まで伝わらず、

「うーん、やはり問題ないですね。すみません、もう一回やってもらえますか？」

何度もやらされていイライラしているうちに、たまたま通りかかったエンジニアの人が「全角／半角」などの問題に気付き、教えてあげて解決しました。
貴重な時間を取られてしまったHRさん、SaaS側の対応と、半角だか何角だかなんだか分からないこのイライラが、今度は入力者の方に向いてしまいました。

「なんでちゃんとしたメールアドレスを入力しないんだ！もういい、きちんと入力しないのが悪い」

わざわざ半角に直して送るのも大変なので、今回はそのまま送らず、出社してから伝える形を取りました。
さて、これはどうするべきだったでしょうか。

①メアド専用入力ボックス

メールアドレスは、長い上に記号も入ります。誰だって誤入力や、半角／全角の間違いは発生するという前提に立った方がいいでしょう。HRさんも一度くらいは間違えた事があったかもしれませんね。

これを解決できる方法を3パターンほど挙げておきましょう。

SaaSは、メールアドレス用の入力欄を用意しているケースが多いです。
「半角しか許さない」「@が間に入ってる」「スペースは許さない」などのメールアドレス特有の制限が入っており、形式に当てはまらないとエラーを出してくれます。
メアドに限らず、こうした入力チェックのことを「バリデーションチェック」と呼びます。

②javascriptカスタマイズ

専用の入力方法が無くても「javascriptを登録できます」みたいにカスタマイズができるSaaSもあります。
その場合は

「メールアドレス　バリデーション　js」

などで検索するといろいろ見つかるので参考にしてみましょう。正規表現というもので非常に細かい制御が可能です。
ただし、理解は少々難しいので、もしこれで実現するとしても、エンジニアを召喚してください。

③確認メール

絶対に間違ってはいけないケースでは、きちんと確認メールを送ってくれる機能があるSaaSを選ぶ方がよいです。

一度は見たことがあるのではないでしょうか。

適用する

さて、今回のSaaSは安否確認システムだけあって、実はメアド専用入力フォーム＆確認メールまで出来る部品がありました。

項目	入力形式	入力制限など	必須
氏名	記述式テキスト	なし
住所	記述式テキスト	なし
電話番号	記述式テキスト	なし
メールアドレス	記述式テキスト	メアド専用(確認付き)	必須
性別	ドロップダウンリスト	性別マスタ	必須

記号はメールアドレスに使用できるもののみとなっていたので、＜＞は半角も除外してくれました。
鈴木花子さんがメアドを持ってないですが、安否確認の性質上「必須」にさせてもらいましょう。どうしても無い場合は問合せしてもらって、相談させてもらう事にします。

すると中のデータはこうなりました。

氏名	…	旧メールアドレス	新メールアドレス
山田 太郎	…	[e-mail]	[e-mail]
山田太郎	…	$\normalsize {[e-mail]}$	[e-mail]
山田　太郎	…	＜[e-mail]＞	[e-mail]
ﾔﾏﾀﾞﾀﾛｳ	…		[e-mail]
ササキジロウ	…	090098876543	[e-mail]
鈴木花子（スズキハナコ）	…	持ってません	[e-mail]

鈴木さん、実は持ってたんですね。携帯のアドレスを入れてくれました。必須にして良かった・・・
よし、これでメールと性別がキレイになりましたね。

氏名	…	メールアドレス	性別
山田 太郎	…	[e-mail]	男性
山田太郎	…	[e-mail]	男性
山田　太郎	…	[e-mail]	男性
ﾔﾏﾀﾞﾀﾛｳ	…	[e-mail]	男性
ササキジロウ	…	[e-mail]	男性
鈴木花子（スズキハナコ）	…	[e-mail]	女性

最大文字数と数字の制限

ここまでくると、電話番号も分かってきますよね。

氏名	住所	電話番号
山田 太郎	…	09009876543
山田太郎	…	090-0987-6543
山田　太郎	…	０９００９８７６５４３
ﾔﾏﾀﾞﾀﾛｳ	…
ササキジロウ	…	三重県津市◯町3-5
鈴木花子（スズキハナコ）	…	090０９９９8765

「実際に使えない番号」を入力させないために、入力する箇所でバリデーションチェックを行いましょう。
電話番号の最低限のバリデーションとしては、

• 0から始まり、その後9か10桁（つまり10桁か11桁のみ）
• 数字かハイフンのみ

があります。メアドと同様、もっと細かく制限はありますが一旦こんなところでいいでしょう。

「数字かハイフンのみ許容する」としてもいいのですが、「090-0987-6543」と「09009876543」は同じ番号であるにも関わらず、システム上はイコールにならないです。また、ハイフンで区切る位置が人によってバラバラだったりする可能性もあります。
ですので、筆者はハイフンが入らないようにする方が好みです。

今回のようなシステムであれば分析の機会は無いと思うのでどちらでも良いのですが、

「電話番号が同じなら同一人物と仮定して、１年間に何度このサービスを使ってるか調べる」

といった分析をする事があると、ハイフンありと無しが別々として認識されてしまう（番号は同じなのに2種類になってしまう）為、気付かなければ誤った数を報告してしまうことになりますし、気付いたとしても一度ハイフンを消す作業が必要になるので手間です。

また「半角／全角」もシステム上ではイコールにならないので、数値は「半角のみ」で統一させましょう。
これでバリデーションの方針がだいたい決まりましたね。さて、これをSaaSではどこまで実現できるのか。

電話番号も、前述した「メアド専用」のような専用のフォームがあればそれを使えば良いのですが、もし無ければ、デフォルトで用意されている制限でもマシになるでしょう。

• 文字数制限（最大何文字といった制限）
• 半角数字のみ

この2つは、カスタマイズの効くSaaSなら、大抵の場合用意されています。
半角数字のみで、文字数制限は10桁以上11桁以下、更に必須とすれば、今回のケースも、よほど間違った値は入らないと思います。
更にわがままを言えば、「0」で始まるものだけ（行頭の制限）があれば文句無しですが、これは今回のSaaSに用意されていませんでした。

ということで、入力欄はこのようになり、

項目	入力形式	入力制限など	必須
氏名	記述式テキスト	なし
住所	記述式テキスト	なし
電話番号	記述式テキスト	半角数字のみ 文字数10桁以上11桁以下	必須
メールアドレス	記述式テキスト	メアド専用(確認付き)	必須
性別	ドロップダウンリスト	性別マスタ	必須

中身のデータも無事揃ってくれましたね。

氏名	…	旧電話番号	新電話番号
山田 太郎	…	09009876543	09009876543
山田太郎	…	090-0987-6543	09009876543
山田　太郎	…	０９００９８７６５４３	09009876543
ﾔﾏﾀﾞﾀﾛｳ	…		09009876543
ササキジロウ	…	三重県津市◯町3-5	09009887654
鈴木花子（スズキハナコ）	…	090０９９９8765	09009998765

ちなみに、この「半角数字のみ」にする制限は「年齢」など、使う場面が多いのでよく覚えておきましょう。

要素を分割しよう

次は住所です。

「今回の地震は三重県だけなので、三重の人たちに連絡してほしい」

と指示があったので、早速HRさん、住所から「三重県」で検索しましたが、該当は0人でした。
データの中身を見てみましょう。

氏名	住所
山田 太郎	愛知県名古屋市◯区◯町1-22メゾン◯107号
山田太郎	名古屋市◯区◯町
山田　太郎	愛知県
ﾔﾏﾀﾞﾀﾛｳ	愛知県名古屋市◯区◯町1-22
ササキジロウ	514-0000
鈴木花子（スズキハナコ）	岐阜県◯市◯町

かなりバラツキがありますねー。

• 都道府県が入ってたり入ってなかったり
• 市区町村が入ってたり入ってなかったり
• 郵便番号が入っちゃってたり

「三重県」で検索しても出てきませんが、ササキジロウさん、郵便番号は三重県のようです・・・

「わかるか！」

こういう場合は、まず、分割できないかを考えましょう。
今までやってきた「必須」や「マスタ」「半角数字」などの規則を当てはめられる分解ポイントが無いか考えます。

「住所」を分解すると「郵便番号」「都道府県」「市区町村」「番地建物」に分けられます。
そうすると、

分解項目	規則	使える入力規制
郵便番号	7桁半角数字のみ	半角数字のバリデーションと必須
都道府県	47都道府県のみ	マスタからのプルダウンと必須
市区町村	都道府県に紐づく市区町村のみ	マスタからのプルダウンと必須
番地建物	不明	なし

分解してみると、結構規制が使えそうです。
今回の依頼も、都道府県を必須にしておけばすぐに算出できそうですしね！

関連しているマスタ

市区町村もマスタなのですが、先程紹介したものより若干複雑です。
なぜなら「都道府県」で何を選択したか、によって、そのあと選択できる「市区町村」が決まってくるからです。
「三重県、名古屋市」などの、ありえない組み合わせを防止しなくてはいけません。

また、一つの県で出てくる市区町村の数が多すぎて、入力側が選択するのが大変です。
もう一つ厄介なのは、市区町村は合併などで、追加や変更が多々あるので、メンテナンスしないといけません。
そして、もっと言うと、都道府県と市区町村は、郵便番号から関連しています。

このイレギュラーな組み合わせを全て入力時に防ぐには、ちょっと用意してある部品では作れないレベルになってきます。
ですので、もし、SaaS側にこのような、

住所用の入力補完機能が備わっているものが用意されている場合は、それを使いましょう。
最後に番地建物だけ入力してもらうだけですみます。
更に、番地のところは、数字やカナが入ってくるので、半角か全角に統一できると、尚よいでしょう。

もし専用のフォームが無くても、分割して必須にし、郵便番号と都道府県のバリデーションをするだけでも、最初の状態よりはかなりマシになり、バラツキを防げます。
郵便番号は、電話番号と同じくハイフンは禁止とし、7桁の数字のみとします。

HRさん、今回のSaaSは住所専用の部品が無かったので、このようにしました。

項目	入力形式	入力制限など	必須
郵便番号	記述式テキスト	半角数字のみ 文字数7桁のみ	必須
都道府県	ドロップダウンリスト	都道府県マスタ	必須
市区町村	記述式テキスト	なし	必須
番地・マンション名	記述式テキスト	なし	必須

これで入力してもらうと

こうなりました。
記述式テキストの市区町村も、必須にすることで未入力はなくなりました。
番地まではさすがにバラツキが出ましたが、前より全然マシです。これでかなり揃ってきましたね。

分割はよく使うので、もう一例挙げておきましょう。
例えば取引先マスタを考えてみます。若干やりすぎ感もありますが、考えられる分割はこんな感じです

会社名	➡	会社形態（マスタ）	前／後（マスタ）	会社名
株式会社ホゲホゲ	➡	株式会社	前	ホゲホゲ
ハラペコ株式会社	➡	株式会社	後	ハラペコ
サバサバ有限会社	➡	有限会社	後	サバサバ
㈱フガフガ	➡	株式会社	前	フガフガ

会社形態をマスタとすることで「㈱」と「株式会社」のバラツキを防げます。
「前／後」は少し応用パターンですね。
いわゆる前株と後株と言われるような、会社形態がどちらにつくかを表現してみました。
「前」か「後」しか存在しないので、それをデータとして保持しておき、出力するときにこの値を見ながらくっつけて出力しようと思います。

あまり分割しすぎても入力側が大変だったり（特に一般ユーザー向けのサービスはUI／UX的に入力欄は少ない方がいいので、もうひと工夫必要です）分析もかえってややこしくなる時があるので、闇雲に分割すればいいというわけではありませんが、基本的には分割すればするほど、入力に規制をかけることができ、ゴミデータが混じりにくくなるという事を覚えておいてください。

さぁ、あとは氏名だけです！

半角全角とスペース

現状の氏名を見てみましょう。

氏名
山田 太郎
山田太郎
山田　太郎
ﾔﾏﾀﾞﾀﾛｳ
ササキジロウ
鈴木花子（スズキハナコ）

ここでのバラツキは

• 漢字とフリガナが入っている
• 半角と全角が混じっている
• 性と名の間のスペースがあったりなかったり、半角全角が違ったりする

といったところでしょうか。

まずこのスペースが厄介です。スペースには半角と全角があり、システム的には別の文字ですが、空白なので、どちらなのかが分かりにくいです。排除しましょう。

ここでも有効なのは、先程の住所の時に出てきた「分割」です。
今回であれば「性」「名」「性のふりがな」「名のふりがな」のように分割できそうですね。

それぞれに分割できれば、間のスペースをそもそも入力する必要がなくなります。排除できました。

次に、カナの半角全角を揃えましょう。
カナの半角、全角は、先程のスペースと同様、システム上、別のものとして扱われます。
（最近は内部で同じ扱いにしてくれるシステムも増えてきましたが、基本的には別物です）
「ﾔﾏﾀﾞﾀﾛｳ」と「ヤマダタロウ」は、人間の解釈では同じなのですが、システムに同じ？と聞くと「違う」と答えます。

例えば先の取引先マスタでも同じです。

会社名	➡	会社形態	前／後	会社名
株式会社ホゲホゲ	➡	株式会社	前	ホゲホゲ
株式会社ﾎｹﾞﾎｹﾞ	➡	株式会社	前	ﾎｹﾞﾎｹﾞ

いくら分割しても、この2社は、システム的には別の取引先として認識してしまいます。
すると例えば、この取引先毎に、毎月取引データを紐付けて登録していた場合、入力者によってバラバラになってしまう、ということが起こります。

「株式会社ホゲホゲさんって先月いくら取引あったっけ」

と質問があった時に

「あ、株式会社ホゲホゲさんは500万円ですね」

と回答したけど、実は半角の「株式会社ﾎｹﾞﾎｹﾞ」にも500万円で登録されており、本当は1000万円だった・・・みたいな事です。

会社形態	会社名	取引額	入力者
株式会社	ホゲホゲ	5,000,000	Aさん
株式会社	ﾎｹﾞﾎｹﾞ	5,000,000	Bさん

更に、ある時これに気付いたはいいが、過去実績は確定して変更できないので、マスタから消せず、仕方ないので、毎回この2社を合算して報告する（そしてそれをつい忘れる）みたいな、更にアナログな運用が増えるケースもありえます。

こういった事を防ぎ、あくまで人間の解釈と同じ状態にするには「半角か全角、どちらかしか入力できなくする」とった対応が一般的です。
SaaSでも、半角禁止の入力規制が用意されている事は多いので、活用しましょう。

さて、今回も、半角禁止にしたのでこのようになりました。ついでにフリガナはカタカナのみにしました。

項目	入力形式	入力制限など	必須
姓	記述式テキスト	半角禁止	必須
姓フリガナ	記述式テキスト	全角カタカナのみ	必須
名	記述式テキスト	半角禁止	必須
名フリガナ	記述式テキスト	全角カタカナのみ	必須

外国人のようにミドルネームがあるケースも網羅するなら、

「姓名分けずに1項目とするが、必ず半角スペースで1箇所以上区切られており、全角スペースは許さない」

などとすれば、国の違いは関係なくフルネームを入れる事ができ、且つデータもキレイになりますが、今回のSaaSはここまで複雑な条件式を設定出来なかったのと、現状は日本人しかいなかったので、一旦これでいくことにしました。

これで入力してもらうと・・・

| 旧氏名 | ➡ | 性 | 性フリガナ|名 |名フリガナ|
|-----------|-----------|-----------|-----------|-----------|-----------|-----------|
| 山田 太郎 | ➡ | 山田 | ヤマダ|太郎 |タロウ|
| 山田太郎 | ➡ | 山田 | ヤマダ|太郎 |タロウ|
| 山田　太郎 |➡ | 山田 | ヤマダ|太郎 |タロウ|
| ﾔﾏﾀﾞﾀﾛｳ |➡ | 山田 | ヤマダ|太郎 |タロウ|
| ササキジロウ |➡ | 佐々木 | ササキ|次郎 |ジロウ|
| 鈴木花子（スズキハナコ） |➡ | 鈴木 | スズキ|花子 |ハナコ|

いいですねー、これで全ての項目が整理されました。

重複をはじこう

まずは、今までキレイにしたものを確認してみましょう。
元々のデータがこれでしたが、

こうなりました。

超キレイ！
なんと美しいデータでしょう。

でもまだなんです。ずっと気になっていた問題があります。

「山田太郎、同一人物じゃないの？」

先の取引先の重複でもそうでしたが、今回のケースでも、重複データは百害あって一利なしです。
メールを送っても、同じ人に4通来るし、愛知県の人数や男性の人数はかさ増しされてしまうし、山田さんの住所変更があったら4行も変えないといけません（そしてだいたい何行かは漏れます）

しかし、同一人物かどうかをいちいち人がチェックするのは大変です。
だからといって、入力者側に「2回登録しないでね！」と伝えても、

「あれ、俺登録したっけな・・・」

と忘れてしまい、念の為もう一度登録してしまう、という事は、社員が1000人もいれば、数人は発生します。
ですので、これもシステムで入力した時に判別できるようにしましょう。

前までの入力データでは、システム的に一致を判断できる項目が一つもありません。

• 氏名：スペース半角、スペース全角、スペースなし、半角カナの4種類。同じデータなし。
• 住所：愛知県があったり無かったり、途中までしか情報が無かったり。同じデータなし。
• 電話番号：ハイフンありなし、全角、未入力。同じデータなし。
• メールアドレス：半角、全角、全角記号、未入力。同じデータなし。
• 性別：男性、男、man、性別・・・。同じデータなし。

どれ一つとして、同じデータが無いわけです。
これでシステムに同一人物と判断しろと言っても、流石に無理ですね。
それに比べて、新しくなったデータではどうでしょう。

番地・建物名を除いて、全てが同じです。これなら、システムでも判断できそうですね！

重複条件を考えよう

ここで注意したいのは、一つの項目だけでは重複判断出来ない場合があることです。
まず姓名。同姓同名は存在します。なので、姓名の重複だけを許さない設定にしてしまうと、同姓同名の社員が入社した場合に登録できなくなってしまいます。
逆に、市区町村、番地・建物名はテキストの自由入力なので、今回のように同一人物でも表記が揺れる事がありえます。
また、メールアドレスを複数持ってる可能性もあるので、ここが別だからといって、同一人物ではない、と判断するのも危険でしょう。

そういった可能性をいろいろ考えて、重複判断の条件を考えていきます。
HRさん、今回は、姓名＆郵便番号＆電話番号が同じなら、同一人物とみなすことにしました。

「＆（アンド）」というのは「この条件全てが一致したらはじく」という意味合いです。
他には「or（オア）」というのもあり、これは「どれかが一致したらはじく」という意味になります。
SaaSにはどちらも設定できるようになっている事が多いので、ケースによって使い分けましょう。

重複判定されたらエラーを出す

入力確定した時に、同じデータが存在するかをチェックさせ、存在したら「既に登録済みです」とメッセージを出して登録できないようにします。

「あー、そういえば前に登録したんだった💦」

無事思い出してもらえました。
さぁ、これで全て完了です。重複登録ができなくなり、中のデータがどうなったかというと・・・

Ｏｈ！ビューティフル！
しかも、入り口でしっかりデータのコントロールが出来ているので、あとはほっといてもキレイなデータが溜まっていきます。

HRさんも、最初はいろいろヤキモキしていましたが、ここまで整備しておいてあげれば「データがおかしい」と上司に言われる事もなく「もう一度性別教えて下さい」などといちいち聞く必要も無くなり、啓蒙作業もいらなくなり、もう入力者側にイライラする必要はありません。そして使いたい時に、正しく使えます。

絶対防ぎたい「重複規制なし」

この「重複条件を考える」というのは非常に重要なのですが、何も設定しておらず結果的に「IDだけ違うけど同じデータ」が発生しがちです。

取引先ID	会社形態	会社名	都道府県	電話番号
1	株式会社	ホゲホゲ	愛知県	09009998766
2	株式会社	ホゲホゲ	愛知県	09009998766

これまで頑張ってきてせっかくキレイなデータを手に入れたとしても、他の情報が全て同じでも登録できてしまうので、新しいIDだけが付番されていき、システム的には違うデータとして登録されていきます。そうすると、先程例にあげたような取引額の間違いなど、数々の問題を引き起こします。
会社規模が小さく、数社しか取引が無い場合は目視で確認できるのでまだ良いのですが

• 会社規模が大きくなりビジネスの数が増えてくる、などの自社の変化
• 昨今フリーランスが流行りで取引先自体が増えている、などの環境の変化
• 社内でIDによるやりとりが増え、ID意外の情報に目が触れる回数が減る

などに伴い、知らない間に、目視で確認できる範囲をすぐに超えてきます。
重複を甘く見るなかれ。人の目や意識を過信してはいけません。
入力時点でエラーが出るような、絶対に重複させないためのシステム的な仕掛けが必ず早めに必要です。
これが制御できないSaaSは使わないか、後述する諦めない工夫を考えましょう。

入力フォーム完成版

さて、これで全ての項目に対してバリデーションをセットしました。

バリデーションチェック

項目	入力形式	入力制限など	必須
姓	記述式テキスト	半角禁止	必須
姓フリガナ	記述式テキスト	全角カタカナのみ	必須
名	記述式テキスト	半角禁止	必須
名フリガナ	記述式テキスト	全角カタカナのみ	必須
郵便番号	記述式テキスト	半角数字のみ 文字数7桁のみ	必須
都道府県	ドロップダウンリスト	都道府県マスタ	必須
市区町村	記述式テキスト	なし	必須
番地・建物名	記述式テキスト	なし	必須
電話番号	記述式テキスト	半角数字のみ 文字数10桁以上11桁以下	必須
メールアドレス	記述式テキスト	メアド専用(確認付き)	必須
性別	ドロップダウンリスト	性別マスタ	必須

重複条件

条件１		条件２		条件３		条件３
姓	＆	名	＆	郵便番号	＆	電話番号

入力項目数は多くなりましたが、ゴミデータが入る余地を最大限無くしました。
プログラムであればこれよりもっと余地を無くす事ができますが、SaaSでここまでできれば良い方でしょう。

逆に言えば「入力規制をかける機能がどれくらいあるか」というのも、SaaSの選定基準に入れておいた方が良い、という事ですね。

入り口が大事

これまで説明してきたデータとシステムの関係を、汚れた水と浄水器みたいな関係で例えてみました。

仕事の場面では、大抵は「コーヒーを作って飲みたい」のような、使う目的（見た目）から話が始まる事が多いので、コーヒーをいれる方法を探します。
しかし、入れる方法や器具は合っていたとしても、汚れや菌が入ってる汚い水を使ったコーヒーは、まずかったり、おなかを壊したりして、結果「これじゃなかった」となります。
その時はもう手遅れ。既に入ってしまった汚れや菌を後から取り除くのは容易ではありません。💦仕方ないので捨てる事になります。
1杯くらいならキレイな水で入れ直せばいいですが、パーティーなどで何十杯も作っていた場合は、作っていた「時間」と「捨てるコーヒー」が丸ごと無駄になります。

更に原因が水だと気付かなければ、コーヒー豆と変えたり、コーヒーメーカーを変えたりしても結果が変わらず、いつまでたっても美味しいコーヒーにたどり着かないのです。
「これだけ手と時間とお金をかけてもこんなに不味いってことは、コーヒーは美味しくない飲み物なんだな」と間違った判断をしてしまうかもしれません。

まず入り口で、菌などをきちんと取り除き、おいしい水を作って、それがあって初めて美味しい料理や飲み物になるのと同じように、どんなに良いシステムも、キレイなデータがあって初めて最大の効果を発揮します。

そして「水」はいろんな料理で使うように「データ」もいろんなものに使われます。
料理の度に浄水するのは大変すぎます。そうではなく、一番最初の入り口のところで水をキレイにするシステムを入れておけば、あとは料理に専念でき、料理だけでなく飲み物にも使えて、短い時間に美味しいものをたくさん作れて、ますます素敵な食卓になるわけです。

目的の「コーヒーを作る」を聞いた時に、その裏にある目に見えにくい「水」とその「流れ」を想像して、コーヒーを作る前に準備しましょう。

キレイなデータのためなら諦めない

ちなみに「今のSaaSはこんなにできないよ」という場合もあるかもしれません。
その場合は、若干エンジニアの工数を借りることにはなりますが、入力させる部分だけを自前で開発して細かい制御をかけ、入力後のデータをSaaSに自動連携させる、といった方法も考えられます。
（「API」という機能があると自動連携がしやすいので、製品選定の時は必ず確認しましょう）

入力画面だけなら開発も少ない工数で出来るかもしれません。エンジニアに相談してみましょう。
とにかく、なんとしてでも、キレイなデータを手に入れましょう。 簡単に諦めてはいけません。

複数のSaaS連携

ちなみに、なんだかんだ言いましたが、そもそも冒頭に記載した

本当なら、労務管理系のシステムにほぼあるデータなので、連動させられる

のが一番いいですよ！
（こんな長く読ませといてそれかーい∠( ﾟдﾟ)／）

とはいえ別システム同士のデータ連携は、自部署の範囲からもう少し踏み込んで、部門を跨いだ**「複数システム」になるのでちょっと難易度高いです。
複数システムを考えた場合、上流システムにあるデータを下流システムでも使いたい場合があります。この場合は上流システムの入り口**が最大の肝となります。
それさえ整えておけば、あとは、下流システムから汚いデータが入らないように、下流の入り口を遮断しておけばキレイに流れます。

自分の使ってるシステムがデータの流れのどこにいるのか考えてみましょう。もし上流であれば、下流の全システムのデータがあなたの肩にかかっているということです。

まずは今回のように**「単一システム」でデータをキレイに出来るようになり、次に「複数」ゆくゆくは、「会社にある全てのデータ」**が、美しく流れる川のようになるにはどうすればいいのか、ステップアップしてみるのもよいですし、難易度の高い部分なので、無理して全部自分でやろうとせず、遠慮せずエンジニアを頼るのも良いと思います👍

まとめ

今回のお話は、エンジニアで言うところの、データベース設計と、エントリーフォームのバリデーションチェック、というものに当たります。

SaaSは、今までエンジニアに任せておけばよかった部分が若干簡単になり、誰でもWEB上でやれるようになった、というだけで、考えなくてはならない本質は同じです。ところが、使う側の人は専門性が違うため、当然そんなスキルがありません。
ですので、エンジニアに頼らず導入するには、酷なようですが、現場の非エンジニアが代わりにデータリテラシーを身に着けなければいけません。

また、導入時にエンジニアに手伝ってもらえた場合も安心できません。
運用してみないと分からなかった、想定外のデータがいつの間にか紛れ込んでいます。
こういったイレギュラーのデータに、運用の途中でいかに気付けるか。そして、それをアナログでなくシステム的に修正できるか、データに着目し、にらめっこし、傷口が広がる前に手を打つ必要があるのですが、導入後にエンジニアはいません。

格納されるデータの流れや綺麗さを想像しながら設計したり、或いは、おかしなデータに気付いてすぐに修正する、手に負えなければエンジニアに相談する、というのは、関与がどうしても薄くなるエンジニアより、毎日運用している現場の方が適している場合が多いのです。

「システムさえ入れればなんとかなる」といった、魔法の杖はありません。
便利なツールを使う事になるなら、使いこなせるだけのリテラシーを現場が身につける事が大事です。
それさえあれば、先々の自分の仕事をうんと楽にできますし、逆に無頓着だと、せっかく苦労したシステムで更に苦労し、数年も持たず破綻して、またシステム導入の話が上がってしまいます。

世の中の流れ

今回の事例は、HRさんが悪いわけではないんです。元々専門性が違いますし、今まではやらなくて良かったスキルです。
ただ、今の時代、元々のエンジニア不足と、急速なIT化、DX化、ノーコード/ローコードなどのキーワードが盛んになっている昨今の市場が、ダブルパンチで襲いかかってきているため、本来ならITに苦手なままで生きていけるはずだったHRさんにも火の粉が飛んできているという状態になっています。
しかし、残念なことに、これからもその傾向は強まると考えた方がいいでしょう。

2019年にAmazonでは

倉庫のワーカーまで含め、あらゆる職種の10万人のデジタル能力トレーニングに、6年間で7億ドル以上を教育投資する

と、発表がありました。非エンジニアの方にもデジタル能力を付けさせるという事です。こうした準備を着々と進めている企業だけが生き残れるような時代も近いかもしれません。
逆に言えば、プラスアルファでデータリテラシーを身に着けておくことは、活躍できる幅や可能性を引き上げてくれるということです。

最後に

ここで紹介したような事例は極端すぎるのであまり無いと思いますが、これをヒントに、似たような事例が身近に無いかチェックしてみてください。これからSaaSの導入を考えている人がいれば参考になれば幸いです。

そして、日々忙しくて、導入に関わりたくても関わる時間が無いエンジニアの皆さんが、**「とりあえず、この記事だけ見といて！」**と、現場に紹介できるツールになれば幸いです。

Let's Enjoy 『Data』！

次回告知

Ateam Group Manager ＆ Specialist Advent Calendar 2020の18日目は @hyshr がお送りします。
1on1をよりよくするための「とある」方法・・・気になりますねー！是非ご期待ください！！

※ 他にもこんな記事書いてます