You shouldn’t use a spreadsheet for important work (I mean it)
経済学者はうらやましいね。コンピューター科学者とは違って、革新的な研究で、ベストセラー本をだせるときている。たとえば、 Capital in the Twenty-First Centuryだ。この本はマルクス経済を再認識させる本だ。本を読んでいない人のために要約すると、資本の増加は賃金の増加よりも高いので、資本を持つ者はますます富み、ますます強大になる。大多数は貧する。少数のエリート達が、富のすべてをかき集める。一般人には富は残らない。この見方は、彼の専売特許ではない。富の集中という概念には、富める者はますます富み、貧するものはますます貧すというキャッチフレーズまである。
同じ主張をするものはいくらでもいる。しかし、証明するのは難しいし、一部の経済学者は、反証すら見つけている(Wojciech Kopczuk and Allison Schrager | The Inequality Illusion | Foreign Affairs)。今日、高額な遺産相続によって大金持ちのリストに乗るのは、1970年より難しい(更に詳しくは、Women, Wealth and Mobility, Earnings Inequality and Mobility in the United States: Evidence from Social Security Data Since 1937, Top Wealth Shares in the United States: 1916-2000: Evidence from Estate Tax Returnsを参照)
Pikettyの研究で興味深いのは、彼は自分の主張の裏付けとして、膨大なデータと解析を元にしていることだ。残念ながら、実に多くの人間がそうするように、Pikettyはまともなソフトウェアを書く代わりに、表計算を使った。高評価できる点としては、彼はコードを公開した。低評価としては、Pikettyのコードには誤りがあったということだ。
表計算には、オリジナルのソースの打ち込み間違いや、間違った数式が使われていた。中略。ファイナンシャル・タイムズが修正したところ、ヨーロッパの数字は、1970年以降、資産の不公平な増加傾向は見られなかった。外部の専門家も、ファイナンシャル・タイムズと同じ懸念を表明している(ファイナンシャル・タイムズ、2014-05-23)
その結果として出たのは、中略、他のデータからの解析結果でも、新しいデータによる数字の更新でもなく、泥水で滑ることで、人為的な傾向が、潤滑油により「滑らか」に修正され、中略、その結果は、解析に申告な問題があるにも関わらず、主要な学術誌によって印刷された(Phillip W. Magness » Piketty Tricketty & Historical US Wealth Data)
驚きはしない。去年、筆者はReinhart-Rogoffの事例を検証した。二人の著名な経済学者は、過去のデータに基づく複雑な統計解析に基づき、多額の負債は経済発展率の低下につながると結論づけた。残念ながら、彼らも表計算を使ってしまったのだった。
だいたい、表計算というものは手早いやっつけ仕事には向いているものの、真面目で重要な作業には向いていないのだ。
- まともなソフトウェアには詳細なテストが付随するべきである。テストなしで、どうして自分の書いた機能が、自分が意図する通り正しく動作すると言えるのだ? 表計算は、テストをサポートしていない
- 表計算は、コードレビューを困難にする。コードは何十、何百もの小さなセルの中に散らばっている。コードを自分で注意深く検証できず、また他人による検証も難しい状況で、どうして信頼できようか?
- 表計算はコピペプログラミングとやっつけ仕事を自然と行わせてしまう。コードの検証、テスト、保守を難しくする。
筆者は、生徒の成績処理とか、退職後の貯金推定とか、去年支払った税金の計算などの作業には、表計算で満足だ。しかし、筆者は、銀行運営とかスペースシャトルの軌道計算に、Microsoft Excelは絶対に使わない。表計算はお手軽だが、間違いやすい。表計算は、間違いがそれほど問題にならないか、問題が簡単な場合にのみ適しているのだ。Pikettyは複雑な処理を行っていたし、彼のキャリアの進展は、結果の正確性にかかっていたようだ。
ReinhartとRogoffのように、Pikettyは問題があることを否定しなかった。しかし(ReinhartとRogoffのように)、彼は自身の誤りは些細なものであり結論に影響するものではないと主張した。
反論に対する第一声で、Pikettyは相手に証明を押し付けた。「もちろん、ファイナンシャル・タイムズの統計と資産ランキングが逆の結果を出したのならば、私としてもその統計を検証するし、もちろん結論を変えるよ」と
Pikettyは問題を正しく認識していない。正しい答えがでることだけでは十分ではないのだ。バグだらけのソフトウェアを搭載した飛行機に乗りたいと思うかね。プログラマーはバグが飛行に影響するものではないと主張しているとしてもだ。そりゃ、飛行機は安全に着地するかもしれん。だが、それは単に運がよかっただけであるかもしれんだろう?
Pikettyは、自分はコードを公開したという事実を強調するという点でも、問題を認識していない。そりゃ、解析に悪意があったわけではなかろう。だが、正しいとも限らん。
人は間違いを犯すものだ。表計算にしろ何らかのアプリにしろ、何かソフトウェアをリリースしたとしたら、確実に何らかのバグが含まれているのだ。どうしようもない。しかし、バグを防ぎ、見つけ、悪影響の範囲を制限するために努力したはずだ。筆者は毎日プログラミングする。少なくとも、筆者のプログラミング時間の半分は、バグを探すことに費やされている。Pikettyは、Reinharは、Rogoffは、一体どれだけ解析結果の精度の検証をしたというのだ? 彼らが表計算を用いたという事実が、精度にそれほど気を使っていなかったという事実を如実に物語っている。そりゃ、優秀な外科医は、タキシードを着たままキッチンナイフで腫瘍切除ができるかもしれん。しかし、いったい手術が正しく行われるという自信はいかほどか。データ解析に基づいて600ページもの本を書くのであれば、何ヶ月もの間、解析の検証、テスト、ドキュメント化に費やすべきだ。
これがPikettyのキャリアのどれだけ影響を与えるのか、興味深いことではある。先週、何十人もの経済学者が、Pikettyはノーベル賞確実だと話すのを聞いた。果たして今もノーベル賞を取れるのか? 解析がどれだけ間違っていたのかと、論文にある解析の品質によるだろうとしか言えん。
Pikettyは、経済学者としては膨大なデータを扱った。思うに、経済学者もこれからは複雑で莫大なデータを扱わなければならなくなる。より一層複雑な解析が必要となる。彼らがまともなツールと技術を使うことを覚えるといいのだがな。
参考文献:
- Piketty’s Data Is Full of Errors (Slate)
- Did Piketty Get His Math Wrong? (New York Times)
- Thomas Piketty’s Inequality Data Contains ‘Unexplained’ Errors (Huffington Post)
- Are there major mistakes in the bombshell economics book of the year? (Quarz)
追記:Richard Tolも、最近間違ったデータ解析のしっぽを掴まれた経済学者の一人だ。彼もまた、Excelを使っていた。
追記2:経済学者がExcelを使うというのがどれほど一般的なのか、筆者は知らない。そんなに一般的ではないのかも知れない。経済学者のSergio Salgadoは書いている。「まともな統計解析は、STATAかSASか、まあ、最低でもRかFORTRANを使うものだ。Excelなんて使う奴はいない」と。
ドワンゴ広告
ドワンゴ社内のデータマイニングに使われているツールについて、筆者は詳しく知らない。本人が最も使いやすいと思うツールを使えばいいのではないかと思う。ドワンゴでは、優秀なデータマイニングのエンジニアは大歓迎であると聞いているし、実際に中途の採用募集もしているようだ。本物のデータマイニングエンジニアは、本物C++プログラマーより希少かもしれない。
ドワンゴは本物のC++プログラマーも募集しています。
CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0
5 comments:
そもそも何であれ、Excelなんか使うという発想が起こらない。
狭い発想力ですね
Excel は作るのは簡単だけど、検証・メンテナンスは地獄。
Office ソフトというか、GUI で操作するタイプのソフトウエアは、
みなそうなのですが。
クリックしてみないと、どこに何があるのかわからない。
まるでトレジャー ハントのように、あちこちクリックして、
何か入っているか探さないといけない。
しかも、クリック操作で内容が変わってしまう危険性もある。
データ編集の記録・履歴が残らず、
今までどこをクリックしてどう操作したのか全て人間が記憶しておく必要がある。
(もちろん、そんなことは不可能)
ただ、データを眺めるのには、GUI の方が見やすいというのはあるのですよね。
よって、編集はテキストベースのコマンドで行い、
結果は GUI で見る、というのがベストかと。
Excel もデータ閲覧のみに使う分には良いと思いますよ。
R でデータ編集して、Excel に出力して閲覧するとか。
責任論(honest error)と、論文の正誤の問題とを混同しているという、どこかの論文事件のみならずあちこちで起こっている論理欠落ですね。
しかしそもそも、精確性が必要な場面で検証困難なソフトウェアを利用することが業界常識になってhonest errorで済むとしたらまずい。
検証するには、複数のソフトウェアを用いることが良いし、入力した算式を含めて他者による査読を受けてから発表するがよろしいと思います。
> 検証するには、複数のソフトウェアを用いることが良いし、入力した算式を含めて他者による査読を受けてから発表するがよろしいと思います。
膨大な量のデータ(数百年分)を分析した、
というのが売りの本ですから、かかったコストも莫大でしょうね。
おそらく、大学院生・大学生を動員して、人海戦術でやったのでしょうけど。
かの Microsoft には、プログラマと同数のテスターがいるそうですが、
これは年間 3 億ものソフトを売る会社でも、
倍の人数を用意するのが限界ということでもあり。
事前に完璧に検証するのはコスト的に不可能でしょうね。
コンピュータ科学者の作るプログラムにだってバグはあるわけで。
現実的に考えるなら、検証作業までよく考えた上で、
ソフトウエアを 1 つ選び、
可能な限り検証しやすく作るしかないかな、と思います。
論文・本が有名になれば、この件のように後から検証する人も出てくるでしょう。
個人的には R を使ってプログラムを作り、GitHub で公開するのが良いと思います。
データをどうするかは難しいところ。
Git のリポジトリに入れるには、サイズが大きすぎますからね。
データの編集履歴はあきらめるしかないかなあ。
(表計算だとデータとプログラムが一体化しているから、分けて管理できない、
というのもありますね)
Post a Comment