BT

The Phoenix Project後の世界をJohn Willis氏とGene Kim氏が語る

| 作者: Helen Beal フォローする 4 人のフォロワー , 翻訳者 徳武 聡 フォローする 0 人のフォロワー 投稿日 2018年6月5日. 推定読書時間: 10 分 |

原文(投稿日:2018/05/23)へのリンク

読者の皆さんへ。あなたのリクエストに応じて、ノイズを減らす機能を開発しました。メールとウェブで興味のあるトピックのの通知を受けることができます。詳しくはこちら

IT Revolutionは、約8時間に及ぶオーディオブックを発表した。これは、Beyond the Phoenix Project; the Origins and Evolution of DevOpsという名前で、Gene Kim氏John Willis氏の対話だ。

The Phoenix Project, a novel about IT, DevOps and Helping Your Business Winは、Gene Kim氏、George Spafford氏、Kevin Behr氏が書いた2013年発売の書籍で、The Goalへオマージュを捧げている。The GoalはEliyahu Goldratt氏の作品であり、製造業についての小説で、1984年に発表された。Goldratt氏は2003年にBeyond The Goal: Eliyahu Goldratt Speaks on The Theory of Constraintsというオーディオブックを発表している。

Kim氏とWillis氏のオーディオブックは、9つのモジュールを通じた会話の中でDevOpsへの旅に対する個人的な観察や洞察を語っている。この中で、インフルエンサーやDevOpsを今日のような状態にした思考についても言及している。Kim氏はDevOpsについて、中心にある慢性的な対立を定義している。

組織がマーケットで勝つことを支援するために、技術はビジネスの差し迫ったニーズに応える必要があります。つまり、私たちはより素早く変更をリリースする必要があります。しかし同時に、信頼性、セキュリティ、安定性を維持しなければなりません。しかし、それでは何も変更できません。両方とも有効なビジネス上の目的なのです。私たちは差し迫ったビジネスニーズに応える必要があり、しかし、セキュリティと安定性を維持する必要がある。頻繁にかつ素早く変更することと注意深く少ない回数で変更することは全く反対の方向のアクションです。開発者はリリース、リリース、リリースと言い、他方、運用者は安定性を第一に考えます。

2人はこのオーディオブックの目的を次のように定義している。

'The Phoenix Project'以降、たくさんのことを学びました。'The DevOps Handbook'の仕事を始め完成させる前でも、私たちは人々の知識を広げ、組織がハイパフォーマンスになるように支援してきました。全くバラバラの知識を取り上げながら、私たちはこれらの知識がいかにしてDevOpsを可能にするかを示してきました。業界規模でこれらの原則が提示されたのはこの時が初めてでした。

最初のモジュールではThe Phoenix Project自体を取り上げている。次のモジュールではGoldratt氏を、そして、3つ目ではW. Edwards Demingを取り上げている。4から6までのモジュールでは、リーン安全な文化学習する組織の理論と実践が語られ、最後の3つのモジュールでは専門家から学べること(Kim氏がホストを務めたStephen Spear氏Sidney Dekker氏Richard Cook氏とのパネルディスカッションの音源も含まれている)や、ケーススタディ(Nordstrom、Target、Disney、Marks & Spencer、CSG、Microsoft、Colombia Sportswear、Walmart、Nike、Goldman Sachs)が語られ、結論が述べられる。

このオーディオブックを通じて2人は多くの先行する仕事に言及している。自分たちが巨人たちの肩に乗っているのを自覚している。例えば、Goldratt氏、Deming氏、Spear氏、Mary Poppendieck氏Ben Rockwood氏Mike Rother氏Mark Burgess氏Peter Senge氏Simon Sinek氏Eric Ries氏Sidney Dekker氏Carlota Perez博士Donald Reinertsen氏L. David Marquet氏に言及している。多くの原則や実践についても議論している。メンタルモデルSimianArmyCOSOキューブドラム・バッファー・ロープ現用問題構造ツリー, 決定論仮説駆動開発ETTO腐ったりんご理論Westrumの組織文化類型学などだ。

2人ともThe Phoenix Projectの読者がキャラクターや語りについて自分たちの考えを頻繁に語っていたことを振り返っている。

「あのキャラクター知っている。GeneはThe Phoenix Projectを獲得にうちの会社に忍び込んだんじゃないか。」とか「なんてこった。The Phoenix Projectで起こったことはうちの会社で起こったことだ。」というような声を聞きました。The Phoenix Projectで生まれた予期しなかった喜びは、BrentというキャラクターがDevOpsコミュニティの心に深く響いたということです。

Kim氏はThe Phoenix Projectの目的を説明している。

製造業に適用されたリーンの原則と技術の価値の流れに適用されたリーンの原則と間の同型写像を作ることです。'The Phoenix Project'での私たちの望みは、技術の価値の流れの中の機能的な塊が直面する課題を等しく明らかにすることでした。

2人は、DevOpsの動きを前に進める人や実践者がいることの重要さを説明している。

私にとってのある種のアハ体験は、素晴らしい理論を生み出したとしても、実際に業界に持ち込んでくれる響きがあるコミュニティがなければ、アカデミックな仕事、知的な作業になってしまう、ということです。異なる領域から貪欲かつ熱心にアイディアを借りて、そのアイディアを仕事に取り組むコミュニティは見たことがありません。なので、私はDevOpsとDevOpsのコミュニティには楽観的です。

Willis氏とKim氏はDevOpsを支える原則とThe Third Wayについて説明している。その中でKim氏のメンターであるSteven Spear博士が頻繁に言及されている。トヨタ生産方式を学んだ博士は問題を学習機会として把握することを支持している。Kim氏はThe Third Wayを次のように説明する。

リスクを背負うことを育むこの文化によって、成功と失敗から学ぶことができます。反復は熟達の前提です。継続的な実験と学習の文化を作るのも、この文化です。学習で競合を上回っている者が市場で高い成果を上げる者だ、という考え方なのです。Andrew Shaferは、「学習する組織にいるか学習者を失うかのどちらかだ。」と言っています。

7番目のモジュールのパネルディスカッションでは、Spear博士は心理的安全性の見地からDevOps文化の特性を語っている。

人を萎縮させるのに恐怖は必ずしも必要ありません。萎縮は、脳が文字通り短絡するだけで発生し、「何をすればいいんだ。何をすればいいんだ。わからない。とにかくフロアで椅子に座って問題が通り過ぎるのをやり過ごそう。」というループに陥ります。しかし、これは私たちの話題ではありません。私たちが話しているのは、規律、厳密さ、エネルギー、楽観主義を持って、何をするべきか、どうやってするべきかがわからない瞬間を認識することです。「でも、どうやって対処するかは知っている、私は問題解決者として訓練され実践してきたからだ。」、だから、麻痺に陥る必要はないのです。

Sidney Dekker氏はこのふたつのアイディアを一緒にしている。

Allspawが、このことを綺麗に表しています。つまり、インシデントとは計画していなかった投資であり、リーダーとしてそのように認識していなければ、この投資からリターンを得ることはできない、ということです。

Kim氏はDevOpsモデルの中の自動化の目的について説明している。

可能な限り自動化したいと思っています。自動化できない場合は、手作業を削ってなるべく単一の作業フローに近くようにします。ひとつのフローで安全にセキュアに安定的にデプロイできるのが理想的です。

Willis氏は別のレベルでの自動化の重要性を探る。

単に自動化するだけで魔法が生まれるのではありません。価値の流れを無駄の観点から分析すること、そして、より重要なのが、全体最適の観点からボトルネックを探る能力です。

Kim氏とWillis氏は、DevOpsの原則を使って技術産業の仕事を理解し改善を行うときの価値の成果について頻繁にを振り返っている。また、技術チームとその他の組織の間で密に協力することの重要さにも言及している。Kim氏は次のように言っている。

ボトルネックが最終的にどうなるかはとても興味深いです。私がこの話を初めて聞いたのはNetflixのAdrian Cockcroft氏Roy Rappaport氏からです。Adrian氏は次のように言います。「制約は最終的にプロダクトオーナーになります。多くのアイディアがうまれるのです。」別の言い方をすれば、優れたアイディアのどのくらいが実際の顧客でテストする価値があるのか、ということです。氏は、ボトルネックは開発でも品質でも運用でもセキュリティでもない、と言っています。私は、これは、優れたアイディアの創出がボトルネックになるべきだ、というEric Ries氏とSteve Blank氏の考えに合うと思います。

Kim氏とWillis氏は技術産業の仕事は難しくなりがちだと認識している。ソフトウェアは不可視で複雑なシステムであり、技術負債の重さは不確実性と脆弱さを生み出し、簡単に理解できない。Willis氏は次のように言う。

Demingのアイディアで、不確実性に対処するしかないという状況になりました。私の考えでは、彼は不確実さに対処するより良い道筋を示してくれました。失敗と効率性の坩堝、これが私たちがDevOpsについて語ってきたことであり、素早さと堅牢さの直感に反するあり方です。

Kim氏とWillis氏は、レジリエンスとサイト信頼性エンジニアリングを詳しく調べ、エラーバジェットを素早さと信頼性のバランスをとるものとして例示する。Kim氏は次のように言う。

エラーバジェットの制約は自分自身でバランスを取るシステムの例として最適なものです。開発者が早くやりたいなら、その権利を失う壁にぶつかるまで早く動けます。他方、うまくやっている人たちにも見返りがあります。サービスレベル目標で定義されたコントロールを失わない限り素早く動くことができるのです。.

Stephen Spear氏, Richard Cook氏、Sidney Dekker氏とのパネルディスカッションで、Cook氏はコミュニティでの知識の共有、学習、専門性について次のように話している。

DevOpsは問題を解決したり、速度を生み出したりするための単なる実践ではありません。DevOpsはDevOpsを実践する人のコミュニティを構築するための実践でもあります。経験を周囲に共有するという道徳的責任があると思います。周囲の人が問題に対してよりしっかりと準備できるようにするためです。たとえ、彼らのそばにはいなくても。この責任はDevOpsの正体の一部だと思います。DevOpsはツールチェーンを超え、リポジトリを超え、人を巻き込む実践になる必要があると思います。これを実現するには、ある企業xで働く人、ではなく、DevOpsを実践する人として、自分を認識する必要があるでしょう。つまり、DevOpsの人になるには、ある種の専門性とスキル、特定の雇用関係とは切り離された専門知識が必要です。

2人はDevOpsの原則と実践を活用する高いパフォーマンスを生み出す組織は'ダイナミックな学習する組織'であり、DevOpsは生産性を次のレベルに上げるためには必要不可欠だ、と結論付けた。

Beyond The Phoenix Projectのオーディオブックはここからダウンロードできる。文字起こしはここにある。

 
 

Rate this Article

Adoption Stage
Style
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT