はじめに
こんにちは、SREグループの山下(@task2021)です。
私たちSREグループには、「本来取り組むべき活動に十分な時間を割けていないのではないか」という課題感がありました。ここでいう「本来取り組むべき活動」とは、ユーザー体験の維持、開発者体験の向上、コストの最適化を指します。
SREのプラクティスでは「トイルを減らし、エンジニアリングに投資する比率を高める」ことが重視されます。私たちも同じ問題意識を抱き、その実態を把握することから始めました。
その可視化の結果が、次のグラフです。
方法としては、作業をいくつかのカテゴリに整理し、スプリントごとに分布を追えるようにしました（可視化の実装にはJiraダッシュボードを利用）。
（ダッシュボードの技術的な実装については、認証チームの今廣さんが別の記事で詳しく解説しています！ちなみに僕は元「認証チーム」にいたので、輸入した形になります。）
2か月運用して見えてきたのは次の傾向です。
- 改善活動: 上述した本来やりたい活動は全体の約1/3
- 計画保守: スプリントごとに波がある
- 突発保守: 緊急対応の発生頻度
- 作業依頼: 毎スプリント一定量発生
- アウトプット: ブログや登壇などの外部発信
- EMタスク: Engineering Manager業務
本記事では、この可視化の仕組みをどのように構築し、運用から何を学んだかをお伝えします。
なぜタスク可視化が必要だったのか
課題1: 現状を感覚ではなく数値で語れない
- 計画的な改善活動に時間を使えているのか？
- 突発的な対応にどれくらい時間を取られているのか？
- 開発チームからの作業依頼はどの程度あるのか？
「改善活動に十分な時間を割けていない」という漠然とした感覚はありましたが、それを裏付けるデータがありませんでした。
課題2: 施策の効果を測定できない
- 権限委譲で作業依頼は減ったのか？
- 自動化で定期保守の工数は下がったのか？
仮に何か施策を打ったとしても、それがSREグループの仕事にどのような影響を与えたかを定量的に測る手段がありませんでした。
分類ルールをチームで作り上げる
スタートは3分類
考えすぎず、まずは以下の３つでシンプルに始めました。ここで分類に悩むよりも、運用からのフィードバックを経て改善していく方が早いだろう！というスタンスです。
| タイプ | 説明 | 具体例 |
|---|---|---|
| 改善活動 | SREグループが本当にやりたい活動 | Kafka移行、Graviton化、CI/CD改善 |
| 定期保守 | サービス品質維持に不可欠な定常業務 | EKS/PHPアップグレード、パッチ適用 |
| 外部要因対応 | 計画外・突発的な対応 | インシデント対応、作業依頼 |
分類に迷うケースを蓄積する
運用を始めてすぐに、予想通り分類に迷うケースが出てきました。
- 「対応漏れの修正」はどこに分類？ → 改善活動？外部要因対応？
- 「社外イベントの準備」は？ → どのカテゴリにも当てはまらない
- 「採用面接」などEMタスクは？ → SRE活動とは別枠で管理すべき？
これらの迷ったケースは、振り返りでみんなで相談した結果、Confluenceに専用ページを作って、チームメンバー誰でも「このチケット、分類に迷いました」と書き込めるようにしよう、ということになりました。
最終形：6分類
迷ったケースが蓄積されたタイミングで、振り返りの場でみんなで議論しました。 この過程を経て、最終的に以下の6つの分類に整理されました。
| タイプ | 説明 | 具体例 |
|---|---|---|
| 改善活動 | 信頼性向上・コスト削減・開発者体験改善 | 「はじめに」で挙げた活動 |
| 計画保守 | 計画的な保守作業 | 定期アップグレード、パッチ |
| 突発保守 | 計画外の緊急対応 | インシデント対応、脆弱性対応、顧客起因調査 |
| 作業依頼 | 開発チームからの依頼 | 調査依頼、DBユーザー追加、調査 |
| アウトプット | 外部発信活動 | ブログ、登壇 |
| EMタスク | Engineering Manager業務 | 採用、予算管理 |
この分類体系により、曖昧だった「外部要因対応」が明確に分かれ、より具体的な分析ができるようになりました。
2か月の運用で見えたこと（暫定）
データとしてはまだまだ少ないため、本格的な分析は今期の最後に実施する予定ですが、現時点で見えてきたことをご紹介します。
傾向1: 改善活動は全体の25-33%程度か？
現時点での数値を見ると、改善活動に割ける時間が全体の1/4から1/3程度に留まっているように見えます。これが多いのか少ないのかはまだ判断できませんが、この数値は今後の議論の出発点として興味深いデータです。
傾向2: 作業依頼の一定量発生
作業依頼が毎スプリントほぼ同じ量発生している傾向が見られます。もしこの傾向が続くとすれば：
- 開発チームが自己完結できない作業が構造的に存在する可能性
- 権限委譲や自動化の余地がまだ残っている可能性
- 作業依頼の内容を分析することで、次の改善ポイントが見つかる可能性
といったことが推測されます。
まとめ
Jiraチケットの分類とダッシュボード化により、これまで感覚的だった「忙しさ」の中身が少しずつ見えるようになってきました。改善活動が全体の1/3程度という数値が見えてきたことで、今後「どうすればもっと改善活動に時間を割けるか」という建設的な議論の土台ができそうです。
現時点ではまだ「データ収集フェーズ」と位置づけています。2ヶ月のデータでは十分とは言えませんが、完璧な仕組みを作ることではなく、小さく始めて継続的に改善していくことが重要だと感じています。
