Experts.jp日本に、もっとエキスパートを。Experts.jp編集長)IoT,ソラコム,マイクロサービス2017年4月14日0click0350HTML5Experts.jp名物、いろんな会社におじゃまして開発環境や開発体制とかを根掘り葉掘り聞く企画、今回はIoT通信プラットフォームとして大変な注目を集めるソラコムさんに伺ってきました。インタビューに答えてくれたのは、執行役員プリンシパルソフトウェアエンジニアの片山暁雄さん、シニアソフトウェアエンジニアの清水雄太さん、同じくシニアソフトウェアエンジニアの小熊崇さんです。今回は副編集長の仲さんがインタビュアーを務めます。本企画は、イケてるサービスを作っている会社を訪問して、どう開発しているのかなどを根掘り葉掘り聞く企画です。イケてるっていう前提がハードル高いですね(笑)。私は現職ではソフトウェアエンジニアで、課金の周りやSIMを管理する仕組みなどを開発しています。どちらかというとバックエンド寄りですね。Javaのプログラマーを10数年やっていて、以前は金融業界にいたので、ずっとBigDecimalとかを扱うプログラムを書いていました。結局今も同じようなことをやっていますけど(笑)。前職はAWSでサービスの普及に務めていたのですが、だいぶ普及も進んだのでプログラマーに戻ろうかなと思い、転職して今ここにいるというかんじです。私はソラコムに入社した当初は、Webの管理コンソールを開発していました。今はAPIのゲートウェイになる部分を作っています。ソラコムのバックエンドは、実際にはいくつものマイクロサービスに分かれているのですが、それを外から見た時に単一のAPI群に見えるようなゲートウェイを作っています。あとは、コマンドラインインターフェースやSDKなど、開発者の皆様に使っていただく部分を開発しています。私はフロントエンドを中心に担当しています。先ほどの小熊が以前開発していたWebの管理コンソールは、現在私が開発を引き継いでいます。Railsを使ってフロントエンド・バックエンドの開発を行っていましたので、ここでもそういう役割が多いですね。ほかにも、普段の開発作業で行うスタンドアップ・ミーティングやSlackなど、開発体制の整備も行っています。このオフィスを作るにあたってのディレクションなど、開発から少し外れた部分も担当しています。はい、私たちのサービスを一言で言うならIoT向けの通信プラットフォームです。IoTのサービスを実際に展開しようとした際に発生する、技術的な課題やビジネス上の課題解決を支援するためのプラットフォームです。具体的には、3GやLTEといったモバイル通信を使った通信サービス、そしてそれらをうまくクラウドにつなぐためのサービスです。Air」は、Amazon.co.jpで1枚から通販で購入可能です。世界の120の国と地域で通信を行えるようになります。SIMカードを提供するとだけでは従来の通信事業者さんと変わらないのですが、私たちの特徴はIoTに特化しているというところです。私たちの特徴の一つとしては、通信事業者であれば通常必要とされるようなパケット交換機や顧客管理といった通信用のハードウェアを一切持っていません。専用のハードウェアを用意する代わりに、それらを実現するソフトウェアコンポーネントを用意して、AWS上ですべてを実現しています。通信に必要な基地局などは、MVNOとして通信キャリアから借りて、クラウド上ですべてを処理できる仕組みを持っています。IoTに特化した、クラウドネイティブなMVNOというかんじですね。したサービスをAPIの形で公開している、というのも大きな特徴と言えるでしょう。IoTをやろうと考えるお客様は、数万から数十万の回線を扱うことも、特別なことではありません。ビーコンに通信機器を入れて全国にばらまく、といったことをする場合は相当な回線数になるので、人手では管理しにくい。そこをAPIで管理できるようにしているので、通信量のモニタリングや、異常があったら通信を止めたりということを自動化していただくことができる。したあたりが、私たちが「IoT向け」と謳っている強みになります。Thingsといえども「インターネットを使わない」という環境を作ることもできます。自社システムがAWSの中だけにあったりする場合に、SIMカードを持っている人しか閉域に入れないような仕組みも簡単に作ることができる。いった、セキュリティが重視されるIoTのシステムなんかも作ることが可能です。最近のアップデートとしては、「LoRaWAN」という通信量は限られているのですが、非常に省電力で広域まで届く通信プロトコルにも対応します。なってくると、さらに多くのお客様に使っていただけるんじゃないかと思っています。私のようなWebエンジニアが、ソラコムさんのサービスを使って、何かしらIoTを試してみたい...ということもできるんでしょうか。Piのような汎用的なデバイスもありますし、簡単に試せると思います。SIMのソケットを持つIoTデバイスを用意して、ほんとに簡単なロジックを書くだけで、クラウドまでデータが届きます。POSTするだけとかでもいい。JSON形式のデータでクラウドまで届きますので、後はご自由にどうぞというかんじです。ソラコムさんはWebのフロントエンドから通信キャリア的なバックエンドまで幅広く開発をされていますね。チームに分かれて開発...というっかんじではないかもしれません。私たちは2週間のイテレーションをベースとして開発しており、2週間に1回インテグレートしてリリース、というのを繰り返しています。イテレーションを開始する際に次に実現する機能のプランニングや担当を割り振って、あとは個々人がそれぞれ進めていきます。担当の割り振りについては、決まったものがあるわけではありません。エンジニアの平均年齢は30代中盤、ぼくらは各分野で経験を積んできたメンバーが集った、言ってみれば「おっさんベンチャー」なので(笑)、「これしかできません」っていう人はあんまりいない。足りないところがあったら「代わりにやりますね」という雰囲気です。皆さん、一番得意なスキルはあれども、その他のこともこなせるというかんじなんですね。開発者としては実際に10名ちょっとなので、基本的に1チームで開発を進めている雰囲気です。弊社は、ベースが開発者っぽい人が多いんです。ビジネス開発をしているメンバーも、実はデバイスにものすごく詳しかったりして、コマンドラインで作業したり、ハードウェアの調査をしたりというのを普通にやったりするので...。いうところからも開発リソースを調達したりしています(笑)。グローバル展開されているので、海外にも開発者がいるわけですよね。Hangoutとかですね。ビデオ会議システムについては、いろいろ紆余曲折がある(笑)。Callsはまだリリースされたばかりで、機能も不足しています。スクリーン共有ができなかったり。Businessとか、いろいろ試しましたね。ここについては決定版がないという状態です。リモートワークが可能な体制になっているわけですね。はい、今日人が少ないのは雨だからだと思います(笑)。生産性を高く保てる環境で仕事をしているはずです。オフィスにいないと困る職種の人もいるので、そういう人は基本的に出社していますね。実際の開発をどのように進めているかも教えてください。基本的には、先ほども申し上げたように、ソラコムの内側はマイクロサービスとして分かれているので、それぞれのサービスを開発者が選んだ言語で開発しています。「使いたいライブラリがその言語にあるから」という理由で言語を採用することもありますね。ぼくらはスタートアップなので、一番早く実装できる方法を選択したいというのがその理由です。今のところ、使っている言語としてはGo、Java、Node.js、C...。Lambdaの開発は、実はPythonが一番やりやすかったりもするので、Pythonを使ったりということもしていますね。CTOに相談したり、といったことは多少ありますけど、基本的には開発者の自由ですね。マイクロサービスに分けているからこそ、様々な言語を混在させることも可能なわけですね。興味本位で伺いますが、そこまで自由だと今後エンジニアが増えていったときとかに、「既存のコンポーネントを自分の好きな言語で書き直したい」なんて要望も出てきたりしないのかな...なんて。書き直す正当な理由があるなら、それも許されるとは思います。APIの定義さえ変わらなければ、あるコンポーネントの中身がごっそり置き換わっても他の部分には影響ないですし。あとマイクロサービスのいいところは、オーナーシップがわかりやすいことですね。サービスごとに開発した人が大体分かれているので、担当者が自然と定まってくる。今後開発者が増えていって、100人とかになった時に、今と同じことができるかはわからないです。なったら、ある程度統一しようという話も出てくるのかもしれませんが、とりあえず現在の段階では、マイクロサービスを開発者それぞれが開発するという体制でスケールアウトを目指したほうが素早くサービスを拡張できると考えています。マイクロサービスによる開発には、開発そのものをスケールアウトできるというメリットもあるわけですね。コードそのものよりも、仕組みやアーキテクチャ、APIのほうを重点的にレビューするようにしていますね。APIの挙動がよく分からなかったり、バグっぽかったりしても、相手に聞いたりする前にまずコンポーネントのコード読んじゃって、「あ、なるほど、こうやってこのAPI呼び出すのか」とかって自己解決しちゃったりすることもあります。その際に、そのコードが難解すぎて読めないとか、何をするためのコードなのか理解できないとかいったようなことはこれまで経験していません。事前にアーキテクチャなどをレビューしているからということもありますし、各コンポーネントを担当しているエンジニアのスキルが一定以上の水準だからだと思います。私の担当しているユーザーコンソールなどは複数人で開発しているので、少しレビューを綿密にやっていたりはしますね。ソラコムさんは「理想的なリーダーシップ」について書かれた15の項目「リーダーシップ・ステートメント」をメンバー内で共有し、定期的に議論、各自が実践することで、自由なワークスタイル、自由な開発体制、そして各自が責任を持って仕事をすることを同時に実現しているのだそう。サービスの運用などについても聞いてみたいです。そこは、弊社だとOpsDevと呼んでいるんです。Opsをメインでやっている人間が強いこだわりを持っていまして(笑)。開発したものを運用するんじゃなくて、運用のためにこそ開発がある、と。運用をメインで行うチームがあるというわけではないんですか。そもそも開発メンバー自体が、日々の運用やサポートにも直接参加しています。いわゆるDevOpsです。弊社では、運用の自動化にメインで取り組むエンジニアが一人いて、彼を中心に様々な自動化や監視を行っています。メインはZabbixによる監視と、Ansibleによる自動化をしています。何か問題があったら、次はどうそれを自動化するかとか、次に問題をどうやって起こさなくするかとかを決めて、あとはそれを担当のOpsDevエンジニア中心にやる、という運用になっていますね。御社だと、運用そのものがビジネスかもしれませんよね。通信コア部分を安定的に、そしてスケーラブルにAWS上で動かすというのが我々のビジネスの根源と言えば根源なので、そこは一番力を入れています。それ以外の、例えば私が書いているバックエンドの部分などは、AWSのBeanstalkなどにを使えばそれなりにスケールアウトするし、それに頼って作っているという部分はありますね。DBをメインで使っています。メインとなる通信サービスで、RDB使ってるところはほとんどないんじゃないかな。DBだと、アプリケーション側で頑張らなきゃいけない部分が出てくるので、そこは頑張るといった感じですね(笑)。