page icon

キャリアプロフィール「Eight」


応募要項はこちら

WEBアプリ開発エンジニア

基盤開発/DevOpsエンジニア


Pick Up コンテンツ

挑戦できる環境がSansanにはある。成長を続けて、新しい景色を見たい。

技術本部 Mobile Applicationグループ 河辺 雅史
https://jp.corp-sansan.com/engineering/products-and-technologies/eight/?interview=01
https://jp.corp-sansan.com/engineering/products-and-technologies/eight/?interview=01
キャリアプロフィール「Eight」のiOS版の開発に従事している河辺雅史。柔らかな物腰ながらも、胸の奥に熱い思いを秘める彼は、常に成長することに貪欲であり続けてきました。「エンジニアとして、より難易度の高いプロジェクトに挑戦していきたい」と語る、河辺が見据える未来とは?
 

 
 

プロダクト概要

「Eight」をさらに良いサービスに育てるため、私たちエンジニアは「つながりから生まれる価値は何か」というテーマと向き合い続けています。

キャリアプロフィール「Eight」は、名刺を基点に、いつでも活用できるビジネスネットワークを構築するサービスです。ユーザーはスマートフォンなどで名刺画像を取り込むだけで、名刺交換をした企業や人物と「Eight」のネットワーク上でつながります。企業のプレスリリースや人事異動情報、知人や取引相手の転職や起業などの近況を、すべてアプリ上で知ることができるのです。
「○○さん、起業したんだな。ウチの会社と協業してもらえないだろうか」 「○○さんが部長になったそうだから、お祝いを兼ねて久しぶりに連絡してみよう」
「Eight」を起点に、そんな行動が生まれるかもしれません。「Eight」がもたらすネットワークは、ビジネスの「種」を創出します。その種子は小さな芽を出し、花を咲かせ、大きな実を結んでくれるかもしれない。「Eight」が媒介した人と人とのつながりが、いつしか素晴らしいビジネスチャンスにつながり、新しいキャリアの転機になる。私たちはそんな世界観を目指しています。
もっと見る
多様化する働き方に合わせ、名刺のあり方そのものも、アップデートする必要があると私たちは考えています。これまでのように、紙の名刺を大量に発注するのではなく、必要な時に必要な分だけ発注できるほうがよい。そして、オンライン上での商談・会議においては、自己紹介や情報交換のためにオンライン名刺を活用する。働き方に合わせた形式の「名刺」が今後必要とされるでしょう。 このように多様な働き方を支援するため、当社は名刺作成サービス「Sansan名刺メーカー」を開発・提供しています。「Sansan名刺メーカー」は、営業DXサービス「Sansan」をはじめ、ビジネスプラットフォーム上で、名刺データの作成と発注申請を可能にするもので、作成された名刺データはオンライン名刺としても利用可能です。
2021年5月末より提供を開始した「Sansan名刺メーカー」は、まだ産声をあげたばかり。サービスとして成長過程にあります。開発に携わるエンジニアも少数で、各メンバーが幅広い業務領域を担っています。ゼロからサービスを立ち上げたからこそ、開発に伴う大変さも伴います。しかし「Sansan名刺メーカー」の開発には、エンジニア自身の意見や作業が、ダイレクトにサービスの成長に結びつく面白さがあります。
「Sansan名刺メーカー」は今後、単なる名刺作成機能“ではない”サービスへと進化していきます。名刺データは個人を識別できる正確な社員情報です。だからこそ、他サービスとの連携や、社員の認証など、さまざまな用途に活用できる可能性を秘めています。今後は「Sansan名刺メーカー」のデータを利用して、業務の利便性を高められる場面が増えていきます。
これまでSansanは営業DXサービス「Sansan」や個人向け名刺アプリ「Eight」などを通じて、名刺を起点とした出会いからイノベーションを生み出してきました。「Sansan名刺メーカー」はそんな私たちが見つけ出した、ビジネスの新しい可能性。この挑戦は始まったばかりです。
 
 

キャリアプロフィール「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
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
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 ...
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 をまとめておけば、ファイルを見たときにどのライブラリに依存しているかがひと目で分かるようになります。 のようにバラバラよりは、 のようにライブラリ(
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: | ...
まだ間に合う!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
新卒メンバー座談会 Part3 | Sansan公式メディア「mimi」
こんにちは!人事部で新卒採用を担当している阿部です。 「新卒メンバー座談会」第3弾となる今回は、エンジニア職、デザイナー職として新卒入社したメンバー3人のインタビュー。 入社後にどのようなものづくりをを行っているのか、これまで直面した課題とその乗り越え方についても話を聞きました。 Sansanならではの ものづくりのやりがい 技術本部 Data Hub Engineeringグループ 木下 賢也 阿 部  本日はよろしくお願いします。早速ですが、自己紹介をお願いします。 木 下 初めまして21卒で入社しました木下賢也と申します。現在、技術本部 Data Hub Engineeringグループに所属していて、「 Data Hub 」というプロダクトを開発しています。よろしくお願いします。 辻 木下さんと同じく、21卒のエンジニアとして入社しました辻繁樹です。技術本部 Eight Engineering Unitというところで、名刺アプリ「 Eight 」の機能開発をしています。 富 岡  20卒でEight事業部でデザイナーをやっている富岡といいます。「Eight」に加え、Seminar One Unitも兼務して「スマートエントリー」「スマートパンフレット」のプロダクトデザインを担当しています。よろしくお願いします。 阿 部  よろしくお願いします。それでは早速最初の質問に行きたいのですが、皆さんの業務について具体的にお話を聞ければと思っています。では、木下さんからお願いします。 木 下  現在は「Data Hub」というプロダクトの開発を行っています。「Data Hub」というのは、外部の他サービスとの連携をして、社内に眠る顧客情報を一元管理するプロダクトです。 そしてSansanに取り組んだ名刺を外部のサービスと連携して、名刺の価値を広げていくプロダクトです。その開発に携わっている中で、ドメインの設計やコーディング、運用に取り組んでいます。その他には、顧客からの依頼に対応して調査なども行っています。 辻 普段の業務内容としては「Eight」のWeb/アプリに関わるサーバーサイドの開発を担当しています。「 Eight ONAIR」「 Eight Team」「 Eightプレミアム 」など、Eightが展開するtoC/toBサービスの新規機能開発・既存機能の改修・運用などを行っています。 富 岡  辻くんが開発している名刺アプリ「Eight」のUI/UXデザインを行ってます。 具体的にはプロダクトマネジャーと連携しながら企画や仕様設計を詰めたり、あとはエンジニアと実装に向けて、デザインに関するやりとりをしたり、手を動かすデザインからコミュニケーションを担当しています。 阿 部  続いてその業務のやりがいについてもお話を聞きたいと思います。 木 下 僕が一番やりがいに感じているのは新しい価値観をつくれている実感が持てるところです。社内に眠っている、顧客データ等を一元管理することでどんな価値が生まれるか、 Sansan株式会社 が持つ強みに直結しています。 まだ世の中にないプロダクトを自分たちがつくって、社内のデータを一元管理する重要性や価値を、日々の業務を通じて世の中に伝えていけてるなと実感できるところにやりがいを感じますね。 さらに「Data Hub」はSansanで取り込んだデータを他サービスに連携するという役割を持っていて、今ある名刺以上により価値を広げていけてるな、と実感できるところもやりがいです。 阿 部  開発をする中で「新しい価値をつくることができる」と日々実感しているんですね。辻さんはいかがでしょう? 技術本部 Eight Engineering Unit Web Devグループ 辻 繁樹 辻  ...

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

 

Sansan株式会社について

 

Sansan Tech Podcast

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