スプレッドシートからBacklogにタスク管理を移行するコツをお伝えします！

by Nulab

2018年6月4日

チュートリアル

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

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

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

タスク管理の上手な進め方は、下記をご参照ください。
参考:タスク管理の上手なやり方とは？4つのステップとオススメツールを解説

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

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

あらゆる情報を「プロジェクト」というまとまりで管理

・情報が行き届く範囲を、プロジェクトとそこに参加するメンバーに限定することで、関係ないユーザに情報が漏れることを防ぐ
・自分が参加していないプロジェクトの情報は見れない

一つひとつのタスクに当たる最小単位を「課題」と呼ぶ

・課題には、「件名」「担当者」「期限日」など一定の情報フォーマットが存在する
・一つの課題につき一担当者のみ
・責任を明確にし、タスクを見える化

課題の状態は「未対応／処理中／処理済み／完了」の4種類のみ

・ステータスを限定することで、課題の進捗を一目で把握できる
・独自のステータスは設定できない　※

課題の階層は二階層（親子課題）まで

・階層をシンプルにすることで見通しよくする
・孫課題を作ることはできない
・代わりに以下の課題の分類を活用しましょう

種別	主に課題の性質の分類に使う（問い合わせ／要望／不具合／TODOなど）
カテゴリ	主に課題の内容の分類に使う（地域／対象物／制作物の種類など）
マイルストーン	主に課題の時期の分類に使う

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

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

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

Backlog-Excel-1 ▲クリックすると拡大表示

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

タスク管理の上手な進め方は、下記をご参照ください。
参考:タスク管理の上手なやり方とは？4つのステップとオススメツールを解説

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

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

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

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

４つの状態に当てはめる

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

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

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

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

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

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