ワークフローの基礎を築く

組織

組織は、Asana を使っているあなたの会社のすべての従業員が、会社の共有メールドメインに基づいて、つながることのできるスペースです。

チーム

組織では、あなたや同僚はチームに分かれ、プロジェクトやタスクでコラボレーションを行います。組織内のユーザーは必ず少なくとも 1 つのチームに所属します。複数のチームへの参加も可能です。

プロジェクト

プロジェクトでは、特定のイニシアチブや目標、大規模な仕事に関連するタスクのすべてを整理できます。プロジェクト内ではセクションを使用してタスクを整理できます。

タスク

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

サブタスク

サブタスクを使ってタスクの作業をさらに小さなパーツに分けたり、作業を複数名のメンバーに分割したりできます。

コメント

タスクでコメントを投稿して、質問をしたり、追加の情報を提供したり、インサイトを提示したりできます。

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

続いてワークフローが適切に機能するように、いくつか重要な決断を下す必要があります。

判断 1: プロジェクトか？タスクか？

ワークフローをプロジェクトに組み込むべきか、またはタスクに組み込むべきかの判断に多くのチームが悩みます。

Asana では、まずはすべてのワークフローをプロジェクトに組み込むアプローチをおすすめします。

プロジェクトは、ステークホルダー (関係者) と調整を行う際の主要な場として機能します。タスクやサブタスクを追加して、実行可能な作業を表示しましょう。「プロモーション」のようなタスクは曖昧すぎるため、より実行しやすいタスク名に変えるべきです。

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

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

シーケンス

シーケンスはチェックリストに似ています。最終的な成果物にたどり着くまで、特定の順序で仕事を完了していきます。イベントの企画や新入社員のオンボーディングがシーケンス型ワークフローの典型的な例です。このような場合には、リストビューでプロジェクトを設定し、セクションを使ってカテゴリまたは期間を表して、タスクを分類しましょう。

ステージ

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

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

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

整理

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

自動化

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

レポート

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

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

単一のタスクや成果物をさらに小さな、一連のステップに分割しなければならないこともあります。このような場面に遭遇したらサブタスクを活用しましょう。

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

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

リクエストがトップレベルのタスクとして表される場合は、サブタスクを使ってステップを細分化できます。

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

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

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

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

判断 5: 1 つのプロジェクトか？複数のプロジェクトか？

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

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

ワークフローが、すでに自前のプロジェクトを持つ別のチームと関わるケースが該当します。たとえば、あるチームが、あるプロジェクトで記事の投稿を追跡確認している一方で、別のチームが同じ記事を次回のミーティングで取り上げる必要があるときです。この場合、双方のチームはそれぞれのプロジェクトに関連するタスクを追加することになります。

ワークフローの一部のフェーズに大量のタスクが集中し、1 つのプロジェクトですべてを網羅しようとすると混乱が生じる恐れがある場合も、複数のプロジェクトを作成するべきです。たとえば、1 つのプロジェクトを用いて 1 種類のリクエストを受け付けて管理していて、大量のリクエストが寄せられた場合です。このようなケースでは、チームは処理中のリクエストに対応するための専用プロジェクトを作成します。カスタムルールを介してこのプロセスを自動化できます。

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

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

大半のワークフローでは、プロジェクトメンバーがそれぞれのタスクでアクションを起こせるように、メンバーに編集の権限を与える必要があります。ただし、次の場合においてはコメント限定の権限の利用をおすすめします。

• タスクを担当しない多くのステークホルダーにプロジェクトを公開する必要がある場合。
• プロジェクトに機密情報が含まれ、誤った変更または不要な変更を防ぐ必要がある場合。

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

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