DevOpsカルチャーのKPI

Westrumのカルチャー調査指標

Ron Westrumの開発した仕事の満足度調査の指標。

四半期ごとに調査実施し、プロジェクトやチームごとに集計することで、全体の傾向を把握できる。

6つの質問それぞれ、7(とてもそう思う) ～ 1(まったくそう思わない)で評価する。

1. 私のチームでは、情報は積極的に求められる。

2. 私のチームでは、失敗は学習の機会であり、失敗した人は罰せられない

3. 私のチームでは、責務が共有されている

4. 私のチームでは、組織横断的なコラボレーションが推奨され、報酬が出る。

5. 私のチームでは、失敗は探究心を引き起こす

6. 私のチームでは、新しいアイデアが歓迎される

計算式

回答を単純平均でスコアを出す。

$ S=\frac{A_1 + A_2 + A_3 + A_4 + A_5 + A_6}{6}

改善のために

このツールは、全体的な傾向を把握するためのもので、意図的に不正確な指標になっている。そのため個人の仕事のパフォーマンスを評価するために使ってはいけない。

以下の点に注意して運用しよう。

1. アンケートの匿名性を保つ

2. この調査を頻繁には行わない。4半期に1度くらいの頻度を推奨する。

3. 懲罰的な行動を正当化するのに、この調査を使わない。

4. チームの目標として、これを強調しすぎない。ポジティブな強調も、懲罰的な強調と同じくらい有害である可能性がある

5. 十分な規模のチームや長期に渡る十分なデータがある場合は、データサイエンスの技法を使って、特定のチームの懸念事項や破滅的なイベントを示すデータの異常値を検出できるかもしれない。

参考

新しい環境のプロビジョニング時間

チームが実験を行い、組織の機動性を高めるためには、多くの場合、主となるコードのデリバリーストリームと平行して、違う機能やオプションをテストできるように、新しいハードウェアを導入する必要があるだろう。このとき、手動でプロビジョニングを行うと、不必要なボトルネックが発生する。最初のステップは、すべてをスクリプト化し、仮想マシンやコンテナなどの動的プロビジョニングツールを用いて、数回のボタンクリックですべてを処理することだ。

新しい環境の立ち上げにかかる時間を測定する場合、単にボタンをクリックしてから環境が稼働するまでの時間だけを計測してはならない。また、最大のボトルネックである環境の承認や、プロビジョニングを決定する際の人間の手作業による手順も忘れてはならない。

ソフトウェアのライセンス

課金ルールの設定

予算の交渉

リクエストの承認

計算式

新しい環境のプロビジョニングにかかる時間は、要求が記録された時点から、環境準備の検証が完了し、新しい環境の準備が整ったことが要求した人に通知された時点まで、エンドツーエンドで計算する必要がある。数日や数週間ではなく、数時間単位であれば、良いスコアといえるだろう。

$ T = H_{prod} - H_{start}

成熟度スコア

エグゼクティブダッシュボードのために、環境プロビジョニングにかかる時間を、0～5のシンプルなスコアで表すことが出来る。

$ M = \frac{M_{max} - M_{min}}{T_{max} - T_{ideal}} (T - T_{max})

$ T_{ideal} = 1時間

$ T_{max} = 144時間: プロビジョニングの最大値

$ M_{min} = 0 : 成熟度の最小値

$ M_{max} = 5 : 成熟度の最大値

改善のために

1. 手動の決定や承認を特定し、可能な限り廃止する

2. 意思決定を自動化できるようなスコアリングソリューションを設計する

3. 監視やレポーティングのデータを利用し、使われてない環境を自動的にクリーンナップし、コスト超過の不安を軽減する

4. 本当に複雑な承認には、Deep Learning APIとAI戦略を使って、人間のボトルネックを置き換えることを検討する

アイデアから製品化までの時間

DXには効率性よりもアジリティの方が重要だ。組織は、顧客のニーズや要求の変化に迅速に対応する必要がある。技術者は、自分の仕事や組織のパイプラインをより速く、より労力をかけずに済むよう、効率化を図ることになれている。だが、我々は時として、解決が簡単な技術分野で最適化しすぎて、開発者の仕事の前後にある、あまり技術を必要としないパイプラインのことを忘れてしまう。成功をエンドツーエンドの時間で測ることにフォーカスしなおせば、他の目立たないボトルネックを解消する方法が見つかり、より速く本番環境に製品をデプロイできるようになる。エンドツーエンドのチーム全体がこの指標に責任をもつことで、特定の事業目標に向けた横断的なチームが自然に形成され、従来の部門ごとのサイロを打ち破ることになるだろう。(もちろん、それが推奨されるのであればの話だが！)

これはプロダクトオーナー、デザイナー、ビジネスチームが行う最初のコンセプトアイデア出しの作業を含め、アイデアのパイプライン全体を、JIRAやその他チケットトラッキングシステムに取り込むことで、もっとも上手くいくようになるだろう。

計算式

アイデアから製品化までの時間はかなりシンプルな計算式になる。

$ D = D_{prod} - D_{start}

成熟度スコア

エグゼクティブダッシュボードのために、アイデアから製品化までの時間を0～5のシンプルなスコアとして表すことができる。

$ M = \frac{M_{max} - M_{min}}{D_{max} - D_{ideal}} (D - D_{max})

改善のために

1. 最も上手くいくのは、特定のプロダクトや目標に特化した組織横断なチームを作ることだ。デザイナー、プロダクトオーナー、開発者、テスターが同じ部屋にいて、外部からの干渉を受けずに1つの共通の目標に向かって働くことで、スタートアップの魔法を再現できる。

2. 自身のソリューションを設計・開発する権限をチームに与える。明確に提示されたビジネス目標を達成するために、チームが自己管理できるようにすることはとても難しいことだが、その自由な意思決定が迅速なアジリティの鍵となる。

3. 長いチケットと短いチケットを比較して、ボトルネックを特定し、それを取り除く。

4. 構想を小さく分割する

5. MLP(Minimum Lovable Product) を継続的に見直す

6. すべてを自動化する。機能の提供を覗いて、自動化を最優先のタスクとして設定する。

リリースサイズ

アジャイル、DevOps、エクストリームプログラミングの原則の1つは、継続的インテグレーションと継続的デプロイを重視することだ。ソフトウェアとチームの両方を壊してしまうようなモノリシックな塊を避けるために、理想的には継続的デリバリによって、小さく、速く、リーンなリリースを実践すべきだ。これを計測する方法の1つは、リリースサイズをチェックすることだ。リリースの規模は、プロジェクトの総コード行数に対する、リリースで変更された行数の割合で測ることができる。リリースの変更量が少なければ少ないほど、確実にリリースできる頻度が高まる。

計算式

$ S = \frac{L_{changed}}{L_{total}}

成熟度スコア

当然ながら、プロジェクトのコードベース全体が非常に大きいと、この数値は小さくなる傾向にある。したがって、異なる規模のプロジェクトを比較する場合には、規模係数を使う必要がある。より重要なのは、この数値がプロジェクト内で時間経過とともに、どう変わっていくかということだ。

リリースサイズスコアは、リリースごとに異なる値として追跡できるが、リリースのサイズが大きくなる場合、そのデータは特に有用ではない。かわりに、直近のリリースのサブセットの移動平均を追跡すれば、トレンドをよりよく把握できる。

$ M = (\frac{M_{max} - M_{min}}{S_{max} - S_{min}})(S - S_{max})

あるプロジェクトにおいて、1%がリリースにおける最大の変更料で、0.0001%が達成可能な最小の変更量であると設定すると、計算式は次のようになる。

$ M = (\frac{5 - 0}{0.01 - 0.0001})(S - 0.01)

改善のために

1. 開発サイクルを短くする。期間が短ければ、作業総量も小さく済むからだ。

2. モノリスアーキテクチャから、デプロイ単位が小さくできるようマイクロサービスアーキテクチャに移行する

3. プレゼンテーション層からビジネスロジックを切り離し、抽象レイヤーを作る。APIはサブスクライバーから独立してデプロイ可能であるべきだ。

5. エンドツーエンドで継続的デリバリを導入し、コードの変更がテストにパスし承認されたら、すぐさま本番反映されるようにする。

参考

立ち上がりの早さ

チームが成熟し強力なDevOps文化を発展させれば、その知識や習慣を他のチームにも広め、成功を拡大することができる。しかし、チームの成功は、そこにいる人たちの個性が魔法のように混ざり合ってうまく機能しているからこその成果かもしれない。チームがどれだけ集団的な成功を伝えられているかを測る指標はあるだろうか？ドキュメントのアウトプットを定量的に測定することはできるが、それはゲームのように簡単なスコアであり、ドキュメントが意味のある価値を提供しているのか、それともチームがただひたすらドキュメントを作成しているだけなのかを判断する方法がない。他のチームが作ったプロダクトを活用しているかどうかを測定することもできるが、それは組織の特定のビジネスニーズやチームの特定のプロダクトに大きく依存します。だが、新しいチームメンバーがどれだけ早く立ち上がるれかを評価すれば、チーム内でどれだけ知識が継承されているかを客観的に測ることができるかもしれません。

新しいチームメンバーの立ち上がりの早さは、間接的にいくつかの価値ある特性を測ることがでる。そのチームの特徴は次のようなものだ。

1. 新メンバーへのコーチングに長けている。

2. 最新のドキュメントが充実している。

3. 開発要求をさばくための仕組みが自動化されている。

4. 組織的に自己完結している。

5. 外部コードへの依存を最小限に抑えている

6. 優れたアーキテクトがいて、明確なコーディング標準を持っている。

もしチームが新しい開発者を短期間で生産的にすることができれば、それはそのチームがアジリティと成熟したDevOpsプラクティスを体現している証拠だ。

計算式

立ち上がりスピードを計測するもっとも簡単な方法は、新しいチームメンバーの参画日と、そのメンバーが携わったコード変更が、本番デプロイされた日を比べることだ。

$ R = D_{prod} - D_{start}

成熟度スコア

$ M = \frac{M_{max} - M_{min}}{D_{max} - D_{ideal}}(D_{max} - D)

改善のために

1. コードの共同所有ができているチームは、新しいメンバーへのコーチングを上手くやれる可能性が高い

2. ドキュメントの量よりも質を重視する

3. 開発のセットアッププロセスを自動化する

4. 開発のセットアッププロセスを頻繁にテストし、最新の状態にしておく

5. 認証アカウントを統合し、システムへのアクセスのプロビジョニングを自動化する

6. 外部への依存を考慮する

7. チームのローテーションを検討する(慎重に！)

8. 定期的に「オープンハウス」を開催し、チームのプロセス、ツール、プロダクトを紹介する

9. すべてを自動化する

バス係数

サイトを破壊し、チーム全体で知識を共有すれば、チーム全体のコードベースの理解度が向上し、変更や障害への対応が素早くできるようになる。コードの一部しか理解していないチームメンバがボトルネックになっていると、チームにとって迅速なデリバリーの妨げになるという危険なシナリオが発生する。チームメンバが「バスに轢かれて」入院するというものだ。あなたのチームには、プロジェクトに不可欠なメンバーが何人いるだろうか? つまり、そういう人がバスに轢かれたら、仕事は止まってしまうのだろうか?

計算式

HBaB係数(Hit By a Bus Factor)は高ければ高いほどよい。理想的なHBaB係数はチーム全体のサイズであり、仕事の完遂が妨げられる唯一の方法は、チームメンバ全員がいなくなる場合であることを意味する。

$ HBaB = T \times (1 - \frac{A}{5})

改善のために

HBaBの改善には以下の方法がある。

1. 複雑さをへらす

2. アーキテクチャをシンプルにする

3. 言語のフットプリントを減らす

4. モジュール化

5. 専門的だが繰り返し発生するタスクの自動化

6. すべての手順をドキュメント化し、そのドキュメントを常に最新に保つ

7. 横断的な教育を促進する

コードの共同所有

チームは、メンバの全員がチーム全体のコミットメント達成の責任を感じられる程度の規模であるべきだ。チームが責任感を持てば、目標達成のために積極的に協力し合えるようになるだろう。これにより、チーム全体に知識や専門性が分散され、バス係数が改善されると同時に、チケットが多くのチームメンバに渡ってしまうことで発生する問題も減らせる。

計算式

このKPIは、プロジェクトの構造に依存するため、計算するのがより困難だ。まず、チームが担当する業務領域をどのように分類しているかを確認する必要がる。ここでは、これらの業務分野を「コンポーネント」と呼ぶことにする。コンポーネントを特定したら、2つの異なる計算式を作成して、コードの共同所有についての知見を獲得できる。

各コンポーネントについて、そのコンポーネントに取り組んだ人の数を計算します。これは「チケットオープン中の関与者数」と似ている、チケットの解消に積極的な役割を果たした人だけが対象となる。つまり、コントリビューターまたは担当者のみが考慮される。

$ R = \frac{A_1 + C_1 + A_2 + C_2 + ... + A_N + C_N}{N \times T}

また、個々のチームメンバーと、彼らが積極的に参加しているコンポーネントの数をみれば、コードの共同所有がわかる。

$ P = \frac{C + A}{C_t}

改善のために

1. 各コンポーネントのスコアに異常値がないか、さらに分析してみよう。

そのコンポーネントでは、チームメンバの巻き込みが不足していないか？

コンポーネントの中で、チケットは通常、毎回同じ人の手を経ているか？

2. チームメンバーの見直し

チームメンバーが頻繁に参加していないコンポーネントについてトレーニングを行う

知識を広める機会をみつける

3. デリバリに外部依存を必要とするコンポーネントを探す。チーム間の相互依存関係を解消するために、再配置や再設計が可能か？

4. チームサイズを制限する。チームの規模が大きすぎると、特定のコンポーネントの周りに孤立したサブグループが形成される可能性が高くなる。チームが大きくなりすぎた場合は、チームを分割する。

5. 一度にアクティブにするタスクの数を制限する。コンテキストの切り替えは、チーム内の孤立化サブグループに発展する。

コードリファクタリング率

アジャイルチームは変化を受容する。チームが時間をかけてコード品質を向上させていることが、その良い指標になる。それは継続的なリファクタリングとして表れるだろう。コードのリファクタリングを客観的に計測するには、ユニットテストが修正を必要とせず、ユニットテストが継続してパスするようなコードの変更を探せばよい。

これを行うには、いくつかのデータポイントを集約する必要がある。

計算式

$ R = \frac{C_\Delta}{T_\Delta}

改善のために

CloverやIstanbulのようなレポートツールを使って、コードカバレッジがすべてのファイルやメソッドを通っているかだけでなく、コードが通りうるすべての分岐をカバーしていることを確認する。さらに、例外的なシナリオや予期せぬデータ入力がテストされていることも確認しよう。

ユニットテストでは、全体のコードカバレッジを向上させるようにします。全体のコードカバレッジが高ければ、コードカバレッジが限られている場合よりも、1つまたは2つのテストを変更することによるコードリファクタリング比率への影響は小さくなる。

メソッドが内部で行っていることではなく、メソッドの動作や出力をテストするようにしよう。メソッドの内部はブラックボックスであると考えるべきだ。出力のテストにフォーカスすれば、内部は変更可能だが、メソッドはそれを使用するすべてのものに同じインターフェイスを透過的に提供していることを保証することになる。

チケットオープン中の関与者数

1つのチケットが多くの人を行き来しているならば、プロセス、理解、チームの調整、コミュニケーションに問題がある可能性を示している。チケットのルーティングと完了に必要な人数が少なければ少ないほど、チームが仕事に責任を持ち、不必要なコンテキストスイッチを減らせる。

2枚のピザがグループ全員に行き渡らないような会議をしてはならない

ジェフ・ベゾスの有名な造語である「Two Pizza」ルールは、最大のチームサイズが6～8人程度であることを示している。アジャイルの推奨もほぼ同じ(7±2)であり、意思決定には7人、全員が満足感を得るには5人のチームサイズが理想的であるという研究もある。

計算式

チケット担当者の総数は以下の単純な和で表される

$ N = N_r + N_a + N_c + N_d + N_m

チケットにコメントした人もスコアに含まれる。理想的には、チームは外部からの追加のインプットなしに成果を上げることができるべきだ。プロダクトオーナーがいる場合は、ビジネスに関する気づきや関係者へのインタビューをプロセスに反映させるべきです。エンドユーザーの意見は、アンケート、ユーザビリティテスト、アナリティクス、その他の類似した方法で収集し、チームが活用できるデータを得るべきだ。外部からのコメントが悪いというわけではないが、チームの一員ではない人を単にプロセスに参加させるのではなく、実用的な方法で収集し、レポーティングする必要がある。

改善のために

1. バグチケットのトリアージ手順を自動化する方法を探し、より少ない手数で適切な担当者に届けるようにする。

2. チームでバグのトリアージを行う技法を採用して、全員がチケットを認識し、適切な担当者に届けるようにする。

3. 一度に処理されるチケットの数を減らすことで、フローをコントロールする。多くの場合、チームは自身の処理能力に基づいてチケットを過度にやりとりしてしまう。

4. テスト駆動開発を導入し、機能的なコードを導入する前に仕様を明確にする。これにより、不明確な要件やテストの前提条件による行き違いを減らすことができる。

5. ユニットテストを自動化する。

6. QA検証を自動化する。

7. チームサイズを小さくする。

8. 自己完結できるようにチームを編成する。

9. チーム間の相互依存性を減らす。