iOS エンジニア


応募要項はこちら

テクニカルリード


Pick Up コンテンツ

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

技術本部 Mobile Applicationグループ 河辺 雅史

2018年、Sansan株式会社に新卒として入社。キャリアプロフィール「Eight」のiOS版開発に従事し、Eight iOSの機能開発・改善を行う。Eightをビジネスプラットフォームにするべく、日々奮闘している。
キャリアプロフィール「Eight」のiOS版の開発に従事している河辺雅史。柔らかな物腰ながらも、胸の奥に熱い思いを秘める彼は、常に成長することに貪欲であり続けてきました。「エンジニアとして、より難易度の高いプロジェクトに挑戦していきたい」と語る、河辺が見据える未来とは?
続きを読む

開発レビューでいただいたコメントはエンジニアの財産

Sansanに新卒で入社して、今年で4年目になります。携わった仕事を振り返ってみると、私は本当に環境に恵まれていたなと思います。大変ではあるけれど、壁を乗り越えることで自分自身の成長につながるようなプロジェクトをいくつも担当してきました。
特に印象深いのがキャリアプロフィール「Eight」のiOS版のメジャーバージョンアップを行ったプロジェクトです。このプロジェクトでは、iOS版の機能や画面構成などを大きく刷新しました。当時の私はまだ新卒1年目。正直なところ、まだまだエンジニアリングのスキルは未熟でした。
自分なりに一生懸命にコードを書いてPull Requestを出すと、レビューで先輩エンジニアたちからたくさんのコメントをもらいました。それが、当時の私には本当にありがたかったです。私は常々、レビューで得たコメントはエンジニアにとっての財産だと思っています。
コメントの内容を確認することで、今の自分にどのような領域の知識が足りていないのかがわかります。レビューで受けた指摘を、着実に自分の糧にしたいと考え、仕事の後や休日に勉強をしていました。
成長を実感しはじめたのは、2年目になってからです。徐々にPull Requestで他のメンバーから指摘を受ける量が減ってきました。自分自身の勉強が報われた気がして、エンジニアとして働くのが本当に楽しくなってきました。

大規模プロジェクトをリードできるようなエンジニアへ

私たちが開発するキャリアプロフィール「Eight」は、スマートフォンで名刺を撮るだけで情報を正確にデータ化し、人と人とのつながりから新たな価値を創出するサービスです。私たちは「どのような機能があればユーザーに最大限の価値を提供できるのか」をいつも考えながら、開発を続けています。
サービスに盛り込む機能には、世の中の潮流や人々のニーズの変化が反映されることも多いです。その好例が、昨年にリリースしたQRコードを活用したオンライン名刺交換。新型コロナウイルス感染症の感染拡大の影響で、人々が対面で会う機会が少なくなり、オンラインでのコミュニケーションの機会が増えました。対面で名刺交換が行われなくなることで、本来ならば「Eight」が創出できていたはずの価値を、ユーザーに提供できなくなってしまうかもしれない。可能な限り、その事態を避けたいと思いました。
自分たちに何かできることはないかと考えた結果、QRコードを活用したオンライン名刺交換機能が生まれました。これはオンライン商談や会議で使用されるバーチャル背景に、オンライン名刺のQRコードを組み込んだものです。今では多くの方々が、オンライン商談や会議の場で名刺のやりとりをしています。これまでの「Eight」の“当たり前“にとらわれず、斬新な機能を開発できた。その結果として、世の中に新たな価値を提供できたことに、エンジニアとして大きなやりがいを感じました。
Sansanは挑戦できる環境が整っている会社です。先ほど1年目に経験したプロジェクトの話をしましたが、そこから現在に至るまで、常に挑戦の連続でした。その積み重ねで、一歩ずつエンジニアとして成長することができたと思います。いつかは、大規模なプロジェクトを自分自身の力でリードできるようなエンジニアになりたい。周囲の人々に良い影響を与えられるような仕事がしたい。まだまだ、学びたいことや、やりたいことは山ほどあります。
 

 
 

チーム概要

Sansanの提供するアプリを、さらに価値のあるものに洗練させるため。そして、ユーザーへの提供価値を最大化するために。

Sansan株式会社では、営業DXサービス「Sansan」やキャリアプロフィール「Eight」を開発しており、それぞれのモバイルアプリも提供しています。数年前まではブラウザーでの利用が主流だった「Sansan」ですが、現在ではブラウザーと同じくらいモバイルアプリからも利用されるようになりました。さらなる事業成長のためには、モバイル向けの機能開発が重要な鍵となっています。
もっと見る
また、「Eight」はモバイルユーザーの割合が非常に高いアプリです。ユーザー数が280万人を超える「Eight」をさらに改善するため、既存の名刺管理機能を充実させるだけではなく、ビジネスSNSとして活用してもらえるように、ビジネスニュースの配信や共通の知り合いを可視化する機能、企業向けの新機能などの開発に取り組んでいます。
これらの開発をさらに加速させるため、私たちは2021年7月から体制変更を行いました。これまでは「Sansan」や「Eight」などのプロダクトごとに専属のモバイルアプリ開発チームが存在していましたが、そのチームを1つに統合し、プロダクト横断で開発をするためにMobile Applicationグループを立ち上げたのです。
過去の体制では、モバイルアプリを担当するエンジニア同士が、プロダクトチームをまたいで情報交換をするのは難しい部分がありました。また、特定プロダクトの開発のために一時的に人員を増やしたくても、他の事業部からエンジニアに応援に来てもらうことが困難だったのです。モバイルアプリ開発をプロダクト横断の組織形態にすることで、こうした課題の解決を目指しています。
この新しい体制はエンジニアのキャリアにもプラスの影響があります。プロダクトごとに、ソフトウェアのアーキテクチャや開発プロセスは異なるもの。そうした複数の環境を経験することは、エンジニアとしての成長に結びつきます。また今後は、エンジニア一人ひとりの目指すキャリアプランに応じて、担当するプロダクトや機能を選択可能にすることも構想しています。
エンジニアが自らのスキルを向上させるには、「どのような環境に身を置くか」がとても重要です。Mobile Applicationグループは深い知見を持つエンジニアたちとともに、“モバイルアプリ開発のスペシャリスト”として切磋琢磨できる環境。これ以上ない研鑽の場です。
Sansanの提供するアプリを、さらに価値のあるものに洗練させるため。そして、ユーザーへの提供価値を最大化するため。エンジニアたちは今日もモバイルと向き合っています。手のひらに収まる小さな端末の向こうに、私たちは無限の可能性を見いだしています。
 
 

Mobile Application Group(iOS) 技術スタック

CategoryTechnology Stack
Sansan(iOS)Programming Language Swift, Objective-C
Library RxSwift, Alamofire, Realm, SDWebImage, KeychainAccess, SwiftyUserDefaults, R.swift, XcodeGen
Monitoring Firebase Crashlytics
CI Bitrise, GitHub Actions
Machine learning Library CoreML
Code Management GitHub
Architecture VIPER
CI Bitrise
Design Tool Figma
Testing Service DeployGate
Eight(iOS)Programming Language Swift, Objective-C
Library RxSwift, Realm, Swinject, SwiftGen
CI Bitrise
Code Management GitHub
Architecture MVVM
Design Tool Figma
Testing Service Deploygate, Google Play Console
 

iOSエンジニアに関する記事

社内ライブラリを Swift Package Manager に対応させた話 その1 ~Swift, Cベースの言語, MLModel が混在するプロジェクト編~ - Sansan Tech Blog
こんにちは、 Mobile Application Group で iOS アプリエンジニアをやっている 多鹿です。 過去にもいくつかこのブログに投稿してきましたが、 iOS アプリエンジニアらしい記事を書くのは初めてかもしれません。 今回は、 Sansan / Eight の iOS アプリにて共通で使っている社内ライブラリを Swift Package Manager (以降 SwiftPM) に対応させた話をしていこうと思います。 二つのライブラリを SwiftPM に対応したので「その1」と「その2」の二回に渡ってそれぞれのライブラリの対応について共有できればと思います。 Sansan / Eight の両 iOS アプリケーションでは、どちらも「名刺」を端末のカメラで撮影する機能があります。 カメラに投影した「名刺」をリアルタイムで認識する機能と、撮影した画像から名刺部分を切り抜く機能が別のライブラリになっており、それぞれ研究開発部が開発したものを iOS アプリケーションからは Carthage を使用して xcframework にしたものを使用しています。 今回 SwiftPM に対応したのはこの「名刺認識」ライブラリと「名刺の切り抜き」ライブラリの二つになりますが、本記事ではこれら二つのうち「名刺認識」ライブラリについて書いていきます。 また、本記事にて「名刺認識」ライブラリそのもののリアルタイム名刺認識の技術を掘り下げることはしませんが、研究開発部による下記の記事で触れられているので、興味がある方は併せてご覧ください。 buildersbox.corp-sansan.com Sansan iOS アプリケーションおよび Eight iOS アプリケーションにおいて、 SwiftPM を利用して名刺認識ライブラリを利用できるようになること SwiftPM 対応後も従来通り Carthage を利用したライブラリの使用ができること*1 今回の対象である名刺認識ライブラリは、ベースになる処理が C++ のコードベースになっており、 iOS / Android 共通で利用できるようになっています。 そのため、このリポジトリの構成は「共通の C++ コードベース」「Android アプリに組み込むフレームワーク」「iOS アプリに組み込むフレームワーク」がディレクトリによって分かれており、やや複雑な構成になっています。 .
チームが統合され、案件も全員で開発するようになった Sansan iOS チームで試行錯誤したことまとめ - Sansan Tech Blog
こんにちは、技術本部 Mobile Application グループの山名です。 普段は Sansan iOS チームで iPhone/iPad アプリを開発しています。 本記事は Sansan Advent Calendar 2022 の3日目の記事になります。 adventar.org 前回予告した通り、今回は最近の Sansan iOS チームで起きた変化、生じた問題、解消に向けた試行錯誤についてお話しします。buildersbox.corp-sansan.com 大きく2つの変化がありました。 内部で2チームに分かれていたが、1つに統合 案件は個人が担当していたが、チームで担当することに まず前者ですが、 弊チームは内部的に Cocoa と Cupertino という2つのチームに分かれていました。 分かれた当時はチーム全体の人数が多かった、見習い中のチームリーダー(以下 TL)を育成するためにあえて細かく分けたかったなどの事情がありました。 しかし異動によってチーム全体の人数に変化があり1チームあたり開発メンバが2人程度に、TL も見習いから正式登用になるなど状況が変化しました。 その結果、ただただマネジメントコストだけが高いという状況になったため、統合するに至りました。統合後の構成は TL 1、開発メンバ4、アーキテクト1 です。 次に後者ですが、弊チームでは余程規模が大きくない限り、案件は個人が担当する方針でした。 それはそれでマネジメントコストや開発者間のオーバーヘッドが発生しないというメリットもありましたが、ドメインの知識が偏ってしまうことや、チームとしてのベロシティが出せないので確度の高いリリース日を出しづらいという問題がありました。 そんな折、チーム統合というイベントが発生したため、それを機に案件もチーム全体で担当する方針に変わりました。 ...と、ここまで聞くと良さげな変化に思えますが、水面下では色々と問題が生じていました。 体制変更後、タイミング良くそこそこの大規模案件(10人月くらい)が降ってきたので、新体制で取り組むことになりましたが、その中で問題が表面化しました。 ありがたいことにプロジェクトリード(以下 PL *)を任せてもらっていたので、その視点から印象的だったことを2つ紹介します。 コードレビューの時間増加 & 品質低下 案件全体の進捗が把握しづらい * PL はその名の通りプロジェクトをリードする役割ですが、Sansan ではプロジェクト全体を横断的に見る役割としての PL は存在しないため、各プラットフォームにおけるまとめ役のことを指しています。Sansan iOS だとプロダクト側(PdM・デザイナ・データ分析)と他プラットフォーム(API・Android)に対する窓口、TL へのプロジェクト進捗報告、アーキテクトとの設計相談、開発メンバの進捗管理、チーム内でのリソース調整など、諸々の活動を主導します。 弊チームでは Pull Request は Approve が2つ付かないとマージできない決まりになっています。Approve を付ける人は PR 作成者が指名するのですが、以下のように1人目と2人目で役割が異なります。 1人目:仕様としての間違い/漏れがないか等、要件の実装に対して責任を持ってレビューする 2人目:具体的なコードの書き方や適切な責務分割ができているか等、保守性を意識した実装に対して責任を持ってレビューする その性質上、1人目はチーム内の案件を把握している TL が、2人目はランダムなメンバがアサインされるのが通例でした。ただチームの統合によって TL が1人になり、そのままだとチームの全ての PR を見ることになって流石に無理があるため、2人ともランダムアサインすることになりました。 しかし、これによってコードレビューの時間増加と品質低下が発生してしまいました。案件を個人が担当し、TL以外は全体を把握していなくてもレビューできるという状況が長く続いていたためです。案件の初期から把握している TL と比べ、どうしても仕様の確認に時間がかかる、理解度が浅いことによって議論が長引く、細かな仕様までチェックしきれないという事態が起こりました。 この問題を解消すべく、実装前にチーム全体へ担当箇所の仕様と設計を共有する会を設けました。誰が1人目にアサインされても問題ないよう、共有と質疑応答を通して解像度を上げてもらうのが狙いです。実施前は PR にアサインされると「そもそも何の PR だこれは...?」という状態でしたが、実施後はタイトルを見るだけで「ああ、あの機能のあそこの部品の PR ...
 

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

 

Sansan株式会社について

 

Sansan Tech Podcast

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