「待ち」をひとくくりにすると、見えなくなる
進行が止まっているとき、私たちはざっくり「クライアント待ちです」と言いがちです。でも、この一言が曲者でした。待ちにはいくつも種類があって、それぞれ対処が違うからです。
私の現場では、待ちを大きく4つに分けるようにしています。クライアントの確認待ち。社内の承認待ち（上長やアートディレクターのチェック）。素材・原稿待ち（先方支給のロゴ、文章、写真など）。そして、いちばん見落としがちな「自分待ち」——本当は自分が次に動く番なのに、止まっていると思い込んでいるやつです。
正直なところ、この4つ目がいちばん多いです。「先方の返事待ち」と思っていたら、実は2週間前にもう返ってきていて、自分が拾えていなかった。チャットの流れの中にOKが埋もれていて、誰も気づかないまま時間だけ過ぎる。これは相手のせいではなく、こちらの管理の問題です。
待ちを種類で分けると、打つ手が変わります。クライアント待ちなら催促のリマインドだし、社内承認待ちなら承認者をつつく話だし、自分待ちなら今すぐ着手するだけ。「クライアント待ちです」の一言で片付けていたものを分解するだけで、止まっている理由の解像度が一段上がります。
ボールの所在が消える瞬間
では、なぜ「誰待ちか」が分からなくなるのか。私の経験では、だいたい次の場面でボールの所在が消えます。
ひとつは、確認依頼がチャットに流れていったとき。「ご確認お願いします」とSlackやメールで投げた瞬間は、たしかにボールは相手に渡っています。でもその投稿は3日もすれば他の話題に押し流されて、誰が何を待っているのか、当事者しか覚えていない状態になります。返事が来ても、来なくても、可視化されないまま埋もれます。
もうひとつは、タスクのステータスが「進行中」のまま放置されているとき。多くのチームのボードは「未着手／進行中／完了」くらいの粗さで運用されています。でも実際には、デザインを描いている「進行中」と、描き終えてクライアントの返事を待っている「進行中」は、まったく別の状態です。前者は自分が動いていて、後者は自分は動けない。これを同じ「進行中」に押し込めると、ボードを見ても誰待ちか分かりません。
そして三つ目が、誰待ちが口頭やその場のやり取りでしか共有されていないとき。朝会で「あれ、クライアント待ちです」と言って、その場の全員が「OK」と頷く。けれどその情報はどこにも残らないので、翌週には「あれってどうなったっけ？」が始まります。
共通しているのは、ボールの所在が「人の記憶」と「流れるチャット」の中にしかない、ということです。記録される場所がないから、見えなくなる。
「進行中」を解体する——誰待ちをステータスにする
ここがこの記事のいちばん伝えたいところです。滞留を減らす起点は、催促のマメさでも、クライアントの躾でもなく、「進行中」というステータスを解体することでした。
具体的には、案件やタスクの状態に「いま誰がボールを持っているか」を含めてしまいます。たとえば「進行中」を、こんなふうに割り直します。社内作業中（自分／チームが動く番）、クライアント確認待ち、社内承認待ち、素材待ち。たったこれだけでも、ボードを開いた瞬間に「自分が動くべきもの」と「相手の番で待っているもの」が一目で分かれます。
私がこの運用に切り替えたとき、最初の効果は意外なところに出ました。「クライアント確認待ち」のステータスに並んだ案件を眺めて、そのうち2件はもう先方からOKが返っていることに気づいたのです。つまり、自分待ちが2件も埋もれていた。ステータスを分けただけで、止まっていたはずの案件が動き出しました。
もうひとつ大事なのは、待ちのステータスには必ず「いつまでに返してほしいか」をセットで持たせることです。「クライアント確認待ち」だけだと、いつまで待つのが正常なのか分かりません。「6月12日まで確認待ち」と期限が入っていれば、過ぎた瞬間に「これは催促すべき滞留だ」と判断できます。先方にも最初に「ここの確認は2営業日でお願いします」と握っておくと、確認期間そのものが進行表に組み込まれます。制作側だけが締切を持って、クライアント側は無期限、という非対称が滞留の温床なので、ここは最初に握る価値があります。
滞留を、人力で見張らない
ステータスを分けても、それを毎朝ひとつずつ見て回って「これは期限を過ぎているな」と人力でチェックするのでは、結局その手間がボトルネックになります。ディレクターが10案件、20案件と抱えていれば、全部の待ち期限を頭で追うのは現実的ではありません。
だからここは仕組みに任せます。やることは2つです。
ひとつは、滞留の予兆を自動で拾うこと。待ち期限が近づいた、あるいは過ぎたタスクを、こちらが探しにいかなくても通知が教えてくれる状態にする。「先方の確認が予定より1日遅れています」と先に言ってくれれば、火を噴く前に催促の一本が打てます。
もうひとつは、誰待ちが集計された一覧をいつでも見られるようにすること。案件ごとにステータスを見て回るのではなく、「いまクライアント確認待ちで止まっている案件」「社内承認待ちで滞っている案件」を横断で一望できるダッシュボードがあると、朝の数分で全体の詰まりが把握できます。どこに渋滞が起きているかが見えれば、その日に最優先で押すべきボールが決まります。
このあたりは、後述するLOGLIKEのAI予告通知やダッシュボードが効く領域ですが、その前にツール全般の話をしておきます。
ツールのステータス・通知設計を率直に見る
汎用のプロジェクト管理ツールでも、誰待ちの可視化はある程度できます。ただ、得意不得意ははっきり分かれます。等距離で褒めても選ぶ参考にならないので、率直に書きます。
Backlogは、課題のステータスを自分たちで定義できるので、「確認待ち」「承認待ち」のような状態を足すこと自体は問題なくできます。担当者を必ず立てる文化とも相性がよく、誰がボールを持っているかは追いやすい。料金はユーザー数ではなくスペース単位の定額で、スタンダードプランが月額17,600円（2026年時点）。人数が増えても価格が変わらないので、外部の協力会社を巻き込んで人数が膨らむ制作現場では効いてきます。一方で、もともと開発チーム発のツールなので、デザイン校正やクライアントへの見せ方は別の工夫が要ります。
滞留の予兆検知という一点では、Asanaが一歩抜けています。ステータスやカスタムフィールドの自由度が高く、Asana Intelligenceが進捗データから遅延リスクのある作業を拾って、ステータス更新の文面まで下書きしてくれる。ここは正直、頭ひとつ抜けていると感じます。ただ料金はユーザー課金で、AIやタイムライン（ガント）が使えるStarterプランで1人あたり月額10.99ドル（年払い・2026年時点）から。クライアントや外注を都度アカウントに入れていくと、人数ぶん費用が膨らむのは構造的な弱点です。
Notionは、データベースの組み方しだいで「誰待ちビュー」を自在に作れます。柔軟さは随一です。2026年にはAIアドオンが廃止され、AI機能がビジネスプラン以上に標準で含まれるようになり、タスクDBから遅延リスクのある項目を検知してリーダーに通知する、といった使い方もできるようになりました。ただ、その自由度の裏返しで「設計しないと迷路になる」のはNotionの永遠の課題で、誰待ち運用を維持できるかはチームの設計力に強く依存します。正直、進行管理の専用ツールではないぶん、運用を立てる側の負担は大きめです。
どれも、ステータスで誰待ちを表現すること自体はできます。差が出るのは、それを「クライアントにも見せられるか」「滞留を予兆で拾えるか」「校正や請求まで地続きか」といった、進行管理の前後の工程と繋がっているかどうかです。
AIに任せていい部分、任せると痛い目を見る部分
ここ1〜2年で、各ツールのAIは「滞留を見張る」役割をかなり担えるようになりました。私の実感として、AIに任せて気持ちよく回るのは、状態の検知と下ごしらえの部分です。期限を過ぎた待ちを拾う、ステータス更新の文面を下書きする、複数案件の停滞を要約して並べる。このあたりは人がやると抜けるし、面倒なので、任せたほうが精度も上がります。
逆に、任せると痛い目を見るのは判断です。たとえば「このクライアントは普段から確認が遅いから、ここで催促すると関係がこじれる」といった呼吸は、AIには読めません。滞留しているという事実は拾えても、いま押すべきか、待つべきか、誰にどう連絡するかは人間の領分です。AIが「3日滞留しています」と教えてくれたあとに、相手の事情と案件の温度を踏まえて一手を選ぶ。そこを丸ごとAIに渡すと、機械的な催促でかえって信頼を削ります。
だから私は、AIには「気づかせる」までをやってもらって、「動かす」のは人がやる、という線引きにしています。ボールの所在を見える化するのも、滞留を拾うのも、最終的には人が次の一手を打つための材料を整える作業です。
LOGLIKEで誰待ちを可視化する
ここまでの設計を、私たちのLOGLIKEでどう回すか、実際の運用に寄せて書きます。宣伝というより、誰待ち可視化の一例として読んでもらえればと思います。
まず、案件に紐づいたコメント・メンションで確認依頼を残します。チャットツールに投げると流れて消える依頼を、案件の中に置いておく。これだけで「どの案件の、何の確認を、誰に頼んだか」が記録として残り、後から遡れます。メンションで相手を指名すれば、ボールが誰に渡ったかも明示されます。
次に、滞留はAI予告通知に見張ってもらいます。締切や対応の予兆を先回りして知らせてくれるので、確認待ちが長引いている案件を、こちらが探しにいかなくても拾えます。「気づいたら期限切れ」を減らす役割です。
そして、全体の詰まりはダッシュボードで一望します。案件横断で進捗を見られるので、いまどこで止まっているか、誰待ちの渋滞がどこに起きているかを朝の数分で把握できます。
拾ったけれど今すぐ動かせない待ちは、「あとで対応」に逃がしておきます。素材待ちで自分は動けないタスクを、忘れない場所に置いておく受け皿です。頭の中で覚えておく必要がなくなります。
クライアントとの認識合わせには、ガントチャートの外部共有が効きます。LOGLIKEのガントチャートは外部共有ができるので、「いまどの工程で、何の確認を待っているか」を先方にもそのまま見せられます。確認待ちが自分の番だと先方が視覚的に分かると、催促の角も立ちにくくなります。これらの機能は機能ガイドにまとまっています。
LOGLIKEのよさは、これらが別々のツールではなく、同じ案件の上に乗っていることです。確認依頼（コメント）、滞留の通知、全体の見える化（ダッシュボード）、持ち越し（あとで対応）、クライアント共有（ガント）が地続きなので、ボールの所在を追うために何画面も行き来しなくて済みます。案件管理から校正、請求書管理まで一つにまとめる設計思想はキャンペーンページで紹介しています。
まとめ：止まっているのは人ではなく、ボールの所在が見えていないだけ
確認待ちで案件が止まるとき、つい「クライアントの返事が遅い」「承認者がつかまらない」と相手のせいにしたくなります。でも私の経験では、滞留のかなりの部分は、誰がボールを持っているのかが見えていないこと自体が原因でした。見えていれば、催促すべきものは催促できるし、実は自分の番だったものはすぐ動かせます。
やることはシンプルです。待ちを種類で分ける。「進行中」を解体して、誰待ちをステータスにする。期限をセットで持たせる。そして滞留の見張りは人力ではなく仕組みに任せる。これだけで、締切間際にまとめて火を噴く回数は確実に減ります。
もし、いままさに「自分は終わっているのに案件が止まっている」もどかしさを抱えているなら、誰待ちが見える状態を一度試してみてください。LOGLIKEは無料トライアルから始められます。まずは1案件、ステータスを分けて誰待ちを見えるようにするところから、止まっていた案件が動き出す感覚を確かめてもらえればと思います。