The DevOps　逆転だ！究極の継続的デリバリー 読書メモ

The DevOps　逆転だ！究極の継続的デリバリー 読書メモを残す。

開発業務をやっていく指針となる気づきが多い良書であった。

# 第1章　突然の呼び出し
> 「ITには光を照らし続けてほしいんだ。トイレと同じさ。トイレを使うときに、動かないかもなんて心配は決してしない。トイレが逆流して建物全体が洪水になるようなことだけは避けてほしいんだ」。彼は自分のジョークに笑った

> ITシステムはいつでも動いていて信頼でき、事業部門が頼れるものでなければならないということです

# 第4章　サラとの遭遇

> 顧客だか、社外との約束のために決して遅れが許されない急ぎのプロジェクトがある。テストや運用のためのデプロイのために時間を残さず、納期ぎりぎりまでの時間をすべて自分のものだと考えている開発者たちがいる。誰も納期を破りたくないので、開発に従う人々は、納期を守るためにとんでもない手抜きをする

# 第6章　インデックスカード
> 「どんなときでも、知っているほうが知らないでいるよりもいい。先に進もう」

> 自分が怒っているのは、2台目のドライブがエラーを起こしたからではない。会社にとってもっとも大事なことに全力を集中できなくなることが多すぎるから


# 第7章　エリックに連れられて工場へ
> ボトルネック以外のところでいかに改良を加えても無駄だということを教えてくれた。


# 第10章　ブレント導師
> ITシステムに依存しているすべての人々が仕事できるようにブレントが純粋にケアしているのを見て偉いなと思う一方で、みんなが彼のことを無料で使える個人的なギーク戦士のように使っているのにがっかりした。そのためにフェニックスが犠牲になっているのだ。

> 「物流担当のVPが補充注文が作れない、すぐに直してくれなければ、店舗でよく動く製品が品切れになると騒いでいると言われたからです。手助けをせず、店舗で品切れが発生するのを許した人間とは呼ばれたくないので」

> 私は、「手順というものは、人を守るためのものだ。ブレントをどうやって守るか、いい方法を考える必要がある」と言った。

> 私が知っていることを言っておこう。私たちが誰ひとり真似できない修復作業をブレントにしてもらうたびに、ブレントは少し賢くなり、システム全体はバカになる。このような形は終わりにしないと

# 第14章　どん底での和解
> お客さんは、車が動くように直さなければならない人々、子どもたちとの約束を果たそうとしている父親だ。それから我が社は最良のサプライヤーやクライアントにも迷惑をかけた。
 
> ただでもらってきた犬のようなものでさ、手に負えなくなるのは、初期費用じゃないんだ。目に見えない運用やメンテナンスなんだよね。

> ほとんどの工場には、システム全体の出力を左右するごく少数のリソースがあることを教えてくれた。リソースというのは、人でも機械でも原材料でもよい。その少数のリソースを制約条件、あるいはボトルネックと呼んでいる。

# 第15章　第4の仕事 
> ステップ2は、制約条件を十分に活用することだ。言い換えれば、制約条件が時間を無駄にするのを許してはならない。制約条件は、何であれほかのリソースを待っていてはならないし、IT運用の組織が会社の他部門のためにしていることのなかでもっとも優先順位の高い仕事をしていなければならない。いつもだ」

> 君は製品のなかに、人が『非機能要件』と呼んでいるこれらのものを入れる必要がある。しかし、君の問題は、君たちの技術的な負債について、運用しやすく設計されたコードを実際に作る方法についてもっともよくわかっている人物が忙しすぎることだ。

# 第19章　それぞれの秘密
> 私たちの『完成したプロジェクト』の定義には非常に間違っている部分がある。『クリスはフェニックスの自分のところの仕事を終わらせたのか？』という意味なら、成功だっただろう。しかし、フェニックスを本番稼働させ、ビジネスの目標を満たし、ビジネス全体を火だるまにするようなことはしないということがプロジェクトの完成なのだとすれば、まったくの失敗だったと言わなければならない」 

> IT運用の仕事には4種類のものがあります。ビジネス・プロジェクト、IT運用のプロジェクト、プログラム変更、予定外の仕事です。

> 私たちはいつも緊急状態で、近道を通らざるをえなくなります。そのために、本番環境でより脆弱なアプリケーションを動かすことになります。すると、そのあとで予定外の仕事と火消しが増えるわけです。こうして、私たちは堂々めぐりになっています

> 未払いの『技術的負債』のことだ。それは近道を通ることによって生まれる。短期的にはいいように見えるが、本物の負債と同じように、時間とともに複利方式で利息がたまっていく。技術的負債を返済しなければ、組織のすべてのエネルギーが予定外の仕事という形の利息の支払いで手一杯になってしまう。

> 火消にばかり時間をかけていると、計画のための時間もエネルギーもほとんど残らなくなる。起きたことに反応するばかりになると、新しい仕事を受け入れられるかどうかを判断するという難しい頭脳労働に十分な時間をかけられなくなる。プロジェクトを押し込めば押し込むほど、それぞれにかけられるサイクルは少なくなり、悪しき仕事の掛け持ちが増え、ダメなコードによるエスカレーションが増え、近道を通ろうとすることが増える


# 第20章　ワークセンター
> 「ひとつ以外のすべてのプロジェクトを凍結して何がよかったかといえば、そこだよ。みんな何の仕事をするか決めなくて済む。仕事の掛け持ちが認められないんだから」

> ブレントは作業者でワークセンターではありません。そして、ブレントは非常に多くのワークセンターを手伝っている作業者だと思います。だから彼が制約条件になるのです 

> 日常の仕事を改善することは、日常の仕事をすることよりも重要

> 何を改善しているかはほとんどどうでもよいと言っている。なぜか？　改善をしていなければ、エントロピーの法則により、実際にはどんどん悪くなっていく。


# 第22章　かんばんボード
> みんながそれぞれのプロジェクトをどれくらい大事だと思っているかは考えないつもりだ。制約条件の余力が残るかどうかを考える必要がある。


# 第23章　稼働率
> すべての人にアイドル時間、というかのんびりした時間が必要だということね。のんびりした時間が誰にもなければ、システム内にWIPが積み上がってしまう。というか、もっと正確に言えば、待ち行列に引っかかってただ待つことになってしまう

> ブレントがブレントになったのは、ブレントだけが理解できるようにインフラストラクチャを構築することを認めてしまったからだ

# 第25章　ビジネスを知る
> 今俺たちが直面しているこういう問題の多くは、俺たちが下した決定が引き起こしたものだよ。俺たちは敵に会った。それは俺たちだったってことだ

> ITがオイルを使わず物理的に荷物を運ぶわけでもないからといって、ITには予防的メンテナンスが不要だと思ってしまう」

# 第26章　ITへの不満
> うちの多くのセールスパーソンが自分ではどうにもならないことのためにわずかな差でノルマを達成しそこなったんだ。ITエラーのおかげで遅れた注文で未達になった部分については、ノルマ達成を認めてくれってスティーブに言ってるよ。そうじゃなきゃ、士気が下がる

# 第28章　ブラックマーケット
> 今までになく、何の仕事をすべきかを正確に把握できるようになった。そして、修正ばかりの仕事から抜け出せて満足感を持つようになってきている。実際に本来の仕事をできるようになったため、人々は幸せに感じ陽気になってきていると報告を受けている。

# 第29章　シングルピースフロー
> もっとも早い段階で製品設計に品質を組み込むのだ。そのためには、9カ月のリリースではだめだ。もっと早くフィードバックをする必要がある。 　9カ月に1度しか大砲を撃てないのであれば、狙っている的に当てることはできない。

> ゴールドラットが言うように、君はすばらしいテクノロジーを配備したのに、君自身が仕事のやり方を変えていないために、実際には限界を乗り越えられていない

> 仕事の流れは、片方向のみ、つまり前に進むのが理想的です。仕事が後ろに戻るようなら、『無駄』と思います。それは欠陥、仕様の不足、作業のやり直しなどによるものです。

> 仕事の流れは、片方向のみ、前にだけ進む。ITのなかでこのような仕事のシステムを作れ。目標はシングルピースフローだ、忘れるなよ。

# 第30章　バッチサイズ
> 1日10デプロイを目指せ

> すべてのものをバージョン管理システムに入れる必要がある。すべてだ。コードだけでなく、環境を作るために必要なものすべてだ。そして、環境作成プロセス全体を自動化する必要がある。

# 第33章　クラウドに救い
> この5週間の間に、ユニコーンのコードと環境のデプロイは20回もしているからね。デプロイが日常的なことのように感じるよ。