疎結合で非同期なチーム開発
SORACOM “F” 開発秘話
株式会社ソラコム
シニアエンジニア
松井 基勝
2016/2/20 Developers.IO 2016
•松井 基勝(まつい もとかつ)
•来歴
〜2010/6 ゲーム会社
2010/7〜2015/5 ADSJ
2015/6〜2015/12 フリー
2016/1〜 ソラコム入社
(シニアエンジニア)
•ソラコムの”外の人”→ “元・外の人”
自己紹介
Tw: @j3tm0t0
FB:motokatsu.matsui
•本を書かせて頂きました!(共著)
(クラスメソッドの大瀧さん、
大栗さんも書いてます)
•技評さんから 2/26 発売です!
•この後のクロージングでは、
数冊のプレゼントがあるそうです
(実はまだ実物見てない)
宣伝
株式会社ソラコム
創業者:玉川 憲
元AWSエバンジェリスト
IoT向け
通信プラットフォームの
提供
《 時を遡る事1年前 》
2015年
2月2日
3月のJAWS DAYS 2015
「IoTプラットフォームの
スタートアップを
立ち上げます!」
<写真・虎ノ門の板橋さん提供>
昨年4月からステルスモードで
開発をスタート…
《 それから約半年 》
2015年9月30日 サービスリリース
IoT(Internet of Things)
インターネット クラウドモノ
New Normal
Connected
Devices
インターネット クラウドモノ
セキュリティ?
電力消費?
インターネット
接続?
端末管理?
モノ向けの
クラウド?
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 という名前に決定!
(その後厄介な事になるとも知らずに)
《 4ヶ月後… 》
2016/1/27
初のプライベートカンファレンス
一気に4つの新サービスを発表
お気づきですね?
http://togetter.com/li/925613
Air Beam と発表した後に 次は C だと言った人が
いらっしゃったので、つい乗っかってしまった
今は反省している…
すいませんBeam考えたの私です
スタートレックの転送”ビーム”のイメージ
安全に惑星表面などに移動する装置
実はこれが一番近かったですね
SORACOM SIM アダプター
《 本題 》
今日する話
ソラコムではどのようにして
開発スピードを上げているか
. . .
今日しない話
あなたの会社でどのようにして
開発スピードを上げるか
なぜか
組織が違えば
仕事の仕方も当然違う
昨日のデブサミで…
http://www.ryuzee.com/contents/blog/7078
Amazonの組織図
Jeff Bezos
AWS
Sales
Marketing
Support
SORACOM
ソラコムの組織はこんな感じ
•中心は Ken(玉川憲)
(社内では基本的に
お互いをニックネームで
呼ぶ決まり)
•エンジニアは半分くらい
•色々なプロジェクト毎に
1人または少人数で協調
•組織はフラット
→ 全員がリーダー
Ken
全員がリーダー
Customer Centric: 顧客中心主義
Done is better than perfect: 完璧よりもスピード
Proactive: 未来に対して明るく肯定的
Likability: オープンでフェアで誠実、ユーモアを忘れない、みんな
のソラコム
・・・14個のリーダーシッププリンシパル
新しいものを作るのだから定量的評価よりも、定性的評価が大事
SORACOMのリーダーシッププリンシプル
“我々の間には、チームプレーなどと
いう都合のよい言い訳は存在せん。
有るとすればスタンドプレーから
生じる、チームワークだけだ。”
─ 公安9課 荒巻大輔
(『攻殻機動隊 S.A.C. 第5話』)
→(それぞれが自立)“Stand Alone”
かつ “Complex”(複合体)な組織
理想
ソラコムを支えるツールたち
waffle swagger
Travis CI appear.in
etc…
•基本はScrum
• DailyのSync meeting
Appear.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
コンソール
Polaris
Dipper
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月の中旬、大体の仕様が固まる
•データやコンフィグの形式
•実装するパーツ
• クレデンシャルを安全に保存する
• データをデバイスから受け取る
•データをクラウドサービスに流す
•結合テストのタイミング→年明けすぐ
イベントの2週前には動いている状態にしたい
EDD(Event-Driven-Development)
決まった事
《 そして年が明けた 》
1/7 年明け初の結合テスト
…なんと一発で繋がってしまった
「試しにデータ投げてみますか?」
《 さらに翌週 》
1/13 本番環境で端末から Funnel 開通
仕様決定から約一ヶ月
ただし年末年始があったので正味2週間
CTO安川曰く
「仕様をwikiに書いただけ
なのに、いつの間にか
サービスが出来上がって
胸熱!」
•あらかじめAPIやデータフォーマットなどの仕様が
ほぼ決まっていた(細かい変更は適宜すり合わせ)
•小さなパーツをそれぞれ一人で作るので効率が良い
(しかもなるべく楽に作るようにする)
•直接会話はしてないが Sync や Slack でお互いの状
況が分かっていた(Slackの個人チャンネルで考えて
る事とか試している事をdumpしている)
考察:なぜうまくいったか
“システムを徹底的に疎結合にしたら
開発チームも疎結合になって
非同期に開発できるようになったので
とても開発スピードが上がった件”
まとめ
《 株式会社ソラコムのビジョン 》
世界中のモノと人をつなげ
共鳴する社会へ

Developers.IO 2016 | 疎結合で非同期なチーム開発