aretan.jp

オープニング¶

DevOpsは技術と文化の変化
コミュニティだけの話ではない
変化させ改善させていこう、潰さないで！

エンジニアはDevOpsのビジネス価値を伝える
ビジネスパーソンはプロセスと技術を理解しよう

WHYとHOW両方が必要である
時にはスーツを切る必要がある、Tシャツを着る必要がある

What is devopsdays
一日目はWHY
二日目はHOW

CTC
サービス開発プロセス　メトリクス　変更管理　統制　セキュリティに時間を割かねばならない
IgniteってDevOpsサービスを提供している

Agile Microservice Embracing Container
557Microservicesで回している
2000 3-tier
2007 SOA
NOW Container

Transformation: How big can you dream?¶

開発に1ヶ月かけてテストに2ヶ月かかっていた
本番機のアクセスを禁止した
ゴールデンゲートブリッジができる前はフェリーで20分だった
1960年から8年かけていろいろな人と話して提案が承認された

Lucretius 発展というのは世界を全く変えてしまう
INDUSTRIAL AGE 生産性が劇的に上がったが、世界大戦があった
DIGITAL AGE トランジスタ
企業の寿命が年々低くなっていく
UBERが出てきたからディストラクションが起きた
NETFLIX vs BLOCKBUSTER
ツタヤみたいなもんがあったけど5年で潰れた

DevOpsによって
Production Deployments 200x
。。。など

そこにディストラクションがあるから、どうにかやらねばならない
1950年メインフレーム
PC Internet Mobile IoT AIと、どんどん早く出てきている
対数的にLOGARITHMIC COSTが下がっていっている
昔はGoogleとかしか最新のテクノロジーが使えなかったが
今では誰でも最新のテクノロジーが利用可能になっている
パワーポイントを作る前に作ってしまうのが勝てる企業になる
なぜ会社が迅速に行動できないのか
Frederick winslow taylorが効率を考え始めた、今では悪評
USE METRICS, OPTIMIZE, MANAGEMENT, ...
今でもこの従来型で運営されてる企業もある
顧客へのトランザクションの即時性が上がっている
Edwards Deming品質にフォーカスすることで効率もあがる
スーパーバイザーではなく、リーダーが必要
QCDなんかより市場に導入するスピードが最も重要だった
つまり、プロセスが最も重要であるという事
遅延コストという概念、機会損失
Klaus Schwab 遅い魚を早い魚が食べる
COUPLING：一つでは存在できない、関わり合っている
一人の開発者がどれぐらいのスピードでデリバリできるか
一人だととても早いが、2人にしても2倍にはならない
Softwareでいうと4-7名が適正である、4名が最も適してる
簡単な作業なのであれば10名でも構わないかもしれない
150名が最大で、150以上になるなら事業所を分ける
Softwareでいうと結束力を保つために50名が最大
VALUES: 品質を重視する
STANDARDS: こういうのを違反してはいけない
BEST PRACTICES
FREEDOMS: あとは自由
Turn the Ship Around、ガバナンスのきかせ方
命令を決して出さない
ARCHITECTUREを独立させていく
単体ですべて成り立たつようにする
PIPELINEに人の介在をなくす
QUALITY ENGINEERINGでガバナンスする
プロセスは顧客のためにある
会員登録などのカスタマージャーニーごとにUNITを定義する
どのようにして価値創造していくか
時速320キロのタカにならねばならない
TRANSFORMATIONしなければならない
変化を促す要求要素
QUALITY、COST、SPEED、HYPER SPEED
アプローチ：テスト自動化、アジャイル、CDなど
Business Agilityに影響する要素はどれか
Engineering Transformationは少し影響する
（クロスファンクション）
Enterprise Transformationで全てに影響させる
より効果のあるEXECUTIONをPLANする
1年で早くやるには痛みを伴う
職責や職務が変わってしまう、解雇も伴う

政府系のプロジェクトは遅いと言われている
政府のプラットフォームから独立してスピードを上げた
そのプロジェクトの部屋だけ笑顔があった

Q. PIPELINEから組織横断していくための壁
いろいろな仕事を外してしまうという事
UPSCALEとRISK KILLが必要である

Q. 失敗例
何を期待すればいいかわからない、結果だけ求めている
明確化していく必要があるが、過小評価する事がある
あと問題があったときに技術的なものばかり見てしまう
文化的な変革をしてから、目標を掲げていく
一番は実行で失敗しやすい、技術要素は簡単だけど組織との整合性

Q. スピードとアジリティの関係
速度を上げれば品質が下がる事がある
人間が携われば失敗が発生する
PIPELINEをうまく作ることで解決できる

DevOpsでデジタル変革 デンソー¶

サービスとしての移動手段の提供 MaaS
売り上げ98%が車の中のコンポーネント
EVなどの変革で全て要らないものになる

Dlabプロジェクトレポート
テレビの画質→コンテンツ
携帯電話→IT企業がプラットフォーマーに
オーディオ機器→itunes

破壊的イノベーションはどこにでもある
OEMに従って開発してりゃよかった
最もどうでもいいソフトが最も重要になる

ユーザー接点が最も近い所が強くなる
UberがOEMに指示する側になる

これまではIT化だったがこれからはデジタル変革
要件なんですか？から、自ら矢面に立ちビジネスを作る

シリコンバレーは決まりごとだらけ、イノベーションには方法論があった
デザイン思考、アジャイル、リーン

ゼロからイチを創る デザイン思考
早く作る安く作る プラットフォーム構築
作りながら考える アジャイル開発
同じ土俵に立つ為に同じ道具を持つ

グローバルでは54%がアジャイル
日本では3.4%がアジャイル

ウォーターフォールはスコープ固定でリソース調整
アジャイルはリソース固定でスコープ調整

最初は遠慮してても、すぐにできる領域が広げられていく
ユーザーストーリーマッピング
提供価値、必要機能、構成要素、MVP、必要かも
物理的にやることはかなりやる気に寄与している

プロダクトマネージャーはゼロからイチ
プロダクトオーナーは製品価値を追求
macがいいとか、どういう机がいいかとかも開発チームが決める

マイクロサービス、サービスメッシュ
勝ち組パートナーと組む

shadow and knowledge structure
データから情報に知識に知恵にする

AWSにしか無いようなサービスは使わない
そこでk8sを活用して、対策して行きたい
サービスメッシュが使えるようになってきた
開発は競争力なのになぜ外注してしまうのか

なぜdevopsなのか、それはもう必要であるから

アメリカでの事例 Inedo¶

１キーとなるビジネスプロジェクトの確認
２Team DevOpsの編成
３マネージメントや他のチームへの成功例の伝搬
４他のプロジェクトへの反復
うまくいったが、Team DevOpsは大半が離職
DevOpsは銀行には関係ないと思われた
DevOpsチームを構築するだけではうまくいかない
企業全体の変革が必要

DevOps Fundamentalsというトレーニングを全員にした
C#やNodeなどの技術を使うことで有能なエンジニアを雇えるように
Autonomousチームが成功のキーとなった
セルフサービスなリリースとデプロイは必要不可欠
フォーマルなワークショップとトレーニングが望ましかった
リーダーシップとの調整という意味のトレーニング

DevOps for Enterprises
コンプライアンスは遵守しつつ、ビジネス上必要な変化をより迅速に
NetflixやRakutenやTwitterやCookpadは含まれない

DevOps成功パターン
１DevOpsのマインドセット（リーダーシップの養成）
リーダーシップが理解すべき事項：DevOpsとは何か、どう利益を出し変革するか
２評価と計画
３より多くの実行を可能に
達成に５年を見積もる、長期間の変化は容易ではない

SalesforceではDevOpsがないと今のスピードでは開発できない
開発中心のツールを開発する会社は、DevOpsに一番に乗り換える。
ツールに過剰に依存してしまう：事業とITがなぜかをちゃんと知るべき
予算を削減できるのではないか：削減だけしか見えてないなら説明しきれてない

Q.５年といったが、３年２年のMilestoneを教えてほしい
日本は計画に頼りすぎている、計画不足というより、計画頼りになっている
再評価をしていくプロセスが必要

Q. コスト以外のどういうBenefitがあるのか
すべての事業が存在する理由は、利益を得るため。
そのためにコストを下げるという事は一番の目的になる。
事業の観点からみると、機会損失と見る事ができる。

Applying DevOps to an organisation Naboek¶

DevOpsやるかどうかではなく、それが機能しているかどうか
会社全体のことを考えたら、サイロ内に閉じるのは正しくない
サイロから人を借りて、元に戻さない。
空のサイロができる、そうするとサイロが不要になる

DevOpsチームがStrategic-Business側にPushしていく
Business側からITが重要であることを知ってる人もいてPull
信頼というのは、良い意図を持っているか、コンピタンスを持っているか
The Trust Matrix信頼の要素の図

FragileなScrumをAntifragileにするためにCIなどを組み込む
攻撃すれば攻撃するほど強くなるのがAntifragile
カオスモンキーはAntifragileにするために使っている
NetflixはChaos Engineerを求人募集している
Backlogにちゃんと技術的負債返済を組み込んでいく
Bite the bullet

Lagging indicatorだけでなくLeeding indicatorも追う
State of devops report 2014 puppet labs and dasa devops fundamentals

Agile Leadership and Knowledge worker
ナレッジワーカーはわざわざ管理する必要がない
Autonomy + Mastery + Purpose = Motivation

複雑なことを変えるなら、ちゃんと練習しなければならない

For high-performing teams you need to nurture and grow your people¶

https://prezi.com/embed/jgeyawor30ww/?feature=oembed
DevOpsとはよりよいコミュニケーションとコラボレーション
各チームに権限を与え、気持ちよく働ける
DevOpsはテクニカルスキルばかり持ち上げられる
外科医に技術がなければ怖いから、間違いはない。
同僚のメンタリング・顧客のサポートなどのソフトスキルも重要
Critical thinkingが重要、そのまま受け入れるのではない
似たもの同士ばかりでは良いチームにならない
スーパーチキン3羽以外は死に絶えてしまった
強い人ばかりだと組織力がどんどん衰えてしまう
生産性が高いチームというのはどういうものか
１社会的な分別、お互いの配慮ができる
２EQが高い
３支配的な押しの強い人がいなかった
４女性も多かった
GoogleのアリストテレスPJというので生産的なチームの要素
心理的な安全、頼りあえる、自分の役割がある、仕事の意味、仕事の重要度
売上よりもPurpose and missionが重要
にしこりをどうコーチするか、弱い所を強くするのか、強い所をより強くするのか
舞の海は強みを活かして曙を倒した
Strengths finderで自分の強みを見つけても良い
上手く言ってる所に焦点を当てていく

まとめ、重視している所
Soft skill and diversity > technical skills
Purpose and Mission > financial goal
Team empowerment > smart manager
Build on strength > improving weakness

Docker Primer Accelerate your Testing with Containers COUCHBASE¶

チームの人数がすごく少ないので、Devopsなどでできるだけ快適にしたい
１人で様々な環境でソフトを提供する必要がある
昔はそれぞれパソコンを買うしかなかった
今ではVMで複数のOSが実行できるようになった
おめでとう、VMはDockerにしんかした
制限はあるけど、十分にできるし、起動時間は数秒
Valgrandメモリ違反をチェックするツールをビルドしてみる

シアトルDevops視察ツアー¶

https://speakerdeck.com/kawaguti/panel-at-devopsdays-tokyo-2018
Software is eating the world by marc andressen (2011)
Software is still eating the world by jeetu petel (2016)
ソフトウェア中心に世界が変わってきている
Digital magic How Eric Ries Brought The Startup Way to GE

DevOps 10 deploys per day
Automated infrastructure
Shared version control
One steo build and deploy
Feature flags
Shared metrics
IRC and IM robots
ソフト
Respect
Trust
Healthy attribute about feature
Avoiding Blame (叱責しない)

2009年にリーマンショックで人が溢れたからリーンスタートアップが生まれた
Enterprise Agile Michael Sahota
Agile Enterprise Michael Sahota

The Agility Pipeline @ Bing

Scrum gathering tokyo 2018
クラウドは完璧というのが存在しないなかで、どうやってシステムを動かし続けるか
会社に来るモチベーションとして家に居るより良いマシンがないと意味がない

DevOpsは時間との戦い
サイクルタイム短縮がビジネス構造を変える
意思決定のタイミングが変わる
意思決定に求められるスピードが変わる
組織構造と求められるスキルが変わる
断続的に不可逆の変化が続いていく

本当に必要なものを考えるための時間を作るために時間が必要
MSですらダークサイドから生まれ変わった
建物もスクラム仕様に変更した

バリューストリームマッピングだけやってみんなAWSに行く
一番のエコは人が死ぬこと
保守プロダクトでもVSMで吐き出せる事でスタートラインが一緒になる

menti.comでリアルタイム集計を作成する
開発チームが機能横断チームになっている
経営陣が支援している
デプロイパイプラインは自動
テストは自動化している

マネジメントの人はイベントの時にかわりに運用する
MSのマネジメントはコード書けるし、会話が合わない事がない