ID:49043さん

弊社ではデータの取り扱いに関して以下の問題がありました。 - 分析するデータがプロダクトのデータに依存している - 似たような依頼に対して似たような分析を行うことがある - datastudioでダッシュボードを提供しても、定義が変わると各ダッシュボードのクエリを変更する必要がある - 分析者、依頼者によって指標の定義がずれることがある - データが分析しやすい粒度でBig Queryの中にあってもSQLのリテラシーに差があって分析できない人は時間がかかったり、そもそもデータ抽出ができない -> 依頼が分析チームに集中する 上記の問題に対してDWHの構築、Lookerの導入を推し進めることにしました。 進めていく中で感じた課題は立ち上がりのタイミングだとどうしてもLookMLを書く部分がボトルネック化すると感じています。ここに対してはLookMLを書ける人材を育成することで解消を試みています。 難しいと感じている点は、任意の期間で一度でも利用したユーザーをきれいに分析できるようにLookMLを書く点です。ここはnative derived tableを使った設計で綺麗に書けるようになったと感じています。 導入して2ヶ月ほどでPdMがデータを元に議論するようになり、リリースした機能の評価もダッシュボードをもとに議論できる状態を作ることができました。 また、Lookerだけではなくデータウェアハウスの構築もデータエンジニアと二人で進めました。 データウェアハウスとデータマートに位置するLookerの両方の面倒を見ることで、早いサイクルでLookerによるデータを見れる環境を提供できるようになりました。

- 自然言語の情報から実数値のKPIを予測するタスクに対して、自然言語特徴量をTf-idfで処理し、Lassoによる回帰を用いて予測を行うようにしました。 - Lassoを用いた理由は、自然言語を扱う上でノイズとなるような単語はたくさんあると考え、そのような項の寄与はL1正則化により潰してしまったほうがいいと考えたからです - 実験をすすめる上でjanomeの扱いやすさとmecabのスピード、そして新しい日本語を使うためのNEologdをかんたんに扱えるように[wakameというOSS](https://github.com/tenajima/wakame)を個人開発しました - 開発動機の詳細については[こちらのブログ](https://tenajima.hatenablog.com/entry/2019/12/07/133645?_ga=2.229013148.1010687965.1600125104-1170363756.1575042957)で紹介していますので、ご覧いただけると幸いです - データ活用をメインにした機能開発において、PdMと「どのようにしたら顧客がほしいと思える、顧客にとって価値があるアイテムを実現できるか」を要件定義の段階から対話を通して決めていった - このようにして開発すすめる直前にPdMが決めてきた仕様に対して「機械学習、アルゴリズムを使ってなんとか実現してくれ」というスタンスを取っていたのですが、実現可能性がどうしても低いものを無理やり実装したりなど、心苦しくなることや、「それは〇〇な理由でできません」と断ることが増え、お互いに気持ちよく仕事できなくなってるなと感じ、もっと上流の部分から関わることで気持ち的にも、歪み的にもクリーンになるように心がけました - アルファ版の開発において、自分を含め普段からプロダクトコードを書いているわけではないメンバーで、最短で実装できるよう[gokart](https://github.com/m3dev/gokart)をプロジェクト全体で導入し、インターフェイスの共通認識を作ることで設計コスト、レビューコストを減らすことに努めました。