iOS エンジニア


応募要項はこちら

テクニカルリード


Pick Up コンテンツ

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

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

 
 

チーム概要

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エンジニアに関する記事

【オンライン名刺開発の裏側】iOS アプリ開発で良かったことを紹介! - Sansan Builders Blog
こんにちは。 Sansan iOS アプリエンジニアの中川です。 Sansan iOS アプリは今年の 6 月 15 日にメジャーバージョンアップをしました。 このバージョンアップにはオンライン名刺が目玉機能として含まれています。 オンライン名刺は昨今の新型コロナウイルスの流行から企業がテレワークやオンライン上での働き方への移行を迫られている中、名刺交換をオンラインで実施できない現状に対して、会社として向き合わなければならなかった重要な機能でした。 改めて、数字を出してみると、多くのメンバーがオンライン名刺に向き合ってくれたことが分かります。 これほどの人数で一機能を作るのは自分の経験の中でもはじめてのことでいかに円滑に進めて、事業的に要求されている期日にコミットできるかプロジェクト当初に頭を悩ませていたことを思い出せます。 では、何がオンライン名刺の開発で有効だったか、チームで振り返って出た意見を以下に挙げます。 採用しているアーキテクチャとデザインとの親和性が高かった エラーハンドリング、ローディングについての指針ができた Sansan iOS アプリでは VIPER*1 と呼ばれるアーキテクチャを採用しています。 VIPER は一画面、一機能をモジュールとして扱い、責務を分離します。モジュール間のデータの受け渡しは Router を通して行われるため、渡すデータの方式だけメンバー間で合意が取れていれば、その後の画面、機能実装については独立して開発を進めることが出来ます。また、アプリに実装されたデバッグメニューで Router からダミーデータを差し込んで、遷移前画面の実装前に動作確認やデザイナーレビューを実施することが出来ました。 そして、以下がデザイナーが作成したプロトタイプです。 プロトタイプを見ると一目瞭然ですが、大量の画面から構成されています。この画面毎にモジュールを区切ることで並列数をチームメンバーの最大である 9 まで上げることが出来ました。 Sansan iOS アプリでは今までエラーハンドリングやローディングは機能毎に UI / UX を考えながら、作ってきたため、共通の指針もなく、プロジェクトごと、実装者ごとに思い思いの実装がされてきました。そのため、コードの統一感はなく、コードレビューや影響範囲調査をする際に手間がかかるし、新機能を実装する度に固定の工数として積まれるため、開発のスピードに影響を与えていました。 しかし、オンライン名刺のプロジェクトにて、デザイナーとエンジニア間で共通の指針が作られ、それに則って、共通のコンポーネントができたため、エラーハンドリングやローディングの実装が楽になりました。まず、どのような指針を策定したか、紹介します。 上記の指針を満たすために作ったコンポーネントを紹介します。 Sansan iOS アプリは API 通信のハンドリングに RxSwift を利用しています。 API 通信を行う前に処理を挟むことで容易にローディングを共通化することが出来ました。 ローディングを挟む Observable は RxSwift のサンプルコードに含まれている ActivityIndicator.swift を利用しています。 Sansan iOS アプリでは以下のように実装してます。 1.
App Clip - in a nutshell 前編 - Sansan Builders Blog
こんにちは。最近子供の頃にハマっていた、懐かしいゲームたちが続々とリマスターされて、プレイしながらエモい気分に浸っている iOS チームの髙橋佑一朗です。 今回はタイトル通り、社内で行った WWDC キャッチアップ会のために作成した App Clip についてのスライドを記事にしてみました。 勉強会で利用したスライドも公開しております ので合わせてご覧ください! また、今回の記事を書くにあたって利用した動画は3本ありますが、ひと記事でまとめようとするととても長くなってしまうため、前編・後編に分けて紹介したいと思います! 前編で紹介する動画 後編で紹介する動画 前編の目次 App Clip は iOS14 から追加される本体アプリのダウンロードが不要な軽量版のアプリのようなもので、しかもネイティブで動作するので、本体アプリと変わらない体験を提供することができる Cool なやつです。 まずは App Clip を理解するために必要な三つの概念を説明していきます みんな大好き iOSアプリです。 App Clip はアプリの extension としてプロジェクトを追加する形になるため、App Clip だけを作るということはできません。必ずこの本体のアプリが必要になります。 また、ソースコードや画像、アイコンなどのアセットを App Clip と共有することが可能です。 こちらはユーザが App Clip を見つけて体験するためのエントリーポイントになるものです。 内部的には URL になっており、NFCタグやQRコード、後述する App Clip Code など様々な形式で見つけることが可能です。 物理的なもの以外にも位置情報と紐付けて Map や Siri の NearBy のサジェストから見つけることもできます。 App Store Connect から使いたい URL を App Clip Experience として設定することで使い始めることができます。 App Clip Code?
「After iOSDC Japan 2020」参加レポート - Sansan Builders Blog
こんにちは! Sansan事業部でiOSアプリエンジニアをしている砂金です。 先日開催された「After iOSDC Japan 2020」に参加しましたので、その様子をレポートしたいと思います。 After iOSDC とは After iOSDCとは、iOSDCの振り返りをしつつ、LTやパネルディスカッションにより、iOSに関連する技術やノウハウを共有するイベントです。 今回のAfter iOSDCは、note(株)、(株)ZOZOテクノロジーズ、Sansan(株)の3社によるオンライン合同イベントとなりました。 イベントの様子はYoutubeからも確認できますので、ぜひご覧になってみてください。 イベント概要 LT 特別講演 パネルディスカッション トップバッターは、ZOZOテクノロジーズの元さんによる、アプリの起動時間の改善に関してのLTとなります。 起動時間について考慮することがなぜ重要かについては、WWDCでAppleは以下の3点を挙げています。 起動がスムーズであることが、アプリの第一印象の良さに繋がる 起動時の処理がコードの全体的なパフォーマンスを示す 起動時にCPUやメモリの負荷を抑えることが、バッテリーやパフォーマンス改善に繋がる 上記を踏まえた上で、どのようにして起動時間を短縮していくかを見ていきましょう。 まず、アプリの起動時間短縮のためのアクションをとる前に、現状の起動時間を計測しないことには改善のしようがないですね。 そこで挙げられていたのが以下の3つです。 Metrics Organizerを使う Window → Organizer → Metricsから確認可能 現状の起動時間を把握する Instrumentsを使う App Launchを使うことで、起動処理のデバッグが可能 環境変数にDYLD_PRINT_STATISTICSを追加する pre-main time(UIApplicationMainがreturnされるまでの時間)を表示できる 計測する際には以下の2点をしておくことで、起動時間の計測に対しての外部からの影響を抑えることができます。 iCloudをログアウトしておく ネットワークは切るか機内モードにしておく アプリ起動時間の計測方法と注意点について理解したところで、 次に、アプリの起動フェーズを6つに分けて説明していただきました。 System Interface Init Runtime Init
iOSDC Japan 2020 & After iOSDC Japan 2020 に登壇しました - Sansan Builders Blog
こんにちは。 Sansan 事業部プロダクト開発部で iOS アプリエンジニアをしている中川です。 今回は iOS 関連技術をコアのテーマにした技術者向けのカンファレンスである iOSDC Japan 2020 と その振り返りイベントである After iOSDC Japan 2020 に登壇の機会をもらい、登壇をしてきたので、それぞれの登壇についての感想だったり、新たな発見だったりを共有できればと思い、筆を執ります。 どちらのイベントもオンラインでの開催は初の試みでしたが、様々なサービスを活用して、オフラインで行われていたスピーカーと参加者のコミュニケーションをオンラインへ移行出来ていたように思います。 iOSDC Japan 2020 でコミュニケーション用途で利用されたサービス一覧 After iOSDC Japan 2020 でコミュニケーション用途で利用されたサービス一覧 以下は iOSDC Japan 2020 のトーク配信時のコミュニケーションの一例です。 トーク開始時、終了時に「8888」コメントで盛り上げてくださったり、トークの内容に対しての質問や私の補足コメントに関する共感などオフラインでは味わえないようなトーク中のコミュニケーションがとても楽しかったです。 コメントをしてくださった皆さま、本当にありがとうございました。 以下は After iOSDC Japan 2020 の質疑応答時の一場面です。 この時はリアルタイムで LT を行った後で緊張もあり、分かりやすい回答が出来たか、自信はないですが、自分で適切な回答が出来なかったものは Twitter で別途、回答をしたりとフォローアップは出来たと思います。 休憩中の時間を利用して、 https://t.co/JdzWmvbSoo の回答、ちょっと適切ではなかったので、以下の質問について、スレッドにて補足します。 「UI
iOS14 勉強会参加レポート - Sansan Builders Blog
こんにちは。Twitter に流れてくる PS5 当選Tweet を見て嫉妬にかられている iOS チームの髙橋佑一朗です。 今回は 11/06 の金曜に行われた「アプリ開発に強みを持つ3社がiOS14の開発事情を語る」 に参加してきましたので、その内容をレポートにまとめてみました! 今回の勉強会はつい最近リリースされた iOS14 へのアプリ対応の取り組みについて 株式会社Mobility Technologies、株式会社ゆめみ、Sansan株式会社の3社の iOS エンジニアが登壇し、どのような開発を行っているか、どんな部分に苦労したかお話ししていただきました! トップバッターは今年4月に会社統合をした Mobility Technologies の日浅さんから、会社統合後のチームビルディングやその中での iOS 14 対応についてお話いただきました! 今年の4月に会社統合が行われ、 JapanTaxi と MOV のエンジニアが一緒になったことで合計8名になり 、開発も爆速でできる!と喜んでいたのも束の間、統合直後の課題として次のようなものを挙げられていました。 新しいアプリの仕様が FIX していないため、開発が進められない 人数が増えたが、既存アプリの改修、問い合わせ対応でリソースが持っていかれてしまう コロナ渦でリモートワークだったため、新メンバーとのコミュニケーションが取りづらい 4月といえばコロナが日本でも猛威をふるい始めた時期でとても混乱していた時期に思います。そんな時期に新しいメンバー、新しい環境で仕事をするということは自分が考える以上に大変なのかなと感じました。 開発を円滑に行うためには多くの課題がありましたが、アプリの仕様が固まった際に爆速で開発できるように準備を進めていたようです。 リソース増強へ向けて 既存アプリの対応を減らしていくため、JapanTaxi アプリの開発、運用を委託したそうです。 委託に関して、 JapanTaxi は Library アップデート、コードフリーズやリリース作業の自動化などをしており、コミュニケーションパスの整理だけで開発の移譲が終わったということでした。 開発を移譲したことで 80% ほどプロパーエンジニアの対応工数を削減できており、既存アプリの対応工数の問題は解決したそうです。 自動化やリリースの自動化に関しては同じくMobility
iOS アプリで様々なファイルをプレビューできる QLPreviewController の紹介 - Sansan Builders Blog
こんにちは、Sansan プロダクト開発部 iOS アプリエンジニアの相川です。最近個人的に機械学習を勉強していて、数学の勉強もすることになり、毎日新しいことを学ぶことができているのと大学時代に塾講師をしていた経験も少し活きていて楽しいです。 今回は iOS アプリにおいてファイルを簡単にプレビューできる API である QLPreviewController について紹介しようと思います。 Sansan アプリにはコンタクト(商談記録のようなもの)を作成できる機能があります。もう夏頃にはなりますが、アプリ内でコンタクトに添付ファイルを付けたり、コンタクトの添付ファイルを閲覧できるようにしたい!という要望がありました。QLPreviewController はそのうちの 添付ファイル閲覧機能 を実装するために利用することとなりました。 ちなみに実装した機能は ↓ のようなものになります。 プログレスバーは QLPreviewController の機能ではありませんが、pdf ファイルを QLPreviewController でプレビューすることによって、pdf を見ることができるだけではなく、ピンチインピンチアウトなどの動作も実現することができていることがわかります。 ちなみに、この機能を実装する際、ファイルプレビューについてはこれから説明する QLPreviewController を利用することによって簡単に実現することができたのですが、Alamofire を利用してプログレスバーを実現しようとしたら非常に苦労した経緯があったので、いつかその話も紹介できたらと思います。 QLPreviewController については公式が一番よくまとまっていると思います。 以下で紹介する内容も WWDC2018 の「Quick Look Previews from the Ground Up」と Apple Documentation の QLPreviewController についての説明を参考にしています。 冒頭で少し紹介しましたが、QLPreviewController は iOS アプリ上で様々な種類のファイルをプレビューすることができる
Sansan iOSアプリにおけるiOS14対応 - Sansan Builders Blog
みなさん、こんにちは。プロダクト開発部iOSエンジニアの荒川です。 本記事はSansan Advent Calendar 21日目の記事です。 11月24日リリースにて、Sansan iOSアプリのiOS14対応が完了しました🎉 今回はSansanアプリで実施した対応をご紹介します! デフォルトブラウザがSafari以外の場合に、 UIApplication.sharedApplication().canOpenURL()が false を返却するようになった影響でアプリからブラウザに遷移できないユーザがいることが分かりました。こちらはiOS14にアップデートしたユーザがすぐに影響を受けることもあり、iOS14がリリースされた直後に修正対応を入れました。 SansanアプリではcanOpenURLに渡るURLスキームが多くもないことから、 LSApplicationQueriesSchemes へアプリで対応しているスキームを追加することで対応を行いました。 https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl Xcode12でCarthageで導入したライブラリをアップデートしようとすると、以下のエラーが発生してビルドが通らないという現象が発生しました。 the same architectures (arm64) and can't be in the same fat output file arm64 向けアーキテクチャを同じファットバイナリに含むことができないというエラーで、Xcode12からApple Siliconへの対応が新しく追加されたために発生するようになりました。 この問題は、CarthageのIssueにもあげられており、公式からWorkaround用のスクリプトが用意されています。 ドキュメントに記載のあるスクリプトを carthage update の代わりに実行することで、Sansan iOSアプリではビルドできる状態となりました。 iOS14より「戻る」ボタンを長押しすることで一気に前の画面に戻ることができるようになりました。 将来的にはロングタップでの体験を整えたいとは思っていますが、一時的に機能をオフとする対応を行いました。 対応自体はApple Forumsを参考とし、 UIBarButtonItem を継承したクラスを作成し、既存の箇所で置き換えることにしました。 アルバムのパーミッション取得に新しく「選択した写真を選択」する機能が追加され、選択した写真のみをアプリに渡す権限制御ができるようになりました。 その影響で UIImagePickerViewControllerにて一部の挙動が変更されており、 phAsset や
Sansan iOS アプリの iPad 対応 - Sansan Builders Blog
こんにちは。iOSチームの髙橋です。皆さんは年毎にテーマや目標があったりしますか? 年が明けてから3週間ほど経ち、まだ今年のテーマで悩んでいましたが、肌荒れや体力の低下など心身の不調を強く感じることが多くあったので今年のテーマは健康になりました。今年は基礎となる主に体力づくりなどに励んでいくつもりです。 さて、今回は昨年 Sansan の iOS アプリで行った iPad 対応についてのお話をしたいと思います。 まだ、最低限の対応しかしてはいませんが、それでも存外対応することが多かったのでこれから iPad にアプリ対応させたいけどどこから始めたら良いのやら?という人の手助けになればなと思います。 iPad 対応を行うにあたって、僕も初めてでしたし、チームとしても対応を行ったことがなかったのでまずは何をする必要があって、どこまでやるべきかというところを明確にする必要がありました。 どこまでやるかと言っても、当時の Sansan iOS アプリは全く iPad 対応をしておらず、画面いっぱいにアプリを表示するところから始めて UISplitView への対応や iPad 用アプリとしてのレイアウトの最適化などやるべきことは無限にありそうで、きちんとラインを引かないと終わらなさそうでした。 そのため、まずは iPad で使えるようにするために最低限どこまでやるべきか?という観点で整理し始めました。 調べていくと 2020年11月 の段階では大きく分けると以下のことをやる必要がありそうでした。 iPad アプリ向けのアイコンと App Store の iPad 用のスクショの準備 UIActivityViewController, UIAlertController (preferredStyle が actionSheet のみ) を利用している箇所について Popover の設定を行う 縦向き、横向きどちらでも使えるように画面回転への対応 SplitView の機能が使えるように画面分割への対応 Popover
Sansan iOS アプリにおけるリリース作業自動化の仕組みを作り直した話 ~背景編~ - Sansan Builders Blog
こんにちは。 Sansan 技術本部 Mobile Application グループで Sansan の iOS アプリを開発している 多鹿 です。 私が Sansan の iOS チームにジョインしてから約 1 年半が経とうとしています。(時が経つのは早いですねぇ、、) 弊チームでは、私がジョインした当初から独自に作成した Slack bot*1 を活用したアプリのリリース作業自動化の仕組みが確立されており、とても便利に ChatOps でアプリのリリース作業を行なっていました。 しかし、この度そんな便利な Slack bot を作り直すことになったので、その背景やどういった構成にしたかを(先人に感謝しつつ)記していこうと思います。 また、当記事では背景や全体像の紹介を行いますが、作り直した仕組みを実現した技術的な話については、 Bolt 編, GitHub Actions 編 という風に続編として連載の形式で別の記事として紹介させていただこうと思います。 まずは、そもそもどのようにして Slack bot を活用したリリース作業を行なっていたのかを紹介します。 ※ iOS アプリの話なので、「リリース= App Store への公開」と読み替えていただければと思います。 Sansan iOS チームでは、毎週*2 週初めの定期リリースを行なっています。
Sansan iOS アプリにおけるリリース作業自動化の仕組みを作り直した話 ~ Bolt 編 ~ - Sansan Builders Blog
こんにちは、Sansan 技術本部 Mobile Application Group に所属している iOS アプリエンジニアの 相川 です。 本記事は「Sansan iOS アプリにおけるリリース作業自動化の仕組みを作り直した話」の 2 作目にあたります。 仕組みを作り直すことになった詳しい背景などについては、弊チームの多鹿による 1 作目の「 背景編 」をご覧いただければと思います。 buildersbox.corp-sansan.com 本記事では Bolt という framework を用いて、Slack 上での対話的なリリース作業自動化の仕組みを作り直した話について紹介しようと思います。 記事が長くなってしまったので、最初に目次を示しておきます。 開発に関する話を紹介する前に、Bolt framework を用いて実現したリリース作業がどのようなものなのかについて簡単に紹介します。 リリース作業の全体像については、1 作目の「背景編」を参照して頂ければと思います。 前提として既存のリリース作業は、大きく以下のように分けることができます。 「deliver」コマンドによって起動するリリース用の作業 「cleanup」コマンドによって起動するリリース掃除用の作業 リリース作業自動化の仕組みを作り直す案件は、作業量が多かったため、第 1 弾と第 2 弾に分割して進めていくことになりました。 第 1 弾では、「cleanup」コマンドによって起動するリリース掃除用の作業の置き換えを行なったため、その部分についてのみ本記事では説明します。 とは言っても、置き換えを行なった「cleanup」コマンドによる対話的なリリース作業の流れは非常にシンプルです。 まずリリース作業担当者は以下の図のように、@AppleBoltDevelop cleanup(本番では @AppleBolt cleanup) というメッセージを
Sansan iOS アプリにおけるリリース作業自動化の仕組みを作り直した話 ~ GitHub Actions 編 ~ - Sansan Builders Blog
こんにちは。 技術本部 Mobile Application Group で Sansan の iOS アプリを開発している山名です。 本記事は「Sansan iOS アプリにおけるリリース作業自動化の仕組みを作り直した話」の 3 本目で、最後の記事となります。 作り直すに至った経緯、Bolt を用いた Slack Bot 作成に関しては、以下の記事をご覧ください。 buildersbox.corp-sansan.com buildersbox.corp-sansan.com 本記事では GitHub Actions を用いて、リリース作業自動化の仕組みを作り直した話について紹介します。 本題に入る前に、少しだけこれまでのおさらいをさせてもらいます。 (1, 2 作目に続いて読んでいただいている方は飛ばしてもらっても大丈夫です) まず、既存のリリース作業は大きく 2 つに分けられます。 「deliver」コマンドによって起動するリリース用の作業 「cleanup」コマンドによって起動するリリース掃除用の作業 ただこれらは一度に実装しきるには作業量が多いです。そのため、第 1 弾では比較的簡単な「cleanup」を、第 2 弾ではその知見を活かしてより難易度の高い「deliver」を実装する形で進めています。 本記事の執筆時点では第 1 弾のみ完了しているため、以下ではそちらの内容についてお話しします。 「 Bolt 編 」で解説した通り、「cleanup」において Bolt で作った Slack

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

 

Sansan株式会社について

 

Sansan Tech Podcast

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