書籍レビュー 経営システム 28巻2号「ビジネスでインパクトが出せるデータサイエンティストになるには」

@pseudo_finite さんより, 経営システム 28巻2号をいただいたので, @pseudo_finite さんの解説記事　「ビジネスでインパクトが出せるデータサイエンティストになるには」の感想などを書いていきます。
(1/24 には届いていたのに引っ越しなど諸々忙しくて感想を書くのが遅くなりました :pray:)

本記事では, まず自分の立ち位置を示した上で記事の各章について本文の主張に関連して感想や実務を通して身につけた自分の考え方を述べていこうかと思います。
書いてから記事を読み直すと, 本文が学術誌ということでこの記事の書き方もやや硬めの書き方になってしまいました。

解説記事の章立ては以下のとおりです

1. はじめに
2. データサイエンティストが力を発揮する場
3. 課題設定
4. 解決方法の設計
5. 検証
6. 育成
7. まとめ

このフォーマットはu++ さんのものを大幅に参考にさせていただきました :bow:

【書籍メモ】「ビジネスでインパクトが出せるデータサイエンティストになるためには」 - u++の備忘録

また一旦勢いで書いたのでこの記事はdraft に近いです。参考になるリンクなど随時追記していきたいと思います。

自分の立ち位置

アドテク会社のData Mining (Machine Learning) Engineer 新卒2年目(もうすぐ3年目)です。
肩書はEngineer とはいえ, 会社の特性上, ログ, KPIの分析, 文献調査, offline検証, 設計, 開発, online検証, 運用 など割と全部やるため, フェーズによってはいわゆるデータサイエンティストっぽい業務もあります。

1. はじめに

いわゆる序論で導入と記事の構成の説明を行っています。
導入の中で 近年データサイエンス自体に注目が集まっているのはもちろんだが, 本来的にビジネスの場で必要とされているのは広義のサイエンティストである という要旨の記述があり, とても同意しました。
データサイエンス(以下DS)やMachine Learning(以下ML)は, いわゆるエンジニアリングとは違って結果が確率的なものであるため, 方法論ありきのやり方は失敗しやすいなと最近いろいろな方の話を伺って感じているところです。

2. データサイエンティストが力を発揮する場

企業という場に絞って, 表題通りの内容について解説しています。
本文中で大事なのは主に以下2点だと述べられています。

1. データサイエンスによってスケールさせられるビジネスドメインである
2. 十分な量と質のデータを保有している

1 について, DS, MLは0->1や1->10というよりは 100000 を10000 * 1.01 にするような役割を果たすことが多いため, 解説記事中にあるようにニッチな産業あるいは十分なデータがない新規事業だとビジネスインパクトを出すのは難しいと思っています.
ただ例外はあると思っていて, DS, MLの知識自体を売るモデル(教育, コンサル) や既存事業のデータを活用した新規事業の場合はこの限りでないかなと思います。

2 について, 量については割と当たり前なので質の部分に触れていきます。
本文中ではデータの質に関して, 匿名データより実名データ, 閲覧データより購買データの方がユーザの性質をよく表しているため質の高いデータであるという旨が書かれています。

自分の業務(アドテク)周りだと, アドフラウドなどで不正なclick除外したり, conversion はユーザによって定義が違うので気をつける必要があります。実務のML Engineer の業務は前処理がほとんどと言われるのもこの辺りの所以なのかなと思います。
またデータをどう活用するかという観点からテーブル定義やロギングの設計を行うのもとても大事なことです。

3. 課題設定

適切な課題設定が大事だと言う話でそもそも解くべき問題か?を考えるのが重要だと述べられています。

伝え聞く話では Japanese Traditional Big company などでは, "Deep Learningでいい感じにしてくれ" というようなオーダーがお偉方から降ってくるらしいですが, そのような方にこそ本章を読んでいただくのが良いのではないでしょうか。
ただ翻ってみると自分も方法論ありきで課題を設定してしまう(この言語, フレームワーク,ライブラリ, アルゴリズム が使いたい)ということはあるなと思ったので気をつけようと思いました。

4. 解決方法の設計

前半部では, 手法の検討において, ML, 数理計画, 確率モデリングなどを解決手法として公平に考える必要がある旨が述べられています。

こちらの主張もほぼ同意で, 自分の意見を加えるとプロジェクトの期限やリソースに寄ってはルールベースのロジックで設計するのも検討する必要があるなと考えています。
いずれにせよ前章でも触れたように方法論で解決方法を決めるとロクなことにならないは確かです。
若干後付けですが, 自分も解法をMLで縛りたくないため MLエンジニアではなく Data Mining Engineer の肩書を名乗っています (弊社では肩書は個人で決めてOKだった)

後半部ではML, 数理モデリングにおいて重要なことがおおまかに以下のように述べられています。

• 実装可能性(いわゆる feasibility)
  • 不可能な場合は問題の方の性質を変更する
• 実装容易性, 保守, 運用の容易性
• 近似の精度

それぞれについて, 自分の考えを述べます。

実装可能性

これはちょうど最近あまり考えず雑にタスクを進めてしまったせいで, アプリケーションエンジニア, インフラエンジニアとのコミュニケーションコストが増大して余計に開発期間を要したということあったので耳が痛い話でした。
新規にロジックを実装する場合は アプリケーションエンジニア, インフラエンジニアには事前に確認とっておきましょう。。。

実現容易性, 保守, 運用の容易性

本文中にも述べられていますが, 実務だとモデリングの手直しが必要なことはままあります。
実際に経験したのは オンライン検証の結果モデルに問題があることが判明した, 本番運用において入力データが想定しない形で変更された などです。 本来はモデリングの際に考慮できていればよいのですが, 完璧な考慮は無理です。
したがって改修が容易なコードで実装しておくのが良いため, 設計, リファクタリング周りの勉強はDS, ML Engineer でもしておくと良いと思います。
学習コストとのバランス考えたときの個人的なオススメ本は以下あたりです。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

UMLモデリングの本質 第2版

近似の精度

実務において何がしかの近似は必ず必要になってくるので, その影響を考えるのは大事です。
時に近似が思わぬ挙動をすることがあるので, モデルの予測精度まで時系列で監視できるような基盤があるのが望ましいかなと思います。またDS, ML周りで物理の強い人が多いのはこの辺りが強いなのかなと思います。

5. 検証

本章で重要だと述べられているのは主に以下2点です。

• スピード重視で検証をおろそかにするのはNG
• 施策の「良さ」の評価

スピード重視で検証をおろそかにするのはNG

これはもちろんで要件定義の段階で検証でモニタリングするKPIはビジネスの意思決定者と握っておくのが望ましいでしょう。
ただし, 対象KPIは検証を行う過程である程度柔軟に変更,追加できるようにしておくほうが良いです。
モニタリングについては改善すべきKPIはもちろん非機能要件の精度, データの量, 質などについても行っておくのが望ましいです。　
また, ないとは思いますがMLのフリーランス, SIでPoCまともにやらないところは避けたほうが良いです(社会性フィルタ)

どの程度の確信度で検証を行いたいか。

DS, ML では特に 施策の良さの評価が難しい. 常にmore better の施策が存在することが多いうえにそれを確かめるすべがないという旨が書かれていました。

本文ではよりよい施策の探索法として以下二点が挙げられていました。

1. 仮説を元に網羅的に施策を走らせる
2. 複数のDSに施策を競わせる

これは業務上では前者は時間や後者は人的リソースの制約で厳しいパターンが多く, (DS, ML Enginner にとって)十分な検証ができないまま開発が進んでしまうのが多いのかなと感じています。
この辺り解決するいい感じのOSS, SaaSが生まれてくれればよいのですが...

6. 育成

サイエンスの能力 と 実務遂行能力 の二点を育てるのが大事だと書いてあります。

実務遂行能力 については,いろいろな人にレビューをしてもらうように著者は心がけていると記述があり, この点についてはとても同意できました。 実務においてまず身につけないといけないのはドメイン知識でありその部分はレビューの中で質問するのが身につくのが早いと考えています。

あとちょうど昨日こんなツイートが流れてきて, そうだなーと思いました。

「コンサルタント型のデータサイエンティストや一部の機械学習エンジニアは直接の開発部隊から部署が離れていることがあり，開発経験が積みにくいことがあります」「開発力のないデータサイエンティストは自分の技術の出口を持てないため価値を出すのが難しいです」 https://t.co/ugiVHVdpJz

— kng (@kng_ac) 2019年3月29日

新人でDS職の人でも最低限のproduction deploy くらいは経験積んでおいたほうが良いかと思います。

サイエンスの能力 については正直アカデミアでないと満足な教育が難しいため各自大学時代に勉強するのが一番大事だと思います。 企業の中では社内での書籍, 論文の紹介仕合いや有識者による勉強会などがあると良いのかなと思いました。

全体を通しての感想

ML, DSは新しい分野であるが故に企業で成果を出すためのノウハウは形式知化してないことが多く, その点で本解説記事はとてもよくまとまっていて良いと思いました。
自分もスキル的にまだまだ未熟ですがスキルを成長させるのはもちろん, 実務で得た知識も積極的に世の中に還元して DS, MLに関わるひとがハッピーになるように貢献できればと思います。

久々に長めの文章を書いて疲れた