疎結合で非同期なチーム開発SORACOM “F” 開発秘話

株式会社ソラコム

シニアエンジニア

松井 基勝2016/2/20 Developers.IO 2016

•松井 基勝 ( まつい もとかつ )•来歴

〜 2010/6 ゲーム会社2010/7 〜 2015/5 ADSJ2015/6 〜 2015/12 フリー2016/1 〜 ソラコム入社 ( シニアエンジニア )

•ソラコムの”外の人”→ “元・外の人”

自己紹介

Tw: @j3tm0t0

FB:motokatsu.matsui

•本を書かせて頂きました！ ( 共著 )( クラスメソッドの大瀧さん、 大栗さんも書いてます )•技評さんから 2/26 発売です！•この後のクロージングでは、数冊のプレゼントがあるそうです( 実はまだ実物見てない )

宣伝

株式会社ソラコム

創業者：玉川 憲元 AWS エバンジェリスト

IoT 向け通信プラットフォームの提供

《 時を遡る事１年前 》

2015 年2 月 2 日

３月の JAWS DAYS 2015

「 IoT プラットフォームの　スタートアップを　立ち上げます！」＜写真・虎ノ門の板橋さん提供＞

昨年 4 月からステルスモードで開発をスタート…

《 それから約半年 》

2015 年 9 月 30 日 サービスリリース

IoT （ Internet of Things ）

インターネット クラウドモノ

New NormalConnectedDevices

インターネット クラウドモノ

セキュリティ ?

電力消費 ?

インターネット接続？

端末管理 ?

モノ向けのクラウド？

IoT の課題

IoT の通信の課題

インターネットモノ《 IoT の通信の障壁 》

・有線 LAN は場所の制約・無線 LAN はセキュリティ難

インターネット接続？

→ モバイル通信が良い　しかし、　ヒト向けのプラン　しかない　　

IT ベンチャーがモノ向け通信を

どうやって提供するのか？

通信キャリアと MVNO

インターネットモノ 基地局 データセンター

ISPパケット交換帯域制御顧客管理課金・・・

通信キャリア

専用

線接

続

インターネットモノ 基地局 データセンター

ISPパケット交換帯域制御顧客管理課金・・・

NTT ドコモの基地局とAWS クラウドで

バーチャルキャリアを実現

モバイルとクラウドが融合した

IoT 向け通信プラットフォーム

1 日 10 円〜、モノ向け通信サービスSORACOM Air

インターネット

SORACOM Air – モバイル通信サービス

NTT ドコモの交換局

お客様

① 　 SIM を購入して　　　モノに挿す

Web コンソール

②Web から　　コントロール

Web コンソールで回線管理

API Reference

IoT 通信の標準共通基盤としての特徴を備える•1 日 10 円〜の従量課金•スモールスタートでき、必要に応じてスケール• IoT デバイスを監視 / 管理でき、運用を楽に•プログラマブルな API 提供•誰でも自由に値付けをしてビジネスができる→失敗のコストを下げ、イノベーションを支援

オープンでフェアなプラットフォームとしての SORACOM

アワードを多数受賞！

ちなみに Beam はプライベート β 時に“IoT Exchange” という名前だった

《 ある日の会食にて… 》

「玉川さん、 IoT Exchange って名前 分かりづらいよ…」

サーバーワークス 大石代表

10 人くらいでウンウン唸った結果、Beam という名前に決定！

( その後厄介な事になるとも知らずに )

《 ４ヶ月後… 》

2016/1/27初のプライベートカンファレン

ス

一気に４つの新サービスを発表

お気づきですね？

http://togetter.com/li/925613

Air Beam と発表した後に 次は C だと言った人がいらっしゃったので、つい乗っかってしまった今は反省している…

すいません Beam 考えたの私です

スタートレックの転送”ビーム”のイメージ

安全に惑星表面などに移動する装置

実はこれが一番近かったですね

SORACOM SIM アダプター

《 本題 》

今日する話

ソラコムではどのようにして開発スピードを上げているか

　 . . .今日しない話

あなたの会社でどのようにして開発スピードを上げるか

なぜか

組織が違えば仕事の仕方も当然違う

昨日のデブサミで…

http://www.ryuzee.com/contents/blog/7078

Amazon の組織図

Jeff Bezos

AWSSales

MarketingSupport

SORACOM

ソラコムの組織はこんな感じ

•中心は Ken( 玉川憲 )( 社内では基本的に お互いをニックネームで 呼ぶ決まり )•エンジニアは半分くらい•色々なプロジェクト毎に１人または少人数で協調•組織はフラット→ 全員がリーダー

Ken

全員がリーダー

Customer Centric: 顧客中心主義

Done is better than perfect: 完璧よりもスピード

Proactive: 未来に対して明るく肯定的

Likability: オープンでフェアで誠実、ユーモアを忘れない、みんなのソラコム

・・・ 14個のリーダーシッププリンシパル

新しいものを作るのだから定量的評価よりも、定性的評価が大事

SORACOM のリーダーシッププリンシプル

“我々の間には、チームプレーなどという都合のよい言い訳は存在せん。有るとすればスタンドプレーから生じる、チームワークだけだ。”　　　　　─ 公安９課 荒巻大輔 (『攻殻機動隊 S.A.C. 第 5 話』 )

→( それぞれが自立 )“Stand Alone”　かつ “ Complex”(複合体 ) な組織

理想

ソラコムを支えるツールたち

waffle swagger

Travis CI appear.in

etc…

•基本は Scrum•Daily の Sync meetingAppear.in または Slack で報告•2 week 単位での スプリントプランニング〜テスト〜リリースタスク管理は GitHub Issues + Waffle.io

•フルフレックス＆リモートワーク可能•自宅やカフェでも作業できる•部分的に仕事を切り出してお願いする事も

ソラコムのワークスタイル

Sync meeting: appear.in ↓ オフィス ←リモート組（自宅・カフェ等

)

タスク管理： GitHub Issues + Waffle.io

インテグレートして大きな力を発揮

↑Beam MQTT 開通時

↓ インテグレーション成功時はお寿司

•働く場所や時間はかなり柔軟•ミーティングが少なめ•メールの量がとても少ない ( 外部とのやりとりのみ )•Slack の流量はそれなりただし未読管理や返信もメールに比べれば楽Webhook や Bot を活用して ChatOps

ソラコムのワークスタイルのいいところ

《 開発方針 》

•SORACOM という大きなサービスは構成要素となる小さなサービス（マイクロサービス）とそれを実装するコンポーネントが疎結合されて構築される•各マイクロサービスやコンポーネントごとに Primary Owner がいて、 Ownership を持って開発・メンテナンス・運用に携わる•各コンポーネントはそれぞれ API を通じて連携するため、API については他のコンポーネント Owner としっかり連携、 API の裏側については開発スピードを重視してそれぞれに適した実装方法を導入

基本原則

パケット転送帯域制御アクセス制御Beam 処理

回線・セッション管理認証課金イベント通知APIコンソール

PolarisDipper

Hubble監視・デプロイ

SORACOM Architecture

Polaris と Dipperマイクロサービス化された機能コンポーネント群

セッション管理 認証 課金

API Gateway

User Data API

API

User Data

パケット転送帯域制御… Amazon DynamoDB

•We develop!•We operate!!•We support!!!→ 運用が楽なシステムを開発

開発者が運用・サポートもやる体制

•まずは動かす事を考え、後から機能・品質を改善“ Done is better than perfect”•マネージドサービスをとことん活用するDynamoDB, Lambda, Beanstalk etc…•ただし要件に合わない場合には自作も辞さない→「 SORACOM API こぼれ話」https://blog.soracom.jp/blog/2015/10/09/api-gateway/

どうやって開発スピードを上げるか

《 “ F” ができるまで 》

✖️ ファンネル○ファネル

意味 : 漏斗 (ろうと )→

Funnel?

SORACOM Funnel

SORACOM Funnel – クラウドリソースアダプタ

クラウドサービスに特化したデータ転送サービス( デバイスに認証情報や SDK を持つ必要がない )「 Amazon Kinesis 」「 Amazon Kinesis Firehose 」と「 Microsoft Azure Event Hubs 」

《 “発端” 》

昨年 10 月の slack から

実はサービスロンチの約 1 週間後C 〜 F のサービスが確定してた

《 月日が流れ 》

12 月の中旬、大体の仕様が固まる

•データやコンフィグの形式•実装するパーツ•クレデンシャルを安全に保存する•データをデバイスから受け取る •データをクラウドサービスに流す

•結合テストのタイミング→年明けすぐイベントの２週前には動いている状態にしたいEDD(Event-Driven-Development)

決まった事

《 そして年が明けた 》

1/7 年明け初の結合テスト

… なんと一発で繋がってしまった

「試しにデータ投げてみますか？」

《 さらに翌週 》

1/13 本番環境で端末から Funnel 開通

仕様決定から約一ヶ月

ただし年末年始があったので正味２週間

CTO安川曰く

「仕様を wiki に書いただけなのに、いつの間にかサービスが出来上がって胸熱！」

•あらかじめ API やデータフォーマットなどの仕様がほぼ決まっていた (細かい変更は適宜すり合わせ )•小さなパーツをそれぞれ一人で作るので効率が良い( しかもなるべく楽に作るようにする )•直接会話はしてないが Sync や Slack でお互いの状況が分かっていた (Slack の個人チャンネルで考えてる事とか試している事を dump している )

考察：なぜうまくいったか

“ システムを徹底的に疎結合にしたら 開発チームも疎結合になって 非同期に開発できるようになったので とても開発スピードが上がった件”

まとめ

《 株式会社ソラコムのビジョン 》

世界中のモノと人をつなげ共鳴する社会へ