Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

xOps: エンジニアがスタートアップの成長の原動力となる日

15,259 views

Published on

近年増え始めている xOps についてのスライドです。RevOps、DataOps、DesignOps、Customer Ops などが生まれてきている背景としてのサブスクリプション化と SaaS について、そして xOps を実現するうえで必要なフローの概念と目標設定について書いています。またこうした流れの中でエンジニアが貢献できる部分が多くなっているのでは、と考えています。

Published in: Technology

xOps: エンジニアがスタートアップの成長の原動力となる日

  1. 1. xOps: エンジニアがスタートアップの 成長の原動力となる日 Takaaki Umada / https://medium.com/@tumada/ 1
  2. 2. • 今日は主に xOps の話です • スライドが 200 枚ぐらいありますが、 できるだけ記事などで公開するのでメモ らなくても大丈夫だと思います 2 今日の構成 導入 (ここ) xOps の台頭 流れ / Flow 目標設定 2 分 10 分 4 分 まとめ 10 分 4 分
  3. 3. 3 今日の 3 つのトピック (OFO) 1. xOps 2. 流れ (Flow) 3. 目標設定 (Objective)
  4. 4. The Rise of xOps 4
  5. 5. Photos by Kharnagy 5
  6. 6. https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr 6
  7. 7. Photo by Kharnagy 7
  8. 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. 9. http://blog.indeed.com/2017/03/21/best-jobs-united-states-2017/ 9 Indeed でも DevOps エンジニアが人気
  10. 10. 10 DevOps / SRE が次々に発刊
  11. 11. • 開発費用が 1 億ドルから 5,500 万 ドルに減少 • サポートする製品数が 140% 増加 • イノベーションのために使えるキャ パシティが 8 倍に (5% から 40% に) 11 DevOps の効果: HP のケーススタディ
  12. 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. 13 (例)
  14. 14. https://code.facebook.com/posts/270314900139291/rapid-release-at-massive-scale/ 14 継続的デプロイメントの採用で 2 ~ 3 時間ごとに段階的プッシュ
  15. 15. • Infer / AL • Buck • Watchman • Flow • One World • Etc, etc, 一部オープンソース。その他表に出ていないものもたくさん… 15 Facebook のプロセスを支える社内ツール
  16. 16. 16 色々自動化できるように
  17. 17. https://medium.com/@tokoroten/闇のdevops-devopsと業績評価-5aff8b60f589 17 (& Ops 業務の多く Dev が取り扱えるように)
  18. 18. 18 そして Dev だけじゃない スタートアップ業界における Ops への注目
  19. 19. 19 xOps
  20. 20. 20
  21. 21. 21 DataOps Manifesto の登場 (2017 年)
  22. 22. 22 Airbnb の DesignOps
  23. 23. 23 Design in Tech Report 2018 でも Design Ops に言及
  24. 24. 24 DesignOps Summit @ NYC が 2017 年に初開催
  25. 25. 25 GE でも BizOps
  26. 26. 26 BizOps Conference が 2017 年に初開催
  27. 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. 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. 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. 30 xOps が次々登場
  31. 31. 31 なぜ Ops で IT をここまで 気にするようになってきたのか?
  32. 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. 33 どの業務の Ops においても IT がボトルネックに なりつつあるから
  34. 34. 34 ではなぜそもそも Ops に注目が集まるのか?
  35. 35. Why xOps 35
  36. 36. 1. ビジネスの変化:サブスクリプション化 2. SaaS の激増:ソフトウェアによる効率化の導入が容易に 36 Ops が注目される背景
  37. 37. 37 1. サブスクリプション化
  38. 38. SaaS だけではなく多くのビジネスがサブスクリプション化しています。 38 様々な既存ビジネスがサブスクリプション化 従来もあったもの • 雑誌 • フィットネス • カントリークラブ • ハードウェアメンテ ナンス 少し前から • B2B SaaS (今日の メイン) • 映画 (Netflix) • 音楽 (Spotify, Apple Music) • ダイエットプログラ ム (Nutrisystem) • 食品配達 (Instacart) 新しい潮流 • ひげそり (Dollar Shave Club) • 歯ブラシ (Good Mouth) • 食事 (Blue Apron) • 健康飲料 (Soylent) • フィットネスクラブ (ClassPass) • 配達 (Amazon Prime)
  39. 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. 40 エンジンもサブクスリプションに GE はエンジンそのものを売る(所有してもらう)ビジネ スから、飛行機が飛んだ時間に合わせて課金する、利用 へのビジネスモデルに移行した。 サービスとして継続的に運用から保守までを提供するこ とで、プロダクトに関するビッグデータの蓄積が生まれ、 より効率的なメンテナンスができるだけでなく、顧客の 状況をより詳細に把握できるため、顧客の課題に合わせ た提案ができるようになった。
  41. 41. 41 所有 利用
  42. 42. 42 購買時点で 関係が終わる 購買時点から 関係が始まる
  43. 43. 43 サブスクリプションビジネスの ほとんどの収益は 関係が始まった後から生まれる
  44. 44. http://www.forentrepreneurs.com/customer-success/ 44 実際にサブスクリプション ビジネスの売り上げの 70 – 95% は更新やアップセル
  45. 45. Customer Success 45 “Recurring Revenue ビジネスにおいて 「ポストセールス」は存在しない。 すべての活動が「プリセールス」である。”
  46. 46. 46 さらに満足度の高い顧客は 新規顧客を呼んできてくれる
  47. 47. Edelman Trust Barometer によるリサーチ 47 84 が紹介から始まる B2B の購買プロセスの %
  48. 48. 48 サブスクリプションの時代は サービスの継続的な改善と同時に 安定的な運用のバランスが これまでより大事に
  49. 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. 50 A1. サブスクリプション化により Ops (IT) が売上に直結する時代に
  51. 51. 51 ⇒ エンジニアが成長の原動力に
  52. 52. 52 2. SaaS の急増
  53. 53. https://www.bettercloud.com/monitor/saas-powered-workplace-multi-saasmanagement/ 53 SaaS がここ数年 で急増
  54. 54. https://martechtoday.com/infographic-marketing-technology-landscape-113956 54 Marketing Tech だけで 150 -> 5000 に (毎年約 2 倍に増える)
  55. 55. 55 RevOps ができるのも SaaS による自動化が背景に
  56. 56. 56 今後多くの企業が SaaS だけ になるという予想も
  57. 57. 57 SaaS の急増が意味するところ = 様々な領域や業務で ソフトウェアでの自動化が起こる
  58. 58. 58 さらに
  59. 59. https://www.programmableweb.com/news/programmableweb-api-directory-eclipses-17000-api-economy-continues-surge/research/2017/03/13 59 API も急増
  60. 60. https://medium.com/stories-by-ibanfirst/apis-for-newbies-rise-of-the-api-economy-de209d44048e 60
  61. 61. API の対象が、ロボットの操作や「手紙を出す」といった、従来より幅広 いタスクに対応しつつある 61 API で操作できる対象の増加 例) Lob: Print, Mail, Postcard API 経由で手紙の送付までやってく れる。 例)Transcriptic AWS for Life Sciences。ロボット による実験代行。Autoprotocol を 策定。
  62. 62. 62 API の種類と数が増える = API 同士の連携で 自動化の柔軟な設計が可能に
  63. 63. 63 & 各業種の Ops の一部を Dev が扱えるようになりつつある
  64. 64. https://www.bettercloud.com/monitor/saas-operations-management/ 64
  65. 65. https://www.bettercloud.com/monitor/saas-operations-management/ 65 Systems of Record (SoR)
  66. 66. https://www.bettercloud.com/monitor/saas-operations-management/ 66 Systems of Record (SoR) Systems of Engagement (SoE)
  67. 67. https://www.bettercloud.com/monitor/saas-operations-management/ 67 Systems of Control (SoC) Systems of Record (SoR) Systems of Engagement (SoE)
  68. 68. FinTech 金融 EdTech 教育 AgTech 農業 Health Tech ヘルスケア Legal Tech 法律 HR Tech 人事 Gov Tech 政府 Retail Tech 小売り 68 さらに xTech の台頭 様々な分野で新しいスタートアップが生まれつつあります。
  69. 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. 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. 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. 72. Photo by JJ Merelo https://www.flickr.com/photos/atalaya/34622320425 72
  73. 73. 73 SaaS の普及は スタートアップにとって 大きなメリット
  74. 74. • スタートアップでも大企業レベルのソフトウェアが比較的安 価に使える • SaaS と同時にプロセスのベストプラクティスを導入可能 (既存企業は既存のプロセス自体を変更しなければ SaaS を 導入しづらい ) (& 開発も運用も外部委託していることが多い) 74 SaaS がスタートアップにもたらすメリット
  75. 75. 75 さらに
  76. 76. これまで演繹的なアルゴリ ズムでは精度が出づらかっ た一部のタスクも機械学習 によって可能になるかも… https://www.slideshare.net/pfi/20180305ppl2018 76 演繹から帰納へ (PFN 丸山先生)
  77. 77. 77 恐らく SaaS でできるタスクが これからもう少し広がる
  78. 78. 78 A2. SaaS の急増により xOps の実現可能性が上がる
  79. 79. 79 ⇒ エンジニアが成長の原動力に
  80. 80. 1. ビジネスの変化:サブスクリプション化 2. SaaS の激増:ソフトウェアによる効率化の導入が容易に 80 Ops が注目される背景
  81. 81. 81 Ops の改善のために 流れを改善する
  82. 82. 流れ Flow 82
  83. 83. http://www.af.mil/News/Photos/igphoto/2000610956/ 83 ここ数年の “流れ” 系の方法論の増加 エクスペリエンスマップ バリューストリームマッピング サービスブループリント 顧客ファクトリー カンバン フロー効率性
  84. 84. 84 Ops への注目 ⇒ 流れへの注目
  85. 85. 85 フロー効率性
  86. 86. http://i2key.hateblo.jp/entry/2017/10/02/081429 86 リソース効率的な状態とフロー効率的な状態 リソース効率的 リソースを 100% 使っているかど うか。(人が忙しいかどうか、稼働 率など) ※多くの場合はマルチタスクになる フロー効率的 対象が流れているかどうか (機能リ リースまでのリードタイムの短さ) ※少タスクのため、場合によっては 忙しくない人もいる。WIP 制限など に通じる。
  87. 87. 承認者や意思決定者が別の仕事もしているため、コミュニケーションコストなどもかかり 意思決定まで時間がかかりがちです。 87 たとえば通常のフローだと… 顧客 CEO 開発者 Review Work 待機 Review Approve Use & Feedback Work待機 待機 PM 価値を提供できるまでの時間が長い Review
  88. 88. モブプログラミングや Design Sprint などで意思決定者がその場にいると、一部の人がリ ソース効率的ではなくなりますが、フロー効率は上がります。 88 モブプロや DS などで意思決定者がその場にいると 顧客 CEO 開発者 Review Work Use & Feedback Work PM 暇な人は出てくるがリードタイムは短くなる (リソース効率性は落ちる) Review 暇 暇
  89. 89. 89 プロセス改善と Ops が組み合わさると…
  90. 90. 90 Ops を自動化すれば価値提供までの時間が更に短くなる 顧客 System 開発者 Work 待機 Use & Feedback Work System より短く!
  91. 91. 91 Facebook は 2 ~ 3 時間ごとにリリース可能で 安全な実験環境を提供
  92. 92. • Infer / AL • Buck • Watchman • Flow • One World • Etc, etc, 一部オープンソース。その他表に出ていないものもたくさん… 92 Facebook のプロセスを支える社内ツール
  93. 93. 93 様々な業務のフローも DevOps 的な発想と技術で フロー効率的にできるのでは?
  94. 94. 94 (例) ユーザーサポートの Ops
  95. 95. Wufoo では 50 万人のユーザーと 500 万人のフォーム利用者に対して、たった 10 人で 以下のような SDD (サポートを中心とした開発) を行っていた。 95 Wufoo の Dev によるサポートの改善 10 人中 1人 はシフト制でサポート担当 専属となる 毎週必ず 4~8 時間 ユーザーと直接対話するよ うに義務付け 開発時間の 30% をサポート用の内部ツール の開発に充てていた 毎週 400 の問題と 800 のメー ルに対応できていた。そして 9 時から 21 時までの通常のレス ポンスタイムは 7 ~ 12 分、 21 時以降は1時間程度、週末 も 24 時間以内にレスポンスし ていた。 ユーザーとの直接のコミュニ ケーションがプロダクトを良く する。報告書やグラフではダメ というルールを課して、サポー トを含むユーザーとの直接対話 を行っていた。 ツールの開発で迅速なサポート ができ、より良いサポートが可 能になるほか、自分たちのサ ポートの時間を減らすことがで きる
  96. 96. Image from Wufoo Lecture startupclass.samaltman.com/courses/lec07/ 96 Wufoo の実績:SDD により右肩上がりの購読者数
  97. 97. 常にサポートと開発を同時に行うことでスケール後も サポートリクエストの量がほぼ変わらず、少人数で対応可能 Image from Wufoo Lecture startupclass.samaltman.com/courses/lec07/ 97
  98. 98. Photo taken by Wufoo Team https://www.flickr.com/photos/wufoo/5169213466/ 98 Support Driven Development By Wufoo
  99. 99. 99 やってた
  100. 100. 100 DevOps を参考にしながら エンジニアが担当の幅を広げて 淀みのない xOps のフローを作る
  101. 101. 101 1.ワークフローを高速にする (フローの原則) 2.フィードバックフローを実 現する (フィードバックの 原則) 3.企業文化を生み出す (継続 的な学習と実験の原則)
  102. 102. 102 1.ワークフローを高速にする (フローの原則) 2.フィードバックフローを実 現する (フィードバックの 原則) 3.企業文化を生み出す (継続 的な学習と実験の原則)
  103. 103. カンバンのコアプラクティス 1. 見える化 2. WIP の制限 3. 流れの管理 4. ポリシーの明治 5. フィードバックループの実現 6. コラボレーティブな改善と実験的な進化 103 とりあえず最初に見える化
  104. 104. http://gihyo.jp/dev/column/01/devops/2017/value-stream-mapping 104 例)様々な業務でバリューストリームマッピングから
  105. 105. 105 ただ流れに関する 「プル」と「モノと情報の流れ」 について少しだけ解説
  106. 106. 106 「プル」の概念
  107. 107. https://www.slideshare.net/i2key/xpjug 107
  108. 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. 109 「モノと情報の流れ」の概念
  110. 110. モノの流れは左から右へと流れていき、顧客に購入されて届きます。 110 モノの流れ(作業の流れ) モノの流れ モノの流れ
  111. 111. しかし実際には、どの顧客が何をいつ、どれぐらい欲しいかという情報に 応じてモノづくりを始めると効率がいいはずです(ニーズからプルする)。 111 情報の流れは顧客から始まる モノの流れ 情報の流れ 情報の流れは逆(ニーズからプル)
  112. 112. しかし現代社会において、顧客の本当に欲しいものというのはなかなか分 かりません(顧客自身も分かっていないことが多くあります)。 112 しかし顧客の真のニーズが分からないことが多い 顧客が 本当に 欲しい もの 情報の流れ モノの流れ
  113. 113. そこでデザイン思考などが注目されています。 113 デザイン思考やリーンスタートアップに注目が集まる 顧客が 本当に 欲しい もの 情報の流れ モノの流れ デザイン思考 リーンスタートアップ
  114. 114. 114 でもそもそも Ops が効率的でなければ勝てない 顧客が 本当に 欲しい もの 情報の流れ モノの流れ Ops
  115. 115. 115 全体を効率化する 顧客が 本当に 欲しい もの 情報の流れ モノの流れ プルに対して、全体を効率化する
  116. 116. This is Lean より 116 フローを妨げるボトルネックはどこ?
  117. 117. 顧客に対する価値を最大化できるように、その流れを淀みなくすることを考えてみる。 117 “価値の流れ” を妨げる場所を見つけて広くする 流れを広く、太くする 流れが太くならない原因 の例 • ニーズの理解の間違い • リソース不足 淀みが発生する原因の例 • 意思決定の遅さ • チームコミュニケー ションによる淀み • チャネルの非効率化 • 調達の非効率
  118. 118. Photo by Yesicavaldez https://commons.wikimedia.org/wiki/File:Michael_porter.jpg 118 価値提案は、戦略をつくる要素 のうち、社外の顧客に、つまり ビジネスの需要サイドに目を向 ける要素である。これに対して バリューチェーンは社内の業務 に焦点をあてる。このように戦 略は、事業の需要サイドと供給 サイドを一つにまとめるという、 統合的な性質がある。 - Michael Porter エッセンシャル版 マイケル・ポーターの競争の 戦略 (ジョアン・マグレッタ著)
  119. 119. 戦略を考えるとき、戦略論の大家である Michael Porter の考え方を活用して、「独自の 価値提案」「独自の価値の作り方」をまず考えることをお勧めします。 119 戦略では「価値」と「作り方」の 2 つを考える 独自の 価値 提案 独自の 価値の 作り方
  120. 120. 120 独自の 価値 提案 独自の価 値の 作り方 顧客 (需要) サイド 社内 (業務/供給) サイド 価値提案は「顧客サイド」 価値の作り方は「社内サイド」 にそれぞれ対応しています
  121. 121. 121 独自の 価値 提案 独自の価 値の 作り方 何を作るか どう作るか 言い方を変えれば 「何を作るか」と「どう作るか」です
  122. 122. 122 独自の 価値 提案 顧客 (需要) サイド 社内 (業務/供給) サイド まずは顧客サイドのほうが重要なので 需要サイドの価値提案の構築を考えます
  123. 123. 123 独自の価 値の 作り方 どう作るか しかし同時に「どう作るか」を考えなければ 戦略とは言えません
  124. 124. 124 「どう作るか」の Ops 部分で IT を活用していく
  125. 125. 要件定義 基本設計 詳細設計 コーディン グ 単体テスト 結合テスト システムテ スト 125 たとえば開発の流れ (V 字モデルを参照) 開発の流れは以下のようになっています。
  126. 126. 要件定義 基本設計 詳細設計 コーディン グ 単体テスト 結合テスト システムテ スト 126 少しだけ視野を広げて見ると 開発 運用 マーケティ ング セールス カスタマー サクセス サポート 開発の後に様々な付加価値活動があります。
  127. 127. 要件定義 基本設計 詳細設計 コーディン グ 単体テスト 結合テスト システムテ スト 運用 127 DevOps は Dev の後工程を統合 開発 運用 マーケティ ング セールス カスタマー サクセス サポート DevOps は流れの中の二つを統合したものと言えます。 DevOps フローの高速化とフィードバックループと継続的改善の文化
  128. 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. 129 その後うまくいったとして…
  130. 130. 130 (例) 肺がんの画像診断で 検出率が 99% になった!
  131. 131. 131 でもどうやって 認識率 98.9% の他社競合と 差別化するの?
  132. 132. 132 ちょっとだけ視野を広げて見てみると… 開発 運用 マーケティ ング セールス カスタマー サクセス サポート 開発したものの価値はその後ろの工程で決まることがあります。
  133. 133. 133 そして xOps の時代だと… 開発 運用 カスタマー サクセス 開発と運用の先に各領域のビジネス機能があり、それぞれがつながってい るのが xOps と考えると… 開発 運用 サポート 開発 運用 セールス 開発 運用 マーケ フィードバックループと継続的な改善 フィードバックループと継続的な改善 フィードバックループと継続的な改善 フィードバックループと継続的な改善
  134. 134. 134 たとえばカスタマーサクセスでの新しい潮流として… 開発 運用 カスタマー サクセス 開発 運用 サポート 開発 運用 セールス 開発 運用 マーケ
  135. 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. 136 エンジニアの職責が 一歩広がっている? (ビジネスモデルにもよりますが)
  137. 137. 137 xOps 改善を始めるのは、 既にモデルがはっきりしていて 顧客への価値に近いところから (RevOps, カスタマーサクセス等)
  138. 138. 価値をどこに置くかを決めるのはプロダクトマネジメントの仕事です。 138 価値を決めなければ流れの行き先が決まらない 顧客 への 価値 提供 情報の流れ モノの流れ プロダクトマネジメント
  139. 139. 139 エンジニアが プロダクトマネージャーになって 顧客への価値の流れを 制御するのも一つの手
  140. 140. 140 その他のサポート系 Ops も同様にフローで考える 開発 運用 マーケティ ング セールス カスタマー サクセス サポート 人事 法務 調達
  141. 141. LawGeex が 5 種類の NDA を AI と人間にレビューさせたところ、AI の ほうが 94% の精度を出し、時間は人間に比べて 212 倍早かった。 https://blog.lawgeex.com/ai-more-accurate-than-lawyers/ 141 例)法務文章のレビューを正確かつ迅速に (Feb, 2018)
  142. 142. https://medium.com/salsa-silicon/10-todays-hr-tech-landscape-a910ab0a1d4f 142 HR Tech の台頭による 自動化の可能性
  143. 143. 143 エンジニアが人事になれば もしかすると Ops の改善も…?!
  144. 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. 145 エンジニアが 様々な Ops を継続的に効率化する
  146. 146. 146 トイル (toil) 手作業で繰り返し行われ、自動化 することが可能であり、戦術的で 長期的な価値を持たず、作業量が サービスの成長に比例するといっ た傾向を持つもの
  147. 147. 147 エンジニアなら 様々な業務のオペレーションで 流れを妨げるトイルを撲滅できる (ときもある)
  148. 148. 148 こういうツールでの自動化だけでも効果あり
  149. 149. 149 その結果…
  150. 150. • 開発費用が 1 億ドルから 5,500 万 ドルに減少 • サポートする製品数が 140% 増加 • イノベーションのために使えるキャ パシティが 8 倍に (5% から 40% に) 150 DevOps の効果: HP のケーススタディ
  151. 151. 151 エンジニアが 会社の Ops を変えて 次の成長へ挑戦できる キャパシティを増やす
  152. 152. 152 エンジニアが 次の成長の原動力になる
  153. 153. • エンジニア出身のカスタマーサクセス • エンジニア出身の人事 • エンジニア出身の経理 • エンジニア出身のマーケター • エンジニア出身の…… 153 ソフトウェアエンジニア出身の〇〇担当を増やす
  154. 154. 154 ただコードを書く量は減ります… (なので場合によってはお勧めできないかも…)
  155. 155. 155 さらに社内のツールが 新規事業やスタートアップになる 可能性もある
  156. 156. ボーイング時代のニーズをベースに開発。 156 Rescale: HPC ソフトウェアと計算資源の AWS
  157. 157. 157 社内ツールが 独立して スタートアップに (Phacility)
  158. 158. 158 何より、改善されたプロセスは 一朝一夕には真似できない 競争優位になる
  159. 159. 159https://www.slideshare.net/kdmsnr/lean-enterprise-20170719
  160. 160. 160https://www.slideshare.net/kdmsnr/lean-enterprise-20170719
  161. 161. 161https://www.slideshare.net/kdmsnr/lean-enterprise-20170719
  162. 162. 162 継続的な改善は裏切らない
  163. 163. 163 各領域のプロセスの流れの中に エンジニアの力を
  164. 164. 164 ただし
  165. 165. 165 早すぎる最適化は 諸悪の根源である By Donald Knuth
  166. 166. 166 統合はある時点 では競争上不可 欠だが、後には 競争上の障害と なるのだ 競争上、統合が優 位となる地点と非 統合が優位となる 地点は、ときとと もに間違いなく移 動する
  167. 167. 目標設定 Objective 167
  168. 168. 168 xOps は 技術論と組織論の組み合わせ
  169. 169. https://www.slideshare.net/dragan10/hb-study-74-site-reliability-engineering 169 SRE 本の翻訳者の玉川さんの解説スライド でも「技術論よりも組織論」
  170. 170. 170 継続的な改善と安定的な運用の 両方を同一チームで 実現するために考えるべきこと
  171. 171. 171 メトリクスの設定
  172. 172. どうやって共通ゴールを持たせるかが課題 • DevOps だと開発と運用でだいたいトレードオフが生じる • 新しい機能をリリースしたいけれど安定性が…等 • xOps でも IT とビジネスのトレードオフが生じる • でも従来通りそれぞれ別の KPI を持たせたらサイロ化し て意味がない • しかし売上をそのまま xOps に持たせると破綻しそう 172 Objective / KPI 設定の難しさ
  173. 173. 173 しかし Flow も Ops も Objective 次第なところもあり 避けて通れない (xOps は単純な自動化だけではダメ)
  174. 174. 174 (解決例) SRE における エラーバジェット
  175. 175. 関係各所の共通ゴールを持てるようなメトリクス設定が必要に 例) • エラーバジェット (SRE) エラーバジェットの範囲内で新しい挑戦ができるように • 遅延コスト (CD3: Cost of Delay Divided by Duration) 緊急性と価値を組み合わせたもの などなど…(模索中) 175 Ops 時代の Objectives の例
  176. 176. 176 エラーバジェットが 設定できるのも ビジネスとして適切な SLO (Service Level Objective) が定められるからこそ
  177. 177. 177 この種の KPI の設定ができるのは ビジネス全体に責任を持つ人で、 かつエンジニアリングが分かる人
  178. 178. 178 さらにメトリクスの追跡の自動化 にもエンジニアが必要
  179. 179. • Ops の発展により、売上に近い KPI を Dev が持てる時代に • ただしもちろん売上には関わらないままの選択もあり • 関わればその分、ビジネスにおいてエンジニアは責任と自由 を持てる傾向にある 179 Dev がビジネスゴールを持つべきかどうか?
  180. 180. https://www.slideshare.net/i2key/devsumib 180 ビジネス貢献が可視化しやすいとエンジニア文化に
  181. 181. 181 大企業ではなかなかできない xOps が スタートアップならできるかも
  182. 182. まとめ 182
  183. 183. 今日は新規事業を育てるための xOps、流れ、目標設定について 話しました。 183 今日の 3 つのトピック 1. xOps 2. 流れ (Flow) 3. 目標設定 (Objective)
  184. 184. 184 エンジニアがスタートアップの 成長の原動力になる日 = エンジニアが一歩他の領域に 踏み出して Ops を改善し始める日
  185. 185. 185 エンジニアがスタートアップの 成長の原動力になる日 = 今日、というか昨日 (から Ops を継続的改善しているところが強い)
  186. 186. 186 今日の End Action の提案 エンジニアの皆さんへ • エンジニアが色々な領域で活 躍できるチャンスが来てるの で、ちょっとだけ担当の視野 の範囲を広げてみませんか • チャンスが見つかればキャリ アの幅が広がるし、起業のア イデアにつながるかも ビジネスサイドの皆さんへ • Ops の改善が持続的な成長 の鍵 • 売上に近いところに IT とエ ンジニアによる Ops 改善を • エンジニアの皆さんに機会を チャンスを与えて、エンジニ ア視点での Ops の改善機会 の発見をしてみませんか
  187. 187. 187 振り返ってみれば…
  188. 188. http://www.visualcapitalist.com/chart-largest-companies-market-cap-15-years/ 188 時価総額 Top 5 はデジタルプロダクトを持つ企業
  189. 189. 189 Digital Product Wins!
  190. 190. http://www.visualcapitalist.com/chart-largest-companies-market-cap-15-years/ 190 と同時に、最高のデジタルオペレーションを持つ企業?
  191. 191. 191 Digital Operation Wins!
  192. 192. 192
  193. 193. イノベーションのジレンマを書いたクリステンセンは組織の能力を「資源」「プロセス」 「価値基準」の 3 つに分解しています。 193 クリステンセンによる組織の「能力」の分解 資源 Resource プロセス Process 価値基準 Value
  194. 194. 3つに含まれるものの例は以下のとおりです。 194 クリステンセンによる組織の「能力」の分解 資源 Resource プロセス Process 価値基準 Value 人材、設備、技術、 情報、資金、関係 性など 意思決定、意思伝 達、資源配分、連 携など 優先順位をつける ための判断基準、 自らに課す制約
  195. 195. 195 戦略を考える上ではつい資源に目を向けがち 資源 Resource プロセス Process 価値基準 Value
  196. 196. しかし重要なのは資源だけではありません。クリステンセンは能力が徐々にプロセスや価 値基準へ移動することを指摘しています。 196 資源だけでは不十分で、プロセスや文化に能力が宿る 資源 Resource プロセス Process 価値基準 Value
  197. 197. 197 「プロセスを信じよ」 ピクサーの二大原則の一つ
  198. 198. プロセスが企業文化を作っていくところが多々あると思っています。 198 資源だけでは不十分で、プロセスや文化に能力が宿る 資源 Resource プロセス Process 価値基準 Value
  199. 199. 199 もしプロセスや Ops を作るところに エンジニアが加わることが多くなれば エンジニアが企業文化を作る時代に
  200. 200. https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0 200
  201. 201. 201 Digital Culture Wins!
  202. 202. 202 スタートアップなら 理想の Culture を作れる
  203. 203. イノベーションのジレンマを書いたクリステンセンは組織の能力を「資源」「プロセス」 「価値基準」の 3 つに分解していて、その中の二つにもエンジニアは貢献ができます。 203 エンジニアが組織の能力を決める時代に 資源 Resource プロセス Process 価値基準 Value エンジニアがプロセスと文化を作る
  204. 204. 204 最後に エンジニアリング (工学) とは
  205. 205. 205 工学とは数学と自然科学を基礎と し、ときには人文社会科学の知見 を用いて、公共の安全、健康、福 祉のために有用な事物や快適な環 境を構築することを目的とする学 問である。
  206. 206. 206 工学とは数学と自然科学を基礎と し、ときには人文社会科学の知見 を用いて、公共の安全、健康、福 祉のために有用な事物や快適な環 境を構築することを目的とする学 問である。
  207. 207. 207 エンジニア同士、 有用な事物を作るために いろいろな知見を活用しながら 社会をより良くしていければと 思ってます
  208. 208. 208 まだまだ道半ばですが 一緒に頑張れれば嬉しいです (おわり:何かあればお声がけください)

×