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

■イベント
公立はこだて未来大学での授業

■登壇概要
タイトル：サービスコア技術名刺データ化 -研究と開発と運用と-
登壇者：Data Strategy and Operation Center R＆Dアーキテクト 島 貴宏

▼Sansan Builders Box
https://buildersbox.corp-sansan.com/

Transcript

1. サービスコア技術 名刺データ化 - 研究と開発と運用と - Sansan株式会社 DSOC (Data Strategy and Operation Center) R&Dアーキテクト 島 貴宏
2. 自己紹介 - 島 貴宏 - 2011年 公立はこだて未来大学大学院修了 - 川嶋研究室, 画像処理専攻 - 2013年 Sansan株式会社入社 (2017年から札幌ラボ) - 私の入社と同時にR&D部門が創設されました - 以来、広く研究・開発・運用に携わっています - 2016年から チーフR&Dアーキテクト を名乗り、設計や運用の改善含め幅広く担当しています
3. 今日お話しすること 1. 研究者と研究領域について 2. R&Dをどう世の中に出していくか 3. Sansan流 R&Dアーキテクトとは
4. DSOCの紹介
5. 法人向け名刺管理サービス 個人向け名刺アプリ Sansanの提供する2つの名刺管理サービス ➢ 名刺の正確なデータ化 ➢ 名刺管理の見える化による気づき・営業支援 ➢ データ分析からの新たな価値の提供
6. 6 研究開発部門の位置づけ 法人向け名刺管理サービス Sansanの開発、提供 個人向け名刺アプリサービス Eightの開発、提供 R&D データ分析・研究開発 （画像処理／機械学習・AI） Sansan事業部 Eight事業部 Data Strategy & Operation Center Sansan株式会社 データ統括部門
7. 7 Sansan における AI 活用の動機と背景 大量の名刺 データ化業務の 自動化・精度向上 サービス向上のための データ分析・活用 「出会う、が、世界を変えていく」の実現
8. 8 Sansan の R&D 博士（物理学）、博士（数理科学）、 博士（計算機科学） 各１名 多 様 な 研 究 者 博 士 学 位 画像処理、データサイエンス（統計学、自然言語、機械学習）、 社会科学・計量経済学・労働経済学、データビジュアライゼーションの 各スペシャリスト ※世界的機械学習コンペ Kaggle のタイトルホルダ ※ Grandmaster 2名
9. 研究分野の紹介
10. 研究分野・研究者の紹介 • 画像処理・機械学習のエンジニアが多いです。 • その他、自然言語処理、労働経済学、社会科学等、多彩な研究領域のメン バーがいます。 • 名刺の認識は思った以上に難しい領域です。 • 名刺の繋がりは他のSNS等とは異なったデータであり、そこから価値を見 出そうと奮闘しています。
11. 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/ ディープラーニングを用いた項目判定
12. 12 脳科学 ディープラーニングを用いた言語判定 名刺画像から言語を判定 ◦４言語（日英中韓）に対応 ◦データ化フローの効率化 ◦オペレータへの振り分けの自動化 ◦精度 98 % 参考資料:”Deep Residual Learning for Image Recognition” Kaiming He, Xiangyu Zhang, Shaoqing Ren, Jian Sun https://arxiv.org/abs/1512.03385 言語判定モデル 日本語名刺 英語名刺 中国語名刺 その他言語 韓国語名刺 名 刺
13. 13 脳科学 AI 活用とワークシェアリング 人とAIの共存による高精度／高効率の実現 AIの活用により、人のリソースをチェック工程に集中 （ワークシェアリング） 数千万枚／月 の 名刺データ AI：名刺画像の 自動解析と入力 AI：ミスの抽出 ✓ 人：最終チェック 再学習
14. 14 脳科学 実現したこと 名刺データ化の自動化率を約 80％に高め、処理能力大幅アップ 名刺画像の読取 による名刺情報の入力 ビジネスデータベース 人力 × 機械学習 名刺データ化の精度 99.9%
15. 15 建築・不動産業界 企業 某大手ネットサービス企業 Eightの 名刺交換履歴 インターネットから 最新動向を収集 ープロファイリング インターネットから最新企業動向を収集し 企業の特徴データから独自の業界マップを作成 統計学・確率論 キーワードの抽出 自然言語処理
16. 16 現 職 Yonyon株式会社 田中 太郎 前 職 Sansan株式会社 田中 太郎 例）時系列や人脈の類似性に基づく名刺の 新旧判定、同一企業／人物判定 など 共 通 ビッグデータやネットワーク類似度に基づく、 高精度な名寄せ ープロファイリング 統計学・確率論 自然言語処理
17. 17 名刺交換の傾向を数値化し、ビジネスマンとしてどのようなタイプかを分析。 ビジネスマンタイプ診断(β) ープロファイリング 統計学・確率論 自然言語処理
18. 18 社会科学的アプローチ 企業の特徴ベクトルの視覚化 企業の業界親密度の視覚化 商社A 商社B 商社C 商社D 商社E 大学・官公庁 小売業 金融業 A社 情報通信業 ーネットワーク分析 統計学・確率論 自然言語処理
19. 19 人と人の出会いを最適化 社内の人脈を有効活用 レコメンデーション ー3分野の応用 統計学・確率論 自然言語処理 企業と企業の出会いを最適化（検証中） コンタクトすべき企業のホワイトリストを生成 知人の推測 より人脈を広げる 企業と人の出会いを最適化 ユーザーに合った求人マッチング パーソナライズされたタイムリーな情報を提供 ニュースフィードのレコメンデーション
20. 20 S a n s a n レコメンデーションエンジン Sansanに蓄積された 名刺情報 成果の理解＋人物の分析 出会いがもたらす成果の予 測 出会うべき時、出会うべき人 を確実に捉える S a n s a n ビジネスデータベース 出会いの最適化によって働き方を革新する ー出会う、が、世界を変えていくー ー3分野の応用（レコメンデーションがもたらす未来の価値） 統計学・確率論 自然言語処理
21. 21 AI活用・研究の紹介 Sansan Labs AI を活用した実験的機能 / サービスの提供 社員の強みをキーワード化 バーチャル組織図 企業間距離の変遷 社内キーパーソン Sansan Labs ABMダッシュボード 顧客ごとのタッチポイントを俯瞰 自分や同僚の強みを可視化 自社と親密/疎遠になっている顧客を抽出 人脈をもとに真のチームを可視化 顧客との関係拡大に寄与した社員を抽出
22. R&Dでの研究開発業務の流れ
23. 大まかに2つの領域 • データ化の自動化 • データベースから、ユーザへの新たな価値の創出
24. 目標設定 • 特に名刺データ化であれば、求められるQCDSがある。その実現のため取 り組む。 • データ化を、間違えなく、高速に、かつセキュアに • RecallとPrecisionの対立とおおむね言い換えられる • データベースから何か意味のある情報を見出す、といった研究ならば、目 標から自分で見つけに行くことになる。
25. 研究開発の例：自動項目入力 • 各項目についてOCRをかける。 • 答えがある(定義できる) ので、比較的システム開発 の型にはめて進めやすい。 • 人間が判断する正解を真値として、差を最小化する
26. 研究開発の例：自動項目入力 • R&Dは万事、リリースしてからが本番。 • 予期しなかった新たな名刺への対応 • 業界等による独特な名刺の対応（国会議員秘書の名刺などが顕著） • デザイン性の高い”変わった”名刺への対応 • 日本国外の名刺への対応
27. 研究開発の例：影除去 • 白くして見た目をきれいにする。 • 影領域を推定し、影なら強めに色を飛ばし、それ以外は穏やかに。 • 白地に黒字の「普通の」名刺なら大体うまくいく。 カラフルな名刺、影が激しいケース等が難しい。
28. 研究開発の例：影除去 • 弊社の名刺は非常に難しい。 顔写真が「影っぽい」ので間違えがち。 • 答えを決め難い。テストケースすら書きにくい。 • OCRの精度（成功しやすさ）で測る • PSNRで測る [人間の感覚とあまり一致しない] • 人間の知覚に近い尺度で測る (ECCV 2018 PIRM Workshop で示されている手法など https://www.pirm2018.org/PIRM-SR.html) こういうのも何とかしたい
29. 精度向上への向き合い方 • きりがない • ある程度で一旦リリースし、世に出してみたほうが得られるものが多い • それが許される現場がありがたいですね • 機械学習はそもそも100%の判定をするためのものとは違うと考えている。 人間の判断と併用するのが望ましい捉え方。
30. 大学との研究の違い • (弊社の場合) 最新の研究を追いかける必要は、必ずしもない。枯れた技 術でも充分成果になる。 • むしろノウハウがあり製品化が容易 • ある程度の段階での割り切り(諦め?)も肝心 • とはいえ、競合企業もいる。枯れた技術で出したその次から、試されていく。 • 研究自体を追い求めたいか、世に出すことを価値と捉えるか。 進路はよくお考え下さい！
31. 研究者が成果を出す仕組み R&Dアーキテクト
32. DSOCでの研究者(R&Dメンバー) • Sansanでは、「R&D」つまり研究も開発もでき、成果をカタチにできる 人を採用してきている。 • 具体的には、高精度なライブラリの開発からWebAPIの開発、ログやインフラの検討、運用 まで、一人でこなしてほしい。 • とは言うものの、やはり強みは研究要素であり、一般の開発onlyな技術者 とは違う。 強みを生かすのは、他に代えの利かない研究要素であるべきとも思う。
33. 研究をカタチにする、縁の下の力持ち • 研究要素についてある程度知識があり、 • 開発にも長けて、適切な実装、設計やインフラ等の助言・実行を行う • そんな役割がほしい！ そんな人間はなかなかいないのだが
34. 機械学習 データ分析 自然言語処理 画像認識 R&D Group の構成 研究員 R&D アーキテク ト
35. R&Dアーキテクトとは - 2016年8月に創設 - R&Dチームがより円滑にR&Dできるために基本的に何でもする - ただし、R&Dの作成するシステム全体のアーキテクチャを設計する者で はない
36. ありがちな仕組み - 研究者がアルゴリズムを作る - 開発者がそれをライブラリやフロントエンドシステムに組み込む - これは全く悪くはないと思います。 アルゴリズム システム開発 研究者 開発者 サービス
37. 分業制の課題 - そもそも人(開発者)が足りない - 開発者も研究要素にある程度詳しくないと、開発しづらい - 逆に研究者も開発技術が皆無だと製品化が遠い - 研究で手一杯なので開発環境が荒れがち、レガシーになりがち、手作業 の職人芸がいつまでも残る
38. 分業制の課題 - そもそも人(開発者)が足りない - 開発職の採用をかけても、あまり魅力的に映らないらしい - 研究者の下請け的イメージ - サービスに直接関わる華々しい部隊と比べて、最新の技術に触りにくそ うだし、キャリア的にどうなの？ - かたや研究者が開発にも全力投球するとしても、彼らにとっては実装は 手段であり、それ自体に楽しみを持ちにくい人がいる（印象）
39. 分業制の課題 - 開発者も研究要素にある程度詳しくないと大変 - 一般的に開発チームはある程度全員で共通の技術知識を持つものだが、 R&Dではそれが乏しい。 - 得意な領域が異なる (言語:C++, Python, R, … 機械学習やWeb等のフレームワークも多 彩) - Gitに不慣れな人も普通にいる - ローカルで少量の処理しか念頭にない実装が出てきて、それを製品化可 能なレベルにもっていくのが大変。 - 負荷等のインフラ問題、依存データの問題、実装の問題、ログの問題、など
40. 分業制の課題 - 研究で手一杯なので開発環境が荒れがち - ソースコードに “C:/tanaka/hoge.dat” を読んでいる箇所がある、といった ことがよくある (自分でしか動かせない) - デプロイや動作検証作業が職人芸を要する - その人がもし辞めた時に大変
41. そこで - 「R&Dアーキテクト」を新設 - 「アーキテクト」ではありません。 「R&Dアーキテクト」 - 世間でいうアーキテクトとは違うと考えるため - 研究員でありつつ、製品化に関わる設計・運用なども面倒を見る - 研究の事情も開発の事情も分かる人 - 開発の肩代わりではなく、あくまで助言者
42. R&Dアーキテクトの業務内容 - 技術指針の決定 - コーディング規約 - Web Application Framework の標準化 - 新サービス設計の相談役 - 設計レビュー - コードレビュー - 日常的に質問を受ける - 開発環境整備 - シンクライアント化 - CI/CD環境の構築 - 社内ライブラリ管理サーバの構築 - ライブラリやミドルウェアのアップデート - 基盤構築 - OCR共通処理サービス - KPI - 障害対応 - システム運用 - たまに研究開発
43. R&Dを支える “縁の下の力持ち”
44. R&Dアーキテクト創設の経緯 - アーキテクトの話が出る前後で、実はそんなに業務は変わっていない。 名前が付いたのみ。 - 以前は、“雑用”ばかりで研究できてないな… と鬱々とすることがしばしば。 名前を付けておおっぴらにすることは大事。 - 業務改善系はなかなか着手し難く、おおっぴらに担当できる。 私の名刺に入れた肩書。 チーフ！と家族に喜ばれます
45. R&Dアーキテクト業務紹介 - いくつか例にあげます
46. 例1. シンクライアント化 - 以下の課題から - さまざまなデータを取り扱う - 本番データを用いて開発・分析を行う - ローカルに本番データを取得するのは怖い - ハイエンドPCに縛られる - 重い - 在宅勤務や障害対応のためにPCを持ち帰るのは苦行 - サービスの価値をいち早く届けたい
47. 構成
48. 効果 - マシンの軽量化に成功（約500g） - どこにいてもネットさえ繋がれば開発できる - 試作したアプリケーションを気軽に社内公開できる - ステージングのアプリケーションとの疎通ができる
49. 例2: CI導入 • 今どき誇るものでもないが、研究者だけの部隊だと割と導入困難 • GitHubと連携した自動テスト・自動デプロイ、自動パッケージ化等を実現 • 「研究者も開発者」だからこそ意義がある。Pull requestを出さないと話 が始まらないようにする。 • テストファーストの根付き・デプロイ高速化
50. 例3. コードレビュー • 開発についてよりよい助言のためには、見ておかないと始まらない • 研究の実装は日々少しずつdiffが出てくるものではなく、ドカッと一気に pushされがち。大変。 • 朝から晩まで 見ていることがあります 大体土日は草生えていません ホワイトですよ！ レビューが多い
51. 例4. 障害対応 • アラートの一次受け • OpsGenieにより、アラートの 通知先限定とエスカレーション 研究者に極力集中できる環境を。
52. 例5. 設計レビュー • 作り始める前に、どういう構成が望ましいか、研究メンバと相談する時 間を設ける。 • アドバイス項目の例 • それはLambdaのほうが良いかも？ • DynamoDB / RDS / Elasticsearch / … • 監視の方法 (WebAPI / バッチ) • ログ
53. 例6. ライブラリ整備 • 2,3年経った頃から技術的負債が目立つように。 • C#の実装は「社内NuGetパッケージ」化して整理整頓。 30個前後のパッケージに分割。 依存関係の理解が難しい。 依存の基底では特に互換性維持に大変神経を使う。 セマンティックと日付の折衷バージョニング。 依存関係マトリクス (Ndepend)
54. R&Dアーキテクトは開発職？ • ここまで、とても開発エンジニアくさい。 • しかし、背景に研究要素や事業知識を持っているからこその働き。 • 純粋な開発エンジニアだと、イライラして投げ出していたでしょう。 • 現在でも、研究的なことも時々担当している。 二刀流
55. 普段の苦労
56. 普段の苦労 • セキュリティ • 精度との板挟み • 過去作ったシステムのお守り (技術的負債) • 一番先輩だが年上が多い • コードレビュー • 専門性の薄さ • コミュニケーション
57. セキュリティ • 顧客から預かっている名刺データは万が一でも漏洩などあってはならない。 開発はできるだけダミーデータで行う。 • しかし本物の名刺データでないと検証し難いことも多い。R&Dではこのジ レンマが特に多い。 • 対策の例 • 本番データから再現に必要な要素のみ抜き出す ・データをマスクする • クラウド環境で開発し、ローカルにデータを残さない
58. 精度との板挟み • Sansanのデータベースは、誤りが無いからこそ価値がある。 • R&Dで自動化することは、どうしても精度に弱みが出てしまう。 自動化作ってよ このミスは致命的 精度上げられない？ 両立しがたい
59. 過去作ったシステムのお守り • 手がけたシステムが増えるにつれ、だいたい日々何かしら障害が出る。 • その調査や修理をしていたら1日終わることも多い。 • 深夜・休日も常に障害アラートにおびえて精神を病みます。 • 障害を出しにくい実装やインフラについての知見は年々高まっている。 • 近年のサーバレスの潮流(AWS Lambda等)は効果的。 • 人を増やさないと…
60. 一番先輩だが年上が多い • 26歳で入社して6年、まだ若いつもりですが、R&Dチーム最古参。 • チームは20人以上で、年上が過半数。若干やりづらいことはあります。 • お互い敬語 • もしこれで最年長だと図に乗っていた気がするので、ちょうど良いのか もしれません。
61. コードレビュー • リリースにはGitHubのpull requestを義務付け、私は全て目を通す。 • 専門性が高くて、何が書いてあるかよくわからない • なかなか「研究者らしい」実装 • レビューしていたら1日終わるのはよくある • ここ数年来の経験から、見る側も見られる側も、場数を踏むしか無いと 思っています。必要次第でヘルプに入りつつ、粘り強くコメント。 • かなり運用に乗ってきたと感じます。
62. 専門性の薄さ • 研究の専門性も乏しいし、開発力も突出しているわけでもないと、ずっ と悩んでいました。 • R&Dアーキテクトになったことで、研究で最先端を進むことは100%諦めたと思ってい ます。 • 今でもこの悩みは晴れませんが、こんな役目も世の中合ってしかるべき と信じています。実際頼りにされている実感は大きいです。 • ドラクエの「賢者」になれたらいいと思っています (いいところ取りで強い) • FFの「赤魔導士」 だと微妙ですね… はてさてどちらなのか
63. コミュニケーション • 研究者は、空気が独特。あせらずじっくり聞く。 • 札幌に来て、職場の微妙な空気感は感じられなくなった （感じずに済むようになったとも言う）。 • コードで語る、テレビ会議、中長期のタスクで管理。 周りの尽力かもしれませんが、なんとか回っています。
64. 最後に
65. きょうのまとめ • SansanのR&Dには、多彩な分野の研究者がいます • 「データ化の自動化」と「新しい価値創出」に取り組んでいます • 研究者だけでは難しい面を「R&Dアーキテクト」が受け持ち、成果に結 びつけています • 我々、いわゆる「AI」をやっていますが、日々の業務は泥臭いです
66. いちおう、雇われ人として R&Dアーキテクト含め、エンジニアを絶賛募集中！ ご興味ある方はぜひ連絡いただけると幸いです。 https://jp.corp-sansan.com/recruit/graduate
67. おしまい