渋谷駅前で働くデータサイエンティストのブログ

元祖「六本木で働くデータサイエンティスト」です / 道玄坂→銀座→東京→六本木→渋谷駅前

データサイエンティストがこっそりこぼす8つの愚痴(海外記事紹介)

ちょっと前の記事なんですが、面白かったので紹介します。


データサイエンティストのConfession(告白)というよりただの暴露談義なんですが、もっと言ってしまうとこれって「データサイエンティストあるある」ですよね(笑)。むしろ暴露じゃなくて愚痴大会と言った方がいいような。。。



ちなみに↑こちらが元ネタみたいです。ということで、データサイエンティストやデータ分析者の人たちには「他の人たちもこういうことで頭抱えてるのか!」という安心感を差し上げるために、そういう人たちに仕事を頼む立場の人たちには「へー彼らこんなことで悩んでるのか」「へー裏ではこんなヤバいことになってんのか」という意外感を差し上げるために、適当にまとめておきます。


1. いつ分析をクローズしていいのか分からない


データサイエンティストが作り上げたモデルや分析結果は「もっと、もっと、もうちょっと改善できるよね?もう一声!」という飽くなきクライアントからの要望のもと、いつまででも改善し続けなきゃいけないことが大半。なのでどこでクローズすべきかを決めるのは至難の業だし、一方でかかる労力や時間の割にその改善で得られる効果は微々たるものだったりするという。。。


2. データを歪曲(拷問)しているんじゃないか?という罪の意識


「データを歪曲*1させ続ければ、いつかは吐く」。どんな効果でも、ものすごーーーく特殊なやり方でデータを見ていれば見つかるものです(たとえ何の効果もなかったとしても)。


3. 「そこに何か重大な兆候がある!」と見つけたふりをする


一番面倒なのは、そこに何もそれらしき兆候やら目立った知見がないのに、クライアントがめちゃくちゃ期待している場合。特に「ビッグ○○○」とか言われた日には。。。


こういう場合にデータサイエンティストが選べる選択肢はつらいものばかり。仕方ないので事実をありのままに話して契約を反故にされるか、それともクライアントが分析料を支払ってくれると信じてひたすら最終レポートの提出をのらりくらりと引き延ばし続けるか、さもなくばそれとなーくクライアントが期待したような「何か」が見つかったかのように見えるようにデータをいじるか。。。


4. 上司からのヤバいプレッシャー


もし上司から「データをいじって俺が正しいことやってるって上層部から見えるようにしてくれよ」とか頼まれるようになったら、その仕事は辞め時ですな。


5. クライアントとのコミュニケーション(不全)


クライアントに対して、そのビジネス上の課題に対して答えを出すには何年にも渡ってキーとなる変数すらないような*2ペタバイト級のデータを蓄積する必要がある、と説明しなければならないとしたら? もしクライアント側の担当者が、ずっとデータ収集の責任者をやっている人だとしたら、これを言うのは難しいでしょうねぇ。。。


6. モデリング手法のジレンマ


Hadoopクラスタでも動くような超高速線形回帰アルゴリズムを使うか、それとも自分のデスクトップ上でしか動かないものすごく遅いニューラルネットを使うか、迷ったとしたら?


前者は全てのデータを有効活用できるけどありきたりの結果しか出ないし、一方で後者はすごく面白い結果が出そうだけど代わりにとんでもなく長い時間をかけてIT部門の人たちに「サンプリングすることのメリット」だの「最終的に中心極限定理に従う」だの説明しなければならないことになるわけで。。。


7. 日々進歩する専門用語に詳しくあり続けなければならない


新たに誕生する頻度表やら記述統計量やらにまつわる専門用語*3の全てに対してキャッチアップし続けるというのは大変なこと。


しかーし。Wikipediaという究極のサポートもあるし、それこそGoogle Scholarがあれば怖いものなし。それでもダメなら、自分で造語を勝手に作って置き換えてしまうか「うちの業界ではその用語には違う意味がありましてねー」とか言い訳すべし(笑)。


8. オープンソース縛り


そして最も面倒なのがオープンソース縛り。もちろん、動いてくれればいいんです。けれども最悪の場合、使い方覚えるためだけに何時間も費やすことも。それが例えばよく分からないメモリ制限のせいだったり、自分のデスクトップ環境でのみ起きる不具合だったり、何かが無限ループして永遠に処理が完了しなかったり。。。そう、金を払わなくて済んだ、ただそれだけなんですね。。。



・・・いやー、データサイエンティストって大変ですよね(棒)。でもまぁ、大体どこの現場もこんな感じだと思います。システム運用もやっていれば、これにさらに普通のSEの現場のあるあるも加わりますし、お疲れ様でございます。

*1:"torture"には「歪曲」と「拷問」の両方の意味があるので、ここは拷問して自白させるという下りとかけてるみたいですね

*2:つまりRDBMSに突っ込めない非構造化データの類かと

*3:ぶっちゃけ記述統計量絡みの用語なんてどれも難しくない気がしますが