先日、別の知らない会社が作った基幹システムから出力したデータを、私の作ったサービスへインポートするという作業があった。インポートしてみると大量のバリデーションエラーが。どんなデータなのかと見てみたら、JANコードが入っているはずのカラムに、1.234567E+22のような感じの科学的表記法で表された謎の数値が入っているではないか。私はすぐピンときた。あっこれ、エクセルでデータが破壊されてるやつだ──。
もちろんこれは、まともなバリデーションを実装していないその基幹システムを作った人にも大いに責任はある。しかし、巡り巡ってエクセルの悪行が私にも降り掛かってきたという感じもある。私の怒りは、なぜかエクセルへと向かったのであった。
私は反エクセル過激派である。エクセルは強力なツールではある。しかし、とにかく落とし穴が多い。エクセルに電話番号を破壊された。ディスプレイ上できっちりレイアウトしたのに、印刷したらはみ出ちゃった。UTF-8のCSVをダブルクリックで開いたら文字化けしている。うん。それはエクセルの仕様だ。思い通りにならなかったとしても、そんなことは私の預かり知るところではない。しかし、エクセルを好んで使っている人たちほど、エクセルを使いこなせていない。仕方がないので、直せる誰かが直すしかない。それを直す役目はしばしば私に回ってくる。私はエクセルの大先生ではないのだが。世界からエクセルを消滅させるボタンが目の前にあれば、一瞬のためらいもなく１００連打するだろう。
後方互換性を大切にするのはマイクロソフトの良い面ではあるが、エクセルはいかんせん古い。とにかく古い。Pythonでスクリプトを書けるとか、ティラノサウルスを表示できるとか、変な機能が増え続けている一方で、古い駄目な仕様は正されず互換性のために維持され続けている。マイクロソフトがエクセルの落とし穴を放置しているのは、落とし穴の存在に気付いていないからではない。互換性のために意図的に残しているのだ。つまり、この落とし穴が今後改善される見通しはない。直らないのであれば、エクセルはいさぎよく腹を切って死ぬべきである。
このあいだ、帳票を出力するシステムの話をツイッターで見かけたときに、エクセルで作る帳簿のことも思い出した。この狂った因果は断ち切らねばなるまい。エクセルへの敵意と、今どき紙ベースの業務フローの悲しみが合わさり、エクセルを討ち滅ぼすツールを自分の手で作りたいという謎のソフトウェア開発意欲が生まれた。現在は、エクセルを粉砕する新たなツールの技術的な実験をしたり仕様を夢想しているところだ。