名刺アプリ「Eight」

応募要項

 

カジュアル面談

Sansan技術本部では中途採用向けにカジュアル面談を実施しています。各プロダクトの開発チームの業務内容ややりがいを現役エンジニアの視点からお話します。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
 

プロダクト概要

名刺アプリ「Eight」は、主に個人のユーザーを対象にしたサービスです。2012年の誕生以来、名刺を起点としてビジネスパーソンの出会いやその後のつながり、キャリア形成をサポートし続けてきました。現在は330万人を超えるユーザーにご利用いただいています。
そして2023年9月、Eightはスマホを近づけ合うだけで名刺交換が完了する「タッチ名刺交換」の機能を実装しました。名刺情報をデータ化したデジタル名刺を、アプリ一つで瞬時に交換することができます。
 

Eight Engineering Unit 部長 メッセージ

「あると便利」から「ないと困る」ビジネスツールへ

Eight Engineering Unit 部長　大西 真央
Eightは、リアルな名刺交換の場において瞬時に活用できるアプリです。いわば、個人のデジタルIDのようなもの。ユーザーの活用範囲も、ビジネスアワーである平日の9時から18時だけでなく終業後に参加するビジネスイベントや、紙の名刺を持ち歩かない休日など、多岐にわたります。だからこそEightに携わるエンジニアには、高い信頼性を担保することが求められています。名刺交換の際に障害が発生しないよう、どんな時でも安定稼働を徹底しなければいけません。
Sansan株式会社のビジョンでもある「ビジネスインフラになる」を目指すプロダクトとして、「あったらいい」ビジネスツールから「ないと困る」ビジネスツールへと進化する。そのために信頼性を担保しながら、さらなる機能追加をしていくことはとても難しいことですが、Eightの開発における面白みでもあります。その両立に面白さを感じられる人なら活躍できる環境です。
ビジネスパーソン個々人が、培ってきた人脈を最大限に生かす。 個人の変化がきっかけとなり、新しいビジネスへと繋がっていく。名刺アプリ「Eight」は、これまで大切にしてきたその価値を大切にしながら、これからは名刺管理にとどまらず、ビジネスパーソンの出会いの体験、そのものを進化させていきます。
 
 
オフィスについて
業務環境・社内制度について
 

技術スタック

CategoryTechnology Stack
Programming Language / Library etc.Frontend HTML, CSS, JavaScript, TypeScript, React, Redux, GraphQL, Apollo Client, webpack, SCSS, styled-components, Storybook, Jest, PostCSS, OpenAPI
Backend Ruby, Ruby on Rails, Sinatra, Python, GraphQL, OpenAPI
iOS Swift, Objective-C, Realm, RxSwift
Android Kotlin, Dagger, Retrofit, Kotlin Coroutines, RxJava
Other Docker, AWS CodePipeline, Terraform, Chef, Serverless Framework, AWS SAM
Infrastructure AWS EC2, ELB, ECS, ElastiCache, CloudFront, Route53, S3, SQS, SES, SNS, Lambda, API Gateway, CloudSearch, Elasticsearch Service, Athena, Glue, Fargate
DatabaseAmazon Aurora MySQL, Amazon Redshift, Amazon DynamoDB
Container OrchestrationAmazon ECS
CICircleCI, Bitrise, GitHub Actions
Code ManagementGitHub

「Eight」に関する記事

Eight で Internet Explorer のサポートを終了するために行ったこと - Sansan Tech Blog
こんにちは。Eight でエンジニアをしている鳥山（@pvcresin）です。 2022 年 6 月 15 日、 Internet Explorer（IE）のデスクトップアプリの提供が終了しました。 それに伴い、PC 版 Eight では IE のサポートを完全に終了し、閲覧することができなくなりました。 今回はサポート終了の際に行ったことについてお話ししたいと思います。 Web サービスを運営する中で今後、ブラウザのサポートを終了する際の参考になれば幸いです。 （本当はサポートを終了した次の週あたりに公開しようと執筆していたのですが、気がついたら一カ月以上経ってしまいました😅） IE はかつてトップのシェアを誇ったブラウザですが、既に開発が終了しており、最新の Web の仕様に追従できていない点や、セキュリティ的な観点で以前から問題視されてきました。 PC 版 Eight では IE 11 が推奨環境に含まれており、機能開発の際に対応工数が多くかかったり、実現できないレイアウトがあったりと、特に Web フロントエンドの実装観点で悩みの種となっていました。 そのため、IE のサポートを終了することで対応のための開発や QA の工数を削減し、今後の価値提供速度やユーザー体験の向上にリソースを割きたいと常々考えていました。 そんな中、IE の開発元である Microsoft が 2021 年 11 月頃から 自社のサービスで IE のサポートを終了することを発表 しました。 この発表をきっかけに、Eight
https://buildersbox.corp-sansan.com/entry/kill-ie
esbuild-loader 試してみたら開発ビルドが 2〜3 倍速くなった話 - Sansan Builders Blog
こんにちは。Eight でエンジニアをしている鳥山（@pvcresin）です。 散歩が趣味なので、暖かくなってきて嬉しい今日このごろです。 さて今回は Web フロントエンドのビルド時間短縮のため、esbuild-loader を導入した話をしたいと思います。 ビルドにかかる時間はプロダクトが大きくなるにつれてじわじわ伸びていき、開発者体験（DX）を悪くする原因となるため、常に短縮する方法を考える必要があります。 Eight の Web フロントエンドは主に TypeScript・React で開発を行っており、ビルドには webpack を使用していますが、 ビルド時間の大部分はこの TypeScript や React の JSX 記法を JavaScript に変換する処理の時間です。 そこで、この処理を代替することのできるより高速なツールを使うことでビルド時間を短縮しようと考えました。 近年、高速な動作を売りにしたビルドツールが台頭してきていますが、ビルドツール自体を webpack から変更することはなかなか骨が折れることが予想されたため、webpack の loader の形で導入できるものを検討していきました。 Eight では TypeScript のコンパイルに TypeScript Compiler + ts-loader を、JSX から JavaScript へのトランスパイルに Babel + babel-loader を使っています。 これを代替するため、以下の方法を検討しました。 esbuild
https://buildersbox.corp-sansan.com/entry/2022/04/19/110000
Sansan Technical View に参加してきました - Sansan Builders Blog
こんにちは。 Sansan 事業部プロダクト開発部で iOS アプリエンジニアをしている 中川 です。 今回は 5/25 に開催された Sansan Technical View に参加してきたので、それぞれの発表についてまとめてみました。参加されていない方へとっかかりになればと思います。 弊社 CTO 藤倉がイベント概要と弊社の紹介を行いました。 Sansan Technical View は技術的「挑戦」をテーマにサービス開発の過程で得た技術的知見や取り組みの発信を行い、参加された方にヒントやエッセンスを持ち帰って頂くためのイベントです。 本記事でもエンジニア目線から良いなと思った点をピックアップして紹介していきます。 軽く会社についても触れますが、弊社は法人向けクラウド名刺管理サービス 「Sansan」, 個人向け名刺アプリ「Eight」の 2 つを軸に名刺をビジネスを後押しするものに変えて、これまでにないクラウド名刺管理という新しい市場を作ってきました。さらに人と人との出会いだけでなく、企業と企業の繋がりを表す契約書や請求書にもイノベーションを生み出そうとしており、新たな市場に取り組んでいるのがクラウド請求書受領サービス「Bill One」です。これまで培ってきたテクノロジーを活用して、請求書に関わる業務を効率化、アナログからデジタルへ進化させていきます。そして、ビジネスにおけるあらゆる出会いをデータとして捉え、まだ見ぬ可能性から価値を生み出す。こうしたビジネスの出会いを科学するのが 「DSOC」 です。弊社は人と人、企業と企業の出会いからあらゆるビジネスを後押しするインフラになろうと日々、開発を行っています。 個人的に面白かった話は弊社のプロダクト開発にまつわる 3 つの数字についての話です。 「300 人」「15 件」「800 TB」。みなさんはそれぞれの数字についての予想は当たりましたか？ それぞれ、説明すると「300 人」はプロダクト開発に従事しているエンジニアの数、「15 件」はすべてのサービスを合わせた 1 日あたりの平均リリース件数、「800 TB」は蓄積されているデータの総量でした。 まず、「300 人」もエンジニアがいるということに中の人ながら、驚きました。何故かと言うと、自分自身は法人向けの Sansan のいち iOS アプリエンジニアに過ぎず、コロナ禍のため、フルリモートで開発をしていることもあり、顔を合わせるメンバーも限られていたからです。 次の「15 件」はユーザーに価値を継続的に伝えられているのだと安心しました。プロダクトを開発しているだけではユーザーの利便性は何も変わりません。リリースしてこそ、変化を起こせるものだからです。 最後に「800 TB」。正直、想像ができないほどのビッグデータです。このデータを有効活用し、ユーザーのビジネスを後押しする新機能の企画や開発が日々進んでいます。 ここから各プロダクトを担当するエンジニアの発表になります。 ファーストバッターは法人向け名刺管理サービス Sansan の iOS アプリを担当する相川です。 アプリの紹介からどんな課題があったか説明があった後に解決策の取り組みについて話されてました。 アプリの紹介では相川から「名刺管理をするアプリだと思われがち」と前置きを置いた後に以下の機能紹介がありました。 オンライン名刺交換機能 名刺を自動認識し、名刺情報をデータ化 名刺交換した相手の情報を外出先で閲覧 名刺を元にした企業のニュースを閲覧 同僚とコミュニケーション 商談記録 etc 名刺を軸に様々な機能が備わっているアプリであることが分かります。 そんなアプリの開発メンバーとして join した相川が体感した課題は以下のように説明しています。 開発スピードの加速によるコンフリクトの増加 project.pbxproj が可読性が低いファイルなのに、プロジェクト内のファイル操作だけで差分が発生してしまうのが問題 コードベースの課題 Swift は同モジュール内であれば、 import が不要という言語仕様があり、 ファイル間の依存関係が不明瞭 現在は VIPER アーキテクチャを採用しているが、昔の MVC 時代のレガシーコードが数多く残っている これらの課題に対する解決策を以下のように話しています。 XcodeGen という project.pbxproj 生成ツールの利用 Embedded Framework 化による import の強制 XcodeGen ...
https://buildersbox.corp-sansan.com/entry/2021/06/16/110000
TypeScript / JavaScript の import を自動でソートする - Sansan Builders Blog
こんにちは。Eight でエンジニアをしている鳥山（@pvcresin）です。 マイブームはコンビニで買える GODIVA のベルギーダークチョコレート（アイス）を食べることです。 濃厚で甘すぎず、量も多すぎないところが気に入っています。 今回は TypeScript や JavaScript の import を自動でソートする話をしたいと思います。 といっても、TypeScript でソートがうまく行けば JavaScript でも大抵うまくいくので、主に TypeScript にフォーカスした話になるかと思います。 import をソートしようと思ったきっかけは、チームのメンバーが出した 1 つの PR（プルリクエスト）でした。 新規作成したファイルの import が、ライブラリからの import とその他のファイルからの import でそれぞれまとめられており、見やすいと感じました。 とはいえ、毎回手動で import を整理するのは大変ですし、他のメンバーに取り組みを広げることも難しいので仕組み化したいという話になりました。 import を自動ソートするメリットについて考えてみると、以下の 2 点が挙げられます。 どのライブラリに依存しているかがひと目で分かる 同じライブラリ・ファイルからの import に気づきやすくなる 今までは import の書き方に関してルールを設けていなかったので、順番はバラバラでした。 ライブラリからの import をまとめておけば、ファイルを見たときにどのライブラリに依存しているかがひと目で分かるようになります。 のようにバラバラよりは、 のようにライブラリ（
https://buildersbox.corp-sansan.com/entry/2021/05/28/110000
Visual Regression Testingで安心できるフロントエンド環境を作る - Sansan Builders Blog
こんにちは。Eight事業部で主にフロントエンドを担当している青山です。 今回はEightのWebフロントエンドコンポーネント集にVisual Regression Testingを導入した事例を紹介します。 他社さんの事例や勉強会を見るに敷居も下がってきているようで、遅ればせながらDX(開発者体験)向上を見据えて環境を構築していきました。 Visual Regression Testing (以下、VRT) は日本語で画像回帰テストと呼ばれています。対象の修正前後の画像を比較し、差分がないこと、もしくは差分が正しいことをチェックします。 GUIアプリケーションの場合、最終的にユーザーが触れるのは画面であり、この状態をスナップショットでチェックできるのはとても安心できるものだと思います。 今回導入対象として目をつけたのがEight内のコンポーネント集です。その内容について簡単にご紹介します。 EightではWebフロントエンドの構築にReactを利用しています。 Reactは自体はとても使いやすいUIライブラリですが、決まりごとがない状態でチーム開発を進めていくとカオスになっていきます。 特に、似たようなスタイルの乱立や同じスタイルでもそれぞれでハードコーディングされているなど、サービスの統一的なデザインの障害になってきます。 そこでスタイルガイド*1の一部としてReact用のコンポーネント集を準備しました。経緯などについては以前、弊社のイベントで 少しご紹介しています。 コンポーネント集は以下の技術スタックで作られており、GitHub上で管理されています。 Storybook はReactをはじめとしたUIコンポーネントをカタログ化して確認できるツールです。 コンポーネント集ではStorybookのstoryとしてコンポーネントの状態ごとにUIを確認できるようになっています。 GitHub Actionsによるワークフローを組んでおり、CI時に静的ページとしてS3にデプロイしています。 さらにその流れの中でPR上に確認用のURLがコメントされるようにしており、「デモ画面」を見れば誰でも変更内容を触って確認できます。 すでにJestによるDOMの差分チェックは行っていましたが、レビューなどで常に目視確認するのは少し無理があるように思います。 そこで先にも述べたようなメリットを享受できるVRTの導入を進めることにしました。 Storybookの準備が整っていたこともあり、 Storycap + reg-suit という組み合わせでのVRT環境としました。 StorycapはStorybookのstoryごとの画面キャプチャを保存してくれるStorybookのアドオンです。 サイト内の Managed mode に記載のとおり、以下の手順のみで準備完了です。 yarn add -D storycap stroybookのaddonにstorycapを追加 storybookの設定にdecorator (withScreenshot) を追加 reg-suitは画像の比較を行なうためのVRT用ツールで、今回はStorycapの出力を利用します。 reg-suitのプラグイン機能を利用すると、以下のようなことを一括でやってくれるのでとても便利です。 こちらもStorycapと同様にサイト内の Getting Started に従って、インストールと設定をしていきます。 質問に対話形式で答えていくことで設定ファイルが出来上がります。 以下が今回作成された設定ファイル regconfig.json です。 reg-notify-github-pluginはGitHub Appになっており、 上記コマンドの中でインストールやクライアントIDの取得を行います。 今回は上記設定でCIステータスへの反映を止めています。PRでの不要な混乱を避けるためでしたが、renovateによる自動マージを実施している部分などは反映しても良さそうだと感じています。 今回はCIワークフローとしてGitHub Actionsを利用しています。 CIサービスの設定方法も各種揃っているので 参考にして設定していきます。 Eightではすでにワークフローでstorybookのサイトを作成してあったので、既存の設定に以下を追記しました。*2 - name: add JP font run: | sudo apt-get install fonts-ipafont-gothic fonts-ipafont-mincho - name: workaround for detached HEAD run: | ...
https://buildersbox.corp-sansan.com/entry/2021/03/18/110000
まだ間に合う！node-sass（LibSass）から sass（Dart Sass）への移行 - Sansan Builders Blog
こんにちは。 Eight で エンジニアをしている鳥山（@pvcresin）です。 違う違うと自分に言い聞かせていますが、おそらく花粉症になってしまいました 🥺 在宅勤務で良かったです。 今回は Sass のコンパイルに使用しているライブラリを node-sass（LibSass）から sass（Dart Sass）に移行した話をしたいと思います。 Sass の実装としては、以下の 3 つがあります。 まずは移行作業の話の前に、各実装について簡単に振り返ってみたいと思います。 Ruby Sass は Sass の最初の実装でした。 発表された 2006 年当時、Ruby のエコシステムは急成長しており、すぐに多くの人に使われるようになりました。 しかし、徐々に Ruby 製であることに起因するコンパイル速度の遅さや、他のツールとの連携容易性の問題が取り上げられるようになっていきます。 その結果、開発も活発に行われなくなり、Ruby Sass は 2019 年 3 月にサポートを終了しました。 Ruby Sass の問題を解決するために、開発されたのが LibSass です。 LibSass は C/C++製で、動作の速さや連携のしやすさを念頭に開発されています。 LibSass 自体はライブラリであり、これを使用するための ラッパー がたくさんの言語で存在しています。 特にフロントエンド開発においては、Node.js
https://buildersbox.corp-sansan.com/entry/2021/03/10/110000

当社エンジニアに関する記事

 

Sansan株式会社について

 
 

Sansan Tech Podcast

当社のエンジニアがお届けするPodcastです。Sansanエンジニアの技術のこと、カルチャーのこと、日々のSansanライフについて自由に語っています。