SlideShare a Scribd company logo
Submit Search
Upload
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
Report
Share
Tokoroten Nakayama
雑用 at 株式会社NextInt
Follow
•
464 likes
•
122,211 views
1
of
99
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
•
464 likes
•
122,211 views
Report
Share
Download Now
Download to read offline
Business
2020/03/03 に富士通本社で行われた、富士通TechLiveに発表資料です。 コロナウィルスの影響で、リモート発表になりましたが、当日は800人以上の方に同時視聴していただきました
Read more
Tokoroten Nakayama
雑用 at 株式会社NextInt
Follow
Recommended
ビジネスパーソンのためのDX入門講座エッセンス版 by
ビジネスパーソンのためのDX入門講座エッセンス版
Tokoroten Nakayama
52.6K views
•
26 slides
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質) by
ラボラトリーオートメーションのためのソフトウェア思想教育(非プログラマ―が知っておくべきプログラミングの本質)
Tokoroten Nakayama
20.1K views
•
72 slides
エンジニアの個人ブランディングと技術組織 by
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
23.3K views
•
40 slides
心理的安全性の構造 デブサミ2019夏 structure of psychological safety by
心理的安全性の構造 デブサミ2019夏 structure of psychological safety
Tokoroten Nakayama
188.3K views
•
84 slides
なぜコンピュータを学ばなければならないのか 21世紀の君主論 by
なぜコンピュータを学ばなければならないのか 21世紀の君主論
Tokoroten Nakayama
92.1K views
•
58 slides
世界一わかりやすいClean Architecture by
世界一わかりやすいClean Architecture
Atsushi Nakamura
47.1K views
•
77 slides
More Related Content
What's hot
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話) by
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
Tokoroten Nakayama
9.4K views
•
34 slides
開発速度が速い #とは(LayerX社内資料) by
開発速度が速い #とは(LayerX社内資料)
mosa siru
61.4K views
•
18 slides
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ by
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
54.7K views
•
243 slides
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019 by
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
165.4K views
•
67 slides
TLS, HTTP/2演習 by
TLS, HTTP/2演習
shigeki_ohtsu
13.1K views
•
129 slides
マイクロにしすぎた結果がこれだよ! by
マイクロにしすぎた結果がこれだよ!
mosa siru
132.6K views
•
32 slides
What's hot
(20)
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話) by Tokoroten Nakayama
事業の進展とデータマネジメント体制の進歩(+プレトタイプの話)
Tokoroten Nakayama
•
9.4K views
開発速度が速い #とは(LayerX社内資料) by mosa siru
開発速度が速い #とは(LayerX社内資料)
mosa siru
•
61.4K views
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ by Yoshiki Hayama
「のどが渇いた」というユーザーに何を出す? ユーザーの「欲しい」に惑わされない、本当のインサイトを見つけるUXデザイン・UXリサーチ
Yoshiki Hayama
•
54.7K views
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019 by Tokoroten Nakayama
チャットコミュニケーションの問題と心理的安全性の課題 #EOF2019
Tokoroten Nakayama
•
165.4K views
TLS, HTTP/2演習 by shigeki_ohtsu
TLS, HTTP/2演習
shigeki_ohtsu
•
13.1K views
マイクロにしすぎた結果がこれだよ! by mosa siru
マイクロにしすぎた結果がこれだよ!
mosa siru
•
132.6K views
Python 3.9からの新定番zoneinfoを使いこなそう by Ryuji Tsutsui
Python 3.9からの新定番zoneinfoを使いこなそう
Ryuji Tsutsui
•
6.9K views
分散システムについて語らせてくれ by Kumazaki Hiroki
分散システムについて語らせてくれ
Kumazaki Hiroki
•
119.4K views
【メタサーベイ】基盤モデル / Foundation Models by cvpaper. challenge
【メタサーベイ】基盤モデル / Foundation Models
cvpaper. challenge
•
16.4K views
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein by Tokoroten Nakayama
心理的安全性と、Veinの紹介 Psychological safety and introduction of Vein
Tokoroten Nakayama
•
161K views
本当は恐ろしい分散システムの話 by Kumazaki Hiroki
本当は恐ろしい分散システムの話
Kumazaki Hiroki
•
686K views
フロー効率性とリソース効率性、再入門 #devlove #devkan by Itsuki Kuroda
フロー効率性とリソース効率性、再入門 #devlove #devkan
Itsuki Kuroda
•
48.2K views
Dockerからcontainerdへの移行 by Kohei Tokunaga
Dockerからcontainerdへの移行
Kohei Tokunaga
•
16.6K views
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ by YoheiGibo
「DX完全に理解した」「DXわけがわからないよ」なユーザ企業の方へ
YoheiGibo
•
566 views
暗号技術の実装と数学 by MITSUNARI Shigeo
暗号技術の実装と数学
MITSUNARI Shigeo
•
9.6K views
45分間で「ユーザー中心のものづくり」ができるまで詰め込む by Yoshiki Hayama
45分間で「ユーザー中心のものづくり」ができるまで詰め込む
Yoshiki Hayama
•
50.6K views
ChatGPTは思ったほど賢くない by Carnot Inc.
ChatGPTは思ったほど賢くない
Carnot Inc.
•
4.5K views
「速」を落とさないコードレビュー by Takafumi ONAKA
「速」を落とさないコードレビュー
Takafumi ONAKA
•
55.5K views
Docker Compose 徹底解説 by Masahito Zembutsu
Docker Compose 徹底解説
Masahito Zembutsu
•
61.1K views
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」 by Takuto Wada
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Takuto Wada
•
148.6K views
Similar to DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
[18-A-1] ハッカー中心の企業文化を日本で根付かせる by
[18-A-1] ハッカー中心の企業文化を日本で根付かせる
Hiro Yoshioka
9.7K views
•
49 slides
Hacker centric culture @devlove 110423 by
Hacker centric culture @devlove 110423
Hiro Yoshioka
4.1K views
•
56 slides
Building Hacker Centric Culture in Japan by
Building Hacker Centric Culture in Japan
Hiro Yoshioka
3.2K views
•
58 slides
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~ by
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~
Developers Summit
2.3K views
•
55 slides
楽天の中のわたしと勉強会 by
楽天の中のわたしと勉強会
Rakuten Group, Inc.
3K views
•
29 slides
ハッカー中心の企業文化を日本で根付かせるには。TechLION vol.5 12/14/2011 by
ハッカー中心の企業文化を日本で根付かせるには。TechLION vol.5 12/14/2011
Hiro Yoshioka
1.6K views
•
54 slides
Similar to DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
(20)
[18-A-1] ハッカー中心の企業文化を日本で根付かせる by Hiro Yoshioka
[18-A-1] ハッカー中心の企業文化を日本で根付かせる
Hiro Yoshioka
•
9.7K views
Hacker centric culture @devlove 110423 by Hiro Yoshioka
Hacker centric culture @devlove 110423
Hiro Yoshioka
•
4.1K views
Building Hacker Centric Culture in Japan by Hiro Yoshioka
Building Hacker Centric Culture in Japan
Hiro Yoshioka
•
3.2K views
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~ by Developers Summit
【19-B-1】情シスの中のアーキテクト ~ソフトウェアアーキテクチャを超えて~
Developers Summit
•
2.3K views
楽天の中のわたしと勉強会 by Rakuten Group, Inc.
楽天の中のわたしと勉強会
Rakuten Group, Inc.
•
3K views
ハッカー中心の企業文化を日本で根付かせるには。TechLION vol.5 12/14/2011 by Hiro Yoshioka
ハッカー中心の企業文化を日本で根付かせるには。TechLION vol.5 12/14/2011
Hiro Yoshioka
•
1.6K views
ごった煮じゃNight!vol.1 by Satoshi Furuichi
ごった煮じゃNight!vol.1
Satoshi Furuichi
•
410 views
opensource and accessibility (Dec2000) Part 2 by Takuya Nishimoto
opensource and accessibility (Dec2000) Part 2
Takuya Nishimoto
•
570 views
市場価値を高める仕事のつかみ方 by Daiki Tanoguchi
市場価値を高める仕事のつかみ方
Daiki Tanoguchi
•
1.7K views
Oss magic2 by K5_sem
Oss magic2
K5_sem
•
639 views
Oss magic by K5_sem
Oss magic
K5_sem
•
1.3K views
Deploy Rails Application on Docker with Elasticbeanstalk by aktsk
Deploy Rails Application on Docker with Elasticbeanstalk
aktsk
•
2.2K views
【17-E-1】自動化はどこに向かうのか~まだ開発・運用の自動化で消耗しているの?~ by Masahito Zembutsu
【17-E-1】自動化はどこに向かうのか~まだ開発・運用の自動化で消耗しているの?~
Masahito Zembutsu
•
19.1K views
やりたいことをプロダクトにねじ込む技術とねじ込んだ結果 by KayoMiyata
やりたいことをプロダクトにねじ込む技術とねじ込んだ結果
KayoMiyata
•
649 views
Opensource and Value creation by community by Hiro Yoshioka
Opensource and Value creation by community
Hiro Yoshioka
•
583 views
Xp Terakoya No02 by takepu
Xp Terakoya No02
takepu
•
1.1K views
ドキュメント生成ツールのお話 by Shota Homma
ドキュメント生成ツールのお話
Shota Homma
•
3.1K views
攻める情シス by Kazuki Murahama
攻める情シス
Kazuki Murahama
•
4.9K views
作る人から作りながら運用する人になっていく by Ryo Mitoma
作る人から作りながら運用する人になっていく
Ryo Mitoma
•
1K views
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~ by Shuji Yamada
【Interop Tokyo 2013】 どうする?どうなる?SDN/クラウド時代の運用管理 ~データセンター、クラウド提供事業者の立場から~
Shuji Yamada
•
973 views
More from Tokoroten Nakayama
データマイニングの話詰め合わせ by
データマイニングの話詰め合わせ
Tokoroten Nakayama
17.2K views
•
65 slides
データサイエンティスト養成読本の解説+書き忘れたこと by
データサイエンティスト養成読本の解説+書き忘れたこと
Tokoroten Nakayama
24.4K views
•
18 slides
機械学習の精度と売上の関係 by
機械学習の精度と売上の関係
Tokoroten Nakayama
47K views
•
14 slides
難易度ボラタリティグラフという分析手法 by
難易度ボラタリティグラフという分析手法
Tokoroten Nakayama
258.3K views
•
52 slides
インターネット上の情報発信手段の変遷 情報発信の簡易化 by
インターネット上の情報発信手段の変遷 情報発信の簡易化
Tokoroten Nakayama
14.8K views
•
17 slides
データ分析グループの組織編制とその課題 マーケティングにおけるKPI設計の失敗例 ABテストの活用と、機械学習の導入 #CWT2016 by
データ分析グループの組織編制とその課題 マーケティングにおけるKPI設計の失敗例 ABテストの活用と、機械学習の導入 #CWT2016
Tokoroten Nakayama
29.1K views
•
41 slides
More from Tokoroten Nakayama
(20)
データマイニングの話詰め合わせ by Tokoroten Nakayama
データマイニングの話詰め合わせ
Tokoroten Nakayama
•
17.2K views
データサイエンティスト養成読本の解説+書き忘れたこと by Tokoroten Nakayama
データサイエンティスト養成読本の解説+書き忘れたこと
Tokoroten Nakayama
•
24.4K views
機械学習の精度と売上の関係 by Tokoroten Nakayama
機械学習の精度と売上の関係
Tokoroten Nakayama
•
47K views
難易度ボラタリティグラフという分析手法 by Tokoroten Nakayama
難易度ボラタリティグラフという分析手法
Tokoroten Nakayama
•
258.3K views
インターネット上の情報発信手段の変遷 情報発信の簡易化 by Tokoroten Nakayama
インターネット上の情報発信手段の変遷 情報発信の簡易化
Tokoroten Nakayama
•
14.8K views
データ分析グループの組織編制とその課題 マーケティングにおけるKPI設計の失敗例 ABテストの活用と、機械学習の導入 #CWT2016 by Tokoroten Nakayama
データ分析グループの組織編制とその課題 マーケティングにおけるKPI設計の失敗例 ABテストの活用と、機械学習の導入 #CWT2016
Tokoroten Nakayama
•
29.1K views
ヒューレットパッカード社の社員の離職リスク予測 第一回機械学習ビジネス研究会 #ml_business by Tokoroten Nakayama
ヒューレットパッカード社の社員の離職リスク予測 第一回機械学習ビジネス研究会 #ml_business
Tokoroten Nakayama
•
18.2K views
機械学習ビジネス研究会(未踏研究会) by Tokoroten Nakayama
機械学習ビジネス研究会(未踏研究会)
Tokoroten Nakayama
•
9.7K views
失敗から学ぶデータ分析グループのチームマネジメント変遷 (デブサミ2016) #devsumi by Tokoroten Nakayama
失敗から学ぶデータ分析グループのチームマネジメント変遷 (デブサミ2016) #devsumi
Tokoroten Nakayama
•
47.5K views
失敗から学ぶデータ分析グループのチームマネジメント変遷 by Tokoroten Nakayama
失敗から学ぶデータ分析グループのチームマネジメント変遷
Tokoroten Nakayama
•
25.2K views
プロダクション環境でオンラインで機械学習を動かすにあたってツライ話 #MLCT by Tokoroten Nakayama
プロダクション環境でオンラインで機械学習を動かすにあたってツライ話 #MLCT
Tokoroten Nakayama
•
17.8K views
特徴ベクトル変換器を作った話 #dogenzakalt by Tokoroten Nakayama
特徴ベクトル変換器を作った話 #dogenzakalt
Tokoroten Nakayama
•
11.5K views
特徴ベクトル変換器を作った話 by Tokoroten Nakayama
特徴ベクトル変換器を作った話
Tokoroten Nakayama
•
8.3K views
jubatusのECサイトへの適応 #jubatus_hackathon by Tokoroten Nakayama
jubatusのECサイトへの適応 #jubatus_hackathon
Tokoroten Nakayama
•
17.2K views
スマホマーケットの概要と、マーケティングの失敗例と改善 (アナリティクス アソシエーション 特別セミナー) by Tokoroten Nakayama
スマホマーケットの概要と、マーケティングの失敗例と改善 (アナリティクス アソシエーション 特別セミナー)
Tokoroten Nakayama
•
197.4K views
DAUを評価指標から捨てた会社の話 #tokyowebmining by Tokoroten Nakayama
DAUを評価指標から捨てた会社の話 #tokyowebmining
Tokoroten Nakayama
•
151K views
BattleField3に見る自己表現としてのゲームプレイ by Tokoroten Nakayama
BattleField3に見る自己表現としてのゲームプレイ
Tokoroten Nakayama
•
31.4K views
情報処理とは何か あとbigdataとか by Tokoroten Nakayama
情報処理とは何か あとbigdataとか
Tokoroten Nakayama
•
29.5K views
ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話 by Tokoroten Nakayama
ビッグデータとioDriveの夕べ:ドリコムのデータ分析環境のお話
Tokoroten Nakayama
•
5K views
ソーシャルゲームにレコメンドエンジンを導入した話 by Tokoroten Nakayama
ソーシャルゲームにレコメンドエンジンを導入した話
Tokoroten Nakayama
•
9.4K views
Recently uploaded
【会社紹介資料】イー・フォース株式会社_2023_11.pdf by
【会社紹介資料】イー・フォース株式会社_2023_11.pdf
eForce
61 views
•
39 slides
cluture deck.pdf by
cluture deck.pdf
hiromasa4
42 views
•
44 slides
1ページでわかるTAPP.pdf by
1ページでわかるTAPP.pdf
ssuser615e86
60 views
•
45 slides
企業向け_01BoosterStudio_231126.pdf by
企業向け_01BoosterStudio_231126.pdf
ssusere7a2172
34 views
•
13 slides
Service.pdf by
Service.pdf
Yasuyoshi Minehisa
45 views
•
12 slides
清田軌道工業会社紹介資料230728.pdf by
清田軌道工業会社紹介資料230728.pdf
ymoteki
10 views
•
62 slides
Recently uploaded
(16)
【会社紹介資料】イー・フォース株式会社_2023_11.pdf by eForce
【会社紹介資料】イー・フォース株式会社_2023_11.pdf
eForce
•
61 views
cluture deck.pdf by hiromasa4
cluture deck.pdf
hiromasa4
•
42 views
1ページでわかるTAPP.pdf by ssuser615e86
1ページでわかるTAPP.pdf
ssuser615e86
•
60 views
企業向け_01BoosterStudio_231126.pdf by ssusere7a2172
企業向け_01BoosterStudio_231126.pdf
ssusere7a2172
•
34 views
Service.pdf by Yasuyoshi Minehisa
Service.pdf
Yasuyoshi Minehisa
•
45 views
清田軌道工業会社紹介資料230728.pdf by ymoteki
清田軌道工業会社紹介資料230728.pdf
ymoteki
•
10 views
p02_info 2.pdf by ssuser615e86
p02_info 2.pdf
ssuser615e86
•
11 views
Helpfeelサービス資料.pdf by ssuserb35af3
Helpfeelサービス資料.pdf
ssuserb35af3
•
32 views
スライドショー.pptx by kohsei-hp
スライドショー.pptx
kohsei-hp
•
24 views
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2023年11月号(♯163) by Members_corp
株式会社メンバーズ社内報MEMBUZZ(メンバズ)2023年11月号(♯163)
Members_corp
•
138 views
p02_info 2.pdf by ssuser615e86
p02_info 2.pdf
ssuser615e86
•
19 views
HMS vision.pptx by ssuser6c5c0a
HMS vision.pptx
ssuser6c5c0a
•
27 views
fmx_credential.pdf by kiryutakumi
fmx_credential.pdf
kiryutakumi
•
159 views
slide.pdf by ssuser7664a8
slide.pdf
ssuser7664a8
•
1.3K views
他社会計ソフトからの仕訳インポート(TKC) by Money Forward, Inc.
他社会計ソフトからの仕訳インポート(TKC)
Money Forward, Inc.
•
13 views
個人開発のオープンソースで起業&マネタイズ.pptx by uchi825
個人開発のオープンソースで起業&マネタイズ.pptx
uchi825
•
11 views
DXとかDevOpsとかのなんかいい感じのやつ 富士通TechLive
1.
DXとかDevOpsとかの なんかいい感じのやつ 2020/03/03 富士通 Tech Live 中山ところてん 1
2.
自己紹介 • ところてん • @tokoroten •
株式会社NextInt 代表 • 怪文章職人・インターネット芸人 • 最近のお仕事とか • 謎の講演とかワークショップ業 • 機械学習顧問(2社) • モバイルミドルウェア企業 • データ分析企業 • 新規事業コンサルティング(1社) • 業務改善コンサルティング(1社) • ゲームディレクター(1社) ↓共著 ↓寄稿↓共著 2
3.
今日の経緯 • だいたい、緑の恐竜が悪い 3
4.
注意 • このスライドは緑の恐竜がだいたい悪い • 自分が勉強したことや見聞きしたことが適当にまとまってます •
ポエムであり怪文章です • 本ポエムは「闇のDevOps」というブログ記事を下敷きにして います • https://medium.com/@tokoroten/5aff8b60f589 • だいたい緑の恐竜が悪い、いいね? 4
5.
目次 • ソフトウェアが世界を食らう • DevOpsとは何か? •
日本の労働法とDX/DevOps • DevOpsとメンタル 5
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
9.
• コンピュータ・サイエンスのスキルを身につけることは、皆さん自 身の未来のみならず、私達の国の未来にとっても、大事なことです。 • アメリカという国が最先端であり続けるためには、皆さんのような 若いアメリカ国民に、今後の世界のあり方を変えるようなツールや 技術について学んでもらわねばならないのです。 •
初めからコンピュータ・サイエンスの専門家の人なんていません。 しかし、少しの努力と数学と科学の知識で、誰でもコンピュータ・ サイエンティストになることができます。 • コンピュータは皆さんの未来の大部分を占めることになります。 President Obama asks America to learn computer science 9
10.
余談:オバマ前大統領のスピーチの背景 • 2013年12月に行われた、コンピュータ科学教育週間の応援 • コンピュータ科学教育週間の主催はCode.orgというNPO •
https://hourofcode.com/jp • Hour of Codeというイベントを実施 • 1時間のプログラミングでコンピュータサイエンスに対する理解、興味 を持ってもらうのが目的 • 2013年はアメリカのみならず、170の国や地域から約1500万人が参加、 累計で5億行のプログラムが書かれた • コンピュータサイエンスを通じて「問題解決能力」「論理的思考」 「創造性」をはぐくむことで、21世紀のキャリアパスにおいて成功す る基盤を身につける 10
11.
What Most Schools
Don't Teach https://www.youtube.com/watch?v=nKIu9yen5nc 11
12.
全てはコンピュータに 12
13.
全ての職業にプログラマーが必要 • ポール・グレアム、Yahooに起きてしまったこと http://blog.livedoor.jp/lionfan/archives/52682119.html 13
14.
100の職業でどんな数学が使われるか • When Are
We Ever Gonna Have to Use This? (1996) https://readingmonkey.blog.fc2.com/blog-entry-625.html 14
15.
100の職業でどんな数学が使われるか • コンピュータの利用は82/100の職業で必要 • プログラミングは13/100の職業で必要 •
ただしこれは1996年の書籍 • 現在はもっと比率が上がっている と思われる https://readingmonkey.blog.fc2.com/blog-entry-625.html 15
16.
全ての産業でコンピュータが使われている • コンピュータ無しでの現代の産業は成り立たない • 1996年の書籍でも82/100の職業でコンピュータを使う •
日本の場合 • 工場の情報化は80年代から • 一般オフィスへの浸透は2000年ごろ • 1990年前後と現在を、フィクションの中で比較してみる • 1988 美味しんぼ • 1989 機動警察パトレイバー • 2015 SHIROBAKO • 2016 シン・ゴジラ • 2018 アグレッシブ烈子 16
17.
1988 美味しんぼ • 新聞社のオフィス •
ワープロもなければパソコンもない 17 公開版は画像省略
18.
1989 機動警察パトレイバー ON
TELEVISION • 当時はコンピュータは「電算室」にあるものだった 18 公開版は画像省略
19.
2015 SHIROBAKO • アニメの制作デスクはPC上で仕事をする 19 公開版は画像省略
20.
2016 シン・ゴジラ • 職員(国家公務員)はすべてPCを活用して仕事を行う 20 公開版は画像省略
21.
2018 アグレッシブ烈子 • 経理は全員PCを利用して仕事をしている 21 公開版は画像省略
22.
世界経済の変化(時価総額トップ10) https://finance-gfp.com/?p=2042 https://finance-gfp.com/?p=6595 石油、小売り、電気、通信、タバコ、銀行、薬品 ソフトウェア、ソフトウェア、銀行、医薬品 22
23.
日本経済の変化 https://finance-gfp.com/?p=2042 https://finance-gfp.com/?p=6595 23
24.
余談)石油王には勝てなかったよ…… • 2019年12月、サウジアラムコ(サウジ国営石油)がIPO • 時価総額200兆円超、世界一の時価総額に https://www.180.co.jp/world_etf_adr/adr/ranking.htm 24
25.
世界ではなにが起こっていたのか? • DX、DevOps、toCのソフトウェア会社が躍進 • ソフトウェアを全世界に輸出できている •
日本企業はうーん… • ソフトウェアの輸出ができていない? • じゃあ、DX、DevOpsって何よ?なんでDevOpsが必要なの? 25
26.
目次 • ソフトウェアが世界を食らう • DevOpsとは何か? •
日本の労働法とDX/DevOps • DevOpsとメンタル 26
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
28.
28 https://commons.wikimedia.org/wiki/File:Devops.svg
29.
なぜDevOpsが必要なのか • 収益の主体・差別化がDev・SalesからOpsに移った • LTV>CPAである限り無限スケール •
マーケットの変化速度の上昇 29
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
32.
LTV>CPAの戦い方 • 例)IPO直前のGunosyは調達した資金をほぼ広告に投入 32 https://jp.techcrunch.com/2014/06/23/j p20140623gunosy/ https://jp.techcrunch.com/2014/0 3/14/jp140314gunosy-kddi/
33.
マーケットの変化速度の上昇 • 5000万ユーザ獲得までの時間 33 https://steemit.com/steemit/@johnnywingston/how-long-does-it-take-steemit-to-hit- 50-000-000-users--1502430927-1670258
34.
変化に対応するには細かい軌道修正が必要 • 従来の中央研究所方式の製品リリースでは世界と戦えない • 研究所で数年 •
事業会社でさらに1年開発 • 運用移管して数年の運用 • より短い期間で軌道修正を行える者が勝つ • リーン開発、スクラム、DevOps、DX 34
35.
生き残る種とは、最も強いものではない。 最も知的なものでもない。 それは、変化に最もよく適応したものである。 チャールズ・ダーウィン35
36.
わが社でも DevOpsをやってみたいので、 どのツールを使えばいいのか 教えてほしい 36
37.
違う、そうじゃない 画像省略37
38.
なぜDevOpsという言葉が出てきたのか? • DevとOpsは組織が分かれており、対立していることが一般的 だった コードのせいじゃないよ マシンのせいでしょ?マシンのせーじゃねーよ コードのせいだろ!! 38
39.
なぜDevとOpsは対立していたのか? • 部署が分かれている • 評価基準が違う •
採用が違っていた 39
40.
直交する評価基準 安定性 新機能 新しい機能を追加すると、 バグは必ず出る 40
41.
直交する評価基準:Dev目線 安定性 新機能 現実 新機能追加しました!! これで儲かります!! 41
42.
直交する評価基準:Ops目線 安定性 新機能 現実 新機能で儲かるわけねぇよ どうせまたバグが出るだけだろ 42
43.
ベクトルで分かる、部門対立 • 評価軸が部門ごとに独立 • Devは新機能軸を評価する(評価される) •
Opsは安定性軸を評価する(評価される) • どうしてこうなった? • ハードウェアの時代の歴史的経緯による分業 • 現代では、分業による効率化、餅は餅屋 43
44.
ハードウェアの時代の歴史的経緯 • 研究・開発・運用サポートの分離 • 少数精鋭・高学歴の研究開発 •
基礎技術の研究開発 • 製品の開発のための図面起こし • 高等教育を受けた製造オペレータ • 工場労働、製品の品質管理 • 大量の運用人員、労働集約産業 • 設備の設置、修理サポート、販売支援 • コールセンターサポート • 製品に何かあったら運用でカバーはこの時代から • ハードウェアはなかなか直せない 44
45.
ソフトウェアの時代へ • ソフトウェアはハードウェアの従属物の時代 • ハードウェア時代のウォーターフォール開発が そのままソフトウェアに適用される •
ハードウェア時代の組織構造がそのままソフトウェアに適用 • 設計:コードの設計をする人 • 製造:コードを書く人 • 保守:コードの運用+マシンのメンテをする人、サポセン • ソフトウェアのリリースも一年に一回、半年に一回程度 • 運用でカバーで何とかなっていた 45
46.
企業のネットが星を被い 電子や光が駆け巡っても 国家や民族が消えてなくなるほど 情報化されていない近未来 攻殻機動隊 GHOST IN
THE SHELL(1991)46
47.
時代はインターネットへ • 毎日が機能追加、毎日がデプロイ、毎日がバグ • 開発部門は機能開発・売上が業績評価指標 •
運用部門は稼働率、SLAが業績評価指標 • 開発と運用では必要なスキルセットが異なるので、分業する • 開発部門と運用部門の業績評価指標が直交 • DevとOpsが対立する • じゃあ、これを何とかしようぜ、というのがDevOps • そして、そのキッカケはクラウドの登場(だと思っている) 47
48.
余談)少しずつ壊れていく分業 • 最初はうまくいく • なぜ部門が分割されたか皆が知っている •
隣の部門をカバーするように動く • 評価制度が狂いはじめる • 問題を分割したことによって、 評価が分かりやすい数字に置き換えられる • 部門の数値目標が一人歩きを始める • 個人の評価も同様の数値目標で行われるようになる • 考える人が居なくなる • 与えられた評価基準を満たすように皆が動くようになる • 隣の部門の問題は誰も知らない • 部署の間に落ちたボールは誰も拾わなくなる 48
49.
クラウドの登場 • 1999年 VMWare •
x86の完全仮想化 • 2000年 FreeBSD jail • 1台のPC内のユーザを仮想的にアイソレーションする • 2003年 Xen • 2005年 OpenVZ • 2006年 AWS EC2 • APIでキックしてインスタンスを立ち上げる • 2009年 FlickrがDevOpsの講演 詳しい話は緑の恐竜に聞いてください49
50.
余談:クラウドと仮想化って何が違うの? • 仮想化:基礎技術、1960年代からあった • 分散処理:基礎技術、1960年代からあった •
クラウド:提供形態、2006年ごろから • クラウドは仮想化されたコンピューティング資源が、APIを経由してプログ ラマブルになったサービス • コンピュータを制御するのに、人の手を介さないでもよくなった • 人間が直接管理できるコンピュータはせいぜい10台程度 • コンピュータをコンピュータで制御することで限界突破 • より優れたプログラマは、より多くのコンピュータを扱える時代 • クラウドは人間の能力の限界を突破させた 50 詳しい話は緑の恐竜に聞いてください
51.
余談:Иττのクラウドに絶望した話 51
52.
余談:Иττのクラウドに絶望した話 • 入社式で分散処理の専門家のS先生がゲスト公演 • クラウドは人間をエンパワーする •
より優れたプログラマが、 より多くのコンピュータを扱える時代が来る • クラウドとは人間の能力を100倍、1000倍に引き上げる仕組み • 社長の講演は全く覚えてなかったけど、 S先生の話は自分に深く刻まれていた • Иττのクラウドは人間をエンパワーしているか? • していない → 退職へ 52
53.
クラウドの登場で何が変わったのか? • クラウドにより「計算機資源そのものが仮想化され、計算機資 源がプログラマブルになった」 • Ops業務のメインは「サーバ管理」=「計算機資源のマネジメント」 がであったが、これの大部分がプログラマブルになった •
仮想化や自動化に対して様々なツール・サービスが登場 53
54.
Opsの手作業業務の大部分が自動化 • サーバラックに機材を積み込んで、 電源入れてOSインストールして、 必要なパッチを当てて、 ネットワーク回りの設定を書き換え、 サービスをデプロイして、 ログを画面に表示して目視確認して…… • 開発初期におけるOpsの手作業業務の大半がプログラマブルに •
Infrastructure as a Code、 Immutable Infrastructure、に繋がる • DevがOpsの業務を取り扱えるようになった • Opsがプログラミングによって自らの仕事を減らすのもアリだが、 日本ではプログラミングのできるOpsが少ないため、 結果的にこうなることが多い 54
55.
DevOpsとは何か? • クラウド+周辺ツールによるOpsの手作業業務の自動化 • 変化への対応 •
無限の事業スケールへの対応、LTV>CPA時の急拡大対応 • DevとOpsの業務をプログラミングにより垂直統合 • 「手を取り合えば効率的になる」というわけではない • Opsの仕事をDevがプログラミングで奪い取る • 業績評価指標の見直し • 分業から垂直統合仕様に • 垂直統合前提で業績評価指標を見直す 55
56.
DevOpsとはツールではない • 業務プロセスの垂直統合 • プログラマーの活動範囲の拡大 •
オペレーションまで加味した全体最適化 • 全体最適化なので、業績評価指標を「全体最適」にする必要 • 個別最適の業績評価指標のままではDevOpsはできない 56
57.
業績評価指標をDevOps仕様にする • 一番簡単なのは生株付与やSO • 会社の評価額の上昇が、自らの利益になる •
サービスの価値が上がる、会社の評価額が上がることなら何でもやる • 次に簡単なのはサービスの利益連動ボーナス • とはいえ、サービスの利益を計算するのはとても大変 • 人数が多くなると、その人の貢献を計測するのは超大変 • 配属ガチャで給与が決定されるという問題が生まれる • GoogleではSREとプロダクト開発チームはError Budgetを共 通の指標にする 57
58.
Error Budget • SLO(Service
Level objectives)に基づくError Budgetを設定 • DevとSREは Error Budget を共通の評価指標に • Devも稼働率を改善するのに協力する • サービスがダウンすると、その分 Error Budget が削られる • Error Budget が尽きるとデプロイできなくなる • Error Budget が尽きそうになったら、デプロイの間隔を下げる • その分、コードレビューやテストを厚くする • サービスの種類によって、設定されるBudgetの 大きさは異なる • 安定性が重要なtoBサービスは小さく • 改善速度が重要なtoCサービスは大きく • プロダクト性質に応じて柔軟に変更する 58
59.
目次 • ソフトウェアが世界を食らう • DevOpsとは何か? •
日本の労働法とDX/DevOps • DevOpsとメンタル 59
60.
日本の労働法の歴史的経緯1 • 明治時代 • 工場労働者は低賃金 •
給与を上げるには、スキル身に着けて転職 • 大正から太平洋戦争 • 熟練工の長期雇用をしたい • 社内で職工を育成、長期雇用が前提に • 年功賃金制、年功序列制の発生 • 生活給思想が広まる • 若年層に過度な高給を与えても飲食で浪費してしまう • 壮年層には、家族を扶養するために多くの給与を与えるべきだ • 賃金統制令、年功序列が法律で規定される 60
61.
日本の労働法の歴史的経緯2 • 戦後、電産型賃金体系 • 本人の年齢+扶養家族数をベースに生活給を決定 •
これに職能給や勤続給を加えた年功賃金制度 • 占領軍、政府、経営はこれに反対 • 1950年代、職能給の確立 • 技術革新により新規工場が設立、大規模な配置転換が必要に なり、労働者は給与が維持されること条件にこれを労使合意 • 給与の維持=職能の維持、仕事が代わっても「職能」は変化しない • これにより、労働市場からの人材調達ではなく、 社内の配置転換による雇用調整がメインになる • 「勤続年数が長くなれば潜在能力が伸び、潜在能力があるか ら配置転換しても大丈夫」というのが建前 61
62.
日本の労働法の歴史的経緯3 • 1960~1970年代 • 配置展開が子会社、グループ会社間に拡大 •
転籍という形で企業の枠を超えた異動 • 人事権法理の確立 • 労働者の同意を得ない配置転換を正当とする • 配置転換に本人の同意が必要だとすると、同意を得られな かった場合、労働者を解雇することになる • 一方で解雇権は制限されている • 配置転換と解雇で、配置転換が優先される • ジョブ保障とメンバーシップ保障で後者が優先された 62
63.
日本の労働法の歴史的経緯4 • 1985年 男女雇用機会均等法 •
男性採用・女性採用のラベルを張替えて対応 • 男性採用→総合職 • (家族を養うので)職能給、年功序列で昇給 • コア業務、配置転換あり • 女性採用→一般職 • (結婚までの腰掛なので)昇給しない • 事務業務、配置転換なし • 日本企業は総合職の配置転換によりアジリティを 確保していた 63
64.
日本の労働法と事業会社 • 事業会社は配置転換を前提に従業員を雇用する • 配置転換できそうか?どこに配属しても大丈夫か? •
そしてコミュ力採用に…… • そして産業の高度化について行けず…… • IT人材は社内での配置転換先がないので、雇いづらい • ITシステム開発には稼働の波があるが、事業会社一社ではこれを吸収できない • IT人材を配置転換したいが、配置転換先がない、なので雇えない • IT業務については社外に発注する → SIerへの依存 • 社内にITの専門家がいなくなる • 要件定義、発注、ベンダーコントロールができない • 日本的DX問題に発展、みずほ4500億円… … … 64
65.
余談:追い出し部屋は何故できるのか? • 日本の給与制度と、労働法の判例が合わさった結果の闇 • 解雇、不当な減給は禁止、でも配置転換はOK •
配置転換をして、自主的に進退を考えるように促すことはOK • 職能が上がってしまって、給与が上がり過ぎてしまった人が生まれる • 職能は「潜在能力(笑)」なので、計測が難しく、年功で上がってしまうことが多い • 職能は「潜在能力(笑)」なので、下げることが難しい • 職能は実際に仕事ができるかどうかは別 • 職能と役職はリンクすることが多いが基本的には独立 • 職能は高いが役職がない、という人が生まれる • リンクさせる必要がある場合、解雇か降格をする必要があるが、これは難しい • 「異動してきたばかりだから、出来なくても仕方ない、そのうち出来るようになるよ…」 65
66.
国内であれば乱暴に出来る 66 http://web.archive.org/web/20180223103231/http://tech.nikkeibp.co.jp/it/atcl /ncd/14/457163/111501934/ https://twitter.com/kumagi/status/966708024491442176 どうして記事が消えてるんですかね?
67.
SI企業の配置転換の事例 67 https://www.nikkei.com/article/DGXMZO37008040W8A021C1TJC000/
68.
保険事業者が介護事業を買収、配置転換 68 https://www.jiji.com/jc/article?k=2019062401063https://medfit-gl.jp/cw_job/column/1114.php
69.
ローテーション人事とプログラミング 69 https://twitter.com/tokoroten/status/617923913964654592
70.
余談:本当にあった怖い話(n=1) • 優秀な新人はプロフィットセンターの生産部門へ • アレな新人はコストセンターのIT管理部門へ •
IT管理部門が人材の吹き溜まりに…… • 現場とは話が通じるが、IT部門が30年遅れ…… • 何も考えずに安全側に倒しまくる • データは工場の外に出してはいけない、クラウドなんてもってのほか • ある種のイノベータのジレンマ • 稼いでいる部門に優先的にモノヒトカネを投入 • IT部門に投資して全体の効率を改善するという意思決定ができない 70
71.
分社化される大企業 • 労働者は「同一職能・同一賃金」を期待する • 経営者は「同一労働・同一賃金」にしたい •
これを両立させるために、事業・職種ごとに分社化される • グループ会社間で異動させることで、給与を調整できる • 大きく給与を下げるのは判例的にはNG • どこの会社で最初に雇用されたかで給与差が生まれる • 親会社から送り込まれた天下りおじさんが自分の倍の給与をもらっておりモチベダウン • 大企業、本社指向で、そこに人が集まる • あと、ポストを用意したい • 人件費圧縮として行ってきた子会社戦略がDevOps、DXの足枷に • 部署の壁よりも厚い、会社間の壁が 71
72.
そして火を噴く日本的労働 • 仕事が高度化、配置転換では対応できなくなってきてる • 配置転換先のない窓際おじさん、パソナルーム、追い出し部屋 •
配置転換をすることで「自発的に退職していただく」 • 先端業務で使える専門性が磨けないローテーション人事 • DXの要請、 2025年の崖 • 仕事の高度化=コンピュータ時代、全てがコンピュータの時代 • コンピュータが使えないやつに仕事がない時代 • ルールを作って人を管理する時代から、 コードを作ってコンピュータで世界を管理する時代へ • 機能別子会社による給与抑制は、DXの足枷になる • DXは業務をデジタルによって垂直統合をする • 部署の壁だけでなく、会社の壁にぶち当たる 72
73.
全てのがDevOpsになるのか? • toC、toBで状況が変わる • toC •
toCはOpsの自動化と無限オートスケールの相性が良い • LTV>CPAの数式でビジネスが語れる世界 • toB、toGov • ビジネスのスケールが限定的、まだ変化速度は遅い • なので、全部が全部、DevOpsにならなくてはいけないわけ ではない 73
74.
とはいえ、toB、toGovも変わっていく • 政府のソフトウェアのOSS化 • クラウドの採用、API化 •
入札からコンペ型・直接雇用の契約へ • Industory4.0やConnected Factoryによる事業のAPI化 • 少量多品種生産の増加、全自動フルカスタマイズ生産 • 変化速度が速まっていくことは間違いない • 遅かれ早かれ、WFタイプは減っていくんじゃないかなー 74
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/
76.
目次 • ソフトウェアが世界を食らう • DevOpsとは何か? •
日本の労働法とDX/DevOps • DevOpsとメンタル 76
77.
大本営発表マネジメント • 日本的な職能による昇進は、その職位に付く能力があるかない かとは関係なく行われる • マネジメント能力がない人がトップに就くと、大本営発表マネジメン トがよく行われる •
「俺たちは勝っている」というメッセージを発し続ける • 大本営発表マネジメントは、視野の狭い人には強烈に効く • 大半の人は「お気持ち」で働いており、「お気持ち」=生産性 • 視野の広い人には、強烈なマイナスに作用する 77 大本営発表マネジメントは私の造語なので、ググっても出てきません
78.
めんどくさい人々 78 https://twitter.com/tokoroten/status/1235268249723359233
79.
失敗を語れるか? 79 https://twitter.com/tokoroten/status/1141273917308334080
80.
How Not to
Land an Orbital Rocket Booster 80 https://www.youtube.com/watch?v=bvim4rsNHkQ
81.
ポストモーテム、検死 • 大本営マネジメントは、失敗から学ばない組織を作り上げる • 失敗したプロジェクトを社内でちゃんと話せるか? •
失敗のコストとは教育である 81 https://landing.google.com/sre/sre-book/chapters/postmortem-culture/
82.
Error Budgetは失敗を許容する • Error
Budgetは開発者とSREの間でのインセンティブに使われる • 信頼性100%はあり得ない、誰でも、どんなシステムでも失敗する • Budgetが尽きない限り失敗してもよい • Budgetを設定することで、信頼性を上げすぎて、過剰コストになることを防止する • 失敗が起こることを前提に組織を回すことができる • 失敗をゼロイチで捉えない • SLAの場合、SLAを割ったかどうかでしか評価されない • SLAを下回ったから、謝罪、返金、社長が謝る、終わりの組織は多い • Budgetにして監視をすることで、連続値になり、 意思決定を柔軟に変えることができる 82
83.
学習姿勢と心理的安全性 • How Google
Works ラーニングアニマルを採用す る • 自分の能力は変わらないと考えていると、その自己イメー ジを維持するために「到達目標」を設定する。一方、しな やかマインドセットの持ち主は「学習目標」を設定する。 • 学ぶこと自体が目標になると、くだらない質問をしたり、 答えを間違えたりしたら自分がバカに見えるのではないか などと悩んだりせず、リスクをとるようになる。 • ラーニング・アニマルが目先の失敗にこだわらないのは、 長い目でみればそのほうが多くを学び、さらなる高みに上 れることを知っているからだ。
84.
プロジェクトアリストテレス • 心理的安全性はGoogleの調査からIT業界に広まった • Project
Aristotle チームの生産性に何が寄与するかを調査するプロジェクト https://rework.withgoogle.com/jp/guides/understanding-team- effectiveness/ https://rework.withgoogle.com/print/guides/5721312655835136/
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/
87.
心理的安全性とは何か? • 意訳: 心理的安全性とは、提案をしたり、質問をしたり、懸念してい たり、失敗したことによって、罰せられたり、恥をかかされた りすることが無いことだと信じている状態 https://www.youtube.com/watch?v=LhoLuui9gX8
88.
心理的安全性は何のために必要か? • ひとことで言うと、心理的安全があれば、厳しいフィード バックを与えたり、真実を避けずに難しい話し合いをしたり できるようになる。 • 心理的に安全な環境では、何かミスをしても、そのためにほ かの人から罰せられたり評価を下げられたりすることはない と思える。 •
手助けや情報を求めても、不快に思われたり恥をかかされた りすることはない、とも思える。 • そうした信念は、人々が互いに信頼し、尊敬し合っていると きに生まれ、それによって、このチームでははっきり意見を 言ってもばつの悪い思いをさせられたり拒否されたり罰せら れたりすることはないという確信が生まれる。 チームが機能するとはどういうことか 4章 心理的に安全な場を作る より引用
89.
心理的安全性の勘違い • 「うちの会社は心理的安全性があります!」に意味はない • セクハラだと当人が感じたらセクハラ •
心理的に安全だと当人が感じたら心理的安全 • 心理的安全性は、空間ではなく個人の体感 • 心理的に安全だと感じるラインは個々人で異なる • リーダーは「ここまでやっても安全だ」と見せる必要がある • 自社の失敗をモンティパイソンのBGMで紹介できるか? • 周りはなかなか変えられない、自分は変えられる • 心理的安全性のラインが高い人を雇用することも大事
90.
個人が心理的に安全になるには? • なぜ人は発言しなくなるのか? • 会社や組織と対立することによって、自分の仕事が危うくなると思っている •
日本的な雇用は対立を極端に恐れる • いつ配置転換で地方に飛ばされるか分からないし…… • 会社や組織に対して強くなることでも心理的安全性は改善する • 会社や組織が間違っているのであれば、いつでも出ていける • クビを切られたとしても明日からでも行ける会社がある • 対立したとしてもそれは学習だと認識する • 能力・人脈・転職活動・学習姿勢がある人は、 対立を恐れずにGive firstができる
91.
DevOpsが出来る人材を雇用する • そもそもプログラミングが出来ることが必須 • 失敗を学びだと認識できる人 •
目の前の不確かな事象を理解できる言語能力の高さ • 人と対立してもそれを感情ではなく、ロジックで解釈する • 全体最適を意識した動きをするための視野の広さ • HRT、謙虚・尊敬・信頼を持った人 • コミュ力と言語能力は違う • 相手に共感することと、論理的に情報をやり取りする能力は違う • 言語能力が高い人を正しく採用する • これを間違えると、言葉狩り、ポリコレ、コンプラ地獄に陥る • 配置転換を前提とした企業は、コミュ力に寄りがち 91
92.
HRT(謙虚・尊敬・信頼) • 優れた開発チームでは、HRTの価値が大切にされている • 謙虚
Humility • 世界の中心は君ではない。 君は全知全能ではないし、絶対に正しいわけでもない。 常に自分を改善していこう。 • 尊敬 Respect, • 一緒に働く人のことを心から思いやろう。 相手を一人の人間として扱い、その能力や功績を高く評価しよう。 • 信頼 Trust • 自分以外の人は有能であり、正しいことをすると信じよう。 そうすれば、仕事を任せることができる。 • HRTは学び続け、成長し続けるための姿勢 • HRTの逆を考えてみればよい、人から学ぶことが出来なくなる • HRTを持つことで同僚の行動に対して正しく振る舞える • 同僚は安心して自己を開示し、良い議論が行えるようになる
93.
NETFLIXの事例 • 一時ネットフリックスはバッファリング時間(ビデオをクリックして からスタートするまでの時間)の短縮に大苦戦していた。エンジニア にしか完全には理解できない、厄介きわまりない問題だ。 • 私たちはセールスとマーケティングの担当者に要請した。「あのくそ いまいましいバッファリング問題をなんとかしてくれ!」とエンジニ アにぶちまける代わりに、「なぜバッファリングにこんなに時間がか かるのか、わかるように説明してくれ」と聞いてほしい、そしてその 質問は本心からぶつけてほしいと。 •
相手がとりくんでいる課題に心から関心をもってする質問は、理解の 架け橋になる。技術系でない従業員は、この質問への答えを通して、 エンジニアがどんなに手ごわい課題にとりくんでいたかを初めて知り、 視野を大きく広げた。 • こうした質問を投げかけるうちに、やがて社内に好奇心と敬意が育ま れ、チームや部門の内外で有益な学習が行われるようになった。いい 加減な噂や陰口のたぐいも減った。 NETFLIXの最強人事戦略4章より引用
94.
余談)IPOでレガシー化するベンチャー企業 • 売り上げを増やすために商品を増やす • 商品を増やすために人を一気に増やす •
人材レベルが低下して、大本営マネジメントが始まる • 市場に対して弱気を見せると株価が落ちる • 市場への強気のアピールは社員の自己洗脳につながる • 対外的なポストモーテムは株価に影響が出ると思い込んでしまう • 社内で失敗の分析や、ネガティブな発言は禁忌となる • 失敗から学ばなくなる • 監査対応でレガシーなシステムが必要になってしまう • 会計監査、内部統制 • 外部の会計会社が慣れ親しんだワークフローを要請される • チェックリスト地獄、監査がレガシー • それをビジネスに組み込んでしまうとシステムが複雑化、レガシー化 94
95.
余談)クソスクラム野郎問題 • 「俺たちはスクラムをしているから勝っている!」と思い込む • 大本営発表マネジメントの亜種 •
プロセスを信奉して思考停止する • プロセスは改善するものであり、信奉するものではない • スクラムは「まずは型をコピーするところから始め、自らのビジネス に合わせてカスタマイズしていく」という守破離を説いているが、 そのせいで、守で満足して思考停止してしまう人が多い • 新しいことをするのは怖い、勝ってることにするのは楽 • 「俺はスクラムが嫌いだ」と言うスクラムマスターが何人も… 95
96.
SIerはどうなるのか? • 企業・公共のアジリティを上げる流れ • 公共のOSS化、公共のクラウド化 •
世界は「WFよりも、DevOpsのほうがコストが下がる」ということを 知ってしまった • 柔軟な予算体制を組める組織はそちらに移行していく • 準委任契約の請負とか • ITシステム入札の闇にそろそろ気づき始めている • 結論 • 知らんがな、うちは単なる中小企業だ、俺に聞くな • 緑の恐竜がだいたい悪い 96
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