Sansan Tech Blog

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

【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

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

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

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

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

続きを読む

オンライン開催となったDEIM2020に協賛企業として参加しました

こんにちは、DSOC 研究開発部の橋本です。前回から引き続きファイアーエムブレムをぼちぼちやっていますが、全ての攻撃を躱すユニットを作ってしまうと良くも悪くも一気に簡単になってしまい、なんだかなあ、となっています。

さて、今回は3/2(月) ~ 3/4(水) で開催されたDEIM2020に、Sansan DSOC研究員の奥田、糟谷、橋本の3人で協賛企業として参加してきましたので、その報告をいたします。

DEIMについて

DEIM とは「データ工学と情報マネジメントに関するフォーラム」のことで、情報科学における様々な研究トピックについて議論を行えるワークショップです。
例年合宿形式で開催されており、今回は福島県の磐梯熱海ホテル華の湯で開催される予定でしたが、新型コロナウイルスの感染拡大の影響もあり、オフラインでの開催が中止となってしまいました。わずか2週間の準備期間にも関わらずオンライン会議システムを構築および運営していただき、ありがとうございました。DEIM2020の運営の皆様に感謝申し上げます。このような困難を乗り越えたオンライン学会に参加することができて、とても光栄でした。

f:id:w-hash52:20200311190745p:plain
オンライン開催になっても参加者数はほぼ変わらなかったようです。すごい。

オンライン会議について

DEIMの通常の発表は、全てWebExを通して行われました。プレナリーセッションは1つのチャンネルで、一般の口頭セッションは各セッションごとにWebExのチャンネルが割り振られ、各自興味あるチャンネルに入っていく、という形です。もちろん全てのチャンネルを確認したわけではないですが、いずれのチャンネルにも30人程度は常に入っていたようです。
また、インタラクティブセッションと呼ばれるポスター発表のセッションですが、こちらはpdfが貼られており、Wherebyのリンクを踏むと発表者に直接質問に行けるシステムになっていました。
さらなる細部の詳細についてはWIkiに記載されていますが、このようにオンライン学会開催についてGithubで知識共有がなされているのは素晴らしいなと感じました。

続きを読む

B2B 企業ブランドとは何か vol.3

こんにちは。DSOC研究開発部の真鍋です。
今回は、B2Bブランドに関する論文の例として、Brand equity in the business-to-business market (Industrial Marketing Management, 33(5), 371–380, Bendixen, M., Bukasa, K. A., & Abratt, R.) という論文を、以下に簡単にまとめてみたいと思います。

リサーチクエスチョン

この論文のでは以下のリサーチクエスチョンにアプローチしました。

  • P1: ブランド価値は、B2B 市場において、ブランドの価格プレミアムを支払う意思として表れる
  • P2: 買い手に、ブランドに対するロイヤルティがある場合、ブランドを他の人々に推奨し、さらに同社の別の製品に対する購入意向を有する
  • P3: 知覚品質は、ブランド価値を生む、主要な要素である
  • P4: B2Bブランド認知の主要なソースは、展示会である
  • P5: 購買意思決定を行うグループはそれぞれ、ブランドに対し、様々なレベルの重要度を認識し、それぞれ様々なコミュニケーションチャネルを求める
方法
  • 対象のブランド: 中電圧屋内サーキットブレーカーパネルのメーカー
  • 調査対象: 南アフリカの産業企業の購買部門。企業は工場や電力供給会社など。3 年以内にパネルを購入した企業が対象
  • 分析方法: アンケート調査による分析。コンジョイント分析による解析。
  • 回答者: 上記対象企業から、54 名。
  • コンジョイント分析: 回答者は、「ブランド」「価格」「納期」「技術」「交換部品のリードタイム」という属性の様々な要素(全部で 16 個) を、好ましい順、または、購入したいと思う順に、並び替える。各人のランキングデータを集計し、コンジョイント分析により、各属性の部分効用値を算出する
  • その他の質問: 回答者は、ブランドの他の製品を購入したいか、他人に推奨したいか、ブランド認知の手段、ブランド価値の理由、などについて、1-5 段階で回答する
結果
  • コンジョイント分析: 購入に対する効用値は、「納期」「価格」「技術」「ブランド」「交換部品」の順。「ブランド」は 4 番目。
  • ブランドの効用を価格の効用と比較した場合、平均価格の 6.8 %、無名のブランドの 14 % 分の価値があり、これはブランドプレミアム価格とみなせる (高いブランドの製品は、無名ブランドの価格の 14 %上乗せと、同等の効用)。
  • 好ましいブランドと他製品への関心の高さの間には、関連がみられる (Kruskall–Wallis test)。また推奨意向も、好ましいブランドと関連がある。
  • ブランドの知覚と最も関連が高い要素は、「品質」であった。次に「信頼」「パフォーマンス」と続く。
  • ブランド認知のソースは、「技術コンサルタント」が最も高く、次に「営業」。展示会は 4 番目。
続きを読む

© Sansan, Inc.