技術 Podcast はじめます

高橋 洸です。近日 Sansan の非公式 *1 Podcast を公開します。

始めることにした背景などは Podcast 内でも話すつもりですが、主に以下の 2 つです。

• 楽しそう
• 技術的な広報ができそう

社内メンバー数名に声をかけたところ、面白そうじゃん！と盛り上がり、早速企画することになりました。

内容は、技術のこと、技術と関係ないことを好き勝手に話すというものです。 Sansan エンジニアはもちろん、いずれは非エンジニア職の方や非 Sansan 社員の方にも出演いただくかも......？

トークテーマとしては以下のようなものを検討中です。

• 新規サービスのアーキテクチャの話
• 社外イベントに登壇した話
• PostgreSQL の実装の話
• エンジニアのキャリアの話
• 技術スキルを効率的に身につける話
• 好きなラジオの話

また、非公式と言いながらもせっかくなのでロゴとか作りたいよねということで、社内のデザイナーさんにお願いしたところ、最小工数で最高品質のものを作っていただきました！ぜひ公開をお楽しみに。

---

......というわけで「Podcast はじめます」エントリでしたが、当初の予定だと「Podcast はじめました」エントリになる、はず、でした。

数週間前、我々は意気揚々と第1回を収録し、編集したものを聞いてみました。そしたら、なんとまあ衝撃的な滑舌の悪さとテンションの低さと内容のグダグダっぷり。

こいつは世に出していい代物じゃない。我々はそう判断しました。

そんな苦い経験を経て、真の第1回の収録を先日おこないました。果たしてその質は我々を満足させられるのか。第1回は本当に配信されるのか。乞うご期待。

*1:公式ブログで非公式の話をするのも不思議ですが......

【つながりに効く、ネットワーク研究小話】vol.7 セレンディピティと社会ネットワーク

Sansan DSOC研究員の前嶋です。「つながりに効く、ネットワーク研究小話」の第7回です。

ネットワーク研究の世界で最も興味深い研究トピックの一つが、「社会ネットワークがイノベーションやアイデアの創出に対して与える影響」です。例えば、異なる集団を仲介する人ほど、革新的なアイデアを思いつく傾向にあるという研究(Burt 2004)や、創造性にとって、集団"間"の橋渡しと同時に集団"内"の結束も重要である、といった研究(Uzzi and Spiro 2005)は有名です。

セレンディピティ

ところで、皆さんは「セレンディピティ」という言葉をご存知でしょうか。セレンディピティとは、様々な説明の仕方があると思いますが、「思いがけない偶然に出会ったり、探しているものとは別の重要なものに出会うこと、またはその能力のこと」です。科学史上で重要な発見には、多くの場合セレンディピティが関与していると言われています。

例えば、古代ギリシアの数学者アルキメデスは、複雑な形状をした黄金の王冠の体積をどう測るか？という問いに悩んでいたところ、入浴中たまたま風呂桶から水があふれる様子を見て、王冠を水に沈めた時に増えた水の体積をもとに王冠の体積を測るというアイデアを思いついた、という逸話が広く知られています。

行ってきました re:Invent 2018 (Day 3 Keynoteすごすぎてお腹いっぱい編)

お久しぶりです id:matetsu です。大変お待たせしております。間が空きすぎてもはや自然消滅なのではと思われていた方もいるかと思いますが、しぶとく書き続けていきます。(使命感と編集部の圧)

皆様は1月をどう過ごされましたか？ 私はよくわからないうちに1ヶ月が終わっていました。といった、本題とは関係のないことは最後おまけとしてお話するとして、さっそく re:Invent を振り返っていきましょう。

布団は友達

前日の飲みは健全な時間には終わりましたが、少々疲れが出ていて予定よりも多くアラームのスヌーズをやり過ごした朝。

この日は皆様お待ちかねのAWSのCEOである Andy Jassy によるKeynote #1。朝食をとっている余裕なんてないくらいの時間だったので急いで身支度を整え、空腹のままKeynote会場のオープンを待つ行列へ向かう。 開始の1時間以上前だというのに結構出遅れた感満載の大行列でテンションだだ下がり。

re:Invent 2018 に参加して実感したもの

CTO の 藤倉 です。

かなり時間が経ってしまいましたが、昨年に参加した AWS re:Invent 2018 の記事を書いておこうと思います。

圧倒的

re:Invent に参加することによって、大いなるやる気をもらうことができました。

参加を申し込んだときから、その規模は頭では理解しているつもりでしたが、実際に現地で体験したそれは、想像の何倍もすごいものでした。次々に発表される新しい技術にわくわくし、多くの方との出会いもあり、お祭り騒ぎも十分に楽しむことができました。それらも非常に素晴らしい記憶ですが、イベントが終わってもっとも頭に残っていたのは、イベントの莫大な規模感と、自分たちとの歴然とした差の実感でした。

自分もこういうものを主催する側にいたいと思う気持ちを強くしました。

基調講演会場に入るところ

Sansan CI チームの CI (継続的インテグレーション)

はじめに

こんにちは。Sansan 事業部 プロダクト開発部 CI チームの 中田 です。

突然ですが、CI チームと聞いてどんな仕事を想像しますか? 一般的に IT 分野で CI というと 継続的インテグレーション (Continuous Integration) の略です。 ところが Sansan では違います。Sansan で CI というと Sansan Customer Intelligence (Sansan CI) というものを指し、継続的インテグレーションとは全くの別物です。そして、この Sansan CI の開発を担当しているのが私たち CI チームです。 この Sansan CI がどういうものかは次で軽く紹介しますが、本記事では Sansan CI チームで 継続的インテグレーション をどう実現しているかについての話をしようと思います。

Sansan CI の紹介

Sansan CI というのは、Sansan の名刺を名寄せする技術を応用し、名刺データはもちろん、Salesforce をはじめとする外部サービスの様々なデータを統合し、総合的な顧客データベースを提供することを目的とした Sansan の新機能です。2017 年後半から開発が開始され、2018 年 2 月にサービスインしました。

Sansan CI のアーキテクチャ

製品としては Sansan の機能として位置付けられている一方で、システム的には Sansan 本体からは独立しています。そもそも使用しているクラウドプラットフォームからして違います。Sansan 本体は AWS ですが、Sansan CI は Microsoft Azure です。

ゼロベースでシステムを構築するにあたり、Sansan CI では Function as a Service (FaaS) を全面的に使用したクラウドネイティブなアーキテクチャを採用しました。FaaS といえば AWS の Lambda が有名ですが、Azure にも Azure Functions という FaaS サービスがあります。これほど Azure Functions を積極的に使い込んだシステムは他にあまり多くの例がないのではないかと思います。

また、Azure には一般的な Web アプリケーションを簡単に動かせる Azure App Service という PaaS サービスがあります。Sansan CI の目に見える Web GUI の部分にはこの App Service が使用されています。

写真を撮る、ということ（後編）

こんにちは。ブランドコミュニケーション部 高橋です。

今回は「写真を撮る、ということ」の後編です。

前編を知り合いのカメラマンに「写真について書いたから読んで！」とシェアしました。
その感想をまずはご紹介します。

「恥ずかしい」それが正直な感想。いつから評論家になったの？笑
（雑誌や広告のポートレート撮影で活躍する男性カメラマン N氏）

全体的にいけ好かない筆致。本当にこんなこと考えてる？ そこが疑問だわ。一番笑ったのは『表現に力を入れることだけを「こだわって」「一生懸命やってる」のは、伝える相手にとっては本質ではないので、日々気をつけています。』そんなこと思ってるのかよ〜
（昨年写真展が好評だった女性カメラマンO氏）

と、批判を大いに含む、辛辣な意見がバンバン届きました。

これらの意見には持ち前の明るさで対応しましたが、彼らとの付き合い方を改める必要がありそうです。

さて、めげずに本編です。

今回は「Sansan Builders Box」でも執筆している、DSOC研究員 西田との撮影を題材にして、具体的に「写真を撮る」を紐解きます。

新卒セキュリティエンジニアがインシデントに対応し、現場の開発エンジニアから意見をもらった話

Sansan株式会社で新卒セキュリティエンジニアになりました大井です、現在CSIRTに配属されています。

今回は、オープンソースライブラリに悪意のあるコードが混入されるインシデントに、新卒セキュリティエンジニアがいかにして対応を行い何を学んだのかを記したいと思います。

インシデント対応を行って得た学び

私がこのインシデントに対応し得た学びとしては以下の２つが挙げられます。

1. 開発部門に対しインシデント連絡を行う場合は、可能な限り詳しい情報を渡す必要がある
   ・具体的には危険性、発生条件、バージョンなどを伝達すること
   
   
2. 対策は多段的に行う
   ・初動対応と根源対応を適切に使い分けること