こんにちは。 Sansan 事業部プロダクト開発部で iOS アプリエンジニアをしている中川です。 今回は 5/25 に開催された Sansan Technical View に参加してきたので、それぞれの発表についてまとめてみました。参加されていない方へとっかかりになればと思います。
Opening Talk
弊社 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」。正直、想像ができないほどのビッグデータです。このデータを有効活用し、ユーザーのビジネスを後押しする新機能の企画や開発が日々進んでいます。
XcodeGen を利用したマルチモジュール化の取り組み
ここから各プロダクトを担当するエンジニアの発表になります。 ファーストバッターは法人向け名刺管理サービス Sansan の iOS アプリを担当する相川です。 アプリの紹介からどんな課題があったか説明があった後に解決策の取り組みについて話されてました。
アプリの紹介では相川から「名刺管理をするアプリだと思われがち」と前置きを置いた後に以下の機能紹介がありました。
- オンライン名刺交換機能
- 名刺を自動認識し、名刺情報をデータ化
- 名刺交換した相手の情報を外出先で閲覧
- 名刺を元にした企業のニュースを閲覧
- 同僚とコミュニケーション
- 商談記録
- etc
名刺を軸に様々な機能が備わっているアプリであることが分かります。 そんなアプリの開発メンバーとして join した相川が体感した課題は以下のように説明しています。
- 開発スピードの加速によるコンフリクトの増加
- project.pbxproj が可読性が低いファイルなのに、プロジェクト内のファイル操作だけで差分が発生してしまうのが問題
- コードベースの課題
- Swift は同モジュール内であれば、 import が不要という言語仕様があり、 ファイル間の依存関係が不明瞭
- 現在は VIPER アーキテクチャを採用しているが、昔の MVC 時代のレガシーコードが数多く残っている
これらの課題に対する解決策を以下のように話しています。
- XcodeGen という project.pbxproj 生成ツールの利用
- Embedded Framework 化による import の強制
XcodeGen の解説は以前、相川が投稿した記事にて詳細に説明されているのでここでは省略します。
XcodeGen を導入することによって、二点目の Embedded Framework 化の実現可能性にも寄与したとの前置きの後に解説が始まります。
ファイルの集まりを Framework (モジュール) として分割する仕組みを Embedded Framework といい、モジュール間の依存関係を明確にすることを期待して、取り組んだとのことです。 副次的な効果として、ビルド時間の短縮や Framework ごとにテストが記述できる点を挙げていました。 XcodeGen を導入したことによって、 yml に Embedded Framework の設定を記載するだけでよく、共通設定を切り出して、個別の設定に毎回書かなくても良い状態にしていたり、チームでのコードレビューも出来たことが良かった点として紹介がありました。 ただ、進め方に課題があったようで以下のように説明されてました。
- 事前調査不足でEmbedded Framework 化しやすいと思っていた箇所が実際はそうではなかった
- 理想形を考えられておらず、方針にブレが生じ、チームを混乱させてしまった
これらの課題から得られた学びとして以下のように紹介されてました。
- アーキテクチャに変更を加える場合、影響範囲を明確にすることと理想形を考えること
- 開発環境に変更を加える場合、アイデア段階からチームメンバーに共有しつつ、徐々に進めること
ニューノーマル時代のイベント運営への取り組み
次はビジネスイベント「Meets」を担当する齊藤です。 「Meets」はユーザーが抱えているビジネス上の課題とそれを解決するソリューションを持つ企業をイベントを開催することでマッチングするサービスと説明があった後、運用パートと技術パートに分けて取り組みが紹介されます。
スイッチスリーリード制
運用パートではイベント事業である「Meets」がコロナ禍が原因で急速なオンラインシフトを求められ、開発が多忙になる中、プロジェクトをマネジメントするために行った施策として、「スイッチスリーリード制」を取り入れた話になります。
「スイッチスリーリード制」自体は独自の呼称のようで、以下の 3 つのリードの役割を用意し、定期的に交代する制度のことを指すようです。
- プロダクトリード
- アーキテクトリード
- チームリード
この「スイッチスリーリード制」を取り入れたことによるメリットは以下の 4 つと説明されていました。
- アテンションを貼るべきポイントが絞られ、集中して改善に動けるようになった
- リードをローテーションすることで多視点からの改善が進んだ
- それぞれが各リードを経験することで相互理解が深まり、認識齟齬が減った
- 役割を与えられたことでリモートでのモチベーションの維持につながった
これらのメリットは「Meets」に限らず、他の開発現場でも得られるものになっており、すべてを真似るのではなく、各々の課題が改善される見込みのある体制変更やプロセスの導入を行えると良いかなと思いました。
インタラクティブなコンテンツの仕組みとその実装
技術パートでは「Meets」のオンラインサービスにあたる「Meets Online Live」でのインタラクティブなコンテンツをどのように作ったのか紹介がされます。「Meets Online Live」は Web 上でセールスピッチ動画が配信され、ユーザーが気に入ったサービスのデモを選択すると、デモが配信され、最後にアンケートが表示される流れになっており、デモ選択、デモ配信、アンケート表示は運営から操作する必要があるそうです。また、イベントを盛り上げる要素としてユーザーによるリアクション機能も備わっています。
技術選定では手法としてポーリング、もしくは、 WebSocket が選択肢として挙げられ、判断軸としては工数削減のため、インフラの作業がなるべく減らせるものである必要があったため、「Meets Online Live」では WebSocket 版の API Gateway を選択したそうです。
ここからは以下の 3 つの機能に関する処理フローの解説が行われました。
- WebSocket 接続確立
- リアクション機能
- 運営からユーザーへ通知する機能
これらの詳細なフローチャートは下記の発表スライドに含まれてますので、気になる方は見てみてください。
新規事業でもマイクロサービスに挑戦する
次はクラウド請求書受領サービス「Bill One」を担当している加藤です。 新規事業でマイクロサービスアーキテクチャを採用するのはアンチパターンと一般的に言われることが多い中、「Bill One」でどうマイクロサービス化したのか、その効果について発表がありました。
サービス開始当初からマイクロサービスで作っていたかでいうとそうではなく、以下のフェーズを得て、マイクロサービス化に至ったようです。
- Django で素早く作って社内トライアル (モノリス)
- Kotlin で追加機能を開発 (モノリス + DBを共有するサービス + マイクロサービス)
- ピボットして 1 から作り直す (マイクロサービス)
マイクロサービスを選択した理由を他のアーキテクチャを選択しようとした場合の状況とともに説明されていました。 モノリスを選択しようとした場合、メンバーの得意なスキルで良さそうな構成が見つからず、モジュラモノリス (アプリケーションコードはモジュール分割し、デプロイ先がモノリス) を選択しようとした場合、モジュール同士の境界を維持し続けられるのか自信がなかったため、サービス間の分離が強制されるマイクロサービスが他の選択肢と比べて、優位になったようです。
では、実際に「Bill One」でどのようにサービス分割されたのかというと、以下の 3 つのサービスに分割されていました。
- invoice (請求書を受領する企業内に閉じた機能)
- network (請求書を発行する企業とのネットワーク機能)
- tenant (テナントやユーザーを管理する機能)
マイクロサービス化の効果としては以下を挙げていました。
- 新機能を素早くリリースしていける
- 障害発生時の影響範囲を局所化できる
最後に「Bill One」での実装方針の紹介です。一般的に知られているマイクロサービスのアンチパターンは踏まないように以下の方針に従っているようです。
- サービスの独立性を重視する (サービスごとにデータベースを持つ、キューによる非同期のデータ連携、共有ライブラリは作らず重複を許容する)
- なるべく開発・運用効率を落とさない (Trace Context を使ったサービス横断でのログ閲覧、モノレポ化)
それぞれの実装方針の詳細は下記の発表スライドに図付きでまとまっていますので、気になる項目があった方は見てみてください。
エンジニアリングが支える研究開発
最後は DSOC の研究開発部で研究員の高橋です。 DSOC は Data Strategy & Operation Center の略で「ディーソック」と読み、 Sansan や Eight で利用されるデータを統括する部門でミッションとして「Activating Business Data」を掲げています。ミッションを説明すると、名刺、書類、業績や株価など企業の公開情報、あらゆるビジネスデータから「出会いのデータベース」を構築し、ビジネスや社会、未来へとつながる新しい可能性を生み出すことのようです。
そんな DSOC が生み出した研究開発の事例紹介が続きます。
- 名刺データ化システム「GEES (Global, Elastic, Efficiency, Scalable)」
- スマートキャプチャー
- 項目セグメンテーション
- 言語判定
- ミステイクディテクター
- パーソナライズされたニュース配信システム
一風変わった事例として Sansan Labs の紹介があります。 Sansan Labs は Sansan のプロダクト内で「未来の働き方を実現する」実験的な機能を提供しているものですが、実際に多くの顧客から利用されているものは正式機能として組み込まれる場合もあります。
さて、数多くの研究開発の実績がありますが、高橋は研究開発の目指す状態を「新しい可能性を生み出し、ユーザーへ価値提供しつつ継続的に改造される」状態と表現し、「新しい可能性を生み出す」は研究の側面が強く、「ユーザーへ提供しつつ継続的に改善」は本番運用を指し、エンジニアリングの側面が強く、両立の大切さを説明していきます。
そもそも、研究段階では検証が目的で動けばよいが、本番運用となると要件に合わせたアーキテクチャ選定を行ったり、利用可能な状態を保ったり、デプロイフローの整備と多くのエンジニアリングが求められます。下の表は実際に高橋が担当した研究開発を例に各項目を比較しました。
| 項目 | 研究員が作りきってしまうアンチパターン | エンジニアによりエンジニアリングが導入されたパターン |
|---|---|---|
| 研究員の責務 | すべて担当 | コンテナとしてアルゴリズムを提供 |
| エンジニアの責務 | なし | デプロイフローやログ基盤など運用を整備 |
| 稼働状況 | エラーになかなか気づけず、改修やデプロイが難しく時間を要する | 安定稼働、かつ、改修のデプロイはデプロイパイプラインがあるため研究員でも完結 |
次に、より研究開発を加速する取り組みとして DSOC では研究員のコードを「とりあえず動く」状態から「良いコード」にするためにガイドラインの策定や flake8 を利用したコードチェック、テストを積極的に導入することを行っています。また、キャッチーな MLOps にも最近は取り組んでいて、推進チームの発足、解決したい課題を整理中です。
DSOC における MLOps の取り組みについては下記の発表スライドを見てみてください。
Sansanでは様々な勉強会・イベントを開催してます。connpassのSansanグループやTwitter @SansanTech で情報を発信していますので、ぜひフォローをお願いします。
