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

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

1. 1. 疎結合で非同期なチーム開発 SORACOM “F” 開発秘話 株式会社ソラコム シニアエンジニア 松井 基勝 2016/2/20 Developers.IO 2016
2. 2. •松井 基勝(まつい もとかつ) •来歴 〜2010/6 ゲーム会社 2010/7〜2015/5 ADSJ 2015/6〜2015/12 フリー 2016/1〜 ソラコム入社 (シニアエンジニア) •ソラコムの”外の人”→ “元・外の人” 自己紹介 Tw: @j3tm0t0 FB:motokatsu.matsui
3. 3. •本を書かせて頂きました！(共著) (クラスメソッドの大瀧さん、 大栗さんも書いてます) •技評さんから 2/26 発売です！ •この後のクロージングでは、 数冊のプレゼントがあるそうです (実はまだ実物見てない) 宣伝
4. 4. 株式会社ソラコム 創業者：玉川 憲 元AWSエバンジェリスト IoT向け 通信プラットフォームの 提供
5. 5. 《 時を遡る事１年前 》
6. 6. 2015年 2月2日
7. 7. ３月のJAWS DAYS 2015 「IoTプラットフォームの スタートアップを 立ち上げます！」 ＜写真・虎ノ門の板橋さん提供＞
8. 8. 昨年4月からステルスモードで 開発をスタート…
9. 9. 《 それから約半年 》
10. 10. 2015年9月30日 サービスリリース
11. 11. IoT（Internet of Things） インターネット クラウドモノ New Normal Connected Devices
12. 12. インターネット クラウドモノ セキュリティ? 電力消費? インターネット 接続？ 端末管理? モノ向けの クラウド？ IoTの課題
13. 13. IoTの通信の課題 インターネットモノ 《 IoTの通信の障壁 》 ・有線LANは場所の制約 ・無線LANはセキュリティ難 インターネット 接続？ →モバイル通信が良い しかし、 ヒト向けのプラン しかない
14. 14. ITベンチャーが モノ向け通信を どうやって提供するのか？
15. 15. 通信キャリアとMVNO インターネットモノ 基地局 データセンター ISP パケット交換 帯域制御 顧客管理 課金・・・ 通信キャリア 専 用 線 接 続
16. 16. インターネットモノ 基地局 データセンター ISP パケット交換 帯域制御 顧客管理 課金・・・ NTTドコモの基地局と AWSクラウドで バーチャルキャリアを実現
17. 17. モバイルとクラウドが融合した IoT向け通信プラットフォーム
18. 18. 1日10円〜、モノ向け通信サービス SORACOM Air
19. 19. インターネット SORACOM Air – モバイル通信サービス NTTドコモ の交換局 お客様 ① SIMを購入して モノに挿す Webコンソール ②Webから コントロール
20. 20. Webコンソールで回線管理
21. 21. API Reference
22. 22. IoT通信の標準共通基盤としての特徴を備える •1日10円〜の従量課金 •スモールスタートでき、必要に応じてスケール •IoTデバイスを監視/管理でき、運用を楽に •プログラマブルなAPI提供 •誰でも自由に値付けをしてビジネスができる →失敗のコストを下げ、イノベーションを支援 オープンでフェアなプラットフォーム としてのSORACOM
23. 23. アワードを多数受賞！
24. 24. ちなみに Beam はプライベートβ時に “IoT Exchange” という名前だった
25. 25. 《 ある日の会食にて… 》
26. 26. 「玉川さん、 IoT Exchange って名前 分かりづらいよ…」 サーバーワークス 大石代表
27. 27. 10人くらいでウンウン唸った結果、 Beam という名前に決定！ (その後厄介な事になるとも知らずに)
28. 28. 《 ４ヶ月後… 》
29. 29. 2016/1/27 初のプライベートカンファレンス
30. 30. 一気に４つの新サービスを発表
31. 31. お気づきですね？
32. 32. http://togetter.com/li/925613
33. 33. Air Beam と発表した後に 次は C だと言った人が いらっしゃったので、つい乗っかってしまった 今は反省している…
34. 34. すいませんBeam考えたの私です
35. 35. スタートレックの転送”ビーム”のイメージ 安全に惑星表面などに移動する装置
36. 36. 実はこれが一番近かったですね
37. 37. SORACOM SIM アダプター
38. 38. 《 本題 》
39. 39. 今日する話
40. 40. ソラコムではどのようにして 開発スピードを上げているか
41. 41. . . . 今日しない話
42. 42. あなたの会社でどのようにして 開発スピードを上げるか
43. 43. なぜか
44. 44. 組織が違えば 仕事の仕方も当然違う
45. 45. 昨日のデブサミで… http://www.ryuzee.com/contents/blog/7078
46. 46. Amazonの組織図 Jeff Bezos AWS Sales Marketing Support
47. 47. SORACOM ソラコムの組織はこんな感じ •中心は Ken(玉川憲) (社内では基本的に お互いをニックネームで 呼ぶ決まり) •エンジニアは半分くらい •色々なプロジェクト毎に １人または少人数で協調 •組織はフラット → 全員がリーダー Ken
48. 48. 全員がリーダー Customer Centric: 顧客中心主義 Done is better than perfect: 完璧よりもスピード Proactive: 未来に対して明るく肯定的 Likability: オープンでフェアで誠実、ユーモアを忘れない、みんな のソラコム ・・・14個のリーダーシッププリンシパル 新しいものを作るのだから定量的評価よりも、定性的評価が大事 SORACOMのリーダーシッププリンシプル
49. 49. “我々の間には、チームプレーなどと いう都合のよい言い訳は存在せん。 有るとすればスタンドプレーから 生じる、チームワークだけだ。” ─ 公安９課 荒巻大輔 (『攻殻機動隊 S.A.C. 第5話』) →(それぞれが自立)“Stand Alone” かつ “Complex”(複合体)な組織 理想
50. 50. ソラコムを支えるツールたち waffle swagger Travis CI appear.in etc…
51. 51. •基本はScrum • DailyのSync meeting Appear.in または Slack で報告 • 2 week 単位での スプリント プランニング〜テスト〜リリース タスク管理は GitHub Issues + Waffle.io •フルフレックス＆リモートワーク可能 • 自宅やカフェでも作業できる •部分的に仕事を切り出してお願いする事も ソラコムのワークスタイル
52. 52. Sync meeting: appear.in ↓オフィス ← リ モ ー ト 組 （ 自 宅 ・カ フ ェ 等 )
53. 53. タスク管理：GitHub Issues + Waffle.io
54. 54. インテグレートして大きな力を発揮 ↑Beam MQTT開通時 ↓インテグレーション 成功時はお寿司
55. 55. •働く場所や時間はかなり柔軟 •ミーティングが少なめ •メールの量がとても少ない(外部とのやりとりのみ) •Slackの流量はそれなり ただし未読管理や返信もメールに比べれば楽 WebhookやBotを活用して ChatOps ソラコムのワークスタイルのいいところ
56. 56. 《 開発方針 》
57. 57. • SORACOMという大きなサービスは構成要素となる小 さなサービス（マイクロサービス）とそれを実装するコ ンポーネントが疎結合されて構築される • 各マイクロサービスやコンポーネントごとにPrimary Ownerがいて、Ownershipを持って開発・メンテナン ス・運用に携わる • 各コンポーネントはそれぞれAPIを通じて連携するため、 APIについては他のコンポーネントOwnerとしっかり連 携、APIの裏側については開発スピードを重視してそれ ぞれに適した実装方法を導入 基本原則
58. 58. パケット転送 帯域制御 アクセス制御 Beam処理 回線・セッション管理 認証 課金 イベント通知 API コンソール Polaris Dipper Hubble 監視・デプロイ SORACOM Architecture
59. 59. PolarisとDipper マイクロサービス化された 機能コンポーネント群 セッション管理 認証 課金 API Gateway User Data API API User Data パケット転送 帯域制御 … Amazon DynamoDB
60. 60. •We develop! •We operate!! •We support!!! →運用が楽なシステムを開発 開発者が運用・サポートもやる体制
61. 61. •まずは動かす事を考え、後から機能・品質を改善 “Done is better than perfect” •マネージドサービスをとことん活用する DynamoDB, Lambda, Beanstalk etc… •ただし要件に合わない場合には自作も辞さない →「SORACOM API こぼれ話」 https://blog.soracom.jp/blog/2015/10/09/api-gateway/ どうやって開発スピードを上げるか
62. 62. 《 “F”ができるまで 》
63. 63. ✖️ ファンネル ○ ファネル 意味: 漏斗(ろうと)→ Funnel? SORACOM Funnel
64. 64. SORACOM Funnel – クラウドリソースアダプタ クラウドサービスに特化したデータ転送サービス (デバイスに認証情報やSDKを持つ必要がない) 「Amazon Kinesis」「Amazon Kinesis Firehose」と「Microsoft Azure Event Hubs」
65. 65. 《 “発端” 》
66. 66. 昨年10月のslackから
67. 67. 実はサービスロンチの約1週間後 C〜Fのサービスが確定してた
68. 68. 《 月日が流れ 》
69. 69. 12月の中旬、大体の仕様が固まる
70. 70. •データやコンフィグの形式 •実装するパーツ • クレデンシャルを安全に保存する • データをデバイスから受け取る •データをクラウドサービスに流す •結合テストのタイミング→年明けすぐ イベントの２週前には動いている状態にしたい EDD(Event-Driven-Development) 決まった事
71. 71. 《 そして年が明けた 》
72. 72. 1/7 年明け初の結合テスト …なんと一発で繋がってしまった 「試しにデータ投げてみますか？」
73. 73. 《 さらに翌週 》
74. 74. 1/13 本番環境で端末から Funnel 開通 仕様決定から約一ヶ月
75. 75. ただし年末年始があったので正味２週間
76. 76. CTO安川曰く 「仕様をwikiに書いただけ なのに、いつの間にか サービスが出来上がって 胸熱！」
77. 77. •あらかじめAPIやデータフォーマットなどの仕様が ほぼ決まっていた(細かい変更は適宜すり合わせ) •小さなパーツをそれぞれ一人で作るので効率が良い (しかもなるべく楽に作るようにする) •直接会話はしてないが Sync や Slack でお互いの状 況が分かっていた(Slackの個人チャンネルで考えて る事とか試している事をdumpしている) 考察：なぜうまくいったか
78. 78. “システムを徹底的に疎結合にしたら 開発チームも疎結合になって 非同期に開発できるようになったので とても開発スピードが上がった件” まとめ
79. 79. 《 株式会社ソラコムのビジョン 》 世界中のモノと人をつなげ 共鳴する社会へ