こんにちは。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
講演動画
※ 視聴には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つのカウチを一緒に運んでいるような状態だったからです。
デプロイ件数からも見てとれます。1999年には年間で多数のデプロイが行われていたのが、2001年にはほぼ停止状態となっていました。
年間にわずか数十件で、多くのデプロイが未完に終わりました。
スティーブ・イエギ氏が書いた有名なメモがあります。
Amazonの元CEOで創設者ジェフ・ベゾス氏の有名なお達しに言及した内容で、"チーム間のコミュニケーションはAPIのみで行い、例外は許されない"、"従わない者は解雇する"とまで書かれたものでした。
最後の"良い一日を"はイエギ氏の追加したジョークだそうです。
"ベゾスはスタッフの一日がどうでも気にしない"とね。
それ以外は実際の内容で、元陸軍レンジャーで当時CIOだったリック・ダルゼル氏が強行しました。
10億ドル規模のプロジェクトでしたが効果も絶大でした。1つのサービスを10に分割し、10から100、さらには1000にまで分割しました。
すると年間数十件だったデプロイ数は、2011年には1日あたり1万5000件、2015年には1日あたり13万6000件にまで増えました。
さて、なぜでしょう？
彼らはカウチを細かく分割することで、行動に独立性を与えました。おかげでチーム外とのコミュニケーションや調整を行わずに、開発、テスト、デプロイができるようになったのです。
ケント・ベック氏はよく、疎結合を理解するのに30年かかったと話しています。
私もまったく同じです。疎結合がなぜそれほど重要なのか理解するのに30年かかりました。
増幅（Amplification）
それでは最後のテクニックを簡単に紹介したいと思います。
最初に話した巧遅（前倒し）化は本番前の段階で問題を解決するという話でした。単純化は問題を分割して小さくする話でした。3つ目は弱いシグナルを増幅する話です。大きな問題になってしまう前に、大きな問題と同様に対処するためです。
ウェストラム博士の組織文化モデル
先程のロン・ウェストラム博士。
彼が研究していたのは、医療、航空宇宙、原子炉分野の安全性に関してです。
その中であることに気づきました。安全性は組織文化と相関性が高いということです。
安全性が最低レベルの組織に見られたのは、これらの特徴です。情報を隠ぺいし、悪いニュースのメッセンジャーを攻撃します。
チーム間の橋渡しは行わず、失敗も隠ぺい、新しいアイデアは潰します。良くありませんよね。
真ん中は彼が"官僚的"と呼ぶグループで、人を守るためにプロセスを作ります。わりと良さそうです。
でも最高の組織では、これらの特徴を見いだせます。情報を積極的に求め、メッセンジャーは悪いニュースを伝えるように訓練され、リーダーはそれを聞くように訓練されます。
大野耐一氏が言うように、"問題がないことが最大の問題"なのです。
責任が共有されているのでチーム間の橋渡しも推奨されます。アップタイムと可用性はOpsだけの仕事ではありません。情報セキュリティがそうであるように、それは皆の仕事なのです。そして障害が起きてしまったら、とことん調べます。
情報理論で文化を診断する
ロン・ウェストラム博士は言いました ── "文化は時に問題となり得る"。なぜなら彼の言葉で言うと、文化は軽くて空気のようなもので、つまり目には見えにくく、実体がないものだからです。
スピアー博士と私が挑戦したことの1つは、ウェストラム博士が明確化しようとした内容と同じでしたが、私たちは情報理論を使いました。ウェストラム博士が言っていたことをすべて表現できると思います。
情報はまず生成されなければならず、それが送信され、確実に受信され、対応がなされてから問題が解決したか確認します。助けを求めてきた人に、問題は解決したかと尋ねるのです。
そして ── 私がこれを好きな理由はエンジニアとして診断できるからです。
つまり、文化の問題なのか？
情報生成に問題があったのか？
そもそも知ってたのか？
それとも送信段階の問題？ 悪いニュースのメッセンジャーは攻撃されるので送りたくないですからね。
それとも受信側の問題？
リーダーに届いていない？
あるいは対応が見送られた？
つまり優先順位の問題？
それとも最後の確認漏れ？
問題が解決したか確かめていない？
トヨタ工場でのシグナル増幅
スティーブン・スピアー博士の本はすべて読みました。トヨタ生産方式の研究論文も含めてね。ただ『Wiring the Winning Organization』の"増幅"の章で、彼は非常にすばらしい事例の1つを挙げていました。
進行中のトヨタ生産方式に基づいた事例です。
彼がトヨタ自動車の製造工場を直接訪問した時の話でした。
テキサス州サンアントニオにある、トラックやSUVを製造している工場です。トヨタの社員とティア1サプライヤーの人間、合わせて数千人の従業員がいたそうです。
シグナル増幅のスピードの速さを示す事例です。
工場には3000〜4000ものアンドンのコードがあり、それを引くとリーダーの助けが必要な問題発生を意味します。
しかし最も注目すべきことの1つは、米国トヨタのSVPであるKevin Voelkel氏が毎日数時間は現場にいるということです。
リーダーが現場を実際に見ることの大切さを示すエピソードです。
従業員の仕事ぶりを確かめることで、部下の目標達成のために自分に何ができるかが見えてきます。
私がこの話をした理由は皆さんがリーダーだからです。
現場で従業員の業務を妨げている障害に気づいてあげるために、どうすれば現場の実態を把握できるか考えてみてください。
生成AIから得た教訓
話を締めくくる前に、昨年生成AIを使ってみて私が学んだことをお話ししたいと思います。
正直、これまでのキャリアを通してこんなに楽しかったことはありません。
昨日、ケント・ベックも最高に楽しいと言っていましたね。とにかく目新しくて新鮮で、コーディングの喜びを私の日常にもたらしてくれました。
先程、スティーブ・イエギ氏が書いたこちらのメモをご紹介しました。
私は彼の仕事ぶりの大ファンで、長年彼の話を引用し続けています。AmazonとGoogleで20年過ごしてきた彼と、昨年やっと会えました。
"駆け出しエンジニアの死"と題した講演をカンファレンスで行い、AI登場の影響について話していました。
駆け出しエンジニアは消える運命か？ 答えはノーです。これまで以上に開発者は増えるでしょう。
実際に開発作業にAIを使ってみて、新たな楽しい冒険が始まりました。スティーブとは一緒に本を書き始めました。『バイブコーディングブック』という今秋に出版予定の本です。
私はあることに驚嘆しました。なんとスティーブは、調子が良い日には、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つでした。
ソシオテクニカルの達人になればそれが実現できます。
高エネルギーで高基準、大規模でも小規模でも活躍し、現場歩きが大好きな人です。
9月にはまた別のカンファレンスを開催します。テクノロジーリーダーが開発チームや企業のためにどうAIを活用しているかなどの話が聞けます。
ぜひそちらにもお越しください。各講演へのリンクや本の抜粋など、本日紹介した内容の詳細に興味がある方は、スライド送信用のアドレスにメールを送ってください。
件名に"Vibe"または"DevOps"とあれば、数分以内に自動返信が届きます。
本日はありがとうございました。
（会場拍手）
前編・後編を通して、Gene Kim氏の26年にわたるDevOps研究の集大成をお届けしました。DORA研究のデータに裏打ちされたハイパフォーマーの実態、製造業からソフトウェアまで共通する「勝つ組織の原則」、そして生成AIがもたらす新たな可能性 ── 皆さんの組織でも、この"魔法"を実践してみてはいかがでしょうか。
前編はこちら tech.findy.co.jp
今年も開催します！（名前変わります）
『継続的デリバリーのソフトウェア工学』著者 Dave Farley氏と和田卓人氏の登壇が決定！
スポンサー募集中です。（残り僅か！）
We're Hiring
ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。 興味を持っていただいた方はこちらのページからご応募お願いします。
