システムは稼働しているのに業務が止まる：サービス品質の測り方

障害報告はゼロ、稼働率の目標も達成。それでも利用部門から「締め処理に間に合わない」と苦情が来る。運用側はサーバーが動いていた証拠を示し、利用側は画面の前で待った時間を訴える。双方の記録が正しくても、議論はかみ合わない。測っているものが違うからだ。

ここで稼働率の目標だけを厳しくすると、止まっていない機器へ投資を増やし、仕事が終わらない原因を残すかもしれない。反対に、利用者が困っているという理由で契約上の約束を曖昧にしてよいわけでもない。

本稿の提案は、合意したサービス水準の確認を続けながら、重要な仕事の開始から完了までを測り、失敗している場所へ改善費用を向けることだ。稼働率を上げるか、画面や手順を直すか、外部との受け渡しを変えるか。その選択をできる記録にしたい。

「動いている」と「使い終えられる」は違う

SLAは提供者と利用者のサービス水準に関する合意であり、何を対象にどう算定するかは個々の合意による。稼働率はその一項目にすぎない。画面が応答していることを測る契約なら、その達成だけで、申請が正しく提出できたことや期限までに承認されたことまでは分からない。

GoogleのSRE Workbookは、重要な利用行程からサービス目標を考え、測定を利用者に近付ける方法を説明している。サーバーへ届いた要求の記録だけでは、そこまで到達しない失敗を拾えないという問題も挙げる。2018年の実務知見であり、特定の目標値が顧客満足を何％上げるという比較実験ではない。Google SRE「Implementing SLOs」

例えば申請画面が開いていても、添付ファイルを送れなければ申請は終わらない。送信が成功しても、確認番号が表示されず、利用者が何度も送れば重複処理が発生する。機器側の成功、利用者が認識する完了、業務としての完了を分けると、誰が何を直すかが見えてくる。

すべてを一つの指標に詰める必要はない。機器側の記録は原因を探す材料として残す。その上に、利用者が必要な作業を終えたかを置く。両方を見ることで、技術障害なのか、操作の難しさなのか、後続の業務待ちなのかを切り分けられる。

完了率の分母から、困った人が消えていないか

英国政府のサービスマニュアルは、利用を開始した取引のうち完了した取引の割合を測る方法を示す。途中離脱や失敗を分母に含め、保存後に再開する利用も開始と完了を対応させる。行政の測定指針で、日本企業の利用者行動を実測した統計ではない。GOV.UK「Measuring completion rate」

ここで重要なのは、率の計算より、何を開始と数えるかである。ログインに成功した人だけを分母にすると、認証できずに諦めた人は消える。最後の送信ボタンを押した人だけを数えれば、入力途中で止まった人も見えなくなる。

一方、トップページを眺めた全員が手続きを始めたわけでもない。対象者ではないと分かって離れた人と、対象者なのに先へ進めなかった人を同じ失敗にしない。業務の入口を決め、その入口より前で起きる問題は別の確認先として残す。

数字を比較するときには、開始した集団をそろえる。月末に始めた申請が翌月に終わるなら、今月の開始件数と今月の完了件数を割るだけでは、その人たちの完了率にならない。受付時点のまとまりごとに追うか、完了までの期間を別に示す方が判断しやすい。

率の改善と、利用者の改善が逆転する例

以下は計算を確かめるための仮想例である。千件の申請開始に対して九百件が完了した。完了率は90％になる。入力項目を減らした後、同じ定義の千件に対し九百五十件が完了すれば、95％になった理由を調べる価値がある。

ところが改善後は、本人確認を通過した九百五十件だけを開始として数え、九百件が完了したのだとしたら、見かけの率は約94.7％へ上がる。完了件数は増えていない。これを画面改修の成果とすることはできない。

さらに、九百五十件が送信できても、そのうち一部を職員が後から補正しているかもしれない。送信成功率を上げるため入力確認を外したなら、仕事が窓口の内側へ移った可能性がある。完了率と、差し戻し・重複・後処理の件数を対応させたい。

この例は指標を疑って何も決めないためのものではない。同じ入口の人が、手直しを増やさず完了できたなら、改善を広げる根拠になる。入口や完了の定義が変わったなら、効果判定を保留して比較し直す。同じ定義でも、利用者の構成や繁忙度が変われば、改善分のすべてを改修の効果とは言えない。その違いを決めるための例である。

入口が変わった例からは、開始できた率、開始後の完了率、全対象の完了率を分けて追う必要が分かります。始められなかった人を除けば、途中の率だけがよく見える場合があります。同じ利用者の行程へ戻し、支援が必要だった完了も含めて、次の投資先を考えます。 支援付きの完了

苦情の多い機能からではなく、失敗した仕事から選ぶ

改善会議には、次の三つを並べるとよい。本稿の判断案であり、研究で検証済みの診断表ではない。

締め処理の遅れが承認待ちなら、サーバーを速くしても承認者の判断は早まらない。一方、承認後のデータ転送が毎回失敗しているなら、担当者へ急ぐよう依頼するより転送の復旧が先になる。最初の苦情が同じ「遅い」でも、選ぶ案は逆転する。

利用者の言葉だけで原因を確定しないことも必要だ。「システムが遅い」という訴えに、観測した時刻、止まった工程、再操作の有無を結び付ける。問い合わせできた人だけでなく、利用を諦めた人の痕跡も、取得できる範囲で確かめる。

完了と、希望が通ったことも区別する。英国の指針では、申請を提出できたことは、申請が認められたこととは別に扱われる。審査のあるサービスで採択率をそのまま使いやすさの指標にすれば、不適切な承認まで成功に数える恐れがある。正しい理由で拒否された処理と、技術的に先へ進めなかった処理を混ぜない。

問い合わせが減った場合も、自己解決が増えたのか、問い合わせ先へ到達できなくなったのかを確かめる。満足度のアンケートは補助材料になるが、回答しなかった人まで満足したとは言えない。数値が改善した理由を説明できる記録と合わせて読む。

測定を追加する費用も無視しない。全操作の詳細を集める前に、改善判断へ必要な開始・失敗・完了の記録へ絞る。利用者をまたいで情報を結び付ける際は、不要な個人情報を収集せず、集計で分かることと個別調査が必要なことを分ける。測れない範囲は空白として残し、完了扱いに変えない。

全利用者の平均で、重要な少数を埋めない

大量の閲覧が成功していても、少数の支払いだけが失敗しているなら、全要求の成功率は良く見える。業務に不可欠な操作を別に見る理由は、その失敗が後で取り戻せるとは限らないからだ。

ただし、細かく分け続ければ管理できない表になる。まず期限、金銭、次の工程への影響が大きい利用行程を選ぶ。少数の取引では率が大きく動くため、分子と分母の実数、失敗した作業の内容も示す。根拠なく小数点を増やして精度を演出しない。

改善後の判断も「目標を達成した」で終えない。完了までの時間、支援を必要とした割合、後から修正した作業を追う。重要な仕事が止まる場所が変わったなら、次の投資先も変える。

機器の稼働率が十分なのに仕事が終わらないなら、目標を厳しくする前に、終わらない工程を特定する。技術の失敗には技術の改善を、入力や受渡しの失敗にはその工程の改善を選ぶ。 サービス報告を緑にすることと、利用者の仕事を終わらせることを、この順序で結び直したい。