Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Agile and DevOps の歴史をチェリーピック

Agile and DevOps の歴史をチェリーピック

Yasunobu Kawaguchi
PRO

September 13, 2022
Tweet

More Decks by Yasunobu Kawaguchi

Other Decks in Technology

Transcript

  1. アジャイルとDevOpsの 歴史をチェリーピックして 勝手にふりかえりながら 仙人と語らうためのスライド

  2. 川口 恭伸 かわぐち やすのぶ Twitter: @kawaguti アギレルゴコンサルティング株式会社 シニアアジャイルコーチ 株式会社ホロラボ シニアアジャイルコーチ

    一般社団法人スクラムギャザリング東京実行委員会 代表理事 一般社団法人 DevOpsDays Tokyo 代表理事
  3. 研修やってます アギレルゴアジャイル研修 検索

  4. 前段で勝手なことを話しておけば だまって聞いてる仙人がウズウズして しゃべりたいことがたくさん出てくる だろうという戦術 仙人 勝手なことを 話してる 市井の人

  5. ITバブル崩壊 2009年 リーマンショック 2001年 まことに勝手なる歴史観

  6. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 まことに勝手なる歴史観

  7. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 2020年 2022年 2020年のコロナ禍と、

    2022年の戦争やインフレ・円安が、 大きな変動であるのは間違いないと思うので、 何か生活のヒントがあるかもしれない。 まことに勝手なる歴史観
  8. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 2020年 2022年 まことに勝手なる歴史観

  9. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 2020年 2022年 まことに勝手なる歴史観

  10. スクラム the ORIGIN : Jeff Sutherland - Roots of Scrum

    (2005) を語るナラティブ 川口恭伸 株式会社ホロラボ アギレルゴコンサルティング株式会社 シニアアジャイルコーチ
  11. https://www.infoq.com/presentations/The-Roots-of-Scrum/ Roots of Scrum (2005) について スクラムの Co-Creator である ジェフ・サザーランド博士が

    スクラムを作る前に参考にしたり、 作りながら実験した話。 なぜスクラムなのか? 2011年に初めて野中先生と顔を あわせるのですが、その6年前。 北米でもスクラムが劇的に広まる 少し前、だと思います。
  12. スクラムの源流 いかにして日本の製造業が 世界のソフトウェア開発 プラクティスを変革したか JAOO, Aarhus, Denmark, 28 Sep 2005

    ジェフ・サザーランド Ph.D. 認定スクラムマスター研修、スクラムプロセスの開発者 https://www.infoq.com/presentations/The-Roots-of-Scrum/
  13. https://www.infoq.com/presentations/ The-Roots-of-Scrum/ オリジナルのスライド ジェフ・サザーランド ・アジャイルシステムズアーキテクト - 9つのソフトウェア企業でCTO/VPoE - 4つの企業でスクラムのプロトタイプ -

    1993年にEasel社で 最初のスクラムを考案、実施 - 5企業にスクラムを展開 1993-2005 - Ken Schwaber がスクラムを 業界に展開するのを手助けした ・アジャイルマニフェスト起草者、 Agile Alliance 創始者(の一人) ・1/3の時間をスクラム研修、 メンタリング、ピアレビュー、 コンサルティングに https://www.infoq.com/presentations/The-Roots-of-Scrum/
  14. https://www.infoq.com/presentations/The-Roots-of-Scrum/ オリジナルのスライド スクラムの源流 • チームプロセス – シリコンバレーの起業家たち • 竹内・野中 –

    日本の製造業 • 世界をもっとよい場所に – 内なるビジョン • オブジェクト技術とEasel社のSmallTalkプロダクト • オブジェクト指向アーキテクチャ 設計ツールの専門家、ベンダー、顧客 • 進化生物学と複雑適応系 • プロセスと生産性の研究 • ソフトウェア生産性の研究 • 外科手術チーム(人月の神話, IBM) • 邪悪な問題、正しい解決 • ボーランド Quattro Pro プロジェクト • iRobot -サブサンプション・アーキテクチャ
  15. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 北米トヨタ自動車のミッション Toyota Motor Manufacturing North America 1. 米国企業として、地域および米国の経

    済成長に貢献する。 2. 独立した企業として、チームメンバー の安定と幸福に貢献する。 3. トヨタのグループ会社として、お客様 に付加価値を提供することで、トヨタ 全体の成長に貢献する。
  16. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 竹内野中論文(1986)が示した マネジメントスタイル • Type A NASAのウォーターフォール型 • 要求、分析、設計、実装、試験と、

    順に次の工程の部署に引き渡される • Type B 富士ゼロックスのサシミ型 • 前工程と後工程が同席する • Type C ホンダのスクラム型 • 一時は全工程が同席する Jeff SutherlandはこのType Cから、 自らのフレームワークの名前を とった。
  17. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ ラグビーのスクラム

  18. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタにおける制約条件の綜合 • 歴史的には、高品質、製品の多様性、低コストを 同時に達成することはできない、とされてきた。 • トヨタ生産方式は、それとは全く異なる考え方に 基づく。 •

    矛盾を綜合する知識創造によって、トヨタは限界 に挑戦する。 • 高品質、多品種、低コストを一度に実現する。
  19. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 綜合であって最適化ではない 規模/範囲 の経済 バンドル アンバンドル 機械的 フロンティア 有機的

    フロンティア スピードの経済
  20. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 顧客が求めているもの スピードの経済 規模/範囲 の経済 契約 顧客の ニーズ

  21. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ さらに「より多く」「少ない労力で」 1. 開発の後半になっても、変化する要求を歓迎する。 2. 動くソフトウェアを頻繁に提供する。 3. ビジネスマンと開発者は毎日一緒に仕事をしなけ ればならない。

    スクラムは反復的であり、顧客は要件を変更すること ができ、ソリューションは自己組織化のなかで後発的 に生まれます。 プランニング スケーリング 開発 インプリメント (パッケージング)
  22. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 文化を変える – そこが難しい 旧来の組織 新しい組織 中央集権型 分散型 統一的な視点

    多様な視点 もともとの意味 後発的な意味 分析的 創発的 分析から行動へ 実践して学ぶ 合理性 冗長性 確実性 不確実性 戦略的コンセプト 現地の活動 命令型 参加型 階層的 フラット
  23. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ コマンド&コントロールを打ち破る • 伝統的な企業では、戦略は中央で開発される。 • 創発的な戦略は、ローカルな行動によって自己組 織化される。 - 分散型の認知と行動

    • スクラムチームには自己組織化が求められる - 自律的 - 超越的 - 他家受粉 (Cross-fertilization) • チームは自分で仕事を選ぶ - 個人が自分の仕事を管理する - 経営陣は邪魔をしない
  24. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ Google の戦略: マネジメントを取り除く • Rosing氏がGoogleに入社した2001年当時は、「エンジ ニアリング部門にマネジメントがいました。そして、その 構造は、「そんなことをしてはいけない」と人々に言う傾 向がありました。そこで、Googleは管理職を廃止します。

    現在、ほとんどのエンジニアは3人1組のチームで仕事をし ており、プロジェクトリーダーはチームメンバーの間で交 代しています。何かおかしいことがあれば、それがすでに リリースされたプロダクトであっても、チームは誰にも聞 かずにそれを修正します。アジャイル原則#5, #9, #12 • 「しばらくの間、私には160人の直属の部下がいました」 とRosing氏は言います。マネージャーはいませんでした。 それがうまくいったのは、チームが自分たちのやるべきこ とを知っていたからです。それが人々の頭の中の文化的な スイッチが入りました。あなたがボスだ。出番を待つな。 管理されるのを待ってはいけない。" アジャイル原則#1, #3 • そして、もし失敗しても大丈夫。次のアイデアに向かおう。 「賢くてやる気のある人たちが正しいことをする能力を信 じています」とRosing氏は言います。「それを邪魔するも のが、悪なのです。」 アジャイル原則#5, #12
  25. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 多様な視点 • クロスファンクショナルチーム • スクラムチームには、プロダクトの知識、ビ ジネスアナリスト、ユーザーインターフェー スデザイン、ソフトウェアエンジニア、QA、 のすべてがいます。

    • 上級者のスクラムでは、経営陣、顧客、イン ストール、サポートなど、さらにステークホ ルダーを招き入れます。
  26. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタ・プリウス-創発的戦略 • 製品、技術、プロセスの革命 - どの製品ラインにも当てはまらない。新しい視 点で設計されている。 • 多くの技術を使用

    - エンジン、モーター、バッテリー、ブレーキを 組み合わせたハイブリッドシステム • 記録的な速さで開発 - 4年かかるものが15ヶ月で • 重複するフェーズ - 研究、開発、設計、生産 • リーダーが作り、利用し、エナジャイズした場 (Ba)
  27. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 場(Ba)というコンセプト: スクラムの禅(本質) • 個人と組織のダイナミックな相互作用は、自己組織化 チームという形で統合を生み出します。 • それは、個人が相互に作用することができる共通の文 脈を提供するものです。

    • チームメンバーは新しい視点を生み出し、対話を通じ て矛盾を解決します。 • 場(Ba)は、意味の流れとしての知識が出現する、動 きのある共通文脈です。 • 創発された知識はコード化されて動くソフトウェアと なり、自己組織化を通じてプロダクトになります。
  28. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ プリウスのプロジェクトチームは “Ba”をマネジメントした • リーダーは、自発的に形成された場(Ba)を「見つ け」、活用することができる。 • リーダーは、交流のためのスペースを提供することで 場(Ba)を構築できる

    - 会議室などの物理的空間 - コンピュータ・ネットワークなどのサイバースペース - 共通の目標のような精神的空間 • 知識創造(自己組織化)の基盤となるのは、愛、関心、 信頼、コミットメントの醸成である。 • スクラムはTRUTH(真実)、TRANSPARENCY (透明性)、COMMITMENT(コミットメント)に 基づいています。
  29. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 場(ba)のエネルギーは、自己組織化に よって与えられる • 場(ba) が効果的に生まれるためには、自分たちの意図、方 向性、関心、使命によって「エナジャイズ(活性化)」され る必要があります。 •

    リーダーは、自律性、創造的カオス、冗長性、必要な多様 性、愛、ケア、信頼、コミットメントを提供します。 • プリウスの創造的カオスは、目標を要求することで生まれ た。 内山田は、新車開発のあらゆる常識を疑うことをチー ムに要求した。 • 経営陣は、プリウスのプロジェクトチームに大きな時間的 プレッシャーをかけ、それが同時並行のエンジニアリング の極端な使用を引き起こした。 • すべてのレベルで情報への平等なアクセスが重要だった • スクラムマスターとマネジメントは、コロケーション、ダ イナミックな相互作用、フェイス・トゥ・フェイスのコ ミュニケーション、透明性、大胆な目標を促進することで、 場(ba)を「エナジャイズ」しなければならない。
  30. https://www.infoq.com/presentations/The-Roots-of-Scrum/ Graphic by Conchango, Ken Schwaber, and Microsoft UK スクラムスプリントサイクル

    プロダクトバックログ 顧客が求める機能の 優先順位付きリスト スプリント バックログ スプリント内で完 成させる機能 機能をより小さな タスクに分解する 新しい機能 スプリントの 終わりにデモする 毎日15分のミーティ ングを行う。 スクラムマスターは 3つの質問をする 1)昨日なにを達成し ましたか? 2)ゴールを満たすた めに障害になってい るのは? 3)明日までになにを た達成しますか? スプリント: 1か月 作業日: 1日
  31. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイ : Learn by Doing 張富士夫 : 代表取締役社長

    2002 • 私たちが一番重視するのは、実際に実践し、 行動すること アジャイル原則#1 • わかっていないことはたくさんある。だから 「とにかくまずやってみよう」アジャイル原則#3, #11 • 自分の知識の少なさに気づき、自分の失敗に 直面して、もう一度やり直し、2回目の試行で また別の失敗に気づく。そしてもう一度やり 直す。アジャイル原則#11, #12 • 絶え間ない改善によって、より高いレベルの 実践と知識に至る。アジャイル原則#3
  32. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ トヨタウェイは 冗長と失敗を許容する • 生物の進化のような創発的プロセスでは、失敗が つきものである • 早期かつ頻繁に失敗することで、迅速な学習と進 化を実現する

    • 合理的、効率的なアプローチでは大惨事を招く - 大規模システムの65%の失敗率 - Caper Jones, 1993 - 国防総省のシステム 75%の故障率 - Jarzombek, 1999 - 英国のシステム 87%の故障率 - Thomas, 2001
  33. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ プロセスの理論 定義的プロセスと経験的プロセス • プロセスが動作する基本的なメカニズムが合理的に理 解されている場合は、定義された(理論的な)モデリ ングアプローチを採用するのが一般的である。プロセ スが複雑すぎて定義的なアプローチができない場合は、 経験的なアプローチが適切な選択となる。

    Process Dynamics, Modeling, and Control. Ogunnaike and Ray, Oxford University Press, 1992
  34. https://www.infoq.com/presentations/The-Roots-of-Scrum/ 不確実性が求める 経験主義プロセス制御 プロセス アウトプット • インクリメン タルなプロダ クトの変更 制御

    インプット • 要件 • 技術 • チーム Adapted from Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. Courtesy of Mike Cohn, Mountain Goat Software
  35. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ ローカルなアクションが自己組織 化を促す • 個人は仕事を自己組織化する • チームは目標に向かって自己組織化する • アーキテクチャはコードを中心に自己組織化される

    • 反復的な適応によって製品が生まれる • 権威的なアプローチではなく、参加型のアプローチが 必要 • フラットな組織構造
  36. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 最初のスクラム – Easel 1993 • ガント・チャートの廃止 • ジョブタイトル(役職名)の廃止

    • スクラムマスターの誕生 • プロダクトオーナーの誕生 • 毎日のミーティングで自己組織化を促進 • スプリント中の干渉からチームを守る • スプリント計画、スプリントレビュー、デモ、レトロ スペクティブ • エンジニアリング手法にとらわれない • XPのエンジニアリング手法を採用
  37. https://www.infoq.com/presentations/The-Roots-of-Scrum/ スクラムがeXtreme Programmingに与えた影響 From: Reply: Date: Subj: Kent Beck To:

    Jeff Sutherland <jsutherland> 70761.1216@compuserve.com Mon, 15 May 1995 18:01:15 -0400 (EDT) HBR paper HBRからSCRUMの論文の別刷りを入手できる 良い場所はありますか?よく似たパターンを書 いているところなので、できるだけ多くのアイ デアを盗みたいのです。 Kent
  38. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ アジャイルを採用&利用する上で の課題/困難 組織の抵抗 経営陣の無関心 不十分な研修 伴走型の支援がない 公式ガイドラインがない 報酬がごく少ない

    プロジェクト失敗のリスク上昇
  39. https://www.infoq.com/presentations/ The-Roots-of-Scrum/ 主な役割と責任 • プロダクトの機能を定義し、発売日と内容を決定する • プロダクトの収益性(ROI)に責任を持つ • 市場価値に応じて機能の優先順位を決定 •

    30日ごとに機能と優先順位を変更可能 • 作業結果の承認・不承認 • チームが完全に機能し、生産的であることを保証する • すべての役割や機能を超えた密接な協力を可能にし、 障壁を取り除く • 外部からの干渉からチームを守る • プロセスの遵守を保証する。毎日のスクラム、イテ レーションレビュー、プランニングミーティングへの 招待 • クロスファンクショナル、7人プラスマイナス2人のメン バー • イテレーションゴールの選択と作業結果の指定 • イテレーションゴールに到達するために、プロジェクトガ イドラインの範囲内であらゆることを行う権利を有する • 自分自身とその作業を整理する • 作業結果をプロダクトオーナーに説明する プロダクト オーナー スクラム マスター チーム
  40. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 2020年 2022年 まことに勝手なる歴史観

  41. アジャイル開発の時代 川口 恭伸 アギレルゴコンサルティング株式会社 シニアアジャイルコーチ 一般社団法人スクラムギャザリング東京実行委員会 代表理事 一般社団法人 DevOpsDays Tokyo

    代表理事
  42. None
  43. ソフトウェアの品質ってなんでしょう? 30年前なら、動いていれば よかったかもしれないけど、 今は、きれいに整理されていて、 メンテナンスしやすいことが必要。 どうやったら変更しにくくなる? …を考える(たぶん数値では測れない)

  44. None
  45. この本が扱うのは人間だ。 それもソフトウェアを書く人間である。 ここ10年ほどの間、我々は、 共同作業によってソフトウェアを 生み出す方法について研究してきた。 優れたソフトウェアを効率的に 次々と生み出す能力に関心が あるのだ。

  46. 1970-80年代 コンピュータの普及 1990年代 パーソナルコンピュータの普及 ソフトウェア工学の黎明 2000年代 Webブラウザ、仮想化、クラウド、スマホ 2010年代 スマホ/クラウド中心、ビッグデータと機械学習 軽量ソフトウェア開発

    方法論の進展 フリーソフトウェア OSS 2001 アジャイル マニフェスト アジャイルの普及 リーンスタートアップ 2009年 リーマンショック 2010年東日本大震災 DevOps MIT, Xerox PARC, DEC, シリコンバレー Unix, Mac, Windows IE4-, VMware/Xen, Chrome, iPhone, Android ドットコムバブル崩壊 クラウドの普及 ユニコーン企業 GAFA+M ざっくり年表 日米経済摩擦 1985年プラザ合意 2001年同時多発テロ 自動車、半導体産業 1991年バブル崩壊
  47. agilemanifesto.org アジャイル マニフェスト

  48. agilemanifesto.org 個人と対話 動くソフトウェア 顧客との協調 変化への対応 コミュニケーション方法 ソフトウェア開発手法 ビジネスの進め方 リスクへの反応の仕方

  49. ボブ・マーティンがミーティングを招集して、こう言った。 「私たちが言っていることって、似ているように聞こえるんだけど、 これって偶然の一致なのかなぁ?」彼はマニフェストを書くことに 関心があることを付け加えた。(私はマニフェストを書くことには 全く関心がなかったので、マニフェストへの世間の反応は、 私はボブ以上に驚いたんじゃないかと思う)。 ボブはワンダフルな人々をミーティングに招待していた。 “軽量プロセス”の提案者として、他の誰より知られた人たちだ。 北米だけでなく、イギリスを基盤とするDSDMの代表とも 話すことができた。

    Ari van Bennekum はオランダから このミーティングのためだけに来ていた。 XP、スクラム、クリスタル、アダプティブ、FDD、DSDM、 軽量で実践的な開発といわれるひとたち (Andy Hunt, Dave Thomas, Brian Marick) が集まっていた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229
  50. 「こんにちは、私は xx です」というやり取りが一周した後、 車座に座って、お互いをしばらく凝視した後、誰かが言った。 「我々は、アジェンダ(今日話す議題)をどうやって作れば いいんだろう?」 すると、誰かがアジェンダ項目をインデックスカードに 書くことを提案した。XPの人たちは研修用にインデックスカードを 持ち歩いていたのですぐに取り出して書き始め、 書き終わったものを中央の床に放り込んだ。

    急に、過半数の人々が床にインデックスカードを入れ始めた。 残りの人も、同じようにやり始めて、アイデアが尽きたときには、 床のインデックスカードは山になっていた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229
  51. 誰かが尋ねた。 「このカードをどうやってまとめて、アジェンダにするんだろう?」誰 かが言った(私はこのときすでに、誰がなにを言ったかを記録する パワーはなかった)。 「アジェンダの順番に意見がある人は、このカードを並べ替えよう。 そうでない人は、ここを離れてもいい。」 私はトピックの順番は気にしていなかったので、休憩をとった。 私が戻ったとき、インデックスカードは壁にテープで貼られていた。 後で、誰かが「私は他のアジェンダ項目を考えているんだけど、 どうしたらいい?」と言い出した。

    誰かが「アジェンダの空いているところ、好きなとこに貼りなよ」 と答えた。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229
  52. 私はこの作業にずっと付き合ったのだが、 それは、このグループの2つの特徴が私の心を打ったからだ。 リスペクト(Respect) その部屋にいた全ての人が、他の人に対して、絶大な信頼を置 いていたこと。だれもミーティングをハイジャックすることを試み たりしなかった。全員が他の人の意見を極めてじっくりとよく聞 いていた。常に、話している人に最大の信頼をおいていた。 自己組織化(Self-organization) そこは、最も優れた人々の自己組織化の場だった。それまで経 験した他の場では、常に一人の人(または、もっと悪い場合は

    複数の人)がミーティングを "動かそう" とするものだった。偉 い人が部屋にいて、お互いをよく知らない場合、まず最初に権 力闘争が始まりやすい。そこでは、そんなことは一切起こらな かった。 https://kawaguti.hateblo.jp/ entry/20110213/1297531229
  53. None
  54. https://kawaguti.hateblo.jp/ entry/2018/10/31/114305

  55. https://kawaguti.hateblo.jp/ entry/20130217/1361047033

  56. https://speakerdeck.com/ kawaguti/hagechabin 現場感覚や当事者感覚が ない人のSystem1で 棄却される問題 System1 System2

  57. ITバブル崩壊 2009年 リーマンショック 2001年 先アジャイル期 アジャイル期 DevOps期 2020年 2022年 まことに勝手なる歴史観

  58. DevOps の源流 : Flickr 10+ Deploys per Day のトーク (2009年)

    を再訪する
  59. 10 deploys per day Dev &ops cooperation at Flickr JohnAllspaw

    &Paul Hammond Velocity 2009
  60. 10 deploys per day Dev &ops cooperation at Flickr JohnAllspaw

    &Paul Hammond Velocity 2009
  61. 一日に10回デプロイする FlickrでのDevとOpsの協調 ジョン・アルスポー (Ops) ポール・ハモンド (Dev) 2009年オライリーの Velocityカンファレンスにて

  62. Paul Hammond 00:51 しかし、始める前に、Flickrとは何 かについて少し話しておきましょう。 フリッカーについて聞いたことがあ る人は手を挙げてください。さて、 フリッカーを知らない人のために説 明しますと、 Flickrは写真共有サイ

    トです。現在、約30億枚の写真を保 存しています。そして、1日の任意 の時点で、1秒間に約40,000枚の写 真を提供しています。これらの写真 は、約6ペタバイトのストレージを 占めています。子猫がたくさんいる ように見えるかもしれませんが、実 はとても大きいのです。 Flickrは写真共有大手
  63. John Allspaw 01:26 そうそう、今回は歴史的、伝統的に 開発(Dev)と運用(Ops)についてお 話します。今でも、これは通常、開 発vs 運用と考えられています。ハイ デガーの基調講演では、このような 二人の男がいるという図式がありま

    した。よく耳にする言葉ですね。 開発(Dev) vs 運用(Ops)
  64. Paul Hammond 02:45 運用担当者というと、もうひとつのス テレオタイプは、「不機嫌な老人」で す。そう、いつも「ノー」と言う不機 嫌なおじさんです。彼らは、これらの 新しい機能がサイトを壊すのではない かと恐れています。とてもとても指摘 好きで、批判ばかり。

    新しい機能がサイトを壊す
  65. John Allspaw 03:00 そうそう、彼らはいつもノーと言いま す。だってサイトが予期せず壊れちゃ いますよ。ステレオタイプのOPSの マネージャーは、こんな不機嫌な男の ように、「いや、それはやりたくな い」と言うんでしょうか。いや、私は そうはなりたくありません。そんな人

    とだれが働きたいんでしょう?誰もい ませんよ、嫌な奴だから。 批判ばかりの嫌な奴
  66. Paul Hammond 03:24 多くの人が考えるのは、開発者(Dev) の仕事はサイトに新しい機能を追加す ること。そして運用者(Ops)の仕事は、 サイトの安定性と高速性を維持するこ とです。 伝統的なDevとOps

  67. John Allspaw 03:44 これは、ある人にとっては新しい発見か もしれませんが、運用(Ops)の仕事はビ ジネスを可能にすることですよね?もし ビジネス要件として、2週間ごとにサイト を停止しなければならないとしたら、た とえあなたが最大のオンラインゲームプ ラットフォームであり、何百万人もの有

    料顧客を抱えていたとしても、その銀行 顧客は可用性が97%を許容します。 99.999%でなく。これは真実です。こ のサイトの安定性と高速性を維持するこ とは、よくあるビジネス要件です。ビジ ネス要件の話なんです。 Opsの仕事はビジネスを可能にすること
  68. Paul Hammond 04:34 ビジネス、特にオンラインビジネスで 働く上での現実の一つは、ビジネスに は変化が必要だということです。もし あなたのビジネスが立ち止まっていた ら、TwitterやFacebookのような新 興企業に乗っ取られ、追い越されるこ とになるでしょう。

    そして、ビジネスには変化が必要
  69. Paul Hammond 04:34 もちろん、問題はその変化です。ほと んどの障害の根本原因を調べて一般化 すると、「変化」という結論に至りま す。 ほとんどの障害の根本原因は 「変化」なのでしょうか?数日前、数 時間前、数週間前に変更がなければ、

    ほとんどの停電は起こりません。 ほとんどの障害の根本原因は「変化」
  70. John Allspaw 05:09 つまり、2つの選択肢があります。安 定性を重視して変化を阻止するか。そ れとも、賢くなって、必要に応じて変 化を起こせるようなツールや文化を構 築するかです。 安定性を重視して変化を阻止する? 変化を起こせるツールや文化を構築する?

  71. Paul Hammond 05:29 今日お話しする内容のほとんどは、上 手なツールの使い方と、チーム内での 優れた作業文化によって、変更のリス クを低減することです。これらのツー ルを使ってやろうとしていることは、 ある変更がシステム停止や現場での問 題を引き起こさないという確信を高め

    ることです。また、万が一、障害が発 生した場合の復旧能力を高める方法に ついても検討しています。 上手なツールの使い方と、チーム内での優れた 作業文化によって、変更のリスクを低減する
  72. John Allspaw 06:03 もちろん、開発者と同じような考え方 をする人たちがオペレーションをして くれれば、それはとても助かります。 開発者と同じような考え方をするOps

  73. Paul Hammond 07:42 そこで今回は、ツールについて少しお 話ししましょう。そして、このツール の議論でやりたいことは、これらは私 たちに有効なツールの一部です。必ず しもすべての人に使えるわけではあり ません。全体を通して、私たちが使っ ている具体的なツールの例を挙げてい

    きたいと思います。しかし、私たちが 伝えようとしている重要なことは、こ のカンファレンスの共通テーマになる でしょう。 まず、ツールについて
  74. Paul Hammond 07:42 自動化されたインフラとは、そのよう な技術であり、オペレーションの仕事 を可能にするものです。1,000台以 上のサーバーがある場合、個々のサー バーを手動で管理することは現実的で はありません。開発者の視点から見る と、アプリを構築するための一貫した

    予測可能なプラットフォームを提供し ます。 1.自動化されたインフラ
  75. Paul Hammond 09:50 1つの共有リビジョン管理システムがあれば、チーム の誰もが、どこを見れば特定のボックス用の設定の最 新インスタンスを見つけられるのかを知ることができ、 また、アプリケーションで何が起こっているのか、ど こに変更があるのかを知ることができます。これは、 緊急時には本当に便利です。先週の金曜日、私は外で 食事をしているときに、サイトの一部に問題が発生し

    ていることがわかりました。ジョンのチームで働いて いるケビンが私に電話をかけてきたのです。もしソー スコードのリポジトリが違っていたら、ケビンがアク セスできなかったかもしれないし、私が家に帰って ラップトップを取り出し、自分で修正しなければなら なかったでしょう。このように、シングルソースコン トロールは透明性を提供してくれるので、非常に便利 です。 2.共有のリビジョン管理
  76. Paul Hammond 09:50 開発の観点からは、ワンステップビルドを設定することが最 も重要です。ワンステップビルドとは、現在svnのソースコ ントロールシステムに登録されているコードを、本番サー バーにコピーしてサイトを実行できるようなファイルセット にするために必要なすべてのことを意味します。今お見せし ているスクリーンショットは、Flickr内部の開発管理イン ターフェースの一部です。画面の一番下にある「ステージン

    グを行う」と書かれたボタンをクリックすると、SVM チェックアウトが行われ、すべての翻訳、すべてのテンプ レートのコンパイル、最適化のためのコンパイルなどが行わ れます。そして、そのコードをステージング・サーバーにコ ピーして、テストできるようにします。 3.ワンステップビルド
  77. Paul Hammond 14:45 ジョンがすでに述べたように、私た ちのビルドとデプロイのシステムは 完全に自動化されているので、より 頻繁にデプロイすることができます。 また、1回のデプロイを小さくする ことができるので、個々のデプロイ のリスクが少なくなり、万が一何か

    問題が発生した場合でも、何が起 こったのかを簡単に調べることがで きるので、リカバリーが可能になり ます。 小さく頻繁に変更をデプロイ
  78. Paul Hammond 14:45 次に紹介するのは、これまた開発者 向けの話です。それは、フィー チャーフラグと呼ばれるものです。 これは、コードの分岐と考えること もできます。 4.フィーチャーフラグ (コード内でブランチする)

  79. Paul Hammond 14:45 リビジョン管理の分岐システムについて考えてみると、 それはデスクトップソフトウェアを構築する際の現実 に対する反応です。そして、開発チームはすぐに Microsoft Word 1.1の開発を始めます。そして、マ イクを起動し、1.1を起動します。そして数日後、重

    大なセキュリティ上の脆弱性があることに気づきます。 そこで、1.0のコードベースに戻って変更を加え、そ れを出荷しなければなりません。そして、1.2をリ リースします。そして、1.2をリリースすると、また 別の変更を加えなければなりません。つまり、一度に 3つの異なるバージョンのソフトウェアをリリースす ることになります。 旧来のソフトウェアのブランチ戦略
  80. Paul Hammond 14:45 しかし、ウェブアプリケーション のインスタンスが1つしかない場 合は、そうはいきません。私たち が持っているのは、現在デプロイ されているものだけであり、古い バージョンはもう重要ではありま せん。

    Webアプリのブランチ戦略
  81. Paul Hammond 14:45 私たちがこの問題に対処する方法は、 常にトランクを出荷することです。す べての開発をトランクで行っているわ けではありませんが、ブランチで開発 を行い、そのブランチをマージするこ とも可能です。 常にトランクをデプロイする

  82. Paul Hammond 14:45 しかし、常にトランクを出荷すること で、チームの誰もが、現在サイトにデ プロイされているコードのバージョン がどこにあるのかを正確に知ることが でき、どのブランチのどのパッチリ リースが現在リリースされているもの なのかを考える必要がなくなります。

    全員が現在の状態を知ることができる
  83. Paul Hammond 14:45 SVNに入ると、そこにはトランクがあります。 先ほど、SVNではブランチを行わないと言い ました。代わりにコードで分岐を行います。 つまり、すぐにはリリースしない機能を開発 しているときは、条件分岐を使ってその特定 の分岐をブロックしているのです。ここでは、 PHPの例を紹介します。これはSmartyの例

    です。つまり、まだリリースされていないす べての新機能のコードを、実際に本番サー バーに置いておくことができるのです。本番 サーバーでは、設定を変更するだけで、まだ 実際には表示されません。 すぐに使わない機能 = 条件分岐を使って特定の分岐をブロック
  84. Paul Hammond 18:11 この機能により、いくつかの優れたトリックが可能になりま す。1つ目は、本番サーバー、本番ハードウェア、本番トラ フィックでプライベートベータを行うことができるというこ とです。もちろん、私たちには現実的なテストを行うことが できる素晴らしいステージング環境があります。そして、そ のような環境で多くのQAを行いました。しかし、私たちが 発見したのは、テストのために2台目のサーバーを使用した

    場合、ベータ版サーバーと本番サーバーの間で設定の変更が あることに気づくかもしれないということでした。構成管理 を行っていても、ベータ版サーバーでは新機能が完璧に動作 していたのに、本番版サーバーに移行した途端に動作しなく なったということがあります。しかし、本番環境に移行した 途端、頼りにしていたバックエンドの内部ウェブサービスが、 本番環境のダブダブからブロックされていることに気付きま した。そのため機能が動作せず、そのバックエンドのウェブ サービスに緊急の変更要求を出さなければなりませんでした。 一部の人にだけプライベートβ版
  85. Paul Hammond 18:11 これでバケットテストができるようになりました。 これは非常に便利なことです。つまり、新しい コードパスを手に入れて、新しいバックエンドシ ステムの使用を検討している場合、まずは5%の トラフィックをプッシュして、その後10, 20, 30,

    50と増やしていき、一部のユーザーに対し て機能をオンにすることができるのです。異なる バージョンのソフトウェアを異なるサーバーで実 行したり、本番環境に入れたり出したりといった ことを慎重に行う必要はなく、すべてコードで行 うことができます。 バケットテスト = 徐々に利用者を増やす
  86. Paul Hammond 18:11 そして最後に、ダークローンチこれは、 先ほどJonathanがFacebookの話をし たときに言っていたことですが、新し い機能を舞台裏で立ち上げることがで きるのです。例えば、検索クラスタの データベース・サーバーの memcachedボックスに負荷をかける

    ような新機能があった場合、その機能 を裏でオンにして、数週間データの取 得を開始し、そのデータは表示しない ようにします。 ダークローンチ = 表示はしないが動かす
  87. John Allspaw 21:12 100%懸念通りの結果がでたら、それを無効にする ことができます。また、サイトに影響を与えている もの、つまり可用性やパフォーマンスに関わるもの の動作を変更することもできます。データベースク ラスターがたまたま劣化していたり、他のバックエ ンドサービスが劣化していたりして、それが機能に 依存している場合は、これを変更することができま

    す。そして、サイトに影響を与えることなく、ロー ルバックすることができます。多くの場合、ロール フォワードしてオフにします。これらの機能フラグ の中には、単にオンかオフかだけではないものもあ ります。Paulが言っていたように、量を変えられる ノブのようなものもあります。だから良いのです。 ダメなら問題なく戻せる
  88. John Allspaw 21:12 メトリクスの共有。メトリクスを共有す ることは、バージョンコントロールを共 有することと同じです。あなたは私の ビットを見ることができ、私はあなたの ビットを見ることができます。まあ、私 たちはメトリクスを集めています。 5.メトリクスの共有

  89. John Allspaw 21:12 これは私たちのガングリオンのインス トールのスクリーンショットです。37の 異なるクラスターがありますが、どれだ けの数のメトリクスを収集しているかわ かりません。 ここで重要なのは、開発者 はこれがどこにあるかを知っているだけ

    でなく、アクセス権を持っていて、運用 と同じくらい熱心に見ているということ です。オフィスを歩けば、すべての開発 者が少なくともブラウザの1つのタブに、 このようなものを持っています。 Devもサーバーメトリクスを見る
  90. Paul Hammond 24:10 これが、アプリケーションにおける適応型フィードバッ クループの作成につながります。つまり、非同期に起 こっていることがあれば、システムがうまく機能してい ない場合には、アプリケーションが手を引いて、システ ムへの負荷を減らすようにすることができるのです。先 ほど説明したオフラインタスクセンターは、データベー スが過負荷になり始めると、実際にダイヤルバックして、

    データベースがリアルタイムの負荷に対応できるように してくれます。もし10分後にオフラインタスクを実行す る必要があっても、それは大したことではありません。 また、Yahooフォトからflickerへの移行を行った際に は、ストレージの空き容量に応じてスロットルをかけ、 ストレージが不足しないようにしました。 問題が出たらDev側で変更対応できる
  91. John Allspaw 27:58 コミュニケ―ションは、ツールの最後のパー トです。flickerでは、他の多くの場所と同 様に、IRCを多用しています。開発者と運営 者の間の継続的な対話のために使用していま す。IRCは、特にリモートで仕事をしている 人にとっては便利です。それで、このような 会話が行われているわけです。そして、文脈

    があるのは良いことだと思います。そこで私 たちは、前回のFMで、まさにこのようなこ とをするための素晴らしい小さなツールを書 きました。 6.IRCとIMロボット
  92. John Allspaw 27:58 IRCのストリームにイベント、つまりコンピュータ主 導のイベントを流します。例えば、私たちが本当に 気にしている特定のアラートやモニターは、ビルド ログや、何かがデプロイされたときのデプロイログ です。つまり、あなたは会話をしていて、ある書き 換えルールとデプロイでこんな問題が起きているこ とを知らないのです。それについてどう思いますか、

    それともアラートが出ないのですか?そこで実際に やることは、このログに記録された情報をすべて、 検索エンジンに突っ込むことです。そうすれば、2ヶ 月前の木曜日に一体何をしていたのか、何が起こっ ていたのかを知ることができます。以前にもこのよ うな問題があったのか。人間がコンテキストを持つ ようになったということで、本当に助かりました。 IRCツールで過去にさかのぼって調べられるだけでな く、実際に人間の文脈があるわけですから。 ログとアラートをIRCに集める
  93. Paul Hammond 29:28 どのようなツールを導入しても、信じられない ほどの議論好き、闘争心の強い文化の下では、 役に立ちません。そしてもうひとつ、私たちの 仕事ぶりを非常に楽にしていると思うのが、フ リッカーが持つ文化です。自動化されたインフ ラのようにね。申し訳程度のグラウンドゼロの ようなもので、ツールに関しては非常に基本的

    なことをしなければならないようなものです。 そしてここから文化の話
  94. 1.リスペクト

  95. Paul Hammond 29:28 文化に関して言えば これを言うのはちょっと偽 善的ですが、最も重要なことの1つは固定観念を 避けることです。あなたが5年前に一緒に働いて いたカウボーイは、あなたのアプリケーション に関心がなかったり、システムのアップタイム に関心がなかったりしましたよね。しかし、あ

    なたが一緒に仕事をする開発者の全員が彼のよ うなウイルスに感染しているわけではありませ んし、運用担当者の全員が彼のように妨害され るわけではありません。誰もが最悪の事態を想 定するなら、誰もがあなたに最悪の事態を想定 することになるでしょう。 相手をステレオタイプで捉えるな
  96. Paul Hammond 30:36 誰もが繊細な小さな雪の結晶であり、誰もが少 しずつ、彼らは異なる経験を持っており、あな たとは異なる問題解決策を思いつくからです。 それらの解決策はベストなものではないかもし れませんが、少なくとも彼らの提案を尊重すべ きです。もうひとつ重要なことは、人それぞれ の責任を尊重することです。私たちは皆、ビジ

    ネスに対して異なる責任を負っています。つま り、私たちはそれぞれ異なる優先順位を持って いるということです。それを理解し、認識し、 そして尊重することが大切です。 人々の専門性、意見、責任感を尊重する
  97. John Allspaw 31:20 それは、問題について会話をするときに、「いいえ」 と言うことは、「あなたの問題には関心がありませ ん」と言っているようなものだということです。ブ ルーム・フィルターは書けません。開発者が問題を解 決しようとしているのか、運用担当者が問題を解決し ようとしているのか、何を解決しようとしているのか を知ることができます。ここで最もクールなものを見

    つけることができます。規模の壁を乗り越えて成功し た企業のほとんどは、開発者と運用担当者が一緒に なってユニークなソリューションを考え出したところ です。memcachedがいい例です。かつては、データ ベースといえば、DBAや運用担当者がいて、それが彼 らの仕事だったんです。私は開発者なので、コードを 書きます。そして、どこかに魔法のようなデータベー スがあって、私に代わって答えを出してくれる。そし て、memcachedが開発されました。そして、この問 題を解決するために様々なアーキテクチャが設計され ました。そして、それが実現したのは、開発者と運用 者が一緒に仕事をしたときだけです。 ただ「ノー」と 断るより、建設的に
  98. Paul Hammond 32:41 もし、あなたが問題を解決しようとしているときに、 同僚や他のチームからの反応が「それはダメだ」と いうものであることがわかっているなら、解決策を 隠しておくのは、本当にダメなことです。私がやり たいことをジョンが断るとしたら、それはおそらく 正当な理由があるはずです。それを隠してしまうと、 彼に専門知識を提供する機会を与えないことになり

    ます。さらに重要なことは、もし私が何かを隠して いたら、彼はいずれそれを知ることになるでしょう し、知ったときにはきっと怒るでしょう。 べきです。 専門知識を包み隠さず
  99. Paul Hammond 32:41 繰り返しになりますが、開発者にとって、自分の仕事に敬意を 払ってもらうためにできることのひとつは、何かを立ち上げる前、 あるいは何かを提案する前に、その影響について前もってOpsに 相談することです。もしあなたがコードを公開するなら、どのよ うな指標が変わるでしょうか?どのようなボックスでしょうか? CPUの使用量は増えますか?どのボックスの空きメモリが増え ますか?何かが間違っているかもしれないリスクは何ですか?実

    際に何か問題が起きていることを示す兆候は何ですか?では、運 用チームは何に気をつけるべきでしょうか?そして、もし何かが 起こり始めたら?不測の事態とは何か?サイトを継続的に運営す るために、オペレーションチームはどのように回復することがで きるのでしょうか?これらの答えを導き出すための問題は、オペ レーションチームに話を聞きに行く前に、これらの答えを導き出 す必要があるということです。すべての答えを得ることはできな いかもしれませんが、少なくともこれを会話のベースにすべきで す。 対話のきっかけにする
  100. John Allspaw 34:05 そして、信頼へとつながっていきます。最後のスライドには、 この会話を成立させるのに役立つ様々な事柄や推奨事項が書 かれています。つまり、開発者が運用担当者のところに来て、 不機嫌な運用担当者だけど、そんなに長くは不機嫌にならな いだろうと思って、こう言ったとしましょう。クラスタ A,B,Cの低い特性が変わると思うんだ。これを作ったんだけ ど、小さなフックがあって、これをゼロに設定できるんだ。

    何かあったら私のせいにしてください。この機能のために、 このコードを入れるのは良いことだと思わなければなりませ ん。この男は本当に考えているんだな。それだけではなく、 彼はこのことを気にかけています。彼はサイトのアップタイ ムを気にしているし、真夜中に私のチームを起こさないよう に気にしています。 2. 信頼
  101. Paul Hammond 35:25 開発チームは、運用チームがインフラの変更につい て事前に話し合うことを信頼する必要があります。 繰り返しになりますが、本当に当たり前のことをし ているように聞こえます。しかし、私は過去にいく つかの機能不全のチームで働いたことがありますが、 そこではこれが必要なこととして受け入れられてい ませんでした。これは、組織全体のためにベストを

    尽くそうとしている他のメンバーを、皆が信頼して いるということに帰結します。 勝手にやっちまう前に相談する = 信頼
  102. Paul Hammond 36:17 この会話を確実に行うために私たちが実践し ていることは、可能な限り共有のランブック と共有のエスカレーションプランを作成する ことです。つまり、ジョンと私が一緒に座っ て、どんな機能を見ても、あるいはチームの メンバーが一緒に座って、この新機能が運用 面でどのようにサポートされるのかを検討す

    るのです。何を?失敗する可能性のあるシナ リオは何か?誰がその修正に関与する必要が あるのか、そのためにはどのような会話が必 要なのか。リスクは何か?不測の事態に備え て、全員が参加しているかどうかを確認する。 共有のランブック(作戦)と エスカレーションプラン(不測の事態の作戦)
  103. John Allspaw 37:50 私は、開発者がシステム上で何が起こっているかを確認で きるようにすべきだと考えています。電話のタグを渡すの は最悪です。シェルコマンドでは、ただの馬鹿です。とこ ろで、開発者はあなたのマシンで動いているコードを書い ています。もちろんガードレールは重要ですが、誰かに読 み取り専用のシェルアカウントを与えることは、たとえ本 番用のハードウェアで超偏執的になっていたとしても、リ

    スクは低く、実際に何が起こっているかを見ることができ ます。それは、あなたが共有しているメトリクスを超えて、 あなたが運用担当者として共有しているからこそ、彼らが 実際に内部に入り込み、gangliaやNagiosにあるメトリク スだけでなく、あなたのすべてのメトリクスにアクセスで きることを確認できるということです。そして、何が起 こっているのかを見極める必要があり、それを許可するこ とを恐れてはいけません。 透明性: Opsはすべてを共有すべし
  104. Paul Hammond 38:53 文化の3つ目の側面として、失敗に対する健全 な態度についてお話しします。 3. 失敗に対する健全な態度

  105. Paul Hammond 38:53 ここで重要なことは、失敗は必ず起こるとい うことです。起こるかどうかは問題ではなく、 いつ起こるかが問題なのです。 失敗は必ず起こる

  106. Paul Hammond 38:53 もしあなたが失敗を防ぐ方法を考えることに 時間を費やしているのであれば、失敗が起 こったときにどのように対応するかを考える ことに時間を費やしていないことになります。 例えば、航空会社のパイロットは、毎月何日 も何時間もシミュレーターに通い、エンジン が止まったらどうなるかを考えます。何か問

    題が起きたときのための手順や、避難計画な ども策定しています。 防止策を考える時間 vs 回復策を考える時間
  107. Paul Hammond 38:53 Flickrで障害が発生した場合は、オペレーションチー ムの担当者と上級エンジニア数名が待機し、できるだ け早く問題を解決するようにします。私が始めたこと のひとつに、チームのジュニアエンジニア1人か2人に メッセージを送ることがあります。「いいかい、誰も オフィスにいないと仮定して、サイトがダウンしたと 仮定して、君しかいないんだ。そして、停電が終わっ

    た後に、その内容を比較するのです。これは、この種 の問題にどのように対応すべきか、チームの若手メン バーを訓練するための方法なのです。 あなたしかいないときはどうする?
  108. John Allspaw 41:46 非難しないこと。それは本当に基本的なこと のように聞こえます。 4.非難を避ける

  109. John Allspaw 41:46 問題が発生して、ああ、どうしよう?私はど うすればいいの?もしかしたら変わるかもし れません。何が起こっているかを人に知られ たくないと思っているので ログを削除しよう と思うんだけど、どうしよう?とか、鶏の頭 を切って、私のコードに基づいてではなく、

    あなたのマシンに基づいて、やっとの思いで 解明するんですよ。無駄な時間がやたらと多 いんですよね。縄張り意識が物事を解決する 邪魔をしているんだ。 役割分担が問題の解決を遅らせる
  110. John Allspaw 41:46 こうすればいいんじゃないかな?あなたはそ れを理解することができます。あなたは物事 を修正することができます。そして、後でそ のことについて罪悪感を感じたいなら、そう すればいい。これは一般的に起こることです。 私のチームでもPaulのチームでも、「自分の せいだ」と証明しようとする人が出てきます。

    自分のせいで壊れた。だって、1日に10回は 誰にもわからないんだから。そうすれば、彼 らはそれを修正する人になれると思います。 そして、彼らはそれを修正する男になれるの です。 見つけたら自分で直す
  111. Paul Hammond 43:55 たとえ開発者が待機していたとしても、これが最 初のページであることを知るのは、たいてい運用 チームです。夜中に何かを壊してしまい、朝に なってみると30分もの停電が発生していて、5人 もの人が呼び出されて起こされたのは自分のせい だったというシナリオがあったとしたら、ただ謝 るだけでいいんです。

    多くの開発チームが陥りがちなのが、オペレー ションが存在すること、オペレーションが夜中に 起こされて修正してくれることを当てにしている ことです。しかし、自分自身に問いかけてみるの もいいでしょう。「もし、誰かが私の不足分を 補ってくれなかったら、私は何か違うことをする だろうか?もし自分が夜中に起こされていたとし たら、何かを変えるべきだと思います。 Opsが夜中に起こされないように、自分ごとに
  112. John Allspaw 45:56 はっきり言って、これは絶対に簡単 なことではありません。しかし、あ なたは、あなたは、あなたは、あな たが望むならば、お互いに興奮し続 けることは自由です。 これは簡単なことではない