ユニリタのDevOpsに対する取り組み〜Docker使ってみた〜
株式会社ユニリタ
Be.Cloud真木 卓爾
2016.06.10© 2015 UNIRITA Inc. All rights reserved.

Agenda起(Why)

・・・・7分承(YWT)

・・・・5分転(YWT)

・・・・6分結(YWT)

・・・・2分

なぜDevOps、なぜDocker？

ソリューション、⼿法、ツール

理想と現実

今後の取り組み© 2015 UNIRITA Inc. All rights reserved.

2

起(Why)なぜDevOps(Docker)？
© 2015 UNIRITA Inc. All rights reserved.

3

ビジネスモデル１
・オンプレミス・ライセンス、技術⽀援・役務型
・直販営業が売る
自社パッケージ
自社パッケージ
お客様のデータセンター© 2015 UNIRITA Inc. All rights reserved.

4

ビジネスモデル２
・マネージドサービス(いちおうクラウド)・⽉額利⽤料、技術⽀援・役務型
・直販営業が売る
お客様

お客様

お客様

自社パッケージ

自社パッケージ

自社パッケージ

AWS© 2015 UNIRITA Inc. All rights reserved.

5

ビジネスモデル３
・SaaS(いちおうクラウド)・⽉額利⽤料・サービス型
・直販営業が売る
お客様

お客様

お客様

自社SaaS

自社SaaS

自社SaaSAWS© 2015 UNIRITA Inc. All rights reserved.

6

ビジネスモデルまとめ
ビジネスモデル１ ビジネスモデル２ ビジネスモデル３
インフラは？

オンプレミスクラウド

クラウド

何でお金をいただ
く？

ライセンス
技術支援

月額利用料
技術支援

月額利用料

何を売る？

自社パッケージ

自社パッケージ

SaaS

誰が売る？

直販営業

直販営業

直販営業

スケールしない© 2015 UNIRITA Inc. All rights reserved.

7

スケールするためには？
・すぐに始められる→マルチテナント→トライアルサイト

・⼝コミで広まる(バイラルマーケティング)→マーケティング、インサイドセールスが売る→事業部はコンテンツを提供する

・良いサービスがどんどん⽣み出される→他部⾨や他社との協業モデル

私たちは、これらを実現できるプラットフォームを持っていない© 2015 UNIRITA Inc. All rights reserved.

8理想的なスケールサイクル

App Store

iPhone© 2015 UNIRITA Inc. All rights reserved.

9

新ビジネスモデル
新ビジネスモデル

ビジネスモデル１

ビジネスモデル２

ビジネスモデル３

インフラは？

オンプレミス

クラウド

クラウド

クラウド
プラットフォーム

何でお金をいただく？

ライセンス
技術支援

月額利用料
技術支援

月額利用料

月額利用料

何を売る？

自社パッケージ

自社パッケージ

SaaS

自部門SaaS
他部門SaaS
他社SaaS

誰が売る？

直販営業

直販営業

直販営業

マーケティング
インサイドセールス
事業部、他社
口コミ© 2015 UNIRITA Inc. All rights reserved.

10

CloudGearコンセプト
Be.Cloudサービス

ユニリタサービス

協業サービス

自部門SaaS

他部門SaaS

他社SaaS

自部門SaaS

他部門SaaS

他社SaaS

CloudGear
サインアップ/イン、課金、SSO、ID管理、モバイル、セキュリティ、パーソナライズ

AWS (Elastic Container Service)

CloudGearアカウント© 2015 UNIRITA Inc. All rights reserved.

11

どうやって作るか？
・１年後にできました、はいリリースします・・・ではもう遅い市場投⼊までの時間をいかに短くするか？
・サービスは先に出来上がっていく
運⽤しながら開発しなければならない

運⽤しながら、プラットフォームの変更をいかにスピーディに反映させ、いかに差別化するか© 2015 UNIRITA Inc. All rights reserved.

12

承(YWT)
ソリューション、手法、ツール© 2015 UNIRITA Inc. All rights reserved.

13

ソリューション

Adaptability / Agility

Continuous Delivery(継続的デリバリ)

Continuous
DeployAmazon ECS(Docker)

Continuous
Integration
Jenkins

Iterative
Deployment
スクラム開発Strategic Impact© 2015 UNIRITA Inc. All rights reserved.

14

手法(スクラム開発)
・２週間に１度のスプリントレビューを実施
プロダクトオーナー→プロダクトバックログに責任を持つ→機能や改善の優先度を決める→誰のために、何のために、それが必要なのか、の合意と納得を伝える

スクラムマスター(優秀なメンバー)→スプリントバックログに責任を持つスクラムメンバー(優秀なメンバー２名)→デイリースクラムを実施© 2015 UNIRITA Inc. All rights reserved.

15

手法(スクラム開発)© 2015 UNIRITA Inc. All rights reserved.

16

ツール(Jenkins)

・⾃動コンパイル、⾃動テストを実現© 2015 UNIRITA Inc. All rights reserved.

17

ツール(Docker)
・テスト環境© 2015 UNIRITA Inc. All rights reserved.

18

ツール(AWS ECS)・CloudGear本番環境
AWS S3AWS ECS

CloudGear
CloudGear© 2015 UNIRITA Inc. All rights reserved.

19

DockerとAWS ECSの関係
・AWS ECSはDockerをラップしたAWS EC2の機能
・DockerコンテナのEC2インスタンスへの配備© 2015 UNIRITA Inc. All rights reserved.

20

・サービスの市場投入までの時間をいかに短くするか
ソリューション
・サービスの変更をスピーディに反映させ、いかに差別化するか

Adaptability / Agility

Continuous Delivery(継続的デリバリ)

Continuous
DeployAmazon ECS(Docker)

Continuous
Integration
Jenkins

Iterative
Deployment
スクラム開発Strategic Impact© 2015 UNIRITA Inc. All rights reserved.

21

転(YWT)
理想と現実© 2015 UNIRITA Inc. All rights reserved.

22

AWS ECSのメリット、デメリット【メリット】
・少ない⼯数で本番移⾏可能
・ECS管理によりオーケストレーションを簡易化
・10秒程度で本番リリース可能
・ポータビリティが良い(スケーラビリティより)【デメリット・・・というか⼿間】
・EC2インスタンスを終了した際、⾃動的にECSクラスタから外れない・ECSありきの設計を考えておかないと難易度⾼© 2015 UNIRITA Inc. All rights reserved.

23

理想と現実・勘違いをとく
・円滑な運営のために・チーム管理© 2015 UNIRITA Inc. All rights reserved.

24

理想と現実・勘違いをとく
・円滑な運営のために・チーム管理© 2015 UNIRITA Inc. All rights reserved.

25

勘違いをとくスクラム開発はWFで起きうる問題を解決できる解決しません© 2015 UNIRITA Inc. All rights reserved.

26

勘違いをとくスクラム開発は⾒積り精度が良くなる良くなりません

多少のブレがあっても問題ないだけ© 2015 UNIRITA Inc. All rights reserved.

27

勘違いをとくスクラム開発は仕様変更に強い強くありません

プロダクトオーナーの要求との乖離が少なくなるだけ© 2015 UNIRITA Inc. All rights reserved.

28

勘違いをとくスクラム開発は追加要求にすぐ対応できるできません

トレードオフという概念があるだけ© 2015 UNIRITA Inc. All rights reserved.

29

理想と現実・勘違いをとく・円滑な運営のために・チーム管理© 2015 UNIRITA Inc. All rights reserved.

30

円滑な運営のためにスクラム開発では、プロダクトオーナーと必ず約束しなければならないことがある
約束＝合意と納得
1. スプリント内で実現できること
2. トレードオフの概念
3. ベロシティに気をつける
4. ユーザーストーリーと成果物
これらの約束が守れない(守ってくれない)場合、スクラム開発は必ず失敗する© 2015 UNIRITA Inc. All rights reserved.

31

円滑な運営のために
1. スプリント内で実現できることの約束
・必要なのはガントチャート(進捗管理)ではない
ひとつのスプリントで「何が」できるかそれ以上でもそれ以下でもない
2. トレードオフの概念の約束
・あれをやるならこれはやらない
・追加要求は２スプリント後に再度検討すべき
時間が経つとプロダクトオーナーは往々にしてその要求を忘れている© 2015 UNIRITA Inc. All rights reserved.

32

円滑な運営のためにすごいダメな例

3. ベロシティに気をつけるの約束
・頑張った分だけベロシティは⾼い
頑張るほどにチームの⾸を絞める
・消化不可能な量のユーザーストーリーを持ち込まないこと
4. ユーザーストーリーと成果物の約束・成果物は動くものであり、それがすべて・成果物に不満があるなら、それはユーザーストーリーの約束ができていなかったということ© 2015 UNIRITA Inc. All rights reserved.

33

円滑な運営のためにプロダクトオーナーとスクラムチームの約束
1. スプリント内で実現できること
2. トレードオフの概念
3. ベロシティに気をつける
4. ユーザーストーリーと成果物
私たちは勘違いにうすうす気づきながらも、少しずつ約束を守れるようになってきた
つまり、ペースをつかんできた© 2015 UNIRITA Inc. All rights reserved.

34

理想と現実・勘違いをとく・円滑な運営のために・チーム管理© 2015 UNIRITA Inc. All rights reserved.

35

チーム管理© 2015 UNIRITA Inc. All rights reserved.

36

チーム管理© 2015 UNIRITA Inc. All rights reserved.

37

チーム管理© 2015 UNIRITA Inc. All rights reserved.

38

チーム管理© 2015 UNIRITA Inc. All rights reserved.

39

理想と現実勘違いにうすうす気づきながらも、プロダクトオーナーとスクラムチームがお互いに、少しずつ約束(合意と納得)を守れるようになってきた
スクラム開発のペースをつかんできた
さらに、ホラクラシー型管理
次はペース配分をどう⾼めるかの議論が始まる© 2015 UNIRITA Inc. All rights reserved.

40

結(YWT)
今後の取り組み© 2015 UNIRITA Inc. All rights reserved.

41

今後の取り組み
・できる限り⼿動を⾃動に・ECSのスケールアップ/アウト
AWS S3AWS ECS

CloudGear
CloudGear

自分たちがどれだけやれるかのペースが分かってきた↓
ペース配分をどう高めるかの議論が始まった© 2015 UNIRITA Inc. All rights reserved.

42

今後の取り組み
スクラム開発Dockerなどのツール

C/D、C/I

生産性 UP
ホラクラシー型
組織

リモートワークマネジメント© 2015 UNIRITA Inc. All rights reserved.

43

最後に・・・
Why ?

What ?

How ?

© 2015 UNIRITA Inc. All rights reserved.

44ご清聴、ありがとうございました

www.unirita.jp/UNRITA@UNRITA© 2015 UNIRITA Inc. All rights reserved.

ユニリタのDevOpsに対する取り組み〜Docker使ってみた〜