LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

著者 : Nicole Forsgren Ph.D. Jez Humble Gene Kim 武舎広幸 武舎るみ

• インプレス (2018年11月22日発売)

感想・レビュー・書評

[onesword0618さんの感想 · 2024年2月28日]

開発組織の改善にはどんな手法や研究がされているのか気になり手に取りました。

散発的にプロジェクトへ参加して開発作業を行うこととは違う継続したサービス提供のためのアクションについて理解を深めることができました。

組織の課題を知るために過去の実績や障害を知ること。
組織の現在を知るための計測を行うこと。
組織の未来を得るために人が障壁になっているプロセスを置き換え委譲を行うこと。

不確実性は何かを把握し、分割を試みる。

自分から考え行動し、貢献を行うことが求められて少数では足並みを揃えることができないことを意識して少しずつ活動をしていきたいと思いました。

[hhidevさんの感想 · 2023年12月29日]

付録Aで全体感を抑えてから、自分の興味あるトピックから読んでいくと良いなど
t_wadaさんの説明を聞いてから読むとわかりやすい
https://open.spotify.com/episode/7JP6BFOB2grTJt5V3VmI9Z?si=dd906431d4554645

[さとうさんの感想 · 2023年7月14日]

ソフトウェアや組織をどのように計測するのか、それぞれの値がどのように関係しているのか、が書かれた本
2014年から今まで毎年レポートを行っており、その一部が収録されている
現代においてこの本を読まなければ、ソフトウェア開発について会話ができないと思っても良い、というレベルの一冊

[マーティさんの感想 · 2023年3月18日]

面白かった。
理解はできたが知識とするには難しいので辞書的な役割として手元に置いときたい。

[kyosawaさんの感想 · 2022年10月20日]

・P21：望ましい尺度(Four Keys)
ソフトウェアデリバリのパフォーマンスを的確に計測できる尺度は二つの特徴を持っていなければならない。

1つはグローバルな成果に焦点を当て、チーム同士が競争もしくは対立するような状況を防ぐ機能を持つものである。従来の典型的なやり方は「処理量の多い開発者と安定性向上に寄与した運用担当者を報奨する」というものだが、これが「混乱の壁」の主な誘因となっている。「混乱の壁」とは、開発側と運用側を隔てる縦割りの壁のことである。
〜中略〜
パフォーマンス計測の有効な尺度が備えるべき第2の特徴は、生産量ではなく成果に焦点を当てるというものだ。これはつまり、組織レベルの目標の達成に役立たない「忙しいが価値のない、見せかけの作業」を重ねて大量の仕事をこなしたものを報奨するやり方はやめるべきだ、ということである。

以上のような基準を満たす計測尺度を探した結果、我々は次の4つを選び出した。
　1. デリバリのリードタイム
　2. デプロイの頻度
　3. サービス復旧の所要時間
　4. 変更失敗率

・P31：2.3 組織のパフォーマンスとデリバリのパフォーマンス
組織の使命がなんであれ、技術部門のパフォーマンスの良し悪しは、組織全体のパフォーマンスの予測材料となりうる。なお、非営利組織の目標達成能力の計測には、過去に有効性が複数回にわたって立証され、この目的に特に適した尺度を用いた。

そしてここでも「ハイパフォーマーは、商品やサービスの量、作業効率、顧客満足度、製品やサービスの質、組織や任務の目標達成度で、他集団を上回る傾向があり、その対比は2倍を超える」という結果を得た。以上の関係を示したのが図2.4(ソフトウェアデリバリのパフォーマンス影響)である。

・P32：本書の図について
- テキストボックスは計測の対象にした構成概念である(構成概念の詳細は第13章参照)
- 2つのテキストボックスをつなぐ矢印は、前のボックスが後のボックスの「予測要因」となりうること、つまり2つのボックスが予測関係にあることを指す。

・P48：3.5 組織文化をどう変えていくか
John Shockは、カリフォルニア州フリーモントの自動車工場でチーム文化の改革に携わった際の経験を記した中で次のように述べている(ちなみにこの経験が米国におけるリーン生産方式の端緒となった)。

「私がこの経験から学んだ中でも印象に残っているのが、組織文化を変えていく上でまず最初にやるべきなのは、関係者の思考法を変えることではなく、関係者の言動、つまり皆が何をどう行うかを変えることだ、という点である」。
https://www.thisamericanlife.org/561/nummi-2015

我々はその趣旨に沿う形で「リーンとアジャイルのプラクティスを実践すれば組織文化に好影響を与えられる」という仮説を掲げ、技術的プラクティスと管理面でのプラクティスを視野に、それが組織文化にもたらす影響を測定してきた。

リーンマネジメントの手法は、「継続的デリバリ」と総称される各種技術的プラクティスと併用すると組織文化に好影響を与えられる。
図3.3 Westrumモデルを下敷きにした「組織文化の促進要因」
　継続的デリバリ + リーンマネジメント => 推奨する組織文化

・P53：4.1 継続的デリバリとは？
継続的デリバリとは、機能の追加、構成の変更、バグの修正、各種試行など、様々な変更を安全かつ迅速かつ持続可能な形で本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティから成る手法である。次の5つの基本原則を柱とする。
　 - 「品質」の概念を生産工程の最初から組み込んでいく
　 - 作業はバッチ処理で進める
　 - 反復作業はコンピュータに任せて人間は問題解決に当たる
　 - 徹底した改善努力を継続的に行う
　 - 全員が責任を負う

・P93：7.1 リーンマネジメントのプラクティス
- 進行中の作業(WIP)の制限
- 可視化(見える化)
- ワークフローの可視化
- 負担の軽い変更承認プロセス

・P101：リーン製品開発のプラクティス
- 作業の細分化
- 管理の可視化
- 顧客フィードバックの収集と実装
- チームによる実験

・P126：10.2 組織文化と帰属意識の改善
図10.1 技術的プラクティスとリーンマネジメントのプラクティスが構成員の帰属意識にもたらす効果
　継続的デリバリ + リーンなプラクティス
　　　　=>　帰属意識の強化　=>　組織のパフォーマンス向上
〜中略〜
我々の調査研究でも、「組織に対する従業員の帰属意識の高さは、(生産性・市場占有率・収益性で測定した)パフォーマンス志向で創造的な組織文化の浸透度と組織全体のパフォーマンスのレベルの予測要因となりうる」との結果が出ている。
〜中略〜
つまり、変化と競争の激しい現代の世界で製品・組織・従業員のために出来る最善のことは「実験と学習を重んじる組織文化を育み、そうした文化を実現する効果の高い技術・管理系ケイパビリティの強化に投資をすること」という結果である。

[bob-taniさんの感想 · 2022年6月25日]

潜在的構成概念を軸に統計的なデータを算出した記録。
実に科学的。ハイパフォーマーは質も高く量も多い結果となる組織傾向が見えてくる。
アンケートの取り方や用いた統計手法まで章を割いている珍しさ。
4年かけて集めたデータの質にこだわり実務に活かせる話がそろっている。
この手の書籍の源流の一つであり押さえておきたい。
この業界に限らずパフォーマンスの高い組織作りにサーベイ(もちろん適切な質問ではなく陳述)が欠かせないと見る。

[大阪工業大学図書館 枚方分館さんの感想 · 2022年4月23日]

資料ＩＤ :81800771
請求記号 : 007.63||F
配置場所：工枚ITエンジニア大賞
（※配置場所は、レビュー投稿時のものです。）

☆特集展示「ITエンジニア本大賞」☆

[japapizzaさんの感想 · 2022年1月30日]

■パフォーマンスの良好な組織とそうでない組織の比較
・コードのデプロイ頻度は46倍
・コミットからデプロイまでのリードタイムは1/440
・変更復旧時間（稼働停止から復旧に要する時間）は1/170
・変更失敗率は1/5

■有益で質の良い情報
1．受け手が解消したいと思っている疑問に対し、答えをもたらしてくれる
2．適切なタイミングで伝達される
3．受け手が有効に使えるようなやり方で提示される

■継続的デリバリとは？
・「品質」の概念を生産工程の最初から組み込んでいく
・作業はバッチ処理で進める
・反復作業はコンピュータに任せて人間は問題解決に当たる
・徹底した改善努力を継続的に行う
・全員が責任を担う

■継続的デリバリを実践するために必要な基盤整備
・包括的な構成管理
・継続的インテグレーション
・継続的テスト

■継続的デリバリの効果
・アプリケーションコード、システムコンフィギュレーション、アプリケーションコンフィギュレーション、ビルドスクリプト、コンフィギュレーションスクリプトに対するバージョン管理
・信頼性が高く、修正が容易で、定期的に実行される、包括的なテストの自動化
・デプロイメントの自動化
・継続的インテグレーション
・情報セキュリティのシフトレフト（時間軸上左へ移す、つまり、従来よりも早い段階から実施する）
・「寿命」の長い機能ブランチではなくトランクをベースにした開発
・テストデータの効果的な管理

■継続的デリバリの促進要因
・バージョン管理
・デプロイメントの自動化
・継続的インテグレーション
・トランクベースの開発
・テストの自動化
・テストデータの管理
・情報セキュリティのシフトレフト
・疎結合アーキテクチャ
・権限をもつチーム
・モニタリング
・プロアクティブ（予防的）な通知

■ハイパフォーマーである可能性が高い要素
・テストの大半を、統合環境を必要とせずに実施できる
・アプリケーションを、それが依存する他のアプリケーションやサービスからは独立した形で、デプロイまたはリリースできる（そして実際にもデプロイまたはリリースしている）
・チーム外の人物の許可を得なくても、対象システムに大幅な変更を加えられる
・対象システムの変更作業で他チームに頼ったり、他チームに相当量の作業を課したりすることなく、対象システムに大幅な変更を加えられる
・チーム外の人々とやり取りしたり協働したりすることなく作業を完遂できる
・ソフトウェア製品やサービスを、それが依存する他のサービスに関係なく、オンデマンドでデプロイ、リリースできる
・統合テスト環境を必要とせずに、オンデマンドでテストの大半を実施できる
・デプロイメントを、無視できるほどわずかな稼働停止時間のみで、通常の勤務時間内に完了できる

■コンウェイの法則と逆コンウェイの法則
　チーム間のコミュニケーションの状態とシステムアーキテクチャとのこのような関係を最初に論じたのは米国のコンピュータ草創期のプログラマーMelvin Conwayであり、具体的にはこう述べた―「システムを設計する組織は〈中略〉その組織のコミュニケーション構造を反映した設計しか生み出せないという制約に縛られる」。これに対して我々の調査研究では「逆コンウェイ戦略」とも呼ばれる考え方―組織はチーム構造と組織構造を進化させて、望ましいアーキテクチャを実現すべきだ、という考え方―を裏付ける結果が出ている。目指すべきは、「〈チーム間のコミュニケーションをさほど要さずに、設計からデプロイまでの作業を完遂できる能力〉を促進するアーキテクチャを生み出すこと」なのである。
　この戦略を可能にするアーキテクチャ面でのアプローチとしては「コンテキスト境界とAPIにより、大規模なドメインを、より小規模、より疎結合なユニットに分割する」「テストダブル（ソフトウェアのテストでテスト対象が依存するコンポーネントを書き換えた代用品）と仮想化により、サービスやコンポーネントを独立した形でテストする」などが挙げられる。この点で、サービス指向のアーキテクチャなら（またマイクロサービスアーキテクチャも、堅固なものであれば）しかるべき成果をあげられるはずである。ただしそうしたアーキテクチャを実現しようとする際には、成果の達成度の厳密なモニタリングが不可欠である。あいにく現実には、サービス指向を謳っているにもかかわらず、独立した形でサービスをテスト・デプロイできず、チームがパフォーマンスを高められない、というアーキテクチャが多い。
　もちろんDevOpsのキモはチーム間のより良い協働であり、ここで「チームは協力し合うべきではない」などと説いているわけではない。疎結合のアーキテクチャの目的は「組織内でのコミュニケーションの処理能力を、実装レベルの細かな意思決定に関するやり取りで使い切ったりせず、より高次な共通の目標やその達成方法に関する議論に使えるようにすること」なのである。

■重要なのは、チームが他のチームやシステムに依存せずに製品やサービスに変更を加えられることである。

■リーンマネジメントのプラクティス
１．進行中の作業（WIP:Work in Progress）を制限することでプロセスの改善とスループットの増大を図る
２．品質と生産性に関する重要な数値指標と、（不具合も含めた）作業の現況とを一覧できるビジュアライズディスプレイを作成・継続管理する。エンジニアも管理者もビジュアルディスプレイを利用できるようにし、提示されている数値指標を経営目標に追従させるよう努力を重ねる
３．アプリケーションのパフォーマンスとインフラのモニタリングツールから得たデータに基づいて、日常レベルのビジネス上の意思決定を行う

■リーン製品開発のプラクティス
１．１週間未満で製品と機能を完成して頻繁にリリースできるよう、関連作業を細分化して進める能力
２．開発の最初期から顧客関連業務に至る作業フロー全体に対するチームの理解度と、（製品や機能の状況も含めて）このフローの可視化の度合い
３．組織が顧客フィードバックを積極的・定期的に収集し、それを製品デザインに盛り込む能力
４．承認不要な開発プロセスの一部として、開発チームが有する、製品仕様の作成・変更権限

■変革型リーダーシップ
・ビジョン形成力
・心に響くコミュニケーション能力
・知的刺激
・支援的リーダーシップ
・個人に対する評価

A.1　継続的デリバリの促進効果が高いケイバビリティ

1.本番環境のすべての成果物をバージョン管理システムで管理
　GitHubやSubversionなどのバージョン管理を利用して､アプリケーションのコードやコンフィギュレーション、システムのコンフィギュレーション、本番環境のビルドやコンフィギュレーションを自動化するためのスクリプトなど、本番環境のすべての成果物を管理するケイバビリティである。第4章を参照。
2.デプロイメントプロセスの自動化
　デプロイの完全自動化(手作業による介入が不要な状態) の実現の度合いである。第4章を参照。
3.継続的インテグレーションの実装
　継続的インテグレーション(Continuous Integration: C1)は継続的デリバリの実現に向けての第一歩である。CIとは「コードに定期的にチェックインし、チェックインのたびに重大な不具合を発見するための迅速なテストがトリガーされ、不具合が見つかれば開発者が直ちに修正する」という開発のプラクティスである。このプロセスによって正規化されたビルドとバッケージを作成にデプロイ、リリースする。第4章を参照。
4.トランクベースの開発手法の実践
　トランクベースの開発は､ ソフトウェアのデプロイとデリバリにおけるパフォーマンスの予測要因となりうることが立証されている｡特徴は「コードリポジトリでアクティブなブランチの3つ未満」「統合前のブランチとフォークの『寿命』は非常に短い(たとえば1日未満)」「アプリケーション担当チームが統合の際のコンフリクトやコードフリーズ、スタビライゼーションのためにコードへのチェックインやプルリクエストをストップする『コードロック』の期間がほとんどあるいはまったくない」などである。第4章を参照。
5.テストの自動化
　ソフトウェアのテストが開発プロセス全般にわたって継続的に(手作業ではなく)自動的に行われる、というプラクティスである。効果的なテストスイートは信頼性が高い。本当の不具合を探知し、リリース可能なコードだけをパスさせる｡ 留意すべき点は「自動化テストスイートの作成と管理の主な責任を負うのは開発者」ということである。第4章を参照。
6.テストデータの管理
　テストデータは慎重に管理しなければならず、テストの自動化においてはテストデータの管理の重要性が増しつつある｡ 効果的なプラクティスとしては「使用しているテストスイートに適したデータを入手する」「必要なデータをオンデマンドで入手できる」「自組織のパイプラインでテストデータを調整できる」「実施できるテストの量がデータによって制限されてしまわない」などが挙げられる。ただし、自動化テストを行うのに 必要なテストデータの量は常に極力少なくするべきである。第4章を参照。
7.情報セキュリティのシフトレフト
　情報セキュリティ関連の作業を設計段階とテスト段階に組み込むことも、パフォーマンス向上の重要なカギである。具体的には「アプリケーションの情報セキュリティ関連のレビューを実施する」「情報セキュリティ担当チームをアプリケーションの設計段階からデモ段階までの全工程に参画させる」「事前に承認された情報セキュリティ関連のライブラリとパッケージを使う」「セキュリティ関連機能のテストも自動化テストスイートの一部にする」といったプラクティスが挙げられる。第6章を参照。
8.継続的デリバリ (CD) の実践
　継続的デリバリとは「ソフトウェアを、ライフサイクル全体にわたってデプロイ可能な状態で維持する」という開発プラクティスのことで、チームはこのデプロイ可能な状態の維持を、新機能の追加よりも優先する。このプラクティスを実践すれば、チームのメンバー全員がシステムの質とデプロイ可能性に関するフィードバックを素早く入手できるので､デプロイ不能との報告を受ければ直ちに修正できる。また、本番環境へのデプロイヤエンドユーザーへのデプロイもオンデマンドで行える。第4章を参照。

A.2　アーキテクチャ関連のケイパビリティ
9.疎結合のアーキテクチャ
　チームがアプリケーションのテストやデプロイを、他部署との調整を要さずにオンデマンドで、どの程 度実施できるかは、アーキテクチャの結合の度合いによって決まる。アーキテクチャが結合であれば、チームは他チームの支援や協力に頼らず独立した形で作業を進められ、それによりチームの迅速な作業と組織への価値提供とが可能になる。第5章を参照。
10.チームへのツール選択権限の付与
　本研究では 「ツールを選ぶ権限を与えられているチームのほうが継続的デリバリの能力が高く、それがソフトウェアの開発とデリパリのパフォーマンスを高める」との結果が出ている。チームの効率を上げるのに必要なものは何かを一番よく知っているのは現場担当者である。第5章を参照(製品管理の領域におけるチームの権限については第8章を参照)。

A.3　製品・プロセス関連のケイパビリティ
11.顧客フィードバックの収集と活用
　本研究で「顧客に関するフィードバックの定期的な収集と、製品設計におけるその活用に対して、組織が積極的であるか否かが、ソフトウェアデリバリのパフォーマンスを大きく左右する」との結果が出ている。第8章を参照。
12. 全業務プロセスの作業フローの可視化
　チームにとっては､ 製品の開発段階から顧客対応段階に至る全業務プロセスの作業フロー(ならびに製品や機能の現況)の可視化とその十分な理解が必須である。本研究で、このケイバビリティがパフォーマンスを大きく左右することが立証されている。第8章を参照。
13. 作業の細分化
　作業は1週間未満で完成できるよう、細分化する必要がある。コツは「ブランチを使って複雑な機能を開発し低頻度でリリースするのではなく、迅速な開発が可能な機能に細分化する」というものである。この手法は機能レベルでも製品レベルでも応用できる(たとえばMVP [実用最小限の製品］を利用するのも1つの方法。MVPとは製品自体とそのビジネスモデルの「検証による学び」が可能な規模の機能だけから成るプロトタイプのことである)。作業をこうして細分化して進めれば、リードタイムもフィードバックループも短縮できる。第8章を参照。
14. チームによる実験の奨励・実現
　チームによる実験とは、 開発者が開発プロセスにおいて、チーム外の人々の承認を得なくても新たなアイデアを試したり、仕様を更新したりできる能力を指す。このケイパビリティを強化すれば、チームは革新を迅速に実現し、価値を創出できる。特に「作業を細分化して進める｣「顧客フィードバックを製品設計に盛り込む」「作業フローを可視化する」といった他のケイバビリティと並行して強化すると効果が高まる。第8章を参照(このケイバビリティの技術面に関しては第4章を参照)。

A.4　リーン思考に即した管理・監視に関わるケイパビリティ
15. 負担の軽い変更承認プロセス
　本調査研究で「チーム外の変更諸問委員会(CAB：change advisory board) のレビューを義務付けるより、(ペアプログラミングやチーム内でのコードレビューなど)ペアレビューをベースにしたライトウェイトな変更承認プロセスを確立したほうが、パフォーマンスが高まる」との結果が出ている。第7章を参照。
16. 事業上の意思決定における､ アプリケーションとインフラの監視結果の活用
　事業レベルの作業に関する意思決定で、アプリケーションとインフラのモニタリングツールから得たデータを活かす能力。プラクティスとしては「問題が発生したら担当者を呼び出す」というやり方よりも優れている。第7章を参照。
17. システムの健全性のプロアクティブ(予防的)なチェック
　しきい値警告と変化率警告に基づいてシステムの健全性を重視し、問題の予防的な探知と軽減を図る能力。第13章を参照。
18. WIP制限によるプロセス改善と作業管理
　進行中の作業(WIP: Work in Progress)を制限して作業フローを管理するというのは、リーン思考の実践コミュニティではおなじみの手法である。効果的に実践すれば、プロセスの改善、スループットの増大、システムにおける制約の可視化がれる。第7章を参照。
19. 作業の可視化による、品質の監視とチーム内コミュニケーションの促進
　ダッシュボードや内部Webサイトなどのビジュアルディスプレイを品質やWIPの監視に活用すると、ソフトウェアデリバリのパフォーマンスが向上することが立証されている。第7章を参照。

A.5 組織文化に関わるケイパビリティ
20. (Westrum推奨) 創造的な組織文化の育成
　これは本研究で採用した組織文化の測定基準であり、航空や保健医療などきわめて複雑で高リスクな領域のシステムを専門に研究を重ねた社会学者Ron Westrumが提唱したモデルを下敷きにしている。そして 本調査研究では｢この確定基準で､ チームと組織全体のパフォーマンスを予測できるほか、燃え尽き症候群の軽減効果も予測できる ｢こと」が判明している｡ 具体的にこの基準で測定できるのは、情報の流れ、協働・信頼関係、チーム間の仲介などのレベルである。第3章を参照｡
21.学びの奨励と支援
　自組織は、継続的な進歩を遂げる上で、「学び」を必須の要素と捉えているか｡ 学習を「犠牲」と受け止めているか、それとも「投資」と考えているのか。これが組織の「学び」の文化を測る基準である。第11章を参照。
22.チーム間の協働の支援と促進
　従来、チーム同士は「縦割り」の関係にあったが、それをどの程度脱却し、開発・運用・情報セキュリティの領域を果たせているのかについて、そのレベルを反映するケイバビリティである。第3章および第5章を参照。
23.有意義な仕事を可能にするツール等の資源の提供
　職務満足度の予測要因となりうるケイパビリティである。強化のキモは「各構成員が困難でも有意義でやりがいのある仕事ができ、自身のスキルを活かし判断力を働かせる権限を与えられること｣「各構成員 が、職務を全うするのに必要なツール等の資源を与えられること」である。第10章を参照。
24.改善を推進するリーダーシップの実現や支援
　改善を推進するリーダーシップとは、DevOpsの実践に不可欠な技術的作業とプロセス関連作業を支援・増強するもので、次の5つの要素から成る - 「ビジョン」「知的刺激」「心に響くコミュニケーション」 「支援を重視するリーダーシップ」「個人に対する評価」。第11章を参照。

[noppoさんの感想 · 2021年11月18日]

チームの開発プロセスやシステムアーキテクチャを改善する参考になるかと思い読んだ。正直言って訳がわかりづらく、なかなか頭に入ってこない。言葉の意味がしっかりと定義されてないまま話が進むし、パッと読んでロジカルに思えない文章も散見された。

内容も個人的には目新しさはなかった。具体的にどうすればよいかというHowの部分が知りたいひとには向かない。DevOpsを進める上での学術的根拠がほしいひと向け。

[RyuKnoさんの感想 · 2021年11月6日]

めちゃくちゃよかった
なぜDevOpsが重要と言えるのか？がある程度信頼できる根拠とともに提示されており、今後組織にDevOpsを根付かせていく上でヒントになることがたくさんあった。