翻訳としてのデータ分析#23　大火傷をしないためのSELECT

原文抜粋 ： 「！」の処理について

僕は英文にエクスクラメーションマークがあったらほとんど全部再現します。クエスチョンマークも再現するし、段落も絶対変えない。この3点はもうそのままにして何も考えないですね、面倒だし。

『ぼくは翻訳についてこう考えています －柴田元幸の意見100－』より

データ分析に置き換えて考える

何も考えずに入れる処理がある。

集計するとき、直接必要がなくても、ユーザ数や売上と言った重要指標も合わせて出す処理だ。そして、ダッシュボードなり何なり、社内の公式数字と合っているか確かめる。これは、数字を出すときに必ず行う。

分析は簡単にミスる。
一行書き間違えただけで、数字が増えたり減ったりする。

社会人1年目のとき、営業資料用の集計をミスった。その会社は全国に支店があって、支店ごとに集計結果を用意して送った。その数字を盛大に誤ってしまった。

幸い、先輩がすぐに発見してくれて、支店に届いて間もないうちに修正版を送り直すことになった。先輩は一言も怒らず、ただひたすら、支店に謝る電話をかけ続けてくれた。

怒られなかったのが逆にこたえた。
もう2度と大きな過ちはしたくないと思った。

ミスは程度によって、リカバリーコストが飛躍的に大きくなるポイントがある。ある程度までは、メール1通、チャット1通で訂正すれば済む。ただ、それでは済まず、誰かが正式に謝罪する必要が生じるポイントがある。

そのポイントは、状況によって変わるので、都度見極めが必要だ。ただ「公式数字と合っているかどうか」はいついかなる時も最低限確認する。既存の数字に合わせられない場合でも、少なくとも数字感がズレていないかどうか（桁が誤っていないかどうか）はチェックできる。

雑駁な話をすると。9割以上合っていれば、細かいところが多少誤ったとしても、リカバリーはしやすい。意思決定が変わらないレベルの変更は、真摯に説明すれば、ビジネス上問題は生じにくい。

しかし、結論が変わったり、動くお金が変わるような変更は、問題となる。たくさんの人に迷惑がかかる。信頼も損なう。

ちょっとの手間で大火傷を避けられる可能性が高まるならば、僕はその手間は厭わない。そうして生まれたのが、何も考えずに入れる重要指標の集計処理だったりする。今まで何度、

 SELECT COUNT(DISTINCT user_id), ...

を書いてきただろう。user_id は total_sales や client_id や ad_id だったりした。

そしてこれからも書き続けるだろう。いつか、自動的にチェックできるような仕組みを、Googleが生み出したりするのかもしれないけど、その日まではずっと書き続けるだろう。