Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

Economics Meets Data Science: ML and Economics Together at Last


Hello again, Internet! It's December now, the season of presents, Christmas carols, parties, catching colds and eating fried chicken. This time I'm taking a break from the Structural Estimation Series. Instead, I'll discuss a topic that I have been playing with recently: Double Machine Learning estimators for causal inference. This is a topic that is gonna have a huge impact on empirical Economics, but most people don't seem to have heard of yet.

The Background

Since 6 years ago I have been hearing about Economics adopting (or being replaced by) Machine Learning (ML). It was at that time that Hal Varian published his paper Big Data: New Tricks for Econometrics, and Google published its paper on making causal inference employing BSTS. Future looked bright.


In my dreams, this was me waking up to a new world in Economics:
https://media.giphy.com/media/QsPiApKClOffvxIXUy/giphy.gif

Years passed and I'm still waiting for that promised land. Behind all the hype around ML models there were some issues that needed to be addressed before they could be introduced into the typical economist's toolbox:

ML models are black boxes, and economists really care about understanding the meaning of the coefficients of the model. We are the kind of people who have fun seeing shapes in the clouds.

Also, economists care a lot about bias. Machine Learning algorithms are mostly used for prediction. In order to become useful for that task, algorithms must be good outside-the-sample predictors. To achieve this, regularization must be applied, which affects the capability of the model to fit the data in a given sample. In other words, they admit some bias in exchange for lower variance. In comparison, most econometric models, especially in the policy evaluation literature, don't really attempt to be good predictors outside the sample, and prefer unbiased/consistent estimators that are as precise as possible given a sample size. Thus, the purposes of Economics and ML seem incompatible at first glance.

Finally, when trying to identify a causal effect or a structural parameter, you usually need to know how variable is your estimate, and perform hypothesis testing. ML methods don't offer an easy way of knowing the variance of the millions of parameters they employ. Furthermore, you're probably not interested in what the distribution of the 34th embedding of a word looks like asymptotically. You can try to employ bootstrap to obtain the variance of the million plus parameters in your neural network that took you two days to estimate, but good luck with that.

続きを読む

元開発者の、プロダクトマネージャーへの第一歩

Sansan 事業部でプロダクトマネージャーをしております、熊崎と申します。
プロダクトマネージャーといってもまだまだひよっ子です。

開発者 -> プロダクトマネージャー -> 開発者 -> プロダクトマネージャー

と経歴の変遷を経ているのでプロダクトマネージャーという肩書を得たのは2度目。

1度目の時は十分に稼働できていなかった経験があり、それに対して2度目の今は割とうまくいっている自負が得られており、「その違いって何だろう」と考え始めたのが本記事を書くきっかけとなりました。
これからプロダクトマネージャーを目指す開発者にとっての一助となれば幸いです。

はじめに

私がプロダクトマネージャーという肩書を初めて得たのは2014年。
当時は組織の規模も製品の規模も今と比べて左程大きくなく、創業時からずっと役員がプロダクトマネージャーの責務を持っている状況でした。
私は開発者として籍を置いていたわけですが、会社として「今後の組織や製品のスケールを見据えて、専任のプロダクトマネージャーを立てていこう」という方針となり、それが転身するきっかけとなったのです。

開発者からプロダクトマネージャーに転身した際、以下の疑問が脳裏をよぎりました。

「プロダクトマネージャーって何をする仕事だ ?」

なる前に考えておけよって話ですが、発令がわりと急だったのを言い訳とさせていただきます。
社内でプロダクトマネージャーという職種が立ち上がって間もなかったので周囲にも知見がなく、文献を漁って巡り合ったのが「Inspired: 顧客の心を捉える製品の創り方」。長年愛されている良書です。
私も本書をバイブルとしており、本記事でも何度か引用させていただきます。

プロダクトマネージャーの主な任務としては2つある。製品の市場性を評価することと、開発すべき製品を定義することである。
by Inspired


「なる程凄そう」

開発にしか携わってこなかった私は初めて読んだとき、とても遠い未来の話のように思いました。結局この時は目の前の仕事に追われるまま闇雲に手を動かしてしまい、プロダクトマネージャーという仕事の輪郭を掴めなかったのです。

その時から5年。3年ほどで一度開発者に戻ったので、プロダクトマネージャーとしては実質2年ほどの経験を得ました。
現在でも「Inspired」に書かれていることの20%くらいしか実践できていませんが、未熟であるものの「自分がプロダクトマネージャー足り得ている」と実感できるくらいにプロダクトマネージャーの正体が見えてきました。
本記事では私が考える「元開発者の、プロダクトマネージャーへの第一歩」として、「プロダクトマネージャーの4つの仕事」を述べたいと思います。

尚、本記事ではプロダクトマネージャーの仕事について述べさせていただきますが、以下コンテキストが多分に含まれていること、ご留意ください。

  • 携わっている製品は企業向けソフトウェア (B to B クラウドサービス) である。
  • 製品の新規立ち上げではなく、既存製品の改善が担当範囲である。
続きを読む

Developers Boost 2019に登壇しました

どうも、Sansan事業部プロダクト開発部の林です。11/30に開催されたDevelopers Boost 2019に登壇しました。発表資料はこちらです。
speakerdeck.com

発表まで

弊社ではDevelopers Boostが始まった去年からスポンサーをしていて*1、今年もスポンサー枠で登壇希望者が募られました。ちなみに募集から〆切まで3日間となかなかスピーディーでした。

f:id:kota_hayashi:20191204155059p:plain
登壇者の募集
チームメンバーと雑談していたところtany3(アイコンの人物)が突然現れて、「林君でてみない?」持ちかけられました。Developers Boostのことはよく知りませんでしたが、社会人としてイベントに登壇したことが無かったので良い機会だと思い、2つ返事で登壇を承けました。
その後はタイトなスケジュール感で、翌週末には発表タイトルを決めることになりました。Developers Boostは特定の技術による縛りが無いイベントでエンジニアの生き方というカテゴリーがあるなどエモめのイベントのようだったので、それにあった発表内容を考えるのに苦労しました。
チームメンバーとも相談し、短い期間で色々なプラットフォームでの開発をしていることを主題において話をすることに決めました。ちなみにタイトルは大喜利形式で決めました。

f:id:kota_hayashi:20191204172540p:plain
タイトル決定

続きを読む

勉強会を行うときに知っていたら少し役立つこと

こんにちは。CTO室の鈴木由香です。
Sansan Advent Calendar 2019 14日目の記事を書かせていただきます。

わたしが普段やっていることのひとつに '勉強会の開催' があります。
本記事では、実体験をもとに勉強会開催時のTipsをお届けしようと思います。
勉強会の主催をはじめてやってみる、他の人はどんな方法をとっているのか知りたい、といった方に届けば幸いです。
ただ、あくまで私見となりますので、参考程度にお読みください。

直近で行った勉強会

f:id:s_yuka:20191211173549j:plain

まずは、今年の夏以降に行った勉強会を簡単にご紹介します。
これらの勉強会は、どれも数十人規模で、他社から登壇者を迎える形であり、懇親会の時間をしっかりとっています。
なんとなくふんふんとざっくり見てみてください。

続きを読む

New Relic Alert でサービス全機能のエラー監視を実現させてみた

Eight事業部プロダクト部 Platform Group / Engineering Manager の 藤井洋太郎(yotaro) です。

このエントリは New Relic Advent Calendar 2019 - Qiita の12/13分のものです。

前回、以下のNew Relicを活用したパフォーマンスチューニング事例の記事を書かせていただきましたが、

そこからいろいろとご縁があり、今ではすっかりNew Relic活用大臣と化しています🤵🏻

さて、今回は「Eightサービス上の全ての機能ごとに400系-500系のエラー急増の監視を New Relic Alert にブチ込んだ話」をしたいと思います。

Eight のこれまでの監視

Eight ではこれまでもインフラ基盤やアプリケーション上で発生する「予期せぬエラーや障害」を検知し迅速に対応に入れる仕組みづくりを積極的に行ってきました。

が、先日、ある機能にて、ある条件下において機能が利用できないという不具合が発生してしまいました。

そして予期せぬ事態の際はアラートが上がると思い込んでいたため、この問題に気付くまでに時間がかかってしまいました。(気付いたきっかけはユーザさんからのフィードバックでした🙏🏻)

原因はクライアントエラー

機能停止に至った原因は、アプリのアップデート時にAPI仕様違反が一部条件で発生し400エラーとなるケースがあったためでした。

4xx系エラーはクライアント側の問題ということもあり、これまで Eight では監視対象としてこなかったのでした。 また、今回の件は一部条件下で発生するもので、リリース前の受け入れテストでも見つけられませんでした。

400系も監視対象に

重要機能での機能停止が発生することもある400系エラーは検知できるのに越したことはないということで、以下要件で新たに監視を組み込むことにしました。

  1. 400系と500系のエラーレートを監視対象とする
  2. 機能単位のエラーレートを監視し一定期間で 5% を超えたらアラート
  3. 「すべての」機能(Transaction)に対して監視を入れる

これを New Relic Alert で力づくで実現させたので、ここからはその方法を簡単に共有します💪🏻

続きを読む

Sansan AndroidにおけるFlux移行

SansanでAndroidアプリケーションエンジニアをしている山口 です。リードエンジニアになって8ヶ月が過ぎました。

今回はSansan AndroidにおけるFlux移行について書こうかなと思います。

Flux移行の背景

アーキテクチャの変更に限らず新しいなにかの導入は理由があって行うものです。流行り廃りに敏感になることは重要かと思いますが、現状の開発に問題がない場合、あえて古い技術要素のまま開発を進めることは多々あります。今回Fluxへ移行する理由は以下の3つです。

  • 体制の変更とそれに伴う現状のアーキテクチャにおける問題点を解決する
  • データの表示というアプリの本来の目的にフォーカスする
  • チームメンバーが好きになれるアーキテクチャを採用する

体制の変更とそれに伴う現状のアーキテクチャにおける問題点を解決する

前回この1年の変化を書かせていただいた中でチームメンバーの増加とMVPのレイヤードアーキテクチャについて触れました。

buildersbox.corp-sansan.com

前回の記事の7月時点ではAndroid1チームで開発を行っていましたが現在はリードエンジニアをもう1人立て、2チームに分割されました。更に業務委託メンバーがフルタイムに、12月からは新メンバーが増え、4人チーム+3人チームの計7人の体制になります。

さて人数が増えてくるとより並列に開発が行えるようになります。そこでの問題の1つがコンフリクトによる開発スピードの低下です。 MVPのレイヤードアーキテクチャにおいて、例えば名刺を取得して表示する画面の場合、ViewロジックをBizCardPresenterに、ドメインロジックをBizCardUseCaseに書きます。複数人でこの1画面を開発すると、複数人でBizCardPresenter/UseCaseを変更することになり、コンフリクトする可能性が高くなります。

f:id:phicdy:20190712103739p:plain
MVPレイヤードアーキテクチャにおける名刺取得

更に、1画面におけるViewロジックがPresenterに、ドメインロジックがUseCaseに集まる結果、Presenter/UseCaseが肥大化する傾向にあります。これはプログラムにおける可読性の低下や運用保守性の低下に繋がります。MVPの特性上ViewからPresenter間、PresenterからUseCase間を行き来することが多く、こちらも可読性を下げる原因になっていました。

もう1つの問題点が、状態の管理についてあまり深く定義していないため実装者によって状態の管理方法が異なることが増えてきた点です。View側で状態を持つ場合もあればPresenter側で状態を持つ場合、またはView自体に設定された値を内部から取ってきて状態を復元するなど統一性が取れなくなってきました。

続きを読む

開発チームでデリゲーションポーカーをやってみた

Sansan事業部 プロダクト開発部のエンジニアの岡野です。

先日、開発チーム内でデリゲーションポーカーを実施したので、そのときのお話を紹介したいと思います。

デリゲーションポーカーとは?

担当するタスク(テーマ)において、誰がどのレベルの責任を負うのかを7枚のカードを使用してすり合わせ(権限移譲)を行います。
例えば、有給休暇を取得する際にチームリーダー(管理者)とどのように相談し決めているか等のテーマを決めて話し合います。

実際に使用したカードは以下になります。

f:id:orange-33:20191201233126j:plain

  • レベル1. 命令する : 私が彼らに決定を伝える
  • レベル2. 説得する : 私が彼らに売り込む
  • レベル3. 相談する : 彼らに相談し私が決める
  • レベル4. 同意する : 私が彼らと合意して決める
  • レベル5. 助言する : 私は助言するが彼らが決める
  • レベル6. 尋ねる : 彼らが決めた後で私が尋ねる
  • レベル7. 委任する : 私は彼らに完全に委ねる

レベル1に近づくほどチームリーダー(管理者)が決定することを意味し、レベル7に近づくほどチームメンバーが決定する裁量があることを意味します。

デリゲーションポーカーの流れ

  1. 話し合いたいテーマを決める
  2. テーマに応じて、各参加メンバーが理想と考えている権限の状態(レベル)のカードを選択する
  3. 各参加メンバーが選択したカードの理由をそれぞれ説明する
  4. 3. で説明された理由を踏まえて、チームとしてどのレベルの権限移譲を定義するのか話し合い決める

今回実施したデリゲーションポーカーでは、オリジナル要素が一つあります。
Sansan事業部 プロダクト開発部のPMの加藤に教えてもらった手法です。

デリゲーションポーカーの流れ自体は変わらないのですが、As-is(現状)、To-be(理想)の2パターンを整理する以下の流れで実施しました。

  1. As-is : チームの現状のレベルのすり合わせを行う
  2. To-be : As-is を考慮したうえで理想とするレベルのすり合わせを行う

今回は、開発チームのチームリーダーとチームメンバーでのタスクに関する権限についてのすり合わせを行いました。私は、開発メンバーとしての参加です。

続きを読む

© Sansan, Inc.