⑥ 定着させる（最初の2週間）
ツールの導入が失敗するのは、たいてい機能不足ではなく運用の型がないまま始めるからです。最初の2週間でやることを先に決めておきます。
1週目: 入れることに集中する
Section titled “1週目: 入れることに集中する”この週の目標は、チームの仕事が UTSUROI の外に存在しない状態を作ることです。
決めておくルール
Section titled “決めておくルール”- 依頼は残る場所でする。 口頭・DM で完結させない。
- 依頼には必ず期限とボール保持者を付ける。 「今週中に誰かが」は依頼ではありません。
- 迷ったら作る。 重複は後でアーカイブすればいい。作らないほうが高くつきます。
この週にやらないこと
Section titled “この週にやらないこと”- レーンの作り込み
- ラベル体系の設計
- 分析を見ること
まだデータがないので、分析を見ても何も分かりません。設計は2週目以降に、実際に詰まった場所を見てから行います。
2週目: 滞りを見る
Section titled “2週目: 滞りを見る”データが溜まったら、週に1回、10分だけ盤面を見る時間を取ります。
見るのはインサイト → リスクです。ここには滞っているタスクが集まります。
見るときの質問
Section titled “見るときの質問”- ボール保持者が空のタスクはあるか → 誰も動く番になっていない＝止まっています
- 期限が未設定のタスクはあるか → 期限がないと滞りとして検知されません
- 同じレーンに長く留まっているタスクはあるか → そのレーンが待ちの発生源です
3つめが重要です。特定のレーン（レビュー待ち、承認待ち）に長く滞留しているなら、そこがあなたの組織の同期点です。同期割合を下げる作業は、そのレーンを対象に行います。
詳しい手順は滞留タスクを毎週棚卸しするにあります。
定着したら、次の2つで効きが一段変わります。
- MCP をつなぐ — 議事録からタスクを一括生成する、朝のサマリを AI に作らせる
- ベロシティから現実的な期日を引く — 実績にもとづく見積もり
うまくいかないときのチェック
Section titled “うまくいかないときのチェック”| 症状 | たいていの原因 |
|---|---|
| タスクが作られない | 依頼が DM・口頭で流れている。Slack 連携が未設定 |
| 期限が空のタスクが多い | 依頼時に期限を決める習慣がない。ルール1に戻る |
| 誰も盤面を見ない | ボードが細かすぎて、自分の仕事がどこにあるか分からない |
| 通知がうるさい | 通知を入れすぎ。期限切れ通知だけに戻す |