TODOを一本化し、進捗会議を60分から30分にした事例
週次の進捗会議が長い。しかも、終わったあとに何が決まったのかよく分からない。よくある症状です。
この事例のプロジェクトでは、60分の会議のうち32分が「あれはどうなりましたか」の確認に使われていました。原因はTODOが6か所に散らばっていたことです。一本化した結果、会議は30分になり、TODOが完了するまでの平均日数は18日から7日になりました。会社名・数字はすべて架空ですが、記事の中で辻褄が合うように作っています。
■ 会社と案件の前提
項目 | 内容 |
|---|---|
会社名（架空） | リンクスタッフ株式会社 |
業種 | 人材サービス（派遣・紹介） |
年商 | 210億円 |
従業員数 | 640名 |
登録スタッフ | 4万8,000名 |
取引先 | 2,200社 |
案件名 | 派遣スタッフ管理・勤怠・請求システムの刷新 |
期間 | 2025年2月3日 〜 2026年3月2日 本番稼働（13か月） |
承認予算枠 | 1億8,000万円 |
当初計画額 | 196人月 × 87万円 ＝ 1億7,052万円 |
新規開発規模 | 104KStep |
体制 | 社内7名 ＋ ベンダー最大12名 |
週次進捗会議 | 毎週火曜／参加者14名（社内7名・ベンダー7名） |
■ 2025年6月：会議が終わらない
着手から4か月、週次の進捗会議は毎回60分では終わらず、延長することが増えていました。内容を計ってみると、時間の使い方はこうなっていました。
議題 | 所要時間 |
|---|---|
前週の振り返り | 8分 |
TODOの確認 | 32分 |
課題の議論 | 12分 |
連絡事項 | 8分 |
合計 | 60分 |
半分以上がTODOの確認です。しかも、その32分の中身は「進捗の報告」ではなく「あれはどうなっていますか」という確認の往復でした。直近8回の会議で「それ、誰がやることになってましたっけ」という発言がのべ29回出ています。
本来いちばん時間をかけたい「課題の議論」には、12分しか残っていませんでした。
■ 原因：TODOが6か所に散らばっていた
6月の第3週、PMと事務担当2名で、プロジェクトのTODOがどこに何件あるかを数えました。
置き場所 | 件数 | どう使われていたか |
|---|---|---|
週次会議の議事録（Word） | 68件 | 会議で決まった宿題が「アクション」として書かれる |
ベンダーとの共有Excel | 52件 | ベンダー側の作業依頼を管理 |
チャットでの「お願いします」 | 41件 | その場の依頼。記録には残るが一覧にならない |
メール本文 | 37件 | 社外を含む依頼。本文に埋もれる |
システムのTODO機能 | 34件 | 使われてはいたが、一部の人だけ |
PMの手帳・付箋 | 19件 | PMが自分で覚えておくためのもの |
のべ合計 | 251件 | 重複を除くと実質184件 |
数えてみて分かったのは、次の3つでした。
状態 | 件数 | 割合 |
|---|---|---|
どこにも期限が書かれていない | 89件 | 48% |
担当が組織名（「ベンダー」「経理」など） | 97件 | 53% |
すでに完了しているのに、どこかに残っている | 43件 | 23% |
置き場所が6か所あると、「全部でいくつあるのか」が誰にも分かりません。数えられないものは管理できません。実際、この時点では「期限切れは何件ですか」と聞かれても答えられない状態でした。
そして、会議のTODO確認に32分かかっていた理由もはっきりしました。事前に状況を把握する手段がないので、会議の場で1件ずつ聞いて回るしかなかったのです。
■ TODOを一本化した
2025年7月、次の6つのルールに変えました。
TODOは本システムのTODO機能に一本化する。他の場所に書いたものは無効とする
依頼するときは、その場で起票する。チャットで「お願いします」とだけ書くのは禁止
1件1行で「誰が・何を・いつまでに」を必ず埋める。担当は個人名（組織名は不可）
完了したら、その日のうちに完了にする。週次会議での一括処理をやめる
期限切れは、翌営業日にPMへ自動で通知される（システムの通知機能を使う）
週次会議では、期限が今週のものと期限切れのものだけを見る
このうち、いちばん重要なのは1つめです。「他の場所に書いたものは無効」と決めないと、チャットで「お願いします」と書いた人は依頼したつもりになり、受け取った側は気づかない、というすれ違いが残り続けます。無効と決めておけば、依頼したい人が自分で起票するようになります。
3つめの「担当は個人名」も効きました。「ベンダー」と書かれたTODOは、ベンダーの誰も自分のことだと思いません。97件を個人名に直す作業では、そもそも誰がやるのか決まっていなかったものが14件見つかっています。
■ 移行作業にかかった手間
作業 | 件数 | 所要 | 担当 |
|---|---|---|---|
6か所の251件を突き合わせ、重複を特定 | 251件 → 重複67件 | 3営業日 | PM・事務担当2名 |
すでに完了していたものをクローズ | 43件 | 上記に含む | 同上 |
残りをシステムに登録 | 141件 | 1営業日 | 事務担当2名 |
期限のないものを、依頼者に1件ずつ確認 | 89件 | 4営業日 | PM |
担当を組織名から個人名に直す | 97件 | 2営業日 | PM・ベンダーPL |
いちばん手間だったのは、期限が書かれていなかった89件でした。依頼者に「これ、いつまでですか」と聞いて回るのに4営業日かかっています。
面白かったのは、聞かれた側の反応です。「急ぎではないです」と答えたものが31件ありました。急ぎでないなら期限を入れればよく、それで初めて優先順位がつきます。期限を書かないのは、急いでいるからではなく、考えていないからです。
■ 結果：会議が半分になり、完了が早くなった
項目 | 作り直す前（2025年6月） | 作り直した後（8月〜翌2月） |
|---|---|---|
TODOの置き場所 | 6か所 | 1か所 |
実質の件数 | 184件（のべ251件） | 平均38件（常時オープン） |
期限が書かれていないもの | 89件（48%） | 0件（必須項目のため） |
担当が組織名のもの | 97件（53%） | 0件（個人名が必須） |
期限切れ件数 | 数えられなかった | 平均4件 |
完了までの平均日数 | 18日 | 7日 |
週次会議の所要時間 | 60分（TODO確認32分） | 30分（TODO確認8分） |
「誰がやることに…」の発言 | 8回の会議でのべ29回 | 直近8回でのべ2回 |
会議が30分短くなりました。参加者は14名、8月から2月までの30回で計算すると、210時間が会議から解放されたことになります。
ただ、時間が減ったこと以上に大きかったのは、課題の議論に使う12分がそのまま残ったことです。削ったのはTODO確認の24分であって、議論の時間ではありません。会議が短くなったのに、決まることは増えました。
■ 運用を続けるためにやったこと
一本化のルールは、作った直後は守られます。問題は3か月後です。この案件で効いた仕掛けを3つ挙げます。
1. 期限切れの自動通知
システムの通知機能を使い、期限切れのTODOを翌営業日の朝にPMへ一覧で送るようにしました。人が探しに行く必要がありません。誰かが定期的に確認しないと回らない仕組みは、いずれ止まります。
2. チャットで依頼が来たら、その場で「起票をお願いします」と返す
最初の1か月は、これを徹底しました。断るのではなく、起票の依頼に変えて返すだけです。2か月目からは、依頼する側が最初から起票するようになりました。
3. 月初に「1か月以上オープンのもの」を棚卸しする
月初の会議で、30日以上オープンのTODOを一覧で出します。平均で2〜5件でした。多くは「やらなくてよくなったのに残っているもの」で、その場でクローズします。月1回の棚卸しがないと、少しずつ滞留が増えます。
■ 結果（QCD）
観点 | 合格ライン | 実績 | 判定 |
|---|---|---|---|
Q（品質） | 受入テスト 0.25件/KStep 以下 | 0.21件/KStep（22件 ÷ 104KStep） | 達成 |
C（コスト） | 承認枠 1億8,000万円 以内 | 1億7,400万円（200人月・枠の96.7%） | 達成 |
D（納期） | 2026年3月2日 稼働 | 2026年3月2日 稼働 | 達成 |
実績は200人月、計画196人月に対して4人月の超過です。うち1.5人月は、TODOの移行作業（10営業日 × 3名）に使った分です。
TODOの一本化は、それ自体が納期や品質を良くする施策ではありません。ただ、決まったことが決まったとおりに実行される状態をつくると、他のすべてが回りやすくなります。この案件では、課題の議論に使える時間が増えたことが、間接的にQとDに効いたと見ています。
■ 管理帳票の実物
TODO（一本化後の実際の並び）
内容 | 担当 | 期限 | 依頼者 | 状態 |
|---|---|---|---|---|
勤怠締め処理の仕様確認結果を、設計書に反映する | ベンダー設計担当（佐藤） | 2025/8/8 | 業務リーダー | 完了 |
派遣先2,200社の契約形態を3区分に分類した一覧を作成 | 営業管理担当（鈴木） | 2025/8/22 | PM | 完了 |
勤怠データの移行対象期間を、経理部長に確認して回答する | 経理担当（田中） | 2025/9/5 | ベンダーPL | 完了 |
受入テストに参加するスタッフ12名の日程を確保 | 業務リーダー（高橋） | 2025/12/12 | PM | 完了 |
請求書レイアウトの最終版を、取引先5社に事前確認する | 営業管理担当（鈴木） | 2026/1/16 | 業務リーダー | 完了 |
「依頼者」の欄があることに注目してください。期限を延ばすときに、誰に相談すればよいかが分かるようにするためです。この欄がないと、期限が近づいたときに担当が勝手に先延ばしします。
課題管理表（TODOと分けたもの）
ID | 決めること | 決める人 | 期限 | 状態 |
|---|---|---|---|---|
I-026 | 派遣先ごとに異なる締め日を、システムで何パターンまで持つか | 業務部長 | 2025/8/29 | 完了（5パターン） |
I-033 | スタッフの勤怠入力を、アプリにするかWebにするか | 業務部長・情報システム部長 | 2025/9/26 | 完了（Web） |
I-041 | 旧システムの勤怠データを、何年分移行するか | 経理部長 | 2025/11/7 | 完了（3年分） |
I-048 | 請求書の電子化を今回に含めるか、次期に送るか | 経理部長・営業本部長 | 2025/12/5 | 完了（次期） |
リスク管理表
ID | リスク | 発生度 | 影響 | 監視する数字 | 対応 |
|---|---|---|---|---|---|
R-03 | TODOの運用が元に戻り、また散らばる | 高 | 会議時間の再増加 | 月間の「チャットでの依頼」件数（目標0件） | チャットで依頼が来たら、その場で起票を依頼して返す |
R-06 | 期限切れが放置される | 中 | 作業の遅れが見えなくなる | 期限切れ件数（目標5件以下） | 翌営業日にPMへ自動通知。10件を超えたら棚卸しを臨時実施 |
R-09 | 締め日5パターンの実装が複雑化する | 中 | 開発 ＋8人月 | 締め日まわりの単体テスト不具合密度 | 締め日の判定を1つのモジュールに集約する |
R-14 | スタッフ4万8,000名の勤怠データ移行で不整合が出る | 中 | 稼働延期 | リハーサルでの不一致件数（目標0件） | 本番同等データで3回リハーサルを行う |
R-03の監視する数字が「チャットでの依頼件数」で目標0件になっている点に注目してください。運用が元に戻る兆候は、ここに最初に現れます。実績では、7月に9件、8月に3件、9月以降は0〜1件で推移しました。
■ 振り返りと、自分の現場で使うなら
まず反省点です。
着手時に置き場所を決めていなかった：「システムのTODO機能を使う」とは言っていたが、他を禁止していなかった。だから増えた
4か月放置した：会議が延びはじめた2か月目に手を打っていれば、移行は半分の手間で済んだ
移行に10営業日かかった：件数が少ないうちなら、1〜2日で終わった作業
次に効いた点です。
「他の場所に書いたものは無効」と決めた：これがないと、一本化は成立しない
担当を個人名にした：組織名のTODOは、誰も自分のことだと思わない
完了はその日のうちに、というルールにした：会議での一括処理をやめたことで、会議前に状況が分かるようになった
期限切れの通知を自動にした：人が探しに行く仕組みは、いずれ止まる
削ったのはTODO確認の時間だけ：課題の議論の12分には手をつけなかった
最後に、明日から使える形にまとめます。まずは数えることから始めてください。
いま、TODOが何か所にあるか数える：議事録、Excel、チャット、メール、手帳。3か所を超えていたら、確認作業に時間を取られているはずです
そのうち何件に期限が入っているか数える：半分を切っていたら、優先順位がついていない状態です
担当が組織名になっているものを数える：これは「誰も担当していない」と同じ意味です
そして、一本化するときに1つだけ守ってほしいルールがあります。「他の場所に書いたものは無効」と、声に出して宣言すること。置き場所を1つ決めるだけでは足りません。他を無効にして初めて、依頼したい人が自分で起票するようになります。
会議が長いのは、参加者の話が長いからではありません。会議の前に分かっていないことが多すぎるからです。会議の外で分かる状態をつくれば、会議は自然に短くなります。