ストック・フロー図の例：問い合わせの未処理件数が増える理由

サポートチームが今週解決した問い合わせの件数を増やしても、週末の未処理件数が前週より多くなることはあります。スループットは一定期間に処理を終えた仕事の量、バックログはある時点で残っている仕事の量です。新たに入ってくる仕事を考慮せずに両者を比較すると、チームの実績が矛盾しているように見えます。

ストック・フロー図を使うと、その増減を目で追えます。チームで使うオンラインホワイトボードに、未処理の問い合わせをストック、そこに入る動きと出る動きをフローとして描きましょう。図の横に簡単な計算例を置けば、なぜ件数が変わるのかを全員で確認できます。

ストックとフローを区別する

ストックは、ある時点で蓄積している量です。フローは、時間の経過に伴ってその量を変化させます。この例では、未解決の問い合わせがストック、新規受付、再オープン、解決がフローに当たります。

MITの研究者Linda Booth SweeneyとJohn Stermanは、ストックとフローに関する研究で、浴槽を使って蓄積の関係を説明しています。浴槽の水量は、入る水と出る水によって変わります。仕事の待ち行列にも同じ計算の原則が当てはまります。ただし、仕事が入る理由や出ていく理由は、より複雑な場合があります。

単位も明記しましょう。ある日の始業時点で未処理の問い合わせが12件あり、新規受付の流入率は1日当たり20件、ということがあります。「12件」と「20件／日」は異なる量であり、どちらも待ち行列の大きさとして比較することはできません。

何をこのチームの未処理件数に含めるか決める

この例のストックには、1つのサポートチームが扱う未解決の問い合わせをすべて含めます。顧客からの返信待ちの問い合わせも対象です。新規に受け付けたとき、または一度解決した問い合わせが再オープンしたときに入り、解決したときに出ます。

同じチーム内で担当者を変更しても、その問い合わせはチームのバックログから出ません。「対応中」から「顧客の返信待ち」に変わった場合も、どちらも今回の集計範囲内なので残ります。対応中の仕事だけを調べたい場合は、別のストックを定義し、返信待ちとの間の移動を明示します。

レポートと図では同じ集計範囲を使いましょう。範囲が違うと、ある人は未解決の問い合わせをすべて数え、別の人は担当者が割り当てられたものだけを数えるかもしれません。どちらの数値も、それぞれ別の問いに対しては正しい可能性があります。

未処理件数と出入りを描く

中央に長方形を置き、未解決の問い合わせと記入します。入ってくるフローを示す矢印を2本描き、それぞれ新規受付、再オープンとします。出ていく矢印には解決と記入します。再オープンが新規の需要に埋もれないよう、2つの流入は分けておきます。

一般的なストック・フロー図の記法では、フローはバルブ付きの管、モデルの範囲外にある流入元や流出先は雲の形で表します。チームで初めて話し合うときは、意味が明確になるラベルを付けた矢印でも十分です。ただし、問い合わせの移動と、人員配置などの影響関係を、同じラベルのない線で表すのは避けます。

この図が答えるのは、量がどのように変わるかという問いです。緊急の問い合わせをどの担当者に割り当てるべきかは示しません。それは別の業務プロセスの問いなので、エスカレーションのフローで扱うほうが適しています。また、因果ループ図は、変数同士がフィードバックを通じてどう影響し合うかという、さらに別の問いを扱います。

3日間の問い合わせ件数を計算する

以下は計算を説明するための数値例であり、顧客の実績や基準値ではありません。各行は丸1日を表します。新規受付、再オープン、解決の値は、その日に起きた状態の変化の件数であり、ある瞬間の流入率や流出率ではありません。

終業時の未処理件数 ＝ 始業時の未処理件数 ＋ 新規受付 ＋ 再オープン − 解決。

1日目は12 ＋ 20 ＋ 2 − 18 ＝ 16です。2日目は最初の12件ではなく、この16件から始まります。流出が流入の合計を上回るため、終業時には13件になります。3日目は減る件数より増える件数が多く、未処理件数は16件に戻ります。

3日間でチームは57件を解決し、新規に56件を受け付けています。この2つの合計だけを見ると、未処理件数は減るように思えます。しかし、再オープンによる流入も5件あります。計算は12 ＋ 56 ＋ 5 − 57 ＝ 16となり、バックログは4件増えます。

再オープンした問い合わせは、新しく作られた問い合わせではありません。ただし、未解決のストックには新たに入ります。その状態変化を適切な流入に数え、「新規受付」と「再オープン」の両方に重複計上しないようにします。同じ問い合わせが1日のうちに解決して再オープンした場合は、両方の状態変化を計算に含めます。

図を使って業務上の問いを具体化する

計算は件数の変化を説明しますが、各フローがなぜその値になったかまでは説明しません。理由は別途調べる必要があります。再オープンの増加は、回答が不十分だったこと、問い合わせを完了扱いにする方針の変更、顧客からの追加情報などによる可能性があります。数値だけでは原因を特定できません。

同様に、平均の流入と平均の解決件数を一致させても、その比較の前提の下で長期的な増加を防げるにとどまり、すでにあるバックログはなくなりません。蓄積した仕事を減らすには、対象期間の流出がすべての流入を上回る必要があります。それをどう実現するかには、日ごとの変動、問い合わせの複雑さ、対応の優先順位が関係します。

だからといって、各担当者が単純に多くの問い合わせを完了扱いにすればよいとは限りません。早すぎる完了処理は再オープンを増やし、見かけ上のスループットが改善しても、実際の仕事は未解決のままになることがあります。この図は、その可能性を示せますが、実測した結果を示すものではありません。

Boardmixでストック・フロー図の例を作る

Boardmixのキャンバスに、中央の長方形とラベル付きの3つのフローを作成します。ストックには「件」、流入率や流出率を示す場合は時間の単位も添えます。図の横に3日間の表を置き、各行の終業時の値が次の行の始業時の値につながるように示します。

集計範囲のメモとして、「このチームの未解決の問い合わせすべて。顧客の返信待ちを含む」と記入します。計算の前提も近くに置きましょう。この例では、削除、重複問い合わせの統合、他チームへの移管はないものとしています。実際のデータにそれらがある場合は、開始時の件数を書き換えて無理に合わせず、対応する流入や流出を追加します。

Boardmixは、このモデルを描いて話し合うためのスペースです。ここに示した計算は手作業であり、自動シミュレーションではありません。変化する流入率や流出率、遅延、フィードバックを含む定量モデルを扱うには、適切なデータと計算方法、またはシミュレーション手法も必要です。

Boardmixのボードを開き、レポートを管理する人と一緒にチームの待ち行列を描いてみましょう。まず、どの状態変化が集計範囲への出入りに当たるかを確認します。その定義によって、式に含める数値が決まります。