Sansan Tech Blog

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

【Geek Seek Toolsで買われた、気になるモノ達】番外編2「Sansanで人気のあったガジェットまとめ(2019年版)」

f:id:hartmann3555:20200311125212j:plain

はじめに

こんにちは。DSOC Data Direction Group でデータエンジニアをしている千葉祐大です。

今年の初めくらいから手書きでのジャーナリングを始めているのですが「やっぱり良いモノを使いたいよね」ということで、お高いノートや筆記用具を日々物色しています。
そんな中で長年探し求めていた、Craft Design Technology の Chrome Mechanical Pencil *1を入手してしまい、ますますジャーナリングが捗る毎日です。

さて、この連載は弊社の社内制度である Geek Seek Tools *2で購入されたガジェットの中から、僕がイケてると感じたものを気の赴くままに紹介していく連載となっています。

今回は、前回に引き続き番外編として、2019年に社内で買われたガジェット達を集計し、どのジャンルのどんな製品が最も買われたのかというのランキング形式でまとめてみました。

生産性を上げることに効果的だと選ばれた、栄えあるガジェットはどういったものなのでしょうか、必見です!

*1:このシャーペンは10年くらい前に発売した当初から気になっていたのですが、強気の価格設定に手をこまねいているうちにディスコンしてしまい、現在ではオークションでもほとんど出品されていない個人的に幻の品でした。 たまたま出品されているのを発見して、しかも定価に近い価格で箱付きだったので、迷わず入札し購入することができました。いやー、よかったです。

*2:生産性向上に資するガジェット・デバイスその他が購入しやすくなる制度。Geek Seek Tools の詳しい説明については第1回をご覧ください。

続きを読む

【ML Tech RPT. 】第15回 構造に関連する機械学習を学ぶ (1)

f:id:ssatsuki040508:20181210005017p:plain
DSOC研究員の吉村です. 最近は (ファッション誌ではなく) ファッション史にハマっていて, 色々本をあさっています. 世の中の流れをファッションで変えてきたクリエイターやデザイナーの逸話はとても面白いです.

さて, 今回からは構造に関連する機械学習についての話をしていこうと思います. 構想段階では, 構造学習 (Structured Learning, Structured Prediction, Structured Output Prediction) をテーマにしようとしていたのですが, 構造に関わる機械学習技術を広く扱いたかったため今回は少し広いテーマを立てています. 具体的には、入力か出力に何らかの特殊な構造がくるような問題設定を取り扱います. まずは, 構造をモデルに組み込む意味や, 具体的な問題設定を紹介します.

構造をモデルに組み込む意味

オーソドックスな機械学習では, 入力に属性を並べた特徴ベクトルを与えて, それに対応する連続値や離散値を適切に出力するようにモデルを学習します. このような形の問題設定で構造に関連する機械学習を考えると, 扱える問題の幅に限界があったり, 学習や予測が非効率になることがあります.

そこで, もし, 構造を適切にモデルに反映させることができれば, より広い問題を機械学習で扱うことができ, また, より少ないデータ量で妥当な予測ができるモデルを学習できるようになることが期待できます.

特定の構造を出力する問題設定の場合には, 適切な構造を探し出すために構造を探索する必要があります. この時, 対象の構造にあった最適化アルゴリズムを用いることで, 効率よく現実的な時間で結果を得ることが可能となります.

続きを読む

【Intern CV Report】Trainsによる実験管理

f:id:S_aiueo321:20190404193803p:plain

こんにちは,DSOC 研究開発部 インターン生の内田です.先日プチ卒業旅行として伊豆の温泉旅館に行ってきました.伊豆といえば バナナワニ園 ですよね,異論は認めません.バナナワニ園のワニたちは基本的に動かないので思わず「休日の俺じゃん」って呟いてしまいました.

さて,今回はCVとは直接関係ないですが,多くの人が頭を悩ませている実験管理に関する話題です.

機械学習と実験管理

機械学習,特に深層学習を用いたプロジェクトにおいては,精度を引き出すためにハイパーパラメータが非常に重要です.一口にハイパーパラメータといっても,モデルサイズや学習率,バッチサイズなど挙げるとキリがありません.

最適なハイパーパラメータを定めるには,Grid Searchなりでパラメータを探索し,精度などと共にロギングする必要があります.バナナワニ園のワニのように怠惰な私にとって,パラメータや結果をマメに記録しておくことは簡単なことではありません.現状では表示可能な項目はなるべくTensorBoardに集約して,TensorBoardのログディレクトリにその他の結果を全部吐かせるようにしています.これなら後からでも漏れなく参照できるので安心ですが,TensorBoardに表示できない項目の検索・比較は面倒です.

上記の背景から,もう少し高機能な実験管理ツールを使ってみたい気持ちが常々あります.ただし,導入にあたってはいくつか条件があります.パッと思い当たるのは次のような感じです.

  • 移行コストが低いこと
    ロガーに値を手動で報告する場合,ツールを変えれば当然プログラムの書き換えが生じます.一気に書き換えるのも手ですが,バックアップとしてローカルのログも残しておきたかったりもするので,ロガーの命令をキャッチしてよしなにやってくれると嬉しいです.

  • モデル管理機能
    学習済みモデルと実験を紐づけてUI上で管理できると嬉しいです.

  • 社内サーバでのホスティング
    最近 Comet.mlNeptune.ai のようなクラウド上で実験管理を行えるSaaSが出てきていているのですが,業務で扱うデータの性質上,外部のサーバにデータを送信するのはご法度です.とはいえ個々人のインスタンスに閉じているのもスケールしなさそうなので,社内サーバにデプロイして共有できる程度が望ましいです.

続きを読む

【Techの道も一歩から】第26回「BERTで日本語固有表現抽出器を作ってみた」

f:id:kanjirz50:20190104142720j:plain

こんにちは。DSOC 研究開発部の高橋寛治です。

流行りの BERT(Bidirectional Encoder Represenations from Transformers) ですが、論文を読んだあと、マスク部分を当てるというサンプルを動かしその的確さに驚いたところで、手が止まっていました。

今回は、BERTの特徴である優れた言語モデルを利用して、日本語固有表現抽出器を作ってみました。 その手順をいくつかかいつまんで紹介します。

準備から学習

BERT の実装には、 Hugging Face, Inc. が提供する transformers ライブラリを利用します。 実装は、固有表現抽出のサンプルに準じて行います。

transformers ライブラリは、例によって pip install transformers で完了します。素晴らしい。

ディレクトリ構成のイメージ

data ディレクトリには元テキスト(raw)と処理済み(preprocessed)のテキストを格納します。(これから作るテキストなので、現時点では空です) model ディレクトリには学習した結果や評価結果を格納します。 preprocess.pyrun_ner.pyutils_ner.py は transformers のレポジトリから取得します。 run_training.sh は後で自分で書きます。

.
├── data
│   ├── raw
│   │   ├── train.txt
│   │   ├── dev.txt
│   │   └── test.txt
│   └── preprocessed
│       ├── labels.txt
│       ├── train.txt
│       ├── dev.txt
│       └── test.txt
│
├── model
├── preprocess.py
├── run_ner.py
├── utils_ner.py
└── run_training.sh
続きを読む

オンライン名刺の価値

こんにちは、SansanでCPOとしてプロダクトの責任者をやっている大津です。

先日弊社のオンライン記者会見において、「オンライン名刺 / オンライン名刺交換」の発表がありました。
実際のリリースは6月ということでもう少し先ですが、開発現場に関わる立場としては、今が正に勝負所という状況です。

世の中の状況が状況でしたので、出来るだけポジティブかつ違和感ない形で発表したかったわけですが、SNS上でも予想以上にたくさんの良い反響をいただきまして嬉しい限りです。

今回の記事では、我々が如何にしてこの機能の着想に至ったか、そのプロセスや開発に込めた想いを少しお話しできたらと思います。


f:id:s_yuka:20200317144356p:plain

名刺なら気軽に渡せる

「名刺なんて交換しなくてもFacebookでいいよね」「名刺いつまであるんだろうね」よく知り合いにもこんなことを言われますが、その度に、プロフィール交換と名刺交換は同じものに見られやすいんだなと感じます。

私も名刺と深く関わる前は同じ感覚を持っていましたが、今となっては全然別のものに見えています。

昨今の世には、デジタルプロフィールを交換できるサービスが様々あります。Facebook、LinkedIn、弊社のEightも似たポジションですね。
これらには必ずついて回る大きな不都合があります。

それは、「登録しているプロフィール情報をリッチにすればするほど、見せる相手を限定したくなる」という不都合です。

仕事で100人に会ったとして、その100人全員に見せようという気にはなれません。人によるとは思いますが、何らか無意識にでもポリシーを持って見せる相手を選ぶのではないでしょうか。結果として、記録される出会いの量は一定量に絞られることになりませんか?

一方、名刺はどうでしょう。

仕事で関わった人に対して自分の名刺を渡すことを躊躇したり、相手を選んだりする人は少ないのではないでしょうか。
100人に出会ったなら、100人に気軽に渡せるのが名刺だなと思います(もちろん手持ちの名刺が切れていなければ、ですが)。
会社に持たされているから、という無意識な言い訳ができるからなのか、記載されている情報が限られているからなのか。
間違いなく言えることは、名刺に記載されている情報が適量でとどまっているからこそ生まれている気軽さであり、記載情報をリッチ化すればするほど損なわれてしまう特性ではないでしょうか。

気軽に渡せる程度の情報でとどまっていること、渡すことに抵抗感がないところまで習慣化されているところが名刺の強みなんです。

もし名刺交換の記録を漏らさずデジタル化出来たなら、結果として仕事上の出会いのほとんどが漏れなく記録されることになります。
ビジネスの出会いの証として、名刺および名刺交換という習慣は独特な強みを持っていると言えます。

続きを読む

Sansan iOS アプリの内側

こんにちは。 Sansan iOS アプリエンジニアの中川です。

Sansan iOS アプリは B to B アプリの性質上、 App Store のプレビューやログイン、新規登録くらいしか未登録ユーザーが触れられる領域がなく、ビジネスマンならともかく、エンジニアがそのアプリがどのような技術を使って、エンドユーザーへどんな体験を提供しているのかを知るのは難しいです。

そこで、今回はそんなエンジニア向けに Sansan iOS アプリを紹介してみます!

続きを読む

地方拠点のリードエンジニアとして意識していること

関西支店勤務で、プロダクト開発部のチーム MAIDO でエンジニアをしています、奥野です。

リードエンジニアになってもうすぐ1年、開発部内の関西支店における取りまとめ役として動き始めて8ヶ月になります。
1年たったということで振り返ってみると、地方拠点ならではの課題があり、それなりに向き合ってきたと思っています。

関西支店での自分の役割

Sansan プロダクト開発部として、関西支店には開発チームが2チームあり、それぞれリードエンジニアがチームを率いています。 リードエンジニアは、いわゆる開発プロジェクトのプロジェクトリーダーの役割になり、プロダクトマネージャーを含めチーム外との窓口にもなります。

その2チームをひとまとめにして、関西支店のエンジニア組織として、拠点における環境改善や人材採用などに向き合っています。その旗振り役かつ部門との窓口として取りまとめも行っています。

バックログ一本化の波

私がリードエンジニアに就任した時期に、Sansan プロダクト開発部では大きな変化がありました。
それが「プロダクトバックログの一本化」です。

buildersbox.corp-sansan.com

バックログが一本化されるまでは、開発チームが個々にドメインを担当しており、そのドメインに関するバックログを自己管理し、開発保守を行っていました。
担当外のドメインに携わることはほとんどなく、担当ドメイン内に開発が閉じており、本社の他のチームと関わる必要性はほとんどありませんでした。ドメインをまたぐような問題が発生したとしても、プロダクトマネージャーが交通整理するため、開発チームメンバーが他のチームと調整することは少なかったです。

そのような中で、バックログが開発部全体で一本化されました。
開発部全体として優先順位付けされたバックログに合わせて開発することになりました。そのため、主担当ドメインは継続していたものの、担当ドメイン以外のバックログについても優先順に合わせて開発しなければなりませんでした。
これまでは、関西支店の開発チームの中で閉じていればよかったのですが、そうではなくなりました。

ドメインが変われば、その担当プロダクトマネージャーも変わります。 これまで関わりのなかった、プロダクトマネージャーやデザイナーと開発をすすめることになりました。 また、担当ドメインではないため、他チームのエンジニアの有識者に聞く、レビューしてもらう必要が出てきました。

開発プロセスも統一されたことで、自分たちのやり方で進めること、自分たちだけで意思決定することが難しくなりました。 実際にプロジェクトを進めていく上でも、何度か壁にぶち当たることがありました。

続きを読む

© Sansan, Inc.