1.
xOps:
エンジニアがスタートアップの
成長の原動力となる日
Takaaki Umada / https://medium.com/@tumada/
1

2.
• 今日は主に xOps の話です
• スライドが 200 枚ぐらいありますが、
できるだけ記事などで公開するのでメモ
らなくても大丈夫だと思います
2
今日の構成
導入
（ここ）
xOps の台頭
流れ / Flow
目標設定
2 分
10 分
4 分
まとめ
10 分
4 分

3.
3
今日の 3 つのトピック (OFO)
1. xOps 2. 流れ
(Flow)
3. 目標設定
(Objective)

4.
The Rise of xOps
4

5.
Photos by Kharnagy 5

6.
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 6

7.
Photo by Kharnagy 7

8.
2015 2016 2017 2018
1 Physician Assistant Data Scientist Data Scientist Data Scientist
2 Software Engineer Tax Manager DevOps Engineer DevOps Engineer
3
Business Development
Manager Solutions Architect Data Engineer Marketing Manager
4
Human Resources
Manager Engagement Manager Tax Manager Occupational Therapist
5 Finance Manager Mobile Developer Analytics Manager HR Manager
6 Marketing Manager HR Manager HR Manager Electrical Engineer
7 Database Administrator Physician Assistant Database Administrator Strategy Manager
8 Product Manager Product Manager Strategy Manager Mobile Developer
9 Data Scientist Software Engineer UX Designer Product Manager
10 Sales Manager Audit Manager Solutions Architect Manufacturing EngineerGlassdoor のランキングより
https://www.glassdoor.com/List/Best-Jobs-in-America-LST_KQ0,20.htm
8
Glassdoor ベスト職業ランキングで DevOps が 2 位

9.
http://blog.indeed.com/2017/03/21/best-jobs-united-states-2017/ 9
Indeed でも DevOps エンジニアが人気

10.
10
DevOps / SRE が次々に発刊

11.
• 開発費用が 1 億ドルから 5,500 万
ドルに減少
• サポートする製品数が 140% 増加
• イノベーションのために使えるキャ
パシティが 8 倍に
(5% から 40% に)
11
DevOps の効果: HP のケーススタディ

12.
デプロイの頻度 46 倍以上頻繁
変更へのリードタイム 440 倍速い
MTTR (サービス復元時間) 96 倍早い
変更への失敗率 5 倍低い
https://puppet.com/resources/whitepaper/state-of-devops-report/ 12
DevOps のプラクティスを取り入れている企業の成果
生産性、マーケットシェア、
利益の目標達成の確率
2 倍高い
時価総額の増加 3 年間で 50% 高い
自分の会社を他人に進める
割合
2.2 倍
2017 年版 State of DevOps Report
2016 年版 State of DevOps Report

13.
13
（例）

14.
https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale/ 14
継続的デプロイメントの採用で
2 ～ 3 時間ごとに段階的プッシュ

15.
• Infer / AL
• Buck
• Watchman
• Flow
• One World
• Etc, etc,
一部オープンソース。その他表に出ていないものもたくさん…
15
Facebook のプロセスを支える社内ツール

16.
16
色々自動化できるように

17.
https://medium.com/@tokoroten/闇のdevops-devopsと業績評価-5aff8b60f589 17
(& Ops 業務の多く Dev が取り扱えるように)

18.
18
そして Dev だけじゃない
スタートアップ業界における
Ops への注目

19.
19
xOps

20.
20

21.
21
DataOps Manifesto の登場 (2017 年)

22.
22
Airbnb の DesignOps

23.
23
Design in Tech Report 2018
でも Design Ops に言及

24.
24
DesignOps Summit @ NYC が
2017 年に初開催

25.
25
GE でも BizOps

26.
26
BizOps Conference が
2017 年に初開催

27.
27
SaaS で有名な Tom が
Customer Ops に言及
“Customer Ops provides the software and
metrics for the entirety of the customer
journey”
http://tomtunguz.com/customer-operations/

28.
http://go.radius.com/rs/764-MES-613/images/The-Rise-of-Revenue-Ops-Why-Marketing-and-Sales-Operations-
Make-Growth-Possible.pdf
28
The Rise of Revenue Ops
レポートが 2017 年に出る

29.
従来の Biz Ops 系の話は MBA 的なマネジメント手法によるビジネスプロ
セスの改善だったのが、今は IT/Ops と連携を行いつつ、顧客のジャー
ニーを最適化を行う機能を求められてす (RevOps レポートより)。
http://go.radius.com/rs/764-MES-613/images/The-Rise-of-Revenue-Ops-Why-Marketing-and-Sales-Operations-Make-Growth-Possible.pdf 29
RevOps = Sales Ops + Marketing Ops + IT/Ops
Before After

30.
30
xOps が次々登場

31.
31
なぜ Ops で IT をここまで
気にするようになってきたのか？

32.
Photo/image credit should read: (cc) Kenneth Yeung -www.snapfoc.us
https://www.flickr.com/photos/kyeung808/7412662724/
32
組織デザインで第一に覚えてお
くべきルールは、すべての組織
デザインは悪いということだ。
あらゆる組織デザインは、会社
のある部分のコミュニケーショ
ンを犠牲にすることによって、
他部分のコミュニケーションを
改善する。
- Ben Horowitz
Andreessen Horowitz
“Hard Thing about Hard Things”

33.
33
どの業務の Ops においても
IT がボトルネックに
なりつつあるから

34.
34
ではなぜそもそも
Ops に注目が集まるのか？

35.
Why xOps
35

36.
1. ビジネスの変化：サブスクリプション化
2. SaaS の激増：ソフトウェアによる効率化の導入が容易に
36
Ops が注目される背景

37.
37
1. サブスクリプション化

38.
SaaS だけではなく多くのビジネスがサブスクリプション化しています。
38
様々な既存ビジネスがサブスクリプション化
従来もあったもの
• 雑誌
• フィットネス
• カントリークラブ
• ハードウェアメンテ
ナンス
少し前から
• B2B SaaS (今日の
メイン)
• 映画 (Netflix)
• 音楽 (Spotify, Apple
Music)
• ダイエットプログラ
ム (Nutrisystem)
• 食品配達
(Instacart)
新しい潮流
• ひげそり (Dollar
Shave Club)
• 歯ブラシ (Good
Mouth)
• 食事 (Blue Apron)
• 健康飲料 (Soylent)
• フィットネスクラブ
(ClassPass)
• 配達 (Amazon
Prime)

39.
http://jp.techcrunch.com/2016/07/26/20160722why-did-unilever-pay-1b-for-dollar-shave-club/ 39
ユニリーバが Dollar Shave Club を 1,000 億円で買収
Dollar Shave Club
髭剃りのサブスクリプション

40.
40
エンジンもサブクスリプションに
GE はエンジンそのものを売る（所有してもらう）ビジネ
スから、飛行機が飛んだ時間に合わせて課金する、利用
へのビジネスモデルに移行した。
サービスとして継続的に運用から保守までを提供するこ
とで、プロダクトに関するビッグデータの蓄積が生まれ、
より効率的なメンテナンスができるだけでなく、顧客の
状況をより詳細に把握できるため、顧客の課題に合わせ
た提案ができるようになった。

41.
41
所有 利用

42.
42
購買時点で
関係が終わる
購買時点から
関係が始まる

43.
43
サブスクリプションビジネスの
ほとんどの収益は
関係が始まった後から生まれる

44.
http://www.forentrepreneurs.com/customer-success/ 44
実際にサブスクリプション ビジネスの売り上げの
70 – 95% は更新やアップセル

45.
Customer Success 45
“Recurring Revenue ビジネスにおいて
「ポストセールス」は存在しない。
すべての活動が「プリセールス」である。”

46.
46
さらに満足度の高い顧客は
新規顧客を呼んできてくれる

47.
Edelman Trust Barometer によるリサーチ 47
84
が紹介から始まる
B2B の購買プロセスの
%

48.
48
サブスクリプションの時代は
サービスの継続的な改善と同時に
安定的な運用のバランスが
これまでより大事に

49.
• データドリブンの文化
• 買収時点で従業員全 190 人
中 45 人がエンジニア
• マーケ部隊は何個もソフト
ウェアを試して最適化
• プロダクトがデジタルでなく
ても「デジタル企業」
http://jp.techcrunch.com/2016/07/26/20160722why-did-unilever-pay-1b-for-dollar-shave-club/
https://marketingland.com/cmos-view-adam-weber-dollar-shave-club-video-marketing-184234
http://www.zdnet.com/article/how-dollar-shave-club-went-from-viral-marketer-to-engineering-powerhouse/ 49
例）Dollar Shave Club はある意味「デジタル企業」

50.
50
A1. サブスクリプション化により
Ops (IT) が売上に直結する時代に

51.
51
⇒ エンジニアが成長の原動力に

52.
52
2. SaaS の急増

53.
https://www.bettercloud.com/monitor/saas-powered-workplace-multi-saasmanagement/ 53
SaaS がここ数年
で急増

54.
https://martechtoday.com/infographic-marketing-technology-landscape-113956 54
Marketing Tech だけで
150 -> 5000 に
(毎年約 2 倍に増える)

55.
55
RevOps ができるのも
SaaS による自動化が背景に

56.
56
今後多くの企業が SaaS だけ
になるという予想も

57.
57
SaaS の急増が意味するところ
＝
様々な領域や業務で
ソフトウェアでの自動化が起こる

58.
58
さらに

59.
https://www.programmableweb.com/news/programmableweb-api-directory-eclipses-17000-api-economy-continues-surge/research/2017/03/13 59
API も急増

60.
https://medium.com/stories-by-ibanfirst/apis-for-newbies-rise-of-the-api-economy-de209d44048e 60

61.
API の対象が、ロボットの操作や「手紙を出す」といった、従来より幅広
いタスクに対応しつつある
61
API で操作できる対象の増加
例) Lob: Print, Mail, Postcard
API 経由で手紙の送付までやってく
れる。
例）Transcriptic
AWS for Life Sciences。ロボット
による実験代行。Autoprotocol を
策定。

62.
62
API の種類と数が増える
＝
API 同士の連携で
自動化の柔軟な設計が可能に

63.
63
＆
各業種の Ops の一部を
Dev が扱えるようになりつつある

64.
https://www.bettercloud.com/monitor/saas-operations-management/ 64

65.
https://www.bettercloud.com/monitor/saas-operations-management/ 65
Systems of Record (SoR)

66.
https://www.bettercloud.com/monitor/saas-operations-management/ 66
Systems of Record (SoR)
Systems of Engagement (SoE)

67.
https://www.bettercloud.com/monitor/saas-operations-management/ 67
Systems of Control (SoC)
Systems of Record (SoR)
Systems of Engagement (SoE)

68.
FinTech 金融
EdTech 教育
AgTech 農業
Health Tech ヘルスケア
Legal Tech 法律
HR Tech 人事
Gov Tech 政府
Retail Tech 小売り
68
さらに xTech の台頭
様々な分野で新しいスタートアップが生まれつつあります。

69.
こうした発展が産業の SoC の部分を担い、タスクを効率的に行うことで、
各分野の Ops が改善していく可能性があります。
https://www.bettercloud.com/monitor/saas-operations-management/ 69
様々な領域のオペレーションを改善する可能性
System of Control (SoC)
System of Record (SoR)
System of Engagement (SoE)
FinTech
EdTech
AgTech
Health Tech
Legal Tech
HR Tech
Gov Tech
Space Tech

70.
FinTech
EdTech
AgTech
Health Tech
Legal Tech
HR Tech
Gov Tech
Retail Tech
70
xTech から xOps へ？
FinOps
EdOps
AgOps
Health Ops
Legal Ops
HR Ops
Gov Ops
Retail Ops

71.
FinTech
EdTech
AgTech
Health Tech
Legal Tech
HR Tech
Gov Tech
Retail Tech
71
Retail Ops といえば…
FinOps
EdOps
AgOps
Health Ops
Legal Ops
HR Ops
Gov Ops
Retail Ops

72.
Photo by JJ Merelo
https://www.flickr.com/photos/atalaya/34622320425
72

73.
73
SaaS の普及は
スタートアップにとって
大きなメリット

74.
• スタートアップでも大企業レベルのソフトウェアが比較的安
価に使える
• SaaS と同時にプロセスのベストプラクティスを導入可能
（既存企業は既存のプロセス自体を変更しなければ SaaS を
導入しづらい ）
（& 開発も運用も外部委託していることが多い）
74
SaaS がスタートアップにもたらすメリット

75.
75
さらに

76.
これまで演繹的なアルゴリ
ズムでは精度が出づらかっ
た一部のタスクも機械学習
によって可能になるかも…
https://www.slideshare.net/pfi/20180305ppl2018 76
演繹から帰納へ (PFN 丸山先生)

77.
77
恐らく SaaS でできるタスクが
これからもう少し広がる

78.
78
A2. SaaS の急増により
xOps の実現可能性が上がる

79.
79
⇒ エンジニアが成長の原動力に

80.
1. ビジネスの変化：サブスクリプション化
2. SaaS の激増：ソフトウェアによる効率化の導入が容易に
80
Ops が注目される背景

81.
81
Ops の改善のために
流れを改善する

82.
流れ
Flow
82

83.
http://www.af.mil/News/Photos/igphoto/2000610956/ 83
ここ数年の “流れ” 系の方法論の増加
エクスペリエンスマップ バリューストリームマッピング
サービスブループリント 顧客ファクトリー カンバン
フロー効率性

84.
84
Ops への注目
⇒
流れへの注目

85.
85
フロー効率性

86.
http://i2key.hateblo.jp/entry/2017/10/02/081429 86
リソース効率的な状態とフロー効率的な状態
リソース効率的
リソースを 100% 使っているかど
うか。（人が忙しいかどうか、稼働
率など）
※多くの場合はマルチタスクになる
フロー効率的
対象が流れているかどうか (機能リ
リースまでのリードタイムの短さ)
※少タスクのため、場合によっては
忙しくない人もいる。WIP 制限など
に通じる。

87.
承認者や意思決定者が別の仕事もしているため、コミュニケーションコストなどもかかり
意思決定まで時間がかかりがちです。
87
たとえば通常のフローだと…
顧客
CEO
開発者
Review
Work 待機
Review Approve
Use & Feedback
Work待機 待機
PM
価値を提供できるまでの時間が長い
Review

88.
モブプログラミングや Design Sprint などで意思決定者がその場にいると、一部の人がリ
ソース効率的ではなくなりますが、フロー効率は上がります。
88
モブプロや DS などで意思決定者がその場にいると
顧客
CEO
開発者
Review
Work
Use & Feedback
Work
PM
暇な人は出てくるがリードタイムは短くなる
(リソース効率性は落ちる)
Review
暇
暇

89.
89
プロセス改善と
Ops が組み合わさると…

90.
90
Ops を自動化すれば価値提供までの時間が更に短くなる
顧客
System
開発者
Work 待機
Use & Feedback
Work
System
より短く！

91.
91
Facebook は 2 ～ 3 時間ごとにリリース可能で
安全な実験環境を提供

92.
• Infer / AL
• Buck
• Watchman
• Flow
• One World
• Etc, etc,
一部オープンソース。その他表に出ていないものもたくさん…
92
Facebook のプロセスを支える社内ツール

93.
93
様々な業務のフローも
DevOps 的な発想と技術で
フロー効率的にできるのでは？

94.
94
（例）
ユーザーサポートの Ops

95.
Wufoo では 50 万人のユーザーと 500 万人のフォーム利用者に対して、たった 10 人で
以下のような SDD (サポートを中心とした開発) を行っていた。
95
Wufoo の Dev によるサポートの改善
10 人中
1人
はシフト制でサポート担当
専属となる
毎週必ず
4~8 時間
ユーザーと直接対話するよ
うに義務付け
開発時間の
30%
をサポート用の内部ツール
の開発に充てていた
毎週 400 の問題と 800 のメー
ルに対応できていた。そして 9
時から 21 時までの通常のレス
ポンスタイムは 7 ~ 12 分、
21 時以降は1時間程度、週末
も 24 時間以内にレスポンスし
ていた。
ユーザーとの直接のコミュニ
ケーションがプロダクトを良く
する。報告書やグラフではダメ
というルールを課して、サポー
トを含むユーザーとの直接対話
を行っていた。
ツールの開発で迅速なサポート
ができ、より良いサポートが可
能になるほか、自分たちのサ
ポートの時間を減らすことがで
きる

96.
Image from Wufoo Lecture
startupclass.samaltman.com/courses/lec07/
96
Wufoo の実績：SDD により右肩上がりの購読者数

97.
常にサポートと開発を同時に行うことでスケール後も
サポートリクエストの量がほぼ変わらず、少人数で対応可能
Image from Wufoo Lecture
startupclass.samaltman.com/courses/lec07/
97

98.
Photo taken by Wufoo Team
https://www.flickr.com/photos/wufoo/5169213466/
98
Support Driven Development
By Wufoo

99.
99
やってた

100.
100
DevOps を参考にしながら
エンジニアが担当の幅を広げて
淀みのない xOps のフローを作る

101.
101
1.ワークフローを高速にする
(フローの原則)
2.フィードバックフローを実
現する (フィードバックの
原則)
3.企業文化を生み出す (継続
的な学習と実験の原則)

102.
102
1.ワークフローを高速にする
(フローの原則)
2.フィードバックフローを実
現する (フィードバックの
原則)
3.企業文化を生み出す (継続
的な学習と実験の原則)

103.
カンバンのコアプラクティス
1. 見える化
2. WIP の制限
3. 流れの管理
4. ポリシーの明治
5. フィードバックループの実現
6. コラボレーティブな改善と実験的な進化
103
とりあえず最初に見える化

104.
http://gihyo.jp/dev/column/01/devops/2017/value-stream-mapping 104
例）様々な業務でバリューストリームマッピングから

105.
105
ただ流れに関する
「プル」と「モノと情報の流れ」
について少しだけ解説

106.
106
「プル」の概念

107.
https://www.slideshare.net/i2key/xpjug 107

108.
http://www.flickr.com/photos/joi/2757536235/sizes/o/in/photostream/
Some rights reserved by Joi (https://www.flickr.com/photos/joi/)
108
市場がスタートアップの製品をプルする
(Product/Market Fit についての文脈で)
Andreessen Horowitz
Marc Andreessen

109.
109
「モノと情報の流れ」の概念

110.
モノの流れは左から右へと流れていき、顧客に購入されて届きます。
110
モノの流れ（作業の流れ）
モノの流れ
モノの流れ

111.
しかし実際には、どの顧客が何をいつ、どれぐらい欲しいかという情報に
応じてモノづくりを始めると効率がいいはずです（ニーズからプルする）。
111
情報の流れは顧客から始まる
モノの流れ
情報の流れ
情報の流れは逆（ニーズからプル）

112.
しかし現代社会において、顧客の本当に欲しいものというのはなかなか分
かりません（顧客自身も分かっていないことが多くあります）。
112
しかし顧客の真のニーズが分からないことが多い
顧客が
本当に
欲しい
もの
情報の流れ
モノの流れ

113.
そこでデザイン思考などが注目されています。
113
デザイン思考やリーンスタートアップに注目が集まる
顧客が
本当に
欲しい
もの
情報の流れ
モノの流れ
デザイン思考
リーンスタートアップ

114.
114
でもそもそも Ops が効率的でなければ勝てない
顧客が
本当に
欲しい
もの
情報の流れ
モノの流れ
Ops

115.
115
全体を効率化する
顧客が
本当に
欲しい
もの
情報の流れ
モノの流れ
プルに対して、全体を効率化する

116.
This is Lean より 116
フローを妨げるボトルネックはどこ？

117.
顧客に対する価値を最大化できるように、その流れを淀みなくすることを考えてみる。
117
“価値の流れ” を妨げる場所を見つけて広くする
流れを広く、太くする 流れが太くならない原因
の例
• ニーズの理解の間違い
• リソース不足
淀みが発生する原因の例
• 意思決定の遅さ
• チームコミュニケー
ションによる淀み
• チャネルの非効率化
• 調達の非効率

118.
Photo by Yesicavaldez
https://commons.wikimedia.org/wiki/File:Michael_porter.jpg
118
価値提案は、戦略をつくる要素
のうち、社外の顧客に、つまり
ビジネスの需要サイドに目を向
ける要素である。これに対して
バリューチェーンは社内の業務
に焦点をあてる。このように戦
略は、事業の需要サイドと供給
サイドを一つにまとめるという、
統合的な性質がある。
- Michael Porter
エッセンシャル版 マイケル・ポーターの競争の
戦略 (ジョアン・マグレッタ著)

119.
戦略を考えるとき、戦略論の大家である Michael Porter の考え方を活用して、「独自の
価値提案」「独自の価値の作り方」をまず考えることをお勧めします。
119
戦略では「価値」と「作り方」の 2 つを考える
独自の
価値
提案
独自の
価値の
作り方

120.
120
独自の
価値
提案
独自の価
値の
作り方
顧客
（需要）
サイド
社内
（業務/供給）
サイド
価値提案は「顧客サイド」
価値の作り方は「社内サイド」
にそれぞれ対応しています

121.
121
独自の
価値
提案
独自の価
値の
作り方
何を作るか どう作るか
言い方を変えれば
「何を作るか」と「どう作るか」です

122.
122
独自の
価値
提案
顧客
（需要）
サイド
社内
（業務/供給）
サイド
まずは顧客サイドのほうが重要なので
需要サイドの価値提案の構築を考えます

123.
123
独自の価
値の
作り方
どう作るか
しかし同時に「どう作るか」を考えなければ
戦略とは言えません

124.
124
「どう作るか」の Ops 部分で
IT を活用していく

125.
要件定義 基本設計 詳細設計
コーディン
グ
単体テスト 結合テスト
システムテ
スト
125
たとえば開発の流れ (V 字モデルを参照)
開発の流れは以下のようになっています。

126.
要件定義 基本設計 詳細設計
コーディン
グ
単体テスト 結合テスト
システムテ
スト
126
少しだけ視野を広げて見ると
開発 運用
マーケティ
ング
セールス
カスタマー
サクセス
サポート
開発の後に様々な付加価値活動があります。

127.
要件定義 基本設計 詳細設計
コーディン
グ
単体テスト 結合テスト
システムテ
スト
運用
127
DevOps は Dev の後工程を統合
開発 運用
マーケティ
ング
セールス
カスタマー
サクセス
サポート
DevOps は流れの中の二つを統合したものと言えます。
DevOps
フローの高速化とフィードバックループと継続的改善の文化

128.
Photo/image credit should read: (cc) Kenneth Yeung -www.snapfoc.us
https://www.flickr.com/photos/kyeung808/7412662724/
128
組織デザインで第一に覚えてお
くべきルールは、すべての組織
デザインは悪いということだ。
あらゆる組織デザインは、会社
のある部分のコミュニケーショ
ンを犠牲にすることによって、
他部分のコミュニケーションを
改善する。
- Ben Horowitz
Andreessen Horowitz
“Hard Thing about Hard Things”

129.
129
その後うまくいったとして…

130.
130
（例）
肺がんの画像診断で
検出率が 99% になった！

131.
131
でもどうやって
認識率 98.9% の他社競合と
差別化するの？

132.
132
ちょっとだけ視野を広げて見てみると…
開発 運用
マーケティ
ング
セールス
カスタマー
サクセス
サポート
開発したものの価値はその後ろの工程で決まることがあります。

133.
133
そして xOps の時代だと…
開発 運用
カスタマー
サクセス
開発と運用の先に各領域のビジネス機能があり、それぞれがつながってい
るのが xOps と考えると…
開発 運用 サポート
開発 運用 セールス
開発 運用 マーケ
フィードバックループと継続的な改善
フィードバックループと継続的な改善
フィードバックループと継続的な改善
フィードバックループと継続的な改善

134.
134
たとえばカスタマーサクセスでの新しい潮流として…
開発 運用
カスタマー
サクセス
開発 運用 サポート
開発 運用 セールス
開発 運用 マーケ

135.
http://developer.hatenastaff.com/entry/2017/08/09/173607
https://cloudplatform-jp.googleblog.com/2016/10/google-cre.html
135
Customer Success / Reliability Engineer の登場
CSE/CRE 職が誕生
(顧客もかなり巻き込む)

136.
136
エンジニアの職責が
一歩広がっている？
（ビジネスモデルにもよりますが）

137.
137
xOps 改善を始めるのは、
既にモデルがはっきりしていて
顧客への価値に近いところから
（RevOps, カスタマーサクセス等）

138.
価値をどこに置くかを決めるのはプロダクトマネジメントの仕事です。
138
価値を決めなければ流れの行き先が決まらない
顧客
への
価値
提供
情報の流れ
モノの流れ
プロダクトマネジメント

139.
139
エンジニアが
プロダクトマネージャーになって
顧客への価値の流れを
制御するのも一つの手

140.
140
その他のサポート系 Ops も同様にフローで考える
開発 運用
マーケティ
ング
セールス
カスタマー
サクセス
サポート
人事
法務
調達

141.
LawGeex が 5 種類の NDA を AI と人間にレビューさせたところ、AI の
ほうが 94% の精度を出し、時間は人間に比べて 212 倍早かった。
https://blog.lawgeex.com/ai-more-accurate-than-lawyers/ 141
例）法務文章のレビューを正確かつ迅速に (Feb, 2018)

142.
https://medium.com/salsa-silicon/10-todays-hr-tech-landscape-a910ab0a1d4f 142
HR Tech の台頭による
自動化の可能性

143.
143
エンジニアが人事になれば
もしかすると Ops の改善も…？！

144.
Photo by Ian Kennedy Follow (https://www.flickr.com/photos/clankennedy/16942766725)
Facebook F8 Conference - Chris Cox / Color changed by this presenter
144
Facebook の現 Chief Product Officer の
Chris Cox はエンジニアの後に
Director of Human Resources に

145.
145
エンジニアが
様々な Ops を継続的に効率化する

146.
146
トイル (toil)
手作業で繰り返し行われ、自動化
することが可能であり、戦術的で
長期的な価値を持たず、作業量が
サービスの成長に比例するといっ
た傾向を持つもの

147.
147
エンジニアなら
様々な業務のオペレーションで
流れを妨げるトイルを撲滅できる
（ときもある）

148.
148
こういうツールでの自動化だけでも効果あり

149.
149
その結果…

150.
• 開発費用が 1 億ドルから 5,500 万
ドルに減少
• サポートする製品数が 140% 増加
• イノベーションのために使えるキャ
パシティが 8 倍に (5% から 40%
に)
150
DevOps の効果: HP のケーススタディ

151.
151
エンジニアが
会社の Ops を変えて
次の成長へ挑戦できる
キャパシティを増やす

152.
152
エンジニアが
次の成長の原動力になる

153.
• エンジニア出身のカスタマーサクセス
• エンジニア出身の人事
• エンジニア出身の経理
• エンジニア出身のマーケター
• エンジニア出身の……
153
ソフトウェアエンジニア出身の〇〇担当を増やす

154.
154
ただコードを書く量は減ります…
(なので場合によってはお勧めできないかも…)

155.
155
さらに社内のツールが
新規事業やスタートアップになる
可能性もある

156.
ボーイング時代のニーズをベースに開発。
156
Rescale: HPC ソフトウェアと計算資源の AWS

157.
157
社内ツールが
独立して
スタートアップに
(Phacility)

158.
158
何より、改善されたプロセスは
一朝一夕には真似できない
競争優位になる

159.
159https://www.slideshare.net/kdmsnr/lean-enterprise-20170719

160.
160https://www.slideshare.net/kdmsnr/lean-enterprise-20170719

161.
161https://www.slideshare.net/kdmsnr/lean-enterprise-20170719

162.
162
継続的な改善は裏切らない

163.
163
各領域のプロセスの流れの中に
エンジニアの力を

164.
164
ただし

165.
165
早すぎる最適化は
諸悪の根源である
By Donald Knuth

166.
166
統合はある時点
では競争上不可
欠だが、後には
競争上の障害と
なるのだ
競争上、統合が優
位となる地点と非
統合が優位となる
地点は、ときとと
もに間違いなく移
動する

167.
目標設定
Objective
167

168.
168
xOps は
技術論と組織論の組み合わせ

169.
https://www.slideshare.net/dragan10/hb-study-74-site-reliability-engineering 169
SRE 本の翻訳者の玉川さんの解説スライド
でも「技術論よりも組織論」

170.
170
継続的な改善と安定的な運用の
両方を同一チームで
実現するために考えるべきこと

171.
171
メトリクスの設定

172.
どうやって共通ゴールを持たせるかが課題
• DevOps だと開発と運用でだいたいトレードオフが生じる
• 新しい機能をリリースしたいけれど安定性が…等
• xOps でも IT とビジネスのトレードオフが生じる
• でも従来通りそれぞれ別の KPI を持たせたらサイロ化し
て意味がない
• しかし売上をそのまま xOps に持たせると破綻しそう
172
Objective / KPI 設定の難しさ

173.
173
しかし Flow も Ops も
Objective 次第なところもあり
避けて通れない
（xOps は単純な自動化だけではダメ）

174.
174
（解決例）
SRE における
エラーバジェット

175.
関係各所の共通ゴールを持てるようなメトリクス設定が必要に
例）
• エラーバジェット (SRE)
エラーバジェットの範囲内で新しい挑戦ができるように
• 遅延コスト (CD3: Cost of Delay Divided by Duration)
緊急性と価値を組み合わせたもの
などなど…（模索中）
175
Ops 時代の Objectives の例

176.
176
エラーバジェットが
設定できるのも
ビジネスとして適切な
SLO (Service Level Objective)
が定められるからこそ

177.
177
この種の KPI の設定ができるのは
ビジネス全体に責任を持つ人で、
かつエンジニアリングが分かる人

178.
178
さらにメトリクスの追跡の自動化
にもエンジニアが必要

179.
• Ops の発展により、売上に近い KPI を Dev が持てる時代に
• ただしもちろん売上には関わらないままの選択もあり
• 関わればその分、ビジネスにおいてエンジニアは責任と自由
を持てる傾向にある
179
Dev がビジネスゴールを持つべきかどうか？

180.
https://www.slideshare.net/i2key/devsumib 180
ビジネス貢献が可視化しやすいとエンジニア文化に

181.
181
大企業ではなかなかできない xOps が
スタートアップならできるかも

182.
まとめ
182

183.
今日は新規事業を育てるための xOps、流れ、目標設定について
話しました。
183
今日の 3 つのトピック
1. xOps 2. 流れ
(Flow)
3. 目標設定
(Objective)

184.
184
エンジニアがスタートアップの
成長の原動力になる日
＝
エンジニアが一歩他の領域に
踏み出して Ops を改善し始める日

185.
185
エンジニアがスタートアップの
成長の原動力になる日
＝
今日、というか昨日
（から Ops を継続的改善しているところが強い）

186.
186
今日の End Action の提案
エンジニアの皆さんへ
• エンジニアが色々な領域で活
躍できるチャンスが来てるの
で、ちょっとだけ担当の視野
の範囲を広げてみませんか
• チャンスが見つかればキャリ
アの幅が広がるし、起業のア
イデアにつながるかも
ビジネスサイドの皆さんへ
• Ops の改善が持続的な成長
の鍵
• 売上に近いところに IT とエ
ンジニアによる Ops 改善を
• エンジニアの皆さんに機会を
チャンスを与えて、エンジニ
ア視点での Ops の改善機会
の発見をしてみませんか

187.
187
振り返ってみれば…

188.
http://www.visualcapitalist.com/chart-largest-companies-market-cap-15-years/ 188
時価総額 Top 5 はデジタルプロダクトを持つ企業

189.
189
Digital Product Wins!

190.
http://www.visualcapitalist.com/chart-largest-companies-market-cap-15-years/
190
と同時に、最高のデジタルオペレーションを持つ企業？

191.
191
Digital Operation Wins!

192.
192

193.
イノベーションのジレンマを書いたクリステンセンは組織の能力を「資源」「プロセス」
「価値基準」の 3 つに分解しています。
193
クリステンセンによる組織の「能力」の分解
資源
Resource
プロセス
Process
価値基準
Value

194.
3つに含まれるものの例は以下のとおりです。
194
クリステンセンによる組織の「能力」の分解
資源
Resource
プロセス
Process
価値基準
Value
人材、設備、技術、
情報、資金、関係
性など
意思決定、意思伝
達、資源配分、連
携など
優先順位をつける
ための判断基準、
自らに課す制約

195.
195
戦略を考える上ではつい資源に目を向けがち
資源
Resource
プロセス
Process
価値基準
Value

196.
しかし重要なのは資源だけではありません。クリステンセンは能力が徐々にプロセスや価
値基準へ移動することを指摘しています。
196
資源だけでは不十分で、プロセスや文化に能力が宿る
資源
Resource
プロセス
Process
価値基準
Value

197.
197
「プロセスを信じよ」
ピクサーの二大原則の一つ

198.
プロセスが企業文化を作っていくところが多々あると思っています。
198
資源だけでは不十分で、プロセスや文化に能力が宿る
資源
Resource
プロセス
Process
価値基準
Value

199.
199
もしプロセスや Ops を作るところに
エンジニアが加わることが多くなれば
エンジニアが企業文化を作る時代に

200.
https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0 200

201.
201
Digital Culture Wins!

202.
202
スタートアップなら
理想の Culture を作れる

203.
イノベーションのジレンマを書いたクリステンセンは組織の能力を「資源」「プロセス」
「価値基準」の 3 つに分解していて、その中の二つにもエンジニアは貢献ができます。
203
エンジニアが組織の能力を決める時代に
資源
Resource
プロセス
Process
価値基準
Value
エンジニアがプロセスと文化を作る

204.
204
最後に
エンジニアリング (工学) とは

205.
205
工学とは数学と自然科学を基礎と
し、ときには人文社会科学の知見
を用いて、公共の安全、健康、福
祉のために有用な事物や快適な環
境を構築することを目的とする学
問である。

206.
206
工学とは数学と自然科学を基礎と
し、ときには人文社会科学の知見
を用いて、公共の安全、健康、福
祉のために有用な事物や快適な環
境を構築することを目的とする学
問である。

207.
207
エンジニア同士、
有用な事物を作るために
いろいろな知見を活用しながら
社会をより良くしていければと
思ってます

208.
208
まだまだ道半ばですが
一緒に頑張れれば嬉しいです
（おわり：何かあればお声がけください）