サービスコア技術名刺データ化/Sansan R&D Architect Work Style

by Sansan

Slide 1

Slide 1 text

サービスコア技術名刺データ化 - 研究と開発と運用と - Sansan株式会社 DSOC (Data Strategy and Operation Center) R&Dアーキテクト島貴宏

Slide 2

Slide 2 text

自己紹介 - 島貴宏 - 2011年公立はこだて未来大学大学院修了 - 川嶋研究室, 画像処理専攻 - 2013年 Sansan株式会社入社 (2017年から札幌ラボ) - 私の入社と同時にR&D部門が創設されました - 以来、広く研究・開発・運用に携わっています - 2016年からチーフR&Dアーキテクトを名乗り、設計や運用の改善含め幅広く担当しています

Slide 3

Slide 3 text

今日お話しすること 1. 研究者と研究領域について 2. R&Dをどう世の中に出していくか 3. Sansan流 R&Dアーキテクトとは

Slide 4

Slide 4 text

DSOCの紹介

Slide 5

Slide 5 text

法人向け名刺管理サービス個人向け名刺アプリ Sansanの提供する2つの名刺管理サービス ➢ 名刺の正確なデータ化 ➢ 名刺管理の見える化による気づき・営業支援 ➢ データ分析からの新たな価値の提供

Slide 6

Slide 6 text

6 研究開発部門の位置づけ法人向け名刺管理サービス Sansanの開発、提供個人向け名刺アプリサービス Eightの開発、提供 R&D データ分析・研究開発（画像処理／機械学習・AI） Sansan事業部 Eight事業部 Data Strategy & Operation Center Sansan株式会社データ統括部門

Slide 7

Slide 7 text

7 Sansan における AI 活用の動機と背景大量の名刺データ化業務の自動化・精度向上サービス向上のためのデータ分析・活用「出会う、が、世界を変えていく」の実現

Slide 8

Slide 8 text

8 Sansan の R&D 博士（物理学）、博士（数理科学）、博士（計算機科学）各１名多様な研究者博士学位画像処理、データサイエンス（統計学、自然言語、機械学習）、社会科学・計量経済学・労働経済学、データビジュアライゼーションの各スペシャリスト ※世界的機械学習コンペ Kaggle のタイトルホルダ ※ Grandmaster 2名

Slide 9

Slide 9 text

研究分野の紹介

Slide 10

Slide 10 text

研究分野・研究者の紹介 • 画像処理・機械学習のエンジニアが多いです。 • その他、自然言語処理、労働経済学、社会科学等、多彩な研究領域のメンバーがいます。 • 名刺の認識は思った以上に難しい領域です。 • 名刺の繋がりは他のSNS等とは異なったデータであり、そこから価値を見出そうと奮闘しています。

Slide 11

Slide 11 text

11 脳科学項目判別の結果を学習 ○単体モデルで項目矩形、項目名の推定 ○精度 98 % ※画像はダミー名刺です。参考資料:”Pyramid Scene Parsing Network” Hengshuang Zhao, Jianping Shi, Xiaojuan Qi, Xiaogang Wang, Jiaya Jia. IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2017 https://hszhao.github.io/projects/pspnet/ ディープラーニングを用いた項目判定

Slide 12

Slide 12 text

12 脳科学ディープラーニングを用いた言語判定名刺画像から言語を判定 ○４言語（日英中韓）に対応 ○データ化フローの効率化 ○オペレータへの振り分けの自動化 ○精度 98 % 参考資料:”Deep Residual Learning for Image Recognition” Kaiming He, Xiangyu Zhang, Shaoqing Ren, Jian Sun https://arxiv.org/abs/1512.03385 言語判定モデル日本語名刺英語名刺中国語名刺その他言語韓国語名刺名刺

Slide 13

Slide 13 text

13 脳科学 AI 活用とワークシェアリング人とAIの共存による高精度／高効率の実現 AIの活用により、人のリソースをチェック工程に集中（ワークシェアリング）数千万枚／月の名刺データ AI：名刺画像の自動解析と入力 AI：ミスの抽出 ✓ 人：最終チェック再学習

Slide 14

Slide 14 text

14 脳科学実現したこと名刺データ化の自動化率を約 80％に高め、処理能力大幅アップ名刺画像の読取による名刺情報の入力ビジネスデータベース人力 × 機械学習名刺データ化の精度 99.9%

Slide 15

Slide 15 text

15 建築・不動産業界企業某大手ネットサービス企業 Eightの名刺交換履歴インターネットから最新動向を収集ープロファイリングインターネットから最新企業動向を収集し企業の特徴データから独自の業界マップを作成統計学・確率論キーワードの抽出自然言語処理

Slide 16

Slide 16 text

16 現職 Yonyon株式会社田中太郎前職 Sansan株式会社田中太郎例）時系列や人脈の類似性に基づく名刺の新旧判定、同一企業／人物判定など共通ビッグデータやネットワーク類似度に基づく、高精度な名寄せープロファイリング統計学・確率論自然言語処理

Slide 17

Slide 17 text

17 名刺交換の傾向を数値化し、ビジネスマンとしてどのようなタイプかを分析。ビジネスマンタイプ診断(β) ープロファイリング統計学・確率論自然言語処理

Slide 18

Slide 18 text

18 社会科学的アプローチ企業の特徴ベクトルの視覚化企業の業界親密度の視覚化商社A 商社B 商社C 商社D 商社E 大学・官公庁小売業金融業 A社情報通信業ーネットワーク分析統計学・確率論自然言語処理

Slide 19

Slide 19 text

19 人と人の出会いを最適化社内の人脈を有効活用レコメンデーションー3分野の応用統計学・確率論自然言語処理企業と企業の出会いを最適化（検証中）コンタクトすべき企業のホワイトリストを生成知人の推測より人脈を広げる企業と人の出会いを最適化ユーザーに合った求人マッチングパーソナライズされたタイムリーな情報を提供ニュースフィードのレコメンデーション

Slide 20

Slide 20 text

20 S a n s a n レコメンデーションエンジン Sansanに蓄積された名刺情報成果の理解＋人物の分析出会いがもたらす成果の予測出会うべき時、出会うべき人を確実に捉える S a n s a n ビジネスデータベース出会いの最適化によって働き方を革新するー出会う、が、世界を変えていくーー3分野の応用（レコメンデーションがもたらす未来の価値）統計学・確率論自然言語処理

Slide 21

Slide 21 text

21 AI活用・研究の紹介 Sansan Labs AI を活用した実験的機能 / サービスの提供社員の強みをキーワード化バーチャル組織図企業間距離の変遷社内キーパーソン Sansan Labs ABMダッシュボード顧客ごとのタッチポイントを俯瞰自分や同僚の強みを可視化自社と親密/疎遠になっている顧客を抽出人脈をもとに真のチームを可視化顧客との関係拡大に寄与した社員を抽出

Slide 22

Slide 22 text

R&Dでの研究開発業務の流れ

Slide 23

Slide 23 text

大まかに2つの領域 • データ化の自動化 • データベースから、ユーザへの新たな価値の創出

Slide 24

Slide 24 text

目標設定 • 特に名刺データ化であれば、求められるQCDSがある。その実現のため取り組む。 • データ化を、間違えなく、高速に、かつセキュアに • RecallとPrecisionの対立とおおむね言い換えられる • データベースから何か意味のある情報を見出す、といった研究ならば、目標から自分で見つけに行くことになる。

Slide 25

Slide 25 text

研究開発の例：自動項目入力 • 各項目についてOCRをかける。 • 答えがある(定義できる) ので、比較的システム開発の型にはめて進めやすい。 • 人間が判断する正解を真値として、差を最小化する

Slide 26

Slide 26 text

研究開発の例：自動項目入力 • R&Dは万事、リリースしてからが本番。 • 予期しなかった新たな名刺への対応 • 業界等による独特な名刺の対応（国会議員秘書の名刺などが顕著） • デザイン性の高い”変わった”名刺への対応 • 日本国外の名刺への対応

Slide 27

Slide 27 text

研究開発の例：影除去 • 白くして見た目をきれいにする。 • 影領域を推定し、影なら強めに色を飛ばし、それ以外は穏やかに。 • 白地に黒字の「普通の」名刺なら大体うまくいく。カラフルな名刺、影が激しいケース等が難しい。

Slide 28

Slide 28 text

研究開発の例：影除去 • 弊社の名刺は非常に難しい。顔写真が「影っぽい」ので間違えがち。 • 答えを決め難い。テストケースすら書きにくい。 • OCRの精度（成功しやすさ）で測る • PSNRで測る [人間の感覚とあまり一致しない] • 人間の知覚に近い尺度で測る (ECCV 2018 PIRM Workshop で示されている手法など https://www.pirm2018.org/PIRM-SR.html) こういうのも何とかしたい

Slide 29

Slide 29 text

精度向上への向き合い方 • きりがない • ある程度で一旦リリースし、世に出してみたほうが得られるものが多い • それが許される現場がありがたいですね • 機械学習はそもそも100%の判定をするためのものとは違うと考えている。人間の判断と併用するのが望ましい捉え方。

Slide 30

Slide 30 text

大学との研究の違い • (弊社の場合) 最新の研究を追いかける必要は、必ずしもない。枯れた技術でも充分成果になる。 • むしろノウハウがあり製品化が容易 • ある程度の段階での割り切り(諦め?)も肝心 • とはいえ、競合企業もいる。枯れた技術で出したその次から、試されていく。 • 研究自体を追い求めたいか、世に出すことを価値と捉えるか。進路はよくお考え下さい！

Slide 31

Slide 31 text

研究者が成果を出す仕組み R&Dアーキテクト

Slide 32

Slide 32 text

DSOCでの研究者(R&Dメンバー) • Sansanでは、「R&D」つまり研究も開発もでき、成果をカタチにできる人を採用してきている。 • 具体的には、高精度なライブラリの開発からWebAPIの開発、ログやインフラの検討、運用まで、一人でこなしてほしい。 • とは言うものの、やはり強みは研究要素であり、一般の開発onlyな技術者とは違う。強みを生かすのは、他に代えの利かない研究要素であるべきとも思う。

Slide 33

Slide 33 text

研究をカタチにする、縁の下の力持ち • 研究要素についてある程度知識があり、 • 開発にも長けて、適切な実装、設計やインフラ等の助言・実行を行う • そんな役割がほしい！そんな人間はなかなかいないのだが

Slide 34

Slide 34 text

機械学習データ分析自然言語処理画像認識 R&D Group の構成研究員 R&D アーキテクト

Slide 35

Slide 35 text

R&Dアーキテクトとは - 2016年8月に創設 - R&Dチームがより円滑にR&Dできるために基本的に何でもする - ただし、R&Dの作成するシステム全体のアーキテクチャを設計する者ではない

Slide 36

Slide 36 text

ありがちな仕組み - 研究者がアルゴリズムを作る - 開発者がそれをライブラリやフロントエンドシステムに組み込む - これは全く悪くはないと思います。アルゴリズムシステム開発研究者開発者サービス

Slide 37

Slide 37 text

分業制の課題 - そもそも人(開発者)が足りない - 開発者も研究要素にある程度詳しくないと、開発しづらい - 逆に研究者も開発技術が皆無だと製品化が遠い - 研究で手一杯なので開発環境が荒れがち、レガシーになりがち、手作業の職人芸がいつまでも残る

Slide 38

Slide 38 text

分業制の課題 - そもそも人(開発者)が足りない - 開発職の採用をかけても、あまり魅力的に映らないらしい - 研究者の下請け的イメージ - サービスに直接関わる華々しい部隊と比べて、最新の技術に触りにくそうだし、キャリア的にどうなの？ - かたや研究者が開発にも全力投球するとしても、彼らにとっては実装は手段であり、それ自体に楽しみを持ちにくい人がいる（印象）

Slide 39

Slide 39 text

分業制の課題 - 開発者も研究要素にある程度詳しくないと大変 - 一般的に開発チームはある程度全員で共通の技術知識を持つものだが、 R&Dではそれが乏しい。 - 得意な領域が異なる (言語:C++, Python, R, … 機械学習やWeb等のフレームワークも多彩) - Gitに不慣れな人も普通にいる - ローカルで少量の処理しか念頭にない実装が出てきて、それを製品化可能なレベルにもっていくのが大変。 - 負荷等のインフラ問題、依存データの問題、実装の問題、ログの問題、など

Slide 40

Slide 40 text

分業制の課題 - 研究で手一杯なので開発環境が荒れがち - ソースコードに “C:/tanaka/hoge.dat” を読んでいる箇所がある、といったことがよくある (自分でしか動かせない) - デプロイや動作検証作業が職人芸を要する - その人がもし辞めた時に大変

Slide 41

Slide 41 text

そこで - 「R&Dアーキテクト」を新設 - 「アーキテクト」ではありません。「R&Dアーキテクト」 - 世間でいうアーキテクトとは違うと考えるため - 研究員でありつつ、製品化に関わる設計・運用なども面倒を見る - 研究の事情も開発の事情も分かる人 - 開発の肩代わりではなく、あくまで助言者

Slide 42

Slide 42 text

R&Dアーキテクトの業務内容 - 技術指針の決定 - コーディング規約 - Web Application Framework の標準化 - 新サービス設計の相談役 - 設計レビュー - コードレビュー - 日常的に質問を受ける - 開発環境整備 - シンクライアント化 - CI/CD環境の構築 - 社内ライブラリ管理サーバの構築 - ライブラリやミドルウェアのアップデート - 基盤構築 - OCR共通処理サービス - KPI - 障害対応 - システム運用 - たまに研究開発

Slide 43

Slide 43 text

R&Dを支える “縁の下の力持ち”

Slide 44

Slide 44 text

R&Dアーキテクト創設の経緯 - アーキテクトの話が出る前後で、実はそんなに業務は変わっていない。名前が付いたのみ。 - 以前は、“雑用”ばかりで研究できてないな… と鬱々とすることがしばしば。名前を付けておおっぴらにすることは大事。 - 業務改善系はなかなか着手し難く、おおっぴらに担当できる。私の名刺に入れた肩書。チーフ！と家族に喜ばれます

Slide 45

Slide 45 text

R&Dアーキテクト業務紹介 - いくつか例にあげます

Slide 46

Slide 46 text

例1. シンクライアント化 - 以下の課題から - さまざまなデータを取り扱う - 本番データを用いて開発・分析を行う - ローカルに本番データを取得するのは怖い - ハイエンドPCに縛られる - 重い - 在宅勤務や障害対応のためにPCを持ち帰るのは苦行 - サービスの価値をいち早く届けたい

Slide 47

Slide 47 text

構成

Slide 48

Slide 48 text

効果 - マシンの軽量化に成功（約500g） - どこにいてもネットさえ繋がれば開発できる - 試作したアプリケーションを気軽に社内公開できる - ステージングのアプリケーションとの疎通ができる

Slide 49

Slide 49 text

例2: CI導入 • 今どき誇るものでもないが、研究者だけの部隊だと割と導入困難 • GitHubと連携した自動テスト・自動デプロイ、自動パッケージ化等を実現 • 「研究者も開発者」だからこそ意義がある。Pull requestを出さないと話が始まらないようにする。 • テストファーストの根付き・デプロイ高速化

Slide 50

Slide 50 text

例3. コードレビュー • 開発についてよりよい助言のためには、見ておかないと始まらない • 研究の実装は日々少しずつdiffが出てくるものではなく、ドカッと一気に pushされがち。大変。 • 朝から晩まで見ていることがあります大体土日は草生えていませんホワイトですよ！レビューが多い

Slide 51

Slide 51 text

例4. 障害対応 • アラートの一次受け • OpsGenieにより、アラートの通知先限定とエスカレーション研究者に極力集中できる環境を。

Slide 52

Slide 52 text

例5. 設計レビュー • 作り始める前に、どういう構成が望ましいか、研究メンバと相談する時間を設ける。 • アドバイス項目の例 • それはLambdaのほうが良いかも？ • DynamoDB / RDS / Elasticsearch / … • 監視の方法 (WebAPI / バッチ) • ログ

Slide 53

Slide 53 text

例6. ライブラリ整備 • 2,3年経った頃から技術的負債が目立つように。 • C#の実装は「社内NuGetパッケージ」化して整理整頓。 30個前後のパッケージに分割。依存関係の理解が難しい。依存の基底では特に互換性維持に大変神経を使う。セマンティックと日付の折衷バージョニング。依存関係マトリクス (Ndepend)

Slide 54

Slide 54 text

R&Dアーキテクトは開発職？ • ここまで、とても開発エンジニアくさい。 • しかし、背景に研究要素や事業知識を持っているからこその働き。 • 純粋な開発エンジニアだと、イライラして投げ出していたでしょう。 • 現在でも、研究的なことも時々担当している。二刀流

Slide 55

Slide 55 text

普段の苦労

Slide 56

Slide 56 text

普段の苦労 • セキュリティ • 精度との板挟み • 過去作ったシステムのお守り (技術的負債) • 一番先輩だが年上が多い • コードレビュー • 専門性の薄さ • コミュニケーション

Slide 57

Slide 57 text

セキュリティ • 顧客から預かっている名刺データは万が一でも漏洩などあってはならない。開発はできるだけダミーデータで行う。 • しかし本物の名刺データでないと検証し難いことも多い。R&Dではこのジレンマが特に多い。 • 対策の例 • 本番データから再現に必要な要素のみ抜き出す・データをマスクする • クラウド環境で開発し、ローカルにデータを残さない

Slide 58

Slide 58 text

精度との板挟み • Sansanのデータベースは、誤りが無いからこそ価値がある。 • R&Dで自動化することは、どうしても精度に弱みが出てしまう。自動化作ってよこのミスは致命的精度上げられない？両立しがたい

Slide 59

Slide 59 text

過去作ったシステムのお守り • 手がけたシステムが増えるにつれ、だいたい日々何かしら障害が出る。 • その調査や修理をしていたら1日終わることも多い。 • 深夜・休日も常に障害アラートにおびえて精神を病みます。 • 障害を出しにくい実装やインフラについての知見は年々高まっている。 • 近年のサーバレスの潮流(AWS Lambda等)は効果的。 • 人を増やさないと…

Slide 60

Slide 60 text

一番先輩だが年上が多い • 26歳で入社して6年、まだ若いつもりですが、R&Dチーム最古参。 • チームは20人以上で、年上が過半数。若干やりづらいことはあります。 • お互い敬語 • もしこれで最年長だと図に乗っていた気がするので、ちょうど良いのかもしれません。

Slide 61

Slide 61 text

コードレビュー • リリースにはGitHubのpull requestを義務付け、私は全て目を通す。 • 専門性が高くて、何が書いてあるかよくわからない • なかなか「研究者らしい」実装 • レビューしていたら1日終わるのはよくある • ここ数年来の経験から、見る側も見られる側も、場数を踏むしか無いと思っています。必要次第でヘルプに入りつつ、粘り強くコメント。 • かなり運用に乗ってきたと感じます。

Slide 62

Slide 62 text

専門性の薄さ • 研究の専門性も乏しいし、開発力も突出しているわけでもないと、ずっと悩んでいました。 • R&Dアーキテクトになったことで、研究で最先端を進むことは100%諦めたと思っています。 • 今でもこの悩みは晴れませんが、こんな役目も世の中合ってしかるべきと信じています。実際頼りにされている実感は大きいです。 • ドラクエの「賢者」になれたらいいと思っています (いいところ取りで強い) • FFの「赤魔導士」だと微妙ですね… はてさてどちらなのか

Slide 63

Slide 63 text

コミュニケーション • 研究者は、空気が独特。あせらずじっくり聞く。 • 札幌に来て、職場の微妙な空気感は感じられなくなった（感じずに済むようになったとも言う）。 • コードで語る、テレビ会議、中長期のタスクで管理。周りの尽力かもしれませんが、なんとか回っています。

Slide 64

Slide 64 text

最後に

Slide 65

Slide 65 text

きょうのまとめ • SansanのR&Dには、多彩な分野の研究者がいます • 「データ化の自動化」と「新しい価値創出」に取り組んでいます • 研究者だけでは難しい面を「R&Dアーキテクト」が受け持ち、成果に結びつけています • 我々、いわゆる「AI」をやっていますが、日々の業務は泥臭いです

Slide 66

Slide 66 text

いちおう、雇われ人として R&Dアーキテクト含め、エンジニアを絶賛募集中！ご興味ある方はぜひ連絡いただけると幸いです。 https://jp.corp-sansan.com/recruit/graduate

Slide 67

Slide 67 text

おしまい