Upload
motokatsu-matsui
View
6.063
Download
5
Embed Size (px)
Citation preview
疎結合で非同期なチーム開発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 向け通信プラットフォームの提供
《 時を遡る事1年前 》
2015 年2 月 2 日
3月の 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 という名前に決定!
( その後厄介な事になるとも知らずに )
《 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
AWSSales
MarketingSupport
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 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 月の中旬、大体の仕様が固まる
•データやコンフィグの形式•実装するパーツ•クレデンシャルを安全に保存する•データをデバイスから受け取る •データをクラウドサービスに流す
•結合テストのタイミング→年明けすぐイベントの2週前には動いている状態にしたいEDD(Event-Driven-Development)
決まった事
《 そして年が明けた 》
1/7 年明け初の結合テスト
… なんと一発で繋がってしまった
「試しにデータ投げてみますか?」
《 さらに翌週 》
1/13 本番環境で端末から Funnel 開通
仕様決定から約一ヶ月
ただし年末年始があったので正味2週間
CTO安川曰く
「仕様を wiki に書いただけなのに、いつの間にかサービスが出来上がって胸熱!」
•あらかじめ API やデータフォーマットなどの仕様がほぼ決まっていた (細かい変更は適宜すり合わせ )•小さなパーツをそれぞれ一人で作るので効率が良い( しかもなるべく楽に作るようにする )•直接会話はしてないが Sync や Slack でお互いの状況が分かっていた (Slack の個人チャンネルで考えてる事とか試している事を dump している )
考察:なぜうまくいったか
“ システムを徹底的に疎結合にしたら 開発チームも疎結合になって 非同期に開発できるようになったので とても開発スピードが上がった件”
まとめ
《 株式会社ソラコムのビジョン 》
世界中のモノと人をつなげ共鳴する社会へ