ワークフローの基盤を構築

Asanaでワークフローを構築する

前に、ワークフローが適切に機能するように基盤を設定しておく必要があります。 この記事は3部構成のシリーズの2本目です。 パート1の記事はこちらからご確認ください。

ワークフローの構成要素

buildingblocks

組織

組織は会社の共通メールドメインに基づいて、Asanaを利用する会社の従業員全員が1か所でつながることのできるスペースです。

チーム

組織の中で、従業員はチームに分かれてプロジェクトやタスクに共同で取り組みます。 組織内のすべてのユーザーは、少なくとも1つのチームに属していますが、複数のチームに属することができます。

プロジェクト

プロジェクトでは、特定のイニシアチブ、目標、大型案件に関連するすべてのタスクを整理できます。 プロジェクトではセクションを使ってタスクを整理します

タスク

タスクは、Asanaのアクションの基本的な単位です。

サブタスク

サブタスクを使うと、タスクの作業をより小さなパーツに分割し、複数のメンバーに分配することができます。

コメント

タスクにコメントして、質問や情報の追加、ヒントの共有などをすることができます。

ワークフローを設定する際の判断ポイント

次に、ワークフローが適切に機能することを確認するには、一連の重要な決定を下す必要があります。

decision1

意思決定1 :プロジェクトまたはタスク

チームが尋ねる最も一般的な質問は、ワークフローをプロジェクト内またはタスク内に収めるかどうかです。

まずワークフロー全体を格納するためにプロジェクトを作成することをおすすめします

プロジェクトでは、関係者との調整が1か所で行えます。 タスクやサブタスクを追加して、実行すべき仕事を表示します。 「プロモーション」のように曖昧すぎるタスクは実行が困難です。 タスクを実行可能にするために、仕事を細分化しましょう。

判断2:セクションをどう使うか?

ワークフローを仕事が移動する主な2つの流れ、シーケンス(順序)とステージ(段階)を理解しておくと、プロジェクトのセクションの使い方を決めやすくなります。

sequences

配列

シーケンスはチェックリストのようなものです。仕事は特定の順序で完了し、最終成果物まで作成されます。 イベントの計画や新入社員のオンボーディングはシーケンス型ワークフローの典型的な例です このような場合は、リストビューでプロジェクトを設定し、セクションを使ってタスクをカテゴリや期間で分けるとよいでしょう。

stage

ステージ

ステージはパイプラインのようなもので、1つの成果物が一連のステージを経て完了します。 リクエストのプロセスや製品開発向けのパイプラインでは、ステージベースのワークフローがよく活用されます。 このような場合、ボードビューでプロジェクトを設定し、セクションを使って各ステージを見える化するとよいでしょう。 タスクはそれぞれの成果物を示し、あるステージから次のステージへ進むにつれ、次のセクションへと移動します。

判断3:どのカスタムフィールドを追加するか?

早い段階でカスタムフィールドについて検討を始めましょう。 ワークフローでの整理や自動化、レポートのやり方は追加したフィールドに左右されます。

organize

整理する

ワークフロー内でタスクをどのように整理する必要があるか? 分類に使用している特定のカテゴリを表すカスタムフィールドを作成しましょう。

automate

自動化

ワークフローをどのように自動化しますか? 追加したフィールドに応じてカスタムルールを作成できます。

report

レポート

ワークフロー内でレポートする必要があるのは何ですか? プロジェクトダッシュボードでは、設定されているカスタムフィールドに応じてチャートを表示できます。

判断4:いつサブタスクを使うか?

subtaskst


時には1つのタスクや成果物を小さい一連のステップに細分化する必要があります このような場面に遭遇したらサブタスクを活用しましょう。

プロジェクトを使わず、タスクとサブタスクだけでワークフロー全体を構築するアプローチには 注意が必要です。 このやり方は自動化を追加したいときや、タイムラインビューを使いたいとき、あるいは仕事についてレポートしたいときなど、後々問題を引き起こす恐れがあるためです。

サブタスクの一般的な用途

task request

お客様からのリクエストをタスクで表している場合サブタスクを使ってフォローアップのステップを示してみましょう

task request

トップレベルのタスクで複数名のメンバーから仕事を承認してもらう必要がある際は、サブタスクとして承認リクエストを追加しましょう。

task request

ワークフローの

なかには、特定の条件を満たす際に起きるアクションを持つものもあります。 たとえば、リクエストを管理するチームが、リクエストを進める前に詳しい情報を必要とするなど、一定の条件を求めるケースです。 このような場合はルールを使って、特定のステージにタスクが進む際にサブタスクを追加しましょう。

サブタスクにセクションを追加できることをご存知 でしたか? キーボードショートカットは「Tab + N」です。

原則として、10個以上のサブタスクを加える場合は、タスクとサブタスクの代わりにプロジェクトとタスクを作るとよいでしょう。

意思決定5 :プロジェクトは1つですか、それとも複数ですか?

ワークフローの規模が大きく、複数のプロジェクトにまたがることがあります。

複数のプロジェクトを使用するべきケース

task requestワークフローは、すでに自分

のプロジェクトを使用している別のチームと連携します。 たとえば、あるチームはあるプロジェクトでストーリーの出版物を追跡し、別のチームは今後のミーティングで同じ項目について話し合う必要があるかもしれません。 そこでチームは両方のプロジェクトに関連するタスクを追加します
task request

ワークフローのフェーズに

は非常に多くのタスクが含まれているため、すべてが1つのプロジェクトに存在するにはあまりにも多くのノイズが発生します。 たとえば、あるチームが1つのプロジェクトを使ってリクエストの受信トレイを管理していても、大量のリクエストを受け取っているとします。 そこで、別のプロジェクトを作成し、進行中のリクエストに対応します。 カスタムルールを使用して、このプロセスを自動化します。

判断6:プロジェクトの権限をどう決めるか?

local field

権限の設定の仕方

によってワークフローの働きが変わります。 プロジェクトのメンバーには、編集権限またはコメント権限のみを与えられます。 コメント限定の権限を持つメンバーはプロジェクトの閲覧やコメントの投稿はできますが、編集はできません。

 

コメント限定の権限は、Asana Premiumをご利用のチームと組織のみが利用できます。

詳しく見る

 

ほとんどのワークフローでは、プロジェクトメンバーが自分のタスクでアクションを実行できるように、プロジェクトメンバーに編集権限を付与する必要があります。 コメント限定の権限は、次のような場合におすすめします。プロジェクトを公開するには、タスクを担当していない多くの関係者がプロジェクトを閲覧できるようにする必要があります。 プロジェクトには機密情報が含まれているため、偶発的または不必要な変更を防ぐ必要があります。

権限の詳細についてはこちらをご覧ください

ワークフローの基礎を設定したら、次はワークフローの節目を自動化していきます。 本シリーズの次の記事をご覧ください