背景

こういう現場にいるこういう人間が書いています、という前置きです。

現場

こんな感じ。この記事を読んでくれた方の中にも、似たような案件を持っている方もいらっしゃるかと思います。

とある業務パッケージシステムの「定型運用」を実施
作業を行う環境はすべてAWS上のリソース、OSログインを伴う作業も行う
障害対応は別働隊の管轄
担当プリセールス（もしくはTAM）、あるいはエンドユーザーからの依頼ベースで作業を実施する
運用チーム内の役割は以下
- オペレーター
- ディスパッチャー（依頼作業をオペレーターに割り振ったり、トラブル事象をエスカレーションしたり）

日々のタスク管理にはRedmineを使用していました。今回紹介する定量化に不可欠な要素ですので、どういった数字が取れていたか紹介します。

依頼作業1件 ≒ 1チケット
- 事前準備作業やパラメータシートの作成など、サブタスクはある程度の粒度で子チケットに分割
オペレーターの工数記録
- 記録は子チケットの単位で行っている
- Redmine上で工数記録できていない業務もある
カスタムフィールド（一部）
- 作業種別
- 予定工数（見積もり工数の意味で利用、作業種別ごとに固定値）

筆者

AWS ... ちょっとわかる
記述統計 ... 平均・中央値・分散、などの基本統計量は理解している
役割は当初オペレーター、その後は現場管理的なことをしていた
予算や人員を動かす権限は持たない

当初の問題意識とアプローチ

オペレーターの負荷が高いことでした。チーム全体の稼働時間があまり許容したくない水準に到達しており、負荷的にも採算的にも問題視していました。

作業種別によっては、1タスクにかかる工数が大きいものや、トラブルの発生しやすい傾向が高いものがありました。そこでまず、現場の感覚ベースで「トラブルが起きやすく工数がかさみやすい」作業に当たりをつけ、これに関する負荷を減らしていくために動きました。

やったことは、現場の数字をしかるべき人に示し、事態を動かすように働きかける、という流れです。

問題意識を考察できる軸でいくつか集計を行う
負担がかかっている現状を示す結果が出る
数字の解釈、集計条件、結果の解釈、集計上の仮定、提示する改善案に至る筋道、これらに明らかな矛盾がないか確認する
定例会議等で発表し、議論する（リソースの裁量権を持つ人が出席している場だと好ましい）

数字の集計と考察だけでも良いのですが、私としては「改善のための次アクション」に関するドラフト、ないしは大まかな方向性を添えることを強く推奨したいです。議論の方向性をリードする立場の方が色々と事態を動かしやすいので、次アクションに繋がる議論はこちらで用意したレールの上から始めるのが上策だと考えます。

アウトプットしたもの

実施した集計はいくつかありますが、主要なものは次のような切り口です。

Redmine上の作業工数のボリューム
- 月間での推移
- 作業カテゴリ別で集計した予定工数/実績工数
- 負荷がかかりがちな特定の作業に関して、トラブル発生の割合とその推定原因の内訳（トラブル原因は集計時にチケットのメモ欄を見つつ人力でカテゴリ分けした）
勤怠管理上の実労働時間（Redmineに乗らない工数も存在するため）

アウトプットしたのは次のような内容です。

[1] 他のチーム（主に開発）に向けて

特定の作業についてトラブル率が高く予定より工数を取られがちであること、トラブルの原因はツール関係の不具合が多いことが判明した
- 不必要な負荷が増えており、加えて作業品質の低下を招いている現状を説明
- ツール改修やデプロイの安定化など、優先的に改善アクションの実施が必要であると説明

[2] マネジメント層に向けて

作業の実工数と勤怠上の労働時間を突合し、月次の推移を見た。作業ボリュームは増加傾向であり、労働時間としても許容水準を超えている現状が明らかになった
- 現状アサインしているリソースに不足があり、今後も不足傾向が加速する見通しを説明
- 不足する工数の見積を概算し、工数をどの程度追加アサインする必要があるか説明

幸い、これらの主張は概ね受け入れられ、改善アクションが取られました。

注意したこと

故意かどうかに関わらず、数字で嘘をつかないよう注意を払うこと、これに尽きると思います。

「（自分を含む）運用現場の負荷を減らしたい」というゴールありきで始めた集計ではありましたが、目先の利益を求めるあまり虚偽のレポートを申告するようでは逆効果です。たとえ故意によるものではなかったとしても、ミスリードした結論が顧客・自社双方に損失をもたらすこともありえます。数字の妥当性や解釈にはかなり気を遣いました。

取得しづらいデータに対する考え方

理想的にはすべての業務工数が望ましい粒度で計測できているとよいのですが、現実的にはなかなかそう都合よくはいきません。

このへんは得たい情報の重要性と実務上の負担のトレードオフだと思います。新しい数字を管理するために実務上の煩雑さが大幅に増えるようでは本末転倒ですので、ほどほどに。

適当な仮定を置くことで穴埋めできることもありますし、問題意識のコアに関係ない数字ならば「計測できない」として割り切ってしまっても良い。必要なら概算ベースの見積もりで補完すればいい。

概算ベースの見積もり ってなんぞやと思われるかもしれませんが、これは単価×数量の要領で参考値が出せればそれでOKだと考えます。運用の作業工程であるならば、単価はオペレーターの作業工数でありヒアリングベースで確認、数量は日当たりの平均的な件数をRedmineなどから抜いてこればOKです。もちろん見積根拠は提示します。

まとめ

私のケースはかなりうまく話が転がったほうだと思いますが、これは現場に恵まれた側面も大きいと思っています。まず、この案件に関する私の上長のスタンス（当時）として、短期的な損失よりも今はテコ入れをして将来の収益改善を、という意向がありました。リソース増強に関しては受け入れられやすい下地がありました。また、開発チーム側にもOpsに協力的な方がおられたことも幸いしたと思います。

このような良い条件の下なし得た結果ですので、すべての現場で同様のやり方がうまくいくとは保証できません。しかしながら、ここで紹介したような定量的な議論がなければ運用側の主張が伝わることもなかっただろう...とも思います。アプローチは読者の現場にもいくらか応用できる余地があろうかと思います。

さて、今回のネタをまとめると、拠り所とする前提を固めたうえで定量的なデータを活用した議論をしよう、というお話でした。いかがだったでしょうか？「数字って役に立つやん」って思っていただければ幸いです。