データサイエンティストのデータサイエンス以外のスキル面について考えた
本記事は、所属しているグループのAdvent Calenderです。
で、お前誰
TVの視聴データを扱う会社でデータサイエンティスト(以下DS)をしてます。
31歳院卒。1社目は2年半ほどいてダッシュボードを作ったり、社内データ利活用のための簡易分析や分析設計をおこなったりしてました。
2社目(現職)でははじめの1,2年はひたすらデータ抽出でSQL書きまくったり、ほぼrawデータなDBを使いやすくするためのデータマートの草案作った（実装自体はインフラの人がやった）りデータ周りのことを色々としてました。
ここ1,2年はデータ分析案件で分析をやったり、PM/PLをやったりしてます。
どういう会社観点か
一般的にDSの所属する会社は、分析受託会社か社内データの分析かの2つに分かれるかと思います。
1社目はSES会社だったのではじめの半年は受託での分析(というかダッシュボード作成)、それ以降はずっと同じ会社に常駐で、常駐先社内データの分析をしていました。
現職ではずっと社内データの分析(とその周辺)です。
厳密には、現職はデータカンパニーなので自社データをクライアントに販売するにあたっての研究や、クライアントからKPIデータなどを頂戴してそのデータと自社データをかけあわせた分析をおこなっています。
記事を書く目的と背景
前述のように、ここ1年は分析自体もやりつつ、PM/PLをやったりしてます。
そのため、チームマネジメントや教育をし始めたり、クライアントとのやりとりや分析結果報告をする機会が増えました。また、チームのメンバーが増えたり、チーム(≒部署)のマネージャー(管理職)的なキャリアも意識するようになりました。
さらに、最近ちょくちょく聞く話ではありますが 分析結果を皆が使える/使おうとする状態にする ためにどうしたらいいかも意識するようになりました。
要するに、分析だけ考えるわけにはいかないという状態。
エンジニア界隈でもよく議論がありますが、DSも一般的にデータサイエンス以外のスキルが必要不可欠だと思いました。
そのため、主に以下のスキルについて今年は意識をしたのでそれぞれについてなんとなく考えたことや、そのために学習した書籍を紹介しつつ書きます。
- PM/PL
- 分析結果報告
- チームマネジメントについて
- 分析結果をどうするか
ただし、DSに限ったスキルではない「スキルそのもの」の説明詳細は割愛しつつ、気になる方は書籍や記事を読んでねスタイルで書きます。
PM/PL
プロジェクトの進め方
分析案件は結局結果を出す→その結果を踏まえて別のやり方を試したり深堀りをする、といったようにはじめからカッチリと要件を決めていくことは難しいです。
そのため、昔からCRISP-DMとよばれるフレームワークがよく使われているようです。
DS案件は工数の不確実性が高いためか、不確実性を考慮したエンジニアの開発手法であるアジャイル開発的な手法と相性がよいのでは？(CRISP-DMもアジャイルに近い）という話が色々なところでされているので、いい感じにプロジェクトを進めていくにあたりアジャイル開発について学ぶ必要を感じました。
書籍としては、以下の本がストーリー形式なので全体の流れや実際のイメージを把握しやすかったです。
そして、細かい部分やアジャイルの哲学として次には以下の本で1冊目の肉付けをしていきました。
- 作者:Jonathan Rasmusson
- 発売日: 2011/07/16
- メディア: 単行本（ソフトカバー）
ただし、一般的なアジャイル開発はエンジニアに対する話なので適宜DS向けに修正する必要があり、それについては以下の記事で書きました。
また、そもそもどういった形でアウトプットを出すのか、という点ははじめにちゃんと設計をした方がいいです。
例えば、機械学習モデルだと「どういう精度ならよいか」をはじめに決めたり、分析ならば「どういう形が利用者に使いやすいか」などがそれに当たります。
そのあたりは以下の本が非常に参考になりました。
なお、機械学習系の進め方の個人的なテンプレは過去以下にまとめました。
どういった手法を使うか
分析には色々なアプローチがあります。ではその中でどのアプローチを選ぶか、となると 手元のデータにはどういう特性があるか によって決まります。
何故、特性を調べる必要があるかというと、特性によって使えるモデルが変わるからです。世の中の様々なモデルやアルゴリズムには ある一定の仮定のもとで使える といった制限があります。また、 こういった条件でも使えるためにこのモデルが作成された という背景があります。
つまり、 データの特性を知ることでおのずとどのモデルを使えるか（どのモデルが使えなくなるか）。ということがわかります。
そのため、 xxを知るためのアプローチ = これだ！ みたいな考え方ではなく 、 xxを知るにあたり、データがこうなっている。こういうデータでもカバーできる特性を持ったモデルだとこれだ！ のような決め方が基本となります。
そうなると、各モデルにはどういう仮定が置かれているか・どういった欠点があるか、ということを把握しておく必要があります。
(ちなみにそのあたりについて作成したスライドが以下です。)
なお、これは統計モデル系ではよくある話ですが、機械学習系のモデル（アルゴリズム？）でも同様のことがいえます。
例えば、そもそも機械学習ではtrain, testが同じような特徴量分布をしているという前提が置かれているので、仮にそうなってなかった場合はAdversalial Varidationしようねとか、Random Forestは決定木の特徴としてtrainしたデータの範囲内の出力しかされないから時系列系でトレンドが乗ると上手く使えないとかそういった点です。
つまり、なんとなく勉強をするのではなく、「似た手法のxxxと何が違うのか」「どういった欠点があるのか」「どういった仮定をおいているのか」を意識して勉強をしていく必要があります。
まぁこのあたりは意識的に自分に問わないと「知っていないことを認識していない」ため結構難しいところです。以下の記事では「採用時にDSがちゃんと各手法を理解しているのか」を把握するためのよくある質問集とのことなので、質問に答えれるようにしていくと「知っていないことを認識」しやすいのではないかと感じます。
また、手法そのものの学習の際は挙動を図示しながら学習すると根底のロジックを理解しやすいです。以下のYoutube channelは図示が多いので理解しやすく、応用を効かせやすいように感じます。
ドメイン知識
どうやって要件定義をするのか、という部分でよく「ドメイン知識がないと現場とズレた分析になる」という話があります。じゃあどうやってドメイン知識を得ていくのか、ということはDSの永遠の課題ではあると思います。
一般的には「現場の声を聞こう！」ということが言われたりしています。弊社の場合は、現場＝他社なので他社にいちいち聞くのは難しいのですが、代わりに営業やコンサル部門(正確にはカスタマーサクセス部門)の人(以下営業系部署）に色々と話を聞いています。
具体的には、分析内容について「こういう風にやっていくとこういうことがわかる」という点までいったん考えたあとに、営業系部署に壁打ち相手*1になってもらい、出てきた結果について一緒に解釈したりディスカッションをしてもらっています。
また、slackで営業系部署の人が話している内容を読んだり、定例会議に参加するなどもドメイン知識取得には役にたっています。ただし、こちらはあくまで「営業系部署内での話」がメインなので、例えば「xxさんがキーマン」「今期受注をxx万達成するためには」「営業フローの見直し」といった話が多くあり 時間対効果が悪い です。
そのため、どれがDS的に関係がありそうな話なのかを見極めて集中して聞く話と聞かない話を区別する必要があります*2。
ただし、例えば前述の「xxさんがキーマン」は話の展開によっては「xxさんは特にxxxという部分を意思決定に大事にしているし、業界的には大事な指標になっている。」のようにDSにも関係がある話になることもあるので難しいところです。
そのため、「とりあえずはじめの方は時間対効果は悪いけれどある程度ちゃんと聞いて、ちょっとずつ関係がある部分の勘所を養う」「短期的な効果は見込めないが長期的には役に立つ」くらいの認識でやっていくのかなぁと感じてます。ただし、気づくと惰性でなんとなく参加になりがちなので、slackを決まった時間読んだり定例会に参加したあとに「今日学んだこと・考えといた方がいいこと・アイデア」などを5分間ひたすらメモに書きなぐったりして、学びを最大化するのは必須だと感じています。
きれいなコードを書く/書かせる
jupyter notebookが便利だからかわかりませんが、DSの書くコードは汚いという話をよく聞きます。エンジニアと違い、その案件が終わるとそのコード使わなくなったり、そもそも一人作業が多いので人に見せる必要が薄かったり、そもそもレビューがされないということも原因かと個人的には思います*3。
しかし、これはあくまで コードが汚くてもうまくいっているように見える だけであって、実際は前処理ミスなどがあってうまくいってなくて結果も間違っているけど気がついてないのかもしれません。また、そもそもコードが汚いと自分が読み返すときにミスが生まれやすかったり、再利用することがあるときに過去の自分のコードを読むのに時間が多くかかります。そのため、本来はレビューは必須です。
そうなると、「一人作業で完結」という体制はイコールでレビューがされてないことになりますし、言い方を変えると「レビューは必須なので複数人作業となり、誰かにコードを見せないといけない」です。
そのため、DSもきれいなコードを書く必要性があるのでその点について学習しました。
また、プロジェクトを進める際にコードは別の人が書く場合もレビューを念頭において書かせる必要があります。
ただし、最後にリファクタリングさせるからいいやとしばらく汚い状態で放置しておくとバグの温床になります。他にも、手遅れになってから気付いたり、リファクタリングが非常に時間がかかりいつまでもレビューができないなど、様々な影響が出てくるので、ある程度の頻度でリファクタリングやレビューをするようにマネジメントする必要があります。 エンジニア出身の人はいいのですが、はじめからDSでやってる人はレビュー文化が薄いのか、レビューをする機会を要所要所で作らないと全部終わってからリファクタリング&レビューになりがちな気がします。
では、どうやってきれいなコードを書くかは定番の以下の本がおすすめです*4。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
- 作者:Dustin Boswell,Trevor Foucher
- 発売日: 2012/06/23
- メディア: 単行本（ソフトカバー）
DSに一番わかりやすく必要そうな箇所だけ以下でまとめてます。
上記ではまとめてませんが、他に関数化できそうな部分(というか、2回以上同じ処理をする部分)は関数化するとか、コメントをちゃんと書くとかも大事ですね。
ちゃんと書けてるか？の指標としては、しばらく時間を置いた自分が書いたコードを読んだときに読みやすいか？ 。読みづらかったらその部分を反省してどう読みづらかったかを考えて以降に反映するのがやりやすいです。
なお、notebookでレビューをするのはgithubなどでは表示が見づらいのでReviewNBなどを利用するとよいです。
正しいデータを出す
レビューと内容的に被る部分もありますが、モデルに流すデータが本当に正しく処理されている？ という検証が必要となります。
その際は「テスト駆動開発」というやり方が参考になりました。
簡単に書くと、「テストとセットでコードを書いていく」みたいな開発手法です。
DSにおいては、前処理でこの開発手法を使うことで「正しい前処理ができているか？」という点をテストすることができます*5
詳細や実際の様子は以下の動画がわかりやすかったです。
また、簡易的にはassertを仕込んだり、Rの場合だとどういうJOINがされたかなどを各工程で出力してくれるtidylogの利用をおこなうとレビュー以前の簡単なミスは防ぎやすいです。
分析結果報告
資料作成
DSは多くの場合、分析結果をスライド化なりレポート化なりの資料化をおこなって報告をする必要があります。その際に、せっかく良い結果が得られても適切な伝え方をしないと良いリアクションが返ってきづらいです。そのため、資料作成技術は必須だと感じています。
基本的なことは世の中に数多ある資料作成本を読めばいいですが、DS特化という意味では以下の本が最高です。
- 作者:コール・ヌッスバウマー・ナフリック
- 発売日: 2017/02/16
- メディア: 単行本
Storytelling with Dataという原著のタイトル通り、 データでストーリーを語る 観点での資料作成の本です。データ分析は、非DSの人には複雑になりがちなのでそれをいかに伝えたいことをシンプルに見せるかの点で非常にすぐれています。
ただし、この本はあくまで全体構成や結果の見せ方の本なので例えばどういう手法を使ったかの説明が必要な場合に関しての記述はありません。
そういう場合は、いかにモデルの説明を非DSでも理解できる言葉に落とし込むかが重要になります。
例えば、Youtube広告の認知率を測るモデルとして、
のように 数式をそのまま書くのではなく、
のように、極力日本語化して書きつつ、それぞれの項を色分けして色毎に追加日本語説明をする、など極力わかりやすい形にする必要があります*6。
また、実際にどういうときにどういう動きをするのかということをクライアントの馴染みが深い言葉を用いて具体例を示すとなおイメージがつきやすくなります。
更にいえば、はじめにモデルの説明から入ると難しい印象を与え、聞き手が 「なんか難しそうでよくわからんから流しとこう」モードとなってしまいがちなので、はじめに「今から話すモデルでどういうことができるようになるのか」を実際をイメージ*7して説明をおこなってから話す、といったようなスライドの順番の工夫なども必要となります。
つまり総じて DSの理解そのままで見せても非DSからしたらよくわからないので、どうやったら非DSの人が興味を持ってわかりやすく、興味を失わずに聞き続けることができるか を意識した工夫を随所におこなう必要があります。
この点に関しては、DSである自分ではチェックしづらい部分でもあるので営業系部署の人に壁打ち相手になってもらうなどの準備も必要となります。
マネジメントについて
どういうキャリアを取るかにも寄りますが、ある程度キャリアが長くなっていくとマネジメントをする機会は随所で出てくると思います。
マネジメントは、チームの人に焦点を絞った「ピープルマネジメント」、プロジェクトに関しての「プロジェクトマネジメント」、技術に関しての「テックマネジメント」に分類できるので、それぞれについて書きます。
ピープルマネジメント
どうやってチームをうまく作っていくかとか、メンバーを成長させていくか、のような話ですが、ここはまぁDSに限った話ではないので、読んだ中でよかった書籍をあげるだけにしておきます。
チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ
- 作者:エイミー・Ｃ・エドモンドソン
- 発売日: 2014/09/05
- メディア: Kindle版
1兆ドルコーチ――シリコンバレーのレジェンド ビル・キャンベルの成功の教え
- 作者:エリック・シュミット,ジョナサン・ローゼンバーグ,アラン・イーグル
- 発売日: 2019/11/14
- メディア: Kindle版
マネジャーの教科書――ハーバード・ビジネス・レビュー マネジャー論文ベスト11
- 発売日: 2017/09/14
- メディア: 単行本（ソフトカバー）
世界最高のチーム グーグル流「最少の人数」で「最大の成果」を生み出す方法
- 作者:ピョートル・フェリクス・グジバチ
- 発売日: 2018/08/20
- メディア: Kindle版
ただ、読んでいて思ったのはやはりエンジニア向けのチームビルド・マネジメント系の本はDSと相性がよいように感じます。
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
- 作者:Camille Fournier
- 発売日: 2018/09/26
- メディア: 単行本（ソフトカバー）
テックマネジメント
前述のピープルマネジメントやプロジェクトマネジメント業務をおこなう際に、データサイエンススキル(知識)が欠けているとうまくマネジメントをすることができないように感じました。
例えば、ピープルマネジメントでは今学習している技術の相談であったりキャリアについて上手く話すことができないですし、プロジェクトマネジメントは前述のように要件定義で必要になるし、自分が要件定義をしない場合でも案件で使う技術に関しての相談や壁打ち相手をすることができません。
メンバーが持つスキルよりも全てにおいて詳しいのが理想ではありますが、皆それぞれスペシャリストなのでそれは現実ではないです。ではどうすればいいかというと壁打ち相手になるのに必要な知識があればいいように思います。つまり、基本的に技術自体のことは各メンバーが考えつつも、考えるための手助けになる視点を返していく(いわゆる、ソクラテス問答法)ために必要な知識を得ておけば最低限のテックマネジメントはできるように思います。
そのため、
- 少なくとも話している手法の基本的な部分を知っておく
- 参考にする論文をなんとなく内容を理解できるくらいの知識はつけておき、一読する
これらを指針に知識を得る必要があり、継続的に学んでいく必要があります*8。
分析結果をどうするか
「プロジェクトの進め方」で軽く触れましたが、最終的に分析結果をどうするかによっては「プロトタイプに落とし込み、皆が気軽に触れる状況にする」ことが最適な場合もあります。
その場合、Tableauなどのダッシュボードツールを使えるようにしたり、Python DjangoやR Shinyでプロダクトとして作成する必要も出てきます。
言い方を変えると、「プロトタイプに落とし込むスキルがある」と、アクションに繋がる落とし所を持った分析案件をすすめることができるので選択肢が非常に広がります。会社によっては、プロダクト開発のエンジニアを持っている会社もあるとは思いますが、DSが自分でそこまで落とせる方がスピード感が違うので会社へのバリューに繋がりやすいです*9。
ただし、このときにただスキルがあるだけでは使いづらいUI/UXのプロトタイプが出来上がるので、ある程度プロダクト開発の手法を学ぶ必要があります。
- 作者:丹野瑞紀
- 発売日: 2020/08/26
- メディア: 単行本（ソフトカバー）
行動を変えるデザイン ―心理学と行動経済学をプロダクトデザインに活用する
- 作者:Stephen Wendel
- 発売日: 2020/06/11
- メディア: 単行本（ソフトカバー）
正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について
- 作者:市谷聡啓
- 発売日: 2019/06/14
- メディア: 単行本
ちなみに余談ですがホクソエムさんは「DSはプロダクトマネージャーを目指すのが(キャリアとして）一番いい」といったことを記事で言っていたりするのは、このあたりの話もあるのかな、と思います。
終わりに
「記事を書く目的と背景」に書くか迷いましたが、こちらに書いたほうが締めとしてはよいのでこちらに書きます。
エンジニアで「コード以外の仕事が多い」という議論がよくあるようにDSでも同様のことがいえます。キャリアとして、「ただただデータサイエンスを極めるんや！」というのはそれはそれでいいと思います。しかし、極めようにも世の中にはやべーやつがゴロゴロいる中で戦っていけるのか？と考えると多くの人は難しいように思います。少なくとも私はデータサイエンス力偏差値63くらいまではできても、偏差値70の世界で戦っていく気概はありません。地球人なので、地球人の中では戦えても超サイヤ人に混じっては無理なクリリン/ヤムチャみたいな感じです。
そう考えると、一般的に多くのDSにはデータサイエンス以外の仕事が付随してくるし、そもそもそういうことができるDSはまだ少ないという話もあるので、偏差値63くらいありつつも、63→70になる努力をするよりも、その努力分をデータサイエンス以外の部分につぎ込んで価値を出していく方がコスパがいいと感じたのである程度のデータサイエンススキルを確保しつつ「データサイエンス以外のスキル」について上手くやれるようにしていこうと思い今年は過ごしました。
ちなみに、他にも分析案件以外もやるにあたって時間がめっちゃ足りなくなったのでタイムマネジメント系の学習も結構しましたが、そちらはDSの話ではなくなるので割愛しました。
来年もみなさんそれぞれのキャリアをがんばっていきましょー。
*1:話を聞いてもらって色々意見や感想を聞いてもらう
*2:そのため、定例会議で関係なさそうな話のときは会議中他の作業をしておく旨を営業系部署に合意を得たり、slackの読み方にも注意が必要です
*3:レビュー文化がない会社も多いという噂も聞いたりする
*4:エンジニア向けなのでDSが読むには必要以上な箇所もあります
*5:ただし、性質上あくまで「正しいデータか」という点のみしか検証ができないので「モデルが正しく機能しているか？」「適切なモデルか」といった点は検証できないのでその点はレビューで賄うしかないように思います。
*6:簡易化するにあたり落ちる情報があるので、クライアント先DSに資料が回ったときのことも考えてAppendixにちゃんとした数式を載せる方がベターです
*7:例えば前述のモデルだと、「認知率は表示回数と相関しているけれど、広告によって認知率への表示回数効果が異なるということはよくある(グラフで例示)。その原因として、広告の質によって表示回数効果が変わるのでは？という仮定を置いてモデルを立てた(質が高い広告と質が低い広告のイメージ図示)」みたいな。実際のように、この記事中でも文字ではなくスライド形式で見せた方が伝わりやすいと思うのですが割愛
*8:もちろんこれは最低限必要なスキルですし、そもそも自分が分析する際に必要なスキルも別途磨いていく必要性はあります
*9:もちろん、完成度においてはプロダクト開発のプロより劣るとは思うので、プロトタイプをDSが作成し、ある程度かたちが定まったり利用される見込みがたってからエンジニアに頼るのが一番いいフローな気がします
