データサイエンティストチームをどう作って維持していくかについての本を読んだ（要約）
「The Care and Feeding of Data Scientists. How to Build, Manage, and Retain a Data Science Team」を読んだ
データサイエンティストをどうチームに迎え入れてマネジメントするのかが書かれた書籍。データサイエンティストへのアンケートでは前職の在籍期間が1~2年と短いことが多く、継続的に価値を出し続けてもらうことが難しいことを物語っているという。採用の方法まで書いてある。https://t.co/mYXFTSDkcO
— piqcy (@icoxfog417) 2019年9月21日
私はマネージャーじゃないが、
- 自分のことをマネジメントするためにどう意識したらいいか
- マネージャーがこれをベースにマネジメントをしようとする、という前提で考えることで、マネージャーがどういうことを求めているか（なにをしたら評価されるか）を把握
という観点で読んだ。
以下は後で読み返すときようにChapter毎に何が書いているかのメモ（要約）。
Chapter1:Your Mission, Should You Choose to Accept it
データサイエンティスト(以下DS)の種別を定義ことでどういうことをする人なのかということを理解させ、これをベースにどうフォローしていくか、何で評価していくかといったことが書いている。
種別
説明しやすいのでよく聞く「DSに必要な3つのスキル要素」みたいなのを踏まえて読むとイメージしやすいかも？
Operational Data Scientists
ビジネスにおける意思決定に貢献する人。
ビジネスにおけるステークホルダーとコミュニケーションするのが重要なのでコミュ力が重要。また、非エンジニアとエンジニアを結ぶような翻訳者的な立ち位置でもある。
アナリストと似ているけれど、エンジニアリングやモデリングができるかが差異。
基本的に外部よりも社内の人向けの部署で、営業やマーケティングチームがクライアントとなる。
Product-Focused Data Scientists
プロダクトの開発部署と主にやりとりをする。
アプリのレコメンドみたいな、プロダクトにおける機械学習の実装をするイメージ。
Engineering Data Scientists
プロダクトや機械学習システムに使うデータを整備する仕事。
Research Data Scientists
R&D職。研究などをおこなって会社自体に貢献をする。
ビジネスに紐付いているというよりももうちょっとマクロな視点での分析？
どういうチームにしていくか
DSチームは、DSチームで固まるべきか、上記役割に近い別チーム(Operational Data Scientistsなら営業やマーケター、Product-Focused Data Scientistsなら開発チーム）のそばにそれぞれ座るのか、どちらの方がいいか。
A centralized data science team
DSチームで固まる場合。
メリットは、チームを結束させて新規プロジェクトや手法を試しやすくなるので、満足度が高くなる。
そのため、チーム文化が定着し離職率も下がる。
また、タスク自体をマネージャーが一元管理して割り振りをするので効率的な仕事の割り振りができる。
デメリットは、各種別に近い別チームとの意思疎通が低下するので種別毎でのタスクの達成度が下がること。
A fully distributed data science team
種別の役割に近い別チームのそばに座ってDSチームが分散する場合。
メリットは、各種別のタスクを達成しやすくなると同時に、別チームからDSの仕事の認知度が上がること（こういうことを知りたい→DSチームに振ってみよう、みたいな流れが起きる）。
デメリットとは、手法などのアドバイスが貰いづらくなるしチーム感がなくなるため満足度が下がり、離職率が上がること。
A center-of-excellence model
上記2つのやり方を融合させる。
基本的には、種別の役割に近い別チームのそばに座り、別チームのようにMTGなどに参加をさせるが、定期的にナレッジシェアをおこなう機会を作る。
(メルカリとかはまさにそういうチームのやり方すね。)
この融合のバランスは、チーム規模によって変えていく必要がある。
まだ人が少ないときは前者寄りがいいし、増えてきたら後者寄りにした方がよさげ。
Chapter2:How to Win Friends and Recruit Data Scientists
面接でよく聞かれること（回答を考えておくべきこと）
DSが気になりがちなこと。逆に考えると、質問の背景にある意図にちゃんと答えれるようにすることが良い組織(チーム）作りにつながるのでそういう組織にしていくべき。
会社のミッションしたいことにおける、DSの立ち位置は？
- ビジョンを示すことで惹きつける
- 仕事へのやりがい
作業内容をどうやって決めてる？今やってる最優先のタスクは？
DSチーム同士での共同作業はある？
貢献度への評価基準と、キャリアパスはどうなっている？
- 実力をどのように示したらいいか
- 社内政治に振り回されないか
- 詳細は6章
なんのツール使ってる？
いつどこでだれをどうやって採用するか
採用する場所で候補者の質は変わる。経験者は希少なので頑張って能動的に動かないと見つけられない。
チーム文化や成果物やワークフローのフォーマットを作成していくいつようがあるので、初期は経験者を採用する。
段階的にポテンシャル採用をしていき、経験者をメンターとしてつかせることで成長させる。なお、ここでメンターがいない（学習させてもらえるような自分より強い人）場合は辞められる可能性が高いので注意。
採用者がどういうバックグラウンドがあるかは、組織に入ってからいくらでも変えれるのであまり気にしなくてもいいが、以下のような長所短所がある。
アカデミック出身（博士以上？）
長所：データサイエンス力が強い 短所：ビジネスに適切な手法を適用させる力やスピード感の欠如
DSブートキャンプ修了とかのちょっとかじった人
長所：表面的な理解な可能性が高いが色々知ってる。意欲的。 短所：表面的な理解ゆえに、どうやって使うかが微妙
エンジニアからの職種転換
長所：エンジニアリング力が強い。エンジニア的な発想（保守やプロジェクトにおける効率的な方法など） 短所：統計力やビジネスへの問題定義力
データアナリスト
長所：ビジネス理解と問題定義力、コミュニケーション力 短所：エンジニアリング力
Chapter3:Interview with the Data Scientist
どういう人を採用していくかは、知識（本に書いているようなこと）・スキル（何ができるか：過去の経歴ベース？）・性格（態度、考え方、うまくいかないときどうしていくかなど）それぞれについて考えていくのが募集要項の定義を整理していきやすい。
インタビュー
ホワイトボードを使わせたり、github見たり、持ち帰り課題を出したり、と色々な評価方法があるがやり方によってはそれぞれ短所がある。そのため、短所を回避する方法として、質問形式のインタビューをすることで候補者を見ることを推奨する。
基本的に、実際仕事をおこなっているときを想定したインタビューの仕方をする。
例えば、好奇心と学習に関する気質を判断するには、「自分で新しいことをどのように学びますか」ではなく「自分で何かを学ばなければならなかったときどうしたか」について候補者に尋ねる。
どういう人を採用するか
チームの段階による。初めの方は色々な整備ができる人を雇うべきだし、色々と整備が済んだら高度なスキル持ちだったりニッチな技術を持つ人を採用するべき。
後者に関しては、チーム内でのやりとりに着目するとどういう人が必要か見えてくる。
採用後
キャリアプランやタスクなどをはっきりさせ、スキルギャップなどは90日オンボーディング形式で学習させていく。 (入社後の新入社員研修のようなものでオンボーディングという新しい概念がある。また、そのための90日プランを90-Day Onboarding Planというらしい)
このとき特に、メンターによるペアレビューや、1on1、パフォーマンスレビューなどを通して定期的にフィードバックを返していくことが大事。
Chapter4：Fear and Loathing in Data Science
DSの離職を防ぎ、メンバーの保持のためにはどうすればいいか。
離職する理由の4割は、簡単な仕事ばかりやらざるを得ない、といったように、やりがいのある仕事/学習機会を得られないような仕事ばかりやらされていることが原因となる。
端的にいえば、FOMO(Fear of missing out:取り残される不安・恐怖というSNS社会での現代病)。つまり、他の人達は素晴らしいプロジェクトによって学習していっているのに自分は糞みたいな仕事をしていて業界的に取り残されるのではないかという恐怖から転職していく。
対策としては、最新の手法やツールを使うことにこだわるのではなく、ビジネスにおいてなにが必要十分化を見極められる人を採用することが秘訣となる（例えば、簡単な手法でもビジネス的には十分なのに、工数をさいて最新手法をむりやり使おうとするような人ではない）。
このことは、アカデミック出身の人が特に陥りがちなのでそのあたりの指導は常に意識的におこなうべき。
ただし、何かしらの方法で継続的な（最新手法などへの）学習機会を与えスキルアップをさせるべき。
ジャーナルクラブ
例えば、昼休みなどにアンオフィシャルに、気になったブログ記事や論文などを発表するジャーナルクラブを作るのが良い。また、これは誰でも聞けるようにすることで副次的に他部署の人の学習などにもなる。
このクラブの存在を通すことで、「このチームにおいて、学習していき、それを皆に共有していくことは重要だ」という文化を伝える。
また、些末な質問をあえておこなっていくことで、心理的安全性を確保しよう。
また、クラブではなくPyDataのようなカンファレンスをみんなで視聴するMOVIE NIGHTを開催するのもよい。
HACK TIME
知識に対する投資として、HACK TIMEのための時間を確保する。
Googleの「20%ルール」が有名だが、DSのような仕事だと1日のうちの20%(1.5hくらい)はあまりやれることがない。
そのため、1週間の丸々を自分の気になっている技術やプロダクト、会社データを使った何かをやる時間を個々で設定する。
ただし、ちゃんと機能しつつ会社に承認を貰うために、アウトプットや再現性を踏まえた計画をちゃんと立てる必要がある。
その他
外部イベントで発表させろ。
Chapter5：To Agile or Not to Agile
DSチームとアジャイル哲学（≠アジャイル開発）は相性がいい。
（あんまりちゃんと読んでないから省略。要は、かっちり型にハメなくてもいいが、ある程度のスプリント計画を立て、スプリント毎に成果物を発表する、という哲学を使っていくことでワークフローの見える化と、タスクに対する他の人からのフィードバック、あるタスクのみやりすぎるみたいなことが防げる的な話か？）
また、そもそも何をやるか？という共通したガイダンスとしてOKRを使うと運用をしやすい。
Chapter6：Chutes and Career Ladders
良い仕事をすれば良いキャリアになる・・・というわけではない。
DSの半数以上が、成長とキャリアの向上を理由に転職をする。そのため、この先のキャリアとしてどういうことが待っていて、そのためには何をすべきかという梯子(Ladders）を明確にする必要がある。
各ポジション毎の必要要項はP39~43の表を参照。また、マネジメントとしてのキャリアはP44~45。
雑感
ここに書いていることをマネージャーがやっている組織は良い組織となる。仮にマネージャーがやっていない場合は自分で能動的にここに書いているようなことをマネージャーに提案することで自分で自分のために良い組織を作っていく、という風に考えたい。
