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

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

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

DEIMについて

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

オンライン開催になっても参加者数はほぼ変わらなかったようです。すごい。

オンライン会議について

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 番目。

DeployGateで開発中アプリの配布をスッキリさせたはなし。

みなさまはじめまして！ Sansan事業部プロダクト開発部Androidエンジニアの原田です。
今回は導入から1年半くらいが経つDeployGateというサービスについて、私のチームがどのように利用しているかご紹介いたします。

背景

突然ですがみなさんは、開発中のアプリをテスターさんに渡すときや、エライ人たちから開発中のアプリがどんなものか触ってみたいって言われたとき、どうしていますか？
私達は1年半ほど前まではUSBケーブルを繋いで1台1台ビルドしたアプリを配布していました。

エライ人がちょっと来たときならそれでも良いのですが、テストで複数台の端末への配布となるととても手間でした。

当時はエンジニアの数も少なく一大プロジェクトの真っ只中であったため、CI/CD周りの整備はやや後回し気味でした。が、テストでの配布にかかる負荷がだんだん無視できないものになってきたため改善を試みました。

1台1台USBケーブルで配布するのは面倒

DeployGate とは

iOS / Android向けに展開されている「開発版のアプリを端末に展開する」サービスです。
専用の管理アプリも用意されており、ワンボタンでかんたんに開発版をインストールできます。
また、CI環境にもかんたんに組み込めるようになっており、JenkinsやCircleCI、Bitriseへもプラグインを使ってサクッと導入できます。私のチームではBitriseを利用しているためBitrise用プラグインを利用しました。

チームでの使い方

私のチームでのDeployGateの使い方を紹介します。

PullRequestが作られたらDeployGateへ展開する

GithubでPullRequestが作られたとき、Bitriseを利用してLintとテストを行う仕組みはすでに存在していました。
そこへLintとテストの結果が問題なかったらDeployGateへ配信するフローを追加しました。

DeployGateでは単純なバージョンでの管理の他に、任意の名前をつけた「配布ページ」と呼ばれるページごとにアプリのバージョンを管理できます。
これを利用してPullRequestのブランチ名ごとに配布ページを作成し、各PullRequestごとにビルドしたアプリを管理できるようにしました。見やすいですし、別のブランチのビルドを誤ってインストールしてしまうことを防ぎやすくなります。

DeployGateを使って効率的な開発版の配布環境を実現

リリース前のリグレッションテスト時

リリース前にテスターさんにリグレッションテストをお願いしているのですが、データのマイグレーションなどバージョン間で互換性のない更新が起こることもあるため、一つ前のバージョンからアップデートしてテストをしています。
私のチームではリリースもBitriseを使ってPlayConsoleにアップロードしているのですが、その中でDeployGateにもリリースビルドのバイナリを配布するようにしています。
DeployGateにも過去のバージョンが蓄積するため、容易にバージョンアップのテストをすることができます。

【つながりに効く、ネットワーク研究小話】vol.13 「やぁやぁ、知ってる？」―噂と社会ネットワーク

Sansan DSOC研究員の前嶋です。随分とご無沙汰してしまいました。「つながりに効く、ネットワーク研究小話」の第13回です。先日、新宿御苑に独りで散歩に出かけたのですが、早咲きの桜の木に野鳥が集まっていました。双眼鏡でよく観察してみると、ヒヨドリのくちばしに黄色の花粉がついており、とても愛くるしかったです。

今回の記事では、「噂と社会ネットワーク」について書きます。あなたが最近聞いた噂は、どのようなものでしょうか。「あの人はどうやら株で大損したらしい」「あの人の父親はどうやら有名な芸能人らしい」「どうやらトイレットペーパーが品薄になるらしい」…など、私たちは日常的に、さまざまな噂を耳にします。

噂と社会ネットワーク

さて、噂(gossip)は社会ネットワーク研究の領分でもあります。というのも、噂は人から人へ、社会ネットワークを通じて広まっていくものだからです。なかでも今回の記事では、噂の「社会的影響」と「社会的機能」について考えていきたいと思います。結論から言うと、噂には、集団のパフォーマンスに作用するだけでなく、社会を作り上げたり、社会をつなぎ続ける役割もあるのです。

前もって留意していただきたいのですが、この記事では「噂の広がり方」に関するトピックは扱いません。ですが、もし、噂がどのように社会ネットワークの中で拡散していくかに関する数理モデルに興味のある方は、（少々反則な気もしますが）英語版のWikipediaがよくまとまっていますので、そちらを参照されるかとよいと思います。

en.wikipedia.org

職場での噂がもたらす影響

まずは、噂のもたらす社会的影響についてです。今回は特に「職場の噂」に関する話題を取り扱います。Kurland and Pelled (2000: 429)は、「職場の噂」を「組織内の非公式で評価的な話し合いであり、通常は数人の個人が参加する、そこにいないメンバーについての会話」と定義しています。

職場の噂は、ただの世間話のような無害なものも多いですが、時として、特定の誰かを妨害するために流布される、あるいは、そのような意図がなくともそのように作用してしまうことがあります。

心理学には「職場の迫害(workplace victimization)」という用語があります。これは「意図したターゲットに心理的、感情的、または身体的危害を引き起こす組織の1人または複数のメンバーによって行われる攻撃行為」として定義されています。また、経営学では「長期的に、積極的な対人関係、仕事関連の成功、および評判を確立および維持する能力を妨げることを目的とした行動」のことを「社会的アンダーマイニング(social undermining)」(Duffy et al. 2002: 332)と呼びます。

あまりに悪質な噂は、「職場の迫害」や「社会的アンダーマイニング」のような効果をもたらし、職場の生産性を低下させたり、徐々に職場への不信感を増し、離職率を上げたりする可能性があります(Gouda et al. 2005)。

Wikipediaを元にした日本語の名寄せデータセットを作成しました

こんにちは、DSOC 研究開発部の奥田です。以前の私のブログ記事ではコーギーの動画を見ていると書きましたが、とうとうコーギーを家族として迎え入れ、現在生後6ヶ月の子犬と暮らしております。

さて私たちDSOCでは、SansanやEightの価値を高めるために様々な自然言語処理のタスクに取り組んでおります。例えばニュース記事からの固有表現抽出では、私たちのサービスに特化した固有表現を対象に研究開発しています。その他にも様々あるなかで、特に重要かつ困難とされているものの一つに「名寄せ」というタスクがあります。AIや人工知能と呼ばれるものが発達した現代においても、人間には当たり前にできるタスクが機械には難しいことがまだまだ存在します。

今回は、その「名寄せ」というタスクにおける日本語でのデータセットを作成してみました。これをきっかけに、日本語での名寄せというタスクの研究が進み分野が活性化することを期待しています。

名寄せとは？

まず「名寄せ」というタスクについて紹介します。この記事では、

異なる言葉が同じ事象を表現しているかを判定するタスク

と定義します。例えばいま私が現実に飲んでいる「カフェラテ」は、「ラテ」と省略して表現されることもありますし、「カフェ・ラテ」と中黒を入れて表記されることもあります。Wikipediaの記事だと「カフェ・ラッテ」とあります。一方で「カフェ」とは違いますし、「カフェ・オレ」とも違いますよね*1。こうしたように、人や状況によって異なる言葉の表現をされるものを同一かどうか判定するのが「名寄せ」というタスクです。なおここで言う言葉というのは、一般にはいくつかの単語から成り立つ短い文字列で、文書のような長いものではないものとします。

ちなみに、この「名寄せ」ですが、上記のような定義以外にも様々な考え方があり、あまり統一した定義は無い認識です。データベースのレコード同士を紐付ける行為を指す場合もあれば、Wikipediaの記事を対象に紐付けるもの、文字列を正規化するという場合もあります。また、英語ではEntity Matching、Record Linking、Disambiguation、Deduplicationなど様々な呼ばれ方をしており、タスクによって細かな違いがあるようです。

Sansanでの名寄せ

Sansanでは、この名寄せを人や企業の名前に対して行っています。名刺をデータ化する際には様々な表記ゆれが含まれることがあり、それを解消することが目的です。詳しくは過去に私が発表した資料や講演内容を参照ください。

• 文字起こし：名刺のデータ化における自然言語処理のしくみ　「文字のゆらぎ」をどう扱うか - ログミーTech

Sansanでの名寄せは、これまでに培ってきた知見や創意工夫あふれるシステムを通して高い精度を維持しておりますが、それでも解決できない難しいケースや取り組むべき問題も数多く残されています。私たちの規模のサービスでは全ての処理を人間が行うのは到底不可能なため、人間並みの知覚と知識を持ったシステムの構築が不可欠です。

*1:淹れるコーヒーの種類が違います

レスポンス速度に向き合う

こんにちは、Sansanの杉原です。BtoBサービスのSansanのブラウザアプリケーションのエンジニア兼プロダクトマネージャーをしています。

今回はブラウザアプリのパフォーマンスにおける速度（*1）で苦い経験をしたエンジニアが、プロダクトマネージャーになって速度とどう向き合っているかを紹介したいと思います。 まず結論から言うと私がプロダクトマネージャーとして速度と向き合う時の取り組みはシンプルに次の３つです。

• 定期的に計測する
• 効果が高いところから始める
• 速度目標を設定する

以降ではなぜ速度に向き合うようになったのか、また向き合う時に気をつけていることをお話します。 私の経験がBtoBサービスなどで速度改善に取り組む皆さんの何らかの気づきになれば幸いです。

なぜ速度に向き合うようになったか

それはエンジニアとして参加したプロジェクトの苦い経験がきっかけでした。

そのプロジェクトは外部連携も含めて非常に多くの機能を取り込み、かつビジネス的にも大きく期待されたプロジェクトでした。 その期待に答えるため、エンジニアとして機能を必死に実装しました。また、さまざまな問題もありましたがチームで乗り越えて何とかリリースにまでこぎつけました。

しかし、そのプロジェクトで私は大きな失敗を２つしました。 その１つがレスポンス速度に比重を置けなかったことでした（*2）。

案の定、リリースしてすぐに社内外から遅いという声が聞こえてきました。 せっかく苦労して多くの機能を実現したのに聞こえてくるのは遅いという声ばかり。盛り込んだ多くの機能は使ってもらえてるかすらわかりません。 これは私にとってはとても苦い思い出になりました。 しかし、この経験で私は速度は機能であること（*3）を学びました。 そして、この学びがSansanの速度に向き合うきっかけになりました。

*1:この記事ではレスポンス速度（主にサーバーサイド）のことを指します

*2: 残りの１つはまたの別の機会に

*3:だからこの記事もとても好きです。

「うわっ…弊社のサービス、遅すぎ…？」を New Relic で劇的に速くした話 - Sansan Builders Box

オンライン勉強会のリモート登壇とそれらを通して考えたこと

こんにちは。CTO室改めプロダクト戦略開発室*1の鈴木由香です。何度か本ブログにも寄稿していますが、テックブランディングにまつわる仕事をしています。*2
勉強会などを企画運営することも業務のひとつなのですが、2月後半からは COVID-19 の感染拡大を防ぐために全社でオフラインイベントの開催を自粛しています。*3

jp.corp-sansan.com

弊社主催のものだけでなく多くのイベントが中止や延期になっており、必要な判断とはいえ、参加予定だった方や主催者の方、そのほか会場やイベント会社の皆さんなど関係者の残念な気持ちを思うと苦しい気持ちになります。
しかし、一部内容を変更するなどしてオンラインで開催するイベントも見受けられます。短い期間で関係者一丸となって協力し合い、開催にこぎつけようとする明るいエネルギーはこちらにも活力を与えてくれます。

もともとはオフラインでの開催予定だったTECH PLAYさん主催の「『データ分析基盤Developers Night #4 〜活用されるデータ基盤のつくり方〜』」も、前述の理由からオンラインに切り替えて開催されることになりました。登壇予定だったDSOCの千葉*4に相談すると是非やってみたいということだったので、そのままお引き受けすることにしました。

この記事では、オンライン勉強会のリモート登壇と、それらを通して考えたことをまとめていきます。あまり深くは踏み込めていない領域ですが、少しでも役立つ情報になれば幸いです。

*1:経緯はこちらにあります。 プロダクト戦略開発室の業務について - Sansan Builders Box

*2:詳しくはこちらでお話しています。Sansan Tech Podcast #8

*3:2月3月のイベントにお申し込みいただいた皆さま、ご迷惑をおかけし申し訳ありません。可能な限りちがう形やタイミングに振り替えていきたいと思っています。

*4:ガジェット大好きで、こちらの連載の筆者です。