Backlogカスタマーサクセス担当の鍋島です。

業務の規模の拡大や関わるステークホルダーが増えると、スプレッドシートによるタスク管理が難しくなり、Backlogなどのタスク管理ツールの導入を検討される事が多いと思います。

しかし、スプレッドシートのタスクをBacklogにどのように置き換えるかは、なかなか悩ましい問題です。この記事では、スプレッドシートからBacklogに置き換える際に検討すべきポイントについてご紹介します。

まずはBacklogの課題管理の特長をおさらい

スプレッドシートからの移行ポイントをご紹介する前に、まずはBacklogによるタスク管理の特徴についておさらいしましょう。Backlogの特性を把握することで、移行の戦略を立てやすくなります。

※正確にはカスタム属性（プレミアムプラン以上で使用可能）という機能を使うことで、独自のステータスのような選択リスト形式の入力項目を定義することは可能です。ですが処理状況による色分けの活用や、スケジュール支援機能との連動を考えると、処理状況の把握には、課題の状態を使うことを強くお勧めします。

スプレッドシートからBacklogに置き換えるときに着目するポイント

スプレッドシートからBacklogに移行するためには、表の各項目の意味を読み解きながら、Backlogの持つ機能の特性にフィットさせる必要があります。以下はよくあるタスク管理表のサンプルです。これをBacklogに移し替えるケースを考えてみましょう。

▲クリックすると拡大表示

CHECK1　深くなりすぎた階層を整理しよう

タスク管理表は「B列：グループ」「C列：大項目」「D列：中項目」「E列：小項目」の4階層に分かれています。

しかし、階層が深くなりすぎると、プロジェクトの見通しが悪く、管理しづらくなります。さらに、Backlogの課題は親子課題の2階層までしか作ることができません。深くなりすぎた階層を、Backlogにフィットするように整理してみましょう。

個別のタスクに当たる項目を洗い出す

タスク管理表の記入項目のなかでどこが最小のタスクに該当するのかを確認しましょう。

一般的には1タスク1行で記入することが多いと思いますが、場合によっては行がカテゴリ分けの役割を果たし、各列の記入項目が具体的なタスクを表している場合もあります。

Backlogの管理方法にフィットさせるためには、表を最小のタスクに分解して、個別の課題として登録していくことが必要になります。

課題の分類方法を駆使する

タスク管理表のB列：グループ〜E列：小項目の階層を、Backlogのカテゴリなどの分類に分けられないか検討してみましょう。

例えば、管理表の「B列：グループ」は、内容による分類なのでBacklogの課題の「カテゴリ」に置き換えると良いでしょう。また、タスクの「D列：中項目」と「E列：小項目」は、親子課題機能を使うとスムーズに整理できるでしょう。

その階層、本当に必要ですか？

タスク管理表をよく見ると、C列：大項目の意味合いが定まっておらず、記載されている内容がグルーピングや個別タスクなど行によってまちまちです。

使い方を整理せず、思いつくままに階層を深くすると、記入の手間が増えてプロジェクトの可読性を損ないます。今回の例では、大項目を取り払っても、タスク管理には大きな支障はないでしょう。

💡Tips：カテゴリは、課題に対して複数設定できます。どうしても大項目にあたる分類が必要な場合は、個別のカテゴリとして作って、複数設定するのもひとつの手でしょう。カスタム属性（プレミアムプラン以上）で入力項目を増やしても良いかもしれません。

スプレッドシートからBacklogを検討する

CHECK2 複雑すぎるステータスを整理しよう

タスク管理表の「K列：ステータス」に着目しましょう。8つものステータスが設定されています。

ステータスが複雑だと、記入が煩雑になり、一覧にした時に進捗や残り作業量の把握が困難になりがちです。加えて、タスクが複雑なステータスを必要とするということは、そもそも粒度が大きすぎるタスクを登録している可能性があります。

Backlogでは、あえて未対応／処理中／処理済み／完了の4つの状態に固定して、複雑なステータスを表現できないようにしています。複雑になってしまったタスク管理表のステータスを、Backlogの課題の状態にフィットするように整理してみましょう。

４つの状態に当てはめる

一般的にBacklogの「課題の状態」は以下のような意味で使われています。

• 「未対応」：作業に未着手の状態
• 「処理中」：作業に着手している状態
• 「処理済み」：作業の成果物をチームリーダーやプロジェクトマネージャーに確認してもらう状態
• 「完了」：成果物のチェックが完了した状態（＝リリースができた状態）

今回の例では、内容レビュー／回答待ち／承認待ちは、いずれも、何らかの確認を待っている状態と見なすことができます。そうすると、Backlogの状態で言う「処理済み」に置き換えても、差し障りないでしょう。

あわせて読みたい📖：「処理済み」と「完了」の違いとは？課題の状態を正しく理解しよう

ステータスを個別の課題に置き換える

タスク管理表の「K列:ステータス」には [ドラフト][修正]など意味合いが曖昧なものがあります。これらは何らかの作業をして、成果物を提出するものと想像できます。

このように、設定したステータスが実はタスクや作業そのものを指している場合もよく見受けられます。その場合、ステータスとして管理するのではなく、個別の課題として管理するほうが見通しが良くなります。タスクとして扱うことで「何を」「誰が」「いつまでに」やるのかを明確にし、現状の把握を容易にします。

CHECK3 タスクの粒度を整理しよう

タスク管理表のG列：開始日（予定）〜J列：終了日（実績）を見ましょう。それぞれのタスクにかかる日数にかなりのばらつきがあります。

粒度をどのくらいに設定すべきかは、プロジェクトや業務の性質によってもまちまちですが、できればタスクの大きさを揃えておくと、作業量の見積や進捗確認などプロジェクトの見通しが良くなります。

おすすめの粒度

目安としてお勧めなのは、課題を登録する際に大体1営業日から長くて2〜3営業日で完了するぐらいの大きさにすることです。長すぎると、途中経過が発生してしまいシンプルな4つの状態で把握するのが難しくなり、プロジェクトの見通しが悪くなります。また、短すぎると課題登録・更新の手間が煩雑になります。

ただし、現実には業務の性質によってはここで紹介した運用が難しい場合もあります。その場合は、成果物の大きさや難易度など、別の指標に着目して大きさを揃えると良いでしょう。

開始日を「何となく」で設定しない

現実には1日あれば終わるタスクでも、余裕を見て1週間単位で設定することはありませんか？

もちろんある程度のバッファを見ておくことは大事ですが、行き過ぎるとプロジェクトの見通しを損ない、正確な進捗把握を困難にします。できるだけ実情に即した開始日・期限日の設定を心がけましょう。

まとめ

スプレッドシートによるタスク管理表には、各部署の先人から受け継いだ様々な効率化のノウハウが詰まっています。

ですが、それらはタスク管理ツールへの移行の障害となるばかりか、業務やプロジェクトの可読性を損ない、プロジェクトの見通しを悪くする危険もあります。ちょっともったいない気もしますが、時には大胆に捨て去る勇気も必要です。

スプレッドシートからBacklogへの移行で何か不明な点がありましたらチャットサポートまたはこちらのフォームまでお気軽にお問い合わせくださいね💡

スプレッドシートからBacklogを検討する