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

ジーン・キム / ケビン・ベア / ジョージ・スパッフォード / 長尾高弘 / 榊原彰

彼はある日突然、CEOのスティーブ・マスターズからIT運用担当VP(バイスプレジデント)に任命された。
社運を賭けた、店頭小売とネット通販を統合する新システム「フェニックス」を3カ月以内にリリースせよ。さもないと、IT部門はアウトソーシングする、と告げられる。 プロジェクトの成功に欠かせない「4つの仕事」と「3つの道」を見つけるように言い渡される。
ビルは仲間とともに数々の危機を乗り越えるなかで、開発(Development)と運用(Operation)が一体となってシステムを開発していく「DevOps」に目覚めていく。

• カテゴリ: ビジネス・実用
• ジャンル: IT・コンピュータ / 全般
• 出版社: 日経BP
• タイトル: The DevOps 逆転だ！
• タイトルID: 276164
• ページ数: 400ページ
• 電子版発売日: 2014年08月15日
• コンテンツ形式: EPUB
• サイズ(目安): 3MB

[ブクログ · ★★★★★]

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

[ブクログ · ★★★★★]

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

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

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

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

[ブクログ · ★★★★☆]

新卒で企業に入社する前、入社後にシステム分野に取組むことになったことをインターン先に上司に報告したところ、紹介して貰って読んだ本。最近「The DevOps」・「運用」に悩む・取組む必要があり改めて読み直した。

運用の仕事は、予定された仕事の流れを作り出して社内に価値を届けることが重要であり、４つの仕事に分類されるという。ビジネス・プロジェクト、IT運用のプロジェクト、プログラム変更、予定外の仕事である。本書ではシステム改修のミスにより予定外の仕事が運用を圧迫し、予定外の仕事が出てくる要因を突き止めることから改善が始まる。予定外の仕事は修整作業であり目標から引き離すものである。

そして本書全体通して強調されるのは制約条件・ボトルネックの存在である。ボトルネック・制約条件により処理量が制限される以上、その前後の関係は無意味である。この点を踏まえつつ、予定された仕事の流れを管理、制約条件・ボトルネックに従い処理を構築し、制約条件・ボトルネックに遊ばせることがないようにする。予定外の仕事は制約条件・ボトルネックに係るか、本書では優秀なエンジニアであるブレントどうかで判断する。

運用には３つの道があると解く。「第１の道は、開発からIT運用への仕事の流れを速くするにはどうすればよいかだ。IT運用こそ、会社と顧客の間にあるものだからだ。第２の道は、フィードバックループを短縮、強化する方法だ。すると、源のところで品質を上げ、やり直しを避けることができる。そして第３の道は、実験、失敗からの学習、反復と練習が熟達には不可欠という考え方を並行して育てていく企業文化を作ることだ。」

それ以外に個人的に面白かったのは予定外の仕事が発生させないように予防する、変更管理の定義として「変更』とは、アプリケーション、データベース、オペレーティングシステム、ネットワーク、ハードウェアに対する物理的、論理的、仮想的な働きかけのうち、提供しているサービスに影響を与える可能性のあるものである」、細かい内容を提示させるがゆえに機能しない変更管理である。後者が見覚えしかない。

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

ざっくり言うと生産管理からITが学ぶことは沢山あるよという話。度々引用されるので、ザ・ゴールを読んでから本書を読んだ方がよい。CIO視点のビジネス小説として他に「ビジネスリーダーにＩＴがマネジメントできるか」があるが、そちらより学びが多かった気がする。しかし図があった方がもっとわかりやすかった。

[ブクログ · ★★★★☆]

法改正の度に法外な改修費がかかる状況を何とかしたいと思い手にとった。
自社で開発、運用している状況だからできるのか。ベンダーに開発、運用まで任せている状況で、ユーザ部門まで束ねて情報システム部門で何ができるのか、特に「第2の道」をなんとかしたいなあ。

[ブクログ · ★★★★☆]

IT運用における問題や問題に対する対処、
運用改善、最終的には開発・運用の一体化までを
小説として書いた本。

嫌がらせをされるシーンもあったりと、
実際のIT運用に近い話が多かったような気がする。
おかげで面白く読むことが出来ました。

IT運用から改善を実現するには、
①現状をまずは改善する（小さく改善し、時間を作る）
　・運用フローを可視化する
　・運用を管理する
　・ボトルネックを見つける
　・運用フローを見直す
②業務とITの関連を把握する（業務を理解する）
　・どんな業務にITが必要なのか
　・そもそもどんなことにITを使っているのか
　・トラブルが起きて困ることは何か
　※個人的には、ココが極めて重要だと感じた。
③開発チームと一体となった組織を作る（クイックな組織）
　・開発と運用が繋がる箇所を整理する
　・整理した結果、自動化出来る部分を特定する
といった流れになるのだろう。

[ブクログ · ★★★★☆]

ザゴールのIT版。

基本的に、システム（ある程度規模がある）開発経験者でなければ、用語の理解や、開発現場の雰囲気の調整に難航しそう。また、加えて登場人物の多さも気になる。

日本のシステム開発従事者も、スキルや契約や何より、DevOpsの先にあるITが何のためにあるのかという視点を主人公率いるユニコーンチームみたいに持てると、本当に素晴らしいことだと思う。システムを守るため、ではなくビジネスを強化、補強、推進するために、DevOpsでIT頑張ろうという話。


devops（以下、抜粋）
ビジネスニーズに即応するということは、ビジネスの変化に応じてITシステムの機能が追加されたり、変更されたりすること。
換言すると、ビジネスの好機に必要とされる機能が提供できないITシステムはお荷物ということになる。

これを解消するために、IT（システム開発）の様々な仕事をミクロな視点で捉えつつ、マクロな視野を得、本当に有用なものにして行く。本書では、開発と運用の一体化を図り、ビジネスニーズへの即応性をより高めるDevOpsを目指す。