
ワークマネジメントツール「Asana」って? 徹底的に使い倒しているディレクターの僕が、その魅力を本気でお伝えします!
こんにちは、Webディレクターのともぞうです。
弊社ではAsanaをプロジェクト管理ツールとして使用しているのですが、最近あらためて使用上のガイドラインを策定しました。
今回は実際に作ったガイドラインをご紹介します。
ワークマネジメントツール「Asana」って? 徹底的に使い倒しているディレクターの僕が、その魅力を本気でお伝えします!
Asanaってなに? という方はこちらの記事をご覧いただけますと。
目次
なぜAsanaの使用ガイドラインを策定したかというと以下の課題があったためです。
いわゆるリソース管理の面です。弊社ではチーム制をとっており、各チームリーダーがメンバーのリソース状況を把握しています。
把握方法は、週次のチーム会などで各メンバーから感覚的な報告をもらうことがメインで、なにか具体的な指標があるわけではありませんでした。
これを解決するために、Asanaのワークロード機能の活用を念頭に、ガイドラインを策定しました。
プロジェクトはおもにWebディレクターが仕切ることが多いのですが、これまではそれぞれが自由にAsanaを使ってしまっていました。それぞれがそれぞれの方法でタスクを登録するため、バラツキがうまれ、結果的にリソースの把握も難しい状態になっていました。
そこで、タスクのサイズやタスク名の推奨例を挙げることで解決を図りました。
以下を意識して作りました。
今回のガイドラインはWeb制作に携わるメンバー全員にお願いするものだったため、細かく定義しすぎず、ある程度の余白を設けるようにしました。ガイドラインというと堅いイメージですが、実際はガイドラインに近いものになっていると思います。
ちなみにAsanaは公式ドキュメントがとても充実しており、コミュニティの動きも活発です。機能の具体的な使い方や説明は公式ドキュメントを見るのが一番です。
Asana Guide
Asana Community Forum
どんなタスク名が望ましいのか、紹介をおこないました。
以下のようなタスク名を推奨しました。
逆にアンチパターンとして以下を挙げました。「なにを」のみになっており、どうするのかがわからない状態になっています。
このアンチパターンが発生するのは、たいていセクションを用いて意味を補完しているときです。デザイン制作セクションに属しているからページ名だけ入れておけばわかるだろう、という具合に。
しかし、あくまでタスク単体でみたときになにをすべきタスクなのかがわかるような名前が望ましいです。プロジェクトのタスク一覧はWebディレクターやプロジェクトマネージャーだけがよく見るものであって、作業者自身はマイタスクなどからタスク単体でしか確認しないことがほとんどだからです。
文字ベースの情報はどんなに書いても書ききれない……だからこそ書くべきだと考えました。
タスクの説明欄に書くべき事項として、以下を挙げました。
タスクの背景は記載が漏れがちですが、これの有無で作業者からのフィードバックも変わってきます。背景をもとに別の案を出してくれたりと、一気に精度が上がるので、できるだけ記載するように心がけています。
1つのタスクで複数のことをやろうとすることを避けるために設けました。
極端なアンチパターンですが、10ページのWebサイト制作において、「デザイン制作」と大きなタスクだけで表現することを良しとしないためです。
今回のガイドラインでは、極力1日(8時間)以下で終わるサイズに落とすことを理想としています。そうすることで、デイリーの朝会で進捗を確認でき、順調なのか遅れているのかが計測しやすくなります。またいつまでも完了しないタスクの発生を防げます。
Asanaのタスクをどう管理するかについてまとめました。
タスクの担当が変わるのは、リソース管理上好ましくありません。
たいていWebディレクターへ確認依頼としてタスクが渡りますが、そうなるとWebディレクターのリソースがワークロード上大変なことになってしまいます。逆にタスクを渡した作業者は、一時的にタスクを持っていない状態になるため、暇なように見えてしまい実際のリソースとギャップが生まれてしまいます。
そこで、担当変更はおこなわず、確認依頼用のタスクを作成する運用にしました。
Asanaにはフォローアップタスクを作成する機能があり、それを使用するようにしています。フォローアップタスクは元になるタスクのリンクが説明に記載された状態で、タスクが作成されるため、どういった経緯のタスクなのかが追いやすくなっています。
Asanaのサブタスクは以下の特徴をもっており、目的であったリソースの見える化とは相性が悪いと判断し使用を禁止しました。
ただし、他者確認が発生せず自己完結できるタスクや、各サブタスクが1時間以内に終わるサイズでの場合は使っても問題ないとしています。
個人のタスクをより細かく因数分解したいときに使うイメージです。
完了になった背景・理由をコメントしてもらうようにしています。第三者がタスクを見たときに、なぜ完了になったのかがわかるようにするためです。
AsanaとSlackのどちらもコミュニケーションを補助するためのツールなので、 役割があやふやになりがちでした。
そこで、それぞれで扱う情報の違いを挙げていきました。あくまでも意識なので、原則などにはしていません。
Slackなどのチャットツールを使っていると、ついついメッセージでタスクを依頼してしまうことがあります。
依頼を自分でタスク登録できるならいいのですが、チャットベースだと誰がボールを持っているかがわからなくなりがちです。しかもチャットで話を進めると、どんどん流れていってしまうので、スクロールして遡ったりと非効率になります。そのため、原則タスクをつくり、タスクベースで進めることを推奨しています。
Asanaドリブンのすゝめ。タスクベースで仕事を進めるメリットをお伝えします。
ちなみにAsanaとSlackを連携すると、Slackのメッセージをタスク化、タスクのコメント化ができるようになります。
ガイドラインの作成は、Asanaも推奨しておりガイドで紹介されています。
この記事が、最近Asanaを導入した、しようとしている方の参考になれば幸いです。次回はワークロードの設定についてと、ガイドライン策定の進め方や適用方法などについて紹介する予定です。
ちなみに今回のガイドラインは私ひとりで作ったわけではなく、しげちゃん、ユニットリーダー陣にサポートしてもらいました。一緒に考えてくれたり、フィードバックしてくれたりと時間を割いてくれてありがとうございました。この場を借りてあらためてお礼を述べさせてもらいます。