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