--- title: "課題管理表の作り方：必要な項目とステータス設計、Excelで破綻する条件" url: "https://www.issoh.co.jp/column/details/19764/" published: 2026-11-14 updated: 2026-11-14 categories: ["DX"] publisher: "株式会社一創" --- # 課題管理表の作り方：必要な項目とステータス設計、Excelで破綻する条件 課題管理表は、プロジェクトの途中で起きた「解決しないと先に進めない問題」を1行1課題で記録し、担当・期限・状態・完了条件を関係者で共有する一覧です。この記事では、課題管理表に最初から入れる12列と記入例、「対応済み」と「完了」を分けるステータスの決め方、Excelで作る手順と期限超過を自動で出す数式をまとめました。後半では、Excelの課題管理表が共同編集・件数・経緯の記録で破綻する条件と、課題管理ツールや業務システムへ移す判断を、発注者と受託側の権限分担まで含めて整理します。 ## まとめ：課題管理表は1行1課題と完了の判定者を決めれば回り始める 課題管理表に必要な列は、番号・件名・内容・影響・起票者・起票日・担当者・期限・優先度・ステータス・対応内容・完了日の12列で足ります。列を増やすより先に決めるべきなのは、どの問題を課題管理表に載せるかという起票の基準と、誰が「完了」に変えてよいかという判定者です。 ステータスは「対応中」「確認待ち」「完了」を分けてください。担当者が対応を終えた時点で完了にすると、起票者が納得していない課題まで閉じられ、同じ問題が別の番号で再起票されます。 Excelで回せるのは、関係者が1社内に閉じ、未完了の課題が数十件に収まる間です。社外の受託先と同じファイルを編集する、未完了が50件を超える、経緯を後から監査で問われる、のいずれかに当たったら、Backlog・Redmine・Jira などの課題管理ツールへ移す時期に来ています。 ## 課題管理表とは：タスク・リスク・不具合・変更要求と分ける起票の基準 ### 課題管理表の定義とデジタル庁の標準ガイドラインにおける課題管理の位置付け 課題とは、プロジェクトの進行中にすでに発生していて、誰かが手を打たないと目標・期日・品質のいずれかに影響が出る問題を指します。課題管理表はその一覧で、発生から解決までの経緯を1か所に残す役割を持ちます。 政府情報システムの整備ルールである[DS-100 デジタル・ガバメント推進標準ガイドライン（2026年6月12日決定）](https://www.digital.go.jp/assets/contents/node/basic%5Fpage/field%5Fref%5Fresources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715%5Fresources%5Fstandard%5Fguidelines%5Fguideline%5F01.pdf)は、第3編第2章でプロジェクト管理要領に書く事項の一つとして「課題管理」を挙げ、「プロジェクトの遂行上発生する解決すべき課題について、その発生時の報告先、報告内容、課題の管理手法等を記載する」と定めています。設計・開発や運用・保守の実施計画にも同じ名前の項目があり、課題管理は工程ごとに引き継がれる管理領域として扱われています。 民間の案件にこの規程が適用されるわけではありません。ただ「報告先」「報告内容」「管理手法」の3点を先に決めるという構造は、課題管理表の列と運用ルールを設計するときの下敷きになります。 ### 課題・タスク・リスクの違いを「もう起きたか」と「誰の作業か」で見分ける基準 課題管理表が膨らむ最大の原因は、タスクやリスクが混ざることです。見分ける軸は2つあります。 | 種類 | もう起きたか | 対応の中身 | 載せる表 | | --- | -------- | ------------------ | ---------- | | 課題 | 起きている | 原因を調べて解決策を決める | 課題管理表 | | リスク | まだ起きていない | 発生確率と影響を見て予防・備えを打つ | リスク管理表 | | タスク | 問題ではない | やることが決まっている作業を進める | WBS・タスク管理表 | DS-100 もリスク管理を「プロジェクトの遂行を阻害する可能性のあるリスク」、課題管理を「発生する解決すべき課題」と書き分けています。リスクが顕在化したら、[リスク管理表](https://www.issoh.co.jp/column/details/19780/)の行を閉じて課題管理表へ起票し直す、という流れにしておくと二重管理になりません。タスク管理やToDoとの線引きは[プロジェクト管理とタスク管理の違いとToDo・課題管理の区別](https://www.issoh.co.jp/column/details/11042/)で詳しく扱っています。 ### 不具合と変更要求を課題管理表に混ぜたときに起きる件数の膨張と分け方 システム開発では、テスト工程で見つかった不具合と、発注者から出る仕様の変更要求も課題管理表に流れ込みがちです。結合テストの不具合は数百件に達することもあり、同じ表に入れると本来の課題が埋もれます。 不具合は不具合管理表（バグ票）、変更要求は変更管理表で扱い、課題管理表には「不具合が多すぎてリリース日に間に合わない」「変更要求の費用負担で合意できない」のように、個別の不具合や変更をまとめて判断が要る段階になったものだけを起票します。変更要求の受付から承認、変更契約までの流れと変更管理台帳の列は[スコープクリープとは：原因と防ぎ方、要件追加を変更管理と追加見積で扱う契約の要点](https://www.issoh.co.jp/column/details/19768/)で整理しています。テスト工程ごとに何を記録するかは[システム開発のテスト工程とV字モデル、発注者が見る判断軸](https://www.issoh.co.jp/column/details/13445/)を参照してください。 ## 課題管理表に入れる項目：起票から完了判定まで12列の設計と記入例 ### 最初から入れる12列の一覧と、起票時に空欄を許す列と許さない列の区別 市販や無料のテンプレートを見比べると、列の数は7〜12列程度に収まります。システム開発の課題管理なら、次の12列で始めて足りない列を後から足す方が、使われない列を抱えるより運用が続きます。 | 列 | 書く内容 | 起票時 | | ----- | ------------ | ---------- | | 番号 | 連番。削除せず欠番にする | 必須 | | 件名 | 事象を一文で | 必須 | | 内容・影響 | 何が起き、何が止まるか | 必須 | | 起票者 | 完了を判定する人を兼ねる | 必須 | | 起票日 | 発生または発見した日 | 必須 | | 担当者 | 解決まで責任を持つ1人 | 空欄可（会議で決定） | | 期限 | 解決策を決める日 | 空欄可（会議で決定） | | 優先度 | 高・中・低 | 必須 | | ステータス | 未着手〜完了の5状態 | 必須（未着手） | | 対応内容 | 決めた解決策と根拠 | 空欄 | | 最終更新日 | 滞留日数の計算に使う | 必須 | | 完了日 | 判定者が完了にした日 | 空欄 | 担当者と期限を起票時の必須にしないのは、起票のハードルを下げるためです。誰でも気づいた時点で書けるようにし、担当と期限は週次の定例で決めます。逆に、件名と影響が空欄の課題は定例で議論できないので、起票時点で必須にします。 ### 課題の件名と内容の書き方：事象と影響を一文で書く記入例と悪い例 件名は、表を一覧したときに中身が分かる長さで書きます。悪い例は「在庫データの件」「A社確認事項」のような名詞だけの件名で、開かないと何が問題か分かりません。 良い例は「旧システムの在庫データに品目コードの重複が約300件あり、移行リハーサルが止まっている」です。事象（重複がある）、規模（約300件）、影響（リハーサルが止まる）が一文に入っています。内容欄には、発見した経緯、仮の原因、判断に必要な情報（誰に何を確認すれば決まるか）を書き、推測は推測と明記します。 1行に複数の問題を書かないことも決めておいてください。「重複の解消と、移行手順書の修正」を1行にすると、片方だけ終わった時点でステータスを決められなくなります。 ### 優先度と期限の決め方：影響範囲と後工程の着手日から逆算する基準 優先度は、起票者の感覚で付けると全件が「高」になります。影響範囲と時期の2軸で機械的に決める基準を、プロジェクトの最初に合意しておきます。 実務では、「マイルストーン（稼働日・テスト開始日など）が動く」なら高、「特定の機能や部署だけに影響し、回避策がある」なら中、「品質に影響しない改善」なら低、の3段階で足ります。期限は課題そのものの解決日ではなく、解決策を決める日として設定します。後工程の着手日から、対応に要する日数を引いた日が期限です。移行リハーサルが12月10日で、データ修正に5営業日かかるなら、方針決定の期限は12月3日になります。 ## ステータスの定義と遷移：「対応済み」と「完了」を分けて判定者を決める運用 ### 未着手・対応中・確認待ち・完了・保留の5状態と、それぞれの入口と出口の条件 ステータスの名前だけ決めて、状態を変える条件を決めないチームが多く見られます。各状態に「誰が、何をしたら次へ進めるか」を書いておくと、表記揺れと勝手なクローズが止まります。 | ステータス | 入る条件 | 変えてよい人 | | ----- | ------------- | ----------- | | 未着手 | 起票された | 起票者 | | 対応中 | 担当者と期限が決まった | 担当者 | | 確認待ち | 担当者が解決策を実施した | 担当者 | | 完了 | 起票者が解決を確認した | 起票者または管理責任者 | | 保留 | 今回のスコープ外と合意した | 管理責任者 | 要は「確認待ち」の存在です。担当者は対応を終えたら確認待ちにし、完了に変えるのは問題を挙げた側に限ります。Backlog の標準ステータスが「処理済み」と「完了」を別に持っているのも、作業の終了と確認の終了を分けるためです。 ### Redmineの「Issue closed」フラグに学ぶ、完了扱いの状態を複数持つ設計 保留や取り下げを「完了」と同じ扱いにするか、未完了として数えるか。この区分で変わるのが、定例で報告する残件数です。[Redmine の公式ガイド（Issue tracking setup）](https://www.redmine.org/projects/redmine/wiki/RedmineIssueTrackingSetup)では、ステータスごとに「Issue closed」のチェックを付けられ、完了扱いの状態は複数設定できると説明されています。同じページには、ロールとトラッカーの組み合わせごとに、どの状態からどの状態へ変えてよいかをワークフローとして定義する仕組みも書かれています。 Excelの課題管理表でも考え方は同じです。「完了」「保留」「取り下げ」を完了扱い、それ以外を未完了と決めておき、残件の集計式にはこの区分を使います。保留を未完了に含めると、スコープ外と合意した課題がいつまでも残件として報告され、定例のたびに同じ説明が繰り返されます。 ### 期限超過と放置課題の扱い：経過日数で定例会議に上げるエスカレーション基準 期限を過ぎた課題よりも厄介なのは、期限が空欄のまま更新されない課題です。最終更新日から14日以上動いていない課題は、ステータスに関係なく定例の議題に上げる、と決めておきます。 エスカレーションの基準も数字で持ちます。期限を1回延ばした課題は担当者の判断で可、2回目の延長はPMの承認、マイルストーンに影響する課題は発注者側の責任者まで報告、という3段構えが扱いやすい形です。誰がどこまで判断するかは、プロジェクト管理の体制図と一致させてください。体制と管理領域の全体像は[システム開発のプロジェクト管理の進め方と品質・課題・リスク管理](https://www.issoh.co.jp/column/details/15670/)で整理しています。 ## Excelで課題管理表を作る手順：テーブル化・入力規則と期限超過の数式 ### テーブル化と入力規則でステータスと担当者の表記揺れを止める手順 Excelで課題管理表を作るときは、見た目の罫線より先に、データとして集計できる形に整えます。 1. 1行目に12列の見出しを入れ、範囲を選んで「挿入」タブの「テーブル」でテーブル化し、テーブル名を「課題」に変える 2. 別シートに「ステータス」「担当者」「優先度」の選択肢を縦に並べた一覧を作る 3. ステータス列を選び、「データ」タブの「データの入力規則」で「リスト」を指定し、元の値に選択肢の範囲を入れる 4. 担当者・優先度の列にも同じ入力規則を設定する 5. 起票日・期限・最終更新日・完了日の列を日付の表示形式にそろえる 入力規則を入れないと、「対応中」「対応中 」「対応ちゅう」が別の値として数えられ、残件の集計がずれます。担当者名も「田中」「田中（A社）」の揺れが出るので、選択肢から選ばせる形にしてください。タスク管理表の列設計とチェックボックスの作り方は[エクセルのタスク管理表の列設計と期限の色分けの数式](https://www.issoh.co.jp/column/details/19709/)で手順を示しています。 ### 期限超過と滞留日数を自動で出すIF・TODAY関数の数式と条件付き書式 テーブルに「期限超過」「滞留日数」の2列を足し、次の数式を入れます。テーブルの構造化参照を使うと、行が増えても数式を書き直す必要がありません。 ``` 期限超過列： =IF(AND([@ステータス]<>"完了",[@ステータス]<>"保留",[@期限]<>"",[@期限]完了",課題[ステータス],"<>保留") 条件付き書式（行全体を色付け・ルールの種類＝数式を使用）： =$M2="超過" ``` 条件付き書式は、テーブル全体を選んだ状態で「ホーム」タブの「条件付き書式」から「新しいルール」を開き、数式を使って書式設定するセルを決める、を選びます。M列が期限超過列の場合の例で、列の位置に合わせて書き換えてください。滞留日数にも「14以上」の条件で別の色を付けると、定例で議題に上げる課題が一目で分かります。 ## Excelの課題管理表が破綻する条件：同時編集・件数・経緯の記録で見る限界 ### 共同編集が効かないファイルと「共有ブック」の制限が課題管理で招く上書き事故 課題管理表は複数人が同時に書き込む文書なので、Excelの共同編集が効くかどうかで運用が分かれます。Microsoft の[Office の共同編集のトラブルシューティング](https://support.microsoft.com/ja-jp/office/troubleshoot-co-authoring-in-office)は、共同編集できない条件として、パスワード保護で暗号化されたファイル、最新形式以外のファイル、最終版に設定されたファイル、チェックアウトされたファイル、SharePoint のオンプレミスサイトに置いたブックなどを挙げています。 社内のファイルサーバーに .xls や暗号化付きの課題管理表を置いている場合、誰かが開いている間は他の人が読み取り専用になり、手元のコピーに書いて後で貼り戻す運用が始まります。この貼り戻しで、他人が更新した行を古い内容で上書きする事故が起きます。 古い「共有ブック」機能で逃げる手もありますが、[共有ブック機能について](https://support.microsoft.com/ja-jp/excel/about-the-shared-workbook-feature)のページは、この機能が共同編集に置き換えられたと説明し、共有ブックではテーブルの作成や条件付き書式が使えないとしています。前章のテーブル化と期限超過の色付けが使えなくなるので、課題管理表には向きません。 ### 未完了50件・関係者10人を超えたときに起きる定例の長期化と見落とし Excelの行数の上限に達するより、ずっと手前で人の側が限界を迎えます。週1回・1時間の定例で1件に1分かけると、扱えるのは50件前後です。未完了の課題がこれを超えると全件を読み上げられなくなり、フィルタで絞った一部だけが議論される状態になります。 関係者が10人を超えると、担当者が自分の課題を探すためにフィルタを掛けたまま保存し、次に開いた人には一部の行しか見えない、という事故も増えます。期限が近づいた課題を担当者に知らせる通知もExcel単体では持てないので、PMが毎朝表を開いて個別に連絡する手作業が発生します。 この2つの数字は、ツールへの移行を検討し始める目安です。どちらかを超えた時点で、次の章の判断表に当てはめてください。 ### コメント欄に経緯を追記する運用で、誰がいつ何を決めたか分からなくなる理由 Excelの課題管理表では、対応内容の列に「11/5 A社確認中→11/8 方針変更、B案で進める」と日付付きで追記していく運用がよく見られます。この書き方には2つの弱点があります。 1つは、誰が書いたかが残らないことです。ファイルの更新者はブック単位でしか分からず、セルの1行ずつの書き手は追えません。もう1つは、上書きや削除で過去の判断が消えても気づけないことです。 受託開発で費用負担や仕様の解釈を巡って意見が分かれたとき、拠り所になるのは「いつ、誰の判断で、その方針に決めたか」の記録です。経緯を監査や契約の協議で問われる可能性がある案件では、変更履歴が自動で残る課題管理ツールに移すべきです。 ## 課題管理ツールとシステム化の判断：Excel継続・専用ツール・業務システム組込みの分岐 ### Excelのまま続けてよい案件と、ツールへ移すべき案件を分ける判断表 移行するかどうかは、ツールの機能比較より先に、案件の条件で決まります。 | 条件 | Excel継続 | 課題管理ツールへ移行 | | ------ | ----------- | -------------- | | 関係者 | 社内のみ・10人以下 | 社外の受託先を含む・10人超 | | 未完了の課題 | 常に数十件以内 | 50件を超える時期がある | | 期間 | 3か月程度まで | 半年以上・運用保守へ続く | | 経緯の記録 | 社内の振り返り用 | 契約・監査で説明が要る | | 通知 | 定例で確認すれば足りる | 期限前の自動通知が要る | 1つでも右側に当てはまれば移行を検討し、2つ以上なら移行を前提に計画します。社内の業務改善で、3か月ほどの短期プロジェクトなら、Excelのままで困ることはまずありません。ツールの月額費用と学習の手間をかける理由がないので、ここで無理に移す必要はありません。 ### Backlog・Redmine・Jiraへ移すときに先に決めるステータスと権限の設計 ツールへ移すときに失敗しやすいのは、Excelで曖昧だったルールをそのまま持ち込むことです。ツールを入れる前に、ステータスの一覧と、誰がどの状態へ変えてよいかの表を作っておきます。 Redmine はロールごとのワークフローで、Jira はワークフローの遷移条件で、「完了に変えられるのは報告者とPMだけ」といった制約を設定できます。Excelでは口頭のルールだった完了判定者を、ツールの設定で強制できる点が移行の最大の利点です。Jira の作業項目とボードの基本は[Jiraの使い方とエピックの使い分け](https://www.issoh.co.jp/tech/details/7859/)で解説しています。 受発注・在庫・生産管理のように業務そのものに課題が紐づく場合は、課題管理ツールを別に立てるより、業務システムの画面に課題の起票と状態管理を組み込む方が二重入力を避けられます。どちらを選ぶかは、課題を起票する人が普段どの画面で仕事をしているかで判断します。 ### 発注者と受託側で1つの課題管理表を共有するときの起票権限とクローズ権限 システム開発を外注すると、課題管理表を発注者と受託側のどちらが持つかが問題になります。受託側のツールに発注者のアカウントを発行して共有する形が多いものの、権限を決めずに始めると、受託側が発注者の挙げた課題を「対応済み」のまま完了にする、発注者が受託側の内部課題まで見えて混乱する、といった行き違いが起きます。 決めておくべきなのは3点です。発注者が起票した課題を完了にできるのは発注者だけにする。受託側の内部作業の課題は別プロジェクトに分け、共有の表には発注者の判断が要るものだけを載せる。費用や納期に影響する課題は、定例の議事録と課題番号を紐づけて合意を記録する。 受託側が作った課題管理の仕組みに乗るだけでは、発注者側の判断が追いつかないこともあります。一創の[要件定義・RFP作成・PMO支援](https://www.issoh.co.jp/service/system/pmo/)では、開発を請けない前提で発注者の側に立ち、課題管理のルール作りや定例での課題の読み解きを支援しています。 ## よくある質問：課題管理表のテンプレート・WBSやリスク管理表との関係 課題管理表を作るときによく寄せられる質問に、本文の内容を踏まえて答えます。 ### 課題管理表とWBSは何が違いますか？ WBSは、プロジェクトでやるべき作業を分解し、担当と期日を割り当てた計画です。課題管理表は、その計画どおりに進めようとしたときに起きた問題の一覧です。WBSの作業は最初から予定されていますが、課題は予定外に発生します。課題の解決策として新しい作業が必要になったら、課題管理表の対応内容に方針を書き、作業そのものはWBSに追加して進捗を管理します。両方に同じ作業を書くと更新漏れが起きるので、役割を分けてください。 ### 課題管理表とリスク管理表は1つにまとめてもよいですか？ 関係者が少ない短期の案件なら、「種別」列で課題とリスクを分けて1つの表にしても運用は可能です。ただ、リスクは発生確率と影響度、予防策と発生時の対応策を持つのに対し、課題は担当・期限・解決策を持つため、必要な列が違います。半年以上の案件や社外の受託先が入る案件では、表を分け、リスクが顕在化したら課題管理表へ起票し直す運用にした方が、どちらの表も読みやすく保てます。リスク管理表に入れる項目と発生確率・影響度の評価基準は[リスク管理表の作り方を整理した記事](https://www.issoh.co.jp/column/details/19780/)で解説しています。 ### 課題管理表のテンプレートは無料のものでも使えますか？ 無料テンプレートでも十分に使えます。確かめたいのは、ステータスに「確認待ち」に当たる状態があるか、起票者と担当者が別の列になっているか、最終更新日の列があるかの3点です。この3つが無いテンプレートは、完了の判定者と放置課題の検出ができません。列名を自社の言葉に合わせて書き換え、入力規則で選択肢を固定してから使い始めてください。 ### Googleスプレッドシートで課題管理表を作るときの注意点は？ Googleスプレッドシートは標準で複数人の同時編集ができ、セルごとの編集履歴も右クリックから確認できるため、Excelのファイルサーバー運用より上書き事故は起きにくくなります。注意すべきは共有範囲です。リンクを知っている全員が編集できる設定のまま受託先や協力会社に渡すと、意図しない人が課題を書き換えられます。共有はアカウント単位で行い、ステータス列にはプルダウンの入力規則を設定してください。 ### 課題管理表は誰が更新すべきですか？ 起票は気づいた人なら誰でも、ステータスと対応内容の更新は担当者、完了への変更は起票者または管理責任者、と分けるのが基本です。表全体の管理者は1人決め、週次の定例の前に、期限超過と滞留日数の長い課題を抜き出して議題にします。管理者が更新まで代行すると、担当者が表を見なくなり、管理者が辞めた時点で表が止まります。 ## 関連記事 - [エクセルでプロジェクト管理する方法｜管理表・ガントチャートの数式と複数案件の一元管理、無料テンプレートの注意点](https://www.issoh.co.jp/column/details/11193/)：課題管理表と並べて使う進捗管理表とガントチャートの作り方 - [PMOとは？役割・種類とPMとの違い｜システム開発でPMOを外部に任せる判断](https://www.issoh.co.jp/column/details/19156/)：課題の集約と標準化を担うPMOの役割 - [システム開発の品質管理とは？工程別レビュー・テスト管理とメトリクス判定の手順](https://www.issoh.co.jp/tech/details/15319/)：課題管理表と切り分けて扱う不具合とテストの管理 - [システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】](https://www.issoh.co.jp/column/details/15670/)：課題管理を含む管理領域の全体像 - [プロジェクト管理とタスク管理の違いとは？ToDo・課題管理との区別とWBSでのつなぎ方](https://www.issoh.co.jp/column/details/11042/)：課題とタスク・ToDoの線引き --- 出典: [課題管理表の作り方：必要な項目とステータス設計、Excelで破綻する条件]()（株式会社一創）