筋の良さ・人柄・仕事への姿勢は、教えることができない

備前光隆氏(以下、備前):今の話で言うと、「採用で未経験者はどういうところを見てますか」とかどうですか。どこを見ていますか?

樫田光氏(以下、樫田):それこそ、備前さんが答えた方がいいんじゃないですか? 僕は中途入社なんで(笑)。

備前:当社はだいぶ色合いが違うかもしれないんですけど、新卒の採用基準にしても、素直でいいやつを取りなさいという方針があります。やっぱりそれは一理あるかなと思っています。

先ほど樫田さんもおっしゃっていましたが、筋のいい・悪いや、人柄や仕事に取り組む姿勢を、僕はすごく重視しています。そういうところは、教えてあげられないんですよね。

SQLとかそういう手先の器用さは、勉強してやらせたら、それなりに身についていくものではあるんですが、人格や人間力は、組織・チームで仕事をする以上はすごく大事な要素になっている。それさえあれば、もう手先の器用さなんかあとで学べばいい、とけっこう割り切っていますね。

鉄本環氏(以下、鉄本):うちもけっこう似たようなところがあって、ミッション、ビジョンへの共感をかなり押し出しています。

うちは事業会社で1つのサービスというのもあるかもしれないんですけど、会社やサービスが目指しているところへの共感があれば、自ずと、自分に必要なものに対して動けるようになると思っています。

手先のスキルや、そういったものはいくらでもあとからつけられます。でも、自分で考えて何か新しいことをやろうというのは、会社の向かっている方向に対して共感があるかどうか、というのがないと、違った方向に動いていってしまうということもあり得る。ミッションへの共感はとても重視しています。

各社共通するのは「データ活用による意思決定」

備前:ちなみに、鉄本さんの部門のミッションは何かあるんですか? 共通言語として、「僕たち・私たちの部門は、こういうことをやる部門だよ」ということや、ミッションやビジョンといったものは言語化されていますか?

鉄本:データチームに関しては、「データを活用して意思決定に携わる」というところを見ていますね。

備前:けっこうそこは各社共通ですかね。言葉尻の違いはあれど、同じようなかたちなんですかね。

鉄本:意思決定はわりと、共通ワードでけっこう出てくるワードという認識がありますね。

備前:そうですね。ありがとうございます。牟田さんは何かありますか?

牟田博和氏(以下、牟田):我々は最初のほうでも申し上げたように、特徴としてデータが大きくて複雑だというところがあるので、基礎的な統計は、少なくとも入社したあとで勉強してほしいとは思っているんですね。

なので、その辺の(数理系の)素養はそれなりには重視しています。その他は、実際に面接でどういうことをやっているかという話を通して回答します。面接のときに、いわゆるケース面接をよくやっています。

コンサルでやっているようなフェルミ推定のようなものではなくて、「こういうときにどう分析しますか」というのをシチュエーションを変えていくつもやります。「この人は数字でものごとを考えられる人だな」「自分がこうやりたいという主体性がある人かな」というようなところを見ています。

現場主導でつくる採用のフレーム

備前:たしかに事前の打ち合わせでも、やっぱりLINEさんはその辺が一番厳しそうですよね。狭き門というか。採用のフレームは、人事主導で作ったのか、それとも牟田さんが主導で作られたんですか?

牟田:私とチームの同僚で作りました。

備前:そうなんだ。なんか外資系のエンジニア採用みたいですね(笑)。コードがこれをクリアしないとだめみたいな。

牟田:そうですね。厳しめに見ていると言われると、もしかしたらそうなのかもしれないです。というのも今は事業の数に対して人がぜんぜん足りない状況で、それぞれの方にはリーダーになってほしい。だから、厳しめに見ているということです。もうちょっと人が増えると、もしかしたら変わるかもしれないとは思います。

1個言うのを忘れていたんですが、実はデータ分析チームは我々以外のところにもあって、その辺を今、整備しようとは思っています。我々はData Labsという組織で、会社全体を横串で見るデータ専門組織の中の分析チームです。

実は、事業部がそれぞれの判断でアナリストの採用を進めているところもあります。データ活用の意識が高いチームが進んでやっているという状況なんです。そこではちょっと違うスキルセットの人材を求めています。採用の一本化や分析体制の整備は、今まさにがんばってやっているところです。

ナレッジ活用のベストプラクティス

備前:ありがとうございます。けっこう時間も限られてきました。あと15分なんですが、お題を変えまして、仕組み化で工夫していることや、ナレッジの蓄積・活用・一般化が気になっているという方が、けっこう多いです。まずは実務的なところからいきましょうか。

「クエリの管理方法を知りたいです。昔こういうクエリをやったから、これを見てという流れを作りたいけれども、どういうことをしていくべきなんでしょうか」。これは、普通にクエリを管理していますよね。

鉄本:そうですね。うちはレビューとかもしやすいので、Git(注:GitHub)を使っています。ただ、本当に簡単なアドホックのものだと、Redashにそのまま登録してしまうので、Git化しないものもあります。けっこう何回も使うものや重要なものを(Git化します)。

備前:あと、ベースの定義のところとか。

鉄本:そうですね、ベースとして利用するものはGit、アドホックのものはRedashっていうかたちで(管理しています)。

樫田:うちも同じくGitを使ってます。クエリレシピというディレクトリを作って、そこに必要なものとして意識的にためていくっていう感じです。

鉄本さんと同じで、アドホックなものに関しては、そこにちゃんとコミットされるいうよりは、スプレッドシートや、アウトプットのWikiのほうにペタッと貼られるということがけっこう多いかな。

クエリを貯めてさらにそれを再活用する仕組みをがんばってはいます。例えば、Slackからコマンドで「/query_search sales」と打つと、salesというキーワードが入っているクエリがSlack上でバッと返ってくるようにやってはいます。

クエリを投入してくれる人は思った以上に多くはないので、もっと簡単な仕組み、走らせたクエリの中で、本当にワンボタンでそれをためられるようにするとか、もしくは全部一旦ためてしまって、それをうまく機械的に抽出して必要なものだけぶち込むとか、という仕組みにしないとだめかなと思っています。

話としては難しいかなとは思っているんですけど、ありとあらゆる場面に対応したいというレベルのニーズを1回下げれば、一番ベーシックなもの、ちょっと変えればOKというものを、Gitで管理するというのが今のところはベストプラクティスなんですかね。

アナリストが全員Gitを使えるわけじゃないという問題

牟田:私たちのチームにルールはあまりないんですが、設立当初からの数少ないルールがまさにその話です。分析レポートをいつもWikiで作るんですが、分析レポートに紐づける形で、分析に使ったSQLクエリやRスクリプトを必ず管理してください、というルールにしています。

分析レポートに紐づけてやると、なにがいいかというと、再現性が必ず担保できますよね。だから、そこをすごく重要視しています。

さっきの教育の話にも繋がってくるんですが、こういうクエリを流したらこういう結果が出て、こういう考察ができるんだというのが一連の流れでわかると、それを見るだけで、先人の肩の上に立てる。そういったことを意識していますね。

ただし、同じようなクエリがいろんなところに保管されているという状況があるのは課題で、何とかならないかなというのはすごく思ってます。

備前:各社とも、自分たちのチーム以外の人たちも、そこのWikiにアクセスして勝手にクエリを回すという感じになっていますね。

牟田:それに近い状況にはなりそうですね。

樫田:ちなみに今、追加質問で、「アナリストが全員Gitを使えるわけじゃない問題」という感じのがありまして。うちの会社は普通にWeb GUIで編集するというか貼り付けて、セーブして終わっています。

クエリレシピのディレクトリに関しては、プッシュもコミットもせずに、直書きだけするというのもOKにしています。それはドキュメントを書く感覚とは変わらないのかな、というぐらいで使っていますね。