今日も定例のデータ分析タイム。社内システムから吐き出されたアンケートのCSVを開いたら、目の前に謎の現象が広がっていました。数字がアルファベットに見える。いや、見えるどころか「A」や「B」が本来の数字を表しているらしい。最初は目の錯覚かと思いましたが、冷静に見ると確かに数値が変換されている……。
何が起きていたのか（状況説明）
扱っていたのは社内システムの出力で、目的は分析です。今回はコードやIDがずらっと並ぶ表。ところが、その中の一部カラムが「数字ではない何か」に化けているのです。調べてみると、どうやらデータはShift_JIS系の「10進数表記」を使っており、それを解読しないまま読み込むと見慣れない文字列に変わる、という事情がありました。
最初の試行錯誤：何もわからないけど手を動かす
まず私は「単純な文字化けかな？」と安易に考え、RやSQLであれこれ読み込みオプションを変えてみました。エンコーディングを変える、別エディタで開く――どれも参考にはなるものの、根本原因の輪郭はぼんやりしたまま。既存コードを追っても、どこで「10進数表記の変換」が発生しているのか最初は全くわかりませんでした。
閃きの瞬間と解読の道筋
何度もググり、少しずつコードを変えて検証するうちに、ある時点でピンと来ました。Shift_JISの特定バイト列が何かの変換処理で「数値→文字」のマッピングに使われているのではないか、と。そう気づいた瞬間、頭の中の霧が一気に晴れる感覚がありました。
実際にやったこと（ざっくり手順）
- 問題のカラムをバイナリで確認して、どのバイト列が「変換」されているか特定しました。
- Rで生データをそのまま読み込み、該当バイト列をデコードしてみて、対応表を作成しました。
- 既存のパイプラインに影響を与えないよう、変換は読み込み直後のステップで行うようにコードを書き直しました。
独学で気づくのはハードルが高い理由
今回痛感したのは、こうした「エンコーディング周りの罠」は独学だけだと気づきにくいということです。関連する情報は散在しており、専門用語や環境依存の話が混ざるため、断片的に知識を積んでも全体像が掴みにくい。だからこそ、実際に手を動かして「これかな？→試す→合っているか確認する」を繰り返す地道な作業が必要でした。
やり直して得たもの
最終的にはコードを書き直して問題を解消し、無事に意図したデータとして分析ができるようになりました。正直、解決するまでの道のりは疲れましたが、乗り越えたときの達成感は大きかったです。「独学でここまで辿り着けた」と自分を褒めたくなりました。
同じ罠にハマらないために
- 読み込み時のエンコーディングは疑う：read系関数のencoding/localeオプションを疑ってみる。
- ログとバックアップを残す：変換処理を入れる前に元データを保存しておくと安心
- 分からないときは図にする：どのバイトがどう変換されるか、表にして可視化すると理解が早まります。
まとめ：小さな山を越えるごとに強くなる
今回の出来事は「数字がアルファベットに化ける」という一見奇妙な現象から始まりましたが、掘っていくとエンコーディングやバイトレベルの扱いといった本質的な学びにつながりました。独学だと気づきにくい壁もありますが、小さな成功体験を積むことで確実に成長できます。初心者としてですが、この時の勝利で少しだけ自信がつきました。
同じように悩んでいる方がいれば、一緒にその山を越えていきましょう。
