データアーティスト
データサイエンティストという職業があるようですが、私は世間一般で使われるサイエンスという概念をあまり信用していません。
詳しくはこちらで述べています。
データサイエンティストたちの言動を眺めていると、この人達はサイエンティストではなくアーティストなのではないか？と疑念が浮かんだので少しここでまとめてみようと思います。
そもそもサイエンスの基本は実験と観測です。
これが科学者のやっていることのほとんどなのです。
あとは論文を書くぐらいです。
翻ってデータサイエンティストは何をしているのでしょうか？
実験をやっている気配はないですし、分析はやっているでしょうが観測はやっていなさそうです。
分析と観測は違います。
観測はデータを創造する作業で、分析はデータを加工する作業です。
このように書いてみるとデータサイエンティストは特に科学者っぽいことは何もしていないように見えます。
ではなぜサイエンティストを名乗るのか？
それはきっと自分のやっていることが統計学と同じだと思っているからです。
統計学はソーシャルサイエンスと呼ばれる経済学や経営学ほどではないですが、本来の科学に比べて再現性が低い学問です。
本来の科学(自然科学)は定理や法則が定義されれば、誰がどこでやっても100%同じ結果がでるものでなければなりません。
しかし、統計学は大まかな法則性を見出すことまでしかできません。
法則を定義しても、それが100%の再現性を保証するわけではないのです。
そういった意味で統計はあまり科学的でないとも言えます。
そしてデータサイエンティストの仕事は言ってしまえばコンサルです。
あくまでも商売なので何かしらの結果を出さなければなりません。
そもそも科学者とデータサイエンティストでは仕事に対するアプローチが違います。
科学者であれば「仮説→検証→証明」という業務フローですが、データサイエンティストの場合は「分析→仮説→説得」という業務フローになります。
仮説を証明するのではなく仮説を売り込むのがデータサイエンティストの仕事なのです。
よってこの人達はサイエンティストではないのです。
では彼らは何者なのか？彼らはアーティストなのです。
証明する人ではなく、表現する人なのです。
データと分析の仕方によって人それぞれ、いかようにも仮説(表現)を生み出すことができるのです。
分析データを恣意的に選択でき、分析の手法も表現の仕方も個人の裁量で好きにやっていいのであれば、いくらでも思い通りの仮説をでっち上げることができます。
ここで、数字やデータを根拠とした言説であるにも関わらず、その内容がいかに眉唾ものであるかを、いくつか事例をあげて紹介したいと思います。
- 阪神無敗巨人未だ未勝利
2020年6月17日時点で当年のプロ野球はまだ開幕していませんでした。
例年であればスタートダッシュの勢いが衰えをみせはじめ、そこに交流戦が重なりさらに負けがかさんでいる時期です。
しかし今年はコロナ禍の影響でまだ一試合もしていませんでした。
そこを利用して「阪神無敗のまま親会社の株主総会へ」というタイトルの記事がでて、それがバズりました。
たしかに試合を行っていないので阪神が無敗(0敗)であることも巨人が未勝利(0勝)であることも事実は事実なのです。
言い方を変えれば巨人無敗、阪神未勝利とも言えるし、それもまた事実を表現しています。
しかし「阪神無敗巨人未だ未勝利」という表現をみると阪神は勢いに乗っていて巨人は調子が悪いような印象を受けてしまいます。
ある一つの客観的なデータを元にしていても、表現の仕方によっていかようにも印象を変えられるという好例だと思います。
- 一番狙わる部分を強化すべきです
有名な小話で、爆撃機の装甲を厚くすべき箇所はどこか問題というのがあります。
帰還した爆撃機の被弾箇所を分析して、一番被弾している箇所の装甲を厚くすれば爆撃機の耐久力がまして、機体の損失を最小限に抑えられると考えました。
しかしこれは生存者バイアスの罠で、無事に帰還した爆撃機の被弾箇所は被弾しても無事に帰還できると分析するのが正しく、他の箇所に命中した爆撃機は墜落して帰還できなかったのです。
帰還した爆撃機が損傷を受けていない部位を補強することが正しい対応だったのです。
検証に値するデータがあったとしても分析が間違っていれば結果も間違ったものになってしまうという好例です。
- 次は裏に賭けるべきです
コイントスをしていて表がでるか裏がでるかを賭けていたとしましょう。
現在5回連続で表が出続けています。
そして次の6回目で表がでる確率はいくらでしょうか？
ここであなたはデータサイエンティストであり、勝負をしている人に対してアドバイスをする立場にあるとしましょう。
真っ当な人間であるのならば、5回連続で同じ目が出ていようが100回連続で同じ目が出ていようが次のコイントスの結果の確率は常に50/50なのです。(イカサマがないのであれば)
よって「次は50%の確率で表がでます」というのが正しいアドバイスです。
しかし、データサイエンティストであるあなたは顧客から料金を頂いているので「どっちに賭けても同じ確率ですよ」という無責任な態度は取れないのです。
それを言ってしまうと自分の存在価値がなくなってしまいます。
相手が求めているのは「どちらに賭ければ勝てるか？」なのです。
そこで、それっぽい理屈をつけて「5回連続で表がでているなら統計的にみても、次の目も表が出る確率のほうが高いでしょう」や「5回連続で表が出てしまっているので次のトスで表が来る確率は下がっているはずです、ですので裏に賭けるべきです」などといって相手に納得感を与えるのです。
- 20代や30代の若者の感染者が多い
とあるウイルス検査で20代と30代の陽性患者が多いというニュースが流れました。
50人近くの陽性者が検出されて、そのうち20代と30代の割合は80%近くあったそうです。
このニュースだけを聞くとなにか若者世代が悪いかのようなイメージを持ってしまいます。
しかし、検査の実態はどうだったのでしょうか？
ニュースでは新宿歌舞伎町の夜の街のお店の人たちを集中的に検査を行ったとも言っていました。
このことから推察するに、夜の繁華街で働いている人たちのほとんどは20代や30代の方々だと思われます。
そこを重点的に検査したのですから、陽性者も20代30代の方が多く検出される結果になるのは当然の帰結のようにも思えます。
母集団を恣意的に選択すればある程度、その結果も操作できるという好例のように思えます。
SNSのトレンドや新聞やテレビの世論調査もある程度母集団にバイアスがかかっている前提で解釈するのが懸命だと思います。
こういった例のように、数値を出したりデータを分析したからと言って、その結果が必ずしも真実を現しているとは言えないのです。
やはり彼らはサイエンティスト寄りの人間ではなくアーティスト寄りの人間と思っておいた方がしっくりきます。
真実を突き詰めるのが仕事ではなく相手の共感を得るのが仕事なのですから、これはもうアーティストの仕事です。
もはやアーティストを超えて占い師といってもいいくらいです。
占いだから当たることもあれば外れることもあります。
データの取捨選択と加工を元に、ある仮説からそれっぽい予言を生成しているのがデータサイエンティストと言えます。
ガラス玉やタロットカードがビッグデータや統計学に変わっただけで本質的にやっていることは占い師と同じなのです。
Tag: 仕事
新型コロナウイルスとPCR
徳島大学の大橋眞教授の「新型コロナウイルスは存在しない」という主張を拝見して、そこから気になった疑問点をもとにいろいろ考えてみたので、それをメモ代わりにここに書いておきます。
あくまでただの憶測です。
この辺の動画です。 https://www.youtube.com/user/ias1ohashi/videos
遺伝子情報＝病原体の特定じゃないの？
病原体の特定にはコッホの4原則という鉄則があります。
それは
- ある一定の病気には一定の微生物が見出されること
- その微生物を分離できること
- 分離した微生物を感受性のある動物に感染させて同じ病気を起こせること
- そしてその病巣部から同じ微生物が分離されること
で、新型コロナウイルスと呼ばれるものはまだこの条件を満たしていません。
要するに、ある特定のウイルスがある特定の病気を引き起こす、ということがまだ証明できていません。
では世界中で行われているPCR検査とは一体何をしているのか？
そもそもPCR検査は病原体を発見するものではありません。
PCR検査は特定の遺伝子配列のコピーを大量生成することで検索元の遺伝子配列がそこに存在するかを確認する装置です。
この遺伝子配列のマッチングを行っている、というのがミソです。
ウイルスそのものをマッチングしているわけではないのです。
wikiにも
任意の遺伝子領域やゲノム領域のコピー
と書いてあります。
ウイルスそのもののDNA(RNA)をマッチングしているのではなく中国論文にある遺伝子情報(病原体ではなく、GenbankというDNA配列をコレクションしているところにあるデータ)だけをPCRにかけているので、厳密に病原体を特定しているというわけではないようです。
みんなのイメージだと、新型コロナウイルスの全遺伝子配列が分かっていて、それが仮に”new_coronavirus”という文字列だとすると、その文字列を検索にかけて、文字列が見つかる＝新型コロナウイルスに感染した、という認識だと思います。
しかし、実際のPCRは”*new_corona*”みたいに全体一致ではなく部分一致のワイルドカード検索になっています。
”new_coronavirus”も引っかかりますが、”hoge_new_corona”とか”new_coronafoo”みたいな別のウイルスも引っかかるし、そのどれが症状を引き起こす新型コロナウイルスと呼ばれる病原体かは分からないのです。
しかも中国論文自体の検証をしていないので、先ほどの例でいうと”new_corona”という遺伝子配列を持つウイルスがホントにある一定の病気を発症するかどうかも特定できていません。
コッホの4原則を満たしてないというのはそういうことのようです。
じゃあ、SARS-CoV-2ウイルスとは何者なの？
さきほどのGenbankに登録された遺伝子と一致する配列が存在するウイルスすべてをSARS-CoV-2ウイルスとしているようです。
コロナウイルス自体は大量の種類が存在し、悪性のものだけが研究対象とされており、日和見や善性についてはあまり研究が進んでいません。(日和見を研究してもあまり成果が出ないため)
Genbankに登録されているものもほとんど悪性のウイルスだけで日和見性のウイルスは登録されていないようです。
ということはまだまだ特定していない未知のコロナウイルスもたくさんいるということになります。
WHOが新型コロナウイルス感染症にCOVID-19という名称をつけました。
ウイルス自体にではなく、あくまで感染症という症状に対して、です。
これは何故かというと、病原体を特定できていないからです。
PCRによる遺伝子マッチングでは特定のある一種のウイルスという断定はできないので、そこで同定されたウイルス群が引き起こす症状、として定義したのです。
ウイルスを特定できていないから、ウイルスが引き起こす症状側の方をとりあえず定義したのです。
症状は存在するが、それがどの特定のウイルスが引き起こしたのかは分からない。
ウイルス側の方の定義はいまのところ科学的には存在しないのです。
よって科学的には「新型コロナウイルス」という特定のウイルスの存在の証明はできていないのです。
だから、未知のものに対して謙虚な姿勢である人たちは「新型コロナウイルス」という定義は使わず「COVID-19」か「新型コロナウイルス感染症」という症例にしか言及していないのです。
ちなみにPCRで再陽性が出る現象は初回でマッチングしたウイルスとは別のウイルスを検知している可能性も考えられます。
最後に今までの考えを踏まえて、PCR検査数を増やすほど重傷者や死者が増えるのではないかという仮説を思いついたのでメモとして残しておきます。
仮にPCR陽性者のほとんどが無症状(日和見コロナ)だった場合、PCR陽性者を集めれば集めるほど、一部の悪性コロナ感染者が無症状の人に感染させてしまい、悪性の感染率が高まる気がします。
各国で陽性者同士をどれほど隔離しているかは知りませんが(健常者と患者は隔離するでしょうが患者同士の接触管理は？)。
某ノーベル学者の言ってる「ファクターX」はPCR検査が少なかったことなのかもしれません。
プログラマーにアルゴリズム脳はいらない
プログラマーの適正としてアルゴリズム脳が挙げられます。
しかし、最近この能力はそれほど大事ではないし、むしろ仕事においてはデメリットのほうが大きいのでは？と考えるようになりました。
そこで今回はアルゴリズム周りの能力について考えてみます。
ちなみに、アルゴリズム構築能力は大事だと思っています。
当エントリではアルゴリズム脳は既存の知識や脳内思考のことを指し、アルゴリズム構築能力は結果的にプログラムを書き上げる力、と分別して考えます。
仕事におけるプログラミングでは最初に頭の中で考えたものがそのままサービスで動くコードに置き換わることはあまりありません。
この「最初に頭の中で考える」がいわゆるアルゴリズムを考えることです。
「最初に」と書きましたが、最初に書き下したアルゴリズム実装(ある処理の一連のコード)がそのまま本番環境のデプロイまで残っていることはあまりないと思います。
書き終わったあとに、実際に動かそうとしてみたところで、コンパイルエラーだったり、インターナルサーバーエラーだったり、テストがコケたり、想定していた動きと違う…など、何かしらの不具合が見つかるのが普通です。
逆に、長めのコードを書いたあとに一回でコンパイルが通ってしまうと逆に「えっ！？うそ？」という気分になります。
最初に書いたコードからいろいろトライアンドエラーを重ねて不具合を解消していき、第三者のレビューやCIのチェックを超えて、デプロイされ、やっと「動くコード」として完成するのです。
この流れで見るとアルゴリズムを考える作業は最初だけで、仕事全体で見ればほんの一部だということが分かります。
しかもプログラミングというかシステム開発で一番大事なのは、個々の処理のアルゴリズムではなく、実装する前のモデリングや設計です。
部分的な実装が致命的な障害になる場合もありますが、設計やモデリングの失敗に比べれば傷はまだ浅いほうです。
システム開発における個人のアルゴリズム能力の重要度はそれほど高くないといえます。
そして、アルゴリズムを考えるのが苦手な人でも、プログラミングは全然可能であると考えます。
自分はどちらかというとアルゴリズムを考えるのが苦手な人です。
ここで自分がコードを書くときの例をあげます。
実装したい仕様があったとき、最初に「なんとなくこんな感じかな」とあまりロジカルというかMECE的にやろうとは考えずに、とりあえずそれっぽいコードを一旦書いてみます。
書いてみて実際に動かしてみた結果と仕様を比較しながら「ここはこうじゃなくてこうかな？」というふうに試行錯誤しながら直していって最終的に仕様と同じ挙動になったところで一旦完成としています。
具体的な実装例で説明してみましょう。
「今日が作成日から三日以内なら真」という仕様があるとします。
実装しようとする場合、まずは「作成日と3日で比較すればいいんだな」という安易な発想で
created_at < Time.current + 3.days
みたいに書いてみます。(言語はRuby with ActiveSupport)
で、実際に動かして検証してみます。
すると「あ、現在より過去のデータだとダメだわ」と気づきます。
次にそれを修正して
Time.current < created_at && created_at < Time.current + 3.days
としました。
これでどうでしょうか？
過去のデータはちゃんとはじいているようにみえます。
次に「3日以内ということは今日を含んで、明日と明後日までが対象だな」ということでそれぞれの日付を入れて実際にテストしたところ、今度は今日がダメだと分かります。
更に修正して
Time.current <= created_at && created_at < Time.current + 3.days
としました。
これでもまだダメなようです。
今日だとしても実行時間によって結果が分かれてしまいます。
Time.currentは時分秒も含まれるのでcreated_atが時分秒を含んだデータの場合(Railsの命名規約的には含んでいます)、作成日が現在時刻より過去なら同日でも偽判定となってしまいます。
ということでさらに
Date.today <= created_at && created_at < Date.today + 3.days
としました。
これでうまく仕様を満たしたっぽいです。
さらに「Time型とDate型が混同しててなんか分かりにくかったからダメだったんだな」と思い至り、最終的に
(Date.today..(Date.today + 2.days)).include?(created_at.to_date)
としました。
最初のコードは確かに間違えていて「お前はバカか？」と言いたくなる感じですが、最終的には仕様どおりに動くプログラムができあがりました。
はじめから最後にできあがったようなコードが書ければいいですが、それができなくてもトライアンドエラーを重ねることによって仕様を満たすコードを実装することができます。
さらにトライアンドエラーを重ねて実装していくほうが一発で仕上げるよりもメリットがあります。
仕様の抜け漏れに気づきやすいし、実際の実行結果をもとにコードを洗練させていくので、頭の中だけで考えるより現実的なロジックに到達しやすいのです。
何だったらこの試行錯誤こそがTDDの本質と言えます。
逆に、アルゴリズムを考える能力が高かったらどうでしょうか？
頭の中のシミュレーションとそれを現実に適応した場合とでは往々にして違うことが起きます。
そもそも、みんなの頭の中で考えたことが完璧であればこの世にバグなど存在しないのです。
しかし現実のシステムはバグだらけですし「バグを減らす唯一の方法はコードを書かないこと」と言われるように、コードが存在すればその時点でバグの存在は否定できないものとなります。
それなのに自分の能力を過信して「このロジックで完璧だわ」と実際に動かしもせず、テストも書かずにコミットしてしまい、レビューや運用の段にになってはじめて初歩的なチョンボが発覚し、足をすくわれてしまうのです。
それだったらまだ、答えのアルゴリズムがパッと思い浮かばなくても、試行錯誤をしながら、探り探りロジックを構築していくほうがプログラミングとして正しい姿勢のような気がします。
プログラマーの入社試験でよくFizzBuzzのアルゴリズムを書かせる試験がありますが、個人的にこの試験ではプログラマーの適性は見抜けないと思っています。
試験時は実際にコードを書いて動かしながらロジックを書くのではなく、頭の中で考えたアルゴリズムをそのまま発表してもらって合否を判断するので、試行錯誤しながらコードを書き上げていくタイプの人間だと、この試験で落ちてしまいます。
ところで、英語でのalgorithmは
a set of rules that must be followed when solving a particular problem
と定義されています。
アルゴリズムはルールを考えることと同義なのです。
ルールは実際にやってみて検証してみないと、それがほんとに効果があるかどうかは分かりません。
経済学がいくら発展しても一向に世界の景気を良くすることができないように、言説がいくら確からしくても、現実に適用できなかったり、できたとしても思っていた効果は得られなかったりするのです。
ですのでアルゴリズムを考える能力よりも仮説検証を繰り返しながらアジャイルのようにアルゴリズムを組み上げるやり方のほうが現実に沿っているのです。
そして、既知のアルゴリズムのほとんどはライブラリ化されていますし、ググれば大抵のものは見つかります。
よって、知識としてアルゴリズムを覚える価値もあまりないような気がします。
入社試験で出てくるもう一つ有名なアルゴリズムにバブルソートがあります。
これも「なんか隣と隣で比べながら並び替えていくんだな」ぐらいの認識で、実際の正確なアルゴリズムまでは覚えておく必要はないと思いますし、実際に「今書いてみろ」と言われてもサッと一発では書けません。
というわけで、文頭に考えていたアルゴリズム脳のデメリットは
- 脳内思考に頼りすぎると仕様の矛盾に気づきにくく確認不足による間違いが増える
- 脳内思考と知識としてのアルゴリズムを実装能力そのものと勘違いしてしまう
の2つになります。
実際の実装能力(＝アルゴリズム構築能力)で大事なのは試行錯誤の繰り返しによる動作検証で、これはなかなか試験では見抜けない気がします。
Tag: プログラミング
