FourKeysを導入したが生産性向上には至らなかった理由

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Copyright © NIFTY Corporation All Rights Reserved.  3  ニフティのSRE体制   DevOpsTeam SREs DevOpsTeam SREs DevOpsTeam SREs SREギルド SRE(推進)チーム・ギルド運営・Embedded SRE ・SRE勉強会 WG ・全社ガイドライン策定・e-learning ・ポストモーテム共有会・SRE実践

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © NIFTY Corporation All Rights Reserved.  検証方法 8  (SRE) FourKeys実装 (SRE→Dev) 事前説明会計測 sprint1 2023 09 2024 01 2024 02 2024 03 計測 sprint2 計測 sprint3 確認会確認会確認会 DORAチームのOSSをベースに実装 ● FourKeysを3スプリント（6week）にわたり計測 ● スプリントごとにFourKeys確認会を実施し、課題や改善案の洗い出しを実施 ● 次スプリントで改善案を実施してFourKeysが改善するか検証

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © NIFTY Corporation All Rights Reserved.  デプロイ頻度の減少要因 12  ● ビジネス的な要因 ○ sprint1はキャンペーン期間で細々としたリリースが多かった ○ sprint3になるにつれて施策が減り、開発案件数が減った ● 人的リソースの不足 ○ sprint3では他プロダクトや開発以外のタスクが多く、開発工数が少なかった 💡 開発面の課題は出てこなかった

Slide 13

Slide 13 text

Copyright © NIFTY Corporation All Rights Reserved.  変更のリードタイムの課題 13  ● “リリース日待ち”の発生 ○ リリース日が決まっている案件が多く、開発を早く終えたとしても見かけ上リードタイムが長く計測される ● 中央値しか見れない ○ 現状のシステムでは日ごとの中央値しか見ることができない ○ デプロイの少ない日だと外れ値が表れてしまう ○ 逆に外れ値が隠れてしまう日もある ■ 課題を見つけるには外れ値を見るべきでは

Slide 14

Slide 14 text

Copyright © NIFTY Corporation All Rights Reserved.  障害率、復元時間が計測されなかった原因 14  計測するための手順が行われなかった ● 計測には障害Issueの作成が必要だった → このチームは障害をNotionで管理していた ● 事前に説明はしていたが作られなかった　→ 障害発生時にFourKeys計測のためにIssueを作成するのはきびしい

Slide 15

Slide 15 text

Copyright © NIFTY Corporation All Rights Reserved.  反省点 15  ● SREチーム主導で進めていた　→ 利用者はFourKeysを求めていた？ ● 利用者の求める機能を提供できなかった　→ スプリントごとの集計、余計な作業なく障害率、復旧時間の計測 ● 計測が目的になっていた　→ 可視化はできたがそのあとが不明瞭　→ 計測をする目的は？最終的にどうなりたい？　→ 仮説を立てて検証は大事だがゴールは明確に

Slide 16

Slide 16 text

Copyright © NIFTY Corporation All Rights Reserved.  16  ● FourKeysはソフトウェアデリバリのパフォーマンスを測る指標 ○ 　「開発生産性」を測るものではない ● 今回導入したチームはDevOpsもCI/CDもできていた ○ 改善に役立てるのは難しかった？ ● 開発生産性を計測したいなら別の指標を見るべき？ ○ 開発生産性とは？ ○ 時間あたりの開発機能数？提供価値？組織として何を上げたい？ ○ なぜ開発生産性を測る？理解不足

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Copyright © NIFTY Corporation All Rights Reserved.  今後 18  ● ゴールを明確にするところから再出発   ○ 自分たちの目指すゴールのために何を計測すべき？   ○ FourKeysでいいのか？他の指標？   ● 利用者の求める機能を提供する   ○ OSSは便利だが離れる選択肢も（自作、SaaS）   ● 熱量をあわせる   ○ 目的、使い方、知識を共有   ○ 利用を強制しない、頼まない、関心の高いチームから試す  

Slide 19

Slide 19 text

Copyright © NIFTY Corporation All Rights Reserved.  他の指標で考えているもの 19  FourKeys ＋ α ● FourKeysだけに囚われず他のメトリクスも取り入れる ○ 27のケイパビリティ ○ SPACE ○ ストーリーポイント ● 複合的な観点から生産性を計測 ● 最終目標はKPIやROIのようなビジネス指標の向上：デリバリーパフォーマンス向上：定性的な指標をプラス

Slide 20

Slide 20 text

Copyright © NIFTY Corporation All Rights Reserved.  27のケイパビリティ 20  技術参考：https://cloud.google.com/architecture/devops?hl=ja クラウドインフラストラクチャコードの保守性継続的デリバリー継続的インテグレーションテストの自動化データベースの変更管理デプロイの自動化ツール選定のサポート疎結合アーキテクチャモニタリングとオブザーバビリティセキュリティのシフトレフトテストデータ管理トランクベース開発バージョン管理プロセスお客様のフィードバックモニタリングによる的確な判断障害の予兆通知変更承認の効率化作業の可視化ビジュアル管理仕掛り制限小さい単位の作業文化創造的な組織文化仕事の満足度学習文化変革的リーダーシップ

Slide 21

Slide 21 text

Slide 22

Slide 22 text