こんにちは。Findy Tech Blog編集長の高橋（@Taka_bow ）です。
本記事は、2025年7月にファインディが開催した「開発生産性Conference 」のキーノートスピーカーとしてお招きした Gene Kim氏 の基調講演を、日本語の全文書き起こしとしてお届けするものです。
Gene Kim氏は、ベストセラー『The DevOps 逆転だ！（The Phoenix Project）』『The DevOps ハンドブック（The DevOps Handbook）』の著者であり、1999年から26年にわたり高い成果を上げるテクノロジー組織の研究を続けてきた人物です。
本講演では、DORA研究の成果、勝つ組織に共通する普遍的な原則、そして生成AIがもたらす変革について語られました。
前編では、DORA研究によるハイパフォーマーの実態、DevOps Enterprise Summitで出会った多様な事例、そしてスティーブン・スピアー博士との共著『Wiring the Winning Organization』から導かれた"勝つ組織の魔法"のフレームワークを紹介します。
後編では、その魔法を解き放つ3つのテクニック（巧遅化・単純化・増幅）と、生成AI・バイブコーディングの実践について紹介します。
後編はこちら
tech.findy.co.jp
講演動画
conference.findy-code.io
※ 視聴にはFindy Conferenceへのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。
日本語訳全文
オープニング ─ 26年間の研究とDevOpsへの道
Gene Kim氏： ありがとうございます。
（会場拍手）
私は高業績のテクノロジー組織について1999年から研究しています。創業者兼CTOとしてTripwireという情報セキュリティの会社に勤めていた頃からです。
私が研究対象としてきた高業績の組織は、開発プロジェクトの納期内でのパフォーマンスが申し分なく、運用の信頼性・安定性、セキュリティ・法令遵守体制も万全でした。知りたいのは、彼らがどうやって見事な変革を成し遂げたか、どうすれば他の組織が追随できるかということです。
ご想像の通り、この26年の間に多くの驚きがありました。最大の驚きは、私がDevOpsムーブメントのど真ん中に引き込まれたことで、これは極めて緊急かつ重要な動きだと考えています。
DevOpsは多くの産業に変革をもたらしましたが、それ以前で最後に目にした大変革は、恐らく1980年代にトヨタがアメリカ市場に進出した時だと思います。
彼らは見事に、ほぼすべての米自動車メーカーを完全に打ち負かしたわけですが、根底にはリーンの原則がありました。DevOpsの土台にもなっている原則です。
テクノロジーのバリューストリームに適用すると創発的なパターンが出現し、1日に数十件、数百件、さらには数十万件のデプロイが可能になり、世界水準の信頼性・セキュリティ・安定性も維持したままです。
10〜15年前には考えられなかったことです。少なくとも当時の私は、無理だと思っていました。しかし、今では多くの組織が実現しています。
今日は、私がこの26年で学んだ大事なことをいくつか紹介しようと思います。
私の著書をご覧になった方もいると思います。『The DevOps 逆転だ！』や『The DevOps ハンドブック』などですね。翻訳本を監修してくれた榊原彰さんに昨夜会えたんです。 11年越しの願いがやっとかないました。
補足
『The DevOps 逆転だ！』（原題：The Phoenix Project）および『The DevOps ハンドブック』（原題：The DevOps Handbook）は、いずれも榊原彰氏（パナソニックコネクトCTO：写真右）が監修、長尾高弘氏が翻訳を担当しています。
11年越しの初顔合わせ
さて、昨年こちらのイベントでニコール・フォースグレン博士が登壇しました。
彼女とは6年以上、研究を共にしてきた仲です。内容は、ハイパフォーマンスとはどんな状態か ── それがDevOps研究の現状です。
今日は皆さんに4つのことをお話しします。
1つはニコール・フォースグレン博士と行った研究についてで、ハイパフォーマンスの実態とそれを予測する行動とは何かという話です。
次に、スティーブン・スピアー博士とこの4年で学んだことを紹介します。トヨタ生産方式を長年にわたり研究してきた人物です。
共著『Wiring the Winning Organization』の内容をベースに、DevOpsについて話します。既にご存じの内容もあるでしょう。ただ、何が驚きかというと、トヨタの現場管理者ならすぐに理解・共感できる内容です。
それから、昨日すばらしい講演をしたケント・ベック氏のように、私も生成AIを使ったバイブコーディングに取り組んでおり、非常に楽しく過ごしています。昨年学んだことを共有したいと思います。
DevOpsのビジネス価値は我々の想定よりさらに高い
先ほど、ニコール・フォースグレン博士とジェズ・ハンブルと進めた研究についてお話ししました。ジェズは『継続的デリバリー』の著者で、私達は『The DevOps ハンドブック』を共著しました。
私たちは2013年から2019年まで、6年間の間に3万6000人を対象に調査を行い、高業績な組織はどのような状態で存在するのか、ハイパフォーマンスの実態を調べました。結果は6回とも同様 ── ハイパフォーマンスな組織は存在し、そうでない他者をはるかにしのぐということでした。
その判断基準とは？
私たちが発見したのは、ハイパフォーマーは1日に複数回デプロイしているということです。他者と比べて、頻度が2桁多いのです。もっと重要なのは、デプロイにかかる時間の短さです。バージョン管理システムでコードをコミットしてから、統合してテストしてデプロイするまでの時間 ── つまり顧客に届くまでです。
1時間以内であることが分かりました。リードタイムの違いが2桁なのです。
しかも作業が速いだけでなく、結果も伴っています。彼らがデプロイを行う時に失敗する確率はどの程度なのでしょうか。業務に支障が出る重大度1（SEV1）のインシデントの発生率は？ その可能性は7分の1なのです。
そしていざ何かが起きた時は ── 失敗は必ず起こるものだと言いますからね ── 1時間以内に解決できるのです。これは他者と比べて3桁も短い障害復旧時間になります。
スティーブン・スピアー博士がトヨタ方式を研究していた時、トヨタは生産性が4倍だと分かりました。床面積とサイクル時間は半分にも関わらず、生産物は2倍なのです。ここではそれが4倍どころか、100倍、1000倍なのです。ケント・ベック氏も言っていましたが、ソフトウェアのすばらしいところです。
品質についても多角的に見てきました。ハイパフォーマーは情報セキュリティの目標を日々の業務に取り入れているため、セキュリティ問題の修正に費やす時間は半分でした。
2014年に私たちは別のことに目を向け始めました。これらのハイパフォーマーは技術的に優れていただけでなく、あらゆる指標で数値が高かったのです。
収益性や市場シェア、生産性の目標を上回る可能性は2倍でした。組織が政府機関や軍などといった非営利団体であっても同じことが言えて、組織とミッションの目標を達成する可能性が2倍でした。顧客満足度や量と質の目標においても同様です。
これらはあることを示唆しています。価値の提供やミッションの達成にも、テクノロジーのバリューストリームと同じ作業が必要なら、DevOpsの原則やパターンはその目標達成に役立ちます。
もう1つの興味深い指標は、このような業績の高い組織では、従業員が勤務先をいい職場として同僚や友人に薦める確率が2倍でした。
"従業員ネットプロモータースコア（eNPS）"という ── 収益性や収益成長率と深い相関関係にある指標です。ですから、デプロイができない組織やしづらい組織だと、友人に自分の職場を薦めたいとは思わないということでしょう。
DevOps Enterprise Summit ─ あらゆる業界での実践事例
数字を超えて、これが示唆するのは、私たちはいかに安全かつ迅速に、高い信頼性を持って確実に、サービスの提供対象の目標、夢、願望を達成するかが大事 なのです。
この11年間 ── "DevOps Enterprise Summit"というカンファレンスを運営してきました。カンファレンスの目的は、大規模で複雑な組織が、FacebookやAmazon、GoogleやMicrosoftと同じように勝利をつかむためのパターンを示すことでした。
補足
数多くのテクノロジーリーダーたちに、どうやってDevOpsを使って市場で勝ってきたかを共有してもらいました。私のお気に入りを一部紹介します。
こちらの男性はMike Carr氏で、ヴァンガード社のCTOです。
ヴァンガードは投資信託を普及させた会社で、9兆5000億ドルの資産を運用しています。1万人以上いる技術者の開発生産性を向上させることによって、先程私がお話しした指標をすべて達成しています。
それによって投資家に価値を ── 投資家というのはつまり、彼らの投資信託を買う人たちですね ── 彼らに価値を還元しています。
お次は世界有数の製薬企業ファイザーのJamie Hook氏です。
彼らの開発生産性の向上は、ある協力関係がきっかけでした。エンジニアリングのVPであるMike Lamb氏と、CISOだったBrian Cincera氏によるものです。
目的は生産性だけでなく、安全性も高めることでした。紹介してくれた開発者の支援方法が驚きで、研究開発、販売、マーケティング、流通など所属する組織に関わらず、重要な社会的目標を達成する支援を行っていました。
補足
皆さんはこう思っているでしょうか ── "よくある話だ"。
では、海軍大佐の例はどうでしょう？
現在は准将ですが、当時は大佐でした。彼はイージスミサイル防衛システムの責任者だったのですが、海上にいる船のソフトウェアをアップグレードする必要がありました。なのに8年も待つしかなく困っていました。
ソフトウェアをアップグレードするには、鋼鉄の穴や隔壁を切り開き、コンピューターを運び出す必要があったためです。
ですが今ではDevOpsパターンにより、海上にいる船を2隻同時にアップグレードできます。
紅海にいる船も含めてです。1970年代に造られた船でこれが実践できたのですから、ほぼどこでもできるはずです。
こちらは米国トヨタのKishore Jonnalagedda氏です。彼は工場の現場にDevOpsのパイプラインを構築し、工場の業務だけでなく、セールス、マーケティング、ポストセールスサービスなどの業務の何百ものアプリケーションを効率化しました。DevOpsの有効性を示しています。
彼いわく、トヨタウェイのおかげで改善の文化が築きやすかったそうです。もちろんトヨタでは"カイゼン"の概念が根づいており、ITの人たちも日々の業務を改善しやすい環境ではあります。
私が一番気に入った事例は、こちらかもしれません。シーメンスのThomas Jachmann氏のケースです。
彼はCTスキャナーのソフトウェアの責任者です。CTスキャナーは病院の画像診断部門に6000台も納入されています。
彼が解決したかった問題は、現場でソフトウェアをアップグレードする認証を得るには6ヵ月という長い期間を要することでした。
そこで彼はテスト自動化への投資を始めました。自動テストであれば、好きなタイミングで認証の段階へと進められます。
認証にはまだ数ヵ月かかりますが、認証が下りるかどうかは技術の問題ではありません。ただ、頻繁なアップグレードの土台はできます。
これが重要だと思う理由は、CTスキャナーで撮る際の出力電力というのはソフトウェアで制御されているからです。
安全性に関わり、重要です。
"うちではDevOpsは無理"と言う友人や同僚がいたら、"どこでもDevOpsは可能"と思い直してほしいのです。
困難でも成功した事例はたくさんありますからね。
過去4年間で得た教訓
スティーブン・スピアー博士と仕事でご一緒したことは先程お話ししました。彼との出会いは約10年前にさかのぼります。MITスローン経営大学院のワークショップに参加した時でした。
有名な方ですが、その理由の1つは1990年代の彼の研究で、彼はトヨタ生産方式を深く掘り下げた第二世代の研究者グループの一員でした。
彼らのような人たちのおかげで、アンドン、カイゼン、現場ウォークなどは海外でも通用する言葉となり、トヨタの手法を学ぶ際に役立っています。
補足
トヨタ自動車公式サイト に詳細があります。
1999年に彼は、最も広くダウンロードされたハーバード・ビジネス・レビューの記事を執筆しました。
タイトルは「トヨタ生産方式の"遺伝子"を探る」です。
補足
https://dhbr.diamond.jp/articles/-/3743 に掲載されています。
私はこちらを2001年に読み、そのすばらしさに驚嘆しました。
彼はこう述べていました ── "3000〜5000人の人間がトヨタの工場で働いているとしたら、その全員が科学者集団の一員で、絶えず検証と改善に努めている"。
よく覚えている言葉です。10年後に彼と仕事をできる日が来るとは、当時は思いもしませんでした。
彼とどんなことに取り組んだかと言うと、『Wiring the Winning Organization』という本を書きました。
補足
邦訳『Wiring the Winning Organization 成功する組織を導く3つのメカニズム』（日本能率協会マネジメントセンター）
私たちの目的は ── まずは驚きますよね。なぜスティーブン・スピアー博士と私なのかと。
彼はハードウェアと製造業、私はソフトウェアの出身。
一見、話が合わなさそうです。ですが、私たちが読んできた本や論文を見ると、かなり重なっており、私たちは疑問を持ちました。
次のものの共通点は？ ── アジャイル、DevOps、トヨタ生産方式、リーン生産方式、安全文化。
そして私たちが導き出した結論は、いずれもより大きな全体の不完全な表現であり、3つのメカニズムがそれらを結びつけているのです。
この点を明確にするために、勝つ組織が持つ"魔法"の3つの側面をシェアしたいと思います。
魔法の側面① ── 必要なものが手に入る
まず1つ目の側面というのは、誰もが常に重要な問題に取り組んでいます。
平行して行っているのが理想です。必要な時に、必要なものが手に入るからそれが可能なのです。適切な形式とタイミングで、適切な関係者から手に入るのです。例えばどんなものかと言うと、情報や承認、要件や決定権、テスト結果、生産ログなどがそうです。
その重要性を理解するには、魔法がない状態を想像します。つまり、誰もが行き詰っている状態です。必要なものが適切な形式とタイミングで手に入らないのが原因で、皆に尋ねて探し回るしかありません。だから小さな取り組みでも英雄的な努力を要するのです。
これがどれだけ重要なことかを提唱するために（ダメな例として）、「The Checkbox Project」という論考を友人たちと書きました。著書『The DevOps 逆転だ！』に近いものです。
補足
本稿のベースとなったのは、実際の出来事です。ある大企業で「サービスにシンプルなオプトイン用チェックボックスを追加する」という一見単純なタスクが、構想から完成まで12ヶ月かかり、コストが2,800万ドル超に膨れ上がりました。この実例をケーススタディとして、組織の「配線の仕方」がいかにパフォーマンスを左右するかを解説しています。
著者はApple・John Deere・Scaled Agileなど多様な組織のリーダー6名（Kamran Kazempour、Chris Hill、Steve Pereira、Dean Leffingwell、Amy Willard、Gene Kim）による共同執筆で、2023年9月26日にFall 2023 DevOps Enterprise Journalの一部として公開されました。
The Checkbox Project 入手先
https://itrevolution.com/product/the-checkbox-project/
この話のプロジェクトの目標は、1つのチェックボックスを表示することです。
何百万もの顧客に表示され、それにチェックを入れると、顧客は月額5ドルのサービス契約を結ぶことになります。
問題はそれが4つの顧客チャンネルにまたがり、20のチームによる作業が必要な点です。CEOレベルのサポートを必要とし、連日行われる作戦会議には12ヵ月で2800万ドルかかると見積もられています。さらなる問題は、プロジェクトが成功すると思っている人が20％しかいないという点です。
なぜなら過去2回は失敗したからです。
チェックボックスの表示は技術的に難しいことではありません。実際に大変なのは、調整やコミュニケーション、優先順位づけやスケジューリング、政治工作や説得、エスカレーションなどです。誰も必要なものが得られないとこうなります。これが魔法の1つ目の側面です。
魔法の側面② ── 弱いシグナルが検知される
次に2つ目を紹介します。
至る所で活発なフィードバックループが機能し、些細な失敗シグナルでも検知され、増幅されます。そうすれば迅速な対応でミスを防いだり、修正したりできます。このフィードバックを通して人々は学び、上達し続けられます。ただ、それはフィードバックが適切な人に、適切かつ実行可能な形式で届いた場合に限ります。
再び重要性の確認のため、魔法がない事態を想像します。フィードバックループが弱いか、遅いか、存在すらしない状態です。あるいは間違った人に届く状態です。
それだと失敗が検出されないので、時間の経過とともに拡大してしまいます。小さな問題が雪だるまのように膨らむのです。
シグナルは生成されるものの、システムで抑制されてしまうか、消されるケースもあり得ます。
悪いニュースを伝えると嫌な目に遭うような組織だと、それを恐れてこういうことが起こります。良くありませんよね。これが魔法の2つ目の側面です。
魔法の側面③ ── 計画と実践に十分な時間がある
そして最後の3つ目です。
計画、実践、実験、改善のための十分な時間が確保された状態です。
最も危険かつ重要な事態は、稼働してからではなく、リスクが低い計画と実践の段階で起こるのが理想的です。そうすればやり直しが容易なだけでなく、安全に失敗し、学び、改善することもできます。
そうやって教訓を得ていくことで、より良い仕事につながります。
ここで再びこの重要性を理解すべく、最も重要な作業をすべて本番稼働後に行うしかない事態を想像します。
元に戻すことも、やり直すこともできず、小さなミスが大きな失敗を引き起こします。学べるような状況でもありません。
スピードアップのために一度ペースダウンする時間も、『ノコギリの刃を研ぐ』ために手を止める時間もありません。
明らかにそれは良くない状態で、11年前に発売した『The DevOps 逆転だ！』でも語られている話です。
補足
3つのレイヤー ── 作業の構造を理解する
さて、この3つの側面に名前をつけて説明しますが、先にもう1つお伝えしておきます。
これは最初にスピアー博士が類型化した内容で、私は重要だと思っていませんでした。ですが徐々に重要性が分かってきて、世界の見え方まで変わりました。
私たちが提唱するのは、作業には3つのレイヤーがあるということです。
レイヤー1 は目の前の作業対象です。たとえば患者だったり、取り組んでいるコードだったり、本番環境で動くバイナリだったりします。
レイヤー2 は私たちが使うツールや技術です。たとえばMRI装置、CTスキャナー、X線装置、IDEなどです。Kubernetesプラットフォームもですね。
しかし製造業やソフトウェアで鍵を握るのは レイヤー3 で、社員やチームを編成する役割がある管理システムです。ここで誰と誰が話すかが決まります。その頻度や内容、形式についてもここで決まるのです。
製造業の組織における非常に有名な事例をスピアー博士から教わりました。レイヤー1とレイヤー2は何も変えなかった事例です。
北カリフォルニアのフリーモントに非常に有名な製造工場があります。
ゼネラルモーターズの工場だった頃は、北米どころか世界トップクラスの業績の悪い自動車工場でした。
GMとトヨタの合弁会社の拠点となり、2年も経たないうちに日本の工場レベルの業績をたたき出しました。人も床面積も設備も、何一つ変えていません。
レイヤー1とレイヤー2は変化なしで、唯一変わったのがレイヤー3でした。
私たちの業界では、ソフトウェアアーキテクチャに当たります。リーダーが定める部分です。
一度にたくさんの仕事をするのか、小さく分けて仕事をするのか？ フィードバックのスピードは？
レイヤー3は非常に重要だとお伝えしておきます。
補足
カウチのメタファー ── DevOpsの本質
製造業でもソフトウェアでも、良いシステムを作るには3つの方法があります。
魔法の3つの側面が目指すのは、弱いシグナルを増幅できるかどうか、スピードアップのためにシステムをスローダウンできるか、そしてシステムを分割することで簡素化できるかです。
小難しく聞こえますよね。スティーブン・スピアー博士との研究で、最も鮮明に感じた話をここでご紹介します。
2人でカウチを動かす話です。スティーブとジーンです。
スティーブとジーンが行っているのは、ただの肉体労働で、頭は使わないと思うかもしれません。
しかし、2人で解決しなければならない問題が実はいくつも隠れています。
例えば、カウチの重心はどこか。狭い出入り口を通るにはどう回るべきか。狭いくねった階段を通るには誰が先に行くべきか。体は向き合うべきか、などです。
ただ、コンサルタントもフォーカスグループもここでは必要ありません。
試行錯誤と素早いフィードバック、そして何よりコミュニケーションと調整により、2人は確実に目標を達成するでしょう。
しかしリーダーの力で、彼らの仕事はもっと難しいものにできます。
1つは電気を消すことです。
作業にかかる時間が増え、危険度が増し、カウチや部屋、自分の体を傷つける可能性があります。
他にも様々な方法で変化を加えることができます。
大きなサイレンや大音量の音楽といった雑音を流してみたり、
スティーブとジーンが直接会話できないよう仲介人を送り込んだりもできます。
すると突然、スティーブとジーンがカウチの移動に失敗する姿が想像できます。
なぜなら、問題を解決するのに必要なはずの情報が手の届く範囲にないからです。
要するに、これこそがDevOpsの本質です。
2000年代にデプロイが非常に複雑になり、開発と運用がJiraチケットや要件定義書、プロジェクトマネージャーを介してしかコミュニケーションできなくなると、突然、目標達成に必要な帯域幅が不足してしまうのです。
開発と運用に限らず、技術とビジネスの間、研究開発とマーケと営業など、あらゆるチーム間でです。
スティーブとジーンのカウチ移動は、共同作業における問題解決のメタファーで、彼らのチームとしての成果に焦点を当てています。
リーダー次第で、彼らの仕事は簡単にも困難にもなります。
このカウチは2つのコンセプトを表していると思っています。
1つ目は コヒーレンス（Coherence） です。
スティーブンとジーンはどこまで一体として機能できるでしょうか？
直接話すことができない状況では、もはやチームではなく、ただのカウチを個々に支える2人です。
2つ目は 密結合（coupling） です。
2人でカウチを動かす作業は、2人が2つの椅子を別々に動かすのとは違います。
椅子が2つなら、コミュニケーションや調整は不要です。狭い出入り口を同時に通る時は別ですよ。
私たちが取り組むことの多くは、他のチームと連携して行います。例えば、大規模なカンファレンスの場で何かのプランニングに参加するとします。
何千人もの人が集まってコンテキストを共有し、方向性を決めるのはすてきなことですが、日常業務では行いたくありません。
何千人もの人間が連絡を取り続けて調整するなんて無理です。
代わりに必要なのが、カウチの分割です。
常に連絡と調整に追われることなく、独立して仕事ができるようにするためです。
後編に続きます
後編では、このすばらしいシステムを構築する3つのテクニック ── 巧遅（前倒し）化（Slowification） 、単純化（Simplification） 、増幅（Amplification） ── について、具体的な事例とともに紹介します。さらに、Gene Kim氏自身が体験した生成AIとバイブコーディングの世界についてもお話しします。
後編はこちら
tech.findy.co.jp
今年も開催します！（名前変わります）
『継続的デリバリーのソフトウェア工学』著者 Dave Farley氏と和田 卓人氏の登壇が決定！
スポンサー募集中です。（残り僅か！）
prtimes.jp
We're Hiring
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。
興味を持っていただいた方はこちらのページからご応募お願いします。
herp.careers
