タスク管理のエクセルテンプレート｜列を増やしすぎない決め方
「タスク管理 エクセル テンプレート」で検索するとき、本当にほしいのは完成した表そのものではないことが多いはずです。ダウンロードした表はどれも項目が丁寧に用意されていて、最初の1週間はきれいに埋まります。困るのはその後で、埋まらない列が少しずつ増え、進捗の欄が古いまま放置され、結局は口頭とチャットで確認し直すことになります。この記事では、表の見た目を整える話ではなく、列をどこまで置いてどこで止めるかという設計の話をします。最初に置く列、あとから足したくなる列、足すと更新されなくなる列を分けて考えると、テンプレートを選ぶ基準も、自分たちで作るときの手順も決まります。
タスク表が表計算ソフトで作られ続ける理由
チームの進行管理を専用ツールに移した会社でも、気づくと誰かが表計算ソフトで別の一覧を作っています。これは道具の選定を間違えたからではなく、表計算ソフトが持っている強さが本物だからです。批判から入ると設計を誤るので、まず何が優れているのかを正確に数えます。
白紙から30分で形にできる速さ
表計算ソフトの最大の強みは、思いついた構造をその場で試せることです。列を足す、順番を入れ替える、行を挿入する、といった操作に学習コストがほとんどかかりません。チームの誰に見せても「これは何の表か」がすぐ伝わり、説明のための資料を別に作る必要もありません。新しい案件が立ち上がって30分で暫定の管理表がいる、という場面で表計算ソフトを超える速さを出せる道具はそう多くありません。
さらに、社内のほぼ全員が使い方を知っています。ツールを新しく入れると、まず操作を覚えてもらうところから始まりますが、表計算ソフトにはその壁がありません。進行を預かる立場からすると、この「説明しなくてよい」という性質は想像以上に大きい利点です。取引先に途中経過を渡すときも、ファイルをそのまま送れば読んでもらえます。
計算に強いことも忘れてはいけません。工数の合計、残タスクの件数、担当ごとの負荷、どれも数式で出せます。集計の考え方を自分で組み立てられるので、他の道具では用意されていない切り口の数字も作れます。管理表の役割の一部が「数える」ことである以上、この点は捨てがたい価値です。
それでも詰まるのは「同時に触れない」ことと「更新されない」こと
強さを認めたうえで、実際に詰まる場所は毎回ほぼ同じです。1つ目は、同じファイルを複数人が同時に扱いにくいことです。クラウド上の共同編集を使えば同時編集そのものは可能になりますが、行の並べ替えやフィルタの操作が他の人の画面にも影響する形式では、誰かが整理している間、他の人は落ち着いて見られません。工程表を1人が引き直している間、他の人はその表を見られない、という状態は多くの現場で起きています。
2つ目は、入力してくれる人が増えないことです。表の精度は、担当者が自分で状況を書き込んでくれるかどうかで決まります。ところが列が多い表ほど、担当者にとっては「何を書けばいいのか分からない欄」が増えます。分からない欄があると、その行全体に手をつけなくなります。入力する人が増えないと、進捗の表はすぐ嘘になります。そして嘘になった表は、とりまとめる人が会議前に手作業で埋め直すことになり、管理表が仕事を減らすどころか増やします。
この2つの詰まりは、テンプレートの完成度では解決しません。列の設計と運用のルールで、どこまで軽くできるかという話になります。
列を増やしすぎると、3か月後に何が起きるか
列を足す判断は、その瞬間はいつも正しく見えます。「見積工数も入れておこう」「関連する資料のリンクも置こう」「承認者も分かるようにしよう」。どれも必要な情報です。問題は、足したときの負担が足した人ではなく、毎日入力する担当者に回ることです。
埋まらない列が1つあると、表全体の信用が落ちる
20列ある表で、実際に埋まっているのが8列だけ、という状態を考えます。見る側は、どの列が生きていてどの列が死んでいるかを毎回判断しなければなりません。空欄が「まだ決まっていない」なのか「そもそも誰も入れていない」なのかが区別できないからです。この判断が必要になった時点で、表は一次情報として扱えなくなり、結局は担当者に直接聞くことになります。
埋まらない列は、消せばよいと分かっていても消せません。誰かが必要だと言って足した列なので、勝手に削ると角が立ちます。こうして表は膨らみ続け、横スクロールしないと全体が見えない形になり、印刷もできなくなります。現場では、列が増えすぎた表は2週間ほどで更新が止まると言われています。止まった表は誰も直さず、別の場所に新しい一覧が作られて、管理表が二重化します。
列は「情報の置き場所」ではなく「入力の依頼」
設計を誤る原因は、列を情報の置き場所だと考えることにあります。列は置き場所ではなく、担当者への入力依頼です。列を1つ足すことは、全員に対して「毎回これも書いてください」と頼むことと同じ意味を持ちます。30件のタスクがある表に列を1つ足せば、30回の入力が新しく発生します。
この視点に立つと、判断の基準はひとつに絞れます。その列は、誰が、どのタイミングで、迷わずに埋められるか。この3点に答えられない列は、置いた瞬間から空欄になる列です。
公的機関が業務のデジタル化について繰り返し示している考え方を、ひとことに畳むとこうなります。
道具を入れることそのものが目的になると、現場の入力負担だけが増えて情報は集まらない。まず業務の流れを整理し、集める情報を絞ってから、それに合う道具を選ぶ。 参考: chusho.meti.go.jp
列の設計はまさにこの話です。集める情報を絞る作業を飛ばして表を作ると、何を使っても同じところで止まります。
最初に置く列は7つで足りる
タスク表の最小構成として機能するのは、次の7列です。これ以上増やさずに1か月運用してから、足りないものを足す順番にすると失敗しにくくなります。
| 列名 | 入力する人 | 入力のタイミング | 形式 |
|---|---|---|---|
| ID | とりまとめる人 | 登録時 | 連番 |
| タスク名 | 依頼する人 | 登録時 | 文字列 |
| 担当者 | とりまとめる人 | 登録時 | リスト選択 |
| 状態 | 担当者 | 動いたとき | リスト選択 |
| 期限 | 依頼する人 | 登録時 | 日付 |
| 更新日 | 担当者 | 動いたとき | 日付 |
| メモ | 全員 | 随時 | 文字列 |
なぜこの7つなのか
IDは、会話で指し示すために要ります。「あの、先週話していたバナーの件」ではなく「142番」と言えるだけで、確認にかかる時間が変わります。行の並べ替えをしても消えない番号にしておくことが大事なので、行番号ではなく独立した列に手で入れるか、数式ではなく値として入れます。
タスク名は、動詞で終わる形に統一します。「バナー」ではなく「バナーの初稿を作る」と書きます。名詞だけの行は、何をすれば終わりなのかが人によって変わり、状態の欄が意味を失います。とりまとめる人が登録時に整えるだけで、後の確認が減ります。
担当者は1人に絞ります。複数人を書けるようにすると、全員が「他の人がやると思っていた」と言える構造になります。関わる人が複数いる場合は、責任を持つ人だけを担当者に書き、他はメモに書きます。
状態は、選択肢を4つから5つに抑えます。「未着手」「進行中」「確認待ち」「完了」で多くの現場は足ります。差し戻しが多い仕事なら「差し戻し」を足します。8個や10個に細かく分けた表をよく見かけますが、選択肢が増えるほど担当者は選ぶのに迷い、更新の頻度が落ちます。
期限は日付だけを入れます。時刻まで入れる運用は、締切に時刻の意味があるとき以外は負担にしかなりません。期限が決まっていないタスクは、期限の欄を空けたまま登録して構いませんが、空欄の件数は定期的に見ます。空欄が全体の半分を超えたら、それは表の問題ではなく計画の問題です。
更新日は、この最小構成の中でいちばん軽視されがちで、いちばん効く列です。状態が「進行中」のまま2週間動いていない行を見つけられるのは、この列があるときだけです。担当者に「状態を変えたら更新日も入れてください」と頼むのは負担なので、後述する条件付き書式と組み合わせて、古い行が自然に目立つようにします。
メモは、構造化しない情報の逃げ場です。この列があると、思いつきで新しい列を足したくなる圧力がかなり下がります。「とりあえずメモに書いておいてください」と言える場所を用意しておくことが、列を増やさないための現実的な工夫になります。
置かなかった列をどう扱うか
最小構成に入れなかった項目は、捨てるわけではありません。別のシートに置くか、メモ列に書くか、そもそも表で持たないかの3択で振り分けます。案件名やカテゴリのように、行が増えると必ず欲しくなるものは、最初から入れてもよいのですが、その場合も選択肢をリストで固定します。自由入力にすると、同じカテゴリが表記ゆれで3種類に分かれ、集計が合わなくなります。
あとから足したくなる列と、足す前の判断基準
1か月ほど運用すると、必ず追加の要望が出ます。ここで全部受けると表が壊れるので、判断の基準を先に決めておきます。
基準は3つです。誰が埋めるかが1人に決まっていること。いつ埋めるかが既存の操作と同じタイミングであること。埋めなかったときに困る人が具体的にいること。この3つが揃わない列は、足さずにメモ列で受けます。
足してよいことが多い列
案件名または顧客名は、担当者が複数の案件を並行して持つチームでは早めに足す価値があります。埋めるのは登録時のとりまとめる人で、選択肢も限られるため、入力負担がほとんど増えません。フィルタで案件ごとに切り出せるようになると、打ち合わせの準備が一気に楽になります。
依頼日は、登録時に自動で入る形にできるので負担がありません。期限までの余裕がどれくらいあったかを後から振り返れるようになり、無理な依頼が常態化しているかどうかが数字で見えます。
確認者は、承認や検収の工程がある仕事では効きます。ただし、確認者を置くなら「確認待ち」の状態とセットで運用しないと機能しません。状態が「確認待ち」の行だけをフィルタして、確認者ごとに並べる使い方ができて初めて価値が出ます。
参照リンクは、成果物や仕様書の置き場所を1か所に集める役割を果たします。ファイルサーバーやクラウドストレージのURLを貼るだけなので、担当者の負担も小さく済みます。ただしリンクが切れたまま残ると、逆に信用を落とします。
足す前に立ち止まったほうがよい列
見積工数は、見積もる文化があるチームでは有効ですが、無いチームに入れると全員が適当な数字を入れます。適当な数字が入った工数の合計は、実態と離れた計画を生みます。工数を入れるなら、まず2週間だけ試して、入力率と精度を確かめてから常設にします。
親タスクと子タスクの階層は、表計算ソフトでは表現が難しい情報です。インデントで表す方法もありますが、並べ替えやフィルタをかけた瞬間に階層が崩れます。階層が本当に必要なら、タスク名の頭に案件名を書くか、別シートに分けるほうが現実的です。
足すと更新されなくなる列
ここが本題です。一見すると管理に必須に見えるのに、入れるとほぼ確実に死ぬ列があります。共通しているのは、担当者にとって「いま書くべき値が分からない」ことです。
進捗率
0から100までのパーセントで進み具合を書く列は、タスク表でもっともよく死にます。理由は単純で、正解が存在しないからです。デザインの初稿を作っている途中が40%なのか60%なのかは誰にも決められません。決められないので、担当者は50%と書いて放置します。そして完了の直前まで90%のまま止まります。
進捗率がほしくなるのは、状態の列が粗すぎて途中の様子が見えないときです。その場合の正しい対処は、パーセントを入れることではなく、タスクを分割することです。1行あたりの作業量を2日から3日で終わる大きさに揃えると、状態の4段階だけで進み具合が十分に見えます。
実績工数
かかった時間を書く列も、多くの現場で空欄になります。担当者は作業が終わった直後に時間を集計する習慣を持っていないことがほとんどで、翌日になると正確な値が思い出せません。思い出せない値を書かせると、表の数字は現実から離れます。
実績を取りたい理由が見積の精度を上げることなら、タスク単位ではなく週単位で大まかに取るほうが続きます。請求の根拠として必要なら、タスク表とは別の場所で記録する仕組みを用意します。管理表に相乗りさせると、両方の精度が落ちます。
依存関係
「このタスクはAが終わってから」という前後関係を表す列は、書いた瞬間は正しく、翌週には古くなります。前後関係は計画の変更で頻繁に入れ替わるのに、変更したときに依存の列まで直す人がいないからです。結果として、実態と違う依存関係が表に残り続けます。
10件程度なら頭の中で把握できます。それを超えて依存関係の管理が本当に必要な規模なら、表計算ソフトの列で持つのは無理があり、工程を扱う専用の仕組みが要ります。
優先度
高、中、低の3段階で優先度を付ける列は、置いた直後は機能します。問題は、時間が経つと全部が「高」になることです。依頼する人にとって自分の依頼は常に優先度が高いので、抑える人がいなければ数字は上がる一方です。
優先度を機能させたいなら、値ではなく制約で持ちます。たとえば「高」は同時に3件までと決めて、4件目を高にするときは既存のどれかを中に下げる、という運用にします。制約が無い優先度の列は、あってもなくても判断が変わりません。
死んだ列を片付ける手順
すでに空欄だらけの列がある表は、いきなり消さずに手順を踏みます。まず、その列の入力率を数えます。3割を切っている列は、機能していないと判断してよい水準です。次に、その列を最後に見た人が誰かを確認します。誰も見ていない列は、非表示にして1か月置きます。誰からも問い合わせが来なければ削除します。この順番なら、角を立てずに列を減らせます。
入力規則で、列を増やさずに精度を上げる
列を増やしたくなる動機の多くは、情報が足りないからではなく、入っている情報が信用できないからです。表記ゆれと入力ミスを止めれば、同じ列数のままで表の価値は上がります。表計算ソフトのデータの入力規則は、そのための機能です。
リストからの選択にする
担当者、状態、案件名、優先度のように選択肢が決まっている列は、必ずリスト選択にします。設定は、対象の列を選んでデータの入力規則を開き、入力値の種類でリストを選び、元の値に選択肢を指定するだけです。選択肢は直接書き込むのではなく、別シートに一覧を作ってその範囲を参照すると、後から選択肢を足すときにシート全体を直さずに済みます。
リスト化の効果は表記ゆれを止めるだけではありません。担当者がセルをクリックしたときに選択肢が出るので、「ここは何を書く欄なのか」が説明なしで伝わります。入力の迷いが減ると、更新の頻度が上がります。
日付と数値に範囲を付ける
期限の列には、日付の入力規則を入れます。開始日を今日、終了日を1年後に設定しておくと、年を打ち間違えて2020年の日付が入るような事故を防げます。エラーメッセージには「YYYY/MM/DD の形式で、今日以降の日付を入れてください」のように、直し方まで書いておきます。「入力値が正しくありません」とだけ出る設定は、担当者を止めるだけで助けになりません。
数値の列には上限を付けます。工数の列に1000時間が入るような入力ミスは、合計の数字を一瞬で壊します。上限を付けておけば、その場で気づけます。
条件付き書式で、見るべき行を浮かび上がらせる
入力規則とセットで使うのが条件付き書式です。列を足さずに情報を増やせる、いちばん費用対効果の高い機能です。
期限が今日より前で、かつ状態が完了以外の行に色を付けます。数式は行全体に適用する形で書き、対象範囲を表全体にしたうえで、列を固定する記号を使って判定列を指定します。これで、遅れている行だけが赤くなります。
更新日が7日以上前で、状態が進行中の行にも別の色を付けます。動いていないのに動いていることになっている行が、これで見えます。とりまとめる人が毎朝見るのは、この色が付いた行だけで足ります。全部の行を見る運用は続きません。
色は3種類までに抑えます。色が増えると意味を覚えられなくなり、結局どの色も無視されます。
入力規則が壊れる場面を知っておく
入力規則には弱点があります。他のセルからコピーして貼り付けると、規則ごと上書きされて消えます。担当者が別の表から一括で貼り付けた瞬間に、その範囲だけ規則が外れる、ということが実際によく起こります。
対策は3つあります。値のみの貼り付けを習慣として周知すること。シートの保護をかけて、入力してよい範囲だけを編集可能にすること。そして定期的に、規則が効いているかを確認することです。完全には防げないので、規則だけに頼らず、条件付き書式で「選択肢にない値」に色が付くようにしておくと二重の網になります。
フィルタとテーブル機能を、見る人ごとの視点に使う
列を増やしたくなるもうひとつの動機は、人によって見たいものが違うことです。これはフィルタで解決できる問題であり、列を足す理由にはなりません。
まず範囲をテーブルに変換する
表を作ったら、最初にテーブル機能で変換します。範囲を選んで挿入からテーブルを選ぶだけです。テーブルにすると、行を追加したときに書式と数式が自動で広がり、フィルタのボタンが最初から付き、数式で列名を使って参照できるようになります。
テーブルにしていない表は、行を足すたびに条件付き書式の範囲がずれ、入力規則の適用漏れが出ます。この作業を最初にやっておくかどうかで、3か月後の手間が大きく変わります。
フィルタは保存できる形で使う
フィルタの弱点は、共有ファイルでは他の人の画面にも影響することです。誰かが絞り込んだ状態のまま保存すると、次に開いた人は行が消えたと勘違いします。
これを避ける方法が用意されています。表計算ソフトによっては、絞り込みの条件を名前を付けて保存し、人ごとに切り替えられる仕組みがあります。使える環境なら、担当者ごと、案件ごと、今週締切、といった視点を先に登録しておきます。使えない環境なら、フィルタは解除してから保存するというルールを決めます。ルールにしないと必ず揉めます。
並べ替えの落とし穴
並べ替えは便利ですが、範囲を選ばずに1列だけ選んで実行すると、その列だけが動いて行の対応関係が壊れます。テーブルに変換していればこの事故は起きませんが、変換していない表では致命的です。壊れたことに気づかないまま共有されると、誰の担当が何なのかが分からなくなります。
並べ替えの既定は、期限の昇順にしておきます。開いた瞬間に、締切が近い順で並んでいる状態が、いちばん誤解の少ない見え方です。
集計はピボットテーブルで別シートに出す
担当者ごとの件数、状態ごとの件数、案件ごとの残タスク数といった集計は、元の表に集計用の列を足すのではなく、ピボットテーブルで別シートに出します。元の表に集計列を足すと、行の追加のたびに数式の範囲を直すことになり、そこから表が崩れ始めます。
ピボットテーブルは元データを更新してから更新ボタンを押す必要があるので、会議の直前に押す担当を決めておきます。押し忘れた古い集計で会議が進むと、表そのものへの信用が落ちます。
列より先に、更新のルールを決める
テンプレートを探している段階では見落とされがちですが、表の寿命を決めるのは列の数ではなく更新のルールです。同じ表でも、ルールがあるチームでは半年動き、ないチームでは2週間で止まります。
決めることは4つです。誰が更新するか。いつ更新するか。どこに置くか。更新されなかったときにどうするか。
更新するのは、原則として担当者本人です。とりまとめる人が代理で入力する運用は、負荷が1人に集まるうえ、状況の把握が伝聞になります。ただし、担当者が現場に出ている職種などで入力が難しい場合は、無理に本人に求めず、報告を受けた人が入れる形に決めておきます。曖昧なままにするのがいちばん悪い状態です。
更新のタイミングは、既存の習慣にくっつけます。朝礼の前、日報を書くとき、退勤前の5分。新しい習慣を作るより、すでにある習慣に足すほうが定着します。「気づいたときに」は、実質的に「更新しない」と同じです。
置き場所は1か所に決めます。メールに添付して回すと、その瞬間に版が分かれます。クラウド上の1つのファイルを全員が開く形にして、ファイル名に日付を入れるのはやめます。日付入りのファイル名は、コピーを作る動機になります。
更新されなかったときの扱いも決めておきます。古い行を責める運用にすると、担当者は状態を実態より進めて書くようになり、表がもっと嘘になります。色が付いた行について「詰まっているところはありますか」と聞く運用にすると、表が相談のきっかけとして機能します。
表計算のまま続けるか、板に移すか
ここまでの設計をしても、規模と使い方によっては表計算ソフトのままでは苦しくなる場面があります。判断の分かれ目を、道具の優劣ではなく運用の形で整理します。
表のままでよい場合
タスクの登録から完了までを、実質1人か2人で回している場合は、表計算ソフトのままで十分です。同時編集の問題が起きず、更新のルールも自分の中で完結します。
集計や計算が管理の中心にある場合も、表のままが向いています。原価や工数を細かく積み上げて分析する使い方は、表計算ソフトのほうが柔軟です。
期間が決まっていて、終わったら捨てる表も、無理に移す必要はありません。1か月で終わるイベントの準備表を、専用のツールに載せ替える手間は割に合いません。
移す判断が立つ場面
同時に触る人が5人を超えたときが、ひとつの目安です。人数が増えるほど、誰かが操作している間の待ちが発生し、版のずれも起きやすくなります。
状態の更新頻度が高い仕事も、板の形が向いています。ボード型のタスク管理では、カードを次の列にドラッグするだけで状態が変わります。1枚の板を全員が同時に見て、誰がいつ動かしたかも残る形になると、更新日の列を手で入れる作業そのものが要らなくなります。
社外の人と進行を共有する場合も、板のほうが扱いやすいことが多くなります。ファイルを送り合う形では、相手の手元に古い版が残り続けます。
道具ごとの考え方の違いは、比較のページに整理されています。カードを板に並べる形の代表的な道具との違いをまとめたのがTrelloとの比較で、そこから移す場合の手順はTrelloからの移行にまとめられています。仕事の依頼と進行を細かく分けて管理する使い方との違いはAsanaとの比較に、文書とデータベースを一体で扱う道具との違いはNotionとの比較にあります。
移すときに、列をどう畳むか
表から板に移すとき、そのまま全列を持ち込もうとすると失敗します。板の形では、列は「カードの項目」ではなく「板の縦の区切り」として使われるからです。
畳み方の原則は3つです。状態の列は、板の縦の区切りに変換します。担当者は、カードに人を割り当てる形になります。期限は、カードの期限として持ちます。ここまでで、最小構成の7列のうち3つが、入力欄ではなく板の構造そのものになります。
残るのはID、タスク名、更新日、メモです。IDはカードの番号が自動で振られる仕組みがあれば不要になり、更新日も操作の履歴が残るなら手入力が要らなくなります。つまり、7列のうち手で入力し続ける必要があるのはタスク名とメモだけ、という形まで畳めます。入力の依頼が減るということは、更新されない列が生まれる余地が減るということです。
移した先で機能をどこまで使えるかは、事前に確かめておく必要があります。板の形の道具でできることの範囲はできることに、費用の考え方は料金にまとめられています。細かい機能の数で選ぶより、機能で絞らず、区切るのは人数とボードの数だけという考え方の道具のほうが、途中で使える範囲が変わって混乱する事態を避けやすくなります。
列の設計を点検するための、比較材料の使い方
最後に、いま使っている表やツールを見直すときの手順をまとめます。列を減らす判断も、道具を移す判断も、根拠は同じところにあります。
点検は3つの数字から始めます。1つ目は、列ごとの入力率です。全行のうち値が入っている割合を数え、3割を切る列を洗い出します。2つ目は、状態が変わってから更新日が書き換わるまでの日数です。ここが開いているほど、表は実態から遅れています。3つ目は、直近30日で表を編集した人の人数です。とりまとめる人だけが編集している表は、管理表ではなく報告書になっています。
この3つのうち、1つ目は列を減らせば直ります。2つ目は運用のルールで改善できます。3つ目だけは、表計算ソフトの形式そのものが原因になっていることが多く、道具の形を変えないと動きません。編集する人が増えない原因が、同時に触れないことなのか、開くのが面倒なことなのか、入力の項目が多すぎることなのかを切り分けます。
道具を比べるときは、機能の一覧表を横に並べるより、自分たちの運用の形に合うかどうかで見ます。案件ごとの課題管理を軸に据える考え方との違いはBacklogとの比較に、日本語での運用のしやすさを重視する道具との違いはJootoとの比較に、複雑な工程を細かく組み立てる道具との違いはmonday.comとの比較にまとめられています。全体を並べて見たい場合は比較の一覧から入るのが早道です。
社内の情報をどこまで外に置いてよいかという判断も、移行の前に済ませておく必要があります。データの扱いについての考え方は安全性の考え方に、導入の前に出やすい疑問はよくある質問に整理されています。表計算ソフトのファイルを社内のサーバーに置いている状態と、クラウド上に置く状態とでは、確認すべき点が変わります。委託先との情報共有に関わる場合は、契約上の扱いを含めて、社内の担当部署や専門家に確認しておくと安全です。
列を増やしすぎない、という結論は、情報を減らせという意味ではありません。集める情報を絞り、絞った分を入力規則とフィルタと運用のルールで確実に集める、という設計の話です。7列で始めて、1か月後に足りないものだけを足す。この順番を守るだけで、テンプレートを探し直す回数はかなり減ります。
Q1. タスク管理のエクセルテンプレートは、無料のものをそのまま使ってよいですか？
そのまま使って構いませんが、列を減らしてから使い始めるのが安全です。配布されているテンプレートは網羅性を優先しているため列が多く、進捗率や実績工数など更新されにくい列も含まれています。まずID、タスク名、担当者、状態、期限、更新日、メモの7列だけを残し、1か月運用してから不足分を足す順番にすると失敗しにくくなります。
Q2. 状態の選択肢は、いくつくらいが適切ですか？
4つから5つが目安です。未着手、進行中、確認待ち、完了で多くのチームは足ります。差し戻しが多い仕事なら差し戻しを加えます。選択肢を8個や10個に細かく分けると、担当者が選ぶのに迷って更新の頻度が落ち、結果として表が実態から遅れます。細かく見たいときは選択肢を増やすのではなく、タスクを2日から3日で終わる大きさに分割してください。
Q3. 複数人で同時に編集すると表が壊れます。どうすればよいですか？
まず範囲をテーブル機能に変換してください。行の追加で書式や数式がずれる事故と、1列だけを並べ替えて行の対応が壊れる事故を防げます。そのうえで、フィルタは解除してから保存するというルールを決めます。同時に触る人が5人を超えて待ちが常態化している場合は、表の形ではなく道具の形が合っていない可能性が高くなります。
Q4. 進捗率の列は本当に不要ですか？
不要というより、ほとんどの現場で機能しません。作業の途中が40%なのか60%なのかを決める基準が存在しないため、担当者は50%と書いて放置し、完了直前まで90%のまま止まります。途中の様子を見たいときは、パーセントを入れるのではなくタスクを小さく分割し、状態の4段階で追える大きさに揃えるほうが確実です。