武舎広幸のレビュー一覧

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Nicole Forsgren Ph.D. / Jez Humble / Gene Kim / 武舎広幸 / 武舎るみ

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

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

[Vine]

面白いので頭にすっと入ってくる

UnityのC#で参考になるかと思い購入。
記載されているコードはC++だが、どの言語でも通じるように抽象的に書いてあるので問題なく理解できる。
実際によくある状況をデザインパターンで解決する、という内容が、ただパターンが羅列されている説明と比べると非常にわかりやすい。

＃タメになる

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Nicole Forsgren Ph.D. / Jez Humble / Gene Kim / 武舎広幸 / 武舎るみ

唯一言える注意点は、16章が重い！w
ここがメインコンテンツで、それ以外は言葉や前提を共有するための前菜なんだと思います。

その分、重い内容でも理解しやすく、コードだけでないレガシーなシステムに立ち向かう身としては、すごく実践的で、ここを起点に開発組織を改善していこうと思いました。

【A書評】
- CDに向けて基盤となる仕組みを早急に用意する
- 組織としてパフォーマンス計測ができるよう準備する

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

Webフロントエンドの複雑化に伴い、フロントエンドの設計手法の整備は現代の重要な課題だ。
そんななか、複雑なフロントエンドを何十年も構築してきたのは『ゲーム』の世界だ。
つまり状態をUIに変換していくにあたりどうモデリングするか、ゲームプログラミングからこそ学ぶ点があると思い、本書を手に取った。

この本は、いわゆるデザインパターンをどう道具としてフロントエンドで使っていくかを表したものである。
特定の技術スタックに依存した内容でないため、普遍的な知識を学ぶことができた。
特にコマンドパターンは見方を変えればFluxであり、現代Webフロントエンドにも繋がってくる考え方だ。
やはりこうした自分の領域にとらわれないすぎない知識収集が、最先端を歩んでくためには必要になってくるだろうと再確認した。

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

ゲーム開発者の視点で、「ゲーム開発で使われるアーキテクチャ、デザインパターン」にフォーカスして解説がなされている本。

GUI や アプリケーションフレームワーク に共通する部分が多く、「自分の中で今までパターンと意識していなかったもの」がパターンとして解説されていたこともあり、とても良い頭の整理になった。

また、それぞれのパターンの「なぜ？」が、ゲーム開発の生々しい実例と共に書かれていたので、面白かった。

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Nicole Forsgren Ph.D. / Jez Humble / Gene Kim / 武舎広幸 / 武舎るみ

なぜ開発生産性を改善する必要があるのか、多角的な目線から分析をし、システムや組織にどのように影響するかを知ることができる

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Nicole Forsgren Ph.D. / Jez Humble / Gene Kim / 武舎広幸 / 武舎るみ

Four Keysの元となった書籍。アンケート調査からパフォーマンスの良い組織の特徴を丁寧に説明している。話の盛り上がりとかは特に無いが、各指標値が開発組織の状態を表していることはよく理解できた。

Game Programming Patterns ソフトウェア開発の問題解決メニュー

RobertNystrom / 武舎広幸 / 阿部和也 / 上西昌弘

■ 感想
いい本でした。知っていることもあるものの、知らなくて勉強になったことや、次にコード書くときにもう少しうまく書けそうな気がする本でした。

Unityを使ったことがあれば、すでに利用しているパターンもあるので、Unity使っている人であれば入りのいい本でもあると思います。すでに利用していたパターンでも他との対比もあり理解が深まったり、どういう意図で作っているのかがわかるようになるので、より利用しやすくなります。

難易度的が低い本と言えず、ある程度の期間、ある程度のサイズ感の開発したことがないと理解しきれないと思います。Unity触って3〜5年目ぐらいで、書いてるコードがこんがらがってきて、うまく整理できないみたいな悩みがある人は一度読んでみるのもいいかもなと感じました。

パターンとしてコードの抽象化（分離）の話もありますが、データの最適化の項目もあり、そういう方向が好みの人にも合うと思います。

■ 抜粋

- よいソフトウェアアーキテクチャの本領が発揮されるのは、コードを読んで理解するときだと思っています。コードを脳に読み込むのは非常に時間のかかる処理なので、読み込む量をへらす方策を見つけることに意義があります。（P.12）
- 「分離」の定義はさまざまですが、2つのブログラムが「分離できていない（結合している）」というのは、一方を理解しないと一方も理解できない状態だと私は考えています。（P.12）
- ソフトウェアアーキテクチャを考える主要な目的は、この「次に進む前に頭に入れておかなければならない知識を最小にすること」です。（P.12）
- 面白いゲームを早くすることのほうが、早いゲームを面白くするより簡単です。（P.15）
- 「単純なコードは、書く時間も短くなる」とは言ってはいないことに注意してください。全体のコードの量が減れば、それを書く時間も短くて済むと考えるかもしれませんが、良いコードは蓄積によって得られるのではなく、精製によって得られるのです。（P.17）
- 抽象化と分離により、プログラムの改良は早く簡単にできるようになりますが、取り組んでいるコードがそのような柔軟性を必要としていると確信できるまでは、抽象化と分離に無駄な時間を割くべきではありません。（P.18）
- （メモ）AvatarAdjusterがInputHandlerをCommandとして受け取ることで実行する。この形を取れば、avatarの生成のタイミングか、画面遷移のタイミングだけに絞れる？（P.26）
- 原則は「変数のスコープは、処理に支障のない範囲で可能なかぎり狭くする」です。（P.93）
- 常にバグのないコードを書いているように思える憧れのコーダーたちも、別に超人的なプログラマーなわけではありません。彼らは、どんなコードにバグが入りやすいか本能的に知っているので、そのようなコードを避けているだけなのです。複雑な分岐と、変更可能な状態—時間経過とともに変化するフィールド—はそのようなバグの入りやすいコードのうちの2つです。（P.101）
- 可変更新間隔
私の知っているゲーム開発者のほとんどがこの方式を推奨しないことをわかった上で、ここに挙げています。なぜよくないないのかを知ることも意味があると思うからです。
- 早すぎる場合にも遅すぎる場合にも対応しています—ゲームが実時間に追いつけない場合は、追いつけるまで更新と描画の時間感覚を延長します。
- ゲームは非決定論的になり、不安定になります—先に述べたとおり、これが非常にやっかいな問題なのです。この方式では、物理シミュレーションとネットワーク通信がとりわけ扱いにくくなります。（P.153-154）
- 間違いは誰もが犯すものであり、創造的なプロセスのk塩となるものです。「取り消し（アンドウ）」を可能にするなどしてエラーをさりげなく処理することで、ユーザーの創造性は高まり、より良いものを作れるようになります。（P.192）
- 言語設計者はプロもアマも文法の定義を甘くみすぎています。パーサに楽をさせる文法を定義するのは簡単です。ユーザーに楽をさせる文法を定義するのは難題です。（P.197）
- （P.202）サブクラスサンドボックスパターン（強い継承を使いたい場合）
- パターンの適用条件
- 派生クラスの多い基底クラスがあるとき。
- 派生クラスが必要としている操作や処理を、基底クラスですべて提供できるとき。
- サブクラス間に共通するビヘイビアがあり、同じコードを使ってコードを簡略化したいとき。
- 派生クラスとシステムプログラムの結合を最小化したいとき。
- 派生クラスは、基底クラスを介してコードベースの他の部分にアクセスするのですから、必然的に基底クラスは派生クラスがアクセスする必要のあるシステム内のあらゆる箇所と結合することになります。（P.202）
- 最近ではオブジェクト指向言語の継承に対する批判を目にすることが多くなりました。継承は問題を起こすことが多く、基底クラスと派生クラスの結合ほど強い結びつきはありません。（P.202）
- ゲームのビヘイビアを定義するのに、スクリプト言語やその他の高レベルの手段を利用すると、実行時の効率はいくぶんか低下しますが、生産性はめざましく向上します。ハードウェアは進歩し続けますが、人間の脳のほうはそうはいきませんので、生産性の向上に重きを置くことがますます重要になってきます。（P.220）
- どんなプログラミング言語を使っていても、コツをつかんでしまえば、思いどおりにコードを書くのはそんなに難しいことではありません。難しいのは、実行させたいことが変わったときに簡単にそれに合わせられるコードをあらかじめ書いておくことです。（P.231）
- UnityフレームワークのクラスGameObjectはすべてコンポーネントでデザインされています。（P.254）
- Data-Oriented Design（P.298）
- 最適化を適用する第1の条件は、実行速度に問題があるときというのが普通です。データ局所化パターンも同じです。コードベース内のあまり実行されない部分にこのパターンを適用することで時間を無駄にしてはなりません。最適化すると、コードは複雑になり柔軟性が低くなるので、不必要な最適化を行うと後の作業が面倒になります。（P.299）
- Cachegrind（P.299）
- AngularなどのブラウザサイドのWebフレームワークでよく見られます。ブラウザ内で変更され、サーバに送信する必要が生じたデータを管理するのに、ダーティフラグが使用されます。（P.332）

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Nicole Forsgren Ph.D. / Jez Humble / Gene Kim / 武舎広幸 / 武舎るみ

リーンとDevOpsのケイパビリティが組織とソフトウェアデリバリのパフォーマンスを押し上げるということをアンケートと統計的手法による調査と分析に基づいて説明している。
組織及びチームが高いパフォーマンスを創出するために、その文化を如何に作るかがカギ。学びの組織文化とリーダーシップが大いに関係する。
経営管理（リーダーシップ、組織文化、マトリクス組織、リエゾン担当者、権限移譲、動機付け、目標管理、評価制度等々）に関心のある人にも読める本。
深い技術的知識は不要だけど、DevOpsの知識を補いたい人は他の文献をあたる必要があるかも。

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Nicole Forsgren Ph.D. / Jez Humble / Gene Kim / 武舎広幸 / 武舎るみ

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

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

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

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

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

万人のためのデザイン

エレン・ラプトン / 武舎るみ / 武舎広幸

開始:2022/8/5
終了:2022/8/14

感想
デザインで日常に潜む問題を解決する、だけでなく問題を発見する。消費者はもはや受動的な存在ではなく能動的にプロダクトに関係する必要がある。

LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する

Nicole Forsgren Ph.D. / Jez Humble / Gene Kim / 武舎広幸 / 武舎るみ

■パフォーマンスの良好な組織とそうでない組織の比較
・コードのデプロイ頻度は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章を参照。