こんにちは、Webディレクターのともぞうです。
LIGではプロジェクト管理ツールとして「Asana」を導入しています。最近、メンバーがAsanaをより有効的に活用できるように、あらためてガイドラインを作りました。そのときの話をシェアします。
前回の記事では、実際に作ったガイドラインの内容をご紹介しました。
Asanaの運用ルールを作った話〜ルールの紹介編〜
ともぞう
今回は、ワークロードの設定と、ガイドライン策定の進め方や適用方法について紹介します。
この記事が、最近Asanaを導入した、しようとしている方の参考になれば幸いです。
※ワークロード機能の画面はこんな感じ。こちらの記事でもご紹介していますので、ご覧ください。
ワークマネジメントツール「Asana」って？ 徹底的に使い倒しているディレクターの僕が、その魅力を本気でお伝えします！
ともぞう
ワークロードの設定内容の紹介
以下の3つの目的を実現するために、ワークロード機能を使って稼働量の見える化を目指しました。
- 無理のない人間的生活をするため
- 忙しすぎる人、暇すぎる人のギャップをなくす
- リソース調整のコミュニケーションコスト削減
3はおもにチームリーダー、Webディレクター向けのものです。LIGでは各メンバーのリソースをチームリーダー・マネージャーが把握しており、案件アサイン時にチームリーダーとリソース調整するフローになっています。いままでは都度口頭やチャットベースでリソースを相談していましたが、ワークロード機能によりいつでも視覚的に捉えられるようにすることを目指しました。
ワークロードの設定方法
以下の順序で設定してもらっています。
-
- ポートフォリオはチームリーダー・マネージャーがチーム単位もしくはグループ単位で作成する
- メンバー各自がポートフォリオに関わっている案件を追加する
- 表示するアカウントを対象メンバーに絞り込む
- 工数をEstimate M/Hに設定する
- キャパシティを設定する
- 各タスクの開始日と終了日を設定する
ポートフォリオにはプロジェクトを追加する必要があるのですが、漏れをなくすために当事者にも追加してもらうことを推奨しました。
ここでのポイントを抜粋して説明します。
工数をEstimate M/Hに設定する
ワークロードで用いる工数は、「Estimate M/H」というLIG独自のカスタムフィールドを用いています。
Estimate M/Hとは、このタスクがどのくらいかかりそうかを各自に入力してもらう想定見積です。単位は時間としています。極力2日にまたがない（8時間以内）ようにタスクを小さく分割することを推奨しています。ワークロードが開始日と期限の日数をもとに、工数を自動で均してくれるので、あまり意識せずとも1日あたりの想定稼働が見えるようになります。
このカスタムフィールドは、ふだん案件がはじまったときに使うAsanaのプロジェクトテンプレートにも追加してあるので、基本的にすべてのプロジェクトにEstimate M/Hが追加されている状態になっています。
キャパシティの設定
ワークロードではキャパシティの設定が肝です。キャパシティは1週間のうちで割ける稼働量のことで、LIGではキャパシティを以下で設定しています。
- メンバー：35hrs / 1week
- 1日7時間を作業に割ける時間と仮定
- リーダー以上：30hrs / 1week
- 1日6時間を作業に割ける時間と仮定
一般的には1日8時間労働だと思いますが、8時間ずっと作業できているわけではなく、社内打ち合わせなど作業外の業務も考慮する必要があるので1日7時間稼働としています。
打ち合わせやプロジェクトに直接紐付かないものもAsanaで管理する場合は、キャパシティを8 * 5の40hrsに設定しても問題ありません。しかしそこまでAsanaで管理することは難しいと考えたので、そもそものキャパシティを短くしています。
ワークロードを導入してよかったこと
いままで以上に無理がなく、現実的なスケジュールを引くことができました。Asanaのタイムライン上で仮スケジュールを引いたのち、ワークロードを見ながら各人のタスクを均すことで、無理のないスケジュールが引けます。
たとえば、プロジェクト単体で見れば4時間で終わる見込みになっていても、他のプロジェクトで6時間かかる見込みのタスクを持っていると、ワークロード上のキャパシティはオーバーすることになります。期日に間に合わせるには残業するしかありません。そういったバッティングに当人が視覚的に気づくことができるようになりました。
ガイドライン策定の推進方法
今回は2名体制でガイドラインを策定しました。私と同じWebディレクターのしげちゃんにサポートしてもらいました。なにか新しいことを始めるときは2名体制で取り組むことをおすすめします。
しげちゃんに手伝ってもらうにあたり、あらためて共有する情報を整理したり、考えを言語化する機会が生またりしたので、より理解を深めることができました。また、会話をすることで不明瞭だった部分も明らかになっていくのでとても助かりました。
一緒に推進している相手がいるというのは心理的にもとても楽になります。
3つのステップで作成する
3段階の精度で内容を詰めました。
- 骨子の作成
- 草案の作成
- 初版の作成
骨子・草案までは、箇条書きベースでどういうことを書きたいかを洗い出し、1行で簡潔に伝えることを意識しました。いきなり文章を書き出すのではなく、箇条書きで書いていき、肉付けしていくようにしました。
また、すべての段階でレビューをいれることで、できるだけ認識をあわせ手戻りを少なくしつつ、レビュアーが入れたい内容を吸い上げられるようにしました。
参考画像
▼骨子時点
▼草案時点
▼初版
初版では飽きられないように適宜画像を挿れたり、リンクや文字色をAsanaのガイドに合わせたりと、しげちゃんがいろいろと工夫をしてくれました。
ガイドラインのレビューのフロー
草案までのレビューはCTOのづやさんに、初版のレビューはデザイナー、フロントエンド、バックエンドのユニットリーダーに依頼をしました。各職能のリーダーの視点を入れたかったのと、今後ルールを普及させるためにもまずはリーダー陣に理解してもらいたかったためです。
このときのレビューの依頼方法は、「見ておいてください」と投げることはしませんでした。私含め全員で読み合わせをして、不整合がないか、こういうときはどうするかといった議論をしながら内容を詰めていきました。
現場への展開方法
もともとの目的が「リソースの見える化」だったため、まずはリソース管理者であるマネージャー・リーダー間での読み合わせを依頼。その後各チーム・グループの共有会などで各メンバーに共有してもらいました。
また、各ユニットではユニット会と呼ばれる定期的なミーティングがあります。その場でもユニットリーダーを中心にガイドラインの読み合わせをしてもらい、ガイドラインを見たことがないという状況を極力なくしました。
さいごに
簡単にですが、LIGでのワークロードの設定と、ガイドライン策定の流れを紹介しました。
ワークロードは最初の設定や運用が少し大変ですが、導入したあとの効果は大きいものだと思います。なんとなくで管理していたリソース状況が視覚化されるのに加えて、コミュニケーションコストも大きく下げてくれます。
この記事がAsana導入や、なにか新しいことへ取り組む際の参考になれば幸いです。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
