1章 DevOpsを構成するもの
#システム運用アンチパターンのチラ見会
皆さんもこういった話は聞いたことがあるでしょう。
あるあるすぎて笑いそうだったw
開発チームとIT運用チームの間の機能不全は役割の違いから生じる避けることのできないものとして受け入れられがち
そうならないようにしたいなとなって改めて思った。
チーム感やプロセス間の有害で、無駄なやり取りを解決
1.1　DevOpsとは？
DevOpsの簡単な歴史
歴史的経緯が簡潔にまとまっているのはいいな。
DevOpsとは、ソフトウェア開発の考え方をほかの役割に適用するようなソフトウェア開発手法のことです
わかりやすい定義だ
DevOpsダッシュボードって名前の画面見たことない・・・。（Kaneyasu）
まず人、次にプロセス、そしてその次にようやくツール
大事
これめっちゃおもいますね。どのDevOps系の書籍でも言われている気がする。
DevOpsでは、ソフトウェア開発のライフサイクルに関わるすべてのチームが責任を共有することを重視しています
・責任共有するとは？（集合することなのか？DevとOpsの言葉は別れていないか？）
DevOpsの普及は「伝統的な」システム管理者の破滅を意味する
・伝統というほど歴史は経ていない
・破滅というほどプロセスが破壊されない（印象）
・「伝統的な」の意味する問題は何だったのか？
1.2　DevOpsの柱となるCAMS
Culture, Automation, Metrics, Sharingの4つっていうのはわかるけど、Effective DevOpsではCollaboration, Affinity, Tool, Scalingとなっていて、似ているけどちょっと違うのがまた面白い。
大量生産方式では、文化が最初に出てこないので、ソフトウェアぽくって面白いと思った
「自動化とは、人的資本を平凡な作業から開放することです」→経営者ではなく労働者目線で面白いと思った
これはほんとうにそうおもいますね。
メトリクスはエンジニアリングの文化らしさを感じる
→CAMSを起点としてソフトウェア開発におけるリベラルアーツ
書籍によっては共有じゃなくてコラボレーションって言われてたり。そっちの方がしっくりくるかも。
いまはCALMSでLを含めていないってコラムおもしろい。
リーンが有用だが、リーンが適用できない現場でも使えるようにする結果、CAMSがいいっていう理由は納得感がたかくていいな。スクラムもソフトウェア開発に限りたくないから意図的にソフトウェア技術に関する内容をできるだけ削除していったりするし。
-- 次回はここから --
1.3　また別のDevOps本？
DevOpsへの変革を経営層から現場に持ち込むための具体的なアクションをまとめた
現場から経営層だと思っていたが、本書のアプローチはちがった
繰り返すことのできる具体的なアクショん
一回やればOKというものではないというところかな。
単なるX社のケーススタディではなく、あなたが組織の中で実行し、調整し、繰り返すことのできる具体的なアクションを提案
これは期待が高まる！！！！
否定する意図はないんだけど、抵抗感を示す人はいますよね・・・。
あなたが変革者
動機づけるには（この本読むような人は動機があるから読むのだろうけど）
1.4　本章のまとめ
生産性の低下要因の対処を期待（分業と責任に対してか？
DevOpsの変革がもたらす変化は、純粋な技術を超えて仕事の本質に対する考え方にまでおよびます
(本を読み切る前)自分の仕事の本質とは何だろうか？（固定給、時間ベース）
異なるチームにまたがるタスク、チーム間コミュニケーションの問題は厄介
文化というふんわりしたものと具体的な行動との、相互作用が組織を変えていく
企業文化がその状況に与えている影響を強調します
文化：人類の理想を実現して行く、精神の活動。技術を通して自然を人間の生活目的に役立てて行く過程で形作られた、生活様式およびそれに関する表現。
企業における思考や生活様式がどのように働くかを規定し、運用の行動様式を決定している
時代的背景と構築された企業文化が、エンジニアの人間らしい仕事と競合している
1.4章のまとめから察すると、各章の背景では常に文化に対する示唆が含まれているはず
みんなからのコメント
実践する/伝えるためのハードルはなにか？
範囲が広い書籍だからまだ早いかもって思いがち
DevOpsって言葉だとまわりも腰をひきそう（自分にはまだ早いっておもいそう
一緒に使うと良さそうなプラクティスやマインドセットはなにか？
週末に「失敗の科学」を読んだんですけど、合わせてよむと良さげです。「サイロエフェクト」まだ読んでない・・・
たしかに！
ハードルの乗り越え方はなにか？実践/伝える方法はなにか？
他部門の手伝い？する工数どこから出るの？が一番ハードルの気がする。
「工数どこから出るの？」問題あるある。小さくして工数見えなくして乗り越える]
DevOpsって言葉をつかわずに具体的な課題とソリューションに注目して会話をはじめる。実践している人とだけDevOpsという言葉をつかう。
自組織における文化への洞察し、オペレーションへと落とし込む
どれくらい効果がありそうか？
自分の周りからはじめるというモチベーションが高まって計画を立てやすくなる
何からどう変えるべきか考える視点が得られる