プロジェクトが遅れる原因｜見えていない待ち時間を探す
プロジェクトが遅れた原因を振り返ると、たいてい「見積りが甘かった」「人手が足りなかった」「途中で仕様が変わった」の3つに落ち着きます。ところが同じ対策を打っても翌月また遅れる。原因がそこにないからです。日程を食っているのは作業そのものではなく、確認待ち、決裁待ち、返事待ちという、誰の作業時間にも計上されない停滞です。この記事では、その見えていない待ち時間をどう見つけ、どう縮めるのかを、進行をとりまとめる立場の手順として整理します。
作業が遅いのではなく、止まっている時間が長い
遅延の話をすると、真っ先に疑われるのは作業者の速度です。しかし工程を分解してみると、速度の問題ではないことのほうが多くあります。
工数は合っているのに、日程だけがずれていく
たとえば、ある成果物を作るのに着手から完了まで12日かかったとします。担当者に聞くと「実際に手を動かしたのは3日ぶんくらい」と答える。残りの9日はどこへ行ったのか。初稿を出したあとの確認が返ってくるまでに数日、修正して再提出したあと承認が下りるまでにまた数日、その間に担当者は別の仕事に移っていた、という内訳になります。
このとき見積り工数は間違っていません。3日と見積もって3日で作れているのだから、見積り精度はむしろ良いほうです。それでも日程は4倍に伸びる。ここに、遅延対策が空振りし続ける理由があります。工数を精緻化しても、止まっている時間には一切効きません。
進行をとりまとめる人がまず切り分けるべきなのは、「遅いのか、止まっているのか」です。この2つは原因も打ち手もまったく違います。遅いなら人を増やすか範囲を削る話になりますが、止まっているなら人を増やしても止まる箇所が増えるだけです。
待っている時間は、誰の作業時間にも計上されない
止まっている時間が見えにくいのには理由があります。作業時間は担当者が記録しますが、待ち時間には記録する主体がいないからです。
依頼した側は「投げたのでこちらの手は空いた」と考え、依頼された側はまだ着手していないので何も記録しません。結果として、その期間は誰の工数表にも載りません。載っていないものは会議で話題にならず、話題にならないものは対策が打たれません。
この構造は労働時間の議論と似ています。厚生労働省が示している労働時間の適正把握に関するガイドラインでは、作業に従事していない待機の時間についても、労働から離れることが保障されていない状態であれば労働時間として扱うと整理されています。
使用者の指示があった場合には即時に業務に従事することを求められており、労働から離れることが保障されていない状態で待機等している時間（いわゆる「手待時間」） 出典: mhlw.go.jp
これは労務管理の文脈での整理であり、個別の事案がどう扱われるかは所轄の労働基準監督署や社会保険労務士に確認してください。ただ、考え方として借りられる部分があります。作業していない時間も、拘束が続いているなら時間として数えるという発想です。プロジェクトの進行でも同じで、担当者が手を動かしていなくても、その仕事が完了に向かって進んでいないなら日程は消費されています。
対策が毎回同じところに戻ってしまう理由
遅延の振り返りをすると、出てくる対策は「見積りにバッファを積む」「進捗会議を週2回にする」「早めにアラートを上げる」あたりに収束しがちです。どれも間違いではありませんが、待ち時間には効きません。
バッファを積むと、待ち時間はバッファの中に吸収されて見えなくなります。会議を増やすと、確認の機会は増えますが、会議まで待つという新しい待ち時間が生まれます。アラートを早く上げても、上げた先で判断が返ってこなければ止まったままです。
打ち手が的を外しているのは、原因の特定が「人の努力」の粒度で止まっているからです。止まっている場所を構造として特定するところまで降りないと、次に打つ手は決まりません。
待ち時間はどこに溜まるのか
止まっている時間を探すには、溜まりやすい場所をあらかじめ知っておくほうが早く見つかります。よく出てくるのは次の4つです。
確認待ち
成果物を出したあと、レビューやチェックが返ってくるまでの時間です。プロジェクトの中で最も長く、最も見えにくい待ち時間がここに溜まります。
確認待ちが長引く典型は、確認する人が1人に集中している場合です。品質の統一という意味では正しい体制ですが、その人の予定が埋まっている日は全案件が同時に止まります。とりまとめる立場から見ると、進捗表の上では複数のタスクが並行して進んでいるように見えるのに、実際には全部が同じ1人の予定表を待っている、という状態になります。
もうひとつの典型は、確認の粒度が決まっていない場合です。「ざっと見てほしい」のか「細部まで詰めてほしい」のかが分からないと、確認する側は安全側に倒して全部を丁寧に見ます。時間がかかるので後回しにされ、後回しにされるからさらに溜まります。依頼するときにどこを見てほしいかを1行だけ書くことで、この待ちはかなり縮みます。
決裁待ち
金額や契約、対外的な文書など、上位者の承認が要る事項の待ちです。確認待ちと違うのは、待っている相手がプロジェクトの外にいることが多い点です。
決裁待ちで厄介なのは、待ちが始まった時点では誰も待ちだと思っていないことです。「申請を出した」で一段落した気分になり、次に思い出すのは締切が近づいたときです。その間に決裁者が出張していた、差し戻しの連絡が別の経路に届いていた、といったことが起きます。
決裁の順番が直列に組まれている場合はさらに伸びます。3人の承認が要る手続きで、1人あたり2営業日で回ったとしても、それだけで6営業日が消えます。並行して回せる承認なのか、順番に回さなければならないのかは、手続きを作った時点で決まっているので、進行側で変えられることは多くありません。だからこそ、いつ始めるかだけが唯一の変数になります。
返事待ち
社外の取引先、他部署、外部の協力者からの回答を待つ時間です。相手が自分の管理下にいないぶん、期日を握れません。
返事待ちで起きやすいのは、質問の投げ方が原因で往復が増えるパターンです。「この仕様で問題ないでしょうか」とだけ書いて送ると、相手は何を判断すればよいのか分からず、確認のための質問を返してきます。1往復が2日かかる相手なら、余計な往復が1回増えるだけで日程は2日伸びます。選択肢を示して「AとBのどちらでいきますか。返答がなければ3営業日後にAで進めます」と書けば、往復は原則1回で終わります。
手番待ち
前の工程が終わらないと次の工程に入れない、という構造的な待ちです。設計が固まらないと実装に入れない、原稿が来ないと編集に入れない、といったものです。
手番待ちは依存関係として表に描かれることが多いので、4つの中では最も見えやすい待ちです。ただ、見えているのに縮まらない。前工程が遅れれば後工程は待つしかない、という諦めが先に来るからです。
実際には、前工程の成果物を分割して、確定した部分から順に渡す方法が取れることがあります。全部が固まるまで待つのではなく、変わらないと分かっている部分だけ先に流す。この判断ができるかどうかで、手番待ちの長さは大きく変わります。
待ち時間が表から消える4つの仕組み
待ち時間が見えないのは、誰かが隠しているからではありません。使っている表や道具の作りが、待ちを表示しない構造になっているだけです。
状態が「未着手・進行中・完了」しかない
進捗表の状態欄が3段階になっている場合、待ちを表現する場所がありません。レビューに出して返事を待っている仕事は、進行中と書くしかない。担当者は手を動かしていないのに、表の上では進行中と表示されます。
とりまとめる人がこの表を見ても、止まっている仕事は見つかりません。全部が進行中に見えるからです。気づくのは締切の直前で、そのときにはもう間に合いません。
依頼が会話の流れの中にある
チャットや口頭で依頼された仕事は、依頼した瞬間から時間が流れ始めますが、その開始時刻はどこにも記録されません。
会話の中の依頼は、相手が読んだかどうかも分かりません。読んだうえで後回しにしているのか、そもそも気づいていないのかが区別できない。この区別がつかないと、催促するタイミングを決められず、結局は締切が近づくまで放置されます。
担当が空欄のまま置かれている
「これ、誰かやっておいてください」で始まった仕事は、誰のものでもない状態で待ちます。担当欄が空欄の行は、表の上では存在していますが、実際には誰も動かしません。
空欄の行が数行あるうちは目に付きますが、20行を超えるあたりから背景に溶けます。とりまとめる人の頭の中には残っているので当面は回りますが、記憶に頼った運用は本人が忙しくなった瞬間に崩れます。
期限が作業の期限しか持っていない
多くの表には期限が1つしかありません。その期限は成果物の完成期限です。ところが実務では、レビューを依頼する期限、返事をもらう期限、決裁を出す期限といった、途中の期限のほうが日程を左右します。
完成期限だけを置いた表は、締切の当日まで赤くなりません。途中で止まっていても表は静かなままです。逆に、途中の期限を置いておけば、止まった瞬間にその行が期限切れになります。止まったことを表に自動的に語らせることが、待ち時間を見つける最短の方法です。
見えていない待ち時間を見つける手順
構造が分かったら、実際に自分のチームの待ち時間を数えます。全案件を調べる必要はありません。数件を分解すれば傾向は出ます。
直近で遅れた仕事を3件だけ選ぶ
対象は、直近に完了して、当初の予定より遅れたものを3件です。大きい案件と小さい案件を混ぜたほうが傾向が見えます。
3件に絞る理由は、この作業を全案件でやろうとすると必ず途中で止まるからです。分析そのものが待ち時間を生んでは本末転倒になります。3件なら1時間ほどで終わります。
着手日と完了日の間を分解する
選んだ3件について、着手した日と完了した日の間で何が起きたかを時系列に並べます。チャットの履歴、メール、ファイルの更新日時を突き合わせれば、だいたい再現できます。
並べるときの粒度は「日」で十分です。時間単位まで追う必要はありません。何日に誰が何を出して、何日に誰から反応が返ってきたか。それだけを並べます。
誰のボールでもなかった日に印を付ける
並べた時系列を見て、その日に誰かが手を動かしていたかどうかを判定します。手が動いていた日を作業日、動いていなかった日を待ち日として印を付けます。
判定に迷う日は待ち日に寄せてください。「担当者は他の仕事をしていた」という日は、この仕事にとっては待ち日です。目的はこの仕事の日程がどう消えたかを見ることなので、担当者が暇だったかどうかは関係ありません。
3件ぶんの印を付け終えると、作業日と待ち日の比率が出ます。この比率が、遅延対策をどちらに向けるべきかを教えてくれます。作業日のほうが圧倒的に多いなら見積りや人員の話ですが、待ち日が半分を超えているなら、見積りをいくら精緻にしても日程は縮みません。
待ちの種類ごとに数える
最後に、待ち日を確認待ち、決裁待ち、返事待ち、手番待ちの4つに分類して数えます。3件ぶんを合計すれば、どの種類が一番長いかが見えます。
ここまで来ると、打ち手は自動的に決まります。確認待ちが最長なら確認の体制を、決裁待ちが最長なら申請を出す時期を、返事待ちが最長なら質問の書き方を変える。原因を1つに絞れているので、対策も1つで済みます。
現場でよく起きるのは、この4つが均等ではなく、1つに極端に偏るという結果です。偏っているなら、そこだけを直せば効果が出ます。
待ち時間を縮める打ち手
見つけたあとに実際に何を変えるか。順番に効果が出やすいものから並べます。
状態に「待ち」を作る
進捗の状態を3段階から4段階以上に増やして、確認待ちや承認待ちを独立した状態にします。これだけで、止まっている仕事が表の上で区別できるようになります。
状態を増やすときの注意は、増やしすぎないことです。待ちの種類ごとに状態を作ると7段階や8段階になり、担当者がどれを選べばよいか迷います。迷う運用は更新されなくなります。まずは「待ち」を1つ足すところから始めて、種類の内訳は別の欄で持つほうが定着します。
待ちには必ず相手と期日を書く
待ちの状態にした仕事には、誰を待っているかと、いつまでに返ってくるはずかを書きます。この2つが無い待ちは、待っているのではなく放置です。
相手を書くと、催促する先が明確になります。期日を書くと、その日を過ぎた時点で行が赤くなり、催促のきっかけが自動的に生まれます。とりまとめる人が全部を記憶しておく必要がなくなり、表を見るだけで催促先が分かるようになります。
確認を溜めて決まった時刻に流す
確認待ちが最長だった場合、確認する人の作業の仕方を変えるのが最も効きます。よくあるのは、依頼が来るたびに割り込みで見るのをやめて、1日2回など決まった時刻にまとめて見る方式です。
確認する側の集中は保たれ、依頼する側は最長でも半日ほどで返ってくると計算できます。いつ返ってくるか分からない状態が消えるだけで、後続の予定が立てやすくなります。
確認する人が1人に集中している場合は、確認の種類を分けて一部を委譲します。全部を委譲する必要はありません。判断の要らない形式的なチェックだけを外に出すだけでも、待ちの列は短くなります。
決裁の要否と所要日数を先に表にしておく
決裁待ちは、進行側の努力では短くできません。できるのは、いつ出すかを前倒しすることだけです。
そのために、どの手続きに何日かかるかを一覧にしておきます。金額がいくらを超えたら誰の承認が要るか、その承認は何営業日で返ってくるか。この表があれば、逆算して申請日を工程表に書き込めます。決裁を待つ期間そのものが工程の一部として表に載るので、締切直前に気づくことがなくなります。
返事が来ない前提の締切を置く
社外や他部署への質問には、返答期限と、返答が無かった場合にどう進めるかをあらかじめ書き添えます。相手を急かすためではなく、こちらの日程を止めないためです。
この書き方は相手にとっても楽になります。判断の選択肢と期限が示されていれば、読んだその場で返せます。逆に、期限も選択肢も無い質問は、後で考えようと思われて滞留します。
人を責める話にしないための扱い方
待ち時間を可視化すると、必ず「誰が止めていたか」が見えてしまいます。ここの扱いを間違えると、次から誰も正直に記録しなくなります。
待ちの原因は個人ではなく設計にある
確認が3日かかった事実が出てきたとき、確認者の怠慢だと結論づけるのは早すぎます。その人に確認が集中する体制になっていた、依頼の粒度が曖昧で時間がかかった、他の緊急案件が同時に来ていた。原因は本人の外にあることのほうが多くあります。
とりまとめる立場が最初に言うべきなのは、「この仕組みだと誰がやっても止まる」という形の説明です。仕組みの話にしておけば、当事者は防御に回らずに済み、実際に何が起きていたかを話してくれます。
数字は個人別に出さない
分解した結果を共有するときは、担当者別ではなく工程別に集計します。「確認工程で合計何日」までは出しても、「誰の確認で何日」は出しません。
個人別の数字を出した瞬間に、記録は正確でなくなります。待ちの状態に移すのをためらったり、実際より短く申告したりする動きが出ます。可視化の目的は責任の所在を決めることではなく、どこを直すかを決めることなので、個人別の分解は要りません。
改善の結果も待ち時間で測る
打ち手を入れたあと、効果を測るときも同じ指標を使います。作業日と待ち日の比率が動いたかどうかを見ます。
納期を守れた件数で測ると、たまたま余裕のある月だっただけで良い数字が出てしまいます。待ち日の長さは月ごとの忙しさの影響を受けにくいので、施策の効果を見る指標として素直です。
すでに遅れている案件を立て直すときの順番
予防の話とは別に、いま遅れている案件をどう戻すかという課題があります。ここでも最初に見るのは待ち時間です。
挽回策を決める前に、残りの日程の内訳を出す
遅れが判明したとき、最初に出てくる案は「人を増やす」「残業して詰める」「範囲を削る」のどれかです。しかし、残りの日程のうち作業日が何日で待ち日が何日かを出さないまま選ぶと、外れます。
残り10日のうち、確認と承認の往復に6日が予定されている案件に人を追加しても、作業日の4日が2日になるだけで、全体は8日にしかなりません。この場合に効くのは人の追加ではなく、確認の回数を減らす交渉です。初稿と最終稿の2回だった確認を、最終稿の1回にまとめられないかを関係者に相談する。それだけで日程は数日縮みます。
逆に、残り日程のほとんどが作業日で埋まっているなら、人を追加するか範囲を削るかの判断になります。この見極めを最初にやるかどうかで、打ち手の当たり外れが決まります。
範囲を削るときは、待ちが多い部分から外す
範囲を削る判断になった場合、削る候補は工数の大きい順に選ばれがちです。しかし日程を戻すことが目的なら、待ちの多い部分から外すほうが効きます。
対外的な確認が要る成果物、決裁が要る手続きを含む作業、他部署の回答を待つ調査。これらは工数が小さくても日程を長く占有します。工数1日の作業でも、承認に5日かかるなら、外したときに戻る日程は5日ぶんです。工数の大きさと日程への影響は一致しません。
振り返りは、遅れた原因ではなく気づいた時点を問う
案件が終わったあとの振り返りで「なぜ遅れたか」を問うと、答えは属人的な反省に流れます。代わりに「いつ気づけたか」を問うと、仕組みの話になります。
締切の3日前に気づいたのなら、その情報は表のどこにも出ていなかったということです。どこに何を表示していれば2週間前に気づけたかを決め、次の案件の表に組み込む。この問い方にすると、振り返りの結論が具体的な表の変更として残ります。反省文で終わる振り返りは、次の案件に何も引き継がれません。
道具の側で止まっている場合の見分け方
運用を変えても待ち時間が縮まらないとき、原因が道具の作りにあることがあります。ここは進行の努力では埋まりません。
表計算とチャットの組み合わせで詰まる場所
進捗を表計算で管理し、依頼をチャットで流す組み合わせは、小さいチームでは十分に回ります。詰まるのは人数と案件数が増えたときです。
表計算は1人が開いて編集している間、他の人からは古い状態に見えます。とりまとめる人が更新をまとめて反映する運用になると、その更新作業そのものが新しい待ちを作ります。チャット側は前述のとおり、依頼の開始時刻も相手の認識も残りません。
道具を替えるかどうかの判断は、状態を1つ動かすのに何回の操作が要るかを数えると決めやすくなります。担当者が待ちの状態にするために、表を開いて、行を探して、セルを選んで、日付を入れて、保存して、チャットで報告する。この手数が多いほど、更新は省略されます。
ボード型の道具に移すときに見るところ
進行を1枚の板の上に並べる形式の道具は、状態を列として表現するので、待ちが視覚的に分かります。列の幅ではなく、列に溜まったカードの枚数を見れば、どこで詰まっているかがひと目で分かります。
候補を絞るときは、機能一覧を眺めるよりも、いま使っている道具との違いを見るほうが早く決まります。カードを並べる形式の代表的な道具との違いはTrelloとの比較にまとまっています。タスクの割り当てと期限管理を重視する道具との違いはAsanaとの比較、文書とデータベースを兼ねる道具との違いはNotionとの比較で整理されています。
工程の自動化や全社的な運用を前提にした道具と比べたい場合はmonday.comとの比較、開発工程の課題管理を軸にした国産の道具と比べたい場合はBacklogとの比較、同じくボード形式の国産の道具と比べたい場合はJootoとの比較が対応します。候補が定まっていない段階なら、まず比較の一覧で全体を見渡してから絞るほうが手戻りがありません。
大事なのは、いま使っている道具が悪いという結論に急がないことです。表計算もチャットも、それぞれの役割では優れています。問題は、待ちを表示する場所がどこにも無いことのほうにあります。
できることと、できないことの両方を見る
道具を選ぶとき、機能一覧の長さは判断材料になりません。長い一覧は、使わない機能まで含めて長いだけです。見るべきは、自分たちの待ちの型に効く機能があるかどうかと、逆に何ができないかです。
できることには、板の上で状態を動かす基本的な操作がまとまっています。同時に、ソースコードのリポジトリ機能は持たないこと、自動化や外部サービス連携の豊富さでは勝負しないこと、画面は日本語のみであることも明示されています。開発工程をリポジトリと紐づけて管理したいチームや、多数の外部サービスをつないで自動化したいチームは、この時点で検討から外せます。外せる条件が早く分かるほど、選定にかかる時間そのものが短くなります。
移行のしやすさも待ち時間に直結します。移行作業が長引けば、その間は新旧2つの場所に情報が散らばり、探す時間が増えます。Trelloからの移行には自動で取り込める範囲が書かれていますが、自動で取り込めるのは1つのサービスからだけで、それ以外は手作業になります。移行にかける期間を先に見積もっておくほうが安全です。
社外の協力者を板に招く運用を考えている場合は、どこまで見えてどこから見えないかを先に確認しておく必要があります。安全性の考え方にその方針が書かれています。招く範囲が決まらないと招待が止まり、招待が止まると相手からの返事待ちが始まらないまま日数だけが過ぎます。
料金と運用のかたちから、待ち時間の扱いを読む
道具の料金の作りは、運用の詰まり方に直接効いてきます。ここは見落とされがちですが、待ち時間の話と地続きです。
機能でプランを分けない構造がもたらす副作用
料金の設計を運用の目線で読むと、機能で絞らず、区切るのは人数とボードの数だけという構造には、はっきりした副作用があります。「この機能を使いたいので上位プランに上げてほしい」という社内の申請が発生しません。
申請が発生しないということは、決裁待ちが1つ減るということです。前述のとおり、決裁待ちは進行側の努力では短くできない種類の待ちなので、そもそも発生しない設計になっているかどうかは、日程に効いてきます。
一方で、人数が増えれば費用は素直に伸びます。外部の協力者を多く招く運用を想定しているチームは、招待する人数の見込みを先に立てておくほうが安全です。人数の数え方は道具ごとに異なるので、候補が複数あるなら比較の一覧で数え方を並べて確認してください。
使い始めてから止まる場所を減らすという考え方
道具を入れたあとに起きる遅延は、進行の遅延と区別しにくいので厄介です。権限が足りなくて操作できない、上限に達して追加できない、機能が別プランで使えない。どれも待ちを生みますが、工程表の上では「担当者が対応中」に見えます。
導入前に潰しておけるのはこの種類の待ちです。よくある質問には、上限の考え方や運用上の制約が並んでいます。導入を検討する段階で、自分たちの人数とボードの数がどこに当たるかを先に確認しておくと、使い始めてから止まる場所が減ります。
結局のところ、縮むのはどの時間か
待ちを可視化して運用を変えても、作業量そのものは減りません。減るのは、確認が返ってくるのを待つ時間、催促するきっかけを探す時間、そして止まっていたことに締切直前で気づいて慌てる時間です。
この3つは、どれも工数表に載らない時間です。だから削減しても成果として見えにくく、優先順位が上がりません。とりまとめる立場の人ができるのは、遅れた案件を3件だけ分解して、作業日と待ち日の比率をチームに見せることです。比率が出れば、対策をどちらに向けるべきかという議論は終わります。
プロジェクトが遅れる原因は、たいてい誰かの怠慢ではありません。止まっている時間を表示する場所が、どこにも用意されていないだけです。表示する場所を作れば、止まった瞬間に誰かが気づきます。気づいた仕事は、遅れる前に動き出します。
Q1. 遅延の原因が待ち時間かどうかを、手早く確かめる方法はありますか？
直近で遅れた案件を3件選び、着手日から完了日までを日単位で並べて、その日に誰かが手を動かしていたかを判定してください。動いていない日を待ち日として数え、作業日との比率を出します。待ち日が半分を超えていれば、見積りや人員をいくら調整しても日程は縮みません。3件なら1時間ほどで終わります。
Q2. 進捗の状態は何段階にするのが適切ですか？
まずは未着手、進行中、待ち、完了の4段階にしてください。3段階だと待ちを表す場所が無く、止まっている仕事も進行中と表示されます。待ちの種類ごとに状態を分けて7段階や8段階にすると、担当者がどれを選ぶか迷い、更新されなくなります。種類の内訳は状態ではなく別の欄で持つほうが定着します。
Q3. 待ち時間を可視化すると、確認する人が責められませんか？
個人別ではなく工程別に集計してください。確認工程で合計何日という形までは出し、誰の確認で何日という分解は出しません。個人名が付いた数字を出すと、待ちの状態に移すのをためらう動きが出て、記録そのものが不正確になります。原因は本人ではなく、確認が1人に集中する体制側にあることがほとんどです。
Q4. 社外や他部署からの返事待ちは、どうやって短くすればよいですか？
質問に選択肢と返答期限、そして返答が無かった場合の進め方を書き添えてください。判断材料が揃っていれば相手はその場で返せます。期限も選択肢も無い質問は後回しにされて滞留します。1往復に2日かかる相手なら、余計な往復が1回増えるだけで日程は2日伸びるので、往復の回数を減らすことが最も効きます。