Android エンジニア


応募要項はこちら

テクニカルリード


Pick Up コンテンツ

プロジェクトの難所を乗り越えた経験が、エンジニアとしての成長を支えてくれた。

技術本部 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
今後どれだけキャリアを重ねても、エンジニアとしてコードを書き続けていたい──。そう話すのは、Mobile ApplicationグループでAndroid版のモバイルアプリ開発やアーキテクチャ設計、チームのマネジメントに従事する山口佳祐。エンジニアとして技術力の研鑽を続ける山口に、自らの仕事にかける思いを聞きました。続きを読む
 

 
 

Mobile Application Group チーム概要

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

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

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

CategoryTechnology Stack
Sansan(Android)Programming Language Kotlin
Library Dagger2, Kotlin Coroutines, Android Architecture Component, OkHttp, Retrofit, Epoxy
Infrastructure AWS
Monitoring Firebase Crashlytics, Mixpanel
CI GitHub Actions, Bitrise
Machine learning Library CoreML
Code Management GitHub
Architecture Flux
CI GitHub Actions, Bitrise
Design Tool Figma
Testing Service Deploygate, Google Play Console
Eight(Android)Programming Language Kotlin,Java
Library RxJava, Realm, Dagger2, Retrofit, Kotlin Coroutines
Monitoring Firebase Crashlytics
CI Bitrise
Code Management GitHub
Architecture Flux
Design Tool Figma
Testing Service Firebase App Distribution, Bitrise
 

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

僕たちが「アプリがバックグラウンドに回った」の判定にProcessLifecycleOwnerを使わなかったワケ - Sansan Builders Blog
こんにちは!Sansan 技術本部 Mobile Applicationグループの ふるしん です。 本記事は Sansan Advent Calendar 2021 - Adventar 16日目の記事です。 普段は大阪のオフィスでAndroidアプリの開発に従事しています。 play.google.com Sansanアプリでは「アプリがバックグラウンドにまわったら即時実行したい処理」があり、その実装に苦労したので共有します。 「アプリがバックグラウンドにまわった」判定に androidx.lifecycle.ProcessLifecycleOwner を使うとハマりどころがあるので注意が必要 ProcessLifecycleOwnerはアプリのライフサイクルに反応してくれる便利なクラスです。 パっと見これをonStopでobserveすればとバックグラウンド判定が取れそうだなと思って使ってみました。 ただonPause、onStopの動きがちょっと癖があり注意が必要です。 (※本記事執筆時点でのバージョンは2.3.1です) public class ProcessLifecycleOwner implements LifecycleOwner { @VisibleForTesting static final long TIMEOUT_MS = 700; void activityPaused() { mResumedCounter--; if (mResumedCounter == 0) { mHandler.postDelayed(mDelayedPauseRunnable, TIMEOUT_MS); } } void activityStopped() { mStartedCounter--; dispatchStopIfNeeded(); } void dispatchStopIfNeeded() { if (mStartedCounter == 0 && mPauseSent) { mRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP); mStopSent = true; } } } ProcessLifecycleOwnerはonPauseとonStopで700ms分delayさせています。 その理由が公式ドキュメントに書かれています。 Lifecycle.Event.ON_PAUSE, Lifecycle.Event.ON_STOP, events will be dispatched with a delay after a last activity passed through them.
Jetpack DataStore入門〜Proto DataStore実装編〜 - Sansan Builders Blog
こんにちは!Sansan事業部 プロダクト開発部の ふるしん です。 私は大阪のオフィスでSansanプロダクトのAndroidアプリの開発に従事しています。 この記事は Jetpack DataStore入門〜Preferences DataStore実装編〜 の連載として、Proto DataStoreの実装を見ていきます。 Preferences DataStoreに関しては以前の記事を御覧ください。 buildersbox.corp-sansan.com SharedPreferencesに代わるものとして提案されている、新しいデータの永続化の方法です。 公式ドキュメントによると 、SharedPreferencesから置き換えることを考えてね、と書かれていました。 DataStoreは、基本的にはSharedPreferencesの欠点を補うために提案されているようです。 ですので例えば動作はKotlin CotourinesのFlowに則って動作して非同期で走ってくれたりと、他にも素敵だなと思う点がいつくかありました。 今回はそんな点を紹介できたらなと思います。 DataStoreと一言で言っても実は2種類あります。 Preferences DataStoreと、Proto DataStoreです。 本記事ではProto DataStoreに関して見ていきます。 Preferences DataStoreとの違いは「Protocol Buffersを使う」部分です。 Preferences DataStoreではほぼプリミティブ型しか格納できなかったものが、Proto DataStoreではProto Buffersを活用することで自由な型を格納できるようになります。 この `自由な型を格納できるようになる` が嬉しい人は多いのではないでしょうか。 従来のSharedPrefernecesだとプリミティブ型しか格納できなかったためにわざわざDBのテーブルを用意していたものが、サラッと格納できるようになるのは大きな利点だと思います。 では実際にどうやって使うのか、コードを追って説明していきます。 本記事の執筆時点では 1.0.0-beta01が最新でした。 また、後述しますがlifecycleScopeも必要なので追加します。 app/build.gradle dependencies { // DataStore implementation "androidx.datastore:datastore:1.0.0-beta01" implementation
Jetpack DataStore入門〜Preferences DataStore実装編〜 - Sansan Builders Blog
こんにちは!Sansan事業部 プロダクト開発部の ふるしん です。 私は大阪のオフィスでSansanプロダクトのAndroidアプリの開発に従事しています。 play.google.com この記事では、連載として2020年 9月 2日に1.0.0-alpha01として公開されたJetpack DataStoreについて解説していきます。 developer.android.com 2020年10月に行われた GDG DevFest 2020でもセッションでお話しましたので、よろしければその際の動画や資料も御覧ください。 www.youtube.com 前置きが長くなりましたが本題です。 Jetpack DataStoreとは? SharedPreferencesに代わるものとして提案されている、新しいデータの永続化の方法です。 公式ドキュメントによると、将来的にはSharedPreferencesから置き換えることを考えてね、と書かれていました。 DataStoreは、基本的にはSharedPreferencesの欠点を補うために提案されているようです。 ですので例えば動作はKotlin CotourinesのFlowに則って動作して非同期で走ってくれたりと、他にも素敵だなと思う点がいつくかありました。 今回はそんな点を紹介できたらなと思います。 DataStoreと一言で言っても実は2種類あります。 Preferences DataStoreと、Proto DataStoreです。 それぞれの使い方を見ていきます。 Preferences DataStore こちらはSharedPreferencesに限りなく近いです。 格納できる型はSharedPreferencesとほぼ同じIntやStringなどとなっています。 他にどんな型が格納できるかは 公式ドキュメント を御覧ください。 では実際にどうやって使うのか、コードを追って説明していきます。 app/build.gradle dependencies { ... // Preferences DataStore implementation "androidx.datastore:datastore-preferences:1.0.0-alpha06" ...
 

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

 

Sansan株式会社について

 

Sansan Tech Podcast

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