ジーン・キムのリーダーシップスタイル：DevOpsは組織上の問題、技術的なものではない

The Phoenix Projectはビルという架空のITマネージャーについての小説で、プラント管理者が部門をシャットダウンする前に失敗しているITプロジェクトを修正するまでに90日間があります。2013年に出版された、75万部以上を販売しています。素晴らしいフィクションではなく、何千ものCTO、エンジニアリングVP、およびCIOが彼らのCEOに手渡したため：「これは私たちがどのように働くかについての正確な理由です。」

ジーン・キムは創設者として始まりました。彼は1997年にPurdueでTripwire、セキュリティソフトウェア企業を共同設立し、Thoma Bravoが2011年に7億1000万ドルで売却するまで13年間CTO として機能しました。その後、彼はDevOpsで最も影響力のある研究者になり、展開実践のセットを、制約されたシステムを通じて仕事が流れるあらゆる組織に適用可能な管理哲学に変えました。

エンジニアリングチームを実行するか、まったくコードに触れない場合でも、彼の3つの方法フレームワーク（およびそれが動作しないところ）を理解することはあなたの時間の価値があります。

ジーン・キムに関する主要事実

• Tripwire Inc.の創設者とCTO（1997） — セキュリティソフトウェア企業、彼がPurdueで共同設立し、Thoma Bravoが2011年に7億1000万ドルで買収する前に、DevOpsおよび情報セキュリティパイオニアとして13年間導きました。
• 「The Phoenix Project」の著者（2013） — 50万部以上を販売し、CTO就職プログラムで必須読書になったDevOpsクラシック小説形式。
• 「The DevOps Handbook」の共著者（2016） — 定義的なDevOpsリファレンス、Jez Humble、Patrick Debois、John Willisと一緒に書かれました。
• 「The Unicorn Project」の著者（2019） — エンジニアリング文化のための5つの理想フレームワークを導入した続編。
• 「Wiring the Winning Organization」の共著者（2023） — Dr. Steven J. Spearとともに、高パフォーマンス組織の普遍的な理論にDevOpsプレイブックを一般化しました。
• DevOps Enterprise Summitの創設者 — 年次会議（2014年に立ち上げられた）Fortune 500技術リーダーが大規模DevOps変革について事例を提示するところ。
• 高パフォーマンスITオーガニゼーション上の7倍の研究者 — Nicole Forsgren、DORAチームを持つ7つの連続したState of DevOps研究の調査リーダー、現代ソフトウェア操作研究の経験的基礎を生産します。
• IT Revolution Pressの創設者 — 彼がDevOpsおよび技術管理研究を前進させるために具体的に構築した独立した出版社。

DevOpsの3つの方法（The Phoenix Projectモデル）

DevOpsの3つの方法はジーン・キムの高パフォーマンス技術オーガニゼーション用のガバニング フレームワークです。フロー（開発から操作まで、さらには顧客へのバッチサイズを減らし、仕事中進捗を制限することで左から右への仕事の動きを最適化）、フィードバック（製品に戻る右から左へのフィードバックループを作成するチームはソースで問題を修正できる）、および継続的な学習（改善および実験を制度化して、ローカル発見が組織知識になる）。一緒に、3つの方法は、DevOpsを展開実践のセットから、任意の価値流に適用可能な管理哲学に変えます。

リーダーシップスタイルの分析

60/40分割はなぜキムが演算子ではなくエンジニアによって研究されるかを説明しています。彼の研究は操作に根ざし、彼のシステム思考はデータに根ざしており、最もの管理執筆よりも異なる種類の権限を彼のフレームワークに与えます。そのフィールド信頼性と分析的厳密性のその混合は彼が共有する何かです。Werner Vogels、whose distributed-systems work at Amazon is similarly grounded in production reality rather than academic abstraction。

主要なリーダーシップ特性

ジーン・キムを定義した3つのフレームワーク

最初の方法 — フロー

最初の方法は、開発から操作まで、さらには顧客への仕事のフローの最適化についてです。目標は、コード変更が開発者のラップトップから本番まで行くのにかかる時間を減らし、その旅の信頼性を増やすことです。

特定の実践：バッチサイズを減らす（一度に3か月間の仕事を展開しようとしないでください）、仕事中の進捗を制限（同時に飛行中の多くのもの、それはそれを解決するよりも多くボトルネックを作成します）、そして最後の検査ではなく品質で構築します。この最後のポイントはほとんどの組織が間違って取得するものです。開発プロセスの終わりの段階としての品質保証は、ソフトウェアの工場フロアで建設後に製品を検査するのと同等です。欠陥を見つけるまでに、あなたはそれを作成した仕事のためにすでに支払い済みです。

非ソフトウェア演算子にとって、最初の方法はハンドオフを持つあらゆるワークフローに直接翻訳されます。あなたの組織で仕事がどこに列をなしていますか？それはどこでバッチ化されていますか？すべてのバッチは目に見えないWIPコストを蓄積します：承認を待つ決定、法的見直しを待つ取引、優先順位付けエンジニアリングを待つ顧客要求。キムのポイントは、バッチサイズを減らし、WIPを制限することは、単なるスピードについてではないということです。それは問題が化合する前にそれらを見えるようにするについてです。

2番目の方法 — フィードバック

2番目の方法は、価値流で右から左へ素早いフィードバックループを作成することについてです。操作から開発、顧客から製品チーム、製品データから、コードを書いたエンジニアに戻ります。

コア洞察は、本番の問題は週後の事後分析ではなく、彼らが起こる瞬間に最も価値があるということです。キムの研究は、DORAの州DevOpsレポートからのデータによって通知され、インシデントから短い平均復旧時間を持つチームは低いインシデントレートを持つチームより速く学習します。それは反直感的です。より多くのインシデントからより速く回復するチームは稀にインシデントがあるがゆっくり回復するチームを上回ります。学習は化合物。

実用的な含意は重要です。非難のない事後分析、異常を修正できる人々に浮き上がっている監視、および試験失敗に関する即座フィードバックを与える展開パイプラインはすべて、2番目の方法の実践です。エンジニアが顧客サポートで座っている習慣も同様です。フィードバック機構はシグナルが十分に速く行動できる人に到達する場合にのみ動作します。

3番目の方法 — 継続的な学習

3番目の方法は改善の制度化についてです。個々の問題を修正するだけではなく、ローカル発見をシステムが組織知識に変え、新しい学習を生成するために継続的に実験する、

これはキムが最も多くを引き出すトヨタ生産システム研究と高い信頼性の組織からの場所です。実践：改善仕事専用時間（単なる機能配信ではなく）、実験が失敗した実験が罰ではなく学習を生成するように安全に実行できるようにし、それが何であるかについてのチームにまたがるメカニズムを作成し、ローカル。

「The Unicorn Project」（2019）、キムの「The Phoenix Project」への続編は、5つの理想を導入します。これは3番目の方法を可能にする文化的条件です：地域性と単純性（チームは彼らが変えることを所有）、フォーカス/フロー/喜び（最高の仕事をしているデベロッパー）、毎日の仕事の改善（改善時間を保護し、延期されなく）、心理的安全性（人々は恐怖なしに問題を表面化できる）、および顧客フォーカス（顧客インパクトに描かれた決定）。5つの理想は、技術的な実践が配置された後、DevOps変換を維持する文化をキムが名付けようとする試みです。

ジーン・キムがあなたのロールで何をするだろう

あなたがCEOなら、キムが提供する最も有用なものは、なぜあなたの技術オーガニゼーションは必要なだけ速く移動できないかを診断しています。PhoenixプロジェクトのセントラルクライシスはとてもFragileとSlowな展開プロセスで、ビジネスは市場変化に対応できません。あなたのエンジニアリングチームがフィーチャーが6か月かかると言いますが、理由を理解しないなら、キムのフレームワークはあなたに正しい質問を与えます：バッチサイズは何ですか？仕事がどこに列をなしていますか？本番問題を検出し、修正するのにどのくらい時間がかかりますか？それらの質問は制約を表示します。制約はほぼ常に「より多くのエンジニアが必要」です。

あなたがCOOなら、最初の方法はあなたの運用ワークフローに直接適用されます。あらゆるクロス機能プロセスにおいて、仕事が最もに蓄積する段階を見つけます。それがあなたの制約です。キムのポイントは、制約の上流を最適化することは役に立たないということです。仕事は単により速い行列。あなたは制約を特定し、それを上げるために他のすべてを従わせる必要があります。これはGoldrattのロジックが操作に適用されます。ソフトウェア展開パイプラインまたはコンタリアレビュー周期を管理しているかどうかについては機能します。

あなたがプロダクトリーダーなら、2番目の方法はあなたの直接責任です。ユーザーが実際にそれで何をするかとあなたが構築することの間のフィードバックループは、あなたの製品決定を駆動するものです。キムの研究は、それらのフィードバックループの周波数と速度は、あなたの研究方法論の洗練より重要です。あなたは行動できるが四半期の研究は計画サイクルで行動できるの週数ユーザーデータを打ちます。あなたの製品に計器を装備する信号を迅速に生成し、そのシグナルはレポーティング層ではなく決定を下している人々に直接行く、チーム文化を構築し、

あなたがセールスまたはマーケティングなら、キムのコンテンツ戦略は研究の価値があります。「The Phoenix Project」は、彼の対象オーディエンスが、彼らの会社を管理する方法を変える必要がある幹部だったキムの理解のため、存在しています技術が技術的なハンドブックを読むつもりはありませんでした。フレームワークを特定してから、どのフォーマットがそれを決定メーカーに入手する前に、彼は配布ファーストコンテンツ戦略を包装しました。その質問は「どのフォーマットを生成したいか」より面白いものです。

Reworkはエンジニアリングの外の3つの方法を運用化します

キムの3つの方法はソフトウェア配信のために書かれましたが、ロジックはクリーンに一般化し、ハンドオフを通じて仕事が流れる任意のチームに。非技術的なリーダーの質問は：あなたのバッチサイズ、フィードバック遅延、およびブロックされた学習ループはどこですか？Reworkの操作レイヤーは、それらの質問に答えられるようにします。販売、顧客操作、アカウント管理全体にわたるパイプライン可視性は仕事がどこキューに蓄積するかを示しています — 最初の方法の制約狩猟は、展開パイプラインではなく収益操作に適用されます。共有アクティビティフィードと実時間ステータスは、問題の表面化と修正できる人がそれを見ると、2番目の方法の時間を潰す、再構成されました。そして、同じシステムが結果をそれが生産した仕事の隣にキャプチャするため、マネージャーはザ3番目の方法のための原材料を取得します。回想ではなく実データに基づいて定期的な回顧展。キムのフレームワークは、インストルメント化がそれをサポートする方法があるとき、運用をアートからインフラストラクチャに変えます。

注目すべき引用と教室の外の教訓

「The Phoenix Project」から、キャラクターBrent（すべてが依存する上級エンジニア）はキムの最も有用なティーチングツールです。Brentはボトルネックです。管理が彼らの最高のエンジニアを解決策として扱い、すべての問題のリスクについてを扱うことで作成しました。オペレーターが覚えている引用：「不要な仕事をシステムから取り出す能力は、より多くの仕事をシステムに入れることができるより重要です。」すべての組織はBrentを持っています。Brent問題はその人についてではありません。それはそのシステムが作成した人の可用性を制約にした管理システムについてです。

「The DevOps Handbook」から：「ボトルネック以外のどこでも行われた改善は幻想です。」これはGoldrattの制約理論の正確なステートメントが技術操作に適用され、複雑なシステムを管理している場合、あなたの机の上にピン留めする価値があります。ほとんどの組織の最適化の取り組みは、制約ではなく最適化が簡単な部品を目標にしています。結果は、スループットをコントロールしない領域における効率および全体的出力における改善はなし。

キムは、様々な会話およびインタビューで、State of DevOps研究が高パフォーマンスがどのようなもので見えるかについての彼のビューを変えたと言ってきました。彼の研究パートナーシップはNicole Forsgren、およびブロードdevOps コミュニティスケルは、Linus Torvaldsがオープンソースソフトウェアで確立した、開かれた、共同的なethos分布ピアレビューが集中的なゲートキーピングより多くの信頼できるシステムを生成するという考え。デスクの前に、彼は高展開周波数オーガニゼーションがより多くの安定性問題があるだろうと思いました。データは反対を示しました。エリートパフォーマーはより多くデプロイし、より高い安定性を同時に。その発見、スピードと安定性は基礎的な実践が右である場合、緊張していないという発見は、現代ソフトウェア操作研究における最も重要な経験的結果です。

このスタイルが壊れるところ

キムの3つの方法は、開発から顧客までの安定した、識別可能な価値流を持つ製品組織で最もよく機能します。彼らはコンサルティング企業、エージェンシー、または「フロー」が各エンゲージメント上で異なる見えるプロジェクトベースのビジネスに適用することがより困難です。フレームワークはまた、クロスチーム実践を実装する組織的スタンディングを持つIT機能を必要とします。エンジニアリングがエグゼクティブバッキングを欠いている企業で、3つの方法は洞察を生成しますが、動きはありません。

そして、小説形式がキムを広く影響力にしたものはまた、彼のフレームワークが到達できる深さを制限します。「The Phoenix Project」は物語なので、アクセス可能です。それは、物語が可能でなく、完全に指定することがでない限り、制限されます。小説を読んで停止する演算子は診断を取得しますが、治療プロトコルはありません。「The DevOps Handbook」は治療プロトコルですが、それは動作させるため大幅な取り組みが必要です。

---

エンジニアリング実装と文化に関する関連読書の場合は、Martin Fowler Leadership Style、Werner Vogels Leadership Style、Linus Torvalds Leadership Style、Will Larson Leadership Style、およびCamille Fournier Leadership Styleを参照してください。