概要

アジャイル開発を通して組織を改革を目指している人や何を持ってパフォーマンスを測定するなどのエッセンスを知りたい人向けに 「LeanとDevOpsの科学」の自分なりの理解と経験 を踏まえて感じたことをまとめました。

前提条件

• なし

目次

• 概要
• 前提条件
• 内容
  • ■第1部　調査結果から見えてきたもの
    • 第1章　業務を加速させるということ
    • 第2章　開発組織のパフォーマンスを計測
    • 第3章　組織文化のモデル化と測定、改善の方法
    • 第4章 技術的プラクティス―継続的デリバリの基本原則と効果
    • 第5章　アーキテクチャのキーポイント
    • 第6章　デリバリライフサイクルに情報セキュリティを組み込む
    • 第7章　ソフトウェア管理のプラクティス
    • 第8章 製品開発のプラクティス
    • 第9章 作業を持続可能にする―デプロイ負荷とバーンアウトの軽減
    • 第10章　従業員の満足度、アイデンティティ、コミットメント
    • 第11章　変革型リーダーシップとマネジメントの役割
  • 第2部　調査・分析方法
    • 第12章　統計学的背景
    • 第13章　計量心理学入門
    • 第14章　アンケート調査を採用する理由
    • 第15章　データの収集方法
  • ■第3部　改善努力の実際
    • 第16章　ハイパフォーマンスを実現するリーダーシップとマネジメント
    • 付録
• まとめ

内容

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

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

アジャイル開発（DevOps）を前提になっている気がするが、下記の4つの指標に着目し、パフォーマンスを上げることで業務を加速する（価値を提供する）ことができるとのこと。

• デプロイ頻度
• コミットからデプロイまでのリードタイム
• 平均復旧時間（MTTR）
• 変更失敗率

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

測定すべき4つの指標を分析するとハイパフォーマーは他の集団を引きはなし続けているらしい。

1人からLeanやDevOpsを実践できるような組織文化が改革を促し、継続することでハイパフォーマーな組織は、ローパフォーマー／ミディアムパフォーマーな組織を置いてきぼりにしてしまうのだろう。

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

継続的デリバリとリーンマネジメントは組織文化にも良い影響を与えるとのこと😲

DevOps 文化: Westrum の組織類型にある3分類で創造的な組織になると良い影響が与えそう。

• 不健全な組織 ・・・ ブラックな企業のイメージ
• 官僚的な組織 ・・・ 大企業のイメージ
• 創造的な組織 ・・・ 先進的な企業のイメージ

不健全な組織	官僚的な組織	創造的な組織
権力志向	ルール指向	パフォーマンス指向
協力的でない	積極的な協力ではない	積極的に協力
情報を遮断	情報を軽視	情報を積極的に活用
無責任	責任範囲を限定	リスクを共有
仲介を阻止	仲介を許容	仲介を奨励
失敗を責任転嫁	失敗は制裁	失敗を調査
新規性を否定	新規性を問題視	新規性を積極的に受け入れる

• 参考URL
  DevOps 文化: Westrum の組織類型

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

継続的デリバリは下記の2つにつながるとのこと

• デプロイ関連の負荷の軽減
• バーンアウトの軽減

大規模デプロイをCABなどを通じてチーム外の組織に承認をしてもらうための準備に数週間かけてデプロイすれば、「やっと本番環境にリリースできた。。。（燃え尽きて灰になる）」の状態、つまりバーンアウトの状態になってしまう。

その一方、デプロイ関連の負荷を軽減して、毎日のようにデプロイしていれば、日常作業になるのでバーンアウトしにくい状態になる。

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

継続的デリバリのアーキテクチャは

• テストの大半を統合環境なしで実施可能
• チームとアーキテクチャが疎結合
• 他チームに依存せずに開発（デプロイ）できる
  であることがポイント。

第6章　デリバリライフサイクルに情報セキュリティを組み込む

情報セキュリティの対策を最初からソフトウェアデリバリ全体に組み込むと、デリバリーのパフォーマンスが向上するだけでなく、セキュリティの質も上がる とのこと

第7章　ソフトウェア管理のプラクティス

リーンマネジメントのプラクティスが良いとのこと。

• 変更中の作業（WIP）を制限
  1日未満で完了する単位に作業タスクをつくる

• 可視化(見える化)
  GitHub,GitLabJiraなどのツールを使って、状況をダッシュボードで可視化する

• ワークフローの可視化
  誰が何をやっているか可視化する？（イメージがわかなかった）

• 負担の軽い承認変更プロセス
  必ずチーム外や組織、すなわち変更諮問委員会（CAB）の承認を得なければ、デプロイすることができない場合、準備や調整を含めると数日、数週間の時間が必要となる。

  このような承認変更プロセスが負担の重たいチームと負担の軽いチームを比較したときに、負担の軽いチームの方がパフォーマンスまし、もしくは相関関係がなとということがわかった。

第8章 製品開発のプラクティス

製品開発のプラクティスは「作業を細分化して進めてデリバリ」がポイント。リリースできる単位で作業細分化しないとデリバリパフォーマンスは上がらない🤔

第9章 作業を持続可能にする―デプロイ負荷とバーンアウトの軽減

作業を持続可能にする には

• デプロイ負荷の軽減 と
• バーンアウト（燃え尽き症候群）を招きがちな問題排除
  がポイント。

バーンアウトを招きがちな「よくある問題」

• 過重労働
• 自律性の欠如
• 不十分な報奨
• 人間関係の断絶
• 公平性の欠如
• 価値観のズレ

第10章　従業員の満足度、アイデンティティ、コミットメント

組織に対する思い入れ（エンゲージメント）と組織のパフォーマンス は相関関係にある とのこと

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

リーダーはメンバーへの間接的な影響を与え、チームのパフォーマンスをあげるようにする。
変革型リーダーは次のような特徴を持つ。
変革型リーダの特徴

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

管理者（マネージャー）についても、必要なお金（予算）を確保し、より良い組織文化を形成する支援をする必要があるなど記載されていた。中でも従業員が失敗を恐れないようにするという部分が個人的には大事だなと思った。

第2部　調査・分析方法

第12章　統計学的背景

下記の分析法が記載されていましたがまった1使いこなせない😥

• 分析法の種類
  • 記述的
    国勢調査のような記述アンケートなど
  • 探索的
    データ間の関連を探す
  • 推計予測的
    仮説を立て検証する
  • 予測的
    過去の事象に基づき未来を予測する
  • 因果的
    無作為化された検証（A/Bテストなど）
  • 機械論的
    専門家が正確な計算を行う（物理学/工学の分野がおおい）

第13章　計量心理学入門

アンケートも専門的な知識が必要であることがわかった。

• 悪いアンケート調査
  • 誘導する質問
  • わなにかける質問
  • 1つの質問文に複数の質問事項
  • 不明確な言葉使い

第14章　アンケート調査を採用する理由

アンケート調査を採用する理由は下記の5つとありましたが、納得ですね。

1. データの収集と分析を素早く行える。
2. システムデータを用いてシステム全体に関する測定を行うのは困難
3. システムデータによる完全な測定は困難である
4. アンケート調査によるデータは信頼できる
5. アンケート調査によってしか測定できない事柄がある

第15章　データの収集方法

今回のデータ収集方法について記載されていた。

■第3部　改善努力の実際

第16章　ハイパフォーマンスを実現するリーダーシップとマネジメント

INGの企業改革を題材に高パフォーマンスを実現するリーダシップやマネジメントについて記載されていた。

付録

本書のエッセンスをまとめた内容になっており、実践で本書を活用するときに使えそうな付録です。

• 付録A　改善促進効果の高いケイパビリティ
• 付録B　統計データ
• 付録C　本調査研究で使用してきた統計的手法

まとめ

• Lean開発プラクティス、DevOpsによるデプロイを通じて、パフォーマンスが向上する。
• パフォーマンス測定は、下記の指標を使うのがよい
  • デプロイ頻度
  • コミットからデプロイまでのリードタイム
  • 平均復旧時間（MTTR）
  • 変更失敗率
• 指標値はシステムからだけではなく、アンケート調査からも測定する
• 1日未満で作業できる内容に分割するために、疎結合アーキテクチャを適用する
• デプロイ負荷を下げる（テストの大半を統合環境なしで実施可能とし、他チームに依存せずにデプロイできる）
• DevOps 文化: Westrum の組織類型にある3分類で創造的な組織になる

https://marshmallow-qa.com/k69blog_com?utm_medium=url_text&utm_source=promotion

本記事を読んでいただきありがとうございまいた。
少しでもみなさまのお役に立てばうれしいです。