進捗管理表のテンプレートは12列で足りる【2026年版】Excel・スプレッドシートの列設計と記入例

「進捗管理表のテンプレートを探しているが、ダウンロードしても自社に合わず結局作り直している」——プロジェクトを任されたばかりの方から、こうした相談をよく受けます。列が20以上あって誰も全部は埋めない。かといって削ると管理が甘いと言われそうで、どこまで減らしてよいか分からない。テンプレートの数は多いのに、自分の手元で動く1枚にたどり着けない。

結論から言うと、進捗管理表は12列で足ります。ID、タスク名、担当者、状態、予定開始日、期限、実績完了日、進捗、残日、遅延日数、ブロッカー、最終更新日。このうち残日と遅延日数は数式で自動計算し、遅れは条件付き書式で色が付くようにします。ファイルを配るのではなく、列名と記入例をこの記事の本文にそのまま書きますので、Excelでもスプレッドシートでも、見ながら写して作れます。

そして、表の形より難しいのが続け方です。表が形骸化するのは列の設計が悪いからではなく、「誰がいつ更新するか」が決まっていないからです。更新日の列を1本入れて、3営業日以上更新されていない行を自動で目立たせるだけで、表が生きているかどうかが表の中で分かるようになります。

本記事では、12列の設計と記入例、ガントチャート型と一覧型の使い分け、遅延を色で出す条件付き書式4ルールとプルダウンの設定、更新頻度と更新者の決め方と形骸化の対策、スプレッドシートからツールへ移すタイミングと料金、オフショアの開発チームと同じ表を使うときの実務、よくある質問の順に解説します。ツールの料金と機能は2026年9月15日に各公式サイトで直接確認しました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。進捗管理表の相談で最も多いのは「列が足りない」ではありません。「先週の色が今週も同じ」です。この記事を読み終えるころには、自分のプロジェクトで動く1枚と、それが止まらないための取り決めが手元にできているはずです。

進捗管理表の列は12本で足りる——Excel・スプレッドシート共通の列設計と記入例

進捗管理表の目的は、記録を残すことではありません。遅れを今週中に見つけて、手を打つことです。この目的から逆算すると、必要な列は「計画」「実績」「判定」「運用」の4ブロック、合計12本に収まります。ファイルを配る代わりに、列名と記入例をそのまま本文に書きます。Excelでもスプレッドシートでも、この表を見ながら1行目を作れば10分で使えるようになります。

12列の設計表(列・書く内容・入力形式・誰が入れるか)

この12列のうち、市販のテンプレートに入っていないことが多いのがK列(ブロッカー)とL列(最終更新日)です。しかしこの2列こそが、進捗管理表を「報告を写す場所」から「手を打つための道具」に変えます。K列があれば会議で議論すべき行が自動的に絞れますし、L列があれば「更新が止まっていること」自体を色で出せます。

逆に、D列(状態)とH列(進捗)を両方持つのは冗長に見えるかもしれません。しかし状態は集計とフィルタのため、進捗は残作業の量感を伝えるためのもので、役割が違います。状態が「着手中」のまま進捗が25のまま2週間動かない行は、単に着手中の行とは意味が違うためです。

そのまま写せる記入例——問い合わせ管理システムの4行

画面3つ・帳票1つの小規模な問い合わせ管理システムを例にすると、実際の記入はこうなります(基準日は2026年9月15日)。

T-003の行を見てください。状態は「レビュー待ち」で進捗は75、しかし遅延日数が3日立っています。誰かがサボっているのではなく、レビューする側で止まっている。ブロッカー列に相手と依頼日が書いてあるので、定例を待たずに今日その場で片づけられます。T-004は最終更新日が5日前で、こちらは行そのものが放置されている疑いがあります。この2種類の異常を、目で追わずに色で浮かせるのが次章以降の仕掛けです。

数式は2本だけ——残日(I列)と遅延日数(J列)

自動計算する列は2本です。2行目に入れて下までコピーします。Excelでもスプレッドシートでも同じ式が使えます。

• I列(残日): =IF($D2="完了","",NETWORKDAYS(TODAY(),$F2)-1) ——期限までの営業日数を出します。完了した行は空欄にして、残りの行だけに数字が出るようにします。マイナスなら期限を過ぎています
• J列(遅延日数): =IF(OR($D2="完了",$F2>=TODAY()),0,TODAY()-$F2) ——期限超過かつ未完了の行にだけ、超過した日数を出します

土日以外の休みを除きたい場合は、NETWORKDAYS の第3引数に祝日を並べたセル範囲を渡します。ベトナムの開発チームと共有する表なら、日本の祝日とベトナムの祝日を別々のシートに置き、どちらの稼働日で数えるかを最初に決めてください。予定工数と実績工数を足して工数の精度を上げたい場合の考え方は、「工数計算」の記事で扱っています。

WBSとの違い——WBSは「何をやるか」の図、進捗管理表は「どこまで進んだか」の表

ここで、WBSとの関係を整理しておきます。WBS(作業分解構成図)は、プロジェクトの範囲を漏れなく重複なく分解し、1行の意味と工数を固定するための構造の図です。対して進捗管理表は、分解し終わったタスクを時間軸の上で追い、遅れを見つけるための追跡の表です。WBSが「何をやるか」に答え、進捗管理表が「どこまで進んだか」に答えます。作る順番も、WBSが先、進捗管理表が後になります。

したがって列も重なりません。WBS側にはWBS番号・階層・成果物・完了の定義・予定工数といった構造用の列が並び、進捗管理表側には実績完了日・残日・遅延日数・ブロッカー・最終更新日という追跡用の列が並びます。WBSの作り方、分解の粒度、100%ルールについては「WBSテンプレート」の記事で詳しく扱っていますので、まだ分解ができていない方はそちらを先にご覧ください。本記事は、分解した後の話だけをします。

削ってよい列・足してはいけない列——列を増やすほど記入率は下がる

12列でも多いと感じる場合、削ってよいのはE列(予定開始日)とH列(進捗)です。1〜3日の粒度に割れているなら、開始日がなくても期限だけで回ります。進捗の刻みも、状態の5値があれば代用できます。この2列を削れば10列になります。

反対に、足すときに注意が必要なのは「コメント欄」と「備考」です。自由記述の列は、書く人によって粒度が変わり、集計にも判定にも使えません。伝えたいことがブロッカーなら K列に、仕様の確認事項なら別の課題管理表に書いてください。列を増やすほど記入率は下がる、というのが実情です。進捗管理そのものの考え方や、進捗を何で測るか(タスク完了率・出来高・バーンダウン)については「進捗管理とは」の記事にまとめています。

次章では、この12列の表を、ガントチャート型と一覧型のどちらの見た目で持つべきかを整理します。

ガントチャート型と一覧型の使い分け——「何を判断したいか」で形が決まる

進捗管理表を作るとき、多くの方が最初に迷うのが「ガントチャートにすべきか、一覧表でよいか」です。結論から言うと、答える問いが違うので、どちらが優れているという比較には意味がありません。一覧型は「誰の何が、いま何日遅れているか」に答え、ガント型は「全体がいつ終わるか、どこが詰まっているか」に答えます。判断したいことから形を選んでください。

2つの型の比較表(何が見えるか・向く場面・作る手間・限界)

つまり、日々の運用は一覧型、説明はガント型です。どちらか一方しか作れないなら一覧型を選んでください。ガントチャートがなくてもプロジェクトは回りますが、遅れの所在が分からない表では手が打てません。

マスターは一覧型1枚、ガントはそこから生やす——二重管理にしない作り方

最も多い失敗が、一覧表とガントチャートを別ファイルで持ち、両方を手で更新することです。必ずどちらかが古くなり、会議で「どっちが正しいのか」という話になります。マスターは一覧型の1枚だけと決めて、ガントはそこから生やしてください。

Excel・スプレッドシートでの作り方は次のとおりです。一覧型のマスターシートの右側に日付を1日1列で並べ、各セルに「その日がこのタスクの予定期間に入っていれば塗る」という条件付き書式を入れます。式は =AND(N$1>=$E2, N$1<=$F2) の形です(N1に日付、E列に予定開始日、F列に期限がある場合)。実績の帯も重ねたいなら、予定と実績で行を2段にするか、実績側を別の色のルールで上書きします。日付列が横に長くなるので、月単位でシートを分けるか、表示範囲を数か月に絞ってください。

この方法の利点は、帯を手で描かないことです。E列とF列を直せば帯が動くので、更新は一覧型の側だけで完結します。なお、Googleスプレッドシートの上限は1,000万セルまたは18,278列(列ZZZ)なので、日付列を毎日1列足していってもセル数で先に上限に当たることはまずありません。

週次で見るのは一覧型、月次と対外説明はガント型

運用としては、週次の定例では一覧型を「遅延日数の降順」で並べ替えて上から10行だけを見ます。全部は見ません。月次の報告と、発注元や経営層への説明にはガント型を使い、遅れている帯だけを色で示します。見る人が変われば、見せる形も変える。同じデータから2つのビューを作れるようにしておけば、この切り替えに手間はかかりません。表を2枚持ったとたんに転記が発生し、転記が発生したとたんに情報は古くなる。これがガントチャートで失敗する典型です。

遅延を色で出す条件付き書式4ルールと、入力を固定するプルダウン

前章までで表の形は決まりました。ここからは、遅れの判定を人の目に任せないための設定です。行が50を超えると、目視で遅延を探すのは現実的ではなくなります。条件付き書式を4つ入れておけば、表を開いた瞬間に手を打つべき行が浮かび上がります。

条件付き書式の4ルール(数式・色・何を意味するか)

次の4つを、この順番で登録します。順番が重要な理由は後述します。範囲は表全体(A2から最終行のL列まで)、数式はすべて2行目を基準に書き、列だけを $ で固定します。

ルール1を先頭に置くのは、完了した行に赤や黄が付かないようにするためです。Googleスプレッドシートの公式ヘルプでは、ルールはリストに表示されている順序で評価され、最初に真であると評価されたルールでそのセルの書式が決まると明記されています。Excelも同じ考え方で、上にあるルールが優先されます。順番を入れ替えると、完了した行が赤いまま残ります。

ルール4が、前章で触れた「更新が止まっていること」を可視化する仕掛けです。行の中身ではなく、行が触られているかどうかを見ています。青枠が10行並んでいたら、遅れているのはタスクではなく運用のほうです。

色は4色までに抑えてください。赤・黄・グレー・青枠。これ以上増やすと、どの色が緊急なのかが分からなくなり、結局どれも見られなくなります。

Excelとスプレッドシートでの設定手順(公式ヘルプの手順に沿って)

Googleスプレッドシート: 範囲を選択し、[表示形式] → [条件付き書式] をクリックすると右側にツールバーが開きます。[セルの書式設定の条件] で「カスタム数式」を選び、上表の数式を貼り付け、[書式設定のスタイル] で色を選んで [完了]。4つ分を繰り返し、ルールの並びはドラッグ＆ドロップで入れ替えられます。

Excel: [ホーム] → [条件付き書式] → [新しいルール] → 「数式を使用して、書式設定するセルを決定する」を選び、同じ数式を入れます。Microsoftの公式ヘルプでも、論理式(TRUEまたはFALSEを返す式)で書式設定の基準を指定できること、日付を基にした書式設定ができることが案内されています。登録後は [ルールの管理] で並び順を確認してください。

なお TODAY() は開いた日を基準にするため、表を開くたびに色が変わります。これは仕様どおりの動きです。週次の会議で過去の状態を振り返りたい場合は、色ではなくその週の一覧をPDFやシートのコピーで残してください。

状態と担当者はプルダウンで固定する——表記ゆれが集計を壊す

D列(状態)、C列(担当者)、H列(進捗)は、手入力ではなくプルダウン(データの入力規則)にします。「完了」「済」「Done」「かんりょう」が混ざった瞬間に、集計もフィルタも条件付き書式も動かなくなるためです。条件付き書式の数式は $D2="完了" という完全一致で判定しているので、表記ゆれはそのまま判定漏れになります。

Googleスプレッドシートのプルダウンは、既定ではリストにない値を入力するとそのデータが拒否されます。詳細オプションで「警告を表示」に変えればリスト外も入力できますが、進捗管理表では拒否のままにしておくことをおすすめします。入力する側は不便に感じますが、この不便さが表記ゆれを止めます。担当者リストは別シートに置いて参照し、人の出入りがあったらそのシートだけを直す形にしてください。

ここまでで、12列・2つの数式・4つの書式・3つのプルダウンが揃いました。表としては完成です。ここから先は、この表を止めないための話になります。

更新頻度と更新者を決める——表が形骸化する6つの原因と対策

私が進捗管理表の相談を受けるとき、最も多いのは「列が足りない」ではありません。「先週の色が今週も同じ」です。誰も更新していないので赤いままで、赤が背景になっている。表が形骸化するのは列の設計が悪いからではなく、誰がいつ更新するかが決まっていないからです。ここを1行で決めるだけで、同じ表が動き出します。

更新ルールは4項目で決まる(誰が・いつまでに・どの列を・見るのは誰か)

決めるのは次の4つだけです。プロジェクトの開始時に、表の1行目の上か別シートに書いて共有してください。

このうち効くのは3つ目です。触る列を5つに限定すると、担当者の負担は1行あたり10秒程度になります。「進捗管理表の更新に30分かかる」という状態は、担当者に表全体の面倒を見させている証拠です。誰がどの列を持つかは、プロジェクトの体制と一致している必要があります。役割と報告線の描き方は「プロジェクト体制図」の記事で扱っています。

複数人・複数ベンダーが同じ表を触るときの5つのルール

社内の複数部署、協力会社、オフショアの開発チームが1枚の表を共有する場合、次の5つを最初に通達してください。

1. 表は1枚に統一する。 ベンダーごとに自社ツールで管理していても、この表への転記は各社の担当者が行う。発注側が集めて転記する運用にすると、更新の遅れが発注側の作業量として跳ね返る
2. 自分の行以外は編集しない。 Excelならシートの保護で編集可能なセル範囲を指定し、スプレッドシートなら範囲を指定して編集権限を担当者に限定する。列の追加・削除は管理者のみ
3. 完了の定義を1行で書いて全社に配る。 「レビュー済み」なのか「テスト済み」なのか「リリース済み」なのかが会社ごとに違うと、100%の意味が揃わない
4. 他社の行を直したくなったら、K列(ブロッカー)に書く。 直接直さない。誰が何を待っているかが残り、会議で議論すべき行がそのまま抽出できる
5. 更新の証跡を残す。 Googleスプレッドシートには版履歴があり、以前の版の表示・復元のほか、特定のセルを誰が変更したかを確認できます。ただし編集権限のないユーザーは変更履歴を表示できないため、閲覧のみの関係者に経緯を見せたい場合は、週次でシートのコピーを名前付きの版として残すのが確実です

2番目のセル保護は、性悪説ではなく事故防止です。共有した表で最も多い事故は、行の並べ替えやフィルタ操作で他人の行のデータがずれることです。A列のIDを固定の通番にしておくのは、このずれに気づけるようにするためでもあります。

形骸化する6つの原因と対策(一覧表)

このうち5番が最も見落とされます。「遅れている行が赤い」ことより「そもそも更新されていない」ことのほうが実害が大きいのですが、多くの表はそれを検知できません。更新日の列を1本足すだけで防げます。

なお、遅れが報告されない心理的・組織的な背景(悪い知らせほど上がってこない、進捗率が90%で止まるなど)については、「進捗管理とは」の記事で構造から解説しています。表の設計でできることには限りがあり、ここで書いたのはあくまで表の側の対策です。自社の進捗管理表は、いま何日前の情報で議論されているでしょうか。

スプレッドシートからツールへ移すタイミング——5つのサインと、料金・課金単位の違い

表で回らない運用は、ツールを入れても回りません。一方で、表では越えられない限界もあります。移行の判断は「ツールが高機能かどうか」ではなく、いま自分の表が何に詰まっているかで決めてください。

移行を検討する5つのサイン

次の5つのうち2つ以上が当てはまったら、移行を検討する段階です。

1. 行が300を超えた。 並べ替えとフィルタで目的の行にたどり着くまでに時間がかかり、全体像が頭に入らなくなる
2. 同時編集の競合が週1回以上起きている。 誰かの入力が消える、フィルタ操作が他の人の画面に影響する、といった事故が日常化している
3. 「最新版はどれか」という会話が発生している。 ファイルがメールで往復しているなら、これは表の問題ではなく共有方法の問題で、共有ドライブへの移行だけで解決することもある
4. 成果物と紐づけたい。 どのコミットやプルリクエストでそのタスクが終わったのかを追いたい。ここは表では手当てできない
5. 社外と共有する範囲を分けたい。 協力会社に見せる行と見せない行が混在しており、シートを分けるたびに転記が発生している

逆に、行が100以下で、更新者が5名以下で、成果物との紐付けが不要なら、まだ表で足ります。ツールの導入と教育にかかる時間のほうが高くつく、というのが実情です。

Backlog・Jira・Notion・Google Workspaceの料金と課金単位(2026年9月15日に各公式サイトで確認)

ランキングは付けません。課金単位が違うことが、人数が増えたときの総額を決めます。次の表は2026年9月15日に各社の公式料金ページで直接確認した内容です。料金は改定されるため、検討時は必ず最新のページをご確認ください。

課金単位の違いは具体的にこう効きます。20名で使う場合、ユーザー単位のツールは人数分の月額がかかりますが、Backlogのスタンダード以上はユーザー数が無制限のプランなので人数が増えても月額は変わりません。逆に5名以下の小さなチームなら、ユーザー単位のほうが安く収まります。協力会社の担当者にもアカウントを配るかどうかで人数は大きく動くので、最大何名が触るかを先に決めてから料金を比べてください。

機能面では、ガントチャートがBacklogのスタンダードプラン以上であること(スターターには含まれない)は、見落とすと選定をやり直すことになります。Backlogのガントチャートは、ドラッグ＆ドロップで開始日・期限日・担当者を変更でき、状態ごとに色分けされ、Excel形式で出力して参加していないメンバーにも共有できます。

移す順番——表を捨てずに、二重管理の期間を2週間で終わらせる

移行で最も多い失敗は、表とツールを並行運用したまま半年が過ぎることです。次の順番で、二重管理を2週間で終わらせてください。

1週目は、未完了のタスクだけをツールに登録します。完了済みの行は移しません。記録として表のファイルをそのまま残せば足ります。2週目は、両方を更新しながらツール側だけで定例を回します。表は見ません。2週目の終わりに表を読み取り専用にして、以降の更新をツールに一本化します。戻れる状態を残しつつ、見る場所を先に移すのがコツです。列の対応付け(状態→ステータス、期限→期日、ブロッカー→コメントまたはラベル)を1枚のメモにしておくと、途中で参加した人が迷いません。

オフショアの開発チームと同じ進捗管理表を使う——時差2時間での更新タイミングと、日本人PMが担う列

ここまで書いてきた12列の表は、海外の開発チームと共有する場合も基本は変わりません。変わるのは更新の時刻と、誰がどの列を持つかの2点だけです。当社はホーチミンに拠点があり、日本との時差は2時間です。この2時間をどう使うかで、表の鮮度が決まります。

更新はベトナム時間18時まで、確認は日本時間の翌朝——時差2時間の使い方

ベトナムの標準的な終業は現地時間の18時前後で、これは日本時間の20時にあたります。担当者が終業前にD列(状態)・H列(進捗)・K列(ブロッカー)・L列(最終更新日)を入れておけば、日本側は翌朝の始業時にその日の最新の状態を見られます。時差が2時間しかないので、夕方の入力が翌朝に間に合うわけです。欧米やインドとの開発でよく問題になる「確認したいときに相手が寝ている」という状況は、ベトナムではほとんど起きません。午前中に日本側が気づいたブロッカーは、ベトナム側の午前中(日本時間の10時〜)にそのまま相談できます。時差の詳しい早見表と会議に向く時間帯は「ベトナム 時差」の記事にまとめています。

重要なのは、表を2枚持たないことです。日本側が自社フォーマットで、開発側が別のツールで管理すると、必ず転記が発生します。転記された時点で情報は前日のものになり、2時間の優位が消えます。当社では、お客様が既にお使いの表やツールがあればそちらに開発チームが直接入力する形を取っています。

日本人PMが担う列は「状態の翻訳」ではなくブロッカーの解消

日本人PMの役割を「ベトナム側の報告を日本語に直して転記すること」だと考えると、PMは翻訳と転記の作業員になります。当社の体制パターンA(日本人PM/BrSE+エンジニア)で日本人PMが実際に持つのは、K列(ブロッカー)です。朝一番にブロッカー列だけを縦に読み、仕様の確認待ち・レビュー待ち・環境の不備といった詰まりを、その日のうちに解消しにいきます。

状態と進捗は担当エンジニア本人が入れます。前章の「代理入力を認めない」というルールは、オフショアでも同じです。介護記録SaaS「CareViewer」の開発では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次の定例ではお客様に優先順位と「何をもって完成とするか」を決めていただき、日々の状態更新は各担当が入れています。加えて当社ではGitのプルリクエストによるコードレビューを標準化しているため、実績完了日の裏付けがレビューの記録として残ります。自己申告だけに頼らない形です。日本人PMの必要性と役割分担については「オフショア開発 日本人PM」の記事で詳しく扱っています。

列名の日英併記と、テト期間の扱い

実務上の細かい工夫を2つだけ。1つは列名の日英併記です。B列を「タスク名 / Task」、K列を「ブロッカー / Blocker」のように併記し、D列のプルダウンも「レビュー待ち / In Review」のように両方を入れておきます。翻訳の手間ではなく、表記ゆれを防ぐためです。本文は日本語で書いてかまいません。

もう1つは休みの扱いです。ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)で、2026年のテト(旧正月)休暇は2月14日から22日にあたります。I列(残日)のNETWORKDAYS関数に渡す祝日リストに、日本の祝日とベトナムの祝日を両方入れておかないと、テト期間をまたぐタスクの残日が実態より多く出ます。期限をテトの直後に置くと、休み明けの初日に間に合わせる前提になってしまうので、そこは計画の段階で1週間ずらしてください。

なお当社は2,000名以上のIT人財データベースから直接アサインしており、日本人PMをフロントに置くパターンAで、最小構成は2〜3人月で月額約80万円からです。単価は実務3年目安で1,500USD(約22.5万円、1USD=150円換算目安)から公開しています。進捗管理の形はお客様の既存の運用に合わせますので、既に動いている表があればそのままお使いいただけます。

進捗管理表のテンプレートに関するよくある質問

進捗管理表を作るときに、相談の場で繰り返し聞かれる質問を5つにまとめました。列の持ち方、進捗率の刻み、更新の担当、ExcelとGoogleスプレッドシートの選び分け、ツールへ移す判断の5つで、いずれも社内で意見が割れやすい論点です。社内で表の形を決めるときの説明材料にもお使いください。

Q1. WBSと進捗管理表は1枚にまとめてもよいですか?

小規模(タスク50行以下)なら1枚でかまいません。WBSの列の右側に、状態・実績完了日・遅延日数・ブロッカー・最終更新日を足す形です。ただし規模が大きくなると、分解の構造を見たい場面と進捗を追いたい場面で必要な列が違ってくるため、シートを分けてID列で紐づけるほうが扱いやすくなります。

Q2. 進捗率は何%刻みにすべきですか?

0・25・50・75・100の5段階で十分です。1%刻みや10%刻みにしても、担当者の自己申告の精度がそれに追いついていません。細かくすると「毎回5%ずつ増える行」が生まれ、かえって遅れが見えなくなります。刻みを粗くするほど、状態(未着手・着手中・レビュー待ち・完了・保留)のほうで判断するようになります。

Q3. 更新はPMがまとめてやったほうが速いのでは?

速いですが、遅れが見えなくなります。PMが代理入力すると、情報はPMが聞き取った時点のものになり、聞き漏らした遅れは表に現れません。担当者本人が1行10秒で入れられるよう、触る列を5つに絞ってください。それでも入力されないなら、タスクの粒度が大きすぎる可能性を先に疑ってください。

Q4. ExcelとGoogleスプレッドシート、どちらがよいですか?

複数人で同時に触るならスプレッドシートです。範囲ごとの編集権限、版履歴、リアルタイムの共同編集が標準で使えます。Excelは、社外に出せないデータを扱う場合や、既存の社内フォーマットとの互換が必要な場合に選びます。数式と条件付き書式は本記事で示したものがどちらでも動きます。

Q5. ツールへの移行は、どの時点で判断すべきですか?

行が300を超えた、同時編集の競合が週1回以上ある、最新版がどれか分からない、成果物と紐づけたい、社外との共有範囲を分けたい——この5つのうち2つ以上が当てはまった時点。

まとめ: 12列に絞り、判定は数式と色に任せ、更新の担当と時刻を決める

進捗管理表に必要な列は12本です。ID、タスク名、担当者、状態、予定開始日、期限、実績完了日、進捗、残日、遅延日数、ブロッカー、最終更新日。このうち残日と遅延日数は数式で自動計算し、期限超過・期限間近・完了・更新の放置の4つを条件付き書式で色に出します。状態と担当者はプルダウンで固定します。マスターは一覧型の1枚だけを持ち、ガントチャートはそこから生やして二重管理を避けてください。

そのうえで決めるのは4つだけです。誰が(行の担当者本人)、いつまでに(毎営業日の終業前など時刻で)、どの列を(状態・実績完了日・進捗・ブロッカー・最終更新日の5列)、見るのは誰か(遅れたときに順番と日程を決める個人名)。表が形骸化するのは列の設計ではなく、この4つが決まっていないからです。最終更新日の列と「3営業日以上更新がない行に青枠」のルールを入れておけば、表が止まったこと自体が表の中で分かります。行が300を超えた、同時編集の競合が週1回以上ある、成果物と紐づけたい——こうしたサインが2つ以上出たら、ツールへの移行を検討してください。課金単位がユーザー単位かスペース単位かで、人数が増えたときの総額が変わります。

オフショアの開発チームと同じ表を使う場合も、形は変わりません。当社の場合、時差は2時間なので、ベトナム時間18時までの更新が日本時間の翌朝に間に合います。日本人PMが持つのはブロッカー列で、状態と進捗は担当エンジニア本人が入れます。進捗管理の考え方と測る単位は進捗管理とは、その前段である作業分解とWBSの作り方はWBSテンプレートもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、進捗の見え方を含めた体制のご提案と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。