The DevOps ハンドブック 理論・原則・実践のすべて(Geen Kim, Jez Humble, Patrick Debois, John Willis)
書籍情報
書籍目次
- 序章 DevとOpsがDevOpsになる世界を想像してみよう
- 第1部 3つの道
- 第1章 アジャイル、継続的デリバリー、そして3つの道
- 第2章 第1の道:フローの原則
- 第3章 第2の道:フィードバックの原則
- 第4章 第3の道:継続的な学習と実験の原則
- 第2部 スタートのための糸口
- 第5章 最初に手を付けるバリューストリームの選択方法
- 第6章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる
- 第7章 Conwayの法則を念頭に置いた組織とアーキテクチャの設計
- 第8章 開発の日常業務に運用を統合してすばらしい成果を生み出す方法
- 第3部 第1の道:フロー改善の技術的実践
- 第9章 デプロイパイプラインの基礎の構築
- 第10章 高速で信頼性の高い自動テストの実現
- 第11章 継続的インテグレーションの実現と実践
- 第12章 自動化とローリスクリリースの実現
- 第13章 ローリスクリリースのアーキテクチャ
- 第4部 第2の道:フィードバックの技術的実践
- 第14章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す
- 第15章 遠隔測定データを分析して問題の予測と目標の達成に活かす
- 第16章 フィードバックループを実現して開発と運用が安全にコードをデプロイできるようにする
- 第17章 日常業務に仮説駆動開発とA/Bテストを組み込む
- 第18章 レビューと調整プロセスによって現在の仕事の品質を上げる
- 第5部 第3の道:継続的な学習と実験の技術的実践
- 第19章 日常業務での学習の実現と日常業務への学習の注入
- 第20章 一部門の発見を全社的な進歩につなげる
- 第21章 組織的な学習と改善を生み出すための時間を確保する
- 第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践
- 第22章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける
- 第23章 デプロイパイプラインを防御する
- 行動提起:DevOpsハンドブックの締めくくりに
序章 DevとOpsがDevOpsになる世界を想像してみよう
- DevOpsが実現する世界と時代背景:
- 製品オーナー、開発、QA、IT運用、情報セキュリティが共通の目標のもとで協力し、1日に数十〜数千回のデプロイと、ワールドクラスの安定性・信頼性・セキュリティを両立する世界
- 現実の多くの組織では、開発と運用が敵対 --> テストとセキュリティはプロジェクトの最後に回り、手作業と受け渡しの多さによってリードタイムが延び、品質が下がっている
- 1980年代の製造業:
- リーン導入が進み、平均リードタイムは6週間から3週間未満に縮小
- 納期遵守率は70%未満から95%以上に上がった
- リーンを取り入れなかった企業は廃業した
- ソフトウェアデリバリーのサイクルとコスト:
- 1970〜80年代の1〜5年・100万〜1億ドル
- 2000年代以降は2〜12週間・1万〜100万ドルに低下
- エラーのコストも「倒産」から「無視できる」水準へ移行
- 現在、DevOpsを採用した企業は1日に数百〜数千回デプロイしている。それができない企業は市場から退場する運命にある
- 問題: 根深く慢性的な対立と悪循環:
- IT組織は「市場の急速な変化への対応」（開発）と「安定・信頼・セキュアなサービスの提供」（運用）という相反する目標を同時に負う
- Goldrattはこれを「根深く慢性的な対立」と呼んだ
- この対立が技術的負債を増やす
- 第1幕: 運用が、脆くドキュメントのない、しかし最重要の収益システムを支え、技術的負債を抱え込む
- 第2幕: 製品マネージャーや経営者が過大な約束の埋め合わせを求め、開発が妥協して技術的負債をさらに増やす
- 第3幕: あらゆる作業が少しずつ遅く難しくなり、コードは密結合になって変更が恐くなる。デプロイ時間が延び、アウテージが増え、フィードバックが弱まり、市場で敗れる
- 悪循環がどこでも起きる理由は2つある。すべてのIT組織が相反する目標を持つこと、そしてすべての企業が実質的にIT企業であること（設備投資の50%がIT関連）
- 人的コストとして、無力感、燃え尽き、長時間労働を生み、優秀な人材を失う
- 経済的コストとして、IT支出3.1兆ドルのうち約5,200億ドルが予定外の作業やり直しでムダになっている。ムダを半減させ、浮いた人手を5倍の価値の仕事に振り向ければ、年2.6兆ドルの価値が生まれると試算している
- DevOpsが悪循環を断ち切る仕組み:
- 小さなチームが他チームに依存せずに実装・検証・デプロイでき、デプロイは営業時間内のルーチン作業になる
- コミットごとに本番に近い環境で自動テストを実行し、ミスを数分以内に発見・修正して学習につなげる。グローバルな目標を優先するため、技術的負債が蓄積しない
- 遠隔測定をコードと本番環境に行き渡らせ、問題をすぐに発見・修正する
- ダークローンチと機能トグルにより、リリースを制御可能・予測可能・復元可能なものにする
- 仮説と測定に基づく科学的な文化、メンバー固定の長期的な製品・プラットフォームチーム、恐怖ではなく高信頼の文化をつくる
- 自動テストとピアレビューにより、遠くの承認者に頼るよりもリスクを下げ、監査人に対しても内部統制の有効性を示せる
- 非難なしのポストモーテム、社内カンファレンス、本番環境へのエラー注入によって、学習と回復力を強める
第1章 アジャイル、継続的デリバリー、そして3つの道
生産のバリューストリーム
- バリューストリームの定義:
- バリューストリームはリーンの基本概念の1つである
- Karen MartinとMike Osterlingは、バリューストリームを企業が顧客の要求に応えるために着手する一連の活動と定義している
- 生産現場のバリューストリーム:
- 生産現場のバリューストリームは、顧客の注文を受けて原材料が工場のフロアに送られるところから始まる
- 高速で予測可能なリードタイムを実現するには、小さなバッチサイズやWIPの削減、手戻りの防止、絶え間ない改善によってスムースで均等な作業フローを作り出す必要がある
ITバリューストリーム
- ITバリューストリームの定義:
- ものの生産で高速なフローを実現する原則とパターンは、ITを含むあらゆる知的作業に応用できる
- DevOpsでは、ビジネス上の仮説を立案してから顧客に価値を届ける技術サービスを生み出すまでのプロセスをITバリューストリームと定義する
- このプロセスは、開発がアイデアや仮説をバックログに追加したときに始まり、ユーザーストーリー化、実装、インテグレーション、テストへと進む
- 価値はサービスが本番環境で実行されてから生まれるため、障害やセキュリティ問題などを起こさずにデプロイできることが求められる
- デプロイリードタイムの重視:
- 本書では、エンジニアが変更をバージョン管理システムにチェックインしてから、その変更が本番環境で顧客に価値を提供するまでのデプロイリードタイムに注目する
- 第1フェーズの設計と開発は、可変性と不確実性が高いリーン製品開発に似ている
- 第2フェーズのテストと運用は、予測可能性を追求し可変性を最小限に抑えるリーン生産に似ている
- 設計/開発とテスト/運用を逐次的に進めるのではなく同時に行うことで、高速なフローと高品質の実現を目指す
- この方法は、小さなバッチサイズで仕事を進め、バリューストリームのあらゆる部分で品質を保証するときにのみ成功する
- リードタイムとプロセスタイム:
- リードタイムは、顧客が要求してからその要求が満たされるまでの時間である
- プロセスタイムは、顧客の要求のための仕事を始めてから完了するまでの時間であり、キューでの滞留時間を含まない
- 顧客が感じるのはリードタイムなので、プロセス改善ではリードタイムに注目する
- リードタイムに占めるプロセスタイムの割合は、作業効率の重要な指標になる
- リードタイムの短縮には、ほとんどの場合バックログでの滞留時間の削減が必要である
- 数か月単位のデプロイリードタイム:
- 大規模で複雑な組織が密結合のモノリシックアプリケーションを扱う場合、デプロイリードタイムが数か月に及ぶことはよくある
- その背景には、貧弱なインテグレーションテスト環境、長いリードタイム、多くのマニュアルテスト、複数の承認プロセスがある
- このような状況では、ほぼすべてのステージで超人的な作業が必要になる
- 最後に変更を統合した段階でビルドやテストが通らず、修正に数日から数週間かかったうえに顧客の満足が得られないこともある
- 数分単位のデプロイリードタイム:
- DevOpsの理想は、デベロッパーがすばやいフィードバックを受け、他部門の制約なしにコードを実装、統合、検証し、本番環境にデプロイできることである
- この理想は、小さな変更をこまめにチェックインし、自動テストと探索テストを経て本番環境にデプロイすることで実現される
- これにより、変更が設計通りに稼働し、問題があればすぐに発見・修正できるという確信が得られる
- この理想は、モジュール化された疎結合のアーキテクチャによって小さなチームが権限を持ち、ミスの影響が局所に留まるときにもっとも実現しやすい
- このシナリオではデプロイリードタイムは分単位になり、最悪でも時間単位に留まる
- 手戻りの指標としての%C/A:
- 完全正確率（%C/A）は、バリューストリームの各ステップが出力するものの品質を反映する第3の重要な指標である
- %C/Aは、下流の顧客が受け取った仕事のうち、訂正や補足、明確化なしにそのまま使えたものの割合を尋ねればわかる
- 用語の補足:
- 本書でエンジニアという言葉は、デベロッパーに限らずバリューストリームで働くあらゆる人々を指す
- テスト駆動開発のようなテクニックでは、テストはコードの第1行が書かれる前に始まっている
- 同義語が多く混乱を招くサイクルタイムではなく、プロセスタイムという用語を使う
3つの道: DevOpsを支える原則
- 3つの道の概要:
- 『The Phoenix Project』は、DevOpsのすべての行動やパターンの基礎となる原則を3つの道として示している
- 第1の道:
- 第1の道は、開発から運用、顧客へと向かう左から右へのワークフローを高速にすることである
- フローを最大化するには、仕事の可視化、バッチサイズと作業インターバルの削減、品質の組み込み、下流への不良品の受け渡し防止、全体目標のための絶え間ない改善が必要である
- フローを加速すると、リードタイムが短縮され、スループットと作業品質が向上し、競合他社より早く実験する能力が強化される
- ここから導かれる実践は、継続的なビルド・インテグレーション・テスト・デプロイ、オンデマンドの環境作成、仕掛りの削減、変更に強いシステムと組織の構築などである
- 第2の道:
- 第2の道は、バリューストリームのあらゆるステージで、すばやくコンスタントな右から左へのフィードバックフローを実現することである
- フィードバックによって、上流で品質を確保し、致命的な事故のはるか手前で問題を見つけて修正できる安全な作業システムを作れる
- 問題発生と同時に一丸となって対処することで、フィードバックループを継続的に短縮・強化できる
- これは現代のほぼすべてのプロセス改善メソドロジーの基本原則である
- 第3の道:
- 第3の道は、科学的なアプローチに基づく実験とリスクテイクを支持し、成功と失敗の両方から組織として学ぶ高信頼マネジメントの文化を生み出すことである
- 安全な作業システムがあることでリスクテイクと実験がしやすくなり、競合他社より早く学んで競争に勝ちやすくなる
- チーム内の発見を全社的な改善につなげる仕組みにより、社員は組織全体の集合的な経験に支えられて働けるようになる
第2章 第1の道: フローの原則
作業の可視化
- ITの作業が見えにくい問題:
- 生産と異なり、ITの作業は目に見えないため、フローの遅れや仕事の滞留を把握しにくい
- ITでは作業の受け渡しがボタンクリックだけでできるため、不完全な情報のまま作業がチーム間を行き来することがある
- 問題が潜んだまま下流に作業が流れ、納期遅れや本番環境でのエラーにつながることもある
- 作業ボードによる可視化:
- カンバンボードやスプリント計画ボードを使い、作業をカードとして左端から右端の「完了」列へ流していく
- ボードを使うと、作業を速く流すよう管理できるうえ、カードの配置から完了までの時間でリードタイムを測定できる
- 「完了」の定義:
- カンバンボードはバリューストリーム全体を対象とし、右端に達したときだけを作業完了とするのが理想である
- 開発の実装完了ではなく、本番環境で実行に成功し顧客に価値を届けたときにはじめて完了と言える
- キューの可視化の効果:
- 各ワークセンターのキューを可視化すると、ステークホルダーが全体の目標に沿って優先順位を決めやすくなる
- 各ワークセンターは最優先の仕事にシングルタスクで取り組めるようになり、スループットが上がる
WIP（仕掛り）の制限
- ITの仕事の流動性:
- 生産現場は生産計画に従って仕事をするが、ITの仕事はその時点の優先順位に左右され、はるかに流動的である
- ITでは、チケットやメール、電話、チャットなどさまざまな手段から急ぎの依頼が届く
- 作業中断のコスト:
- 生産現場では作業中断のコストが目に見えて大きいため、中断は極力避けられる
- ITでは作業が簡単に中断されるが、その悪影響は見えにくいだけで、実際には生産現場よりはるかに大きい
- 複数プロジェクトを担当するエンジニアは、タスクスイッチのたびに仕事のコンテキストを組み立て直すコストを負う
- 研究によれば単純作業でもマルチタスクで効率は大きく下がり、認知的に複雑なITの仕事では悪影響がさらに大きい
- カンバンによるWIP制限:
- 列に置けるカードの数を制限することで、各ワークセンターが抱えるWIPを制限し、マルチタスクを抑えられる
- 上限に達した列には、カードが完了するかキューに戻されない限り、新しいカードを追加できない
- カードに作業内容を書かなければ着手できないようにすると、すべての作業が可視化される
- Dominica DeGrandisは、キューの長さはリードタイムの数少ない指標の1つであり、強力な管理ツールだと述べている
- WIP制限で見える問題:
- WIPを制限すると、作業の完成を妨げている問題が見えやすくなる
- 手が空いたときは新しい仕事を始めるより、遅れの原因を突き止めて解決を手伝う方がよい
- David J. Andersenの言葉どおり「始めることをやめよ、終えることを始めよ」が原則である
バッチサイズの縮小
- 大バッチの問題:
- リーン以前は、切り替えコストを抑えるために大きなバッチで生産するのが一般的だった
- 大バッチはWIPを膨らませてフローを変動させ、リードタイムを延ばし品質を下げる
- 1つの不良が見つかるとバッチ全体をスクラップにしなければならないこともある
- リーンの教訓:
- リードタイム短縮と品質向上のために、バッチサイズの縮小に絶えず努めるべきである
- バッチサイズの理論的下限は、1度に1単位ずつ作業するシングルピースフローである
- 封筒ゲームの例:
- 10冊のパンフレットを、折る・入れる・封をする・切手を貼るの4工程で郵送する例で考える
- 各工程10秒の場合、大バッチ戦略では最初の完成品ができるのは310秒後である
- 大バッチでは最初の工程の誤りに気づくのが最短でも200秒後で、10冊分すべてをやり直す必要がある
- 小バッチ戦略では最初の完成品が40秒後にでき、誤りがあってもやり直しは1冊分で済む
- 小バッチにより、WIP削減、リードタイム短縮、エラーの早期発見、手戻りの削減が実現する
- ITにおけるバッチ:
- 年1回の大規模リリースは大きなWIPを生み、下流の作業を大きく中断させてフローと品質を悪化させる
- 本番環境への変更が大きいほど、エラーの診断と修正は難しくなる
- Eric Riesは、ソフトウェアでもっとも見えやすいバッチはコードだと指摘している
- ITでシングルピースフローにあたるのは、1つのコミットごとにテストとデプロイを行う継続的デプロイである
受け渡しの数の削減
- 受け渡しが多い問題:
- コードを本番環境に移すまでに数百から数千もの工程が必要なことが、リードタイムが月単位になる原因であることが多い
- テスト、環境作成、サーバー管理、ネットワーク、セキュリティなど多くの部門の仕事が必要になる
- 受け渡しのたびにリクエストや調整などのコミュニケーションと、優先順位付けや確認などの作業が発生する
- キューと情報の損失:
- 複数のバリューストリームがリソースを共有すると、各工程が作業の滞留するキューになり、エスカレーションが絶えず起きる
- 受け渡しのたびに情報は必ず失われ、回数が増えると解決すべき問題や組織目標のコンテキストが失われる
- たとえばサーバー管理者は、アカウント作成チケットを見ても、その目的や背景がわからない
- 削減の方法:
- 作業の大部分を自動化するか、チームが独力で顧客に価値を届けられるよう再編して、受け渡しを減らす
- これにより、キューでの滞留時間や付加価値のない時間が短縮され、フローが速くなる
絶えず制約条件を見つけ出して尊重する
- 制約条件の重要性:
- リードタイム短縮とスループット向上には、システムの制約条件を絶えず見つけ出し、その容量を改善する必要がある
- Goldratt博士は、どのバリューストリームにも唯一の制約条件があり、それ以外の改善は幻想だと述べている
- ボトルネックの前を改善しても仕掛りが積み上がるだけで、後を改善しても仕事を待つ飢餓状態になるだけである
- 5つの重点的なステップ:
- 制約条件を明らかにし、その能力を最大限引き出す方法を決める
- ほかのすべてをその決定に従属させ、制約条件を最大限に尊重する
- 制約条件が解消されたらステップ1に戻るが、惰性で制約条件を作ってはならない
- DevOps改革での制約条件の推移:
- 環境の作成は、セルフサービスでオンデマンドに環境を作れるようにすることで解決する
- コードのデプロイは、自動化を進めてデベロッパーがセルフサービスでデプロイできるようにすることで解決する
- テストの準備と実行は、テストを自動化・並列化してコード開発のスピードに追いつかせることで解決する
- 過度に密結合なアーキテクチャは、疎結合に変えてチームが安全に変更できるようにすることで解決する
- 理想的な制約条件:
- これらをすべて打破すると、制約条件は開発部門か製品オーナーになり、それは理想的な状態である
- その段階での課題は、優れたビジネス仮説をいくつ作り、それを検証するコードをどれだけ開発できるかだけになる
- ここで示した推移は一般化したものであり、実際の制約条件を見きわめる手法は後述される
バリューストリームからムダと苦痛を取り除く
- ムダの定義:
- 新郷重夫は、ムダを企業存続の最大の脅威と考えていた
- リーンでのムダとは、顧客が必要とし支払うつもりのある範囲を越えた材料やリソースの利用である
- 新郷は生産現場のムダとして、在庫、作り過ぎ、加工のしすぎ、運搬、手待ち、動作、不良の7つを定義した
- リーンの新しい解釈では、ムダの削減を「継続的な学習を通じて日常業務から苦痛と重労働を取り除くこと」と言い換えている
- ソフトウェア開発のムダと苦痛:
- Poppendieck夫妻は、顧客への価値提供を遅らせるあらゆるものをムダと苦痛だと説明している
- 部分的に完成した仕事とは、未完成のままキューに溜まっている仕事である
- 余分な処理とは、使われないドキュメントや付加価値のないレビュー・承認など、労力とリードタイムを増やす作業である
- 余分な機能とは、誰も必要としない機能であり、製品を複雑にしてテストと管理の負担を増やす
- タスク切り替えは、複数のプロジェクトを抱える人にコンテキスト切り替えと依存関係管理の余分な労力をもたらす
- 待機とは、作業間の遅れにより下流が仕事を完成できず、リードタイムが延びることである
- 動作とは、情報や材料をワークセンター間で移転するための労力であり、担当者が離れていたり受け渡しがあったりすると発生する
- 不良とは、情報や製品の不良・不明確さであり、作り出してから発見するまでが長いほど解決が難しくなる
- 非標準的な作業や手作業とは、再現不能な環境などのために他者の手作業が必要になることである
- 超人的な作業とは、目標達成のために個人やチームが不合理な作業を強いられ、それが日常化することである
- ムダへの対処:
- ムダや苦痛を可視化し、系統的に緩和・削減することで、スピーディなフローを実現する必要がある
第3章 第2の道:フィードバックの原則
- 第2の道: フィードバックの原則（第3章の位置づけ）:
- 第1の道は左から右（開発から運用）への速いフローの原則である。第2の道は、バリューストリームの全ステージで右から左へ、早く絶えずフィードバックを返すための原則である
- 目標は、より安全で回復力のある作業システムを作ることである
- 生産現場でもITでも、業務災害、原子炉のメルトダウン、本番の大規模アウテージ、顧客データ流出などの重大障害が起きてはじめて問題に気づくことが多い
- 速く頻繁で質の高い情報フロー（フィードバックループとフィードフォワードループ）を作れば、問題が小さく安く直しやすいうちに見つけて修正でき、破滅的な結果を避けられる
- 学習する組織の文化を作り、学んだことを将来の仕事に組み込む。エラーや事故は処罰や非難の理由ではなく、学習の機会と捉える
- 複雑なシステムにおける安全な作業:
- 複雑なシステムでは、誰もシステム全体を見渡せず、部品のかみ合い方を理解できない。コンポーネントは密結合で複雑に絡み合い、個々のふるまいから全体のふるまいを説明できない
- Charles Perrow博士（スリーマイル島原発事故の研究）: 原子炉があらゆる状況でどうふるまい、どう失敗するかを理解できる者はいなかった。問題が起きると、フローが最も抵抗の小さい経路を予測不能な形で通り、ほかのコンポーネントから切り離すのが難しかった
- Sidney Dekker博士（「安全文化」を体系化した1人）: 同じことを2度しても同じ結果になるとは限らない。そのため、静的なチェックリストやベストプラクティスは有用でも、破滅的な障害を防ぐには足りない（補章E参照）
- 複雑なシステムではエラーは避けられない。負傷、不良、顧客への悪影響といった破滅的な結果のはるか手前で障害を見つけられるという自信を持ち、恐れずに働ける作業システムを設計する必要がある
- Steven Spear博士（トヨタ生産方式の因果関係を解読したハーバードビジネススクールの博士論文）: 完全に安全なシステムは設計できないが、次の4条件を満たせばより安全に作業できる
- 設計や運用の問題が明らかになる形で複雑な仕事を管理する
- 問題が起きたら組織が一丸となって解決し、新しい知識を素早く築く
- 組織の一部で得たローカルな知識を、組織全体で活用する
- リーダーが、これらの能力を伸ばし続ける人を次のリーダーとして育てる
- 本章は最初の2つの能力を扱う
- Spear博士は、トヨタのサプライヤーネットワーク、Alcoa、米海軍原子力推進プログラムなども研究している（脚注）
- 発生と同時に問題を知る:
- 安全な作業システムでは、設計と運用の前提を絶えず検証する。多くの分野から早く、安く、因果関係をできるだけ明確にして、作業システムに流れる情報を増やす
- 前提が誤っていると早くわかるほど、問題を早く見つけて直せる。回復力、敏速性、学習とイノベーションの能力も高まる
- Peter Senge博士（The Fifth Discipline、邦訳『最強組織の法則』）: フィードバックループは、学習する組織とシステム思考の重要な一部である。フィードバック/フィードフォワードループにより、システムのコンポーネントは互いに強め合ったり打ち消し合ったりする
- GMフリーモント工場の例: 問題を見つける手続きも、見つけたときの対処手順もなかった。その結果、エンジンが逆向きの車、ハンドルやタイヤのない車、エンジンがかからずラインへけん引して戻す車が作られた
- 高パフォーマンスの工場では、バリューストリーム全体に速く質の高い情報が頻繁に流れる。すべての作業が測定・監視され、不良や大きな逸脱はすぐに誰かが見つけて対処する。これが品質、安全、継続的な学習と改善の基礎になる
- ITでは速いフィードバックがないため、成果が上がらないことが多い（例: ウォーターフォールではテスト段階まで1年間品質のフィードバックがない。フィードバックなしで顧客にリリースすることさえある）
- 目標は、製品管理、開発、QA、情報セキュリティ、運用のどこで働いていても、速いフィードバック/フィードフォワードループが働くようにすることである。自動ビルド、インテグレーション、テストを含め、変更でシステムが壊れてデプロイできなくなったらすぐわかるようにする
- 本番環境の全コンポーネントに遠隔測定（テレメトリ）を行き渡らせる。本来の動作から外れたらすぐ気づけるようにし、目標の達成度も測る。データをバリューストリーム全体で共有し、自分の行動がほかの部分に与える影響がわかれば理想的である
- フィードバックループは、問題の早期発見と解決だけでなく、再発の防ぎ方も教える。作業システムの質と安全性を高め、組織的な学習を生む
- Elisabeth Hendrickson（Pivotal Software技術担当VP、*Explore It!*著者）: 「QA部門の長としての仕事は『フィードバックサイクルを生み出すこと』だった。方向転換できるのはフィードバックがあるからだ。顧客のニーズ、私たちの意図、実装の間で絶えず確認しなければならない。テストはフィードバックの一形態に過ぎない」
- 新しい知識を作り上げるために組織が一丸となって問題解決に当たる:
- 想定外の事態を見つけるだけでは足りない。必要な人をすべて動員し、組織を挙げて対処する
- Spear博士: 一丸となった問題解決の目標は、問題が広がる前に封じ込め、診断・対処し、再発を防ぐことである。その過程で組織は、当初の避けがたい無知を知識に置き換え、システムをうまく動かす方法についてより深い知恵を築く
- トヨタのアンドン:
- 全ワークセンターの上に紐があり、部品の不良や欠品、作業が想定より長くかかるときなどに引くよう全員が教育されている（一部工場では紐からボタンに変わっている: 脚注）
- 紐が引かれるとチームリーダーに警告が届き、すぐに解決に動く。規定時間（例: 55秒）内に解決できなければラインを止め、対策が見つかるまで組織を挙げて取り組む
- 問題を回避したり先送りしたりせず、すぐに解決する。GMフリーモント工場とはほぼ逆の行動である
- 一丸となった解決が必要な理由:
- 問題が下流に波及するのを防ぐ。波及すると解決の費用と労力が指数的に増え、技術的負債が溜まる
- ワークセンターが新しい仕事を始めて、システムに新しいエラーを持ち込むのを防ぐ
- 解決しなければ、次の操業（例: 55秒後）でも同じ問題が起き、修理や作業が増える（補章F参照）
- ローカルな問題で全体の操業を止めることを意図的に認めるので、一般的なマネジメントとは逆に見える。しかし、学習を可能にし、記憶の風化や状況の変化で重要な情報が失われるのを防ぐ
- 人、プロセス、製品、場所、状況の予想外の相互作用で問題が起きる複雑なシステムでは特に重要である。時間がたつと、何が起きたかを正確に再現できなくなる
- Spear博士: 一丸となった問題解決は「リアルタイムで問題を発見、診断、治療（修正・解決）する統制の取れたサイクル」である。Demingが広めたShewhartサイクル（PDCA）を大幅に加速したものである
- 破滅的な結果を防ぐには、小さな問題を早く見つけて一丸となって解決するしかない。メルトダウンが起きてからでは手遅れである
- アンドンの紐を引く回数が減ると、工場の管理者は、より小さなエラーの前兆を捉えて学習と改善の機会を確保するため、引く回数を増やそうとする（脚注）
- ITでの実践:
- アンドンの紐と一丸となった対策に相当するものを作る。本番インシデントでも、上流のエラー（例: 継続的ビルド/テストを壊す変更）でも、紐を引くことが非難されず奨励される文化を作る
- 紐が引かれたら一丸となって解決し、解決するまで新しい仕事を始めない。これにより、関係者全員（特にエラーの原因を作った人）に素早くフィードバックが届き、早期に問題を切り分けて診断でき、因果関係をあいまいにする要因が入り込むのを防げる
- 新しい仕事の開始を禁じることで、ITのシングルピースフローである継続的インテグレーションと継続的デプロイが成り立つ。ビルドとインテグレーションテストに合格した変更はすべて本番にデプロイし、不合格なら紐を引いて一丸となって解決する
- 上流での品質確保を追求する:
- 事故や問題への対処の仕方が、意図せず安全でない作業システムを延命させることがある
- 複雑なシステムでは、検査ステップや承認プロセスを増やすと、将来エラーが起きる可能性がかえって高まる。意思決定を現場から遠ざけるほど承認の効果は下がる。意思決定の質が落ち、サイクルタイムが延び、因果のフィードバックが弱まり、成功や失敗から学ぶ力が衰える
- トップダウンの官僚的な指揮命令がうまくいかないのは、明確さの欠如とタイミングの悪さから、「誰がすべきか」と「誰が実際にしているか」の差が大きくなりすぎるからである
- 1700年代、英国政府は6000km以上離れた植民地ジョージアの農政を、現地の勢力関係・地勢・水資源などを知らないまま計画した。結果は惨憺たるもので、ジョージアは13植民地で最も貧しく人口の少ない地に留まった（脚注）
- まずい品質保証の例:
- 簡単に自動化でき、必要なチームが自分で実行できるはずの、面倒でエラーを起こしやすい手作業を他チームに頼む
- 仕事から遠い多忙な人の承認が要る。その人は内容や波及効果を十分知らずに判断し、ただ承認印を押すだけになることもある
- 疑問点を詳細に書いた膨大な文書を作るが、書いた直後から陳腐化していく
- 承認や作業のために、特別な委員会やチームに大きなバッチで仕事を渡して返事を待つ
- あるべき姿:
- バリューストリームの全員が、日常業務の一部として担当分野の問題を見つけて直す。遠い上級幹部の承認に頼らず、実際に仕事をする部門が品質と安全性に責任を持ち、意思決定する
- 変更が設計どおり動く保証が要るなら、ピアレビューを行う
- QAや情報セキュリティの品質チェックをできる限り自動化する。デベロッパーがテストを依頼・予約せずオンデマンドで実行でき、自分のコードを素早くテストし、自分で本番にデプロイすることさえできるようにする
- 品質を特定部門に押し付けず、全員が責任を持つ。可用性が運用だけの仕事でなくなるのと同じく、情報セキュリティも情報セキュリティ部門だけの仕事ではなくなる
- デベロッパーが品質の責任を共有すると、成果物がよくなるだけでなく学習も加速する。顧客から最も遠いデベロッパーには特に重要である
- Gary Gruver: 「6か月前に壊したものについてガミガミ言われる環境では、デベロッパーは何も学べない。だからこそ、月単位ではなく分単位で、誰にでもできるだけ早くフィードバックを返す必要がある」
- 下流のワークセンターのために最適な出力:
- 1980年代の製造性重視設計（Designing for Manufacturability）では、最も低いコスト、最も高い品質、最も速いフローで作れるよう部品とプロセスを設計した（例: 逆に取り付けられないよう非対称にした部品、締め過ぎられないねじ回し）
- 社外の顧客だけを考え、製造担当などの社内ステークホルダーを見過ごしていた設計のあり方を大きく変えた
- リーンは2種類の顧客を定義する。社外の顧客（サービスに料金を払う人）と、社内の顧客（自分たちが作ったものをすぐ後で受け取り加工する人）である。最も重要な顧客は下流のすぐ次にいる人たちである
- 彼らのために最適な仕事をするには、彼らの問題を自分の問題として捉え、速く滑らかなフローを妨げる設計上の問題を見極める
- ITでは、運用のために最適な設計をすることを意味する。運用の非機能要件（アーキテクチャ、パフォーマンス、安定性、テスト可能性、構成/設定のしやすさ、セキュリティ）に、ユーザー機能と同じ高い優先順位を与える
- これにより上流で品質を確保し、構築するすべてのサービスに体系化された非機能要件を組み込める
- まとめ:
- ITバリューストリームで高品質、高信頼性、安全性を実現するには、素早くフィードバックを返す経路が欠かせない
- そのために、問題の発生と同時に一丸となって解決し、新しい知識と知恵を生み、上流で品質を確保し、下流のワークセンターに適した出力を心がける
- 具体的な実践は第4部で、第3の道（継続的な学習と実験）は次章で説明する
第4章 第3の道:継続的な学習と実験の原則
- 第3の道: 継続的な学習と実験の原則（第4章の位置づけ）:
- 第1の道は左から右へのワークフロー、第2の道は右から左への素早く持続的なフィードバックを扱う。第3の道は、継続的な学習と実験の文化を作ることに着目する
- 個人が絶えず知識を生み出し、それをチームや組織の知識に変えていくための原則である
- 品質と安全を重視する製造現場では作業が厳密に定義され、遵守が求められることが多い。GMフリーモント工場では、改善提案は「無関心の厚い壁にぶつかり」、作業者が日常業務に改善や学習を組み込むことはほぼ不可能だった
- そうした環境には恐怖と不信の文化があることが多い。ミスをした作業者は処罰され、提案や問題を指摘する者は密告者、トラブルメーカーと見なされる。リーダーシップが学習と改善を抑え込み、罰することさえあるため、品質と安全の問題が残り続ける
- 対照的に、高パフォーマンスの生産現場は学習を必要とし、積極的に奨励する。作業システムはダイナミックで、ラインの作業者は日常業務の一部として改善の実験を行う。それを可能にしているのは、作業手順の厳密な標準化と結果の文書化である
- ITバリューストリームでの目標は、日常業務でリスクを引き受ける「生涯学習者」であることを強調し、高信頼マネジメントの文化を作ることである
- プロセス改善と製品開発の両方に科学的手法を使い、成功と失敗から学び、うまくいかないアイデアを見極め、うまくいくアイデアを育てる
- ローカルな学習を素早くグローバルな改善に変え、新しい技術や実践を組織全体で使えるようにする
- 日常業務を改善する時間を確保し、改善を加速して確実に学習が行われるようにする
- 継続的な改善を止めないよう、システムに絶えず緊張を持たせる
- 回復力を高めるため、管理された条件下で本番サービスのエラーをシミュレートしたり、実際に注入したりする
- 継続的でダイナミックな学習システムを作れば、チームは変化する環境に素早く自律的に適応できるようになる。それが最終的に市場で勝ち残る力になる
- 組織的な学習と安全を重んじる文化を作る:
- 複雑なシステムでは、自分の行動の結果をすべて予測することは原理的に不可能である。準備して注意深く進めても、予想外の結果や破滅的な事故が起こりうる
- 事故が顧客に影響すると、根本原因はヒューマンエラーとされがちである。管理者は原因を作った者を特定し、非難し、恥をかかせ（name, blame, shame）、処罰をほのめかし、再発防止としてプロセスや承認を増やす
- この「特定・非難・恥辱」のパターンは、Sidney Dekker博士が批判した「腐ったりんご理論」の一部である（The Field Guide to Understanding Human Error、邦訳『ヒューマンエラーを理解する』）（脚注）
- Sidney Dekker博士（安全文化の重要な要素を体系化し、「ジャストカルチャー（公平な文化）」という言葉を作った）: 「事故や問題への対応を誤ると、安全性の調査を妨げ、安全上きわめて重要な仕事をする人々の心に注意深さではなく恐怖を植え付け、注意深い組織ではなく官僚的な組織を作り、秘密主義、言い逃れ、自己防衛の文化を築いてしまう」
- ITの仕事はほぼすべて複雑なシステムの中で行われるため、これは特に大きな問題になる。管理者の対応で恐怖の文化が根付くと、問題やエラーの兆候が報告されなくなる
- Ron Westrum博士（組織的な安全とパフォーマンスを重んじる文化の重要性を最初に指摘した1人）: 医療機関を調査し、患者の安全を予測する最重要因子の1つは「発生的な」文化があるかどうかだと示した
- Westrum博士の3つの組織タイプ（図8: 情報の扱い方による分類。出典 Ron Westrum, "A typology of organisation culture," BMJ Quality & Safety, 2004）:
- 病理的: 情報は隠される／メッセンジャーは「やられる」／責任逃れに終始する／チーム間の協力は妨げられる／ミスは隠される／新しいアイデアは潰される。恐怖と威嚇が広がり、人々は情報を抱え込み、政治的な理由で隠したり、自分をよく見せるために歪めたりする
- 官僚的: 情報は無視されることがある／メッセンジャーは寛大に扱われる／責任は個人のものとされる／チーム間の協力は認められるが奨励されない／組織は正しく慈悲深い／新しいアイデアは問題を引き起こす。規則とプロセスが特徴で、部門ごとの「縄張り」を奨励する。ミスは判定の仕組みで処理され、懲罰か正義・寛大な措置で決着する
- 発生的: 情報を積極的に集める／メッセンジャーになるよう訓練される／責任は共有される／チーム間の協力は奨励される／ミスは研究・調査のきっかけになる／新しいアイデアは歓迎される。組織の目標をよりよく達成するため情報を積極的に集めて共有し、責任をバリューストリーム全体で分かち合い、ミスが起きたら純粋な原因究明と振り返りの時間をとる
- 医療機関で観察された、メンバーを信頼する発生的な文化の重要性は、ITと組織のパフォーマンスにもあてはまる
- ITバリューストリームでは、安全な作業システムを追求することが発生的な文化の土台になる。事故が起きたら、ヒューマンエラーを犯した人を追及するのではなく、再発を防ぐためにシステムをどう作り直すかを追究する
- 例: インシデント後は必ず非難なしのポストモーテム（事後検証）を行う。インシデントの仕組みを理解し、最善の対策はシステムの強化だという合意のもとで、再発防止と早期発見・解決を目指す
- Bethany Macri（Etsyのエンジニア、ポストモーテム記録ツールMorgueの開発をリード）: 「非難を取り除けば恐怖が消える。恐怖が消えれば正直になれる。正直になれれば予防ができる」
- Spear博士: 非難を取り除いて組織的な学習の価値を認めると、「組織は自己診断と自己改善の能力を高め、問題を見つけて解決する力をつけていく」
- Peter Senge博士（The Fifth Discipline、邦訳『最強組織の法則』）も、これらを学習する組織の特徴として挙げる。こうした特徴は顧客の役に立ち、高品質を確保し、競争優位と活力ある社員を生み、真実を明らかにする
- 日常業務の改善を制度化する:
- チームは作業プロセスを改善できない、または改善したがらないことが多い。その結果、今の問題に悩まされ続け、しかも時間とともに悩みは深まる
- Mike Rother（Toyota Kata、邦訳『トヨタのカタ』）: 改善しなければプロセスが現状のままでいられるわけではない。カオスとエントロピーの増大により、プロセスは時間とともに劣化する
- ITでは、根本解決を避けて日々の応急処置に頼ると、問題と技術的負債が溜まる。すべてが応急処置頼みになって大きな障害から逃げ回るだけになり、生産的な仕事に使う余力がなくなる
- Mike Orzen（Lean IT著者）: 「日常業務よりも大切なのは、日常業務の改善だ」
- 技術的負債の返済、欠陥の修正、コードや環境の問題箇所のリファクタリングと改善のために正式に時間を確保すれば、日常業務は改善される。開発サイクルの合間に時間をとったり、改善活動の予定を組んだりする。改善活動では、エンジニアが自主的にチームを作り、取り組みたい問題を解決する
- これを実践すると、全員が担当分野で日常業務の一部として問題を見つけて直すようになる
- 何か月（何年）も放置してきた日常の問題を解決すると、システムのもっと分かりにくい問題に取り組めるようになる。より弱い障害の兆候に対処できれば、解決は簡単で安く済み、結果が重大になる前に手を打てる
- Alcoaの例:
- 1987年に780億ドル（原文ママ）の収益を上げていたアルミニウムメーカー。アルミ製造には極度の高温、高圧、腐食性薬品が必要である
- 1987年の安全記録は、9,000人の従業員の2%が毎年負傷する（1日7人の負傷者）という深刻なものだった
- CEOに就任したPaul O'Neillが最初に掲げた目標は、従業員、契約社員、訪問者の負傷をゼロにすることだった
- 負傷者が出たら24時間以内に報告するよう指示した。目的は処罰ではなく、事故から教訓を得て、より安全な職場作りに活かすことだった
- その後10年間で事故率を95%下げた
- 事故率が下がると、より小さく弱い問題の兆候に注意を向けられるようになった。社員は負傷時だけでなく、危険な事態（ニアミス）が起きたときも報告するようになった
- その後20年間で職場の安全性をさらに高め、産業界で最もうらやまれる安全記録の1つを打ち立てた
- O'Neillが職場の安全に対するリーダーの道義的責任について示した確信と情熱は驚くべきもので、学ぶべき点が多い（脚注）
- Spear博士: 「社員たちは、感じていた困難、不便、障害から逃げるのを次第にやめた。プロセスや製品の改善機会を探すダイナミズムによって、問題に向き合い、解決のために戦い、解決を実現するようになった。機会を見つけて問題を調べるうちに、彼らの無知は知識の塊に変わった」。これがAlcoaの市場での競争優位の拡大に大きく役立った
- ITでも同様に、作業システムを安全にしていけば、以前より弱い兆候から問題を見つけて直せるようになる。例えば最初は顧客に影響したインシデントだけで非難なしのポストモーテムを行っていても、やがてチームに影響したインシデントやニアミスといった小さな事象でも行うようになる
- ローカルな発見をグローバルな改善に変える:
- ある部門で新しい教訓を得たら、社内のほかの部門すべてがその知識を活用し恩恵を受けられる仕組みが必要である
- チームや個人が知識を生む経験をしたら、暗黙知（書いたり話したりして他人に伝えにくい知識）を体系化された形式知に変え、実践を通じてほかの人の専門能力の一部にする
- そうすれば、誰かが似た仕事をするときに、同じ仕事を経験した社員全員の集合的な経験を下地にできる
- 米海軍原子力推進プログラム（NR: Naval Reactors）の例:
- 原子炉関連の大事故や放射能漏れを1件も起こさず、5,700基年以上原子炉を運転してきた
- 文書化された手順と作業の標準化を特に重視している
- 手順や標準運転から外れたら、障害の兆候がどれほど小さくても事故報告を書くことが義務づけられている
- 手順とシステム設計は、こうして学んだことをもとに絶えず更新されている
- その結果、新しい乗組員が初めて航海に出るときでも、彼らと上官は5,700基年分の集合知を活用できる。さらに彼ら自身の経験もこの集合知に加わり、将来の乗組員が任務を安全に果たす助けになる
- ITでもグローバルな知識を蓄える仕組みが必要である
- 非難なしポストモーテムの報告書を検索できるようにし、同じ問題を抱えるチームが活用できるようにする
- 全社共有のソースコードリポジトリを作り、全社の最良の集合知を体現する共有コード、ライブラリ、構成/設定ファイルを簡単に使えるようにする
- これらは個人の経験を、全社で使えるアーティファクト（成果物）に変えるのに役立つ
- 日常業務に回復力を鍛えるパターンを組み込む:
- パフォーマンスの低い生産組織は、作業の中断の影響を和らげるため、余分な「ぜい肉」を抱える
- 中間製品の遅れや廃棄でワークセンターが手すきになるリスクに備えて、各ワークセンターに中間製品を溜め込む。しかしこれはWIP（仕掛り）を増やし、WIPの増大はさまざまな問題の原因になる
- 機械の故障でワークセンターが止まるリスクに備えて、機械や人員を増やし、床面積を広げることさえある。どれもコストを押し上げる
- 対照的に、能力の高い工場は、日常業務の改善、パフォーマンス向上のための継続的な緊張の導入、システムへの回復力の組み込みによって、同等以上の結果を得ている
- アイシン精機（トヨタのトップサプライヤーの1つ）のマットレス工場の例:
- 1日100ユニットを作れる生産ラインが2本ある。比較的暇な日に、1本のラインで全生産をまかなう実験をする
- 能力を増やす方法を試すとともに、プロセスの弱点を探す。1本のラインに負荷をかけすぎて問題が起きたら、2本目を動かせばよい
- 日常業務の中でこうした実験を繰り返すことで、新しい機器や人員を増やさずにパフォーマンスを上げ続けている
- この改善の儀式から得たパターンは、生産能力だけでなく回復力の向上にも役立つ。組織が常に緊張状態に置かれ、変化を促されているからである
- Nassim Nicholas Taleb（作家、リスクアナリスト）は、ストレスをかけて回復力を強めるこうしたプロセスを「アンチフラジャイル」と名づけた
- ITでも同様の緊張をシステムに持ち込める
- デプロイのリードタイム短縮、テストカバレッジの拡大、テスト実行時間の短縮を追求する
- 開発者の生産性やシステムの信頼性を上げるのに必要なら、アーキテクチャの作り直しまで踏み込んでよい
- Game Days: データセンター全体のダウンなど、大規模障害のリハーサルを本番システムで行う
- 本番環境に大規模なエラーを注入し（本番のプロセスやサーバーを無作為に落としていくNetflixのChaos Monkeyなど）、求められる回復力があることを確かめる
- リーダーが学習する文化を後押しする:
- 伝統的に、リーダーには目標を決め、達成のために資源を投入し、適切なインセンティブを組み合わせることが求められてきた。リーダーは組織の感情的なトーンも左右する。つまり「すべてについて正しい決定を下す」ことで導くとされてきた
- しかし、偉大な成果はリーダーがすべてを正しく決めることで生まれるわけではないという証拠がある。リーダーの役割は、チームが日常業務の中で偉大なものを見つけ出せる条件を整えることである。偉大な成果にはリーダーとワーカーの両方が必要で、両者は互いに依存し合っている
- Jim Womack（Gemba Walks著者）: リーダーと現場のワーカーの間には、補い合う関係と相互の尊重が必要である
- リーダーには問題解決に必要な「仕事との距離の近さ」がない。現場のワーカーには、組織全体の文脈を見る視点や、自分の作業範囲の外を変える権限がない。どちらも単独では仕事ができない
- リーダーは、視野が狭く権限もないワーカーの集団よりも、高いレベルでプロセスを設計し動かす責任を持つ（脚注）
- リーダーは、学習と規律ある問題解決の価値を高めなければならない
- Mike Rotherの「コーチングのカタ（型）」:
- 科学的手法を反映したもので、Alcoaの「事故ゼロの持続」、アイシンの「1年以内の生産倍増」のように、非常に高い目標をはっきり掲げる
- 戦略的な目標から短期的な目標の繰り返しが生まれる。短期目標はバリューストリームやワークセンターのレベルに下ろされ、「次の2週間でリードタイムを10%短縮する」といった目標状態として実行される
- 目標状態は科学的実験の枠組みになる。解決したい問題を文章ではっきり書き、提案する方法でなぜ問題が解けるかについて仮説を立て、検証方法を決め、結果を解釈し、学んだことを次のイテレーション（反復）に活かす
- リーダーは、次のような質問で実験を進める人をコーチする:
- 最後のステップは何で、何が起きたか
- 何を学んだか
- 今の状態はどうか
- 次の目標状態は何か
- 今どんな障害を取り除こうとしているか
- 次のステップは何か
- どんな結果を予想しているか
- いつ結果を確認できるか
- ワーカーが日常業務の問題を見つけて解決するのをリーダーが助ける、この問題解決アプローチこそが、トヨタ生産方式、学習する組織、改善のカタ、高信頼性組織の核である
- Mike Rother: トヨタは「すべてのメンバーに継続的に教えるという独自の行動ルーチンを最大の特徴とする組織」である
- ITでも、この科学的で反復的な手法が組織内のあらゆる改善プロセスを導く。自分たちが作る製品が社内外の顧客の目標達成に本当に役立つかを確かめる実験も、同じ手法で進める
- まとめ（第4章）:
- 第3の道の原則は、組織的な学習を重んじ、メンバーを信頼し、部門の壁を越えた協力を奨励し、複雑なシステムではミスや失敗は避けられないと受け入れ、問題を議論できる環境を作り、安全な作業システムの土台を整える
- あわせて、日常業務の改善を制度化し、ローカルな学びを組織全体で使えるグローバルな学びに変え、日常業務に継続的に緊張を持ち込むことも求められる
- 継続的な学習と実験の文化は第3の道の原則だが、第1、第2の道にも織り込まれている。フローとフィードバックを高めるにも、目標状態を設定し、そこに至るための仮説を文章化し、実験を設計・実施し、結果を評価するという反復的で科学的なアプローチが必要である
- 得られるのはパフォーマンスの向上だけではない。回復力の強化、仕事への満足感の向上、組織の適応力の向上も得られる
- 第1部のまとめ:
- 第1部では、DevOpsの発展を導いた歴史上のさまざまな運動を振り返った
- 組織がDevOpsで成功するための土台となる3つの主要原則として、フロー、フィードバック、継続的な学習と実験を説明した
- 第2部では、自分の組織でDevOpsの取り組みを始める方法を説明する
第5章 最初に手を付けるバリューストリームの選択方法
- 第2部イントロダクション: スタートのための糸口:
- 第2部では、組織でDevOps改革を起こすために、どこから始め、誰を巻き込み、チームをどう組織してメンバーの作業能力を守り、成功の可能性をどう最大化するかという問いに答える
- 自組織のバリューストリームの評価から始め、よいスタート地点の見つけ方、具体的な改善目標を持ち将来の拡張も見据えた専門の改革チームを作る戦略へと進む。そのうえで、バリューストリームごとに必要な作業を明らかにし、変革目標の達成に役立つ組織設計の戦略と組織の原型を見ていく
- 重点的に扱う項目:
- 最初に手を付けるバリューストリームの選び方
- 候補となるバリューストリームで行われている仕事を理解する方法
- Conwayの法則を念頭に置いた組織とアーキテクチャの設計方法
- バリューストリームに属する部門間の効果的な協力による競争優位の生み出し方
- チームを守り、チームに力を与える方法
- 改革のスタート時点は不確実なことばかりで、目的地はあっても途中の経由地はほとんど分からない。そのため、決定を導く思考プロセス、たどるべき具体的な道筋、ケーススタディを示す
- 最初のバリューストリームを慎重に選ぶ理由（第5章冒頭）:
- どのバリューストリームを選ぶかで、変革の難しさだけでなく、関わる人々、チームの組織の仕方、チームとメンバーが力を発揮するために何ができるかまで決まる
- Michael Rembetsy（2009年にEtsyの運用部門担当役員としてDevOps改革をリード）: 「トラブルに陥ったとき、打てる弾はあまりない。だからプロジェクトは慎重に選び、組織のあり方を大きく改善するプロジェクトを守る必要がある」
- Nordstromの事例（Courtney Kisslerの2014年・2015年DevOps Enterprise Summitでの説明に基づく）:
- Nordstromは1901年創立のアパレル小売トップ企業の1つで、最良のショッピングエクスペリエンスの提供に力を入れている。2015年の収益は1,350億ドル（原文ママ）
- 改革のきっかけは2011年の年次取締役会で、企業戦略のテーマとしてオンライン収益の拡大が議題に上がった。Blockbusters、Borders、Barnes & Noblesなど伝統ある小売業者がeコマース対応に遅れて苦境に立ち、廃業の危険さえあることから多くを学んでいた（これらは「死にかけているキラーB各社」と呼ばれることがある: 脚注）
- 当時のKissler（システムデリバリー及び販売テクノロジー担当上級本部長）: 「2011年当時の技術部門はコスト重視に大きく傾いていた。IT部門の多くを売却し、大きなバッチのウォーターフォール型リリースの年次計画サイクルだった。納期・予算・範囲目標の達成率は97%だったが、5か年事業戦略の要求には力不足だった。会社はコスト削減ではなくスピードを重視し始めていた」
- システム全体をひっくり返すのではなく、実験と学習ができるよう限定された分野に集中し、早期に勝利を示して他分野でも同じ改善を取り入れる自信を持たせることを目指した
- 選んだのは、顧客向けモバイルアプリ、レストランの店内システム、デジタル資産管理の3分野。いずれも満たされていないビジネスゴールがあり、新しい仕事の仕方を導入しやすかった
- モバイルアプリ:
- App Storeでの評価はおしなべて否定的で、既存システム前提のプロセスのため年2回しかアップデートをリリースできず、修正を届けるのに何か月も待つ必要があった
- 目標は、より速い（さらにはオンデマンドの）リリースでイテレーションを速め、顧客フィードバックに早く応えること
- モバイルアプリ専任の製品チームを編成し、他チームに依存・調整せずに独立して変更を実装・テスト・デリバリーできるようにした
- 計画を年1回から継続的な計画プロセスに移し、優先されるのは顧客ニーズによる変更だけにした。複数製品を扱うときの優先順位の対立はなくなった
- 次の1年で独立した作業段階としてのテストをなくし、全メンバーの日常業務に統合した。毎月提供できる機能が倍増し、欠陥数は半減した
- プロジェクト最終期に安定化フェーズや強化フェーズを置く方法は、問題が日常業務の中で発見・修正されず雪だるま式に膨らむため、不満の残る結果になりがちである（脚注）
- レストラン（Café Bistro）のインストアアプリ:
- ビジネスニーズは、モバイルアプリのような市場投入の短縮やリリース回数の増加ではなく、コスト削減と品質向上だった
- 2013年に11の「レストラン改革」を打ち出し、顧客に影響するインシデントを何度も起こしていたインストアアプリの改革が求められた。2014年には前年の4倍の44の改革を計画していた
- 経営陣の1人がチームを3倍に拡大することを提案したが、Kisslerは人数を増やすのではなく仕事の方法を改善すべきだと提案した
- 仕事の取り掛かりやデプロイプロセスなど問題のある分野に努力を集中し、コードのデプロイのリードタイムを60%削減、本番インシデント数を60〜90%削減した
- これらの成功で、DevOpsの原則と実践はさまざまなバリューストリームに応用できるという自信が生まれ、Kisslerは2014年にEコマース及び店舗IT担当VPに昇任した
- 2015年のKissler:
- 顧客が直接操作するITを持つ組織が目標を達成するには、一部ではなくすべてのITバリューストリームで生産性を上げる必要があった。経営レベルの決定で、顧客が操作するすべてのサービスでサイクルタイムを20%短縮することを全社的な義務とした
- 当時は全チームでプロセスタイムを測定しておらず、測定したものも可視化されていなかったため、無謀に近い挑戦だった。最初の目標状態は、全チームがイテレーションごとにプロセスタイムを測定・可視化し、短縮の実験を行うよう支援することだった
- バリューストリームマッピング、シングルピースフローを目指したバッチサイズの削減、継続的デリバリーとマイクロサービスの利用によって目標状態に移れると確信しており、改革が経営最高幹部の支援を受けていることは誰もが知っている
- 本章では、Nordstromがどのバリューストリームから始めるかを決めた思考プロセスを再現できるモデルを示す。評価軸は、グリーンフィールドかブラウンフィールドか、参加システムか記録システムか、変革のリスク／効果のバランス、協働するチームからの抵抗のレベルなどである
- グリーンフィールドサービスとブラウンフィールドサービス:
- 用語はもともと都市計画や建築のもの。グリーンフィールド開発は未開発の土地の開発、ブラウンフィールド開発は有害物質で汚染されている恐れのある元工業用地の開発で、前者の方が簡単である
- ITのグリーンフィールドプロジェクトは、新しいソフトウェアを計画・実装の初期段階から、制約の少ない中でアプリケーションとインフラを新たに構築するもの。特に予算がつきチームができている（またはできつつある）なら改革を始めやすく、既存のコードベース、プロセス、チームの心配も少ない
- グリーンフィールドDevOpsプロジェクトは、パブリック／プライベートクラウドの可能性を探るパイロットや、デプロイ自動化などのツールのパイロットになることが多い
- National Instruments（NI）のHosted LabVIEW（2009年）の例:
- NIは30年の歴史、5,000人の従業員、年間10億の収益を持つ企業
- 市場投入を速めるため新チームを作り、既存のITプロセスの外での運用とパブリッククラウドの利用の調査を認めた
- 初期メンバーは、アプリケーションアーキテクト、システムアーキテクト、デベロッパー2人、システムオートメーションデベロッパー、運用リーダー、オフショア運用スタッフ2人
- DevOpsの実践により、通常の製品リリースの半分の時間で市場に投入できた
- ブラウンフィールドDevOpsプロジェクトは、すでに顧客にサービスを提供している既存の製品・サービスで、何年、何十年と稼働していることもある。自動テストがない、サポート外のプラットフォームで動いているなど、技術的負債が積み重なっていることが多い。Nordstromのレストランのインストアシステムとeコマースシステムはどちらもブラウンフィールドである
- DevOpsは主にグリーンフィールド向けだと思われがちだが、実際にはあらゆるタイプのブラウンフィールドで成功している。2014年のDevOps Enterprise Summitで共有された改革ストーリーの60%はブラウンフィールドのものだった。顧客の要求と会社が提供できていたものの間に大きなギャップがあり、改革が莫大なビジネス効果を生んだ
- もっとも大きなビジネス効果がありそうなサービスがブラウンフィールドなのは意外ではない。もっとも頼りにされ、既存顧客が多く、収益がもっとも多いのはこの種のシステムだからである（脚注）
- 2015 State of DevOps Report: アプリケーションの年齢はパフォーマンスの大きな予測因子にはならない。アーキテクチャがテストやデプロイを考慮したものになっているか（作り変えられているか）の方が大きな予測因子である
- ブラウンフィールドを支えるチームもDevOpsの実験を強く受け入れることがある。従来の方法では目標達成に足りないという認識が広く共有され、改善の緊急性が強く感じられている場合は特にそうである
- 一方で、自動テストがない場合や、アーキテクチャが密結合で小さなチームが独力で開発・テスト・デプロイしにくい場合は、大きな抵抗や問題にぶつかることがある。その克服方法は本書全体で考えていく
- ブラウンフィールド変革の成功例:
- CSG（2013年）: 収益7億4,700万ドル超、従業員2,500人以上。9万超の顧客サービスエージェントで、5,000万人以上のビデオ・音声・データ顧客の課金処理と顧客ケア、60億件超の取引、毎月700万枚超の請求書の印刷・郵送をこなす。最初に改善したのは、COBOLメインフレームアプリと20の関連ITプラットフォームを抱える請求書印刷システム。本番に近い環境へ毎日デプロイするようになり、顧客リリースを年2回から4回に倍増させた。アプリケーションへの信頼度が大きく上がり、デプロイのリードタイムは2週間から1日未満に短縮された
- Etsy（2009年）: 従業員25人、収益8,700万ドル。「休日商戦の時期を辛うじて生き残った」あと、仕事のほぼあらゆる側面の改革に乗り出した。その結果もっとも尊敬されるDevOps企業となり、2015年の新規株式公開の成功のお膳立てとなった
- 記録システムと参加システムの両方を考慮に入れる:
- Gartnerが広めたバイモーダルIT（2つの流儀のIT）という概念では、企業のサービスを2種類に分ける
- 記録システム（SoR、タイプ1）: ERP関連システム（MRP、人事管理、財務報告など）。トランザクションとデータの正しさが最重要。変更ペースが遅く、SOXなどの規制・コンプライアンス要件を満たす必要があることが多い。「正しく実行すること」に力を入れる
- 参加システム（SoE、タイプ2）: eコマースや作業補助アプリなど顧客や従業員が直接操作するシステム。速いフィードバックループで顧客ニーズを満たす方法を探る実験が必要なため、変更ペースがはるかに速い。「速く実行すること」に力を入れる
- 分類は便利な場合もあるが、「正しく実行すること」と「速く実行すること」の根深い二律背反はDevOpsで破れることが分かっている。Puppet LabsのState of DevOps Reportのデータ（リーン生産の教訓に学んだもの）は、高パフォーマンス企業がスループットと信頼性を同時に高い水準で実現できることを示している
- システムは相互に依存しているため、どのシステムで何を変更できるかは、安全な変更がもっとも難しいシステムに制限される。そしてそれはほとんど必ず記録システムである
- Scott Prugh（CSG製品開発担当VP）: 「顧客はみなスピードと品質の両方を必要とするので、私たちはバイモーダルITを拒否してきた。30年前のメインフレームアプリでも、Javaアプリでも、モバイルアプリでも、技術的な優越性が必要だ」
- ブラウンフィールドシステムを改善するときは、複雑さの緩和や信頼性・安定性の改善だけでなく、速く、安全で、変更しやすいシステムも目指す必要がある。グリーンフィールドの参加システムにとっては単なる機能追加でも、ブラウンフィールドの記録システムでは信頼性問題の原因になることが多い。こうした下流のシステムを安全に変更できるようにすると、組織全体が速く安全に目標を達成できるようになる
- もっとも関心を持ちイノベーティブなグループから始める:
- 新しいアイデアに対しては、チームや個人によって態度がさまざまである。Geoffrey A. Moore（Crossing The Chasm、邦訳『キャズム Ver.2 増補改訂版』）は、この多様性を技術採用のライフサイクルとして描いた。キャズム（裂け目）は、イノベーターやアーリーアダプターの先のグループに支持されることの難しさを表す
- 図9 技術の普及曲線（出典: Moore and McKenna, Crossing The Chasm）:
- イノベーター（技術オタク）「試してみよう」2.5%
- アーリーアダプター（ビジョナリー）「大勢に先んじよう」13.5%
- アーリーマジョリティ（プラグマティスト）「大勢にくっついていこう」34%
- レイトマジョリティ（保守主義者）「実証されているものにくっついていこう」34%
- ラガード（懐疑主義者）「ダメだダメだダメだ」16%
- アーリーアダプターとアーリーマジョリティの間にキャズムがある
- イノベーターやアーリーアダプターは新しいアイデアをすぐ支持することが多いが、より保守的な人々は拒絶することが多い
- 目標は、DevOpsの原則と実践の必要性をすでに確信し、プロセスを革新・向上させる意思と実証済みの能力を持つチームを見つけ、熱心な支持者になってもらうことである
- 特に初期は、保守的なグループの転向に時間を使わず、リスクを怖がらないグループで成功を収めて基礎を築く
- 経営陣から最高レベルの支援を得ていても、すべてのシステムで一斉に始めるビッグバンアプローチは避け、少数のグループにエネルギーを集中させる。そこで確実に成功してから全社に広げる
- トップダウンのビッグバン改革も可能ではある。PayPalではIT担当VPのKirsten Wolbergがリーダーとなり、2012年にビッグバンでアジャイルへの変革を果たした。ただし、持続可能な変革の常として、経営最高水準のサポートと緩みない継続的な努力が必要だった（脚注）
- DevOpsの組織全体への展開:
- 最初の導入範囲がどれくらいでも、早い段階で勝利を示し、成功を広める必要がある。そのために大きな目標を小さな段階的ステップに分割する
- そうすると改善のペースが上がるだけでなく、バリューストリームの選択を誤ったときに早く気づける。早く分かれば、学んだことに基づいて判断を変え、すばやく引き返して再挑戦できる
- 成功を収めると、改革の範囲を広げる権利を得る。周囲からの信頼、サポート、影響力を着実に高める安全な順序をたどりたい
- 改革派が同盟者と支援基盤を作り広げる理想の展開（MITのRoberto Fernandez教授の講義内容に手を加えたもの）:
- 1. イノベーターとアーリーアダプターを見つける: 運動を本当に助けたい人々、自らDevOpsの旅を始めようとする気の合う仲間に力を注ぐ。彼らが組織全体で尊敬され影響力を持つ人々なら、運動の信頼性が上がる
- 2. クリティカルマスとサイレントマジョリティを構築する: 安定した支援基盤を築くため、より多くのチームとバリューストリームに実践を広める。目立つグループや影響力のあるグループでなくても、考え方を受け入れるチームと組めば同盟者が広がり、「バンドワゴン効果」で影響力がさらに高まる
- 3. 抵抗派を明らかにする: 影響力があり注目されながら取り組みを拒否（妨害さえ）する人々。対決するのは、サイレントマジョリティを築き、運動を守れるだけの成功を収めてからにする
- 組織全体への展開は小さな仕事ではなく、個人、部門、組織全体にリスクをもたらすこともある
- Ron van Kemenade（INGのCIO、同社をもっとも評価の高い技術系企業の1つに押し上げた）: 「改革の先頭に立つには勇気が必要だ。人々が怯えて対立してくる環境ではなおさらだ。しかし最初は少数派でも恐れることはない。リーダーには、チームに計算された冒険をさせる勇敢さが必要だ」
- まとめ（第5章）:
- Peter Drucker: 「小さな魚は小さな池で大きな魚になることを学ぶ」
- どこからどのように始めるかを慎重に選べば、組織全体を危険に晒さずに、一部で実験と学習を通じて価値を生み出せる
- それによって支援の基盤を築き、DevOpsを組織全体に広げられるようになり、より多くの人々に認められるようになる