【オンライン名刺開発の裏側】iOS アプリ開発で良かったことを紹介！

こんにちは。 Sansan iOS アプリエンジニアの中川です。

Sansan iOS アプリは今年の 6 月 15 日にメジャーバージョンアップをしました。 このバージョンアップにはオンライン名刺が目玉機能として含まれています。 オンライン名刺は昨今の新型コロナウイルスの流行から企業がテレワークやオンライン上での働き方への移行を迫られている中、名刺交換をオンラインで実施できない現状に対して、会社として向き合わなければならなかった重要な機能でした。

数字で見るオンライン名刺開発

項目	数字
開発に関わった iOS アプリエンジニア	9 人 (全員)
開発期間	33 日 (営業日ベース)
Pull Request 数	189 Pull Requests
前バージョン (v5.6.2) からのコミット数	1567 commits
前バージョン (v5.6.2) からの変更ファイル数	384 files

改めて、数字を出してみると、多くのメンバーがオンライン名刺に向き合ってくれたことが分かります。 これほどの人数で一機能を作るのは自分の経験の中でもはじめてのことでいかに円滑に進めて、事業的に要求されている期日にコミットできるかプロジェクト当初に頭を悩ませていたことを思い出せます。

では、何がオンライン名刺の開発で有効だったか、チームで振り返って出た意見を以下に挙げます。

• 採用しているアーキテクチャとデザインとの親和性が高かった
• エラーハンドリング、ローディングについての指針ができた

レガシーシステムをこえて

Sansanプロダクト開発部・基盤チームの加畑です。法人向け名刺管理サービスSansan(以下、Sansan)の開発をしています。

これまでに、レガシーシステムの改善を主題とした記事を2つ書きました。レガシーシステムのおそうじでは、レガシーシステムを改善するプロジェクトの担当者としての経験をご紹介しました。レガシーシステムとつきあうでは、少し視点を広げ、ソフトウェアや開発組織の拡大に応じたレガシー化の変遷について考察し、組織としてどのように取り組むべきかの一考察を紹介しました。

ソフトウェア（システム）は本質的に複雑性をはらんでおり、変更が生じるかぎりにおいて、メンテナンス性の低下、いわゆるレガシー化と呼ばれる現象は避けられません。レガシーなシステムは事業の視点からみても技術的負債としてメンテナンスコストとして「利息」を払い続けることになります。それを避けるためには継続的に改善していく必要がありますが、レガシー改善プロジェクトはそれ自体が直接的な利益やユーザ価値を生まないにもかかわらず、コストが生じます。このコストを払わない最良の方法のひとつは、レガシー化してからなおすのではなく、開発の過程で生じるレガシー化の程度を最小限に抑えることです。

そこで今回は、「そもそもレガシーシステムを作り込まない」ことを目的に、開発プロセスについて考えてみます。

時間依存性を考慮したWord Embeddingsのまとめ

はじめに

こんにちは、DSOC研究開発部の橋本です。最近買ってよかったな、と思ったものは「詰め替えそのまま」です。これはシャンプーやトリートメントの詰め替えをそのままホルダーにかけて使うことができるようになるグッズで、文字通り（比較的安い）詰め替えをそのまま・簡単に使えるようになる点、お風呂の床に詰め替えを置かなくて済むようになる点という2つの点から非常に良いです。気になる人はぜひググって買ってみてください。
詰め替えそのままの話はさておき、今回時間依存性を考慮したword embeddingsの話をします。

Goで作るテキストエディタ

はじめに

みなさんこんにちは。Sansan事業部プロダクト開発部のiOSエンジニア荒川です。

以前はRDBMSの記事*1を寄稿し、好評いただいたこともあり、定期的に車輪の再発明系の記事を書いていこうと思います。

さて本日はタイトルの通り、VimやEmacsに代表されるターミナルで動作するインラインテキストエディタをGoで開発してみました。

ソースコードは以下のリポジトリに置いているため、ぜひ参考にしてください。

github.com

*1:https://buildersbox.corp-sansan.com/entry/2019/10/24/110000

SCSS-Lint から stylelint に移行した話

こんにちは。Eight でフロントエンドエンジニアをしている鳥山（@pvcresin）です。
ついこの間新卒で入ったと思ったら、もう 2 年目に突入していました。時が経つのは早いものです。
今回は Eight の Web フロントエンドで使っているスタイルのリンター（コードの静的解析ツール）を SCSS-Lint から stylelint に移行した話をしたいと思います。

GraphQLを導入してDX向上（フロントエンド編）

こんにちは。Eight事業部の青山です。現在は社内の名刺を一括管理できるEightのサービス"企業向けプレミアム"で主にフロントエンドを担当しています。

今回は以前投稿されたGraphQL導入記事のフロントエンド側について紹介したいと思います。

REST APIが主流のプロジェクトの中でGraphQLを導入してみた話（サーバーサイド編） - Sansan Builders Blog

導入の経緯やサーバー側については上記記事を参照ください。

Eight本体はReact+Reduxで構成されており、今回GraphQLを利用するにあたりデータ管理をどうするかサーバーエンジニアも交えて議論しました。結果として、Apollo Clientを使ってデータの管理を行うことにしました。

github.com

Apollo ClientはApolloというGraphQLを利用するためのツール群の一部で、GraphQLサーバーに対するクライアントライブラリを提供します。同様の候補としてFacebookのRelayもありますが、データストアとしても活用しやすい、ドキュメントが充実している、連携するツール群が豊富といった点から、Apolloを採用しています。 豊富なツールの中でも、graphql-code-generatorとApollo Serverによって開発者体験(DX)が大幅に向上しているのでそれらを紹介します。

新卒AndroidアプリエンジニアがSansanに入社して感じたこと

こんにちは！Sansan事業部プロダクト開発部の荒です。
今年の4月に新卒で入社し、SansanのAndroidアプリを開発しています。

この記事では、新卒として入社した私がSansanに入社する前に抱いていたイメージと入社して感じたことを書いていきたいと思います。