トップ > 「大掃除」から「定常的なタスク消化」へ、Repro Sys-infra Unitの取り組み

「大掃除」から「定常的なタスク消化」へ、Repro Sys-infra Unitの取り組み

健全性を保つための活動とそれを評価するために行ったことを説明します。 この活動は Repro 全体の話ではなく Development Division/Platform Team/Sys-Infra Unit が行なったものです。

Sys-Infra Unit は Repro のサービス全般のインフラ管理と一部のアプリケーションの運用などを行なっている Unit です。 SRE 的なこともやっています。

課題

Development Division では四半期ごとに成果目標と行動目標を決めて半期の終わりに達成度などを評価するような制度が運用されています。

期初に作成する目標の一部となるような重要度の高い大きめのタスクについては、よく達成されていて評価にも反映されやすいです。しかし、それらと比較してサイズの小さいタスクについてはタスク管理システムに登録はするものの、完了されることはなく溜まっていく一方でした。

ここで言うサイズの小さいタスクとは、細かいライブラリのアップデートやちょっとした便利な機能の追加やドキュメントの改善など多岐にわたります。

時々、誰かのイライラがマックスになったとき、気合や勢いで片付けられるタスクは多少ありましたが、それらについて特に評価制度上どのように評価するかはなかなか難しい問題でした。

Sys-Infra Unit 発足前の取り組み

Sys-Infra Unit が発足する前に行なっていたことの1つに「大掃除」がありました。

これは半年に一度行うタスクの棚卸に合わせて溜まっているタスクをまとめて片付けようという活動です。主に以下のルールで実施していました。

  • 期初の一ヶ月のうち二週間程度を利用して行う
  • 取り組むタスクは個人の判断に任せる
  • オンコールなどの当番でない人が取り組む
  • 参加できる人だけ参加する

この取り組みである程度タスクは片付くのですが、半年に一度しか実施しないためいくつか問題がありました。

  • タスクに書かれた説明が不十分な場合1、タスクで実施する内容を決めるのに時間がかかったり、タスクの内容がわからないから着手されないことがある
  • 「大掃除」の時期に大きめのタスクに取り組んでいるメンバーはそもそも参加できないことがある

2回か3回実施したところで、定常的にこういったタスクを消化できる体制に変えていく必要があるという気付きを得ることができました。 また、この時代はそのようなタスクについてチームの成果目標に組み込んで評価するようになっておらず、個人の行動目標にあてはめて評価するようになっていました。

Sys-Infra Unit 発足後の取り組み

「大掃除」の課題とは関係なく、組織改変があり、現在の Sys-Infra Unit が発足しました。メンバーも多少入れ替わりました。

半日から数日で完了させることができるサイズ感のタスクで何ヶ月も放置するとまずいが即時対応の必要はないタスクに soundness というタグを付けるようにしました2。普段の業務ではアラートの一次対応やその根本対応など、差し込みで即時対応が必要なタスクもあるのでそういったものと区別できるようにしました。なお SRE 本に載っているトイルとは違って繰り返されるかどうかや自動化可能かどうかは問わないことにしました。

定常的に soundness タスクをこなすために、期初に作成する成果目標にも組込むことにしました。具体的には soundness タスク完了までにかかった時間に応じてポイントを加算し、その合計をチームの成果目標の評価で使用することにしました。

例えば、以下のようなルールでポイントをタスクに付与します。

  • 1 point 2, 3 時間
  • 2 points 8 時間
  • 3 points 10 〜 12 時間
  • 5 points 2.5 日
  • 8 points 4 日

ポイントは事前に見積ることもあるし、タスク完了後に設定することもあります。運用が面倒だとやらなくなるので、あまり面倒でないようにしています。 1 point 以下のタスクについては mini_soundness タグを付与して 10 個完了したら 1 point として集計しています。

チーム全体でこなすポイント数だけを期初に設定し、毎週の進捗共有の場でどのくらいこなせているのかを確認します。これによって、「残り xx 日で yy points 消化しないといけない」というのがチーム内で共有できるようになりました。

また、タスクの内容が不十分だったり曖昧だったりするとタスクが開始されない問題については、タスク作成時に以下のようなテンプレートを埋めることにしました。

# なぜやるのか
(何が問題となっており、なぜ対応する必要があるのかを説明する)
# なにをやるのか
(問題に対する課題や対応方法、対応案)
# どうなっていたら達成しているのか、期待している効果
(完了だと判断できる状況。対応したことによって期待される効果、達成したい(達成されるべき)目標)
# その他

これによって、タスクの曖昧さが減少しタスク開始時にタスクの内容を思い出したり考えたりする時間が減りました。

まとめ

期初に soundness タスクの目標を作成するようにしたところ、2回続けて目標を達成できました。この仕組みは、私たちのチームに合っているようです。

  1. タスクにタイトルだけ書かれていて、詳細が書かれていないことや完了条件が不明なことがありました。↩
  2. soundness タグ自体は同様の定義で以前から使用していました。↩

© About Repro Tech Blog