『LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する』 を読んだので、書籍から得た知見をご紹介します。

背景

『チームトポロジ』を読んで、『LeanとDevOpsの科学』も必読と感じて、この本を読みました。

? LeanとDevOpsの科学［Accelerate］ テクノロジーの戦略的活用が組織変革を加速する - インプレスブックス

以下、印象に残った箇所の引用とメモです。

■第1部　調査結果から見えてきたもの

第1章　業務を加速させるということ

1.1 「成熟度」ではなく「ケイパビリティ」に焦点を

テクノロジー部門の管理者たちは、市場で優位に立つため、ソフトウェアを迅速かつ確実にデリバリしなければならない。しかし多くの企業にとって、これはソフトウェアのデリバリ方法の大幅な変更を意味する。この場合に成功のカギとなるのが、組織の「成熟度」ではなくケイパビリティ(組織的な能力あるいは機能)に焦点を当てた、状況の適切な把握とそれを可能にする指標の測定である。

? Capability（ケイパビリティ）に焦点を当てていきたい。

ケイパビリティモデルへの移行が求められている第2の理由は、成熟度モデルは多くの場合、段階を追って所定の成熟度を達成していくことを良しとし、同じレベルのチームや組織には似たようなテクノロジーやツール、ケイパビリティを推奨していくという点である。特定のレベル(たとえば「レベル2」)と認定されたチームや組織は、どれも似たり寄ったりの状況、状態にあると仮定するが、これが現実に即していないことはテクノロジー関連組織で働く者にとっては周知の事実であろう。

? リアルワールドでは、同じ/似たり寄ったりの状況、状態が続くことは無い。

第2章　開発組織のパフォーマンスを計測

2.2 望ましい尺度

ソフトウェアデリバリのパフォーマンスの測定基準 ・リードタイム ・デプロイの頻度 ・平均修復時間 ・変更失敗率

? 上記の測定基準を参考にしたい。

第3章　組織文化のモデル化と測定、改善の方法

3.1 組織文化のモデル化と測定

表 3.1 Westrum が提唱した3タイプの組織文化とその特徴

? 参考にしたい。

第4章　技術的プラクティス―継続的デリバリの基本原則と効果

4.4 継続的デリバリのプラクティス ― 有効性の高いものは

4.4.4 トランクベースの開発

本調査研究では「『寿命』の長い機能ブランチをベースにした開発をしているチームより、トランクベースの開発をしているチームのほうがデリバリのパフォーマンスが高い」という結果も出た。

? トランクベースの開発は、実務経験が無いので一度どこかで試してみたい。

このようにして、トランクベースの開発というプラクティスには、ソフトウェアデリバリのパフォーマンスを向上させる効果があることがわかっても、「GitHub Flow」での作業に慣れている開発者の中には懐疑的な姿勢を崩さない者がいる。「GitHub Flow」はブランチを使った開発への依存度が高く、トランクへのマージは定期的に行うだけである。ただ、我々が聞いたところでは、ブランチ戦略は開発チームがブランチをあまり長期間維持しなければ効果的だそうで、「寿命」の短いブランチを最低でも1日1回トランクにマージするのであれば、一般に受け入れられている継続的インテグレーションのプラクティスと矛盾しないということであり、この点は我々も同意するところである。

? 慣れ親しんだ GitHub Flow にブランチの寿命を短くするという制約を設けると、トランクベースの開発に近づきそう。

第5章　アーキテクチャのキーポイント

5.4 必要なツールをチーム自らが選択できる

エンジニアが、あらかじめ承認されたものの中からツールやフレームワークを選ぶしかない、という組織は多い。このアプローチの目的としては次のようなものが挙げられる。

・作業環境の複雑さを減らす ・利用する技術をライフサイクルを通して管理するのに必要なスキルを確保する ・ベンダーからの購買力を強める ・使用するすべてのソフトウェアなどのライセンス管理を適正に行う

しかしこうした柔軟性に欠けるアプローチを採っていると、チームは自分たちのニーズに最適なツールを選べず、問題解決のために新たなアプローチやパラダイムを試すこともできない。

? 組織として技術選定スキルを高めることができなくなり、緩やかに競争力が無くなる恐れがある。

我々の分析では「ツールの選択も、技術的作業の重要な要素である」ということが立証されている。必要なツールをチームが選択できる場合、ソフトウェアデリバリのパフォーマンスが向上し、それが組織全体のパフォーマンスにも好影響を与える。これは驚くには当たらない結果である。ソフトウェアの開発とデリバリ、複雑なインフラの運用を担当する技術系の専門職であれば、作業の完遂とユーザーサポートに最善を図れるようツールを選ぶからである。

? “必要なツールをチームが選択できる場合、ソフトウェアデリバリのパフォーマンスが向上し、それが組織全体のパフォーマンスにも好影響を与える”

とはいえ、特にインフラのアーキテクチャや構成に関して言えば、標準化も悪くはない。

? チーム内で完結できない場合、例えば SRE チームの支援が必要な場合は標準化されたものを利用するというのも手。

もう1つ、本調査研究で判明したのが「情報セキュリティの概念をデリバリのプロセスに組み込んでいるチームも継続的デリバリのパフォーマンスが高い」という点である。ここでカギとなる要素は「事前に承認された、使い勝手の良いライブラリ、パッケージ、ツールチェーン、プロセスを、開発者とIT運用担当者が作業で使用できるよう、情報セキュリティの担当チームが取り計らうこと」である。

? セキュリティについても、セキュリティエンジニアの支援が必要な場合は標準化されたものを利用するというのも手。

5.5 アーキテクチャ設計担当者が焦点を当てるエンジニアと成果

使い手がまるで使う気になれないツールやテクノロジー、使い手が重視する成果や振る舞いを実現できないツールやテクノロジーを使わせる、というのは不適切なアプローチである。重要なのは、チームが他のチームやシステムに依存せずに製品やサービスに変更を加えられることである。

? 製品やサービスへの価値提供を優先して考えたい。

第11章　変革型リーダーシップとマネジメントの役割

11.1 変革型リーダーシップ

テクノロジーの変革にリーダーシップが果たす役割は、DevOpsをめぐる話題の中ではとかく見逃がされてきた。その役割は次の点で不可欠であるにも関わらず、である。

・高い信頼性と生産性を実現するための文化規範を確立しサポートする ・開発者の生産性を高めるテクノロジーを創造し、デプロイまでのリードタイムを縮小し、より信頼性の高いインフラをサポートする ・チームの実験や技術革新をサポートし、良質な製品を迅速に創造し実装する ・組織の部署を越えた取り組みにより、戦略的な協力関係を築き上げる

以上、現場からお送りしました。