Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

イベント
SRE関係イベント登壇者のAfter Talk
https://nifty.connpass.com/event/326741/

登壇者
ニフティ株式会社
島 翔平

ニフティ株式会社

September 03, 2024
Tweet

Video


Resources

SRE関係イベント登壇者のAfter Talk / NIFTY Tech Talk #21 - connpass

https://nifty.connpass.com/event/326741/

More Decks by ニフティ株式会社

Other Decks in Technology

Transcript

  1. Copyright © NIFTY Corporation All Rights Reserved.
 FourKeysを導入したが 生産性向上には至らなかった 理由

    ニフティ株式会社 島 翔平 1
 NIFTY Tech Talk #21 SRE関係イベント登壇者のAfter Talk
  2. Copyright © NIFTY Corporation All Rights Reserved.
 自己紹介 ニフティ株式会社 システム統括部

    会員システムG 第一開発 SREチーム 島 翔平 • 2009〜2023年:SIer企業でソフトウェア開発に従事 • 2023年:ニフティ株式会社にSREとしてジョインs 2
 @glass_sms
  3. Copyright © NIFTY Corporation All Rights Reserved.
 3
 ニフティのSRE体制 


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

    開発チームの生産性を可視化、向上したい • FourKeysの導入事例をよく見かけるようになった ◦ FourKeysを試験的に導入検証 4
 FourKeys導入に至った背景
  5. Copyright © NIFTY Corporation All Rights Reserved.
 FourKeysとは | ソフトウェアデリバリのパフォーマンスを

    | 的確に計測できる尺度 5
 「LeanとDevOpsの科学」より ☑ Googleの研究チーム(DORA)が提唱 ☑ 組織全体の業績と相関関係があるという研究結果がある
  6. Copyright © NIFTY Corporation All Rights Reserved.
 FourKeysとは ① デプロイの頻度

    ② 変更のリードタイム ③ 変更障害率 ④ サービス復元時間 6
 :本番環境へのリリース頻度 :コミットから本番稼働までの時間 :リリースによる障害発生率 :障害発生から復旧までの時間 4つの指標から構成 →素早く安定してリリースできているか
  7. Copyright © NIFTY Corporation All Rights Reserved.
 • ある開発チームに協力を依頼し、FourKeysを計測 •

    最終的には全社展開を想定 サービスA 7
 導入過程 SRE(推進)チーム • 計測システムの実装 • 事前説明会 • 導入支援 DevOpsTeam • 導入設定 導入依頼
  8. 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が改善するか検証
  9. Copyright © NIFTY Corporation All Rights Reserved.
 デプロイの頻度、変更のリードタイム 10
 改善傾向見られず

    デプロイ頻度は減少傾向 外れ値 ほぼ横ばい sprint1 sprint2 sprint3 sprint1 sprint2 sprint3
  10. Copyright © NIFTY Corporation All Rights Reserved.
 デプロイ頻度の減少要因 12
 •

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

    “リリース日待ち”の発生 ◦ リリース日が決まっている案件が多く、開発を早く終えたとしても 見かけ上リードタイムが長く計測される • 中央値しか見れない ◦ 現状のシステムでは日ごとの中央値しか見ることができない ◦ デプロイの少ない日だと外れ値が表れてしまう ◦ 逆に外れ値が隠れてしまう日もある ▪ 課題を見つけるには外れ値を見るべきでは
  12. Copyright © NIFTY Corporation All Rights Reserved.
 障害率、復元時間が計測されなかった原因 14
 計測するための手順が行われなかった

    • 計測には障害Issueの作成が必要だった → このチームは障害をNotionで管理していた • 事前に説明はしていたが作られなかった  → 障害発生時にFourKeys計測のためにIssueを作成するのはきびしい
  13. Copyright © NIFTY Corporation All Rights Reserved.
 反省点 15
 •

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

    ◦  「開発生産性」を測るものではない • 今回導入したチームはDevOpsもCI/CDもできていた ◦ 改善に役立てるのは難しかった? • 開発生産性を計測したいなら別の指標を見るべき? ◦ 開発生産性とは? ◦ 時間あたりの開発機能数?提供価値?組織として何を上げたい? ◦ なぜ開発生産性を測る? 理解不足
  15. Copyright © NIFTY Corporation All Rights Reserved.
 収穫もあった 17
 •

    利用者の生産性への意識が高まった ◦ 75%が「生産性への意識が高まった」「もう少し計測を続けたい」と回答 • 「計測する」という大きな一歩は踏み出せた ◦ データの蓄積というベース部分をつくれた ◦ 集計、活用方法次第で利用価値はありそう
  16. Copyright © NIFTY Corporation All Rights Reserved.
 今後 18
 •

    ゴールを明確にするところから再出発 
 ◦ 自分たちの目指すゴールのために何を計測すべき? 
 ◦ FourKeysでいいのか?他の指標? 
 • 利用者の求める機能を提供する 
 ◦ OSSは便利だが離れる選択肢も(自作、SaaS) 
 • 熱量をあわせる 
 ◦ 目的、使い方、知識を共有 
 ◦ 利用を強制しない、頼まない、関心の高いチームから試す 

  17. Copyright © NIFTY Corporation All Rights Reserved.
 他の指標で考えているもの 19
 FourKeys

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

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

    FourKeysを計測して、ビジネス的な要因がデリバリパフォーマン スに影響していることが分かった 
 • FourKeysだけでは開発生産性を測るには不十分だと感じた 
 • 自分たちの目指すゴールと課題を明確にして、何を計測すべきか 決める必要がある