Asanaでのタスク管理：ガイドライン作成から運用までの成功と失敗事例

こんにちは！World SceneのDX担当です。

World Sceneでは、日々の業務のタスク管理にAsanaを活用しています。導入のきっかけは忘れてしまいましたが（おそらく代表のあらたけが「Asana入れよ！」って言ったんだと思う）、導入して少し経ったころに社内用のガイドラインを策定しました。

今回は、ガイドラインを作った背景から、実際のガイドライン、そして作ってみて気づいたことをご紹介したいと思います。

なぜAsanaのガイドラインを作ったのか？

タスク管理のためにAsanaを導入した弊社ですが、導入直後からガイドラインがあったわけではありません。最小限の設定をして、「こんな感じで使いましょう！」と社内に展開するだけで、なんとなくAsanaを活用できていました。これはAsanaが比較的わかりやすいツールであることや、弊社の人数が少ないことが要因だと思っています。

ただ、導入してしばらくすると、メンバー・チームによって微妙に使い方が異なることがわかってきました。例えば下記のような部分です。

• 登録するタスクの粒度の違い
• 詳細を記入する、しない
• コメント機能を使う、使わない

些細な違いかもしれませんが、チームごとに異なる使い方をしているため、「今どのくらい業務を抱えているのか？」「進捗率はどのくらいなのか？」といったことを把握するのが難しくなってしまいました。

そこで、Asanaをより良く活用するために、ガイドラインを策定し、使い方を統一することになりました。

実際に作ったAsanaのガイドラインを紹介！

ガイドラインを策定するにあたっては、他の会社様のタスク管理方法や、Asanaの活用事例を調べることにしました。そのときに見つけた株式会社LIG様の記事が一番参考になったため、弊社のガイドラインにも一部取り入れさせていただいています。

ここからは、実際に策定したガイドラインを一部ご紹介します。

タスク名は「何を + どうする」の構成にする

例えば「Asanaの記事」というタスクがあったとき、タスク単体で見ると、Asanaの記事を「執筆する」のか、「添削する」のか、「サイトにアップする」のか分かりませんよね？
弊社は人数が少なく、さらにそれぞれのメンバーの役割がはっきりしているため、まだ問題はなかったのですが、人数が増えたり、メンバーの担当業務の範囲が広がったりすることを考えると、あまりいいタスク名とは言えません。

そこで、「Asanaの記事の執筆」といったような「何を + どうする」のか分かるタスク名をつけることをガイドラインにしました。

サブタスクは原則使用禁止、タスクは最小単位で

サブタスクを使用したいと思うのは、タスクの中身を細分化し、それぞれの進捗を管理していきたいというニーズがあるときだと思います。
しかし、Asanaの仕様上、サブタスクは「デフォルトで表示されないため認知しにくい」「タスクのカウントがおかしくなる」などの理由があり、弊社ではあまり使用しない方がいい、という判断をしました。

また、タスクは最小単位で登録するというガイドラインを策定しました。ガイドライン策定以前は、例えば10本の記事作成をしないといけない場合、「記事作成10本」といったタスクの中に、サブタスクを10個紐づける、といった管理をしているメンバーもいました。ですが、前述した理由からサブタスクを使用しないことになったため、タスクを最小単位に分けて10個作ってもらうことにしました。

タスクはAsanaで、共有はSlackで

弊社ではコミュニケーションツールとしてSlackを使用しているため、普段のやりとりはSlackで行います。
やりとりの中で「あれやっといて！」「これお願いします！」などタスクが発生するのはあるある。期限まで少し期間が空く場合、そのままタスクが流れてしまう可能性が高いです。
そのため、タスクは依頼する人がAsanaに登録し、そのURLをSlackで共有してコミュニケーションをとるようにしました。

ここで紹介したのはガイドラインの一部ですが、これ以外にもタスクについてのガイドラインをいくつか策定しました。

また、Asanaの「レポート」という機能を活用し、タスクの進捗をグラフで見れるよう、これについてもガイドラインを策定しました。

ガイドラインを作った”だけ”じゃ、Asanaをうまく活用できない

上記のようにガイドラインを策定し、「これでAsanaをうまく活用できるぞ！」と思っていた私たちですが、これが大間違いでした。
社内にガイドラインを展開した当初は、ルール通り活用できていたと思います。しかし、時間が経つにつれ、次のような問題が出てきました。

ついついSlackでタスクを依頼しがち

ガイドラインで策定したSlackとの使い分けですが、その場で完了するちょっとしたタスクはついついSlackで依頼しがちです。それが悪いこととは思いませんが、それにつられて大きめなタスクもSlackで依頼、完了までしてしまうケースも目にするようになりました。

レポート機能、全然活用しない！

タスクの進捗を図るために活用したかったレポート機能ですが、普段から頻繁に見る習慣がありませんでした。週次で行なっているチームMTGでAsanaのレポートを見る習慣が付けきれず、Asanaはタスクを入れておくだけの単なる箱になってしまいました…。

ガイドラインを”活用”するためには、定期的に見直す必要がある

上記の問題が起こってしまって気づいたのは、「ガイドラインは変化していくべきである」ということです。

ガイドラインを策定してしばらく経てば、業務内容や範囲が変わったり、メンバーが増えたり、など会社として変化があるのは当たり前のこと。そして、変化があれば決めたガイドラインが合わなくなったり、足りなくなったりするのも当たり前です。

ガイドラインを作って満足してしまい、フェーズに合わせて見直すことをしなかったのが、弊社DX unitの反省点でした。
失敗に気づいた我々ですが、今後は次のようにガイドラインをアップデートしていきたいと思っています。

定期的にメンバーへのヒアリングを行う

ガイドラインを策定しても、実際に使ってみたらやりにくい…なんてことがあるかもしれません。定期的にヒアリングを行い、その時点での業務内容に対して、ガイドラインが適切かどうかのすり合わせを行います。

メンバーがAsanaを自然に使えるようなルールや仕組みづくり

「MTGでは必ずAsanaのレポートを見せて共有を行う」といった、Asanaを使わざるを得ない環境づくりも、定着への近道だと思います。DX unitメンバーが中心となって、Asanaの利用を呼びかけていきます。

ガイドラインを育てながら、Asanaと向き合っていこう

会社という複数人のチームでツールを活用する上でガイドラインを策定することは、Asanaに限らず、重要だと思います。しかし、ガイドラインを策定したことに満足してアップデートを怠ると、うまくツールを活用できなくなる時が来てしまうことが分かりました。

弊社のガイドライン策定、そしてその後の失敗が、これからAsanaやその他のツールを導入する方の参考になれば幸いです。

Asanaに限らずツールの導入や定着についてお悩みのある方は、ぜひお気軽にご相談ください！