スプレッドシートのタスク管理｜同時編集で起きること
スプレッドシートでタスク管理をしているチームは多く、そして多くの場合、それは正しい選択から始まっています。表計算ソフトはすでに全員が使えて、作るのも直すのも早く、誰かに使い方を教える手間がほとんどかかりません。問題が出てくるのは、その表を同時に何人もが開くようになってからです。この記事では、スプレッドシートのタスク管理で同時編集が生む利点を先に押さえたうえで、同時編集だからこそ起きること、つまり行の並べ替えで他の人が見ている位置がずれること、誰が変えたのか追いにくいこと、変わったことが相手に届かないことの3つを順番に整理します。読み終えたときに、いまの表のどこで詰まっているのかと、次に何を変えればよいのかが決められる状態を目指します。
表計算ソフトがタスク管理の入口になり続ける理由
チームの進行を最初に書き出す場所として、表計算ソフトは今も最有力です。専用のツールを検討する前に、まず1枚のシートを作る。この順番は、多くのチームで自然に選ばれています。理由は好みではなく、導入の摩擦がほとんどゼロだからです。
覚え直さなくていい、という強さ
新しい道具を入れるとき、いちばん高くつくのは料金ではなく、チーム全員が覚え直す時間です。10人のチームなら10人分、30人のチームなら30人分の学習時間が同時に発生します。表計算ソフトはそこがすでに済んでいます。行と列、フィルタ、色付け、条件付き書式。だいたいの人が説明なしで触れます。
進行のとりまとめをしている人にとって、この差は決定的です。道具を入れる話より、入れたあとにチームが使い続けてくれるかのほうが難しい。現場でよく聞くのは、専用ツールを導入した最初の週は全員が入力し、次の週には半分になり、月末には管理者だけが更新している、という話です。表計算ソフトはその離脱が起きにくい。誰も新しいことを覚えていないからです。
もうひとつ、表計算ソフトは形が決まっていません。案件ごとに列を足せますし、途中でやり方が変わっても列を1つ増やすだけで済みます。専用ツールは項目の設計思想が先にあるため、そこに現場の運用を合わせにいく場面が出てきます。まだ進め方が固まっていない立ち上げ期のチームでは、この自由さがそのまま速さになります。
それでも、表が壊れ始める時期がある
一方で、表計算ソフトのタスク管理には、だいたい決まった壊れ方があります。最初は20行くらいだったシートが数百行になり、列が右へ右へと伸びていき、色のルールを決めた人がもう覚えていない。ここまでは「大きくなっただけ」で、まだ運用でなんとかなります。
本当に苦しくなるのは、同じシートを何人もが同時に開き始めてからです。1人で管理していたときには存在しなかった種類の問題が出てきます。しかもその問題は、表計算ソフトの欠陥というより、複数人が同じ座標系を共有していることの副作用として出てきます。だからこそ、機能を足しても消えません。
現場で起きているのは、たいてい次の3つです。並べ替えると他の人の画面がずれること。誰がどこを変えたのか分からなくなること。変わったことが関係者に届かないこと。この3つを、利点と一緒に順に見ていきます。
同時に開けることは、それだけで大きな利点
先に、はっきり書いておきます。オンラインのスプレッドシートを使ったタスク管理は、ファイルを配って回していた時代と比べて、明確に前進しています。同時編集は制約ではなく、まず利点として数えるべきものです。ここを認めないまま「表計算は限界だ」という話にしても、読む側の実感と合いません。
順番待ちが消える
ローカルのファイルでタスク表を管理していたころは、誰かが開いている間、他の人は読み取り専用でしか開けませんでした。工程表を1人が引き直している間、他の人はその表を更新できません。編集したければ「いま閉じてもらえますか」と声をかけて、閉じるのを待つ。5人のチームでもこれは地味に効いて、月末の締めのように全員が同時に触りたい日には、実質的に順番待ちの行列ができていました。
オンラインのスプレッドシートは、この順番待ちを丸ごと消しました。10人が同時に開いて、それぞれが自分の担当行を埋められます。締めの日に「あと3人待ちです」と言わなくてよくなったのは、それだけで運用の負荷を大きく下げています。
最新版が誰かのパソコンの中に閉じ込められない
ファイルで運用していたころの最大の事故は、版が枝分かれすることでした。「タスク管理表_最新.xlsx」と「タスク管理表_最新_修正版.xlsx」と「タスク管理表_0812田中さん修正.xlsx」が並び、どれが正なのか誰も断定できなくなる。誰かが古いほうに書き足すと、その作業は静かに捨てられます。
同時編集の表では、正のデータが1か所にしかありません。開いている全員が同じものを見ているという前提が置けることは、とりまとめる側にとって大きな安心です。少なくとも「どれが最新か」という問いは消えます。
会議の最中に直せる
進行会議のあいだ、画面を共有しながらその場で表を直せるのも、同時編集ならではです。担当者が口頭で「その件は来週に倒します」と言った瞬間に、別の人が期日の欄を書き換えられる。会議のあとに議事録から転記する工程が要りません。転記は必ず抜けるので、その工程が消えることは品質の向上でもあります。
ここまでが利点です。そのうえで、同時に開けるからこそ起きることを見ていきます。以下の3つは、表計算ソフトが悪いのではなく、複数人が同じ表を共有すると構造的に発生するものです。
起きること1：並べ替えで、他の人が見ている位置がずれる
同時編集で最初に体感する不具合は、たいてい並べ替えです。誰かが期日順に並べ替えた瞬間、他の人の画面でも行が動きます。いま入力しようとしていた行が視界から消え、別の案件の行がそこに来ます。
なぜずれるのか
表計算ソフトの並べ替えは、見え方の設定ではなく、データそのものの並び順を書き換える操作です。3行目にあった案件が47行目へ移動すると、その移動は開いている全員に反映されます。自分だけ期日順で見たい、という願いは標準の並べ替えでは叶いません。
そして人は、行の中身ではなく画面上の位置で覚えています。「上から3つ目の行の、右から2つ目の欄」という覚え方をしている人が、並べ替えの直後に同じ位置へ入力すると、まったく別の案件の欄を書き換えることになります。これが表の同時編集で起きる、いちばん静かな事故です。
ずれが事故になる瞬間
危ないのは、入力の途中で並べ替えが走ったときです。セルを選んで文字を打ち込んでいる最中に他の人が並べ替えを実行すると、確定した値が意図しない行に入ることがあります。しかも入力した本人は気づきません。数日後、担当者が「自分の案件の進捗が勝手に完了になっている」と言い出して、ようやく発覚します。
もうひとつは、行の挿入と削除です。誰かが表の途中に1行足すと、その下にある全員の行が1つずつ下がります。別の場所から参照している数式や、別シートから行番号で引いている集計は、この瞬間に指す先が変わります。集計シートの数字だけが静かに壊れ、元の表を見ているかぎり異常が見えません。
現場でよく聞くのは、こうした事故が1回起きるとチームが極端に慎重になり、誰も並べ替えなくなる、という反応です。結果として、期日順にも担当者順にも並んでいない、ただ追加された順の長い表が残ります。見づらいので誰も見なくなり、表は更新されなくなります。
抑える方法
完全には消せませんが、被害は小さくできます。まず、多くのスプレッドシートには自分だけに適用される絞り込み表示の機能があります。全員の並び順を動かさずに、自分の画面だけ期日順や担当者順にできるので、日常の閲覧はこちらに寄せます。標準の並べ替えは、決めた人だけが決めたタイミングで実行する運用にします。
次に、並べ替えの基準列を最初から決めておくことです。「この表は常に期日の昇順」と決めてしまえば、誰が実行しても結果が同じになり、位置の記憶が壊れにくくなります。担当者ごとに見たい場合は、並べ替えではなく絞り込みで対応します。
そして、行の挿入と削除は入口を絞ります。追加は表の最下行に限定し、途中への挿入は禁止する。削除はせず、状態の列を「取り下げ」に変えて残す。1行消すだけで参照が壊れる構造なので、消さない運用にするだけで事故は目に見えて減ります。
起きること2：誰が変えたのか、追いにくい
2つ目は、変更の主が分からなくなる問題です。表の数字がいつの間にか変わっている。期日が動いている。担当者名が空欄になっている。誰がやったのかを突き止めようとして、そこで手が止まります。
履歴はあるが、探せる形ではない
主要なオンラインのスプレッドシートには変更履歴の機能があり、いつ誰が編集したかは記録されています。だから「記録がない」わけではありません。問題は、その履歴がセル単位の編集を時系列に並べたものであり、「この案件について何が起きたか」という単位で読めないことです。
進行のとりまとめをしている人が知りたいのは、「この案件の期日が動いた経緯」です。ところが履歴の画面が返してくるのは、「何月何日の何時何分に、誰かがこのシートを編集した」という粒度の情報です。案件が数百行あり、1日に何十回も編集が入る表では、目的の変更にたどり着くまでに時間がかかります。急いで確認したい場面ほど、この手間が効いてきます。
空欄になった原因が分からない
もっと厄介なのは、消えた場合です。値が書き換わったのなら前後の比較で気づけますが、空欄になった場合、誰かが意図的に消したのか、コピー&ペーストの範囲がずれて上書きされたのか、区別がつきません。ペーストの事故は、貼り付けた本人にも自覚がないまま起きます。
チームの人数が増えるほど、この「原因不明の欠損」は増えます。5人で使っていたときは思い当たる人に聞けば済んでいたものが、20人になると誰に聞けばよいかも分かりません。結果として、とりまとめる人が毎回入力し直すことになり、その負担が特定の1人に集中します。
抑える方法
対策は3つあります。1つ目は、更新者と更新日を列として持つことです。手作業で書くルールにすると必ず抜けるので、更新があったら自動で書き込まれる仕組みにします。少なくとも「最後に触った人」が表の上で見えるだけで、確認先が特定できます。
2つ目は、コメント機能を使うことです。セルの値を直接書き換える前に、コメントで「この期日、来週に倒します」と残してから変える運用にすると、変更の理由が案件のそばに残ります。履歴を掘るのと違い、コメントは案件単位でまとまって読めます。
3つ目は、編集できる範囲を分けることです。担当者が触る列と、とりまとめる人だけが触る列を保護機能で分ければ、確定値が知らないうちに動く事故は減ります。ただし、保護を細かくかけるほどシートの管理が重くなり、担当が変わるたびに設定を直す仕事が発生します。ここは運用の負荷とのつり合いで決めます。
起きること3：変わったことが、相手に届かない
3つ目は、通知です。表計算ソフトのタスク管理でいちばん静かに効いてくるのが、この問題です。表は正しく更新されているのに、更新されたことを知るべき人が知らない。
通知の単位が、仕事の単位と合わない
多くのスプレッドシートには通知の設定があります。ただし通知できる単位は、たいていシート全体か、それに近い粒度です。「このシートが変更されたら知らせる」という設定を入れると、誰かが1文字直すたびに通知が飛びます。20人が入力する表なら、1日に何十通も届きます。
人は、多すぎる通知を必ず切ります。切った瞬間、通知はゼロになります。つまり実際の運用では、「通知が多すぎて使い物にならない」か「通知を切っていて何も届かない」のどちらかに落ち着きます。中間がありません。
一方で、仕事で本当に知りたいのは「自分が担当している案件の期日が動いたとき」や「自分に新しい担当が割り当てられたとき」です。この粒度で知らせる設定は、表計算ソフトの標準機能だけでは組みにくいのが実情です。
チャットに転記する運用が二重管理を生む
そこで多くのチームが取る対策が、チャットへの転記です。表を更新した人が、チャットで「Aさん、この案件の期日を来週に変えました」と伝える。これは確実に届きます。届きますが、同じ情報が2か所に存在することになります。
二重管理は、必ず片方が古くなります。チャットで合意した変更が表に反映されないまま進む、あるいは表を直したのにチャットに流れず、担当者が古い期日で動く。どちらも起きます。とりまとめる人は、表とチャットの両方を突き合わせる仕事を毎日することになり、これが管理コストの正体になっていきます。
現場でよく聞くのは、「表よりチャットのほうが実態に近い」という状態です。こうなると表は報告用の書類になり、進行の道具としては機能していません。
抑える方法
まず、通知の対象を絞ります。シート全体への通知は切り、コメントのメンション機能に一本化するのが現実的です。担当者名を指定してコメントを書けば、その人にだけ届きます。粒度が仕事の単位に近づくので、切られにくくなります。
次に、変更を伝える場所を1つに決めます。チャットで決めた変更は、決めた人がその場で表に書く。表を直したら、その旨をチャットには書かず、表のコメントで伝える。どちらに寄せるかはチームの文化次第ですが、両方に書く運用だけは避けます。
そして、読み合わせの時間を短く固定します。15分でも、週に1度、表を全員で上から見る時間を取ると、届いていない変更がその場で拾えます。通知の仕組みで100%を目指すより、抜けを拾う場を用意するほうが現実的です。
表のまま踏ん張るための設計
ここまでの3つは、運用の設計である程度まで抑えられます。道具を替える前に、まず表の作りを直すほうが早いことも多いので、先にこちらを検討する価値があります。
1つのシートに1つの目的だけを持たせる
壊れる表には共通点があります。1枚のシートが、タスク一覧と、進捗の集計と、担当者ごとの負荷表と、請求の管理を兼ねていることです。目的が混ざると列が増え、列が増えると横スクロールが発生し、横スクロールが発生すると入力ミスが増えます。
タスクの一覧は一覧だけにして、集計は別シートから参照します。参照は行番号ではなく、案件ごとの固有の番号を鍵にして引きます。行番号で引いていると、前述のとおり行の挿入だけで壊れます。案件番号を1列目に置いて、それを鍵にする設計へ直すだけで、並べ替えにも挿入にも強くなります。
入力規則と保護を先に入れる
自由に文字を打てる欄は、必ず表記がばらつきます。状態の欄に「完了」「済」「done」「OK」が混在すると、集計は成立しません。状態や優先度のように選択肢が決まっている列は、入力規則でプルダウンにします。日付の列も、文字列で入力されると並べ替えが効かなくなるので、日付形式に固定します。
そのうえで、数式が入っている列と、集計シートは保護します。保護をかけていない集計シートは、いつか必ず誰かが上書きします。悪意ではなく、単にコピー&ペーストの範囲が広かっただけです。
共有設定を定期的に見直す
タスク管理の表には、案件名、取引先名、金額、担当者の名前が並びます。社外の協力者と一緒に使っている場合はとくに、共有範囲の点検が要ります。急ぎのときに「リンクを知っている全員が編集可」にしたまま、戻し忘れているケースは珍しくありません。
情報処理推進機構が中小企業向けに示している基本の対策にも、共有設定の確認は明記されています。
①OSやソフトウェアは常に最新の状態にしよう ②ウイルス対策ソフトを導入しよう ③パスワードを強化しよう ④共有設定を見直そう ⑤脅威や攻撃の手口を知ろう 出典: 情報処理推進機構
タスク管理の表は、業務の中身がそのまま並ぶ資料です。誰がどこまで見られるかは、四半期に1度でも見直す価値があります。ツールを検討する段階なら、そのツールがどういう考え方でアクセス範囲を設計しているかも確認しておきたいところで、安全性の考え方のページには、データの取り扱いや権限をどう区切るかの整理が載っています。
表のままでよい場合と、板に移したほうがよい場合
道具を替えるかどうかは、機能の多さではなく、いまの詰まり方で決めます。表計算ソフトのままがよいチームは確かにあります。
表のままでよい場合
案件の数が少なく、担当者が固定されていて、期日が動きにくい仕事なら、表計算ソフトのほうが速いままです。とくに、集計や金額計算が仕事の中心にある場合は表計算に分があります。関数で自由に計算できる強さは、専用のタスク管理ツールでは置き換えにくい部分です。
また、進め方そのものがまだ固まっていない立ち上げ期も、表のままが向いています。列を足したり消したりしながら形を探る段階で、決まった形を持つツールに入れると、かえって手数が増えます。
同時に開く人数が少ないうちも、上記の3つの問題はほとんど顕在化しません。3人で使っている表なら、並べ替えのずれも変更者の特定も、声をかければ済みます。
移したほうがよい判断の目安
判断の目安は、次のどれかに当てはまるかどうかです。
1つ目は、表の更新が特定の1人に集中していることです。担当者が自分で更新しなくなった表は、その人が休んだ日に止まります。入力する人が増えないと、進捗の表はすぐ嘘になります。
2つ目は、表とチャットの突き合わせに毎日時間を使っていることです。前述の二重管理が定着している状態で、これは道具の設計で解ける問題です。
3つ目は、事故の後始末に時間を取られていることです。並べ替えのずれ、誤ペースト、参照切れ。復旧のたびに半日かかっているなら、構造を替えたほうが結果的に安く済みます。
4つ目は、案件ごとのやり取りが表の外に散らばっていることです。仕様の相談はチャット、資料は共有ドライブ、進捗は表、という状態だと、新しく参加した人が経緯を追えません。案件を1枚の札としてまとめられるボード型の道具は、この点で表と発想が違います。できることのページには、札の中に何をまとめられるかが整理されています。
移すときに確かめること
移すと決めた場合、確かめる順番があります。機能表を並べて比べる前に、次の3つを見ておくと判断が早くなります。
移行の手間がどれくらいかかるか
いま表に入っている数百件を、手で入れ直すのは現実的ではありません。移行の経路が用意されているかを最初に見ます。ボード型のツールから移る場合、Trelloからの移行のように、自動で取り込める経路が用意されていることがあります。ただし自動で取り込めるのは対応しているサービスだけで、表計算ソフトから移す場合は、書き出しと読み込みの形式を確認する必要があります。ここは正直に見積もったほうがよく、移行に何日かかるかを見ないまま決めると、移行が終わらないまま両方を運用する期間が延びます。
料金の区切り方がチームの増減に耐えるか
料金は、金額そのものより区切り方を見ます。機能ごとにプランが分かれているタイプは、後から「その機能は上位プランです」と分かって計画が崩れることがあります。ボード型のツールの中には、機能で絞らず、区切るのは人数とボードの数だけという考え方を取るものがあり、この形だと必要な人数が決まれば費用の見通しが立ちます。具体的な区切りと金額は料金のページで確認できます。なお料金体系はどのサービスでも改定されるので、比較するときは必ずいつ時点の情報かと、税抜か税込かを見てください。
使い続けられる形かどうか
最後は、チームが使い続けられるかです。導入直後に離脱が起きる原因は、たいてい入力の手数です。1件登録するのに何回クリックが要るか、状態を変えるのに何画面またぐか。ここは実際に試して確かめるしかありません。判断に迷う点はよくある質問のページにも整理されているので、検討の初期に目を通しておくと、あとで想定と違ったという事態を避けられます。
板型ツールの比較から見えること
タスク管理の道具を比べたページを横断して見ていくと、表計算ソフトから移る人が実際に気にしている論点が浮かび上がります。ここでは、その比較の中身から読み取れることを整理します。
論点は機能数ではなく、どこで区切るか
比較を読む人が最初に見るのは機能の一覧ですが、最終的に判断を分けているのは機能の多さではありません。分かれ目になっているのは、無料と有料の境界がどこに引かれているか、そして人数が増えたときに何が起きるかです。
Trelloとの比較では、板と札という発想が同じである分、違いは料金の区切りと日本語での使い勝手に集まります。Asanaとの比較は、多機能で細かく設定できるツールと、設定を減らして使い始めやすくしたツールの対比になります。Notionとの比較では、何でも作れる自由さと、進行の管理に絞った設計との違いが論点です。自由に作れることは強みですが、作った人しか構造を理解していない状態になりやすいという裏返しもあります。
monday.comとの比較やBacklogとの比較は、対象としている仕事の種類が異なります。開発の工程を細かく追う必要があるチームと、案件の進行を俯瞰したいチームでは、必要なものが違います。Jootoとの比較は、日本語で使えるボード型どうしの比較として、料金の区切りが直接ぶつかる組み合わせです。それぞれの詳細は比較の一覧からたどれます。
隠さずに書いてある弱点のほうが、判断には効く
比較のページを読むときに見るべきは、勝っていると書いてある項目より、できないと書いてある項目です。ボード型のタスク管理ツールには、開発リポジトリの機能を持たないもの、自動化や外部サービスとの連携で勝負しないもの、画面が日本語のみのもの、自動での取り込みが特定のサービスからに限られるものがあります。
こうした制約は、チームによっては決定的な欠格事由になります。ソースコードの管理と課題管理を同じ場所で完結させたい開発チームなら、リポジトリ機能の有無は最初の分岐点です。海外のメンバーがいるなら、画面の言語は譲れません。逆に、日本語のチームで進行の管理だけを1か所にまとめたいのであれば、これらの制約はほとんど影響しません。
表計算ソフトから移る判断で大事なのは、いまの詰まりが解けるかどうかの1点です。並べ替えで位置がずれる問題は、札を並べる板であれば、そもそも行番号という共有座標を持たないので構造的に起きません。誰が変えたか追いにくい問題は、札ごとに履歴とコメントがぶら下がる形であれば、案件単位で読めます。変更が届かない問題は、札に人を割り当てる仕組みがあれば、通知の粒度が仕事の単位と一致します。
決めるべきは道具ではなく、運用の置き場所
最後に、比較の結論として書いておきたいのは、道具を替えても運用は自動的に良くなりはしないということです。表がうまくいっていないチームは、たいてい「どこに何を書くか」が決まっていません。決まっていないまま新しい道具に移せば、同じ散らかり方が新しい画面で再現されます。
先に決めるのは、進行の正がどこにあるかです。表なら表、板なら板。そこに書かれていないことは、決まっていないことにする。この一線を引けるかどうかが、道具の選択より先にあります。そのうえで、同時に開いても位置がずれない、誰が変えたか札の中で追える、変更が担当者に届く、という3点を満たす形を選べば、いま表計算ソフトで起きている問題は解けます。
いまの表がどこで詰まっているのかは、この記事の3つの項目に照らせば見分けられます。並べ替えで事故が起きているのか、変更の主が追えないのか、更新が届いていないのか。どれか1つだけなら運用の設計で足ります。3つとも起きているなら、置き場所そのものを見直す段階に来ています。
Q1. スプレッドシートのタスク管理は何人までなら問題なく使えますか？
人数そのものより、同時に開いて編集する人数と更新の頻度で決まります。3人程度で更新も1日数回なら、並べ替えのずれも変更者の特定も声かけで解決できます。同時編集が10人を超え、1日に何十回も更新が入るようになると、行の並べ替えによる位置ずれと通知の問題が運用でカバーしきれなくなります。
Q2. 並べ替えで他の人の画面がずれるのを防ぐ方法はありますか？
標準の並べ替えはデータの並び順そのものを書き換えるため、開いている全員に反映されます。自分だけに適用される絞り込み表示の機能を日常の閲覧に使い、標準の並べ替えは担当者を決めて決まったタイミングだけ実行する運用にします。あわせて、行の途中への挿入と削除を禁止すると事故が減ります。
Q3. 変更履歴があるのに、誰が変えたか追えないのはなぜですか？
履歴はセル単位の編集を時系列に並べたもので、案件ごとにまとめて読める形になっていないためです。数百行の表で1日に何十回も編集が入ると、目的の変更にたどり着くまで時間がかかります。更新者と更新日を列として持つ、変更前にコメントで理由を残すといった運用で、確認先を特定しやすくできます。
Q4. タスク管理ツールに移すかどうかは何を基準に決めればよいですか？
機能の多さではなく、いまの詰まり方で決めます。更新が特定の1人に集中している、表とチャットの突き合わせに毎日時間を使っている、事故の後始末に半日かかっている、案件ごとのやり取りが表の外に散らばっている。このうち複数に当てはまるなら、置き場所を見直す段階です。1つだけなら運用の設計で足ります。