The DevOps逆転だ！ の商品レビュー

ジーン・キム(著者),ケビン・ベア(著者),ジョージ・スパッフォード(著者),長尾高弘(訳者),榊原彰

2024/10/19

ザ・ゴールみたいなストーリー仕立ての技術本？
面白かったけど、どう役に立てるのか分からない。
解説で触れていたように、もう一度３つの道を念頭に読み直さないといけないのか？
DevOpsをやるに至るまでに、ずいぶん長い前置きだなという印象。
ほとんど最後の方で、出てきて技術的な細かいところは触れてなかった。
心理的安全性とアジャイルで触れられるほどアジャイルに関係あるか？と思った…。

2024/02/15

雲をつかむような概念であるdevops。これをアメリカの老舗自動車部品メーカーを舞台とした小説で体感させることを狙った小説。
本書ではdevopsが仕事の4つのタイプと3つの道に沿って解説される。その根本には『ザ・ゴール』のTOC理論がありボトルネックになっているものから仕事をはぎ取ること、加えて、3つの道で示されるバッチサイズを小さくすることがある。
TOC理論で示されるように、いくら周りが頑張っていてもボトルネックが解消されない限り、その努力は無駄だし、WIPが積み重なるように無駄が無駄を呼ぶことにもなりかねない。また、バッチサイズが大きいとリリースまでの時間が長期化し、ビジネススピードから遅れていく。そのためにはバッチサイズを小さくする必要があり、だからこそアジャイルとも親和性が高いということなのだろう。またスピードアップのためには1日複数回のデプロイを可能とするための運用の効率化、標準化も必要ということになるけれど、これも小さく始めるということを前提に進める必要がある。
本書の内容をすべて汲み取れたとは言えないけれど、再読する価値のある良書。

2022/02/07

ITのプロジェクトがどんな風に進んでいくのか、
また最近流行りの（？）DevOpsがどんな概念なのかを知りたくて、
まずは小説から入ってみました。

欧米の小説な上に、自分の門外漢な領域でもあるので、
話の内容が完璧には分かりませんでしたが、
「それって情シスの仕事でしょ？」と安易に考えていたことに、
とても広い領域があって、
会社の戦略との繋がりも意識していく必要があるということが
よくよく分かりました。

結構骨太で、読むのがっ大変だったのですが、
読み進めてみると、大好きな本である「ザ・ゴール」のことが言及されていたりと、
どんどんストーリーにのめり込んでいきました。

非ＩＴ人間がこの分野を理解するのは、
ハードルが高いのですが、少しずつ理解を進めていきたいと思います。

2020/09/12

DevOpsハンドブックの前身との事で、まずはこちらから読了。
究極のピンチからDevOpsを少しずつ実現していく事で成功する道筋を、物語仕立てで教えてくれる本。
IT開発・運用を経験している人なら、大きくうなずく危機や障害、障壁が登場するあるある展開は自身の経験と照らし合わせながら読めると思いますが、いかんせん洋書によくある作風はちょっと読み辛かったです。

2020/07/11

システム開発プロセスの課題を、工場の見学によって俯瞰して洞察を得て、マネジメントに活かしていく物語。タイトル通りのDevOpsの文脈としてだけでなく、普段の業務プロセスのどこに無駄があるのか、それに対する解決のアプローチは製造業からヒントを得られることが多そうだと気付いた。アジャイルやスクラムを学ぶのもいいだろうけど、この本の学びを深めるために次はトヨタ・ウェイやザ・ゴールを手に取ろうと思う。

2018/11/04

・ITの4種類の仕事―ビジネスプロジェクト、IT運用プロジェクト、プログラム変更、予定外の仕事。技術的負債を放置しておくと、予定外の仕事しかできなくなる
・（過度なセキュリティを追求する担当者に対して）会社にとって最大のリスクは、監査所見を解決できないことではない。会社が生き残れないことだ
・「お前はボブではなく、俺の下にいるこを忘れるなよ。この体制で働けないなら、お前をすぐクビにする必要がある」
・「人は、終わりなく続くホラー映画のように、自分には結果を変える力がないと思うと、不満をためてありがたみを感じなくなる。そのことが人間としての自分の価値を傷つけないわけがない。そういう状況を変えなければならないんだ」

2021/08/08

今最も信頼するシステムエンジニアの方に最近のシステム開発の潮流は？と尋ねたら、真っ先に答えたのが、DevOpsである。名前の通り、「Development」と「Operation」を合わせた造語である。取り急ぎ、図書館の蔵書でタイトルになっている本書を読んでみた。本書は、小説仕立てとなっており、Devopsとはどういうことなのか、示唆を与える。
ちなみに、本書の舞台となった企業のIT環境を読むと、ITは本来強みとなるはずのものであるが、ビジネスの制約条件になりがちなのが、むしろ一般論なのではないかということを感じざるを得ない。IT革命という言葉さえ死後になりつつある現在、過去に築いた社内のシステムが乱立し、複雑に絡み合い、維持することさえままならない状態は、企業の危機である。そして、ITはIT部門のものとして、ITリスクがビジネスリスクとして経営側にも認知されていないことがさらに問題である、ということも思い知らされた。

以下、引用。
「『変更』とは、アプリケーション、データベース、オペレーティングシステム、ネットワーク、ハードウェアに対する物理的、論理的、仮想的な働きかけのうち、提供しているサービスに影響を与える可能性のあるものである。」
「第１の道は、開発からIT運用への仕事の流れを速くするにはどうすればよいかだ。IT運用こそ、会社と顧客の間にあるものだからだ。第２の道は、フィードバックループを短縮、強化する方法だ。すると、源のところで品質を上げ、やり直しを避けることができる。そして第３の道は、実験、失敗からの学習、反復と練習が熟達には不可欠という考え方を並行して育てていく企業文化を作ることだ。」
「ステップ１は、制約条件を明らかにすること…
　ステップ２は、制約条件を十分に活用することだ。言い換えれば、制約条件が時間を無駄にするのを許してはならない。」
「チームのダイナミクスについて述べた本のなかでも私が気に入っているのは、パトリック・レンシオーニの『あなたのチームは、機能してますか？』です。彼は、相互信頼を育てるためには、弱い人間でなければならないと書いています。」
「IT運用の仕事には４種類のものがあります。ビジネス・プロジェクト、IT運用のプロジェクト、プログラム変更、予定外の仕事です。」
「君たちビジネスサイドの人間は、プロジェクトのパンチドランカーになってしまって、成功する見込みのない新しい仕事に飛びつく。なぜだ？それは、自分が実際に持っている能力がどれくらいかわからないからだ。」
「予防のための仕事を重視することは、TPMなどのプログラムの中心的な課題だ。TPMは、リーンコミュニティでも支持されている。TPMが強調するのは、メンテナンスを重視して機会が使える状態を保証するため必要なことは何でもすることだ。私の先生のひとりは、『日常の仕事を改善することは、日常の仕事をすることよりも重要だ。』と言っている。第３の道は、システムに絶えず緊張を与え続けられるようにして、習慣を絶えず強化し何かしら改善していくということだ。レジリエンス工学は、システムには定期的にエラーを注入し、それを頻繁に行うことによって、エラー処理が苦痛にならないようにせよと教えている。」
「ローザーは、これを『改善の型』と呼んだ。彼が『型』という言葉を使ったのは、反復が習慣を作り、習慣が習熟を生むということを知っていたからだ。スポーツのトレーニング、楽器の習得、特殊部隊の訓練などでは、訓練と練習以上に習熟に役立つものはない。研究によれば、毎日５分ずつ練習する方が、週に１度３時間練習するよりも効果があることがわかっている。そして、改善の文化を生み出したければ、改善の習慣を生まなければならない。」

2018/10/07

practicalであればあるほどDevOpsの本だとは思わないような気がする。まあそれこそ道徳の教科書みたいになっちゃうしなあ

2018/03/25

資格試験用に貸してもらったのだが、試験対策としては時間がなさすぎて未読。ただDevOpsという概念をじっくり学びたいのでしっかり読みたい。

2016/03/28

自動車部品メーカーのIT部門を舞台にした小説です。
この組織では以下のような問題を抱えていて、自分の職場状況と照らし合わせても他人事とは思えません。
・５分で済む変更のために20分かけて登録するのはアホ臭いと誰も使わなくなった変更管理システム
　→何かを誰かが変えて何かが起こっても誰も状況を把握できない
・優秀な生き字引１人しか知らない部分の多いシステム
　→開発でも運用でも生き字引に仕事が集中してボトルネックに
・障害など予定外の割り込み仕事に振り回されるスケジュール
　→忙しさに追われ対処療法を繰り返した結果さらなる障害を引き起こす悪循環
・ただでさえ忙しいところに面倒を持ち込むセキュリティおじさん
　→本当に必要悪なのか
・etcetc

抽象的で不文律な面が多い仕事というものを分割し、並べなおし、再定義することでコントロール可能なものとし、最終的には自動化により効率面でのブレイクスルーを果たす。。

職場では運用しつつ開発しているのでDevOpsと言われてもイマイチピンときませんが、会社の経営目的とITとの関係を整理するシーンを読んでいて、Devを弊社、Opsを顧客に置き換えると出来ることがあるかも…と感じました。（Opsって保守運用ではなくビジネスの方だったのね…って今更ながら）

小説なので小難しいことはなく、純粋に読み物として楽しめます。
年次を問わずお勧めできる(得られるものは異なると思いますが)本でした。