f:id:yamotuki:20220415125932p:plain こんにちは。エンジニアの鈴木（@yamotuki）です。
本日はインフラタスクの優先度の定量化の試みについて書いていきたいと思います。
ここでいうインフラタスクとは以下のようなタスクが含まれます。

可用性と信頼性に関わる障害対応, バグ対応
ベロシティとストレスに関わる業務効率化（DX: Developer eXperience）
セキュリティやライブラリバージョンアップなど

これらのタスクについて「何を一番優先して取り組んでいくべきか」という優先度について長く頭を悩ませていましたが、私の中で一定の答えが出たので共有いたします。

20%税金ルールについて

私はインフラタスクは概ね20%は必ず時間を割かないといけない税金のようなものだと考えています。税金を払わなければ将来にツケを回すことになり、利息が付いて後で降ってきます。 20%のアイディアはThe DevOps ハンドブックで紹介されているものでした。書籍では以下のように書かれています。

組織が”20%税”を支払わなければ、全てのサイクルを技術的負債の返済に充てなければならなくなるようなところまで、技術的な負債が膨らむ。サービスがどんどん不安定になっていくため、ある時点で突然機能を追加できなくなる。全てのエンジニアがシステムの信頼性の改善や問題点の回避のために追われるようになってしまう。

今の状況が特に悪い場合には、20%を30%以上にしなければならないかもしれません。しかし、20%よりはるかに小さい割合でなんとかなると思っているチームを見ると心配になってきますよ。

この話を根拠に、jira の「インフラ」エピック（ラベルようなもの）が付いているタスクが、全てのタスクの消化量の何%程度になっているかざっくり計算し、低くなりすぎる場合にはPdMとエンジニアが交渉するようになっています。

ただ、やりたいことというのは無限に増えていくものです。20%を闇雲にやっていけばいいわけではなく、重要なものから優先順位をつけてやっていく必要があると考えています。

優先度定量化について

定量化の導入検討

以下に定量化の試みの初期検討資料の冒頭を引用します。

これまで、インフラタスクの優先度つけは、特定の人が属人的に優先度を決めていた。
その優先度付けのプロセスはブラックボックスであり、非効率であった。

特定の指標に基づいて優先度を定量化することでバックログの並び順を変えることができれば、属人化を排除して、開発チームの誰もが納得できる優先度になるのではないか。

この記事の最初に書いたように、「インフラ」に含まれるタスクは広範囲に渡ります。種々のタスクを並列に優先度比較できることを目指しました。

タスクの分類とスコア

インフラタスクを発生している現象ベースでまず以下のように分類してみました。

障害が発生しているか
業務に支障が発生しているか
攻撃が容易な状態にあるか
ライブラリが古いか

その分類の中で、例えば「障害」であれば以下のように傾斜をつけることにしました。

（障害）障害が既に起こっている
（障害）障害がいつでも起こりうる
（障害）障害が起こりうる可能性は高くない
（障害）障害が起こりうる可能性は低い
（障害）障害が起こってから対応しても問題ない

業務効率化については以下のような形です。

（効率化）無いと特定のタスクを進められない
（効率化）著しく業務に支障がある
（効率化）蓄積すると業務に支障がある

タスクのインパクト

発生している現象に対して、その現象がどの程度インパクトがあるかを考えれば優先度を決定できるのではないか、と考えました。インパクトについては、まずは”影響範囲が広いか”が重要だと思います。しかし、業務改善に関わるタスクについては開発者のみに関わるためユーザに関わるものと同列に比較することは難しいです。そこで、「開発者への心理的影響が大きいか」という視点も入れることにしました。ストレスが下がるような改善をすれば業務効率が上がり、間接的に良い影響が広範囲に出るであろうという仮説です。

例えば「障害」であれば以下のようにインパクトの傾斜を設定しました。

（障害）ユーザ行動を大きく阻害する
（障害）ユーザ行動を稀に阻害する
（障害）ユーザ行動を阻害しない

業務効率化については以下のような形です。

（効率化）解決されると高ストレスが解消される
（効率化）ややストレスが解消される
（効率化）そこまでストレスはかかっていない

スコアリング方針

上記の”発生している現象”と”インパクト”をそれぞれスコアをつけて、掛け算したら最終スコアが出るのでは、とシンプルに考えました。初期アイディアとしてはセキュリティ領域でよく使われているCVSSスコアを参考にしましたが、正直なところ跡形もありません。

具体的にはスコアリングは以下の掛け算で行われます。

障害対応、バグ対応（可用性、信頼性）
- 障害発生状況 * 影響度
- 例えば、メール障害であれば（障害）障害が既に起こっている * （障害）ユーザ行動を稀に阻害する
業務効率化（業務ベロシティ、ストレス）
- 業務支障度 * ストレス
- 例えば、AIテストツールの導入に関しては （効率化）著しく業務に支障がある * （効率化）解決されると高ストレスが解消される
  - ※最終的には現時点ではコストに合わないとなり、導入は見送りました
セキュリティ
- 攻撃容易性 * 影響度
保守（バージョンアップ系）
- ライブラリの古さ * 影響度

スコアリング計算実務

計算は単純な掛け算なのでスプレッドシートで行うこととしました。変更も容易です。実際に使用しているものから公開できる部分だけを切り出し、公開用スプレッドシートを作成しました。ご興味がある方はご自身の環境にコピーし、実際にタスクについてスコアリングしてみてください。

docs.google.com

スプレットシートの内部の構造について軽く説明します。

青い背景領域: 選択肢の定義とそのスコア定義
黄い背景領域: 対象となるタスクリストと、選択肢を二つ選択してスコア計算する領域
- 順番のイメージを持ってもらうために、外部に公開しても差し支えないだろうと思われるタスクのみ残してあります（出してヤバそうなのがあったらこっそり教えてね！）。
- 選択肢は、同じタスク分類二つの軸を選択する。発生している現象軸が （障害）障害が既に起こっているなら、インパクト軸にも同じ接頭の（障害）を持つ（障害）ユーザ行動を稀に阻害するを選択する
緑の背景領域: スコアリングの結果、タスクをソートした領域

※各タスクのスコアは良い間隔で分布しているわけではなく、素点数値の微調整によりほんの 0.01 点だけ差があるということも多く発生しています。この数値の絶対値に大きな意味はなく、並び順を決めるためだけに使用されています。「人間が都度判断するとしたらこういう並び順になるだろう」という並び順になるために、素点は微調整をしています。会社によって素点はかなり変わってくると思います。

運用について

以下のようなSlackワークフローを用います。エンジニアは選択肢を選んで理由を書いて投稿します。そうするとその内容がチャンネルに自動投稿され、NoCodeツールであるZapierがキャッチしてJira issueを自動生成します。

f:id:yamotuki:20220415125312p:plain — Slackワークフロー

作られた Jira Issue を、作成したエンジニアが上記スプレッドシートを使用してスコアリングします。最後に（残念ながら）手動でJiraのバックログを並び替えてもらいます。

終わりに

元々は特定のエンジニアが頭を悩ませて優先度を決めていたインフラタスクでしたが、同種のタスクは毎回同程度の優先度になることにより判断コストが劇的に下がりました。また、各エンジニアは優先度を最初から考えるわけではなく、分類だけ考えればいいので判断は難しくありません。
バックログの並び替えまで各エンジニアにやってもらうことができるようになったので、エンジニア人数が増えてインフラタスクが増えても運用を続けることができてスケーラブルな仕組みとなりました。