依頼を「言いっぱなし」にしないチームの作り方

「あれ、お願いしてたやつどうなりました？」

この一言が週に何度も飛び交うチームは、たいてい真面目です。サボっている人はいない。それでも落ちる。

落ちるのは、工程が落ちるようにできているからです。

各ステップに、小さな確率がある

よくある依頼の流れを、確率つきで書いてみます。

ステップ	落ちる確率
A が Slack で依頼する	B が読まない 5%
B がタスク管理ツールに転記する	入れ忘れ 5%、期限の設定漏れ 15%
B が自分のタスクを見る	見逃し 10%
B が実行する	—

ひとつひとつは小さい数字です。でも掛け合わさります。しかも「期限の設定漏れ 15%」は、その場では落ちたように見えません。落ちるのは2週間後です。

ここで多くのチームがやることは、注意喚起です。「ちゃんと入れましょう」「リマインドしましょう」。これは各ステップの確率を少し下げる施策で、ステップの数は変わりません。

工程を1つ消す

効くのは、確率を下げることではなく工程を消すことです。

いちばん脆いのは「転記」です。依頼が発生した場所（チャット）と、タスクが管理される場所（ツール）が違う。この2点間を人間が手で運んでいる。ここを消します。

依頼と同時にタスクになる——それだけで表はこう変わります。

ステップ	落ちる確率
A が依頼する（同時にタスク化される）	未読 0%
転記	工程そのものが消える
期限が通知され、公開の場で共有される	見逃し 1%
B が実行する	—

「見逃し 10% → 1%」は注意力の改善ではありません。期限が公開の場に出ているので、B が見逃しても誰かが気づく。個人の記憶に依存しない構造になった、というだけです。

責めない、という設計方針

この考え方には裏側があります。抜け漏れを個人の落ち度として扱わないということです。

抜け漏れが「個人の責任」である限り、起きたときに報告されません。報告されなければ検知もできず、仕組みも直らない。悪循環です。

抜け漏れを「プロセス上で検知・対処すべき対象」に変えると、逆のことが起きます。落ちたことが普通に可視化され、どの工程で落ちたかが分かり、その工程を消す議論ができる。

チームが安心して非同期に移行できるのは、この安心が先にあるからです。「見逃しても仕組みが拾う」と信じられないと、人は不安で同期に戻ります。会議を増やし、確認を増やし、同期割合が上がる。

最初にやること

いきなり全部を変える必要はありません。次の3つだけでも、体感はかなり変わります。

1. 依頼を口頭・DM で完結させない。 残る場所に書く。
2. 依頼には必ずオーナーと期限を付ける。 「今週中に誰かが」は依頼ではありません。
3. 「確認待ち」を状態として持つ。 着手前なのか、投げ返し待ちなのかが区別できないと、待ちが見えません。

UTSUROI はこの3つを、特別な運用を強いずに成立させるための道具です。普段どおりチャットして、普段どおりタスクを動かすだけで、裏側で状態が構造化されていきます。

---

具体的な手順はレシピ集にあります。