まずは蝋の翼から。

学んだことを書きながら確認・整理するためのメモブログ。こういうことなのかな?といったことをふわっと書いたりしていますが、理解が浅いゆえに的はずれなことも多々あると思うのでツッコミ歓迎

アナリスト系DS1年生が今年を振り返りつつ来年以降やるべきことを考えた

この記事は何か

2019年の振り返り記事です。

アナリスト系データサイエンスを仕事でやり始めた1年の軌跡 という見方もできるかもです。

また、数ヶ月前にデータラーニングギルドというDSのコミュニティに所属したため、そこでのAdvent Calendarとしても投稿しています。明日以降も色々な経歴の人がキャリアの話しなどをこのAdvent Calendarでするみたいなので興味がある人は追ってみるとよさそう。

data-learning.com

qiita.com

ちなみに、データラーニングギルドはオンラインコミュニティではあるけれどギルドという名の通り相互扶助コミュニティなので、ROM専フリーライディングをしない限りは無料枠として参加できる設計になっています。そのため、興味のある人は初月は無料なので是非。
私は今のところ、わからないことあったら質問をしたり、情報交換したり、Kaggleチーム募集してチームを組んだりしてます。

何を書いたか

今年はアナリスト系データサイエンスをやり始め、基本的な部分はできるようになった。同時に、どういうことに注意してやっていけばいいのか、どういうことを自分はやりがちかという癖を把握することができた。

それらを踏まえて、来年は『ビジネス課題を解決する、より良い分析モデルに落とし込む』ために必要なことを考えています。

今年はなにをやったか

今年のはじめに、2018年までを振り返りつつ2019年をどうしたいか書いた。 knknkn.hatenablog.com

『2019年どうしたいか』という最終見出しでは、

アウトプットをひたすらおこない、ある程度は自分でデータサイエンスをできるようになる。 そのために、学んだことはちゃんとブログに落とし込んでちゃんと身に着けたい。

といったことを書いていた。今思うとめちゃくちゃ具体性のない抱負ではあったのだけど、ある程度は自分でやれるようになるために、今年は基礎固めに努めたこともありある程度は自分でデータサイエンスをできるようにはなった。

具体的には、分析をするために必要な最低限の技術を知り実践で使えるようになること(ハードスキル)、分析プロジェクトをするにあたって実践を通して感じた 自分の場合は どういうことを考えて進めていけばいいのかを把握するということ(ソフトスキル)の2点を学んだ。

ハードスキル

いわゆる技術的な部分。

羅列すると、

あたりが、基礎テキスト本レベルのことは使えるようになった。

ただし、実際に仕事で使った度合いが高いものほど習熟したし、使わなかったものは「やりかたはしっているけれど。。。」といった感じになった。
逆説的には、 仕事で使わないとできるようにならない

基本的に、『書籍で詰め込む→仕事でやる』という流れで学習しているが、仕事でやってみると「あれ、ここはどうすれば?」みたいなことが往々にしてある。その際に わかっていたつもりだけどわかっていなかった部分が浮き彫りになる ため習熟へと繋がった。もちろん、書籍の演習や言語化(ブログなど)をすることでも多少はできるが、実案件の複雑な状況を通した方が顕著に出てくるように思う。

ソフトスキル

実際にプロジェクトをやってみると、思いの外自分が考えずにプロジェクトをやっていることがわかった。また、例えばDSのインタビュー記事や書籍などに「要件定義をちゃんと固めてからやろう!」みたいなことはよく書いているが実際にプロジェクトをやってみると何故そういうことを言っているかということがわかるようになりました。

プロジェクトをやってみることで、良い分析に対して自分ができていないことのギャップおよび、何故そのギャップが起きているかどうやったらそのギャップを埋められるか 、つまり『分析プロジェクトをやりかた』に対して、自分の問題に対する把握および自分なりのPDCAの回し方の確立ができるようになった。

ちなみに、今回把握した自分の悪い癖(理想とのギャップ)のひとつ、「自分の頭で考えてるようで考えてない」に関してはDatagatewayTalkというイベントでLTを行ったのでそちらに詳細を書いています。

speakerdeck.com

knknkn.hatenablog.com

来年なにをするか

今年を振り返ることで、「とりあえず基本的なことは最低限できるようになった」ことがわかった。しかし、あくまで最低限であり、これは土台部分なので来年はその土台を基に積み上げていこうと思う。

まだまだ上司にレールを敷いてもらわないといけない状態(ある程度分析の枠組みが与えられたり、誘導尋問的に要件を定義している)なのでこの点の脱却が来年達成すべき目標かと思われます。最終目標は『適したビジネス課題の設定』をし、『課題に対して数あるアプローチ』の中から『一番課題に対して適した分析モデルに落とし込む』ことができるようになりたいです。

そのために来年は

  • 手持ちの道具を増やし、色々なアプローチが使えるようになる
  • 課題を定められるようになる

この2点を目標とします。

今年の振り返りで記載したような『必要になってからやるのが一番学習コスパが良い』ということはよく聞く話だし、今年の目標達成のための学習としても使っていく予定です。ただし、このやり方は似たような課題の案件が増えてくると『仕事で使う手法が、ある程度固定化されてくる』ので『必要になったらやる』やり方ではスキル領域が広がらないという問題をはらんでいます。この問題は分析受託会社でない限り、どこでも起こりうるし実際私にも起きている。

この問題を解決するためには、

  1. 似た課題に対して、他のより良い解決策がないか考える
  2. 新たな課題を考える
  3. 別の課題がある場所へいく

の3つの対策が考えられる。これらを通すことで先程の2点『手持ちの道具を増やし、色々なアプローチが使えるようになる』『課題を定められるようになる』を改善することができそう。

似た課題に対して、他のより良い解決策がないか考える

これを考えるためには、その課題に対する他社のアプローチ事例を読んだり、論文を読むことで手持ちの道具を増やしたり、道具の理解を深めるためのインプットを増やす必要がある。また、少なくとも自分の場合は似た課題に対しては意識をしないと手癖で同じことをついやってしまうので常にこの点は注意したい。

また、『注意したい』はただの根性論なので、システムに落とすのならば例えば『毎週火木は今の課題について他のアプローチを探る時間を作る』と決め、Googleカレンダーの定期スケジュールとして登録をするなどのシステム化も併せておこなう。

新たな課題を考える

クライアントや自社が抱えているが手を付けれていない課題を汲み取ったり、そもそも認知がされていない課題を考えることで『似た課題』以外を創出する。

そのためには、現場の声を聞いたりドメイン知識を得ることが大事。・・・とよく言われている。
ただ、実際に今年はクライアント先に同行をしたり、一番クライアントに近い営業/コンサル部署の定例社内MTGに出たりしていたがものすごく時間対効果が悪い

実際の課題に関しては営業/コンサル部署が聞いているし、課題の深堀りも営業/コンサル部署を通して聞くことができる。そうなると、せいぜい課題を浴びて肌感覚を養う、という抽象的な、じっくり培っていくことしかできない概念なので、難しい。手っ取り早くやるには、それこそ現場で同じ作業をするだとか、いっそ営業/コンサル部署に一時的に在籍するみたいなDSではなくなるしか無理じゃね?と思う。みんな何をもって「現場に出てドメイン知識を得よう!」と言ってるんでしょうね。エピソードが端折られすぎててわからん。

*****追記 ここで書いている『ドメイン知識』は、実際にそのゲームをやってみてユーザーの気持ちを考える = データ生成過程を見てみる*1ことで良いモデルを作る、というようなニュアンスではなく、クライアントがその分析結果を提示されたときに嬉しいのか?という、分析設計寄りニュアンスの『ドメイン知識』です。 *****

今のところ、

  • 営業/コンサル部門に「こういう課題がありそうなので、それを解決するこういうアウトプットあれば嬉しそうすかね?」といったヒアリング
  • 営業/コンサル部門の定例MTGで、クライアントの課題感を話すタームのみ話を聞く(他の時間は別作業をする)

の2点は時間対効果が良かった。特に前者は課題設定の練習にもなるし、フィードバックを通して現場感が伝えられるのでこれからも定期的にやろうと思う。

また、自分の場合は割と目の前の課題や処理をさっさとしたいので『(いったん目の前の課題ややっていることを置いておいて、)考える時間を作る』のが苦手なのでこれもGoogleカレンダーなどに枠を定める必要がある。

まとめ

アナリスト系データサイエンティストとして、基礎固めは終わったのでその先として『ビジネス課題を解決する、より良い分析モデルに落とし込む』ことができるための課題を設定しました。

より正確には『ビジネス課題を解決する、より良い分析モデルに落とし込む』ために必要なことのPDCAを回し始めただけで、『ビジネス課題を解決する、より良い分析モデルに落とし込む』になるためには何年も時間が必要になると思います。

しかし、その時間はやり方によっていくらでも増減すると思うのでちゃんとやるべきことを効率よくやり、ちゃんとPもDもCもAもやって軌道修正をおこなうために引き続きブログを定期的に書いたり、真剣アウトプットの場としてLTをしたりしていきたいと思います。

また、今はブログ執筆は読者を意識せずに、ただメモを書いているだけに近いのですが手法理解系に関してはもうちょっと輪読のように書いた方がアウトプットを通した学習は大きいので少し書き方は変えようかな、と考えてます*2

*1:このインタビュー系の内容とか https://japan.zdnet.com/article/35124706/

*2:ただし、その場合書く心理的ハードルが上がったり、執筆時間が伸びるので適当なバランスのレベルで書くことになりそう