後編　グローバル対応、インフラ、ユーザニーズ、さまざまな視点からアプローチし開発をするSansan――Sansan Builders Box［セッションレポート］

2018年11月10日、Sansan史上初の、ものづくりに携わるメンバーを中心としたカンファレンス「Sansan Builders Box」が表参道ヒルズ（東京・表参道）にて開催されました。エンジニアや研究員、プロダクトマネージャー、デザイナーなど、同社のサービス開発を支えるさまざまな職種のメンバーたちが登壇し、スキルや経験、ノウハウを惜しみなく公開しました。

Sansan Builders Box: https://jp.corp-sansan.com/sbb2018/

後編は、全セッションの中から、とくに注目したい3セッションについてレポートします。

英訳だけじゃダメ！Eight のグローバル展開のための改善

午前中のモバイルセッションとして用意された「英訳だけじゃダメ！Eight のグローバル展開のための改善⁠」⁠。

本セッションでは、Eight事業部Global Groupスマートフォンアプリエンジニア辰濱健一氏が、名刺アプリEightをインドに展開した際のエピソードを披露しました。日本だけをターゲットにしていたら気づけなかった、グローバル展開のために必要なノウハウについて語りました。

日本とはまったく異なる、インドのインターネット環境

Eightがインドに展開し始めたのは2017年の秋。辰濱氏は「アプリの品質は高いため、英訳をすれば十分に海外展開できると思っていました」と語ります。ですが、インド展開の翌日から、日本では発生しないような不具合が相次いで報告されたのです。

「アプリのダウンロードが完了しない、画面がなかなか切り替わらない、通信が終わらない……。配信するアプリのバイナリファイルを間違えたんじゃないかとさえ思いました」と辰濱氏はふり返りました。

問題の調査・解決のため、開発メンバーたちはインドを訪問します。そこで直面したのは、インターネット通信速度の遅さでした。インドで立てられている通信アンテナは半径数百メートルほどの領域しかカバーできず、建物に入ると電波のムラが発生します。さらに、人口が多いため細い回線を大勢の人が取り合っている状態であり、通信状態が安定しません。

「インドにおいては、サーバにリクエストをしてもレスポンスが返ってこないケースがあることを考慮する必要があります。それを前提として、Eightの全体的なつくりを見直す必要が出てきたんです」と解説しました。

通信速度が低速であることを前提に、設計・実装する

開発メンバーたちがまず着手したのは、アプリのバイナリファイルのサイズを削減すること。EightのAndroid版において、海外用のバイナリファイルと国内用のバイナリファイルを分けて配信することを決定しました。前者のバイナリファイルには、海外用に必要な機能だけを含める方針にしたそうです。

さらに、Android App Bundleという、Google Playで推奨されている公開形式を用いることで、配信の最適化も行いました。「⁠こうした数々の対応を行ったことで、もともとは60MBほどあったバイナリファイルのサイズが、なんと9MBほどまで削減できました」と辰濱氏は語ります。

次に取り組んだのは、画面がなかなか切り替わらない問題です。この原因は、通信が全て完了した後に画面遷移をしていることでした。電波が弱い場合に、レスポンスが返ってくるまでに時間がかかるケースがあったのです。

この問題を解決するため、彼らはWorkManagerというコンポーネントを用いました。これは、処理をキューにためておき、特定の条件に合致して処理が実行可能になったタイミングで、自動的に実行してくれるというものです。

「これにより、オンラインになったら自動的にリクエストを再送する仕組みをEightに実装しました。インドの通信環境にマッチした設計にできたのです」と辰濱氏は解説しました。

画像容量の圧縮と分析ツールによって、通信量を最適化

次に彼らは、画像の容量が大きいために通信に時間がかかるという問題を解決していきました。通信時の画像サイズを小さくする、画像の圧縮率を見直す、画像形式をJpegからWebPにするなどの施策を行い、通信量を軽量化していったのです。

さらに、分析ツールを用いて、どの箇所が通信のボトルネックになっているかを解析しました。辰濱氏は、おすすめの分析ツールをいくつか紹介しました。

「Stethoを用いると、Androidアプリのネットワークパフォーマンスを確認できます。また、CharlesはPCにプロキシを立てて通信内容をキャプチャ可能です。Firebase Performance Monitoringも、アプリのパフォーマンス特性を理解するのに役立ちます。

私たちはNewRelicMobileを使っています。NewRelicMobileは各種条件でのデータの絞りこみが簡単にでき、ダッシュボード上でさまざまな数値を可視化できるというメリットがあるからです」

Eightインド展開の過程で、開発メンバーたちは数多くの知見を得てきました。本セッションは、そんな彼らが持つ貴重なノウハウを学べるものとなりました。

Eightのインフラはどう成長してきたのか？運用担当者が考える、SRE実現のために必要なこと

続いて紹介するのは、午後のインフラセッション「SRE全盛期にEightのインフラ担当は何をしているのか」です。

スピーカは、名刺アプリEightのインフラ基盤を支えてきた、Eight事業部Development Groupエンジニア間瀬哲也氏。Eightの成長とともにインフラはどう成長してきたのか。そして、EightチームにおけるSREの概念について間瀬氏が語りました。

サービスの成長に伴い、インフラ基盤も成長

間瀬氏はまず、Eightとインフラの歴史についてふり返りました。Eightの誕生は2010年9月。当時はまだベータ版であり、社内や一部のユーザのみに公開されていました。そのころ、間瀬氏はSansanへ入社したそうです。

「入社後、まずはサービスの監視設定に着手しました。当時はSaaSの監視ツールがそれほど普及していなかったため、NagiosとCactiを用いて設定を行ったんです」

2012年に、Eightの一般公開版であるバージョン3がリリースされます。それに伴い、インフラ基盤強化のためにAWSを導入。さらには構成管理・リソース監視のためにChefやCloudForecastなどが用いられるようになりました。

2013年にはEightのバージョン4が登場。UI/UXが刷新され、現在のビジュアルに近づきます。その後の2014年に、インフラチームではアカウント管理用のLDAP導入など、セキュリティ向上のための施策を行ったそうです。

2015年に登場したバージョン6～7.0では、プレミアムサービスやフィード、プロフィールなどの機能が増えていきました。インフラチームでは、Slackの流行に伴いChatOpsを導入。「⁠Slack上で送信されたメッセージをトリガーに、各種オペレーションを行うような仕組みを構築しました」と間瀬氏は解説します。

より現代的なアーキテクチャへの刷新

2016年には、BLE（Bluetooth Low Energy）名刺交換やリアルタイムレコメンデーション、企業ページなどの機能がEightに実装されました。

ここで、Eightインフラの大幅なアーキテクチャ変更が行われます。可用性や運用容易性向上のため、データベースの構成をRDS MySQL+SpiderからAmazon Aurora+Amazon Elasticsearch Serviceに移行したのです。さらに、Infrastructure as Code実現のためにTerraformを導入していきました。

2017年にはEightのバージョン8がリリースされ、グループチャットや企業による投稿などの機能が追加されます。インフラチームにおいては、AutoScalingやBlue/Green Deploymentなどの仕組みが整備されていきました。

2018年には、インド進出に向けて海外専用アプリをリリース。さらには、端末上でOCRを利用できるクイックスキャンという機能も実装されました。インフラチームでは、MySQLの4バイト文字対応やAmazon ECSの導入、行動ログ活用基盤の構築などが行われました。

このように、Eightの成長は常にインフラの成長とともにあったのです。

DevとOpsが一体となり、SREに取り組む

ここで、間瀬氏はセッションのテーマであるSREについて触れました。SREとは、Site Reliability Engineering（またはSite Reliability Engineer）の略。ソフトウェアエンジニアリングにおいてシステムの信頼性向上に向き合うことを意味します。

開発手法であるDevOpsの概念を持ち出したうえで、「⁠Dev（アプリケーション開発者）とOps（インフラ担当者）が協力体制を築くことを、EightチームではSREだと考えています」と締めくくりました。

「インフラ担当者はシステムの可用性や拡張性、パフォーマンスなどと日々向き合います。でもアプリケーション開発者も、視点が違うだけで大切にしていることは同じ。『⁠信頼性の高いシステムをつくる』という本質は変わりません。だからこそ、SREにおいては両者が手を取り合うことが何よりも大切なんです」

間瀬氏は、Eightの黎明期からインフラ基盤と向き合ってきました。インフラ担当者はシステムを支える屋台骨であり、信頼性の重要さを誰よりも痛感するポジションです。そんな彼が語ったEightの歴史とSREの本質は、多くのエンジニアにとって参考になるものでした。

創り手はユーザの声を聞け。定量だけではわからない「ユーザはなぜ使わないのか」に向き合う方法

最後に紹介するのはSansan事業部プロダクト開発部プロダクトマネージャー尾部絵里子氏による、プロダクトセッション「創り手はユーザの声を聞け。定量だけではわからない「ユーザはなぜ使わないのか」に向き合う方法」です。

尾部氏は、クラウド名刺管理サービス「Sansan」の舵取りを行うプロダクトマネージャーで、これまでずっと「ユーザはなぜ使わないのか」に向き合いながらSansanに関わってきました。その過程で彼女が学んできたノウハウを、余すところなくお伝えします。

プロダクトアウトだからこそ持つ難しさ

尾部氏によれば、BtoBビジネスにはある種の難しさがあると言います。それは、サービスをユーザ自身の意思で導入していないため、利用のモチベーションが低い方も一定数いらっしゃること。

また、Sansanの名刺管理サービスはプロダクトアウト（※）であり、強いニーズに基づいてできたサービスではありません。それも、利用者増加を難しくする一因であると述べました。

「導入済みの企業様でも、便利さに気づいてくださるユーザは導入後すぐにSansanを使っていただけます。一方で、それに気づいていただけないユーザにはなかなか使っていただけません。後者の方々にもプロダクトの価値を届けていくことが、私たちの使命だと思っています」と主張しました。

※）: 市場のニーズよりも、企業が持つ意志を重視してプロダクトを開発し、市場に導入する考え方。

「問い」から始めよ

次に、尾部氏はセッションのメインテーマである「能動的な問い」の必要性について触れます。提示したのは、「⁠いろいろやっても問わないと足りない」「⁠職務に真面目でも問わないと足りない」「⁠センスの良い問いとは」という3つの観点です。

まず、「⁠いろいろやっても問わないと足りない」について。プロダクトマネジメントでよくいわれるのが、右脳と左脳、数字と生の声、俯瞰と熟視、主観と客観、受動的欲求を聞くことと能動的問い、のバランスをとることの重要性です。このうち「能動的に問うこと、が最も忘れられやすい」と尾部氏は指摘します。

問い合わせフォームやアンケート、ユーザ会などから寄せられる喜びや悲しみ、痛みなどの意見は「自分の想いを言語化できるユーザの声」だけに限られてしまいます。これらに応えていくことももちろん大切です。しかし、そうでないユーザの声を拾い上げること、彼ら・彼女らがどのような表情・ニュアンスで語っていたのかという「声なき声」を拾い上げることも、同じくらい重要になります。

「これらは、インタビューやユーザテストなどを通じて能動的に問わなければ、けしてわかりません」と尾部氏は提唱しました。

2つ目の「職務に真面目でも問わないと足りない」について。ユーザに近い立場である営業やCSは、生の声を直接いただく機会が多く、熟視もできます。一方で、エンジニアやデザイナーはユーザから遠い立場にいるからこそ、集約された数字を見たり、間接的な声を聞いたりと、状況を俯瞰的にとらえることができます。

ですが、担当ポジションによるバイアスがかかってしまい、どちらかに偏った視点になってしまうことが業務ではよくあります。ポジションの罠です。組織間で協力すればお互いに補完できるものの、その場合でも能動的問いが抜け落ちてしまうケースは多いです。「⁠だからこそ、プロダクトマネージャーは能動的な問いを意図的に取り入れることが必要です」と尾部氏は語りました。

最後に「センスの良い問いとは」について。ここで、尾部氏は名著『ジョブ理論』で挙げられていた例を解説します。

ミルクシェイクの売上を伸ばすうえで「どうしたら売れるか？」「⁠どうしたら使ってもらえるか？」を検討することは意味がありませんでした。そうではなく、「⁠顧客は自分のどんな“⁠ジョブ⁠”がミルクシェイクを“⁠雇用⁠”させたか？」「⁠ミルクシェイクの『本当の競合』は何なのか？」に基づいて問いを立てる必要があったのだといいます。

このエピソードは「問いの立て方」により上げられる効果が全く変わってくることを示唆しています。

適切な問いを立てることで、解決策が変わる

最後に、尾部氏はセッションの内容を総括し「アイデアを思いついたときに、まず考えてほしいチェックポイント」を挙げました。

本当の競合や課題、解決したいジョブは何か
データやユーザの声でわかるのか。能動的に問いかけなければいけないのか
欲しい情報を引き出すための適切な問いを立てられているか

「センスの良い問いを立てるには、本当に得たい情報や解決したい問題は、この問いでは得られないのではないかとまず疑うこと。適切な問いを立てて本当の競合や課題を知ることで、解決方法が変わるのです」と述べ、セッションを終了しました。

Sansanの今と未来がわかった1日

以上、前後編に分けて「Sansan Builders Box」の模様をお届けしました。「⁠名刺」というメタファを、インターネットにつなげることで企業・個人、それぞれの資産・価値に変えるサービスを開発し続けるSansanの技術力、人財、組織を余すところなく公開したカンファレンスとなりました。

また、内容に加えて、会場内には、よく見かけるパイプ椅子ではなくリラックスチェアが用意され長時間でも聴講しやすくしたり、3トラックが同一フロアで同時進行している場合には、サイレントセッション（聴講者に専用のイヤホンを用意し、それぞれのセッションのプレゼンが干渉しあわない仕掛け）を実施するなど、非常にユニークで、Sansanとしての心配りを感じるカンファレンスでした。

今、多くの企業がテクノロジーを軸に、さまざまなサービス・プロダクト開発を行っています。そして、そのテクノロジーをオープンにし、さらなる高い品質を目指す姿勢は、これからの企業にとって、必須となっていくことでしょう。

Sansanのクリエイターたちによる技術ブログ: https://buildersbox.corp-sansan.com/