形骸化した課題管理表を、動く道具に戻した事例
課題管理表はどの現場にもあります。ただ、本当に使われている表は多くありません。週次会議で開くのは最初の5分だけ、あとは誰も見ない。件数だけが増えていく。
この事例は、オープン112件のうち74件が30日以上触られていない状態から、表を作り直して平均滞留日数を47日から12日にした記録です。会社名・数字はすべて架空ですが、記事の中で辻褄が合うように作っています。
■ 会社と案件の前提
項目 | 内容 |
|---|---|
会社名（架空） | クラウドリーフ株式会社 |
業種 | SaaS（人事労務管理クラウド） |
年商 | 46億円 |
従業員数 | 230名 |
導入企業 | 3,400社（ユーザー42万人） |
案件名 | 自社SaaSの基盤刷新（マルチテナント基盤とデータベースの移行） |
期間 | 2025年1月6日 〜 2026年2月2日 切替完了（13か月） |
承認予算枠 | 1億5,500万円 |
当初計画額 | 172人月 × 86万円 ＝ 1億4,792万円 |
移行対象 | 3,400テナント／データ量28TB |
体制 | 社内8名（開発6・インフラ2）＋ ベンダー6名 |
稼働中のサービスの土台を入れ替える案件です。止められる時間が限られ、顧客への告知も必要になるため、判断しなければならないことが次々に出てくる種類のプロジェクトでした。
■ 2025年5月末：課題管理表がどうなっていたか
項目 | 状態 |
|---|---|
起票件数（累計） | 186件 |
オープン中 | 112件 |
30日以上更新されていないもの | 74件（オープンの66%） |
期限切れ | 58件（オープンの52%） |
担当が「PM」になっているもの | 41件（オープンの37%） |
直近4週の会議で言及されたもの | のべ23件（オープンの21%） |
1件あたりの平均滞留日数 | 47日 |
週次会議の所要時間 | 90分（うち課題レビューに45分） |
数字で見ると、この表が道具として動いていないことがはっきりします。3分の2が1か月以上触られておらず、半分が期限切れ。週次会議で45分かけているのに、実際に話題になるのは全体の2割だけです。
よくある対処は「もっと真面目に更新しましょう」と呼びかけることです。しかし、この案件ではそれをやっても3週間で元に戻った実績がありました。意識の問題ではなく、表の作りの問題だったのです。
■ 原因を調べた：186件の中身を1件ずつ見た
6月の第1週、PMと業務リーダーで186件をすべて読み直しました。分かったのは、そもそも課題ではないものが大量に混ざっているということでした。
本来の区分 | 件数 | 割合 | 例 |
|---|---|---|---|
課題（判断が必要なもの） | 58件 | 31% | 移行を一括で行うか分割で行うか |
作業（やることは決まっている） | 84件 | 45% | 移行手順書の作成、検証環境の構築 |
決定記録（すでに決まったこと） | 44件 | 24% | データベースはPostgreSQLとする（3月に決定済み） |
合計 | 186件 | 100% | ― |
課題管理表に載っているもののうち、本当に課題なのは3割だけでした。残りの7割は、載せる場所を間違えていたことになります。
これが「毎週全件をレビューする」やり方と組み合わさると、会議はこうなります。45分のうち大半が、すでに決まったことの確認と、進めるだけの作業の進捗報告に使われる。判断が必要な58件に割ける時間が残らない。だから決まらず、滞留します。
もう1つの原因は、担当の書き方でした。41件がPMになっています。PMは進行を管理する役割で、技術方式や顧客への告知内容を決める権限は持っていません。決められない人が担当になっている課題は、決まりません。
■ 課題管理表を作り直した
2025年6月の第2週、次の6つのルールに変えました。
課題管理表には「判断が必要なもの」だけを載せる：作業はTODOへ、決まったことは決定記録へ移す
「誰が、いつまでに、何を決めるか」を1行で書く：決める人はPMではなく、決められる権限のある人
クローズ条件を書く：「○○を決定し、△△の議事録に記載する」の形。何をもって完了かを先に決める
期限は必ず日付にする：「随時」「TBD」「順次」は禁止
期限を延ばすときは、影響日数を書く：「6/27→7/11（全体に＋3日）」
週次会議では、期限が今週・来週のものだけを見る：全件レビューをやめる
実際の1行が、どう変わったかをお見せします。
6つのルールのうち、効き目が大きかったのは1つめ（仕分け）と2つめ（決める人）でした。
仕分けをしただけで、課題管理表は112件から34件になりました。解決したわけではありません。移しただけです。それでも、週次会議で見るべきものがはっきりしました。
「決める人」を書き換えたときは、抵抗もありました。技術部長に「あなたが決める人です」と書いて見せるのは、気が重い作業です。ただ実際に見せてみると、「これは自分が決めることだったのか」という反応が返ってきました。担当がPMになっている間、決める人は自分が当事者だと思っていなかったのです。
■ 「判断に必要な材料」の欄が効いた
新しい様式で追加した欄のうち、想定以上に効いたのが「判断に必要な材料」でした。
この欄を書こうとすると、多くの場合こうなります。「決められないのは、迷っているからではなく、材料が揃っていないからだ」。そうなれば、次にやることは「決める」ではなく「材料を3つ集める」になります。そして材料集めは作業なので、TODOとして担当と期限を割り当てられます。
58件の課題について、この欄を埋めてみた結果です。
状態 | 件数 | 次にやること |
|---|---|---|
材料は揃っている。あとは決めるだけ | 19件 | 期限を切って、決める場に出す |
材料が足りない | 31件 | 足りない材料をTODOに起こす（のべ68件） |
そもそも決める必要がなかった | 8件 | クローズ |
合計 | 58件 | ― |
半分以上（31件）が材料不足でした。決まらない課題の多くは、決断力の問題ではありません。この見立てができると、課題管理表の使い方が変わります。「なぜ決まらないんですか」と聞く代わりに、「何が分かれば決まりますか」と聞くようになります。
■ 結果：8か月の推移
項目 | 作り直し前（2025年5月） | 作り直し後（6月〜翌1月の平均） |
|---|---|---|
オープン件数 | 112件 | 21件 |
30日以上未更新 | 74件 | 2.5件 |
期限切れ | 58件 | 3件 |
担当がPMのもの | 41件 | 4件 |
平均滞留日数 | 47日 | 12日 |
週次会議の所要時間 | 90分（課題レビュー45分） | 55分（課題レビュー20分） |
週次会議が35分短くなりました。参加者は12名なので、1回あたり7時間、8か月（約34回）で238時間が会議から解放された計算になります。
ただし、短くなったこと自体より大事なのは中身が変わったことです。全件レビューをやめ、期限が今週・来週の課題だけを見るようにしたので、会議で扱うのは毎回4〜7件です。1件に3分かけられるので、その場で決まることが増えました。
10月にオープン件数が24件へ増えていますが、これは移行リハーサルで新しい論点が出たためです。件数が増えること自体は問題ではありません。触られないまま残ることが問題です。
■ 結果（QCD）
観点 | 合格ライン | 実績 | 判定 |
|---|---|---|---|
Q（品質） | 移行後のデータ不一致 0件 | 0件（3,400テナント・28TB） | 達成 |
C（コスト） | 承認枠 1億5,500万円 以内 | 1億5,050万円（175人月・枠の97.1%） | 達成 |
D（納期） | 2026年2月2日 切替完了 | 2026年2月2日 切替完了 | 達成 |
サービスの停止時間は、分割方式（200テナントずつ17回）を採ったことで、1回あたり最大42分に収まりました。一括方式の試算では6時間30分だったため、顧客影響を大きく減らせています。
この方式が6月27日に決まったのが、図1で紹介したI-034です。78日間動かなかった課題が、様式を変えて材料を揃えたら7日で決まりました。
■ 管理帳票の実物
課題管理表（作り直し後の実際の並び）
ID | 決めること | 決める人 | 期限 | 状態 |
|---|---|---|---|---|
I-034 | 3,400テナントの移行を、1回で行うか200社ずつ17回に分けるか | 技術部長 | 2025/6/27 | 完了 |
I-041 | 移行時のサービス停止を、平日深夜に行うか土曜早朝に行うか | カスタマーサクセス部長 | 2025/7/25 | 完了 |
I-048 | 旧基盤の停止時期を、切替完了の何か月後にするか | 技術部長 | 2025/9/12 | 完了 |
I-055 | 移行に失敗した場合、どの時点まで戻すか（切戻しの基準） | 技術部長・CTO | 2025/10/10 | 完了 |
I-063 | 移行対象外とする休眠テナント（412社）の扱い | 営業部長 | 2025/11/14 | 完了 |
件名がすべて「〜か、〜か」または「〜をどうするか」の形になっていることに注目してください。「移行方式について」のような名詞止めは使いません。決めることが書いていない課題は、決まりません。
リスク管理表
ID | リスク | 発生度 | 影響 | 監視する数字 | 対応 |
|---|---|---|---|---|---|
R-02 | 課題管理表が再び形骸化する | 高 | 判断の遅れが全体に波及 | 30日以上未更新の件数（目標3件以下） | 月初に未更新件数を測り、5件を超えたら仕分けをやり直す |
R-06 | 移行中のデータ不整合 | 中 | 顧客データの欠落 | リハーサルでの不一致件数（目標0件） | 本番同等データで3回リハーサルし、件数照合を自動化する |
R-09 | 分割移行の回数が増え、期間内に終わらない | 中 | 切替完了 ＋1か月 | 1回あたりの所要時間（上限60分） | 60分を超えた回が2回続いたら、1回あたりのテナント数を150社に減らす |
R-13 | 顧客への告知が不足し、問い合わせが集中する | 中 | サポート業務の逼迫 | 告知メールの開封率（目標60%以上） | 告知を3回に分け、管理者向けと利用者向けで文面を分ける |
R-02の監視する数字が「30日以上未更新の件数」である点に注目してください。オープン件数ではありません。件数が多いことは問題ではなく、触られないまま残ることが問題だからです。測る数字を間違えると、対策も間違えます。
TODO（課題から切り出した材料集めの例）
内容 | 元の課題 | 担当 | 期限 | 状態 |
|---|---|---|---|---|
一括移行方式での停止時間を検証環境で計測する | I-034 | インフラ担当 | 2025/6/18 | 完了 |
分割移行方式での追加費用を見積る | I-034 | ベンダーPL | 2025/6/18 | 完了 |
停止告知に必要な日数を、利用規約から確認する | I-034 | 法務担当 | 2025/6/13 | 完了 |
休眠テナント412社の最終ログイン日を抽出する | I-063 | 開発担当 | 2025/11/7 | 完了 |
切戻しに必要な時間を、リハーサルで計測する | I-055 | インフラ担当 | 2025/10/3 | 完了 |
■ 振り返りと、自分の現場で使うなら
まず反省点です。
5か月放置した：1月に18件だったものが5月に112件になるまで、誰も「これはおかしい」と言わなかった
最初に「真面目に更新しよう」で済まそうとした：3週間で元に戻った。様式を変えずに運用だけ直そうとしたのが誤りだった
仕分けに5営業日かかった：186件を1件ずつ読む作業。件数が少ないうちにやっていれば1日で済んだ
次に効いた点です。
課題・作業・決定記録を分けた：混ざっていると、どれも回らなくなる
「決める人」を、決められる人に書き換えた：PMが担当の課題は進まない
「判断に必要な材料」の欄を作った：決まらない理由が材料不足だと分かり、作業に落とせる
全件レビューをやめた：期限が今週・来週のものだけにしたら、1件に3分かけられるようになった
測る数字を「未更新件数」にした：オープン件数を減らそうとすると、無理にクローズするようになる
最後に、明日から使える形にまとめます。いまの課題管理表を開いて、次の3つを数えてみてください。
30日以上更新されていない件数：オープン件数の3割を超えていたら、形骸化が始まっています
担当が「PM」「PMO」「全員」になっている件数：これらは「誰も担当していない」と同じ意味です
期限が「随時」「TBD」「順次」になっている件数：期限のない課題は、永遠に残ります
そして、いちばん簡単に始められることを1つ。件名を「〜について」から「〜をどうするか」に書き換えてください。これだけで、その行に何が足りないのかが見えてきます。「移行方式について」では何も分かりませんが、「移行を一括で行うか分割で行うか」と書けば、決める人と、判断に必要な材料が自然に思い浮かびます。