Care and Feeding of Data Scientistsの備忘録。

2019年出版 OREILLY reportのデータサイエンスマネジメント（DS）についてのレポートを読んだのでまとめました。

DSチームマネジメントについて考えることが多くなってきましたので、以前チラッと読んだきりになっていたレポートを読み返しました。ついでに、チームメイトにも共有できるようにまとめてみました。

DSチーム創成：Your Mission, Should You Choose to Accept It.

DSの役割分類

• DSのタイプを分類することで、期待を明確にすることができる。（若い時や始めたばかりの時は固執する必要はない。）

Operational DS

• データを使って組織の意思決定を最適化し、ビジネス目標をより効果的に達成できるようにすることに重点を置く。

• 技術的な概念を非技術的なクライアントに伝えることに長けており、ビジネス目標をモデルや測定基準に反映させる手助けをする。

• アナリティクスやビジネスインテリジェンスと似通っているが、モデリングやエンジニアリングができることが特徴。

• クライアントは、社内の営業やマーケティングチームなどの社内ビジネス関係者が多い。

Product-Focused DS

• データサイエ ンスや機械学習を使って製品の価値を高めるために、製品そのものに組み込まれた仕事（ex リコメンドエンジンの構築など）をする。

• ビジネスに精通し、マクロ的な企業目標を念頭に置く。加えて、技術的なスキルも要求される。

• クライアントは、ユーザーが中心となる。

Engineering DS

• プロダクトDSやオペレーショナルデータDSの仕事を支えるシステムを構築し、維持する。

• プロダクションコードと機械学習システムを円滑かつ効率的に実行し、データセットを大規模に処理 ・分析し、データ集約的な問題を解決する。→ 市場では、機械学習エンジニアやDSエンジニアとなっていく。

• 技術的なプロジェクト管理能力とリーダーシップ、そしてコードレビュー能力が必須。

Research DS

• 純粋に研究的な役割を期待されている。

• 深層学習、コンピュータビジョン、自然言語処理などの分野で、最先端の技術を進歩させることだけを任務とし、その研究がすぐに会社に役立つという明確な期待は持っていない。

DSチーム編成

A centralized data science team

• DSがチームとして一元的に管理される。

• メリット

  • 強いアイデンティティ、プログラムの一貫性、知識の共有が可能になり、その結果、仕事への満足度が高まり、チーム文化が向上し、定着率も高くなる。

  • 外部チームからのリクエストに一元的に対応することで、会社全体が貴重なリソ ースを効率的に使用できる。

• デメリット

  • ビジネスの他の部分で解決しなければならない問題から遠く離れてしまい、横道に逸れたり、泥沼化しやすくなってしまう。

A fully distributed data science team

• DSが分散し、他のビジネスユニットやチームに組み込まれる。

• メリット

  • 現場での実際の作業に近くなり、重要なビジネスコンテキストと組織全体のニーズに対する認識を得ることができる。

• デメリット

  • 孤立とメンターシップの欠如を感じることもある。

A center-of-excellence model

• 上記の2つのチームモデルのハイブリット。

  • 中央のDSチームがベストプラクティスをプールしてアイデアを共有し、 DS自身は主に「出向」または機能チーム内に「任務として」組み込まれる。

小規模チームではA centralized DS team、中規模以上ではA fully distributed DS teamを検討するのが良い。実現できるのであれば、ハイブリットモデルがおすすめ。

DSチーム募集：How to Win Friends and Recruit Data Scientists.

DSの生態

• DSは、ミートアップに参加したり、地元の 大学でパネルディスカッションに登壇したり、カンファレンスで講演したりと、データ中心の場でのコミュニティ活動に集まる性質がある。

• DSは、学ぶことが好きで、 働きながら学び続けられるような場所で働きたいと思っている。

• DSは、オープンソースコミュニティや技術記事、ブログ記事、ポッドキャストなどで情報発信することで、内発的動機により集まってくる習性がある。

• DSは、自律性を重んじ、自分の仕事にどのように創造性を発揮できるかを知りたがる。

DSとの面接

よく聞かれる質問（質問→質問の意図）

• 会社の戦略は？DSチームがその戦略的に果たす役割は何か？
  → DSが組織にとって不可欠か、どれくらい中心的なものか、ビジョンが投資に値するものなのかについて問いかけ。

• DSチームが取り組むべきことは、どのよう に決めているのですか？今、あなたのチームが取り組むべき最優先のプロジェクトは何ですか？
  → DSが取り組んでいることについて、誰が指示を出しているのかについての問いかけ。
  → 明確な目標と自律性（クリエイティビティ）の両方のバランスについての問いかけ。

• DSは、どのように連携し、協働しているのでしょうか？
  → DSは孤独に陥りやすいので、実際に志を同じくする同僚とつながりや一緒に働けるかどうかについての問いかけ。

• オンボーディングはどのようなものですか？人事考課やキ ャリアパスはどのように行われるのですか？
  → DSは新しい分野であるため、キャリアアップに関する強い規範がなく、昇進には社内政治が必要と感じているケースが多い。その競争に巻き込まれないようにするために評価方法の一連の基準についての問いかけ。
  → 多様性の観点からの公正な評価への問いかけ。

• あなたのチームはどんなツールを使っていますか？あなたの技術スタックはどのようなものですか？
  → 組織が行うDS業務への問いかけ。
  → チームが必要とするコンピューティングリソースへのアクセス確保についての問いかけ。

チームフェーズと採用

チームを立ち上げた当初はできるだけ経験豊富な候補者を採用し、成長段階にはより若い候補者を採用。（経歴での分類もあったが割愛。）

DSチーム採用：Interview with the Data Scientist.

求人票は簡潔に。

• あなたとあなたの会社がDSの本質を理解し、その役割に現実的な期待を持っていることを納得させるもの。

• 知識、スキル、ディスポジション（気質、マインドセット）の3つのカテゴリーで整理する。

採用面接の一例。

• 具体的な質問をする。

• 技術的な評価は、実際の業務シーンと近くなるようにデザインする。

選択

採用基準のヒント（ぶっちゃけフェーズ依存。）

• チームの規模が小さい場合、データパイプラインの構築と、何を測定すべきかの検討にほとんどの時間を費やす。

• 基本的なインフラ（技術、プロセス、文化）が確立されたら、よりニッチなスキルが活躍できる。

• モデルやパイプラインの維持に時間を費やしたり、他の組織からの単発の質問に答えたりする割合が増え始めたら、それはジュニアDSに投資するサイン。

• 多様性。

オンボーディング

• 新しいDSに何を期待し、その期待に応えるために何をすべきかを、できる限り明確に示したもの。

  • 30日、90日オンボーディング（期間によって到達期待値が異なる。）

DSチームマネジメント：Fear and Loathing in Data Science.

FOMO

• ソーシャルメディア時代の典型的な感情であり 、今やっていることよりももっと楽しくてかっこいいことが 、世界のどこかで起こっているのではないかという不安な気持ちが腹の底にある状態。

  • ビジネスに実際に測定可能な影響を与えることに関心を持つDSを採用すること。

  • チームに継続的な学習を実践する機会を与えること。

Journal Club

• 興味深いジャーナル記事や技術ブログ記事を読み、それについて議論し、互いに説明し合う。ネタ帳や参考になるサイトを共有するのもあり。

DSチーム運用マネジメント：To Agile or Not to Agile.

• アジャイルマインドセットはDS業務に適しているが、アジャイルプロセスはDSの探索的創造性を奪いかねない。

• アジャイルの考え方をチームの運営の中心に近いところに置いておく。そして、ビジネスと密接に連携し 、変化するニーズに対応し、仕事をできるだけシンプルに保つことがDSチームマネジメントで重要。

アジャイル

• ウォーターフォール型ソフトウェア開発への対応として開発。

• チームは素早く反復し、可能な限り頻繁に動作するソフトウェアを公開し、利害関係者からのフィードバックや変更要求に早期かつ頻繁に対応。

• 厳格な形式によりタスクのチケット化が行われ、効率的に開発ができる。

• 概念やプロセスがDSの創造性とコンフリクトするとさえ思われる。（"アジャイルの哲学"の項目記載のコンセプトに立ち戻ることが必要）

アジャイルの哲学（コアコンセプト→DSチームへの転用）

Responding to change over following a plan

• やりながら学ぶ。
  → データが導くままに行動し、新しいアイデアを繰り返し探求する自由を持つ。

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• 数週間から数ヶ月の間で、より短い期間を優先して、実用的なソフトウェアを頻繁に提供すること。
  → できるだけ頻繁に中間進捗と結果をステークホルダーに示す。データサイエンス業務への賛同を得るには、段階的なプレゼンテーショ ンが不可欠。

Business people and developers must work together daily throughout the project.

• ビジネスパーソンと開発者が、プロジェクトを通じて日々協力し合うことが必要。
  → ビジネスと手を携えて、どのようにデータが生成され、どのようにモデルが使用され、どのようなプロジェクトが最も価値をもたらすかを理解する。

Simplicity—the art of maximizing the amount of work not done—is essential.

• シンプルであること、つまり、やらないことを最大化する技術が重要。
  → ディープラーニングモデルを構築するために6ヶ月間不在にする前に、単純なロジスティック回帰のベースラインを提供すること。

OKR

• 長期的なDSプロジェクトの調整方法としておすすめ。

• 組織が達成しようとする包括的な目標（Object）です。そして、「どのように」達成するか、つまり、目標達成までのマイルストーンや成果を示すのが「KR（キー・リザルト）」です。

• 目標は北極星（動かない目標）であり、主要な結果はその北極星に到達するための測定可能なステップ。

DSチームキャリア形成：Chutes and Career Ladders.

• DSの転職動機トップ2が『成長』と『キャリアアップ』。

• キャリアラダーは取扱説明書というより、ガイドブックのようなもの。

• 技術系と管理系の両方を用意することが重要。（優秀な技術系DSに、出世のために人を管理することを強要しても、誰も得をしない）

• 3つの重要な「足場」（仕事の技術的側面、チーム内外の組織的相互作用、仕事をする上での個人的特性）に分けて整理。

Technical Footholds

• キャリアの各段階でどのような種類の技術的スキルを習得することが期待されているか。

• T字型のDSというコンセプトがおすすめ。（広くやってから、掘っていく）

Organizational Footholds

• チームのメンバーがお互いに、また社内の他チームとどのように交流するかについて、期待を形成する。

Personal Footholds

• 仕事の進め方や心の習慣。

※ DS協会スキルチェックは参考になる。

まとめ

なんかエールみたいなのが記載されていました。

One thing to keep in mind as we leave you: a great data science team will challenge the person who manages it, almost by definition. The data scientists who you work with are people who have chosen a field that’s characterized by its impact, by its challenge to its practitioners, and by its possibility. Your job is to capture the best of that and use it to navigate new frontiers for your organization.