Ryusuke Nomoto

[読書] LeanとDevOpsの科学

LeanとDevOpsの科学を読んだので、読書感想文を書きます 🙋‍♂️

 

用語の定義

ケイパビリティ

組織全体やグループとして保持する機能や能力

パフォーマンス

本書ではパフォーマンスという場合、組織のパフォーマンスとデリバリのパフォーマンスの2つの意味がある。
組織のパフォーマンスは以下の指標で定義される。
  • 収益性
  • 市場占有率
  • 生産性
 
デリバリパフォーマンスは以下の指標で定義される。
  • リードタイム
    • ここでのリードタイムとは、 コードのコミットからリリースまでの所要時間 を指す
    • 本来は「顧客が要求してからその要求が満たされるまでの時間」だが、ソフトウェア開発においては設計・開発部分の時間が計測しづらく不確実性も高いので、排除した
  • デプロイ頻度
    • ここでのデプロイとは、ソフトウェアをデプロイしてからリリースされるまで を指す
      • 「デプロイ」の定義に「デプロイ」という言葉が使われていてよくわからない
      • が、元々はリーン手法におけるバッチサイズの大きさをソフトウェア開発に当てはめたときにデプロイの頻度が負の相関を持つことを利用していることから、要は「リリース頻度」がどれくらいなのかを言ってると解釈してよい気がする
  • MTTR
    • サービス停止などのインシデントが発生してから復旧するまでの時間
    • 軽微な不具合を直してリリースするまでの期間ではない
  • 変更失敗率
    • 全リリースのうち、リリースが失敗したケースの発生率
 

総論

  • 24のソフトウェアデリバリの効果が高いケイパビリティがわかった
  • 次の5つに分類
    • 継続的デリバリ
    • アーキテクチャ
    • 製品とプロセス
    • リーン指向に基づく管理と監視
    • 組織文化
  • 各ケイパビリティとそれらがもたらす結果の関連性が以下。
    • notion image
    • デリバリパフォーマンスが良好な組織とそうでない組織では以下の差がある
      • デプロイ頻度は46倍
      • リードタイムは1/440
      • MTTRは1/170
      • 変更失敗頻度は1/5

      各論

      組織文化

    • 創造的な組織(使命や任務の遂行、成果に焦点を絞るパフォーマンス志向の組織で協力関係や信頼関係を重んじる)はデリバリパフォーマンスが高い
    • 創造的な組織文化は職務満足度を向上させる
    • リーン(アジャイル)のプラクティスと継続的デリバリと併用することで、創造的な組織文化に近づくことができる
    •  

      継続的デリバリ

      「継続的デリバリ」とは、機能の追加、構成の変更、バグの修正、各種試行など、様々な変更を、安全かつ迅速かつ持続可能な形で本番環境に組み込んだりユーザーに提供したりする作業を促進する一群のケイパビリティからなる手法のこと
       
      継続的デリバリの具体的なケイパビリティは以下。
    • バージョン管理
    • デプロイ自動化
    • 継続的インテグレーション
    • トランクベース開発
      • なるべくmasterもしくはそれに近いブランチで作業する
    • テスト自動化
    • テストデータの整備
    • セキュリティのシフトレフト
    • 疎結合なアーキテクチャ
    • チームに権限があること
    • モニタリング
    • プロアクティブ(予防的な)通知
    •  
      継続的デリバリが達成されることで次のような効果がある。
       
    • 帰属意識の向上
    • 創造的な組織文化の浸透
    • デプロイ負荷の軽減
    • チームのバーンアウト(疲弊)の軽減
    •  

      アーキテクチャ

      デリバリの観点でアーキテクチャに関して抑えなければならないのは以下の2点
    • テスト容易性
      • テストの大半を統合環境を必要とせずに実行できる
    • デプロイ容易性
      • アプリケーションを、それが依存する他のサービスから独立した形でデプロイできる
      これらを達成するには、チームとアーキテクチャが疎結合となっていることが重要
       
      疎結合な状態とは具体的には以下
    • チーム外の許可を得なくてもリリースできる
    • チームが自分たちの裁量と権限においてリリースできる(リリースにおいて他チームへの依存度が低い)
    • 他のチームとやり取りすることなくリリースできる
    • リリースの対象となるサービスが依存するサービスを気にすることなくリリースできる
    • リリースの対象となるサービスが依存するサービスを気にすることなくテストできる
    • 最小限のダウンタイムのみでデプロイできる
    •  

      製品とプロセス

    • 顧客フィードバック
      • 顧客の声を定期的・積極的に収集し、それを製品に取り込んでいるか
    • 業務プロセスの可視化
      • 要件定義から運用保守までのフローを開発チームが理解・可視化しているか
    • 作業の細分化
      • 1週間程度でリリース可能なサイズに作業が小さくなっているか
    • チームによる実験
      • チーム外の承認が不要で、新しいアイデアや仕様変更を行えるか
       

      リーン指向に基づく管理と監視

    • WIPの制限
      • 作業中のタスクを残したまま次のタスクに着手しない
    • 作業の可視化
      • カンバンなどを使っているか
    • 変更承認プロセス
      • プルリクエストのような軽量な承認プロセスが最も効果的
      • チーム外に承認を得るプロセスはむしろ逆効果
    • 監視
      • アプリケーションやインフラのモニタリング結果を元に日常的なビジネス上の意思決定を行う
    • プロアクティブな通知
      • システムパフォーマンスについてしきい値や変化率を用いて警告を通知している
       

      感想

      各ケイパビリティと効果の関連性がまとめられている良書

      肌感覚としてみんなが「これって重要だよね」って思っていた話を統計的に検証し効果を示してくれており、とても参考になりました。
      また、どのケイパビリティがなにに作用するかを図示してくれており、実際に開発を改善するためにどこから出発すればよいか、全体感を知ることができる点も参考になりました。

      ハイパフォーマーのGo-to-Market

      本書ではオンデマンドにリリースできてリードタイムも1時間未満なのがイケてる会社だぜってなっており、開発に閉じた話で言えばそれはそのとおりなんですが、そうした会社のGo-to-Marketどうなってるのかが気になりました。
      仕様変更を伴う開発の場合、ヘルプページを更新したりリリースノートを作成したり営業資料を更新したりビジネスサイドへの周知を行うなどのリリースに伴う開発以外の作業が発生します。
      こうした作業は一定チーム外とのコミュニケーションコストが発生するため、エンジニアがそんなにじゃぶじゃぶリリースできたら逆にビジネスサイドが「そんな仕様変更聞いてないよ」と困っちゃう気がするのですが、ハイパフォーマーな会社はそのへんどうしてるのかが気になりました。
       
       
       
badge