ジーン・キムのレビュー一覧
-
Posted by ブクログ
雲をつかむような概念であるdevops。これをアメリカの老舗自動車部品メーカーを舞台とした小説で体感させることを狙った小説。
本書ではdevopsが仕事の4つのタイプと3つの道に沿って解説される。その根本には『ザ・ゴール』のTOC理論がありボトルネックになっているものから仕事をはぎ取ること、加えて、3つの道で示されるバッチサイズを小さくすることがある。
TOC理論で示されるように、いくら周りが頑張っていてもボトルネックが解消されない限り、その努力は無駄だし、WIPが積み重なるように無駄が無駄を呼ぶことにもなりかねない。また、バッチサイズが大きいとリリースまでの時間が長期化し、ビジネススピードか -
-
-
-
Posted by ブクログ
自動車部品メーカーのIT部門を舞台にした小説です。
この組織では以下のような問題を抱えていて、自分の職場状況と照らし合わせても他人事とは思えません。
・５分で済む変更のために20分かけて登録するのはアホ臭いと誰も使わなくなった変更管理システム
→何かを誰かが変えて何かが起こっても誰も状況を把握できない
・優秀な生き字引１人しか知らない部分の多いシステム
→開発でも運用でも生き字引に仕事が集中してボトルネックに
・障害など予定外の割り込み仕事に振り回されるスケジュール
→忙しさに追われ対処療法を繰り返した結果さらなる障害を引き起こす悪循環
・ただでさえ忙しいところに面倒を持ち込むセキュリテ -
-
-
-
Posted by ブクログ
■5つの理想
第１の理想－局所性と単純性
第２の理想－集中、フロー、楽しさ
第３の理想－日常業務の改善
第４の理想－心理的安全性
第５の理想－顧客第一
エンジニアが現実にいる人ではなく、抽象的な存在として”顧客”を考えると、まず正しい結果を生み出せない。
「ソフトウェアのデリバリーでリードタイムが重要だってことは、ニコール・フォースグレン博士とジェズ・ハンブルの研究でわかったことだ。コードデプロイのリードタイム、コードデプロイの頻度、問題解決時間を見れば、ソフトウェアのデリバリー、運用の能力、組織の能力がわかる。そして、これらは社員の燃え尽き、社員の士気、その他さまざまなものと相関してる -
-
Posted by ブクログ
・ITの4種類の仕事―ビジネスプロジェクト、IT運用プロジェクト、プログラム変更、予定外の仕事。技術的負債を放置しておくと、予定外の仕事しかできなくなる
・（過度なセキュリティを追求する担当者に対して）会社にとって最大のリスクは、監査所見を解決できないことではない。会社が生き残れないことだ
・「お前はボブではなく、俺の下にいるこを忘れるなよ。この体制で働けないなら、お前をすぐクビにする必要がある」
・「人は、終わりなく続くホラー映画のように、自分には結果を変える力がないと思うと、不満をためてありがたみを感じなくなる。そのことが人間としての自分の価値を傷つけないわけがない。そういう状況を変えなけ -
-
-
Posted by ブクログ
IT運用における問題や問題に対する対処、
運用改善、最終的には開発・運用の一体化までを
小説として書いた本。
嫌がらせをされるシーンもあったりと、
実際のIT運用に近い話が多かったような気がする。
おかげで面白く読むことが出来ました。
IT運用から改善を実現するには、
①現状をまずは改善する（小さく改善し、時間を作る）
・運用フローを可視化する
・運用を管理する
・ボトルネックを見つける
・運用フローを見直す
②業務とITの関連を把握する（業務を理解する）
・どんな業務にITが必要なのか
・そもそもどんなことにITを使っているのか
・トラブルが起きて困ることは何か
※個人的 -
Posted by ブクログ
ザゴールのIT版。
基本的に、システム（ある程度規模がある）開発経験者でなければ、用語の理解や、開発現場の雰囲気の調整に難航しそう。また、加えて登場人物の多さも気になる。
日本のシステム開発従事者も、スキルや契約や何より、DevOpsの先にあるITが何のためにあるのかという視点を主人公率いるユニコーンチームみたいに持てると、本当に素晴らしいことだと思う。システムを守るため、ではなくビジネスを強化、補強、推進するために、DevOpsでIT頑張ろうという話。
devops（以下、抜粋）
ビジネスニーズに即応するということは、ビジネスの変化に応じてITシステムの機能が追加されたり、変更された -
Posted by ブクログ
IT部門の開発と運用、延いては全社的なビジネスとITの融合を図るまでの過程を本書でも言及されている「ザ・ゴール」のような小説仕立てで描き、コミュニケーションとコラボレーションの推進を訴え、目的の共有と全体最適を啓蒙する。
トラブルに次ぐトラブル、ビジネス側から突きつけられる厳しい要求、正にデスマーチ、そして急転直下の和解とハッピーエンド、ハラハラドキドキしながら読み進めることができた。ただ、主人公のビル・パーマーが辞意を表明したからステーブ（CEO）が謝るまでの四日間での心変わりと謝罪が良く分からなかった。トップと対立したら辞意を表明すれば事態が好転する程、世の中都合よくできてないと思う。
-
Posted by ブクログ
ITのプロジェクトがどんな風に進んでいくのか、
また最近流行りの（？）DevOpsがどんな概念なのかを知りたくて、
まずは小説から入ってみました。
欧米の小説な上に、自分の門外漢な領域でもあるので、
話の内容が完璧には分かりませんでしたが、
「それって情シスの仕事でしょ？」と安易に考えていたことに、
とても広い領域があって、
会社の戦略との繋がりも意識していく必要があるということが
よくよく分かりました。
結構骨太で、読むのがっ大変だったのですが、
読み進めてみると、大好きな本である「ザ・ゴール」のことが言及されていたりと、
どんどんストーリーにのめり込んでいきました。
非ＩＴ人間がこの -
-
Posted by ブクログ
思ったより読みやすかった。技術スタック的には、自分もやってきたのが並んでて、納得感あった。あるあるネタも、自分も経験あるやつ並んでた。自分のキャリア的に、大手SIerの経験がないのもあるだろうけど、ここまで官僚主義的手続きに技術レイヤまで縛られてる組織の中の人になったことがないので興味深く読めた。今のお客さんは、そーゆー組織多いので。お客さん全部、パーツ・アンリミテッド社より組織階層が深いので、うーん、とゆー感じではあるけど。大きい組織で、ビルドとかデプロイに無頓着なコーダがいるのは、個人的にゼロ年代後半には意識してたけど、今は減ったのかなあ。最後に出てくるコアとコンテキストの整理は、ちょうど
-
Posted by ブクログ
読みにくい本だ…。それほど目からウロコでもないような話題をタラタラタラタラ、翻訳書独特のの長ったらしい文章で説明し、「章タイトルは【最初に手をつけるバリューストリームの選択方法】なんだけど、バリューストリームのカテゴリの話ばかりして選択方法の話が出てこないぞ…」こんなのばっかりで、「これ何の話だったっけ？」と戻り読みすることが多くなかなか先へ進まない。
理想はそうなんだけどさー、どうやって実現にこぎつけりゃいいのよ？ケーススタディとやらも「日常業務の一部として問題を見つけ、修正していくことで、技術的に負債をマネジメントしていった」みたいな抽象的記述ばっかりで、いやいやクソ忙してくてそれどころ