More Related Content
Similar to DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive (20)
More from Tokoroten Nakayama (20)
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
- 2. 自己紹介
• ところてん
• @tokoroten
• 株式会社NextInt 代表
• 怪文章職人・インターネット芸人
• 最近のお仕事とか
• 謎の講演とかワークショップ業
• 機械学習顧問(2社)
• モバイルミドルウェア企業
• データ分析企業
• 新規事業コンサルティング(1社)
• 業務改善コンサルティング(1社)
• ゲームディレクター(1社)
↓共著 ↓寄稿↓共著
2
- 6. Why Software Is Eating The World
http://sora.rainbowapps.com/software
https://www.wsj.com/articles/SB100014240531119034809045765122509156294606
- 7. ソフトウェアが全てを飲み込む
• ソフトウェアによって置き換わったもの
• 電話 → スマートフォン
• カメラ → デジカメ → スマホ
• レンタルビデオ → Youtube、NetFlix
• 映画 → Pixer
• 書店 → Kindle
• タクシー → Uber
• 地図 → Google Map
• 小売店 → Amazon
• 財布 → 電子決済アプリ
• 全ての産業でソフトウェアによる変革が進む
• これから先は?医療?教育?銀行?
7
- 8. President Obama asks America to learn computer
science
https://www.youtube.com/watch?v=6XvmhE1J9PY
8
- 27. DevOpsの初出
• 2009年、Velocity2009
• Flickrの事例
• 「DevとOpsが協力することで、1
日に10回のデプロイが可能にな
る」
• やっていること
• インフラの自動化
• バージョンコントロール
• ビルドとデプロイが1ステップ
• 監視の自動化、IRCにログ
• etc
https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
27
- 30. 収益の主体がOpsに
• ビジネスがサブスクリプション化
• Netflix、YouTube Premium
• Amazon Prime、Kindle Unlimited
• 各種SaaSアプリケーション
• コマツ、KOMTRAX
• GE、航空機のエンジンのサブスクリプション
• Opsがよければユーザは契約を続ける
• =品質が高ければLTVは上昇する
• 満足度が高い顧客は、新規顧客を連れてくる
• 口コミで評判を広めてくれるので、広告が効きやすくなる
• =品質が高ければCPAが大幅に下がる
30
- 31. LTV>CPA の世界
• LTV
• Life Time Value
• 一人当たり顧客生涯価値
• CPA
• Cost per Acquisition
• 顧客一人当たり獲得単価
• LTV > CPAの世界
• 利益=LTV-CPA
• これが実現できていると、広告を打てば打つだけ利益が出る状態
• クラウドのスケールアウトと組み合わせて、急激な顧客拡大が可能になる
• Opsが人手で事業拡大に時間とコストがかかるとこうはいかない
31
- 48. 余談)少しずつ壊れていく分業
• 最初はうまくいく
• なぜ部門が分割されたか皆が知っている
• 隣の部門をカバーするように動く
• 評価制度が狂いはじめる
• 問題を分割したことによって、
評価が分かりやすい数字に置き換えられる
• 部門の数値目標が一人歩きを始める
• 個人の評価も同様の数値目標で行われるようになる
• 考える人が居なくなる
• 与えられた評価基準を満たすように皆が動くようになる
• 隣の部門の問題は誰も知らない
• 部署の間に落ちたボールは誰も拾わなくなる
48
- 49. クラウドの登場
• 1999年 VMWare
• x86の完全仮想化
• 2000年 FreeBSD jail
• 1台のPC内のユーザを仮想的にアイソレーションする
• 2003年 Xen
• 2005年 OpenVZ
• 2006年 AWS EC2
• APIでキックしてインスタンスを立ち上げる
• 2009年 FlickrがDevOpsの講演
詳しい話は緑の恐竜に聞いてください49
- 58. Error Budget
• SLO(Service Level objectives)に基づくError Budgetを設定
• DevとSREは Error Budget を共通の評価指標に
• Devも稼働率を改善するのに協力する
• サービスがダウンすると、その分 Error Budget が削られる
• Error Budget が尽きるとデプロイできなくなる
• Error Budget が尽きそうになったら、デプロイの間隔を下げる
• その分、コードレビューやテストを厚くする
• サービスの種類によって、設定されるBudgetの
大きさは異なる
• 安定性が重要なtoBサービスは小さく
• 改善速度が重要なtoCサービスは大きく
• プロダクト性質に応じて柔軟に変更する 58
- 60. 日本の労働法の歴史的経緯1
• 明治時代
• 工場労働者は低賃金
• 給与を上げるには、スキル身に着けて転職
• 大正から太平洋戦争
• 熟練工の長期雇用をしたい
• 社内で職工を育成、長期雇用が前提に
• 年功賃金制、年功序列制の発生
• 生活給思想が広まる
• 若年層に過度な高給を与えても飲食で浪費してしまう
• 壮年層には、家族を扶養するために多くの給与を与えるべきだ
• 賃金統制令、年功序列が法律で規定される
60
- 61. 日本の労働法の歴史的経緯2
• 戦後、電産型賃金体系
• 本人の年齢+扶養家族数をベースに生活給を決定
• これに職能給や勤続給を加えた年功賃金制度
• 占領軍、政府、経営はこれに反対
• 1950年代、職能給の確立
• 技術革新により新規工場が設立、大規模な配置転換が必要に
なり、労働者は給与が維持されること条件にこれを労使合意
• 給与の維持=職能の維持、仕事が代わっても「職能」は変化しない
• これにより、労働市場からの人材調達ではなく、
社内の配置転換による雇用調整がメインになる
• 「勤続年数が長くなれば潜在能力が伸び、潜在能力があるか
ら配置転換しても大丈夫」というのが建前
61
- 63. 日本の労働法の歴史的経緯4
• 1985年 男女雇用機会均等法
• 男性採用・女性採用のラベルを張替えて対応
• 男性採用→総合職
• (家族を養うので)職能給、年功序列で昇給
• コア業務、配置転換あり
• 女性採用→一般職
• (結婚までの腰掛なので)昇給しない
• 事務業務、配置転換なし
• 日本企業は総合職の配置転換によりアジリティを
確保していた
63
- 65. 余談:追い出し部屋は何故できるのか?
• 日本の給与制度と、労働法の判例が合わさった結果の闇
• 解雇、不当な減給は禁止、でも配置転換はOK
• 配置転換をして、自主的に進退を考えるように促すことはOK
• 職能が上がってしまって、給与が上がり過ぎてしまった人が生まれる
• 職能は「潜在能力(笑)」なので、計測が難しく、年功で上がってしまうことが多い
• 職能は「潜在能力(笑)」なので、下げることが難しい
• 職能は実際に仕事ができるかどうかは別
• 職能と役職はリンクすることが多いが基本的には独立
• 職能は高いが役職がない、という人が生まれる
• リンクさせる必要がある場合、解雇か降格をする必要があるが、これは難しい
• 「異動してきたばかりだから、出来なくても仕方ない、そのうち出来るようになるよ…」
65
- 71. 分社化される大企業
• 労働者は「同一職能・同一賃金」を期待する
• 経営者は「同一労働・同一賃金」にしたい
• これを両立させるために、事業・職種ごとに分社化される
• グループ会社間で異動させることで、給与を調整できる
• 大きく給与を下げるのは判例的にはNG
• どこの会社で最初に雇用されたかで給与差が生まれる
• 親会社から送り込まれた天下りおじさんが自分の倍の給与をもらっておりモチベダウン
• 大企業、本社指向で、そこに人が集まる
• あと、ポストを用意したい
• 人件費圧縮として行ってきた子会社戦略がDevOps、DXの足枷に
• 部署の壁よりも厚い、会社間の壁が
71
- 75. 例)東京都 新型コロナウィルス対策サイト
• Github上でOSSで運営
• https://github.com/tokyo-
metropolitan-gov/covid19
• Vue+Nuxt.js+Netlify
• SSR かつ SPA
• 一般からのPullRequestの
受付
• SIerはこの速度感でサービ
ス提供できるか?
75
https://stopcovid19.metro.tokyo.lg.jp/
- 80. How Not to Land an Orbital Rocket
Booster
80
https://www.youtube.com/watch?v=bvim4rsNHkQ
- 82. Error Budgetは失敗を許容する
• Error Budgetは開発者とSREの間でのインセンティブに使われる
• 信頼性100%はあり得ない、誰でも、どんなシステムでも失敗する
• Budgetが尽きない限り失敗してもよい
• Budgetを設定することで、信頼性を上げすぎて、過剰コストになることを防止する
• 失敗が起こることを前提に組織を回すことができる
• 失敗をゼロイチで捉えない
• SLAの場合、SLAを割ったかどうかでしか評価されない
• SLAを下回ったから、謝罪、返金、社長が謝る、終わりの組織は多い
• Budgetにして監視をすることで、連続値になり、
意思決定を柔軟に変えることができる
82
- 83. 学習姿勢と心理的安全性
• How Google Works ラーニングアニマルを採用す
る
• 自分の能力は変わらないと考えていると、その自己イメー
ジを維持するために「到達目標」を設定する。一方、しな
やかマインドセットの持ち主は「学習目標」を設定する。
• 学ぶこと自体が目標になると、くだらない質問をしたり、
答えを間違えたりしたら自分がバカに見えるのではないか
などと悩んだりせず、リスクをとるようになる。
• ラーニング・アニマルが目先の失敗にこだわらないのは、
長い目でみればそのほうが多くを学び、さらなる高みに上
れることを知っているからだ。
- 85. 生産性には5つの要素が必要
• 次の5つが上から順に重要
• 心理的安全性(Psychological Safety)
• 相互信頼(Dependability)
• 構造と明確さ(Structure & Clarity)
• 仕事の意味(Meaning)
• 影響(Impact)
• 真に重要なのは「誰がチームのメン
バーであるか」よりも「チームがどの
ように協力しているか」であった※
※「Googleに採用されている人」という観測バイアスがかかっているので注意
https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/
- 86. 心理的安全性の計測指標
• チームの中でミスをすると、たいてい非難される。
• チームのメンバーは、課題や難しい問題を指摘し合える。
• チームのメンバーは、自分と異なるということを理由に他者を拒絶す
ることがある。
• チームに対してリスクのある行動をしても安全である。
• チームの他のメンバーに助けを求めることは難しい。
• チームメンバーは誰も、自分の仕事を意図的におとしめるような行動
をしない。
• チームメンバーと仕事をするとき、自分のスキルと才能が尊重され、
活かされていると感じる。
https://rework.withgoogle.com/print/guides/5721312655835136/
https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/foster-psychological-safety/
- 92. HRT(謙虚・尊敬・信頼)
• 優れた開発チームでは、HRTの価値が大切にされている
• 謙虚 Humility
• 世界の中心は君ではない。
君は全知全能ではないし、絶対に正しいわけでもない。
常に自分を改善していこう。
• 尊敬 Respect,
• 一緒に働く人のことを心から思いやろう。
相手を一人の人間として扱い、その能力や功績を高く評価しよう。
• 信頼 Trust
• 自分以外の人は有能であり、正しいことをすると信じよう。
そうすれば、仕事を任せることができる。
• HRTは学び続け、成長し続けるための姿勢
• HRTの逆を考えてみればよい、人から学ぶことが出来なくなる
• HRTを持つことで同僚の行動に対して正しく振る舞える
• 同僚は安心して自己を開示し、良い議論が行えるようになる
- 94. 余談)IPOでレガシー化するベンチャー企業
• 売り上げを増やすために商品を増やす
• 商品を増やすために人を一気に増やす
• 人材レベルが低下して、大本営マネジメントが始まる
• 市場に対して弱気を見せると株価が落ちる
• 市場への強気のアピールは社員の自己洗脳につながる
• 対外的なポストモーテムは株価に影響が出ると思い込んでしまう
• 社内で失敗の分析や、ネガティブな発言は禁忌となる
• 失敗から学ばなくなる
• 監査対応でレガシーなシステムが必要になってしまう
• 会計監査、内部統制
• 外部の会計会社が慣れ親しんだワークフローを要請される
• チェックリスト地獄、監査がレガシー
• それをビジネスに組み込んでしまうとシステムが複雑化、レガシー化
94
- 97. 大企業はどうしているのか?
• 既存ビジネスを変更するコストは激烈にヤバイ
• 新しい子会社を作るのは簡単
• 新しい人事評価制度、採用ラインで運用
• 最近できたRidgelinez社とか、傍からはそう見える
• 既存ビジネスはキャッシュマシンとして現状維持、
新規子会社でチャレンジをする
• 現状に危機感を覚えたら、こういうチャレンジをして
いる子会社への転職・転属・出向を考えるのもアリ
• 富士通クラウドテクノロジーの人にこの辺の話を聞
いてみたい
• 富士通標準の業務プロセスをどうやって潰して、
DevOps体制を構築した?
• どのように人材を雇用した? 評価した?
• 次回の富士通 Tech Liveとかで話してもらったら面白
いんじゃない? 知らんけど
97
https://pr.fujitsu.com/jp/news/2020/01/30.html
- 98. 余談:DXできてない企業だと思う事例
• 激ヤバドメイン
• なんで富士通が2回? 階層おかしくない?
• fujitsu.com/jp/ の下にあるべきなのでは?
• コンウェイの法則
• システム設計は組織構造を反映したものになる
• 社内政治の壁がドメイン名から透けて見える
• 公式ウェブサイトを改修する権限をもらうよりも、
サブドメインを切るほうが楽というのは異常
• 心理的安全性
• 激ヤバドメインにたいしてストップをかけられる
人がいなかったという機能不全感
https://twitter.com/tokoroten/status/1228559664163385346
98
- 99. 参考資料
• 闇のDevOps DevOpsと業績評価
• https://medium.com/@tokoroten/5aff8b60f589
• xOps: エンジニアがスタートアップの成長の原動力となる日
• https://www.slideshare.net/takaumada/xops
• 技術の創造と設計
• https://amzn.to/2VPFaYX
• 日本の雇用と労働法
• https://amzn.to/2vxJPDY
• How Google Works
• https://amzn.to/2TB1J0s
• SRE サイトリライアビリティエンジニアリング
• https://amzn.to/3cmkvkS 99