ジーン・キムの一覧
「ジーン・キム」の新着作品・人気作品や、最新のユーザーレビューをお届けします!
-
作者をフォローする
- フォローするとこの作者の新刊が配信された際に、お知らせします。
ユーザーレビュー
-
読むまでは「開発(Dev)と運用(Ops)の対立」からの『一緒にやりましょうね』ってだけの話だと思って舐めてました。
DevOpsをやらなくても生きてる企業はある。けど、今をトップで生きている(生き残っている)企業がこうなのだ、という事を知っておくと良いかもしれない。
Posted by ブクログ
-
出版された年から数年経っているので少し内容が古いかと思っていたが、そういったことを感じさせない内容だった。
間でところどころに事例も入っていて、AgileとDevOpsとCI/CDの関係性もこの本を通じてクリアになった。
職場においてDevOpsは部分的には実践されているが、この書籍の内容をベー
...続きを読むスに改めて改善可能な点を探したくなるような一冊だった。
チームで共通の理解にしたいと思える。
Posted by ブクログ
-
IT業界で働く人は、ひとつの並行宇宙で進行しているような話として読んでみると面白いのではないか。VR転職というか、エアー出向というか。実際にはもっと行きつ戻りつ紆余曲折あると思うが、ひとつのケーススタディとしては申し分ないと思う。でも、アメリカって本当に最初グズグズでも「レジスタンス」よろしく各自の
...続きを読む持ち分を相乗効果にしてけっこうとんでもないことを成し遂げてしまったりするんですよね。これは日本になかなかできなくて、最初のグズグズを見てバカにしてると最終的にはすごい成果を見せつけられて愕然とする、とか。
Posted by ブクログ
-
自動車部品メーカーのIT部門を舞台にした小説です。
この組織では以下のような問題を抱えていて、自分の職場状況と照らし合わせても他人事とは思えません。
・5分で済む変更のために20分かけて登録するのはアホ臭いと誰も使わなくなった変更管理システム
→何かを誰かが変えて何かが起こっても誰も状況を把握でき
...続きを読むない
・優秀な生き字引1人しか知らない部分の多いシステム
→開発でも運用でも生き字引に仕事が集中してボトルネックに
・障害など予定外の割り込み仕事に振り回されるスケジュール
→忙しさに追われ対処療法を繰り返した結果さらなる障害を引き起こす悪循環
・ただでさえ忙しいところに面倒を持ち込むセキュリティおじさん
→本当に必要悪なのか
・etcetc
抽象的で不文律な面が多い仕事というものを分割し、並べなおし、再定義することでコントロール可能なものとし、最終的には自動化により効率面でのブレイクスルーを果たす。。
職場では運用しつつ開発しているのでDevOpsと言われてもイマイチピンときませんが、会社の経営目的とITとの関係を整理するシーンを読んでいて、Devを弊社、Opsを顧客に置き換えると出来ることがあるかも…と感じました。(Opsって保守運用ではなくビジネスの方だったのね…って今更ながら)
小説なので小難しいことはなく、純粋に読み物として楽しめます。
年次を問わずお勧めできる(得られるものは異なると思いますが)本でした。
Posted by ブクログ
-
■5つの理想
第1の理想-局所性と単純性
第2の理想-集中、フロー、楽しさ
第3の理想-日常業務の改善
第4の理想-心理的安全性
第5の理想-顧客第一
エンジニアが現実にいる人ではなく、抽象的な存在として”顧客”を考えると、まず正しい結果を生み出せない。
「ソフトウェアのデリバリーでリードタイ
...続きを読むムが重要だってことは、ニコール・フォースグレン博士とジェズ・ハンブルの研究でわかったことだ。コードデプロイのリードタイム、コードデプロイの頻度、問題解決時間を見れば、ソフトウェアのデリバリー、運用の能力、組織の能力がわかる。そして、これらは社員の燃え尽き、社員の士気、その他さまざまなものと相関してる。」
単純性が大切なのは、単純じゃなきゃ局所性が得られないからだ。システムを疎結合に保ち、機能のデリバリーをスピードアップしたければ、コードの局所性が必要不可欠になる。局所性が実現されていれば、チームはまわりのチームのことを気にせず、お客さんにとって価値のあるものをすばやく開発、テスト、デプロイできる。組織に局所性があれば、チームの外の人々と話し合って調整しなくても決定を下せる。現場の仕事からかけ離れていて、いい判断を下せる基盤がない権威や委員会なんてもんから承認をもらう必要もなくなる」
「…日常の仕事の改善を重視していかなきゃダメなんだ。日常の仕事以上にそっちに力を入れなきゃならないくらいだ。そこまで徹底して局所性の実現に集中しなきゃ、どんなシステムでも時間とともに劣化し、技術的負債のなかに埋もれちまう。…」
「いろんな定義があるけど、私が気に入っているのはウォード・カンニガムが2003年に作った定義だな。彼は、『技術的負債とは、次の機会に書き換えたいと思うもののことだ。』って言ったんだ。人々が技術的負債と呼んでいるもののなかにはいろんなものがあるけど、たいていはクリーンアップしたいもの、単純にしたいものとか単純さを取り戻したいもののことだね。直せば、自信を持って早く安全にシステムを変更できるようになる部分だ」
「技術的負債になるのは、たとえばプログラマーに早くフィードバックを渡せないビルド、テストシステムがそうだし、この手のシステムが動かなくなったときもそうだ。それから、単純なコンポーネントがコンプレクトになって、莫大な労力をかけたり、大事故のリスクを背負ったりしなきゃ何をしてるのかわからず書き換えることもできないときもそうだね。意思決定プロセスや組織構造に局所性がなくなり、小さな決定を下すために、エスカレーションが必要になる、君たちが罵倒する”官僚主義”もそうだ。
私はこういったものを全部“複雑性負債”って呼ぶことにしている。これは単なる技術的な問題ではなく、ビジネスの問題だからね。で、こういった負債にはあれとこれのどっちを選ぶかって問題がかならずくっついてくる。新しい機能を作るか、複雑性負債を全部返済するかっていうようにね、機能を作ることのために自分の時間を全部使っちゃうバカがいると、簡単な仕事が難しくなり、実行に時間がかかるようになるのは避けられないな。そして、0から始めようとすると、どんなにがんばっても、どんなに部下がいても、最終的には自分の重みのために潰れるだろうね」
「理想は5つある。第1の理想、局所性と単純性についてはもう言ったね。システムとシステムを作る組織に局所性が与えられるように仕事をデザインしていく必要がある。そして何をするにも単純でなきゃならない。コードのなかであれ、組織のなかであれ、プロセスのなかであれ、内部に複雑さがあるのはだめだ。外部はもう十分複雑なんだよ。だから、自分たちでコントロールできるもののなかに複雑さが持ち込んだら大変なことになっちゃう」
「第2の理想は集中、フロー、楽しさだ。これはみな日常の仕事で感じるようにしたいことだよ。退屈して自分のためにほかの人が仕事をしてくれるのを待っていないか?全体を見ないで全体のごく小さな一部の開発とだけ考え、デプロイで全体が吹き飛んでいても自分の作業の結果しか見ず、火消し、懲罰、燃え尽きを招いていないか?それとも、小さなバッチ単位、できればひとつの新機能単位でデプロイし、継続的にスピーディなフィードバックを得ているか?これらは、仕事に集中とフロー、挑戦、学習、発見、担当分野のマスター、そして楽しみを生み出す条件だ。
「…第3の理想は、日常業務の改善だ。日常の仕事自体よりも日常の仕事の改善を大切にしなきゃいけない。そのことを教えてくれるトヨタのアンドンの紐についてよく考えよう。第4の理想は心理的安全性だ。問題の解決のためには問題の予防が必要で、問題の予防のためには率直さが必要だ。そして、あとでどうなるかわからないという怖さがあれば、率直になどなれない。工場では、身体的な安全と同じくらい心理的安全性、つまり安心感も大切なんだよ。そして第5の理想は、顧客第一、つまり機能などがお客さんにとって本当に必要なものかどうかを徹底的に批判的に考え抜くことだ。お客さんがこの機能のためにお金を出す気になるか、それとも自分たちの職場の都合からくる自己満足に過ぎないのかってことさ」
「…
技術的負債は、納期と同じ日常のことだ。ビジネスの人々は、納期のことはわかっても、技術的負債もあるということをまったく知らないことが多い。技術的負債は、それ自体ではいいことでも悪いことでもない。技術的負債が生まれるのは、日常の仕事のなかでいつも決断を迫られるからだ。長持ちしないことがわかってても、仕事の都合で近道を通ったり、自動テストを省略したり、特定の条件のためにハードコードしたりすることがあるだろう。日常的に、手作業で環境を作ったり手作業でデプロイをしたりといった次善の方法で我慢する場合もあるよな。こういったことが将来の仕事の進捗にどれぐらい大きな影響を与えるかがわかってないと、大きな問題を起こすわけだ」
「…
これは従者を引っ張るリーダーシップじゃなくて、変身を促すリーダーシップだ。組織のビジョンを理解し、仕事のやり方についての根本的な前提条件を疑うアグレッシブな知性と人の心を動かすコミュニケーション能力を持ち、メンバーの特徴を把握し、支える指導力がなきゃいけない。…」
「…最高の能力を持たなきゃいけない。とことん完璧を追求し、できる限り早くミッションを達成しようという気概を持ち、現状維持に決して満足せず、組織が奉仕する人々をしっかり支えようという熱意を持たなきゃいけない」
マキシンは、ミーティングの経験から、心理的安全性を実現する条件がいかに薄弱ではかないものかを強く感じるようになった。心理的安全性は、リーダー、同僚の行動、雰囲気、自尊心、過去から引きずっている心の傷といったものによって左右される。
Posted by ブクログ
ジーン・キムのレビューをもっと見る