「LeanとDevOpsの科学」読書メモ

「LeanとDevOpsの科学」の勉強メモ。

４章

4.1

アジャイル開発を実践しているチームの間では、管理面のプラクティスやチームのプラクティスに比べて技術的プラクティスは二の次という扱いをする傾向が強い

しかし

技術的プラクティスが

• 高頻度
• 高品質
• 低リスク

なソフトウェアリリースを実現する上で決定的な役割を果たすことが立証されている

そこで

継続的デリバリを１つのケイパビリティとして測定するため

また

継続的デリバリが

• ソフトウェアデリバリのパフォーマンスと組織文化
• ほかの成果や副作用

にどう影響するのかを評価するためにおこなった調査研究

これにより、継続的デリバリのプラクティスは、結果に測定可能のレベルの影響を確かに与えていることが明らかになった。

4.1「継続的デリバリ」とは

(16:15)

継続的デリバリとは

• 機能の追加
• 構成の変更
• バグの修正
• 各種試行

など、さまざまな変更を、

• 安全かつ
• 迅速かつ
• 持続可能な形で

• 本番環境に組み込んだり、
• ユーザーに提供したりする

作業を促進する一群のケイパビリティからなる手法である。

次の５つの基本原則が柱

• 「品質」の概念を生産工程の最初から組み込んでいく
  • ツールと人員を駆使して問題を素早く探知できる組織文化の構築に投資する
  • 探知と解決がまだ低コストでできる段階で、迅速に問題を修正できるよう図る
• 作業はバッチ処理で進める
  • 作業を細分化すれば、不可欠なフィードバックを得られ、適切な軌道修正が可能になる
  • バッチ処理ではオーバーヘッドが多少増えるが、トータルでマイナスになるような作業を回避できるため、見返りが非常に大きい
  • 継続的デリバリの主目的の１つは「ソフトウェアデリバリのプロセスの経済性を改善し、個々の変更の追加費用を低く抑えること」
• 反復作業はコンピュータに任せて人間は問題解決に当たる
  • 変更の追加費用の削減に有効な方策の１つ
    • リグレッションテストやソフトウェアのデプロイなど時間のかかる反復作業の簡素化、自動化に投資すること
  • 人間は上記で生まれた時間的、労力的余裕を活用し、より高い価値のある問題解決に注力できる
    • →フィードバックに応じてシステムやプロセスのデザインを改善する

• 徹底した改善努力を継続的に行う
  • 常に優れたパフォーマンスを示すチームの最大の特徴
    • 決して満足せず常にさらなる高みを目指す
  • 改善が全メンバーの日常作業の一環
• 全員が責任を担う
  • （直訳すぎて言いたいことがよくわからない）

これを実践するためには、

下記３種の作業の基盤を整備する必要がある。

• 包括的な構成管理(CM: Configuration Management)
  • 以下の作業環境を整備する必要がある
    • バージョン管理で収集した情報のみをを使い
    • 完全に自動化した方法で
    • ソフトウェアをビルド・テスト・デプロイする
  • すべてバージョン管理の自動化されたプロセスに従っておこなうべき
    • 作業環境の変更
    • その環境で運用しているソフトウェアの変更
  • 手作業で承認すべき部分は残るが、その後はどの変更も漏れなく自動化すべき

• 継続的インテグレーション (CI: Continuous Integration)
  • ブランチを作って、何週間もかけて機能開発しているチームは多いが、統合するのにかなりの時間と修正作業を要する
  • 「作業をバッチ処理で進める」と「品質の概念を最初から組み込んでいく」の原則を実践しているハイパフォーマンスチームの場合、ブランチの寿命は常に１日未満
    • メインへの統合を頻繁におこなっている
    • 変更を追加するたびに、単体テストの実施も含めたビルドプロセスが発動
    • プロセスのどの部分が失敗しても、開発者はすぐに修正をおこなう
• 継続的テスト
  • 開発プロセスに必須の構成要素として常時おこなう必要がある
  • 下記のようにすべき
    • バージョン管理システムでコミットするたびに単体テストと承認テストが自動的に実行
    • 変更に関するフィードバックを開発者が迅速に取得できる
    • 開発者は不具合の優先順位を決めて修正にあたれるよう、自動化されたテストはすべて実行可能にすべき
    • テスターは、CIで生じる最新のビルドに対して継続的に探索型テストをおこなうべき
    • 関連する自動テストが全て作成され、その全てに合格しなければ「作業完了」でない

継続的デリバリとは、

室の高いソフトウェアをより高頻度でより確実にユーザに提供できるよう、複数のフィードバックループを作ること

である。

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

これまでで、継続的デリバリのプラクティスを導入すると、

• デリバリのパフォーマンスが向上する
• 組織文化に好影響が及ぶ
• さらに、燃え尽き症候群やデプロイ関連の負荷が軽減される

という調査結果が紹介された。

しかし、アーキテクチャが、リリースプロセスやデリバリ対象のシステムにおいて速度や安定性の向上を目指す上での障害となってしまう場合がある。

ということで、この章では、アーキテクチャがどう影響を与えるか、について検証している。
その結果としては、

下記が疎結合であれば、あらゆる種類のシステムにおいてパフォーマンスの向上が可能。

• システムどうし
• システムの構築チームと維持管理チーム

5.1 システムのタイプとデリバリのパフォーマンス

「ローパフォーマーは、他社が開発したカスタムソフトウェアを使っている、あるいは、それを統合の対象にしている場合が多い」という事実。

つまり、開発対象のアーキテクチャそのものには依存していない、ということ。

そして、アーキテクチャの新旧によらず、２つの特性をもたせることが重要。

5.2 注力すべきはデプロイとテストの容易性

• テスト容易性
  • テストの大半を、統合環境を必要とせずに実施できる
    • 統合環境：複数の独立したサービスがともにデプロイされる環境のこと
• デプロイ容易性
  • アプリケーションを、それが依存する他のアプリケーションやサービスからは独立した形で、デプロイまたはリリースできる

この２つの特性をもたせるには、システムが疎結合である必要がある。

さらに、チームとアーキテクチャが疎結合であることが重要。

→チームとチーム外とのコミュニケーションが必要となるかどうかが、大きなパフォーマンスの差を生んでいる。

コンウェイ：

システムを設計する組織は＜中略＞その組織のコミュニケーション構造を反映した設計しか生み出せないという成約に縛られる

コンウェイ

の逆の考え方を提唱している。（逆コンウェイ戦略）

組織はチーム構造と組織構造を進化させて、望ましいアーキテクチャを実現すべきだ

目指すべきは「＜チーム感のコミュニケーションをさほど要さずに、設計からデプロイまでの作業を完遂できる能力＞を促進するアーキテクチャを生み出すこと」

上記を可能にするアプローチ

• コンテキスト境界とAPIにより、大規模なドメインを、より小規模、より疎結合なユニットに分割する
• テストダブルと仮想化により、サービスやコンポーネントを独立した形でテストする
  • テストダブル：ソフトウェアのテストでテスト対象が依存するコンポーネントを書き換えた代用品）→つまりモックなど？

など。

あいにく現実には、サービス思考を謳っているにも関わらず、独立した形でサービスをテスト・デプロイできず、チームがパフォーマンスを高められない、というアーキテクチャが多い。

耳の痛い話である。

5.3 疎結合アーキテクチャにはスケーリング促進効果も

カプセル化された疎結合アーキテクチャと、それにあった組織構造を実現すると、２つの重要な効果が得られる。

• 作業の店舗と安定性が向上し、バーンアウトやデプロイ関連の負荷が軽減されて、デリバリのパフォーマンスが向上する
• 技術系部署をかなりの規模まで拡大でき、しかも生産性を直線的に（あるいはそれを上回る率で）高められる

人を増やすと全体の生産性は上がるが、一人あたりの生産性は落ちる（つまり、一人あたりの効率は落ちる）というのが従来の見方だったのが覆されている。

ここでの指標としては、開発者一人あたりの1日のデプロイ件数を指標としているが、
開発者の人数が増えるにつれて、ハイパフォーマーほど一人あたりのデプロイ件数が増える結果となっている。

→つまり、疎結合なアーキテクチャを維持していれば、人数を増やすほど生産性が上がる。
→これは確かにそうかもしれないが、意外な事実。