結論: 進捗が見えないのは報告不足ではなく、合図を決めていないからです
外注先の進捗を追うために、新しい報告をお願いする必要はありません。作業をしている人は、状態が変わるたびに必ず何かを言っています。私たちがやっているのは、その言葉を「現場の合図」と呼んで拾い、管理表のほうを自動で書き換えることです。
弊社は動画の制作を複数の編集者にお願いしていて、1本が世に出るまでに素材の受け渡し・編集・確認・やり直しと節目がいくつもあります。以前はこの節目が変わるたびに、人が管理表を手で書き換えていました。書き換えが後回しになれば、表と実態はずれる。進捗が見えない原因は、相手の報告ではなく、こちら側の記録が遅れることでした。
なぜ「進捗どうですか」を聞いても進捗は見えないのか？
答えを先に言うと、聞いた瞬間の写真しか手に入らないからです。理由はシンプルで、次に状態が変わった瞬間は、誰も知らせてくれないからです。
聞けばその場の進捗は分かります。ただし翌日にはまた分からなくなり、また聞くことになる。しかも聞かれる側は、手を止めて答えるという仕事が増えます。確認の連絡は、進捗を見えるようにする作業ではなく、進捗を止める作業でした。
私たちが最初に切り替えたのは、聞く回数ではなく見る場所です。編集者とのやり取りが社内のチャットに集約されたタイミングで、そこに流れている言葉から状態を読み取り、管理表を自動で最新にする仕組みを作りました。人に新しい入力をお願いせず、すでに交わされている会話だけを材料にする——これが「現場の合図」で追うという考え方です。
自動で追う仕組みを作ったのに、試運転で1件も動かなかった話
答えを先に言うと、こちらが想定した合図を、現場は1つも使っていませんでした。
仕組みは、いきなり本番では動かさず、しばらく試運転にしました。実際に管理表を書き換えず、書き換えるはずだった件数だけを記録する期間です。結果は0件でした。数時間おきに会話を読みに行っているのに、状態が変わったと判定できた場面が最後まで1つも出てこない。
原因を調べて分かったのは、単純なズレでした。私たちは提出の合図をレビュー専用ツールのリンクだと決めていました。実際にこのチームが使っていたのは、普段のファイル共有のリンクです。完了の合図も想定と違いました。管理用の決まった言葉ではなく、番号を添えた「編集ありがとうございます」という日常の謝辞が、実際には完了の合図として機能していた。
つまり壊れていたのは仕組みではなく、こちらの読み方でした。合図は設計するものではなく、すでにあるものを見つけるものだった。 ここを取り違えると、現場に「今日からこの言葉で報告してください」とお願いすることになり、報告を増やしたくないという最初の目的に戻ってしまいます。私たちは判定の表を実際のやり取りに合わせて書き直し、それから本番に切り替えました。
見落としの原因を人の注意力ではなく仕組みの側に置く考え方は、見落としが起きる場所を先に書き出した記事にも書いたとおり、弊社が一貫して取っている立場です。
「現場の合図」はどこを見れば見つかるのか？
答えを先に言うと、状態が変わる節目を先に書き出し、その節目で実際に交わされている言葉を1つずつ拾います。頭の中で想像した理想の報告文からは、絶対に見つかりません。
私たちが見ているのは4つの節目です。素材が届いたとき、作業を終えて渡すとき、確認が通ったとき、やり直しをお願いするとき。この4つについて、直近のやり取りを読み返し、そこで実際に使われている言い方をそのまま書き出しました。
書き出してみると、合図はきれいな文ではありません。番号だけのときもあれば、雑談に混ざっていることもある。それでも構いません。必要なのは、その言い方が出てきたとき状態が必ず変わっている、と言い切れるかどうかだけです。逆に、状態が変わっていないのに出てくる言い方は合図にしてはいけません。番号のない「ありがとうございます」や「次もお願いします」を弊社が合図から外しているのは、この理由です。
自動で進めてよい合図と、人に知らせる合図をどう分けるか？
答えを先に言うと、間違えたときに戻しにくい変化だけは、黙って進めない設計にしています。
すべての合図を同じ重さで扱うと、いつか事故が起きます。私たちが仕分けの軸にしているのは①合図が明確かどうか②間違えたときに戻しやすいかどうかの2つです。合図が明確で戻しやすいものは自動で進めます。合図が明確でも、そこから先の工程が動き出してしまう変化は、自動で進めたうえで1件ずつ人に知らせる。合図があいまいなものは、そもそも動かしません。
自動で進める前に満たす条件も決めてあります。どの動画の話かが番号で一意に決まること、合図が上記の一覧に一致すること、いまの状態から次に進む流れとして自然なこと、そして同じ変化をまだ適用していないこと。1つでも欠けたら動かさず、人に確認を出します。判定に迷ったら止まる、が仕組み側の初期設定です。
そしてもう1つ、一言で全体を止められるようにしてあります。おかしな動きをしたときに、原因を調べる前にまず止められること。この逃げ道がないと、仕組みを本番に出す判断そのものが重くなります。何を自動にして何を人に残すかの線引きは、人に残す判断を6つに絞った記事でも同じ考え方で整理しています。
明日から試せる一歩
まず、進捗を手で書き写している管理表を1つ選び、状態が変わる節目を4つまで書き出してください。次に、その節目のやり取りを1週間分だけ読み返し、実際に使われている言い方をそのまま書き写す。この2つだけで、自動化に手をつける前に「合図があるのか、まだ存在しないのか」が分かります。
合図が見つからない節目があったなら、そこは自動化する場所ではありません。誰も何も言わないまま状態が変わっている場所なので、まず声に出す運用を作るほうが先です。現場に新しい入力をお願いする前に、すでに出ている言葉を拾い切ったかどうか——私たちが順番を間違えて試運転を空振りさせたのは、まさにここでした。
なお、現場から情報が上がってこないこと自体を設計の問題として引き取る考え方は、現場が数字を入力してくれない問題を扱った記事にも書いています。あわせて読むと、拾う側の設計として全体がつながります。