RubyKaigi2019にLanyard Sponsorとして参加してきました

初めまして、DSOC Development Groupの村田です。

4/18(木)〜20(土)の3日間、福岡国際会議場で開催されたRubyKaigi2019にLanyard Sponsorとして参加させていただきました。私は普段はデータ統括部門であるDSOCで、サーバサイドをRuby on Railsで開発しています。今回初めて、RubyKaigiに参加してきたのでそのレポートをご紹介致します。

RubyKaigiとは？

プログラミング言語Rubyに関する国内最大のカンファレンスで、年に一度日本のどこかで複数日に渡って開催されています。このイベントには国内外から多くのRubyist たちが集まり、様々なセッションが行われます。Rubyコミッターの方々も多く参加し、そしてたくさんの企業が協賛しているイベントで、Rubyistにとっては年に一度のお祭りのようなものです。

rubykaigi.org

スポンサーブースで「RubyKaigiで楽しみにしているコト」を募集！

弊社は、RubyKaigi参加者の出会いのきっかけとなればとの思いを込めて、「RubyKaigiで楽しみにしているコト」を付箋に書いて投票してもらうという企画を行いました。参加者全員に配られるネームカードに、ルビーをかたどった付箋が挟まれていて、その付箋に「RubyKaigiで楽しみにしているコト」を書いてブースに用意したパネルに貼っていただくと、抽選でTシャツやお米などのノベルティが当たるというものです。

Rubyエンジニアの祭典「RubyKaigi 2019」に協賛します | Sansan公式メディア「mimi」

Rubyの生みの親であるMatzさんやRubyおよびRailsコミッターの松田さんもブースに遊びにきてくださいました。

3日間でとてもたくさんの方が企画に参加してくださり、パネルは皆さんの「RubyKaigiで楽しみにしているコト」でいっぱいになりました！
皆様ご参加いただきありがとうございました！！

セッションをいくつかご紹介！

たくさんのセッションがあった中で気になったセッション、興味深かったセッションをいくつかご紹介します。

Day1. 13:30-14:10「How to use OpenAPI3 for API developer」

まずは1日目の13:30-14:10にあった @ota42y さんのOpenAPI3についてのセッション。

speakerdeck.com

DSOCの開発チームでも、半年くらい前からAPI仕様書をAPI BlueprintからOpenAPI3に移行しつつあったので、聞きたかったセッションの一つでした。
大規模なマイクロサービスの場合APIの数も膨大になってきます。そんな時にまずAPI定義を取り決め、その定義に沿ってクライアントとサーバの開発を同時に進めることをSchema First Developmentというそうです。
クライアントとサーバの開発を同時に進めて結合するには、必ずどちらもAPI定義通りに実装する必要があります。そんな時 commitee.gem を使えば、リクエストとレスポンスのバリデーションをRack層でやってくれ、定義と実装が同じであることを担保できるそうです。便利！ さらに、アプリケーション側では to_s とか Time.parseとかしなくても定義通りに型変換してくれるという賢さ。すぐに導入してみたい！
定義からRubyオブジェクトにマッピングできるopenapi_parser.gemもご紹介いただき、大収穫でした。

Google Cloud Next 2019 @San Francisco に行ってきました！（前編）

DSOC Infrastructure Group の 大澤 です。

先週開催された、Google Cloud Next 2019 に参加してきました。
参加者はCTOの藤倉とR&D島、大澤の3名です。旅行記やイベントそのものについては島の記事を読んでいただくとして、今回は Next 中に発表があった内容や気にあるセッションの感想などをつらねていきたいと思います。
かなり長くなってしまったので前編、後編に分けました。 *1

会場のモスコーニセンターです。電柱が邪魔をして上手く撮れなかった。。。

Day 1 Opening Keynote

www.youtube.com

Day 1のオープンニングキーノートで発表された、Anthos が目玉だったと思います。昨年発表された、 Cloud Services Platform が正式サービスとしてされたローンチしたもので、オンプレミス・クラウドを意識することなく、 Kubernetes クラスタを一元管理できるようになります。VMWare から GCP への移行のデモがあり、ハイブリッドクラウド（オンプレミスとクラウド）の文脈かと思いきや、デモ中に AWS のエンドポイントもこっそり出てきていることから、マルチクラウド（ Google と Google 以外のクラウド）の利用もできるようです。ハイブリッドクラウド、マルチクラウドの利用を先駆けて促進していこうとする意思を感じました。

次に気になったのは、OSS ベンダとの提携です。
Elastic, MongoDB, Redis など大手の OSS ベンダが提供するマネージド版を GCP のマネジメントコンソールと統合され、リソース操作はもちろんのこと、請求やサポートも統合されるとのことです。デモ画面では Redis Enterprise が GCP のマネジメントコンソールに出てきていました。
Redis CEO が Keynote にでてきた他、その他 OSS ベンダの CEO も動画で出てきたあたり、Google と OSS の関係性を強くアピールしていましたね。Google では Google で採用していない他の OSS に対してもバグや脆弱性の発見、修正に対する報奨金を提供していることから、昔から OSS と向き合っていてお互いに良い関係を築いていっていることはとても素晴らしいと思いました。

*1:けっして執筆期限に間に合わなかったとかそういうわけではないですよ。ええ。

行ってきました Google Cloud Next '19 San Francisco [旅行記その1]

DSOC R&Dの島です。こちらで記事を書くのは2回目です。

Google Cloudの一大イベント Google Cloud Next '19 のためサンフランシスコに行って参りました。参加者はCTOの藤倉と大澤・島の3人です。セッションなど技術的な内容は大澤の記事にゆずり、私はこちらでは旅の記録を書きます。長いので2部に分けます。

さらに万一気が向けば、ML系その他、気になった情報について別で書くかもしれません。

レイヤードアーキテクチャを振り返る

こんにちは、Sansanプロダクト開発部の清水です。

ある程度のアプリケーションの大きさだと当たり前に使われる事が多い「レイヤードアーキテクチャ」の自分が考える設計のポイントや、実際に運用する際のポイントについて書いてみようかと思います。 基本的な話なので「今更かよ」って感じがしますが、実際に設計、運用する際には様々な考慮事項のあるものだと思うので、知ってる人にとっても復習にでもお役に立てればと思います。

そもそもレイヤードアーキテクチャって何?

概要

一言でいうと、アプリケーションを作る際にそれを構成する部品を、それぞれ責務が定義された論理的なグループにまとめて整理し、それぞれのグループ間のやり取りの仕方を決めておこうという事です。 このグループ間のやりとりにおいて、一方向かつ隣接するグループとしかやりとりを行えないようにする事が多く、層状になるのでレイヤードアーキテクチャと呼ばれます。 一般的に上記の 論理的な グループの事をレイヤー(Layer)と呼びます。*1

レイヤードアーキテクチャのメリット

アプリケーションは成長していくにしたがって、巨大で複雑なものになっていきます。 そうなってくるとコードが大量にある状態になり、開発を行う際に、どこに何をするものがあるのかを開発者が把握する事が困難になります。

なので、特定の責務によって整理し、何がどこにあるのかを把握しやすくすることで、保守性を高める事ができます。 例えばデータアクセスする処理があったとして、それがデータアクセスレイヤーに置かれているなら、開発者はそのレイヤー内を探せば簡単に見つける事ができます。

ただ、それだけなら単にコードのグループ化だけでも同じメリットが得られます。 グループ間のやり取りの仕方を決めて制限し層状にする事のメリットは、もしアプリケーションに対する変更があった場合に、その影響範囲を、層を直接参照している層のみに限定する事ができるようになります。 もしデータの永続化の方法が、最初はリレーショナルデータベースで行っていたのが様々な都合で KeyValueStore の方が適切になり変更を実施する事になった場合に、その変更の影響範囲はデータアクセスレイヤーとそれを参照するレイヤーのみに影響を抑える事ができます。

代表的なレイヤーの分割単位と、そのやりとりの仕方

レイヤードアーキテクチャではレイヤーを以下の3層に分ける事が多いかと思います。

名称	責務の概要	別名(その表記を見る書籍など)
プレゼンテーション	ユーザとシステムのやりとりに関するものが置かれる。通常のWebアプリケーションならUIとなるHTMLや、WebAPIならリクエスト、レスポンスのモデル。あるいはControllerなど表示を調整するプレゼンテーションロジックなど。	ユーザインターフェース(DDD *2 )
ビジネスロジック	そのシステムで業務を表現するモデルや処理が置かれる。業務的なバリデーションやルールの適応など。	ビジネス(MSAAG*3, ドメイン)(PoEAA*4, DDD)
データアクセス	データアクセスに対する技術的な手段を提供するものが置かれる。主にデータベースや外部サービスを直接的に叩く処理など。	データ(MSAAG), データソース(PoEAA), インフラストラクチャ(DDD)

この3層を取る場合、代表的な処理の流れは以下になります。

1. ユーザはプレゼンテーションレイヤーを介してシステムへの操作を行います。
2. プレゼンテーションレイヤーはビジネスロジックレイヤーとのみやり取りを行います。
3. ビジネスロジックレイヤーはデータアクセスのためにデータアクセスレイヤーを呼び出します。
4. データアクセスレイヤーでのデータアクセスの結果をビジネスロジックレイヤーに返します。
5. 4.の結果をプレゼンテーションレイヤーで加工しユーザへの表示を行います。

この時プレゼンテーションレイヤーは必ずビジネスロジックレイヤーを介してデータの取得や永続化を行い、直接データアクセスレイヤーとやり取りをする事は行いません。 このようにそれぞれのレイヤーに決められた責務以外の事は別のレイヤーに任せ、やり取りする相手を制限する事で処理の流れや依存関係を理解しやすくします。

Layred archtecture

*1:対称的にサーバへの配置場所など 物理的な配置 でグループを分ける場合はティアー(Tier)と呼ばれており、レイヤーとよく混同する事がありますが、意味合いが違うので注意してください。

*2:エリック・エヴァンスのドメイン駆動設計

*3:Microsoft Application Architecture Guide, 2nd Edition

*4:エンタープライズアプリケーションアーキテクチャパターン

DSOCブース：SIP2019

DSOC Creative Groupの山脇です。3/14.15に開催された「Sansan Innovation Project 2019」にクラウド名刺管理サービス「Sansan」と個人向け名刺アプリ「Eight」を支えるデータ統括部門であるDSOCが展示ブースを出展しました。

今年はDSOCが担う大きな二つの役割『DATA』と『RESEARCH』を表現したブースデザインにしました。当日限定で配布したパンフレットも白と黒のリバーシブルデザインにし、『DATA』と『RESEARCH』は表裏一体であるということを表現しています。

Tシャツ

当日ブースで案内したメンバーが着用していたTシャツのデザインも白と黒に分けました。白である『DATA』は、辺や角などが等しく正確なイメージを持つ図形である正方形で表されたデータの粒子で正確性を表現。そしてそのデータの粒子が黒の『RESEARCH』へと流れ、必要なデータで構成された大小の真円となり様々な可能性を秘めた未来を描いていくことを表現しています。『DATA』と『RESEARCH』のTシャツが繋がることでDSOCが持つ可能性をデータの流れにより表現しました。

RESEARCH側の展示

『RESEARCH』側では、壁面のモニターに会場入口で展示していたデータビジュアライゼーション 「Dawn of Innovation」のムービーを放映。「Dawn of Innovation」の詳細はDSOC研究員西田の記事をご覧ください。またDSOCに所属する研究員の研究成果である「Data Science Report」の表紙も新たなコンセプトに合わせたデザインにリニューアルし配布しました。そして「Sansan Labs」のデモ機設置。普段触れることのできない人たちをはじめ、様々な人たちにご使用いただき新たな気づきの声などもいただきとても有意義なものとなりました。

DATA側の展示

『DATA』側では、壁面に設置したパネルにて、独自の名刺データ化システムである 「GEES」を用いた名刺のデータ化フローを紹介。そして素晴らしい進化を遂げたスマートキャプチャーの体験コーナーも設置しました。ダミー名刺を用意し、従来のシステムでは撮影することが難しかったファイルに入ったままの名刺や、キーボード上での撮影、特殊な形状をした名刺の撮影など従来のシステムと比較しながら試せるようにしました。この機能は、Eightにすでに搭載されておりますのでぜひお試しください。機能詳細についてはこちらをご覧ください。

DSOCはこれからもサービスを通じて
新しい価値を提供し、
イノベーションを生み出し続けます。

名刺データ化コストを改善する

はじめまして、DSOC Development Group で開発をしている石畑です。

現在は名寄せチームで、データ統合の機能開発をしています。関連のある名刺データを統合することで、顧客情報を一元管理できるようにしたり、世の中の様々なビジネスデータを収集し、名刺に紐づけることで、名刺の価値を高めることがぼくらの目的です。Ruby(Rails) で開発しています。

RubyKaigi 2019 に参加して、Sansan ブースにも立っているので、ぜひ開発のあれこれについて話しましょう。

DSOC Development Group の取り組み

DSOC は Sansan の「データ」を司る部署です。そのため、「データ」を使ってユーザー価値につながることなら何でもやる所存ですが、現在できていることは大きく次の 3 つです。

1. 名刺データ化システム（GEES）の開発
2. データの名寄せ
3. 人・組織のニュース配信

これらのサービスは、それぞれ 3 - 6 人ほどの小さなチームで開発しています。少人数ながら、Sansan, Eight 全ユーザーに影響を与えられるとても刺激的なサービス開発です。これだけ多くの価値に関われるのが「データ」を扱う DSOC 開発の面白さだと思います。

今回は一例として、以前携わっていた名刺データ化システム（以下、GEES と呼ぶ）で、データ化のコスト削減を行った話したいと思います。

GEES の概要

GEES は名刺を高いセキュリティで、素早く、ミスなく、低コストにデータ化するためのシステムです。今は 10 ヶ国語に対応しています。

スピード・コストを重視すればガンガン自動化していけばいいんですが、そうもいかないのがデータ化精度です。Sansan はデータ化精度 99.9% をサービスとして約束しており、それがサービス価値の土台になっています。 また、本ブログでビジネスネットワークの活用などが紹介されていますが、活用するにはデータが正しくなければ意味がありません。そこで「人」によって高精度なデータ化を実現しています。自動と手動、そこのバランスがとても難しく、GEES 開発の面白いところでもあります。

少しでも自動化の恩恵を受け、手動の効率を上げるために、GEES の内部は自動車の組み立てラインの様に約 20 もの工程（サービス）に分かれています。

多くの工程を AI と人を組み合わせてデータ化している

これらは全て Rails で開発されており、そのマイクロサービスを連携させるのが AWS の Amazon Simple Workflow Service (SWF) です。 データの状態を見て、簡単にサービスを組み替えられるのが SWF のいいところです。 また、それ以外にも Aurora や ElastiCache, SQS, DynamoDB, Elasticsearch Service などなど、少人数チームで大量のデータを扱うために様々な AWS サービスをフル活用しています。

RubyKaigi 2019に参加します

こんにちは。VPoEの宍倉です。

本日よりRubyKaigi 2019が始まります。そして、今回もRubyKaigiの協賛をしています。

数年前より社内にて参加希望者を募るようになりました。毎年参加者が増え、今年は約20名のエンジニアが参加します。
多様なセッションで学び、夜はオフィシャルパーティ等で出会い、多くの気づきを得ることができる良い機会だと考えてます。何より多くのRubyistとともに過ごす時間が楽しいですよね。

昨年のブース

協賛については、Rubyコミュニティを盛り上げたい。この一大イベントを参加者の皆さんと楽しみたい。というのがあります。そして、Sansan という会社、プロダクトを知ってもらいたいです。

ブースにてみなさんと楽しみながら Sansan を知ってもらえるような企画を準備しました。そんな Sansan のミッションは「出会いからイノベーションを生み出す」です。

ミッション：出会いからイノベーションを生み出す

世の中を変えてきたきっかけは、人と人との「出会い」にあり、多くの出会いの中から世の中を変えるプロダクトやサービスなどが生み出されてきました。RubyKaigiに参加される方には、登壇者の方との出会い、他社のエンジニアの方との出会い、Rubyを支える方々との出会いなど、同じ場に集う多くの「出会い」に期待をして参加されている方もいるかと思います。そして、この場の「出会い」からイノベーションが生み出されるかもしれません。

私たちのサービスは、単なる「名刺のデジタル管理」としてだけではなく、イノベーションにつながる「出会い」を生み出すことができるサービスを目指し、名刺からはじまる「出会い」のあり方を変えていこうと挑戦をしている企業です。

サービスとRuby

サービスとして、法人向けクラウド名刺管理サービス「Sansan」と個人向け名刺アプリ「Eight」の２つがあります。

２つとも名刺を管理するサービスとして生まれました。そして、イノベーションにつながる「出会い」を生み出すサービスとして進化をしようとしています。

RubyはEightと基盤技術の部門であるDSOC( Data Strategy & Operation Center）にて利用されています。RubyKaigiにはEightとDSOCのエンジニアが参加します。情報交換をしましょう。

おわりに

昨年までのRubyKaigiでは、Rubyで開発されているEightのサービスを知ってもらいたくEightとしてスポンサードしていましたが、今回は会社自体を知ってもらいたくSansanとして出展します。Eight、DSOCの開発メンバーがブースにいますので、具体的な技術の話もその場でできます。是非遊びにきてください。

今年も Rubykaigi でお会いしましょう！