本ブログについて 本ブログの目的 本ブログはアジャイル型開発におけるJira利用方法の一例を提示することで、Jira導入時や利用時の立ち上がりをスムーズに行えるようにすることを目的にしている。 本ブログに沿ったJira運用を行うことで後述するプロジェクトにおける品質保証におけるメトリクスやDevOps実践におけるメトリクスを取得することができるようになる。 なお、本ブログは2025年12月時点のJira Software Cloudを対象としている。また、あくまでも一例であるため、チームの状況に応じて適宜カスタマイズして利用することを推奨する。 本ブログの想定読者 本ブログの

こんにちは。Findy Tech Blog編集長の高橋（ @Taka_bow ）です。 前編では、Gene Kim氏の26年にわたるDevOps研究の旅路、DORA研究によるハイパフォーマーの実態、DevOps Enterprise Summitの多彩な事例、そしてスティーブン・スピアー博士との共著『Wiring the Winning Organization』から導かれた"勝つ組織の魔法"のフレームワークとカウチのメタファーを紹介しました。 後編では、この魔法を解き放つ3つのテクニック ── 巧遅（前倒し）化（Slowification） 、 単純化（Simplification） 、 増幅（Amplification） ── を具体的な事例とともに紹介します。そして最後に、Gene Kim氏自身が体験した生成AIとバイブコーディングの世界をお届けします。 前編はこちら tech.findy.co.jp 講演動画 日本語訳全文（続き） ソシオテクニカルの達人 巧遅（前倒し）化（Slowification） Netflix と Chaos Monkey ── 本番環境での巧遅化 単純化（Simplification） Amazon ── モノリスからサービス分割へ 増幅（Amplification） ウェストラム博士の組織文化モデル 情報理論で文化を診断する トヨタ工場でのシグナル増幅 生成AIから得た教訓 バイブコーディングの価値と注意点 まとめ 今年も開催します！（名前変わります） We're Hiring 講演動画 conference.findy-code.io ※ 視聴にはFindy Conferenceへのログイン、並びに視聴登録が必要です。ご登録頂ければ、他の講演アーカイブも視聴できます。 日本語訳全文（続き） ソシオテクニカルの達人 このすばらしいシステムはどこから来たのでしょう？ 昨年、フォースグレン博士も言及していたロン・ウェストラム博士です。 彼の詳しい話はあとにしますが、彼には"ソシオテクニカルの達人"という言葉を教わりました。 5つの特徴を持つ人たちです。 高エネルギーで高基準。 システム思考なので大規模作業で活躍しますが、小規模作業でも活躍し、質の高い質問ができます。 フロアを歩くのが好きで、自分の仕事が終わると積極的に現場を見て回ります。 このまま、ソシオテクニカルの達人がどんな行動をするかお話ししますね。 巧遅（前倒し）化（Slowification） 1つ目 ── ソシオテクニカルの達人は"巧遅（前倒し）化"します。最も危険度の高い作業は本番環境では行わず、前段階で問題を解決します。 『Wiring the Winning Organization』では24の事例を紹介しており、うち20％はテクノロジー関連です。 しかし驚くべきことに、最もケーススタディが多いのは医療業界でした。 救急部門は非常に危険な場所として知られています。 事故に遭って運び込まれた時、症状が増えて帰ることになる確率は、スカイダイビングやベースジャンプでケガする確率よりも高いのです。 ベースジャンプはビルや崖、ダムなどから飛び降りるスポーツです。病院はベースジャンプよりも危険です。 Ms.モリス 対 Ms.モリソンというケーススタディがあります。 間違った患者が処置を受けてしまった事例で、14もの強力なシグナルが出ていたにも関わらず手術は行われました。 患者自身も"違う"と訴えていたそうです。 明らかに制御不能な状態に陥っている兆候が見られるような時には、システムを停止させるのが正解だと示す事例です。 Netflix と Chaos Monkey ── 本番環境での巧遅化 私たちの業界における巧遅（前倒し）化の最も良い事例は、2011年4月に起こったAmazon EC2の大規模障害でしょう。 具体的にはAWSで最も規模が大きいUS-Eastの可用性ゾーンがダウンしました。顧客数も最大だったので大手顧客もすべてダウンしたのですが、非常に興味深いことにNetflixは例外でした。 NetflixはAmazonのクラウドサービスの利用を公言している大規模ユーザーですが、どうやって危機を乗り越えたのでしょう？ その答えは後日明らかになりました。 彼らは3つの驚くべき内容を明かしました。 "単一障害点は排除せねばならず、Amazonはその最たる存在だ"。 "障害を乗り越えるためには、常に障害を起さなければならない"。 そう言って"Chaos Monkey"の存在を明らかにしました。 ご存じの方も多いでしょうが、このChaos Monkeyはランダムに障害を起こします。クラウド上の仮想マシンに対して、日中にです。 Netflixの開発者でシステムを構築し実行する人間なら、いつでもシステムがダウンし得ると知っているので、障害時に回復力のあるシステムを作ります。 だからAmazonの障害も彼らにとっては日常にすぎなかったのです。 さらに驚くべきことに、Netflixはいくつもの障害を乗り越えてきました。 2014年にはAmazonの大規模リブートがありました。パッチを当てるために全体の5％のサーバーを再起動する必要があったのです。 ぜひスライドをご覧ください。NetflixのChristos Kalantzis氏が言っていたことです。"緊急リブートのニュースを聞いた時、影響を受けるノード数のリストを確認してぞっとしました。特にデータベース周りです"。ただ彼はこうも言いました。"でもChaos Monkeyのおかげで、かかってこい！です"。 結果はどうだったか。Bruce Wong氏が言ったように、2700以上ある本番データベースのノード中、218のノードがリブートされ、そのうち22は正常にリブートされませんでした。 でもNetflixの顧客にダウンタイムは発生しませんでした。 これこそが巧遅化の賜物です。本当に耐障害性と可用性を重視するなら、私たちは恐れずに本番環境で自分たちを試すべきなのです。 技術的な負債を解消することや、"何かが変"と誰かが言った時には耳を傾けることも含まれます。 巧遅（前倒し）化の事例紹介でした。 単純化（Simplification） 2つ目に移ります。次は"単純化"です。 単純化とはつまり、問題を分割することです。大きな問題を小さくし、安全に解決しやすい問題にするのです。方法はいくつもあります。一気に行うことも、段階的に行うこともできます。私のお気に入りの1つはモジュール方式です。 DevOps研究という観点から最も成果が期待できるのは、アーキテクチャでした。何によって測定できるでしょう？ どの程度まで、誰の許可もなしにシステムを大幅に変更できるのか。チーム外の人間と細かい調整を行うことなく、どの程度まで仕事を進められるか。どの程度まで、他のサービスとは関係なくデプロイとリリースができるか。不足しがちな統合テスト環境を使うことなく、必要なテストを任意のタイミングでどこまで実行できるか。 私たちは社内の多くの人間とカップリングされていますが、これらの条件を満たせれば、営業時間内のデプロイも可能で、ダウンタイムも最小限に抑えられます。 Amazon ── モノリスからサービス分割へ 実際に私が気に入っている事例の1つが、2000年代初頭のAmazonの話です。 米国では多くの人が昔のAmazonを覚えています。90年代後半はAmazonで本を注文しました。本と音楽を売っているシンプルなサイトでした。 しかし2002年になる頃には、製品カテゴリが35種類も増えていました。これによりチーム間のコミュニケーションと調整の量が増えました。 AmazonのCTOであるワーナー・ヴォゲルス博士が2004年にある発言をしています。 デジタルチームが直面していた不可解な仕様に関してです。 その仕様とは、音楽やビデオや電子書籍などデジタル製品を購入する際にも配送先住所の入力が必要というものでした。 配送する物など何もないにも関わらず必須だったのです。 デジタルチームは製品カテゴリーごとにあった80もの受注担当チームの元を訪れて変更のお願いをしました。でも彼らの答えはいつも"予算がない"でした。 そんなわけでデジタルチームはやるべきことを達成できぬまま、行き詰ってしまったのです。 理由は、当時のAmazonのソフトウェアアーキテクチャがモノリスで、3500人のエンジニアが全員、1つのカウチを一緒に運んでいるような状態だったからです。 補足 モノリス（monolith）とは、すべての機能が1つの大きなコードベースに統合されたソフトウェアアーキテクチャのことです。 デプロイ件数からも見てとれます。1999年には年間で多数のデプロイが行われていたのが、2001年にはほぼ停止状態となっていました。 年間にわずか数十件で、多くのデプロイが未完に終わりました。 スティーブ・イエギ氏が書いた有名なメモがあります。 Amazonの元CEOで創設者ジェフ・ベゾス氏の有名なお達しに言及した内容で、"チーム間のコミュニケーションはAPIのみで行い、例外は許されない"、"従わない者は解雇する"とまで書かれたものでした。 最後の"良い一日を"はイエギ氏の追加したジョークだそうです。 "ベゾスはスタッフの一日がどうでも気にしない"とね。 それ以外は実際の内容で、 元陸軍レンジャーで当時CIOだったリック・ダルゼル氏が強行しました。 補足 リック・ダルゼル氏はこんな感じの方です。（動画） www.youtube.com 10億ドル規模のプロジェクトでしたが効果も絶大でした。1つのサービスを10に分割し、10から100、さらには1000にまで分割しました。 すると年間数十件だったデプロイ数は、2011年には1日あたり1万5000件、2015年には1日あたり13万6000件にまで増えました。 さて、なぜでしょう？ 彼らはカウチを細かく分割することで、行動に独立性を与えました。おかげでチーム外とのコミュニケーションや調整を行わずに、開発、テスト、デプロイができるようになったのです。 ケント・ベック氏はよく、疎結合を理解するのに30年かかったと話しています。 Gene Kim氏の講演を聞きながら熱心にメモをとるKent Beck氏 私もまったく同じです。疎結合がなぜそれほど重要なのか理解するのに30年かかりました。 補足 疎結合（decoupling）とは、コンポーネント間の依存度を低くし、それぞれが独立して変更・デプロイできるようにするソフトウェアアーキテクチャの設計原則です。前編で紹介した密結合（coupling）の対義語にあたります。 増幅（Amplification） それでは最後のテクニックを簡単に紹介したいと思います。 最初に話した巧遅（前倒し）化は本番前の段階で問題を解決するという話でした。単純化は問題を分割して小さくする話でした。3つ目は弱いシグナルを増幅する話です。大きな問題になってしまう前に、大きな問題と同様に対処するためです。 ウェストラム博士の組織文化モデル 先程のロン・ウェストラム博士。 彼が研究していたのは、医療、航空宇宙、原子炉分野の安全性に関してです。 その中であることに気づきました。安全性は組織文化と相関性が高いということです。 安全性が最低レベルの組織に見られたのは、これらの特徴です。情報を隠ぺいし、悪いニュースのメッセンジャーを攻撃します。 チーム間の橋渡しは行わず、失敗も隠ぺい、新しいアイデアは潰します。良くありませんよね。 真ん中は彼が"官僚的"と呼ぶグループで、人を守るためにプロセスを作ります。わりと良さそうです。 でも最高の組織では、これらの特徴を見いだせます。情報を積極的に求め、メッセンジャーは悪いニュースを伝えるように訓練され、リーダーはそれを聞くように訓練されます。 大野耐一氏が言うように、"問題がないことが最大の問題"なのです。 補足 大野耐一氏はトヨタ自動車の元副社長で、トヨタ生産方式の生みの親とされる人物です。英語では "Having no problems is the biggest problem of all." として広く知られています。 トヨタ生産方式 作者: 大野 耐一 ダイヤモンド社 Amazon Toyota Production System : Beyond Large-Scale Production Amazon 責任が共有されているのでチーム間の橋渡しも推奨されます。アップタイムと可用性はOpsだけの仕事ではありません。情報セキュリティがそうであるように、それは皆の仕事なのです。そして障害が起きてしまったら、とことん調べます。 情報理論で文化を診断する ロン・ウェストラム博士は言いました ── "文化は時に問題となり得る"。なぜなら彼の言葉で言うと、文化は軽くて空気のようなもので、つまり目には見えにくく、実体がないものだからです。 スピアー博士と私が挑戦したことの1つは、ウェストラム博士が明確化しようとした内容と同じでしたが、私たちは情報理論を使いました。ウェストラム博士が言っていたことをすべて表現できると思います。 情報はまず生成されなければならず、それが送信され、確実に受信され、対応がなされてから問題が解決したか確認します。助けを求めてきた人に、問題は解決したかと尋ねるのです。 そして ── 私がこれを好きな理由はエンジニアとして診断できるからです。 つまり、文化の問題なのか？ 情報生成に問題があったのか？ そもそも知ってたのか？ それとも送信段階の問題？ 悪いニュースのメッセンジャーは攻撃されるので送りたくないですからね。 それとも受信側の問題？ リーダーに届いていない？ あるいは対応が見送られた？ つまり優先順位の問題？ それとも最後の確認漏れ？ 問題が解決したか確かめていない？ トヨタ工場でのシグナル増幅 スティーブン・スピアー博士の本はすべて読みました。トヨタ生産方式の研究論文も含めてね。ただ『Wiring the Winning Organization』の"増幅"の章で、彼は非常にすばらしい事例の1つを挙げていました。 進行中のトヨタ生産方式に基づいた事例です。 彼がトヨタ自動車の製造工場を直接訪問した時の話でした。 テキサス州サンアントニオにある、トラックやSUVを製造している工場です。トヨタの社員とティア1サプライヤーの人間、合わせて数千人の従業員がいたそうです。 シグナル増幅のスピードの速さを示す事例です。 工場には3000〜4000ものアンドンのコードがあり、それを引くとリーダーの助けが必要な問題発生を意味します。 しかし最も注目すべきことの1つは、米国トヨタのSVPであるKevin Voelkel氏が毎日数時間は現場にいるということです。 補足 Kevin Voelkel氏は、トヨタ・モーター・マニュファクチャリング・テキサスの SVP（シニア・バイスプレジデント） です。 リーダーが現場を実際に見ることの大切さを示すエピソードです。 従業員の仕事ぶりを確かめることで、部下の目標達成のために自分に何ができるかが見えてきます。 私がこの話をした理由は皆さんがリーダーだからです。 現場で従業員の業務を妨げている障害に気づいてあげるために、どうすれば現場の実態を把握できるか考えてみてください。 生成AIから得た教訓 話を締めくくる前に、昨年生成AIを使ってみて私が学んだことをお話ししたいと思います。 正直、これまでのキャリアを通してこんなに楽しかったことはありません。 昨日、ケント・ベックも最高に楽しいと言っていましたね。とにかく目新しくて新鮮で、コーディングの喜びを私の日常にもたらしてくれました。 先程、スティーブ・イエギ氏が書いたこちらのメモをご紹介しました。 私は彼の仕事ぶりの大ファンで、長年彼の話を引用し続けています。AmazonとGoogleで20年過ごしてきた彼と、昨年やっと会えました。 "駆け出しエンジニアの死"と題した講演をカンファレンスで行い、AI登場の影響について話していました。 駆け出しエンジニアは消える運命か？ 答えはノーです。これまで以上に開発者は増えるでしょう。 実際に開発作業にAIを使ってみて、新たな楽しい冒険が始まりました。スティーブとは一緒に本を書き始めました。『バイブコーディングブック』という今秋に出版予定の本です。 補足 原題 "Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond" 2025/10/21 に発売されました。 Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond 作者: Kim, Gene , Yegge, Steve It Revolution Press Amazon 私はあることに驚嘆しました。なんとスティーブは、調子が良い日には、1日あたり7000〜1万2000行におよぶコードを35年間取り組んできたゲームのために書き続けていたのです。 彼は作業を進めるために何百ドルもClaudeに費やしていました。 ここで疑問が湧くと思います。 スティーブのような人だけがそうやって ── 多くタイピングすれば良いわけではないので、数字で比べたくはないのですが ── スティーブ・イエギのように100万行以上のコードを書いてきた実績がないとダメでしょうか？ それとも私のような平凡な開発者でもAIの恩恵を受けられるでしょうか？ 驚いたことに答えはイエスでした。 本を書いていた頃、その最後の80時間で ── 気づけば私は4000行のコードを書いていました。原稿の締切直前で怒涛の編集作業を行っていたさなかにです。 スライドの上の部分は、その4日間の間に本の作業に費やした時間を示しています。 その下はコーディングをした時間です。 本の執筆にAIを役立てるためにバイブコーディングでツールを作っていました。 当時の私は、実は手と手首を痛めてしまっており、4つのGoogleドキュメント間でコピペするだけの作業さえ苦痛でした。 そこで思ったのです。本の原稿をSQLデータベースのようにして、クエリを送ることで目次や文章の一部を取り出したり、章や節ごとに取り出したりして、AIで書き換えられるようにしたいと。 スティーブ・イエギのレベルでなくても、平均的な開発者でも、平均以下の開発者でも、バイブコーディングの恩恵は受けることができます。 バイブコーディングの価値と注意点 そして本の中では ── バイブコーディングの価値を挙げ、英語の頭文字から"FAAFO"と呼んでいます。 より速く欲しいものを作ることができ、より高い目標に挑戦することができ、自分一人で構築できるようになります。他人に頼る必要も、他者と調整する必要もありません。普通ならなかなか難しいことですよね。だけど何より、作業がはるかに楽しくなります。ケント・ベックは数十年ぶりに午前3時にコーディングをしたそうですよ。 何かを作る作業というのは非常に楽しいものですが、それがより手軽で楽しいものになる上、私たちの選択肢も大幅に広がります。 ありがたいことに、つい最近あるAIラボの開発生産性ディレクターとお話しする機会を得ました。 彼は自分たちが抱える問題について教えてくれました。 "社内の開発者の多くは日々の業務にAIを使っていない"、"なぜか皆、手書きが好き"なのだとか。 つまり、 AIの開発を行う企業の中でさえ、リーダーが部下に便利なツールの使用を促している状態なのです。 私たちの多くがこれから直面する課題だと思います。 AIという魔法の技術を活用して仕事をうまくこなすことを勧めていくことになるでしょう。 ただ、バイブコーディングは新たなリスクに満ちています。 本でも、自分たちが実際に経験した失敗について書きました。 単体テストを無効にして、コードが消えました。 理解できない謎のコードベースを作成してしまい、変更できなくなりました。 良いコードベースを台なしにしたこともあり、多くの注意と警戒が必要です。 しかし良いニュースもあり、 AIによって私たちの強みと弱みは増幅されるでしょう。 だから単独作業を可能にするモジュラー型アーキテクチャの存在がこれまで以上に必要になるはずです。 フィードバックループはより速さが求められ、学ぶ文化も必要です。 この本の初期の草稿を読んだ人の多くはこんな反応でした。 "2人はものすごく賢いはずだ"、 "たくさん本を書いて優れた開発者の働き方を研究してきたのに、なぜこんなにも愚かな失敗を？"。 でも例えばですが、これまでずっと馬で移動する人生だったとします。 馬にしか乗ったことがなく、最高時速は約5マイル（約8キロ）程度。 その感覚では時速約50マイル（約80キロ）に耐えられません。訓練を重ね、自分をアップデートしなければ車は大破するでしょう。 そこで本ではバイブコーディングの流れを表すループや、内部、中間、外部の開発に役立つ実践項目も紹介しています。 AI活用のメリットが開発者の皆さんに伝われば幸いです。AIを使えばより楽しく、より大規模な開発を行えますし、開発スピードも上がり、所属する組織にもメリットがあります。 本の発売は今年の秋の予定です。（※発売されました） まとめ それでは話をまとめます。 成功する組織は"魔法"の力で並外れたパフォーマンスを実現します。個人の力ではどんな人でもおよびません。 組織内の問題解決能力や想像力が完全に解放された状態なのです。 逆に魔法がない組織では、創造力も問題解決能力も発揮できないまま全員が終わる運命でしょう。 この魔法を解き放つには3つの方法があります。 "巧遅化、単純化、増幅"の3つでした。 ソシオテクニカルの達人になればそれが実現できます。 高エネルギーで高基準、大規模でも小規模でも活躍し、現場歩きが大好きな人です。 補足 『Wiring the Winning Organization』邦訳では、Slowificationを「巧遅化」、Simplificationを「単純化」、Amplificationを「増幅化」（本記事では「増幅」と表記）と訳しています。 9月にはまた別のカンファレンスを開催します。テクノロジーリーダーが開発チームや企業のためにどうAIを活用しているかなどの話が聞けます。 ぜひそちらにもお越しください。各講演へのリンクや本の抜粋など、本日紹介した内容の詳細に興味がある方は、スライド送信用のアドレスにメールを送ってください。 件名に"Vibe"または"DevOps"とあれば、数分以内に自動返信が届きます。 本日はありがとうございました。 （会場拍手） 前編・後編を通して、Gene Kim氏の26年にわたるDevOps研究の集大成をお届けしました。DORA研究のデータに裏打ちされたハイパフォーマーの実態、製造業からソフトウェアまで共通する「勝つ組織の原則」、そして生成AIがもたらす新たな可能性 ── 皆さんの組織でも、この"魔法"を実践してみてはいかがでしょうか。 Ask the Speaker も盛り上がりました ファインディブースにも来てくださいました 前編はこちら tech.findy.co.jp 今年も開催します！（名前変わります） 『継続的デリバリーのソフトウェア工学』著者 Dave Farley氏と和田卓人氏の登壇が決定！ スポンサー募集中です。（残り僅か！） prtimes.jp We're Hiring ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

こんにちは。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 講演動画 日本語訳全文 オープニング ─ 26年間の研究とDevOpsへの道 DevOpsのビジネス価値は我々の想定よりさらに高い DevOps Enterprise Summit ─ あらゆる業界での実践事例 過去4年間で得た教訓 魔法の側面① ── 必要なものが手に入る 魔法の側面② ── 弱いシグナルが検知される 魔法の側面③ ── 計画と実践に十分な時間がある 3つのレイヤー ── 作業の構造を理解する カウチのメタファー ── DevOpsの本質 今年も開催します！（名前変わります） We're Hiring 講演動画 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　逆転だ！究極の継続的デリバリー 作者: ジーン キム , ケビン ベア , ジョージ スパッフォード 日経BP Amazon The DevOps ハンドブック 理論・原則・実践のすべて 作者: ジーン・キム , ジェズ・ハンブル , パトリック・ボア , ジョン・ウィリス 日経BP Amazon 『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 Enterprise Summitは現在、Enterprise Technology Leadership Summitに名称変更されています。 数多くのテクノロジーリーダーたちに、どうやってDevOpsを使って市場で勝ってきたかを共有してもらいました。私のお気に入りを一部紹介します。 こちらの男性はMike Carr氏で、ヴァンガード社のCTOです。 ヴァンガードは投資信託を普及させた会社で、9兆5000億ドルの資産を運用しています。1万人以上いる技術者の開発生産性を向上させることによって、先程私がお話しした指標をすべて達成しています。 それによって投資家に価値を ── 投資家というのはつまり、彼らの投資信託を買う人たちですね ── 彼らに価値を還元しています。 お次は世界有数の製薬企業ファイザーのJamie Hook氏です。 彼らの開発生産性の向上は、ある協力関係がきっかけでした。エンジニアリングのVPであるMike Lamb氏と、CISOだったBrian Cincera氏によるものです。 目的は生産性だけでなく、安全性も高めることでした。紹介してくれた開発者の支援方法が驚きで、研究開発、販売、マーケティング、流通など所属する組織に関わらず、重要な社会的目標を達成する支援を行っていました。 補足 Brian Cincera氏は2024年にファイザーを離れています。 皆さんはこう思っているでしょうか ── "よくある話だ"。 では、海軍大佐の例はどうでしょう？ 現在は准将ですが、当時は大佐でした。彼はイージスミサイル防衛システムの責任者だったのですが、海上にいる船のソフトウェアをアップグレードする必要がありました。なのに8年も待つしかなく困っていました。 ソフトウェアをアップグレードするには、鋼鉄の穴や隔壁を切り開き、コンピューターを運び出す必要があったためです。 ですが今ではDevOpsパターンにより、海上にいる船を2隻同時にアップグレードできます。 紅海にいる船も含めてです。1970年代に造られた船でこれが実践できたのですから、ほぼどこでもできるはずです。 こちらは米国トヨタのKishore Jonnalagedda氏です。彼は工場の現場にDevOpsのパイプラインを構築し、工場の業務だけでなく、セールス、マーケティング、ポストセールスサービスなどの業務の何百ものアプリケーションを効率化しました。DevOpsの有効性を示しています。 彼いわく、トヨタウェイのおかげで改善の文化が築きやすかったそうです。もちろんトヨタでは"カイゼン"の概念が根づいており、ITの人たちも日々の業務を改善しやすい環境ではあります。 私が一番気に入った事例は、こちらかもしれません。シーメンスのThomas Jachmann氏のケースです。 彼はCTスキャナーのソフトウェアの責任者です。CTスキャナーは病院の画像診断部門に6000台も納入されています。 彼が解決したかった問題は、現場でソフトウェアをアップグレードする認証を得るには6ヵ月という長い期間を要することでした。 そこで彼はテスト自動化への投資を始めました。自動テストであれば、好きなタイミングで認証の段階へと進められます。 認証にはまだ数ヵ月かかりますが、認証が下りるかどうかは技術の問題ではありません。ただ、頻繁なアップグレードの土台はできます。 これが重要だと思う理由は、CTスキャナーで撮る際の出力電力というのはソフトウェアで制御されているからです。 安全性に関わり、重要です。 "うちではDevOpsは無理"と言う友人や同僚がいたら、"どこでもDevOpsは可能"と思い直してほしいのです。 困難でも成功した事例はたくさんありますからね。 過去4年間で得た教訓 スティーブン・スピアー博士と仕事でご一緒したことは先程お話ししました。彼との出会いは約10年前にさかのぼります。MITスローン経営大学院のワークショップに参加した時でした。 有名な方ですが、その理由の1つは1990年代の彼の研究で、彼はトヨタ生産方式を深く掘り下げた第二世代の研究者グループの一員でした。 彼らのような人たちのおかげで、アンドン、カイゼン、現場ウォークなどは海外でも通用する言葉となり、トヨタの手法を学ぶ際に役立っています。 補足 「アンドン」はトヨタ生産方式における異常の見える化のための仕組みです。 トヨタ自動車公式サイト に詳細があります。 1999年に彼は、最も広くダウンロードされたハーバード・ビジネス・レビューの記事を執筆しました。 タイトルは「トヨタ生産方式の"遺伝子"を探る」です。 補足 原題 "Decoding the DNA of the Toyota Production System" の邦訳は https://dhbr.diamond.jp/articles/-/3743 に掲載されています。 私はこちらを2001年に読み、そのすばらしさに驚嘆しました。 彼はこう述べていました ── "3000〜5000人の人間がトヨタの工場で働いているとしたら、その全員が科学者集団の一員で、絶えず検証と改善に努めている"。 よく覚えている言葉です。10年後に彼と仕事をできる日が来るとは、当時は思いもしませんでした。 彼とどんなことに取り組んだかと言うと、『Wiring the Winning Organization』という本を書きました。 補足 Wiring the Winning Organization　成功する組織を導く3つのメカニズム 作者: ジーン・キム , スティーブン・J・スピアー 日本能率協会マネジメントセンター Amazon 邦訳『Wiring the Winning Organization　成功する組織を導く3つのメカニズム』（日本能率協会マネジメントセンター） 私たちの目的は ── まずは驚きますよね。なぜスティーブン・スピアー博士と私なのかと。 彼はハードウェアと製造業、私はソフトウェアの出身。 一見、話が合わなさそうです。ですが、私たちが読んできた本や論文を見ると、かなり重なっており、私たちは疑問を持ちました。 次のものの共通点は？ ── アジャイル、DevOps、トヨタ生産方式、リーン生産方式、安全文化。 そして私たちが導き出した結論は、いずれもより大きな全体の不完全な表現であり、3つのメカニズムがそれらを結びつけているのです。 この点を明確にするために、勝つ組織が持つ"魔法"の3つの側面をシェアしたいと思います。 魔法の側面① ── 必要なものが手に入る まず1つ目の側面というのは、誰もが常に重要な問題に取り組んでいます。 平行して行っているのが理想です。必要な時に、必要なものが手に入るからそれが可能なのです。適切な形式とタイミングで、適切な関係者から手に入るのです。例えばどんなものかと言うと、情報や承認、要件や決定権、テスト結果、生産ログなどがそうです。 その重要性を理解するには、魔法がない状態を想像します。つまり、誰もが行き詰っている状態です。必要なものが適切な形式とタイミングで手に入らないのが原因で、皆に尋ねて探し回るしかありません。だから小さな取り組みでも英雄的な努力を要するのです。 これがどれだけ重要なことかを提唱するために（ダメな例として）、「The Checkbox Project」という論考を友人たちと書きました。著書『The DevOps 逆転だ！』に近いものです。 補足 「The Checkbox Project」は、2023年にIT Revolutionが主催したDevOps Enterprise Forum（3日間のリトリート形式）での議論をもとに生まれたガイダンスペーパーです。 本稿のベースとなったのは、実際の出来事です。ある大企業で「サービスにシンプルなオプトイン用チェックボックスを追加する」という一見単純なタスクが、構想から完成まで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 逆転だ！』でも語られている話です。 補足 「ノコギリの刃を研ぐ（Sharpen the Saw）」はスティーブン・R・コヴィーの『7つの習慣』における第7の習慣。生産性を高めるために、あえて手を止めて自分自身を磨く時間を取ることの重要性を説いています。 3つのレイヤー ── 作業の構造を理解する さて、この3つの側面に名前をつけて説明しますが、先にもう1つお伝えしておきます。 これは最初にスピアー博士が類型化した内容で、私は重要だと思っていませんでした。ですが徐々に重要性が分かってきて、世界の見え方まで変わりました。 私たちが提唱するのは、作業には3つのレイヤーがあるということです。 レイヤー1 は目の前の作業対象です。たとえば患者だったり、取り組んでいるコードだったり、本番環境で動くバイナリだったりします。 レイヤー2 は私たちが使うツールや技術です。たとえばMRI装置、CTスキャナー、X線装置、IDEなどです。Kubernetesプラットフォームもですね。 しかし製造業やソフトウェアで鍵を握るのは レイヤー3 で、社員やチームを編成する役割がある管理システムです。ここで誰と誰が話すかが決まります。その頻度や内容、形式についてもここで決まるのです。 製造業の組織における非常に有名な事例をスピアー博士から教わりました。レイヤー1とレイヤー2は何も変えなかった事例です。 北カリフォルニアのフリーモントに非常に有名な製造工場があります。 ゼネラルモーターズの工場だった頃は、北米どころか世界トップクラスの業績の悪い自動車工場でした。 GMとトヨタの合弁会社の拠点となり、2年も経たないうちに日本の工場レベルの業績をたたき出しました。人も床面積も設備も、何一つ変えていません。 レイヤー1とレイヤー2は変化なしで、唯一変わったのがレイヤー3でした。 私たちの業界では、ソフトウェアアーキテクチャに当たります。リーダーが定める部分です。 一度にたくさんの仕事をするのか、小さく分けて仕事をするのか？ フィードバックのスピードは？ レイヤー3は非常に重要だとお伝えしておきます。 補足 この工場はNUMMI（New United Motor Manufacturing, Inc.）として知られ、1984年にGMとトヨタの合弁事業として設立されました。同じ労働者、同じ設備でありながら、トヨタ生産方式の導入により劇的に業績が改善した事例として、経営学の教科書にも登場する有名な事例です。 カウチのメタファー ── 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