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:ガジェット大好きで、こちらの連載の筆者です。

AWS Well-Architected フレームワークを活用したコスト最適化への取り組み

DSOC Infrastructure Group の大澤です。
新型コロナウイルスの影響でマスクが品薄になっていますね。花粉症なので最近は常にマスクしているのでマスクがないと辛いです。幸いにも災害対策で備蓄していたマスクがあったのでそれでなんとかしのいでいます。

最近「Cloud Cost Optimization Engineer」というロールになりました*1。Cloud Cost Optimization Engineer を日本語にすると「クラウドコスト最適化エンジニア」でそのままなのですが AWS や GCP といったクラウドコストを最適化するための取り組みや仕掛けをしていくのが主な役割となります。このロールを名乗り出る前からクラウドコストの最適化を進めてきましたが、改めてロールを立ち上げることで私が取り組んでいることを明確化することが目的です。SRE のようなメジャーな肩書が見つからず、国外でジョブオファーをいくつか見つけたのでそのまま名乗らせていただくことにしました。

AWS のコストを最適化するにあたって、闇雲に手をつけるのではなく、まずは AWS のベストプラクティスに則るのが最善だと思っています。AWS が公開している AWS Well-Architected（W-A）フレームワークの柱の1つである「コスト最適化」でコスト最適化に関するベストプラクティスが述べられています。本記事ではこれまで取り組んできたことと W-A フレームワーク「コスト最適化」のベストプラクティスを照らし合わせて紹介します。

AWS Well-Architected フレームワークとは

AWS Well-Architected（W-A）フレームワークを一言でいえば、AWS でシステム構築する際のベストプラクティスを集結したガイドラインといったところでしょうか。AWS ソリューションアーキテクトが長年にわたってさまざまなビジネス分野やユースケースを設計してきたその経験則に基づいて作られたものです。あくまで「設計の原則」であって具体的な設計や実装について触れられていません。AWS サービスを活用したり組織を改善していくことでベストプラクティスに近づけていきます。

ホワイトペーパーが公開されていて、W-Aフレームワークの設計原則やベストプラクティスを学ぶことができます。また、ホワイトペーパーに記載されている質問に回答していくことで自社のシステムがベストプラクティスにしたがっているかを照らし合わせることができます。すべての項目でベストプラクティスにしたがう必要はなく、照らし合わせることによって自社のシステムのリスクや改善点を知ることができる方が重要です。

W-Aフレームワークでは5つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化）が定義されています。本記事では5つ目の「コスト最適化」について取り上げます。

*1:インフラエンジニアとしての職務はそのままです。

VIPER の実装コストを下げるために

こんにちは！ Sansan iOS チームの髙橋佑一朗です。

Sansan iOS アプリでは現在、 VIPER をアーキテクチャとして採用していますが、VIPER の構成で実装していくに当たって1画面作るのにコードを書く量が多いなぁと少しづつ感じてくるようになりました。
そこで、今回は実装時のコストを下げるために考えたことや試したことを書いていきたいと思います。

VIPER は実装コストが高い？

VIPER についてお話をするときによく聞く話ですが 実装コストが高い というのは具体的に以下の2点から来ているのかなと思っています。

1. 画面あたりのファイル数の多さ
2. 各種 VIPER コンポーネント実装時のボイラープレート (初期化時のコード等)

順番にさらっと見ていきましょう。

1. 画面あたりのファイル数の多さ

VIPER の特徴は責務が細かく分割されているということですね。
Clean Architecture を iOS 向けに最適化したもので、元の Clean Architecture ほどではありませんが比較的細かく分けられています。
それぞれのコンポーネントの責務が明確になり、どこか一つのクラスが肥大化してしまうという事態を防ぐことができます。
また、アプリとしてロジックの置き場所などの一貫性を保ちやすくすることでコードの見通しがとてもよくなります。
反面、細かく分けられているがゆえにファイル数は多くなりがちです。

VIPER といえばこちらの記事が有名かと思いますが

cheesecakelabs.com

こちらの構造に従って VIPER を実装すると1画面あたりに必要なファイルは

• HogeViewController.swift
• Hoge.storyobard (option)
• HogePresenter.swift
• HogeInteractor.swift
• HogeRouter.swift

となり、5(storyboard がない場合は 4)ファイル作成することになります。
まだこれだけであれば苦にはならないですが、次のボイラープレートも合わさると少々しんどくなってきます。