Slide 1
Slide 1 text
Copyright © NIFTY Corporation All Rights Reserved.
FourKeysを導入したが
生産性向上には至らなかった
理由
ニフティ株式会社 島 翔平
#srenext_c
1
SRE NEXT 2024
Slide 2
Slide 2 text
Copyright © NIFTY Corporation All Rights Reserved.
自己紹介
ニフティ株式会社
システム統括部 会員システムG
第一開発 SREチーム
島 翔平
● 2009〜2023年：SIer企業でソフトウェア開発に従事
● 2023年：ニフティ株式会社にSREとしてジョインs
2
@glass_sms
Slide 3
Slide 3 text
Copyright © NIFTY Corporation All Rights Reserved.
● SREチーム：開発チームの生産性を可視化、向上したい
● FourKeysの導入事例をよく見るようになった
● ある開発チームに協力を依頼して導入検証
（将来的には全社展開を想定）bema Towers
サービスA
3
体制と導入背景
SRE(推進)チーム
● 計測システムの実装
● 事前説明会
● 導入支援
DevOpsTeam
● 導入設定
導入依頼
Slide 4
Slide 4 text
Copyright © NIFTY Corporation All Rights Reserved.
FourKeysとは
| ソフトウェアデリバリのパフォーマンスを
| 的確に計測できる尺度
4
「LeanとDevOpsの科学」より
☑ Googleの研究チーム（DORA）が提唱
☑ 組織全体の業績と相関関係があるという研究結果がある
Slide 5
Slide 5 text
Copyright © NIFTY Corporation All Rights Reserved.
FourKeysとは
① デプロイの頻度
② 変更のリードタイム
③ 変更障害率
④ サービス復元時間
5
：本番環境へのリリース頻度
：コミットから本番稼働までの時間
：リリースによる障害発生率
：障害発生から復旧までの時間
４つの指標から構成
→素早く安定してリリースできているか
Slide 6
Slide 6 text
Copyright © NIFTY Corporation All Rights Reserved.
導入過程
6
実装
DORAチームが公開しているOSSをベースに実装
検証
スプリントごとにFourKeys確認会を実施し、
3スプリントにわたりフィードバックループを回した
(SRE)
実装
(SRE→Dev)
事前説明会
計測
(SRE&Dev)
確認会
Slide 7
Slide 7 text
Copyright © NIFTY Corporation All Rights Reserved.
結果
7
Slide 8
Slide 8 text
Copyright © NIFTY Corporation All Rights Reserved.
デプロイの頻度、変更のリードタイム
8
改善傾向見られず
デプロイ頻度は減少傾向
外れ値
ほぼ横ばい
sprint1 sprint2 sprint3 sprint1 sprint2 sprint3
Slide 9
Slide 9 text
Copyright © NIFTY Corporation All Rights Reserved.
変更障害率、サービス復元時間
9
測定されず（障害がなかったわけではない
Slide 10
Slide 10 text
Copyright © NIFTY Corporation All Rights Reserved.
原因①
10
開発以外の要因
● リリース日が決まっているため”リリース待ち”
が発生
● スプリントによって前提条件が違うため単純に
比較できない
→ 開発に入れる人数、開発以外のタスク量
Slide 11
Slide 11 text
Copyright © NIFTY Corporation All Rights Reserved.
原因②
11
障害率、復旧時間を
計測するための手順が行われなかった
● 計測には障害Issueの作成が必要だった
→このチームは障害をNotionで管理していた
● 事前に説明はしていたが作られなかった
→障害発生時にFourKeys計測のためにIssueを作成するのはきびしい
Slide 12
Slide 12 text
Copyright © NIFTY Corporation All Rights Reserved.
しくじりポイント
12
● SREチーム主導で進めていた
→ 利用者はFourKeysを求めていた？
● 利用者の求める機能を提供できなかった
→ スプリントごとの集計、余計な作業なく障害率、復旧時間の計測
● 計測が目的になっていた
→ 可視化はできたがそのあとが不明瞭
→ 計測をする目的は？最終的にどうなりたい？
→ 仮説を立てて検証は大事だがゴールは明確に
Slide 13
Slide 13 text
Copyright © NIFTY Corporation All Rights Reserved.
13
● FourKeysはソフトウェアデリバリのパフォーマンスを測る指標
「開発生産性」を測るものではない
● 今回導入したチームはDevOpsもCI/CDもできていた
→改善に役立てるのは難しかった？
● 開発生産性を計測したいなら別の指標を見るべき？
● 開発生産性とは？
○ 時間あたりの開発機能数？提供価値？組織として何を上げたい？
● なぜ開発生産性を測る？
理解不足
Slide 14
Slide 14 text
Copyright © NIFTY Corporation All Rights Reserved.
今後
14
ゴールを明確にするところから再出発
● 自分たちの目指すゴールのために何を計測すべき？
● FourKeysでいいのか？他の指標？
熱量をあわせる
● 目的、使い方、知識を共有
● 利用を強制しない、関心の高いチームから試す
Slide 15
Slide 15 text
Copyright © NIFTY Corporation All Rights Reserved.
収穫もあった
15
利用者の生産性への意識が高まった
● 75%が「生産性への意識が高まった」「もう少し計測を続けたい」と回答
「計測する」という大きな一歩は踏み出せた
● データの蓄積というベース部分をつくれた
● 集計、活用方法次第で利用価値はありそう
Slide 16
Slide 16 text
Copyright © NIFTY Corporation All Rights Reserved.
NIFTY Tech Talk #21開催
16
本日伝えきれなかった話をお話します！
@glass_sms
Xでも告知します
SRE関係イベント登壇者の
After Talk
8月27日（火）19:00〜20:30
ニフティ 新宿本社 & YouTube Live
ハイブリッド開催
詳細はconnpassにて
https://nifty.connpass.com/event/326741/