技術書典 応援祭に「Sansan技術書典部」として参加します

DSOC Infrastructure Groupの大澤 です。
前回の記事でトレーニングジムに通う話をしましたが継続しています。成果としてベルトの穴が2つ締まりました。今年の終わりには昔のスリムな体型になっていることでしょう。

2月29日、3月1日に開催される予定だった技術書典8に「Sansan技術書典部」としてサークル参加する予定でしたが、新型コロナウイルス感染症の影響で中止になってしまいました。

とても残念でしたが、運営側のご尽力により、オンラインの技術書典 応援祭が3月7日から開催されることになりました。私たちもこの「技術書典 応援祭」に参加します。

サークル紹介および頒布本について

techbookfest.org

Sansan技術書典部からは3部出します。1冊は共著、2冊は単著です。共著の「Sansan Builders Book」は40部程度ですが物理本も販売する予定です。

Sansan iOSアプリの発信者名表示機能に関する実装・運用改善について

はじめに

Sansan事業部で法人向けクラウド名刺サービスSansanのiOSアプリ開発を担当している栗山です。

Sansanアプリには、名刺に記載されている電話番号や同僚から電話があった際に発信者名を表示する機能があります(以下 発信者名表示機能 )。

Sansanアプリの発信者名表示機能

Sansan iOSアプリで発信者名表示機能が搭載されて1年以上経ちますが、実装面と運用面で改善すべき課題が見えてきました。今回は発信者名表示機能に対して行った下記2つの改善の取り組みについてご紹介します。

1. Call Directory Extensionにおけるメモリ使用量改善 (実装面の改善)
2. Call Directory Extension内でのエラー発生を検知する仕組みの構築 (運用面の改善)

発信者名表示機能(Call Directory Extension)について

改善内容について紹介する前に、簡単にiOSアプリにおける発信者名表示機能の構成について紹介します。

iOSで発信者表示を行うためには、事前にiOSに電話番号と表示内容を登録しておく必要があります。*1

iOSへ電話番号情報を登録する際には、 Call Directory Extension という別プロセスを経由して登録する必要があります(iOSに電話番号を登録するためのAPIはCall Directory Extension内からしか利用できません)。

アプリ本体からCall Directory Extensionへ電話番号情報を渡す際には、 App Group という共通領域を経由して行います。App Groupは許可されたアプリやApp Extensionからしかアクセスできない共有ディレクトリのようなものなので、通常は何らかのファイルを使ってデータを渡します。*2

アプリとCall Directory Extension、App Groupの関係

*1:Androidの場合はOSへの事前登録がなくとも、着信時に取得した電話番号情報から自前で検索して表示内容を決定する仕組みとなっており、iOSと作りが根本的に異なっています。iOS/Android両方で発信者名表示機能を提供する際にはこの違いを考慮しておくと良いでしょう。

*2:App Grpupを使う以外にも、Keychainを使ってデータをやりとりすることもできますが、発信者名表示に使う情報は時に大量となることもあるので、Keychainを使ってのやりとりには向きません。

歴史をたどってディープラーニングを学ぶ 第四回 LeNetを作ってコンボリューショナルネットを学ぶ

こんにちは、DeepLearning老人こと糟谷勇児です。

会社では老人ですが、地域活動コミュニティでは若者扱いされギャップに驚いています。

そんなわけで今回もDeepLearningを学んでいきたいと思います。

前回はパーセプトロンを多層化することで画像認識の精度がちょっと上がるところを見てきました。

しかし、精度としてはまだまだ。 今回は畳み込み構造を持つコンボリューショナルニューラルネットを作って精度を上げていきたいと思います。  

ところで、私が新卒で会社に入ったころは、HAAR like 特徴量をAdaboostでカスケードした物体認識の手法が一般的でした。

その手法では、物体を判別するフィルタを20層など複数層重ねて、判別機を作り、画像上を走査して、物体を検出します。

 

フィルタを複数層重ねるという意味ではDeepLearningと似ていますね。

しかしDeepLearningが出てきた当時、若い人に

「DeepLearningでは画像を一枚入れれば（走査しなくても）、どこにあるか含めて判定してくれるんですよ」

と言われて、そんな魔法みたいなことあるか？ と驚きました。

勉強してみると、コンボリューショナルニューラルネットでは、判別機を走査する代わりに、中にフィルタを走査する機構を持っていて類似のことをしており、魔法でなく地続きな手法であると感じます。

コンボリューショナルネットの歴史は長く、古くは福島先生のネオコグニトロンなどがあり、第二回で言及したAlexNetも畳み込みをしています。

ただ、AlexNetはちょっと複雑でまだ難しいので、今回は1998年のLeNetを作っていきたいと思います。

プロダクト戦略開発室の業務について

初めまして。プロダクト戦略開発室でデータアナリストをしています、白石です。
今回はプロダクト戦略開発室での私の業務について書いてみようと思います。

プロダクト戦略開発室とは

そもそもプロダクト戦略開発室は今年1月に出来たばかりの組織で、CPO室とCTO室という組織が合体して出来た新しいチームです。
CPOの大津とCTOの藤倉を中心にプロダクトの戦略から採用ブランディングまで色々やっている守備範囲の広い組織です。笑

なぜこのタイミングで2つの組織が一つになったのかということですが、一言で言うとプロダクトの成長速度を加速するためだと理解しています。
Sansanでは日々、プロダクトの改善、新機能開発、新プロダクトの開発が進められており、その裏側は新しい技術や多くのエンジニアによって支えられています。どんなに良いプロダクトであっても、高い技術を持ったエンジニアがいなければプロダクトは作れませんし、その逆も然りです。
そのような状況で技術(やエンジニア組織の)戦略を司るCTOとプロダクト戦略を司るCPOがより密に連携していくフェーズになっているのだろうなと感じます。

プロダクト戦略開発室の業務

ようやく本題の業務についてですが、上で書いたように2つの異なる組織が合体して出来た組織であり、必要に応じて情報連携しながら各自専門性を発揮してプロジェクトを遂行するスタイルのため、画一的に業務を定義することができません。そのため、今回は旧CPO室が担っていたプロダクト戦略の策定にフォーカスして書いてみようと思います。

【ML Tech RPT. 】第0回 本連載を書くことについて

DSOC研究員の吉村です.

私の好きな歌の歌詞の中に、「案外第0話って後から書かれるよね」みたいなことが書いてあります。(具体的に書くと、どの曲なのかがわかるので雰囲気で書いてます。)

さて, 本連載もそれなりに回数を重ねてきたので, その歌詞のごとく第0話的にこの連載について書きたいと思います. そのため, 今回はあまり技術色は強くないので, 気軽に読んでもらえると良いかと思います.

この連載を書く目的

理由の一つ目：自らのモチベーション維持

この連載をはじめにもらったときから今に到るまで, ずっと同じ目的があってこの連載を続けています. 個人の中での一番大きな目的は単純なもので, 「自らが忙しいという理由にかまけて広く分野の知見を取り込むことを怠らない理由を作るため」です. 冒頭の一言目に毎回テンプレで書いているように, 私の職業は研究員なので現在取り組んでいる業務に関わる技術や知識についての調査は, 当然行なっています. しかし, 弊社の研究員として働く上で「イノベーション」的な側面も求められていると考えていて, それに準ずるアイデアを生み出すためには特定の分野の知識だけを都度必要に駆られて集めるだけではダメだと思っています. アイデアは, あるドメインのものを別のドメインへと転用したり, 応用したりすることで生まれるからです.

先に述べたように「広く分野の知見を取り込むこと」が私個人として重要だと思いながらも, なかなかそういった時間を優先度高く取れないので, 「業務の一環として取り込んでしまう」ことでそれを行わざるを得ないものとしています. これにより, 現在まで継続することができています.

理由の二つ目：採用目的

二つ目の理由に採用目的があります. 弊社で働くことに興味がある方々が, 実際にどんな人間がそこで働いているかを知るのはなかなか困難なことだと思っています. そのような難しさがある中で, 読者にある程度の情報を気軽に得てもらうことも私はこの連載の目的の一つとして置いています. そのため, 毎回, 前置きとして, 多少プライベートな話も盛り込みながら, 自分がどんな人間なのかを表現したりしています. また, 記事の内容についても, 最低限書いている内容について私は理解できている (はず) なので, それらに関連のある人々に新たに弊社に対する興味を持ってもらうことも期待しています.

多国籍なチームでプロジェクトを進める上で大事なこと

こんにちは。Sansan事業部プロダクト開発部の組織デザイングループに所属している平松です。
普段はプロダクト開発部で組織運営をやっているのですが、その傍らでSansanのグローバル展開におけるWebマーケティングのサポートも行っています。今回、グローバル向けのWebサイトをリニューアルするプロジェクトにプロジェクトマネジメント担当として入り、プロジェクトを進めた中での気付きを共有できればと思っています。

グローバル向けWebサイトのリニューアル

Sansanは日本だけではなくグローバル展開も行っており、今は特にシンガポールを中心にビジネスを展開しています。*1

現在のグローバル向けWebサイトは3年ほど前に大幅なリニューアルをしてからは、細かな改修がメインとなっていました。その間、プロダクトも進化し、海外でSansanを使ってくださるお客様も増えました。Sansanの価値をより伝えていくためには、このタイミングでもう一度リニューアルし、価値が伝わるより良いコンテンツを作ろう、そしてもう一段ビジネスを加速しようという思いからリニューアルプロジェクトが始まりました。

多様なメンバーが集まるプロジェクト

プロジェクトメンバーは、見て分かる通り多国籍なメンバー（カッコ内は国籍です）で構成されています。

• 現地法人責任者（日本）
• シニアマーケティングマネージャー（シンガポール）
• マーケティングマネージャー（シンガポール）
• デザイナー（イギリス）
• コンテンツエディター（アメリカ）
• プロジェクトマネジメント（日本/私）

そして、業務を行っている場所も、現地法人責任者・マーケティングメンバーはシンガポール、デザイナー・コンテンツエディター・私は日本と離れており、プロジェクトのやりとりは基本的にテキストかオンラインミーティングで行われます。国籍が違うメンバー間でのリモートによるプロジェクト進行は、普段のプロジェクトとは違った大変さがありました。

*1:日本以外に名刺交換の文化なんてあるの？とよく聞かれますが、結論から言うとあります！以前弊社でシンガポールビジネスマンにアンケートを取ったところ、回答者の内40%の人が月20枚交換するという回答がありました。アジア圏は人と人とのつながりを大切にしてビジネスを進める文化があるので、その中で名刺は大きな役割を果たしています。ただ、日本の「本人のように丁寧に扱う」という姿勢があるかというと、その点は考え方の違いがあるように思います。

【Techの道も一歩から】第25回「できる限りわかりやすく規則による前処理・後処理を記述する」

こんにちは。 DSOC R&D グループの高橋寛治です。

テキストに対して何かしらのアルゴリズムにより結果を得た際に、どうしても出力したくない項目や、少し前処理を書けば改善される、といったことがあります。 例えば機械学習の出力を調整するには、パラメータの調整や学習データの整備となかなか大変な作業が必要ですが、現場ではできる限り早く結果を提供するために、前処理や後処理を追加して対応することがよくあります。 その際に極端な話ですが、都度都度コードに if 文を追記すると、後から読むのが非常に大変になります。

今回は、わりとすっきり記述できたと感じ、運用している設計について紹介します。

設計方針

前処理、中心的な処理、後処理の3パートにわけます。 役割を挙げると次になります。

• 前処理：テキストを入力とし、中心的な処理のためのテキストの整形を行う
• 中心的な処理：前処理されたテキストを入力とし、機械学習モデルなどによる主目的の処理を行う
• 後処理：中心的な処理の結果を入力とし、取捨選択などを行う

また、開発中には各処理工程でどのように変更が加わったかをログで確認できるようにします。

処理の流れを管理するクラスに対して、前処理や後処理を追加するという機構とします。 前処理や後処理は基とするクラスを作成し、それを継承することでインターフェイスを統一します。 ルールを一つ足すには、クラスとして命名する必要が出てくるため、わかりやすさを確保するための一つの項目となります。