読者です 読者をやめる 読者になる 読者になる

歩いたら休め

If the implementation is easy to explain, it may be a good idea.

【雑記】データエンジニア・サバイバルガイド

この間、久しぶりにある優秀な先輩に会い、いろいろと話をする機会がありました。

以前短い期間でしたが一緒に仕事をする機会があり、その際に基本的な統計プログラミングや仕事で気をつけるべき点(闇)についていろいろ教えていただいた方です。「お前はもう少しいろいろできるはずだから気張れ」とケツを叩かれつつ、今の仕事について考えていることを共有していただけました。

(そのとき食べていたのがおいしい中華料理で、妙に辛い肉と紹興酒のせいで次の日お腹を壊してしまいました。)

特にデータ分析者やエンジニアに限らない話も多いですが、そこで話した内容を自分の解釈でまとめておきます。

自分のアウトプットに責任を持たない人を信用するな

企業で働くエンジニアは「どれだけビジネスの役に立ったか」で価値が決まります。

インフラエンジニアなら「可能な限りサービスを止めないこと」、アプリケーションエンジニアなら「新しいサービスを使ってもらうこと」が価値であるのと同じように、データに関わるエンジニアなら「データを正しく活用してビジネスを加速させること」が価値であって、「データ集計・分析を行うこと」で終わりはありません。

先輩は「コンサルティング会社に依頼した日次の売上予測のコードが、(精度はそれなりに良いけど)実行に数時間かかって運用できないから結局自分で全部作り直したよHAHAHA」って言ってました。

(逆に言うと、ある人が信頼できるかどうかを判断するには、エンジニア以外でも、「その人のコード(成果)がちゃんと運用されて役に立っているか」を見ればいい気がしています。また、他人からそれを見られていることも逆に意識しないといけないでしょう。)

自分の成果に責任を持たない人(例えばコードを渡してハイ終わりという立場の人)は、そのコードが今後も運用され続けることを考えないため、とりあえず動かすために平気で例外処理を握りつぶしたり、プログラムの可読性や汎用性を考えません。

コードを自分で書け

自分のアウトプットに責任を持つようにすると、BIツールより、汎用的なプログラミング言語やシステムも使いたくなります。

例えば、もっと多くのデータに適用したり、バッチ処理として自動化したくなると、あらかじめパッケージングされているものより、自分で作って応用先を変えられるもののほうが、結果的には細かいニーズに応えられるでしょう。

ただし、それを行うには、重回帰分析を行う際に多重共線性に気をつけつつ、データ抽出のために負荷の小さいSQLを書くよう気を遣いながら、微妙なR言語のプログラムをメモリを食いつぶさないようにリファクタリングしているうちに、なぜかデータ分析用のサーバー運用まで任されるようになってしまうため、より多くの分野を学び続ける必要があります。

そのため、「評価する(上司や会社)側の立場が、エンジニアのスキルの有無や成果を正しく評価するのは難しいだろうな」と思っています。

会社の外と繋がりを持て

それは、この分野のほとんどのエンジニアや分析者にとって今のところ「ロールモデルとなる人がいない」からです(少なくとも日本では)。

ある優秀な同僚は「論文や最新の記事を読めば必要な情報が集まるから外の繋がりはいいや」と言っていましたが、自分が力を入れるべき分野や、自分自身のキャリアを考えるとき、自分に近い分野の人の考え方を知っておく必要があると思います。

また、会社によって前提になっている技術や文化が違う場合も多いです。 (少し)私の今の仕事では、ほとんどの箇所をRubyで書いている(汎用的な一つの言語で統一しようという思想)ので、場所によっては静的型の言語で厳密に書きたいなあと思うこともあります。

ただ、同じような仕事でも、「得意なものを得意な言語に任せる」という思想もありえます(例えば基本的にはJavaで、分析的なコードだけPythonで書くなど)。そういう話を会社の外の人とすると、気付かされることも多いです。

縄張り意識に気をつけろ

「もうちょっとこういうデータの分析や活用ができるんじゃないか」と思うと、どうしても組織の壁や、既にその仕事をやっている人がいるがイケてないもの(例えば自動化できる仕事を自動化できていない、など)にぶつかります。

まずは、ワインバーグの『スーパーエンジニアへの道』に書いてある「問題ない症候群 (No Problem Syndorome)」に陥らないようにしましょう。 これは「対応する問題を深く理解することなく、××という技術さえ導入すれば問題ない」と主張してしまうことです。多かれ少なかれ(自分でも他人でも)身に覚えがあると思います。

要するに、関係部署にヒアリングや、データの調査(例えばログデータが数日間途切れていたのに、誰も気づいていないということも多々あります)の手間を惜しんではいけません。

スーパーエンジニアへの道―技術リーダーシップの人間学

スーパーエンジニアへの道―技術リーダーシップの人間学

たぶん、ほとんどの人は「自分は無能だ/悪人だ」と認識するのを嫌がります。私も嫌で「自分は有能で、他人の役に立っている」と思いたいです。

そのため「××さえ導入すればものすごく楽になるのに、なんでやらないの?バカじゃね?」という態度でいるのはやめましょう。 大抵はどこか間違ってますし、万が一その通りだとしても相手は反発し、自分の仕事の成果が出なくなるでしょう。

組織構造も重要である

基本的に、データ分析を行う人は「ある程度規模が大きくデータが揃っている組織」に必要とされているのに「複数のスキルや複数の部署の仕事に跨った仕事をするベンチャー精神(?)」が必要であるため、ある程度大変なことはすぐにわかると思います。

そのため、組織構造も(おそらく)重要なはずなのですが、「どういうふうにデータ分析チームをマネジメントすればいいか」というノウハウも、ここ1~2年でようやく少しずつ見かけるようになった程度です。(例えば@tokorotenさんの以下の資料などです)

また、その先輩は「いろいろな会社を見たが、データ分析者の立場や仕事のやり方は、最初に分析の基盤やノウハウを作った人の思想を受け継いでいる」と言っていました。

www.slideshare.net

これからの世代は自分より優秀だ

実は、日本の大学に「統計学」専門の学部がなく、データサイエンス(と呼べそうな)分野を専門的に学んだ人はそう多くはありません。 しかし、日本国内でもそういう機関を充実させる動きはあり、例えば滋賀大学が2017年4月から「データサイエンス学部」が産まれます。

(私自身は、コンピュータサイエンスやデータサイエンス(と呼べる分野)を専門的に学んだことがありません。私のように、WEB企業で働いていて、近い仕事をしている人の中にも、今はそういう人が多い気がします。)

diamond.jp

統計学といえば日本では長らく、経済学部や工学部の一部(学科ですらない!)という位置づけにありました。しかし遂に日本で初めて、独立した“統計学部”が登場します。その名も「データサイエンス学部」。

ということを私から見ると一枚も二枚も上手な先輩でも話していました。「海外のエンジニアと比べると、モデル自体の精度みたいなところで勝負するのは難しいから、他の強みを持っておいたほうがいい」とも。

5年後や10年後の未来には、おそらく自分より遥かに優秀な後輩と仕事をすることになるでしょう。そのときにどこで勝負すべきか考えておく必要がありそうです。