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

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

データサイエンティストの「真の実力」を測るための効果的な面接方法

f:id:TJO:20200915104214p:plain
(Image by neo tam from Pixabay)

最近こんな記事が出ていたようですが、僕にとっては既視感満載の話題でした。何故かというと、実は現職に来る以前に既にここで書かれている面接方法を実務担当者面接の責任者として実践していたからです。ちなみにその方法は2013年ぐらい当時のテック系メディアで記事として取り上げられていたものなのですが、残念なことに現在どれほど検索してもその記事が見つかりません……。

その内容自体はしばらく前に英語版Quoraに書いていたり*1もっと遡ればTwitterに書いたりしていたのですが、そう言えばブログには書いていなかったなと思い出したので、改めてブログ記事にしてみようと思います。なお、ここに書かれている内容は僕の現在の職務とは一切関係がないことを予めお断りしておきます。

データサイエンティストに必要なのは「解決する力」であって「瞬発力」ではない


冒頭の記事でも書かれているように、一般にデータサイエンティストの採用選考はソフトウェアエンジニアのそれに準ずる方法を取っているところが(特にUSでは)多いです。そうすると、どういう面接になるかというと

  1. ホワイトボードコーディング
  2. 統計学機械学習の知識を要求される頭脳クイズ

といったことを聞くものになりがちです。どちらもtech系有名企業各社では良く用いられる有名な面接スタイルですが、一応以下に説明を付しておきます。


一つ目は読んで字の如く、面接担当者から「〇〇を実現するコードを書きなさい」というお題だけを与えられて、ググったり何か資料を参照することなく、その場で自分の知識と技術だけを頼りにホワイトボードに回答のコードを手で書いていかなければならない*2というスタイルの面接方法です。ソフトウェアエンジニアだと平衡二分探索木の実装コードを書かされるなどのド定番問題が有名ですね。なおLeetCodeなどにtech系有名企業各社の問題が収録されていて、これをひたすら解いて覚えるというのがこれまた定番の面接対策です。データサイエンティストや機械学習エンジニアの面接だと、何かのデータと課題のコンセプトを与えられた上で*3、所与の課題を解決するためのコードをPythonやRでホワイトボードに書くというスタイルを取ることが多いようです。


二つ目は企業によってスタイルはまちまちなようですが、ソフトウェアエンジニア採用面接に準ずるスタイルだと結構頭脳パズルみたいな問題を口頭で出されて、面接担当者が納得するような回答を(当然ググったり何か資料を参照することなく)返さなければいけなかったりします。例えば「ある部屋に二酸化炭素濃度計が10個付いていて、それぞれバラバラの値を示しています。この部屋の正確な二酸化炭素濃度を求める方法を考えなさい」みたいな問題ですね。これを解くことによって、候補者は自分の統計学機械学習の知識がいかに確かなものであるかをアピールするというわけです。


ところが、ここまで読めば大半の方々にはお分かりかと思いますが、これらの面接方法で測れるのはどちらかというと「瞬発力」です。確かに、ソフトウェアエンジニアであればいちいちググったり資料を参照する前にさっさと迅速に目の前の課題を解決するコードが書けた方が良いのは事実ですし、そういった瞬発力を問われるのは自然なことだとは思います。


しかしながら、データサイエンティストや機械学習エンジニアで、特にシステム・ソフトウェア開発を直接担当していない場合、「その日のうちに迅速に」というような瞬発力を要するアプローチを求められることは少ないはずです。普通はデータの収集方法や得られたデータの概要や細かい性質、さらには用いる可能性のあるモデリング手法の特徴や相性などを吟味しながら、短くとも1-2週間ぐらいはかけてPoC・プロトタイプを実装し検証していくという流れを取るものだというのが、僕の業界経験に基づく理解です。


それこそ複雑な統計モデルや機械学習手法の詳細など分からないことがあれば、ググったり資料を参照して正確な知識を得た上で、コード実装なり検証なりを行うのが当たり前でしょう。また、見知らぬ部屋に予め設置された素性不明の二酸化炭素濃度計10個から得られたデータなんて信用せず、そもそものデータ収集方法から考え直すのが普通だと思います。非現実的なシチュエーションのもとでの「瞬発力」を試すことにどれほど意味があるのか、僕には分かりかねます。


むしろ、時間を惜しんで、一瞥して分かる範囲の取得済みデータに当てはまりそうな統計・機械学習モデルを恣意的に選んで実装&投入なんてしようものなら、デタラメな結果になった挙句レスキュー&サルベージにも莫大な手間がかかってしまうというのは、データ分析業界では典型的なあるあるパターンです。拙速を避けつつ適切なタイムスケジュールのもとである程度以上のクオリティを確保しながら「解決する力」こそが、現場のデータサイエンティストや機械学習エンジニアに求められる素養でしょう。

  • 実際の仕事で、ホワイトボード上にコードを書いたり、誰かが肩越しに覗いている状態で暗算を実行したりするといったことはあり得ない。業務中にインターネットアクセスを禁止されるなど理解しがたい
  • 実世界では、こうしたアルゴリズムを手で書くことは絶対にないし(通常はインターネット上で入手可能な無償のソリューションを使う)、仕事で遭遇する問題にパズルのようなトリッキーなものは滅多にない

と冒頭の記事では指摘していますが、全くもって同意見です。一説では、そういう「瞬発力」をあえて問うことで知能指数が高く潜在能力に期待できる人材を選別するという狙いもあるのだそうですが、ソフトウェアエンジニアならともかくデータサイエンティストや機械学習エンジニアにそのような選考をすることにどれほどの意味があるものかは、大いに疑問符がつくと思っています。


より現実のシーンに即したシチュエーションでの実力を見る


では、どうしたら「解決する力」を評価できるでしょうか? これについて僕がQuoraで書いたのが、以下の選考方法です。

  • 候補者に事前に解くべきデータセットとデータサイエンス的な課題を送り、面接当日までに1–2週間かけてそれを解いてもらう
  • 実際の面接の際は、候補者に自身のソリューションを構築した過程と、そのソリューションのデータセットに対するパフォーマンス(予測性能など)や得られた知見などを示してもらう

まず、データサイエンティストor機械学習エンジニアの候補者が実務担当者面接まで進んできた時点で、採用担当に依頼して候補者に事前にデータセットとそれに付随するデータサイエンス課題を送ります。その上で採用担当と調整して、大体1-2週間後に面接するようなスケジュールを設定し、候補者に面接当日までに取り組んでもらいます。その上で、面接当日は候補者にそのデータサイエンス課題を解く上で構築したソリューションを実装したコード類を見せてもらいながら説明を求め、さらにはこちらの手元に置いておいた正答(テスト)データセットと照合して候補者のソリューションのパフォーマンスの良し悪しを評価する、というものです。喩えて言えば「自社版ミニKaggleコンペ」を開催するようなものですね。


このやり方なら、そもそも1-2週間という一般的なデータ分析プロジェクトのタイムスケジュールに即した形で、候補者がどれくらいのパフォーマンスを出せるかを見ることができます。しかも、候補者は自宅含め「ホーム」の環境で課題に取り組めるわけで、当然ググって資料を探しても良く、手持ちの資料を参照することもできます。これによって純粋に「現実の職務環境でデータ分析に取り組んだ」場合と同じシチュエーションで候補者がどのように課題を解決してみせるかを評価できるというわけです。


冒頭でも触れた通り、僕はこのデータサイエンティスト選考方法を前職時代に実際に取り入れて実践していました。当時は「統計モデリング課題」としてマーケティング分析を求める課題と、「機械学習課題」として大規模データへの機械学習モデル構築&予測を求める課題の2種類を用意して、候補者に好きな方を選んで取り組んでもらうという方式を取っていました。


これが実に効果覿面で、統計学機械学習の知識が不完全な人だと本当に「いやいくら何でもそれは分かっていませんよね」という回答を持ってくるので、面接当日はその回答から得られた印象が強まるか逆に払拭されるかを口頭での面接を通じて探れば良いだけでした。もっとも大半は悪い印象が強まるだけで終わりましたが……。一方で、優れた回答&テストデータへのパフォーマンスを持ってくる人だと、口頭での面接を通じて「この人は統計学機械学習にも良く通じていて優秀だ」という印象がどんどん強まっていくことが多く、面接していても非常に面白かったです。


なお、当時機械学習課題で最も優れたパフォーマンスを叩き出した候補者の方には当然オファーを出したんですが、非常に優秀な方だったので他の競合他社に好待遇で掻っ攫われていってしまいましたとさ(笑)。


最後に


多分なんですが、洋の東西を問わず結構な数の企業が今でも「採用面接では『頭の良い』候補者を採りたい」と考えているのではないかなと、今回のブログ記事をまとめていて改めて思った次第です。実際、外資のコンサルや金融機関などではいわゆるフェルミ推定の問題を口頭で課すところが多いと聞きますが*4、その狙いはやはり「頭の良さ」とその「瞬発力」を測りたいからということのようです。


しかしながら、ソフトウェアエンジニアや戦略コンサルならともかく、統計分析や機械学習を実社会に適用する実務データ分析の世界で必要な能力は、頭脳パズルをその場でパッパッと解けるような瞬発的な「頭の良さ」とは限らない*5、と過去8年のデータ分析業界経験からは感じています。むしろ、課題を解決するために必要なデータ・環境・手法・組織管理といった複雑に絡み合う材料たちを、拙速を避けつつ適切に決められたタイムスケジュールのもとで組み上げる、いわば「論理性」と「熟考できる力」こそが重要なのではないでしょうか。


これらを僕は総称して「解決する力」と呼んでみたわけですが、もしかしたらもうちょっと良いまとめ方・括り方があるかもしれません。そこについてはまた稿を改めて論じてみようかと思います。

*1:自分で日本語版への翻訳記事も書いています

*2:リモートだとGoogle Docsなどの共有文書にその場でtypeしていくみたいなやり方もある

*3:具体的でない部分は面接担当者に直接口頭で要件を聞き出していって自分でまとめるという作業が要る

*4:実は5年前の転職活動で外資の金融機関を受けた時にフェルミ推定をやらされたことがある

*5:不要だとは言わないが重要だとも思わない