ユーザとプロダクトを語るワークショップイベント "Sansan User Lab vol.1"

Sansan PMOの尾部です。こちらはSansan Advent Calendar 2019 12月25日🎄の記事です。

先日ユーザの方とワークショップをしたのでご紹介します。私達もユーザの方も楽しく意味があるイベントにできました。 CSが企画するMeetupへの参加や1対1でのヒアリングは行っていますが、ワークショップ形式は初めてでした。

1. 「You are not the user」プロダクト開発プロセスとユーザを意識するタイミング

Sansanはすべての社員が利用することで最も力を発揮しますが、一般的に名刺交換や外部との接点が多い営業や調達部門の方が、やはりコアユーザであることが多いサービスです。翻って、プロダクトを作っているメンバーはエンジニアやデザイナーが中心です。

私は「You are not the user」という言葉を大事にしています。 少しのユーザの言葉から多くのことを想像できる優秀なプロダクトマネージャーやデザイナー、エンジニアもいるかと思いますが、それは非常に稀だと思っています。個人的な意見ではありますが、「ユーザのことを分かっている」という自負はただの思いこみであることがほとんどで、怠慢にならないためにも「仮説はハズれる」と自分を疑って検証し続けたいと強く意識しています。

本題に入る前に、私がプロダクト開発において、ユーザを意識するタイミングをご紹介します。

（前置きが長くなるので、スキップしたい方は「2. ワークショップイベント "Sansan User Lab" 」からお読みください）

① プロダクトバックログに積む前に、ユーザの課題は何なのかを調査します。

プロダクトマネージャーにはプロダクトバックログに積む前に心のバックログがあり、「ユーザはきっとこれに困っているのでは？」という仮説を持っているのですが、実際にユーザと会話しながらその仮説が確からしいか、それとも別にあるのかを確認していきます。

やり方としてはNPSや日々のフィードバックを元にすることもできますが、ユーザに直接ヒアリングすることが最も課題を的確に捉えやすいと考えています。理由は2つあります。1つはNPSやフィードバックのようにユーザが言語化できるものだけが課題とは限らず、こちらから引き出す必要があるから。もう一つはその場でプロダクトを操作する手元を見せてもらったり、その瞬間に考えていること、不安などをヒアリングし様々なカットで課題の背景を深堀りできるからです。

AWS re:Invent 2019 にいってみた。（出発準備〜Midnight Madness）

こんにちは。
DSOC Infrastructure Groupの水谷です。*1
アクション映画やアホな映画（褒め言葉）を好んで見ています。amazon primeのおすすめがほぼ全てジェイソン・ステイサムになったのですが無視し続けていたら今度はセガールがやってきました。
今は http://heavy-trip-movie.com/ が楽しみです。

さて、今回はAWS re:Invent 2019の参加レポートになります。

初参加だったのですが、注意点やこうしたほうが良かったなぁっていう情報をちょいちょい挟みつついきます。
全体的にはre:Inventの発表を網羅するというより、DSOCのシステムの紹介も挟みつつre:Inventで発表された技術をどのように活用していくかを発信していこうと思います。
ただ・・・・・初日はただの旅行記です。

最後の投稿に全体のまとめと楽しみ方や持っていったほうが良いもの・要らないものを記載しますので次回行かれる方は参考にしてもらえると嬉しいです。

出発前

行き先がアメリカということで、ESTAの取得が必要です。
過去に見送りで成田にいった際、その場で申請してミスって却下されてるのを見たことがあるのでちゃんと事前にやっておこうと思います。この時はANAの方が大使館？と連絡を取ってくれてどうにか通過してました。航空会社すごい。
父親の名前のヨミが思い出せずGoogle先生の力を借りました。親の名前も教えてくれます。で、無事承認されました。*2
後で私の写真が出てきますが、2年前のパスポートの写真が今と違いすぎるのも若干不安がよぎります。

次は服ですね。
出発前日にネバダの気温はどんなもんじゃろかと、自宅のAlexaに聞いてみます。
6度とな。寒そうなのでダウンジャケットをスーツケースに入れていきます。
ミスりました・・・時差を全く考えてませんでした・・・ネバダの夜の気温でした。12月頭でもラスベガスの日中はそんなに寒くなかったです。
薄手のジャケットで十分です。
また、砂漠だし、傘はいらんじゃろって事で折りたたみ傘をもっていくのも止めました。→ 結構な雨が降りました。

最後の投稿に持っていったほうが良いものと要らないものをまとめようと思います。

ついでに、私、若干偏食気味なのでカップ麺とフリーズドライのお味噌汁も持っていきます。*3

*1:DSOCはSansanにおけるデータ統括部門です。

*2:人生いろいろあるんです。ついでに父親の名前、ヨミがわかりづらい漢字なのです

*3:帰国後不幸の始まりでした。後述します

ナラティヴと向き合う

CTO の藤倉です。

先日、組織論・経営戦略論研究者であり埼玉大学大学院准教授の宇田川先生と、Biz/Zine という Web メディアで対談をさせていただきました。これは、その対談の後記です。

この対談企画は、宇田川先生の著書である『他者と働く──「わかりあえなさ」から始める組織論』出版を記念して、宇田川先生が様々な方と対談をするというものの一つです。対談記事は前編と後編で公開されました。

bizzine.jp

bizzine.jp

他者と働く──「わかりあえなさ」から始める組織論

他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)

こちらの本には、経営学者として多くの経営者の方々と語り、そこで得られた宇田川先生の知見がふんだんに盛り込まれています。全編を通じて多くの気づきと示唆を与えてくれるのですが、私が考える本書の最大の功績は、人がそれぞれに持っている倫理観や組織文化などに基づく解釈の枠組みを「ナラティヴ」という言葉で言語化してくれたことだと思っています。言語化されることで多くの人と共通の認識が持てるようになり、議論の俎上に載せることができるようになりました。

そして、ナラティヴの溝に起因する問題を適応課題として捉え、課題解決に向き合う姿勢を示してくれます。つまり、これらは属人的で解決不可能なものではなく、正しいアプローチによって解決することが可能な課題であるということを意味するのです。（本書の中では撤退も重要だと説いており、全てが解決できる魔法の書ではないことも重要です）

この種の課題は、多くの方が組織の中で経験しているのではないかと思います。

もちろん私もそうです。これまでマネージャとしての職務を行う上で何度も直面し、その度に自分なりの対応方法を考えてきました。本を読み進めながら、これまでの経験を振り返り、自分がやってきたことの本質を知る。自分がしてきたことに名前が付いていて、整理された状態で理解できる。そんな体験を繰り返しました。

この本は、組織で働く全ての人にお勧めできます。周囲の方々との相互理解、合意形成に課題を感じ、それを解決したいという意欲が強い方には特にお勧めです。

本当にあった京都のSansan

DSOC R&Dグループの小林幸司です。

Sansanの京都にある開発拠点 Sansan Innovation Lab(以下SIL) で勤務しています。

SIL執務室。もとは台所の土間を板間に改装しています。

SILイベント用スペース。たまに座椅子に座って作業することも

SILができて一年が過ぎました。京都の寒い冬、熱い夏を克服し、開発者がここで成果を上げ続けることが可能であることを実証できました。 これまでのSansanと京都、この一年のSansanと京都という視点で振り返っていきたいと思います。

これまでのSansanと京都

京都ラボ

Sansanが京都ラボを開設したのは2014年10月でした。 関西で転職先を探していた私は京都にオフィスを開設することを前提として2014年7月Sansanに入社しました。三か月間東京で単身赴任後、新設された京都ラボに移りました。

このときのオフィスはコワーキングスペースである share KARASUMA(現FVC Mesh KYOTO)でした。

当初は一人でしたが、約一年後にもう一人開発者が加わって、この10平米のスペースで約四年間開発業務を行っていました。このころ京都では市内にシェアオフィスの開設が相次ぎ、スタートアップ企業や個人事業主の働き方の一形態として認知されつつありました。

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:

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.

jmartinez 2019-12-19 11:00

コメントを書く

• もっと読む

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

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日間となかなかスピーディーでした。

登壇者の募集

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

タイトル決定

*1:画像内で触れられている河辺の登壇レポートはこちら Developers Boost KANSAI に「Eight iOS を支えるアーキテクチャ」というタイトルで登壇しました - Sansan Builders Box