■目的

LeanとDevOpsの科学[Accelerate] 出版記念イベントに参加した際の目元プレゼン資料をもとにダラダラと書く。話されてた内容と筆者の考えが混ざるので注意。

■開催概要

・版元のImpressの方から説明
・Accelarate翻訳本のキモ(EMCシニアコンサルタント 鳥居さん)
・DevOpsを成功させるための必要な要素とプロセス（クリエーションライン 荒井 裕貴さん)
・DevOpsアセスメント体験（簡易版）

■Accelarate翻訳本のキモ

Accelarate翻訳本のキモ

・DORAの紹介

DORAというDevOpsのリサーチと評価をする団体がある。

主要メンバーは以下の3人

・Nicole Forgren(DORA CEO)
・Jes Humble(The DevOps Handbookの著者)
・Gene Kim(The Phoenix Project*の著者)

* The Phonix Projectの日本語版はThe DevOps　逆転だ！究極の継続的デリバリーと題名が大幅に変わってるので注意。

・DevOpsエンジニアの地位

アメリカでは、データサイエンティストの次に人気のある職業になっている。

<思ったこと> 人気があって給料が良いとはいってもこのレベルの給与がもらえるのって、日本で言うと吉羽龍太郎さんとかそれくらいのレベルの人では...?

・本編について

帰納法ではなく演繹でDevOpsの効果を解説

DevOpsのメリットについて、演繹法ではなく帰納法で解説している。具体的には、AmazonやNetflixなどの成功している企業(ハイパフォーマー)とそうでない組織を分けたときにどのような組織文化面や取組の違いがあるのかを統計的に整理した。

整理した結果として24のケイパビリティが導出された。ハイパフォーマンスな組織ほどこのケイパビリティを持っている割合が高い。

ソフトウェアデリバリの指標

コード生産性(LOC)やベロシティ、稼働率で図るのではなく、リードタイム、デプロイの頻度・平均修復時間(MTTR)・変更失敗率で測定することが重要。

ベロシティは人間の見積もりベースになるので成果を大きく見せるために見積もりを大きく見せたり、自チームのベロシティを稼ぐために他チームとの連携が疎かになりがちであるといった問題点がある。チーム間の連携なども含めて適切に評価するには、タスクに着手してから本番システムに反映されるまでのリードタイムを指標とするほうが適切らしい。

<思ったこと> 稼働率云々の話は勤め先のボスがよく喋ってる内容に似通ってるなと思った(フロー効率性とリソース効率性について（QCDのトレードオフなんて本当は無かったんだ）)。MTTRや変更失敗率はチームが自分たちの作っているものをどれだけ深く理解しているかということに直結するのでその点でも確かに指標としては正しいなと感じた。

スピードと安定性は両立可能

具体的にハイパフォーマンスな組織とそうでない組織の差がどれくらいかというところで、デプロイ頻度・リードタイム・MTTR・変更失敗率の4つの指標で解説。スピードと安定性は両立可能であることを説明している。

<思ったこと>自転車と同じで速いほど安定するという話と同じだと感じた。結局のところデプロイ頻度を増やせば安定的にデプロイするための仕組みの整備を行う。結果として変更失敗率は下がる。変更失敗率が下がると積極的にデプロイをするようになるのでリードタイムは短くなる。イメージ的には下図。

ハイパフォーマンスな組織とそれ以外の違い

4つの指標以外での違いについて解説。

組織文化の面では情報の流れがスムーズであること、ヒューマンエラーを根本原因にしないことなどがある。

<思ったこと> 情報の流れの下りはエンジニアリング組織論への招待でも述べられている。情報の流れがスムーズになり組織の情報処理能力が高まると組織としての問題解決能力が高まり、不確実性への対処能力が高まる(ガルブレイスによる組織の情報処理モデル)。

自動化については主にデプロイに焦点が当てられており、デプロイメントによってかかる精神的負荷を低減すること、デプロイに必要な設定管理を行うことの重要性などについて述べられた。テストの自動化についてはテストコードを開発エンジニアが記述しない限りは組織パフォーマンスと相関関係がないことがわかった(開発エンジニアが記述するほうがパフォーマンスが高い)

<思ったこと> テストコードの下りは開発エンジニアが書いたほうが良いことは理解した。しかし、テストコードではなくテストパイプラインについてはどうだろう？という点が疑問として残った。自分の関わったプロジェクトでは基本的にインフラエンジニアがCI/CDのパイプラインを記述することが多いためテストパイプラインについては開発エンジニアが記述する部分はあまり多くない(改めて見直すコンテナベースで作るメリットのプロジェクトでも同様。ただしアプリケーションの要件などのヒアリングに協力してもらってリと言った形で一部の開発エンジニアが手伝ってくれることはある。最近は手を動かしてもらうことも増えていて助かりますが)。このような場合のパフォーマンスへの影響はどうなのだろうか？聞いておけばよかった。

システム(というよりはアーキテクチャとプロセス)では、粗結合なシステム、デプロイ・テストの容易性が高いシステム、他のチームにやシステムに依存することなしに変更ができる組織のほうがパフォーマンスが高いといったことが述べられた。また、プロセス面ではチーム外部にデプロイ承認のためのプロセスが存在する場合はパフォーマンスが低下する。

<思ったこと> どちらかというと鶏か卵という問題になっている印象を受けた。成功しているから組織が大きくなる。大きな組織であれば、密結合なシステムよりも粗結合なシステムのほうが生産性は維持しやすい。また、デプロイやテストも見据えてシステムを設計できる組織はそもそもエンジニアリング能力が高いのでは？という気持ちもあり、これは因果関係をもう少し整理する必要を感じた。

プロセス面のチーム外部にデプロイ承認のためのプロセスが存在する場合のパフォーマンス低下は意外にシンプルではないかと感じた。具体的には、その外部プロセスへの説明にエンジニアのパワーが割かれて品質そのものが疎かになる。つまり、品質そのものを高めるという本質的な取組よりも承認者を納得させるには？というところにエネルギーを浪費するようになるからでは？と感じた。

環境とかの話は不毛なので飛ばす

変革型リーダーがいない組織はハイパフォーマーになる可能性が殆ど無い。とはいえ、日本と異なって欧米では優れたリーダー、マネージャーは優れたメンバーを引き連れてくるから必ずしも日本にも当てはまるかというと微妙らしい。改善努力の部分では楽しい職場とか、エビデンスに基づく実験と学びといったことが述べられていた。

<思ったこと> 技術・プロセス面で見たときに変革型リーダーを効率を上げるための技術的チャレンジ、プロセス的なチャレンジを奨励し、その結果を以て適切なメンバー評価を下す人と解釈すると納得感があった。また、適切な評価を下すには、リーダーとメンバーで予め仮説をすり合わせ、そこからの検証結果を学びとすると言った部分が必須になると思うのでまあ異論はないかという印象を受けた。

<<セッションを通じて感じたこと>>

基本的にこの本は統計結果を整理してDevOpsのプラクティスと比較しているだけなので、因果関係については教えてくれない。しかし、ハイパフォーマンス組織に共通している24のケイパビリティについては明白な事実なのでその点は留意したい。自身の組織を見返したときにこれらのケイパビリティを備えているか、備えていないのであればそれがどのような悪影響を及ぼしているのかといった点を掘り下げていくのは非常に成果があると思う。

■DevOpsを成功させるための必要な要素とプロセス

内容的には前のセッションとかぶる部分も多々あったので、一旦資料リンクのみ。LeanとDevOpsの科学[Accelerate] 発売記念イベント～DevOpsを成功させるための必要な要素とプロセス～

■DevOpsアセスメント体験（簡易版）

クリエーションラインさんが提供しているDevOps的な組織文化がどの程度定着しているかを測定できるサービスの簡易体験版だった。セッションの中でも説明があったが、組織のリーダーとメンバーなど可能な限りいろいろなロールを担っている人で集まって話合うことでそれぞれの認識の差異を浮き彫りにすることの効果が大きいだろうと感じた。