【マイレース開発記録(9)】
47都道府県の緯度経度実装　　　　　　　　　　　　　　　　　　　　　　　

「出生地」を入れたい。でも、どう扱おう？

マイレースには、いくつかの入力項目があります。

• 生年月日
• 出生時間
• 出生地（都道府県）
• 眺めたい日（占いたい日）

この中で、少し悩んだのが
「出生地」でした。

最初は、
「本当に入れる必要があるかな？」
と迷っていました。

というのも、画面では「東京都」「大阪府」のように
文字で選べても、
天体計算をするときには、
最終的に緯度と経度が必要になるからです。

しかも、都道府県は47あります。

入力しやすさは残したい。
でも、計算に使える形にもしたい。

この間をどうつなぐかが、
今回のテーマになりました。

最初から完璧を目指さないことにした

最初は、

• 「もっと正確な位置情報にした方がいいのかな」
• 「市区町村まで入力できた方がいいのかな」

と、いろいろ考えていました。

でも、考えれば考えるほど
決められなくなってしまいます。

そこで、いったん目的を整理しました。

マイレースで今必要なのは、
精密な地図を作ることではありません。

大切なのは、

「出生地を選べる」という体験を残しながら、
バックエンド側できちんと計算できる形にすること

です。

そこで、まずは、

都道府県 → 代表地点の緯度・経度

という形で進めることにしました。

最初から100点を目指すのではなく、
あとから直せる形で、まず動かしてみる。

この考え方にしたことで、
かなり気持ちが楽になりました。

都道府県ごとのデータをまとめて持つ

次に考えたのは、
47都道府県の緯度・経度を、どこに置いておくか
ということでした。

今回は、都道府県ごとの代表地点の情報を、
ひとつのファイルにまとめて持つ形にしました。

イメージとしては、

• 東京都 → 東京都の代表地点
• 大阪府 → 大阪府の代表地点
• 北海道 → 北海道の代表地点

という対応表を作る感じです。

こうしておくと、

• データの場所が分かりやすい
• 修正したいときに探しやすい
• 後から別の形式に置き換えやすい

というメリットがあります。

47個なら、最初の段階では
十分管理できる数です。

ここでも、
「今の自分が扱いやすい形にする」
ことを優先しました。

画面側は、できるだけ選びやすく

出生地の入力では、
自由に文字を入力してもらう方法もあります。

でも今回は、
都道府県を一覧から選ぶ形にしました。

その方が、

• 「大阪」と「大阪府」のような表記ゆれが起きない
• 誤字が減る
• 入力チェックがしやすい
• ユーザーも迷いにくい

というメリットがあります。

これは自分自身にとっても大切でした。

自由入力が多いと、
「この書き方で大丈夫かな？」
「どこまで入力すればいいんだろう？」
と迷う場面が増えてしまいます。

でも、選択肢があらかじめ用意されていれば、
迷うことが少なくなります。

人の注意力だけに頼るのではなく、
仕組みそのものを分かりやすくする。

この考え方は、
前回のバリデーションにもつながっています。

バックエンドでも、もう一度確認する

画面で都道府県を選べるようにしても、
それだけで安心というわけではありません。

そこで、サーバー側でも、
「この都道府県は、登録されているものかな？」
と確認するようにしました。

もし、存在しない値が送られてきた場合は、
そのまま計算に進まず、エラーにします。

一見すると地味な処理ですが、
こういうチェックが後から役立ちます。

例えば、

• 画面側の表示が変わったとき
• JavaScript側で想定外の値が送られたとき
• 将来、入力方法を変更したとき

でも、サーバー側で最後に確認できます。

前回も書きましたが、
APIが最後の確認役になるという考え方です。

「もっと良い方法があるのでは？」で止まりかけた

今回、技術そのものよりも難しかったのは、
どの方法を選ぶか決めることでした。

考えていると、次々に別の案が浮かびます。

• CSVにした方がいい？
• 外部APIを使った方がいい？
• 市区町村まで選べる方がいい？
• 住所を入力して自動変換した方が正確？

どれも間違いではありません。

でも、全部を比較し続けていると、
いつまでたっても作り始められません。

私はこういうとき、
「もっと良いやり方がある気がする」
と考えすぎて、手が止まってしまうことがあります。

今回も、少しその状態になりました。

AIとの対話で、「今必要なこと」に戻れた

そこで、AIと話しながら、

• 今の段階で、どのくらいの精度が必要？
• 今すぐ市区町村まで必要？
• 後からデータを入れ替えることはできる？
• まず都道府県単位で進めても問題ない？

と、一つずつ整理していきました。

すると、

「今すぐ必要なもの」と
「将来できたらいいもの」を分けて考える

ことができるようになりました。

例えば、今は

都道府県を選ぶ
↓
代表地点の緯度・経度を使う

という形で十分。

もし将来、もっと細かくしたくなったら、

• 市区町村対応
• 外部API
• 住所検索

などを追加すればいい。

そう考えると、
かなり前に進みやすくなりました。

AIが助けてくれたのは「決めること」

今回も、AIが代わりに全部を作ったというより、
迷っているところを整理する相手として
助けてもらった感じです。

私は、選択肢が増えるほど、
「どれが一番正しいんだろう」
と考えすぎてしまうことがあります。

でも開発では、
いつも唯一の正解があるわけではありません。

大切なのは、

• 今の目的に合っているか
• あとで直せる形になっているか

ということなのだと思います。

そう考えられるようになってから、
「まずはこの方法で進めてみよう」と
決めやすくなりました。

「あとで変えられる」は、かなり大事

今回の設計で、もうひとつ大きかったのが、
あとから変更できる形にしておく
という考え方です。

最初に完璧な緯度・経度データを作れなくても、
ひとつの場所にまとめておけば、
後から差し替えられます。

これはかなり安心感がありました。

「今決めたことが、ずっと最終決定ではない」
と思えると、
最初の一歩を踏み出しやすくなります。

開発では、

変えないことより、
変えやすくしておくこと

も大切なのかもしれません。

今回の開発で感じたこと

今回の47都道府県の実装では、
派手な新機能が増えたわけではありません。

でも、

• 入力しやすくする
• データを整理する
• サーバー側でも確認する
• 後から変更しやすくする

という、アプリを長く育てるための考え方を
学べました。

そして何より、

最初から全部を完璧に決めなくてもいい

ということを、またひとつ実感しました。

迷ったときは、
今の段階で必要なことは何か
に戻る。

この考え方は、
これからの開発でも使っていきたいと思います。

次回予告

次回は、マイレースの中でも、
少し「占いらしさ」が見えてくる部分です。

レース結果に合わせて表示するメッセージを、
毎回ランダムに変えるのではなく、

「同じ条件なら、同じ結果になる」

ようにしたい。

そのために使ったのが、
seed（シード）とハッシュ
という仕組みでした。

次の記事では、

【マイレース開発記録(10)】seedによるメッセージ固定化
――「占いの一貫性」を作る――

として、
「ランダムっぽく見えるけれど、実はちゃんと決まっている」
仕組みをどう作ったのかを書いていきます。