- 週刊DoX入門｜第1話『仕事は流れているようで、止まっている』
- 週刊DoX入門｜第2話『観察は分析ではない。まず“見る”ことから始まる。』
- 週刊DoX入門 第3話『観測点は、いくつ要る？』
- 週刊DoX入門 第4話『「念のため」が組織を太らせる』
- 週刊DoX入門 第5話『観測が入ると、会議は短くなる（ただし最初は荒れる）』
「流れを観察する」と言うと、ついこう考えがちだ。
- まず全体図（業務フロー）を描こう
- 次に全部の数値（KPI）を集めよう
- 最後に“改善”しよう
……うん、気持ちはわかる。真面目だし、教科書にも載ってそうだ。
でも現場でこれをやると、だいたいこうなる。
図が増える → 指標が増える → 誰も見なくなる。
まるで、監視カメラを増やしすぎて、結局どの映像も見ない警備室みたいに。
ここでDoXの発想はちょっと意地悪だ。
観測点は、増やすな。絞れ。
そして、最初は“全体”じゃなく“違和感”を追え。
観測点＝「流れが乱れる場所」
流れが乱れる場所って、だいたい決まってる。
- 人が待つ（承認待ち、返信待ち、確認待ち）
- 情報が迷子になる（最新版どれ問題、口頭伝達の蒸発）
- 例外処理が増える（イレギュラーが常態化）
- 「念のため」が積み重なる（二重入力、二重確認）
つまり、渋滞が起きる場所だ。
ここで大事なのは、渋滞を“正しく測る”ことじゃない。
渋滞を見つけられる形で、そっと可視化すること。
たとえば、こんな観測点。
- 申請〜承認の「滞留時間」だけを記録する
- 差し戻し理由を「カテゴリ1つ」だけ選ばせる
- “途中で止まった案件”だけが浮かぶ一覧を作る
これだけで、会議が変わる。
「うちの部署は頑張ってます！」じゃなくて、
「ここで流れが詰まってる」が先に出てくるから。
観測の目的は、結論じゃない
観測は、答えを出すためじゃない。
問いを置くためだ。
- なぜここだけ渋滞する？
- それ、本当に必要なチェック？
- その承認、誰の安心のため？
問いが置けると、改善は“押しつけ”じゃなく“納得”になる。
これが、DoXがDXにちょっと喧嘩を売りたくなる理由（売らなくていい）。
最後に、ひとつだけ。
もしあなたが、現場に 観測点を1つだけ 置けるとしたら、どこに置く？
「人が待っている場所」か、
「情報が迷子になる場所」か、
それとも――
「“念のため”が増殖している場所」か。
4話に続く。