HTML5Experts.jp名物、いろんな会社におじゃまして開発環境や開発体制とかを根掘り葉掘り聞く企画、今回はIoT通信プラットフォームとして大変な注目を集めるソラコムさんに伺ってきました。

インタビューに答えてくれたのは、執行役員プリンシパルソフトウェアエンジニアの片山暁雄さん、シニアソフトウェアエンジニアの清水雄太さん、同じくシニアソフトウェアエンジニアの小熊崇さんです。
今回は副編集長の仲さんがインタビュアーを務めます。

まずは自己紹介から！

仲 本企画は、イケてるサービスを作っている会社を訪問して、どう開発しているのかなどを根掘り葉掘り聞く企画です。まずは、自己紹介からお願いできますか？

片山 イケてるっていう前提がハードル高いですね(笑) 。

私は現職ではソフトウェアエンジニアで、課金の周りやSIMを管理する仕組みなどを開発しています。どちらかというとバックエンド寄りですね。もともとはJavaのプログラマーを10数年やっていて、以前は金融業界にいたので、ずっとBigDecimalとかを扱うプログラムを書いていました。結局今も同じようなことをやっていますけど(笑)。

前職はAWSでサービスの普及に務めていたのですが、だいぶ普及も進んだのでプログラマーに戻ろうかなと思い、転職して今ここにいるというかんじです。

▲株式会社ソラコム 執行役員 プリンシパルソフトウェアエンジニア 片山暁雄さん

小熊 私はソラコムに入社した当初は、Webの管理コンソールを開発していました。

今はAPIのゲートウェイになる部分を作っています。ソラコムのバックエンドは、実際にはいくつものマイクロサービスに分かれているのですが、それを外から見た時に単一のAPI群に見えるようなゲートウェイを作っています。

あとは、コマンドラインインターフェースやSDKなど、開発者の皆様に使っていただく部分を開発しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 小熊崇さん

清水 私はフロントエンドを中心に担当しています。例えば、先ほどの小熊が以前開発していたWebの管理コンソールは、現在私が開発を引き継いでいます。

前職でRuby on Railsを使ってフロントエンド・バックエンドの開発を行っていましたので、ここでもそういう役割が多いですね。

ほかにも、普段の開発作業で行うスタンドアップ・ミーティングやSlackなど、開発体制の整備も行っています。このオフィスを作るにあたってのディレクションなど、開発から少し外れた部分も担当しています。

▲株式会社ソラコム シニアソフトウェアエンジニア 清水雄太さん

ソラコムって…なに？

仲 では、ソラコムさんのサービスの概要を教えていただけますか？

片山 はい、私たちのサービスを一言で言うならIoT向けの通信プラットフォームです。IoTのサービスを実際に展開しようとした際に発生する、技術的な課題やビジネス上の課題解決を支援するためのプラットフォームです。

具体的には、3GやLTEといったモバイル通信を使った通信サービス、そしてそれらをうまくクラウドにつなぐためのサービスです。 SIMカード「SORACOM Air」は、Amazon.co.jpで1枚から通販で購入可能です。また、世界の120の国と地域で通信を行えるようになります。

SIMカードを提供するとだけでは従来の通信事業者さんと変わらないのですが、私たちの特徴はIoTに特化しているというところです。

まず私たちの特徴の一つとしては、通信事業者であれば通常必要とされるようなパケット交換機や顧客管理といった通信用のハードウェアを一切持っていません。専用のハードウェアを用意する代わりに、それらを実現するソフトウェアコンポーネントを用意して、AWS上ですべてを実現しています。

通信に必要な基地局などは、MVNOとして通信キャリアから借りて、クラウド上ですべてを処理できる仕組みを持っています。

仲 なるほど、IoTに特化した、クラウドネイティブなMVNOというかんじですね。

片山 こうしたサービスをAPIの形で公開している、というのも大きな特徴と言えるでしょう。

IoTをやろうと考えるお客様は、数万から数十万の回線を扱うことも、特別なことではありません。例えばビーコンに通信機器を入れて全国にばらまく、といったことをする場合は相当な回線数になるので、人手では管理しにくい。

そこをAPIで管理できるようにしているので、通信量のモニタリングや、異常があったら通信を止めたりということを自動化していただくことができる。こうしたあたりが、私たちが「IoT向け」と謳っている強みになります。

また、3G網からAWSに専用線でつなぐこともできるので、Internet of Thingsといえども「インターネットを使わない」という環境を作ることもできます。

例えば自社システムがAWSの中だけにあったりする場合に、SIMカードを持っている人しか閉域に入れないような仕組みも簡単に作ることができる。そういった、セキュリティが重視されるIoTのシステムなんかも作ることが可能です。

また最近のアップデートとしては、「LoRaWAN」という通信量は限られているのですが、非常に省電力で広域まで届く通信プロトコルにも対応します。 そうなってくると、さらに多くのお客様に使っていただけるんじゃないかと思っています。

白石 私のようなWebエンジニアが、ソラコムさんのサービスを使って、何かしらIoTを試してみたい…ということもできるんでしょうか。

片山 はい、最近だとRasberry Piのような汎用的なデバイスもありますし、簡単に試せると思います。SIMのソケットを持つIoTデバイスを用意して、ほんとに簡単なロジックを書くだけで、クラウドまでデータが届きます。

例えばcurlコマンドでHTTP POSTするだけとかでもいい。JSON形式のデータでクラウドまで届きますので、後はご自由にどうぞというかんじです。

ソラコムの開発はどのような体制で行われている？

仲 ソラコムさんはWebのフロントエンドから通信キャリア的なバックエンドまで幅広く開発をされていますね。開発チームの体制などについて伺ってもよろしいでしょうか？

片山 あまり、チームに分かれて開発…というっかんじではないかもしれません。私たちは2週間のイテレーションをベースとして開発しており、2週間に1回インテグレートしてリリース、というのを繰り返しています。

なので、イテレーションを開始する際に次に実現する機能のプランニングや担当を割り振って、あとは個々人がそれぞれ進めていきます。

仲 なるほど。

片山 ただ、担当の割り振りについては、決まったものがあるわけではありません。エンジニアの平均年齢は30代中盤、ぼくらは各分野で経験を積んできたメンバーが集った、言ってみれば「おっさんベンチャー」なので(笑)、「これしかできません」っていう人はあんまりいない。

足りないところがあったら「代わりにやりますね」という雰囲気です。

仲 皆さん、一番得意なスキルはあれども、その他のこともこなせるというかんじなんですね。

清水 開発者としては実際に10名ちょっとなので、基本的に1チームで開発を進めている雰囲気です。

片山 弊社は、ベースが開発者っぽい人が多いんです。例えば、ビジネス開発をしているメンバーも、実はデバイスにものすごく詳しかったりして、コマンドラインで作業したり、ハードウェアの調査をしたりというのを普通にやったりするので…。だから、そういうところからも開発リソースを調達したりしています(笑)。

雨だから人が来ていない(笑)

仲 グローバル展開されているので、海外にも開発者がいるわけですよね。海外メンバーとのコミュニケーションはどのように取っていらっしゃいますか？

片山 基本的にはSlackとかGoogle Hangoutとかですね。ビデオ会議システムについては、いろいろ紆余曲折がある(笑)。

清水 例えばSlack Callsはまだリリースされたばかりで、機能も不足しています。スクリーン共有ができなかったり。なのでappear.inとかGoogle HangoutとかSkype for Businessとか、いろいろ試しましたね。まだここについては決定版がないという状態です。

白石 リモートワークが可能な体制になっているわけですね。そういえばこのオフィスも、他にほとんど人がいない状態ですが、皆さん別の場所で仕事してらっしゃるんでしょうか？

片山 はい、今日人が少ないのは雨だからだと思います(笑)。生産性を高く保てる環境で仕事をしているはずです。

清水 もちろんオフィスにいないと困る職種の人もいるので、そういう人は基本的に出社していますね。

マイクロサービス・アーキテクチャが実現する「開発者の自由」

仲 では実際の開発をどのように進めているかも教えてください。具体的にはどのようなプログラミング言語を使って開発していますか？

小熊 基本的には、先ほども申し上げたように、ソラコムの内側はマイクロサービスとして分かれているので、それぞれのサービスを開発者が選んだ言語で開発しています。

片山 例えば「使いたいライブラリがその言語にあるから」という理由で言語を採用することもありますね。ぼくらはスタートアップなので、一番早く実装できる方法を選択したいというのがその理由です。

今のところ、使っている言語としてはGo、Java、Node.js、C…。あと、AWS Lambdaの開発は、実はPythonが一番やりやすかったりもするので、Pythonを使ったりということもしていますね。

仲 その技術を採用する前に、誰かに相談したりはしないんですか？

片山 CTOに相談したり、といったことは多少ありますけど、基本的には開発者の自由ですね。

仲 なるほど、マイクロサービスに分けているからこそ、様々な言語を混在させることも可能なわけですね。興味本位で伺いますが、そこまで自由だと今後エンジニアが増えていったときとかに、「既存のコンポーネントを自分の好きな言語で書き直したい」なんて要望も出てきたりしないのかな…なんて。

小熊 書き直す正当な理由があるなら、それも許されるとは思います。REST APIの定義さえ変わらなければ、あるコンポーネントの中身がごっそり置き換わっても他の部分には影響ないですし。

片山 あとマイクロサービスのいいところは、オーナーシップがわかりやすいことですね。サービスごとに開発した人が大体分かれているので、担当者が自然と定まってくる。もし今後開発者が増えていって、100人とかになった時に、今と同じことができるかはわからないです。

そうなったら、ある程度統一しようという話も出てくるのかもしれませんが、とりあえず現在の段階では、マイクロサービスを開発者それぞれが開発するという体制でスケールアウトを目指したほうが素早くサービスを拡張できると考えています。

仲 マイクロサービスによる開発には、開発そのものをスケールアウトできるというメリットもあるわけですね。

白石 しかしそれだけ多様で自由に開発しているとなると、コードレビューなどが難しくなったりはしないのでしょうか？

片山 コードそのものよりも、仕組みやアーキテクチャ、APIのほうを重点的にレビューするようにしていますね。

小熊 開発をしていると、呼び出す相手のコンポーネントについて APIの挙動がよく分からなかったり、バグっぽかったりしても、相手に聞いたりする前にまずコンポーネントのコード読んじゃって、「あ、なるほど、こうやってこのAPI呼び出すのか」とかって自己解決しちゃったりすることもあります。

その際に、そのコードが難解すぎて読めないとか、何をするためのコードなのか理解できないとかいったようなことはこれまで経験していません。事前にアーキテクチャなどをレビューしているからということもありますし、各コンポーネントを担当しているエンジニアのスキルが一定以上の水準だからだと思います。

清水 私の担当しているユーザーコンソールなどは複数人で開発しているので、少しレビューを綿密にやっていたりはしますね。

（筆者補足: ソラコムさんは「理想的なリーダーシップ」について書かれた15の項目「リーダーシップ・ステートメント」をメンバー内で共有し、定期的に議論、各自が実践することで、自由なワークスタイル、自由な開発体制、そして各自が責任を持って仕事をすることを同時に実現しているのだそう。見習いたい！）

DevOpsではなくOpsDev

仲 サービスの運用などについても聞いてみたいです。DevOpsのあたりとかは、どのように運用を自動化しているのでしょうか？

小熊 そこは、弊社だとOpsDevと呼んでいるんです。Opsをメインでやっている人間が強いこだわりを持っていまして(笑)。開発したものを運用するんじゃなくて、運用のためにこそ開発がある、と。

仲 運用をメインで行うチームがあるというわけではないんですか。

小熊 まず、そもそも開発メンバー自体が、日々の運用やサポートにも直接参加しています。いわゆるDevOpsです。さらに弊社では、運用の自動化にメインで取り組むエンジニアが一人いて、彼を中心に様々な自動化や監視を行っています。

片山 メインはZabbixによる監視と、Ansibleによる自動化をしています。何か問題があったら、次はどうそれを自動化するかとか、次に問題をどうやって起こさなくするかとかを決めて、あとはそれを担当のOpsDevエンジニア中心にやる、という運用になっていますね。

白石 御社だと、運用そのものがビジネスかもしれませんよね。

片山 はい、そうなんです。通信コア部分を安定的に、そしてスケーラブルにAWS上で動かすというのが我々のビジネスの根源と言えば根源なので、そこは一番力を入れています。

なのでそれ以外の、例えば私が書いているバックエンドの部分などは、AWSのBeanstalkなどにを使えばそれなりにスケールアウトするし、それに頼って作っているという部分はありますね。

仲 先ほど「スケーラブル」という単語が出てきましたが、スケーラビリティを担保するためにどのようなアーキテクチャになっていますか？

片山 一言で言うのは難しいですが、例えば一番ネックになるデータベース部分はDynamo DBをメインで使っています。メインとなる通信サービスで、RDB使ってるところはほとんどないんじゃないかな。

ただDynamo DBだと、アプリケーション側で頑張らなきゃいけない部分が出てくるので、そこは頑張るといった感じですね(笑)。

白石 マイクロサービスだし、DBも分けてらっしゃるんですよね？

片山 はい、そうです。ただ、使っているDBはみなDynamo DBですね。

白石 決済の部分とかは、トランザクション処理が必要だと思いますが、そこはどうしてるんでしょう？

片山 そこもDynamo DBで頑張っています。Dynamo DBはトランザクションがあるにはあるのですが、2レコードをアトミックに更新できないので、極力1レコードに寄せるようにしたりとか。あと公式のトランザクションライブラリもありますし。

仲 ほかには、ログの管理などはどうしてらっしゃいますか？

片山 Logglyというサービスを使っていますね。ライブラリを使ってログを送ると、よしなにインデックスしてくれるようなサービスです。

仲 Elastic Searchを自前で運用したりはしていないのですね。

片山 はい。弊社のサービスは、ログの分析などがビジネスの源泉になるものではないので。ビジネスの源泉になる部分は自社開発にこだわっていますが、それ以外の部分は積極的に外部のサービスを使用するようにしています。

ソラコムの課題・改善点

仲 では、ソラコムの開発において、課題だと感じていることや今後改善していきたい点などはありますか？

片山 個人的に継続的に追求していきたい課題としては、いかにチームを小さく保っていられるかというところですね。

人が増えるといろんなロスが発生してくるじゃないですか。機動性を確保しておくために、人をなるべく増やさない。そのために必要なのは生産性を上げることなのか、一人が何役もできるようにすることなのか、ということですが、そこを追求していきたいと思っています。

清水 私も、今の片山の話ともリンクしていると思いますが、作るものをいかに小さく保っておけるかが大事だと考えています。大きなものを作ろうと思うと、沢山の人が必要になるし、メンテナンスも必要になってくる。

なので、同じ価値を少ない機能やコンポーネントで実現するということにはこだわっていきたいですね。今はまだぼくらは、機能やツールを追加していくフェーズではありますが、ある程度、一通り揃ったタイミングで、いかにそれらを減らしていけるか、シンプルにしていけるかは考えていきたいと思います。

小熊 ぼくは…課題とか不満とか、あんまりないですねえ(笑)。すごく自由だし、生産性も高いし、今のところ申し分ありません。

あらゆるものが「目」を獲得し進化する

白石 では最後になりますが、まだIoTに取り組んだことのないエンジニアに対して、IoTにどう取り組むべきかを教えてください。

清水 私はもともとWebエンジニアなんですけれども、IoTをやると、様々な業種の人々と接することになるのが楽しかったりします。

例えばWeb系の勉強会だったら、Webのトピックがやっぱり一番熱いので、Webの話が中心になる。それはそれで楽しいのですけど、ソラコムのユーザーグループだったり、メイカーズ・ムーブメントだったりに顔を出していくと、自分と同じくらいのスキルセットを持った人がぜんぜん違うことをやっていたりするわけです。

サーバーサイドもできるんだけど、Arduinoで何かやっていたりもする。そういう人たちに接すると、IoTに取り組むモチベーションも上がったりするんじゃないかなと思います。

小熊 私はもともと組み込み系の出身なんです。組み込みの業界のエンジニアは、「Webやクラウドについてはまだわからない」という人も多いですが、エンジニアリングの基礎がしっかりしているので、吸収も速いと感じています。

なので、組み込みの方々がIoTに取り組むのはすごく向いているので、ぜひトライしてみるといいと思います。

片山 個人的には、IoTでワクワクすることの一つは、あらゆるものに「手足」や「目」ができることだと思っています。どんなものにもセンサーが付き、デジタルデータ化できる可能性がある。

例えばぼくは、部屋のあらゆるものの最終アクセス日時が分かったら、片付けとかにすごく便利じゃないかと考えているんですよね。

白石 確かに(笑)。

片山 センサーだけじゃなくて、Amazon Goみたいに画像解析によるアプローチもあるし、そういうアイデアが実現可能な時代はもう来ている。これが進んで、身の回りのものがデジタルデータになることで、世界はもっと面白く、便利になるんじゃないかと思っています。

生物はカンブリア紀に目を獲得したことで、大幅に進化が進んだと言われているのですよね。それと同じことが、今まさに起ころうとしているんじゃないかなと。現在、そういう進化の途上なのだと考えると、IoTの波に乗っかってみるのも悪くはないと思えるんじゃないでしょうか。