チェック欄だけでは仕事は伝わらない
「提案を準備する」という依頼も、どの案件で、誰が、いつまでに何を仕上げるのかがわからなければ動けません。Tsumiraのタスクはその文脈をまとめて持ちます。小さな確認事項をすぐに記録し、大きな成果物には詳しい説明を追加できます。個人ごとの別リストに仕事を分散させず、プロジェクトの中で整理して進められます。
仕事と成果を具体的に説明する
タスクにはタイトルと説明があり、対応するエディターでは構造化した説明内容も扱えます。開始日、期限、見積分数は、計画に必要な場合に追加します。親タスクやマイルストーンを指定すれば、小さな作業がどの成果につながるのかも明確です。見積時間は予定の情報であり、実際に働いた時間を示すタイムシートではありません。
- タイトルと詳しい説明
- 開始日・期限・見積時間
- 親タスクとマイルストーンへの関連付け
担当と状態を明確にする
有効なプロジェクトメンバーを担当者に選び、低・通常・高・緊急の優先度を設定します。状態はバックログ、準備完了、進行中、ブロック、レビュー、完了、中止を区別します。ブロックの理由を書けば、進まない原因を周囲も判断できます。レビューを完了から分けることで、作成は終わったが確認が必要な成果を正しく引き渡せます。
- 複数の担当者を設定
- 七つの作業状態を区別
- 優先度とブロック理由を共有
顧客の文脈と変更を整える
タスクは通常、プロジェクトの顧客を引き継ぎます。必要な場合は、対応するCRM顧客参照をタスク独自に指定できます。更新時には現在の版を確認し、古い画面からの編集が新しい変更を黙って上書きすることを防ぎます。プロジェクトをまだ選ばず作成する場合は受信箱が受け皿になり、素早い記録にも整理された置き場所ができます。
- プロジェクト顧客の継承と明示的な変更
- 同時更新を確認
- 受信箱ですぐにタスクを記録
具体的な業務の流れ
必要な仕事を記録
期待する成果を書き、プロジェクトを選びます。判断前の依頼は受信箱で受け止めます。
担当を決める
担当者、優先度、日付をそろえ、実行する人と依頼する人の認識を合わせます。
状態を更新
着手し、進めない理由があれば示し、成果ができたら必要なレビューを依頼します。
成果を完了する
確認済みの仕事を完了にし、引き継ぎ事項を関連するプロジェクトの会話に残します。
実務を想定した例
例：顧客ワークショップの準備
責任者は顧客プロジェクトに「ワークショップの議題を準備」を作り、進行役と開催前の期限を指定します。参加者の質問収集は子タスクとして整理します。外部からの回答が必要ならブロックにして理由を記録し、議題ができたらレビューへ進めます。別の表を増やさなくても、準備の流れと最後に必要な確認がプロジェクト内でわかります。
この機能についての質問
担当者を複数にできますか。
はい。複数の担当者を設定できます。その場合も、誰が成果を準備し誰が確認するかを説明に書くと、共同作業の責任が曖昧になりません。
プロジェクトを決めずに作れますか。
素早いタスク作成では会社の受信箱プロジェクトを利用できます。正式な所属を決める前でも、基礎となるプロジェクトのないタスクにはなりません。
見積分数は請求できる実績ですか。
いいえ。見積は計画値です。実際の作業時間、承認、請求の扱いは、つながるTimeの処理で管理します。
完了にすると請求書が発行されますか。
いいえ。完了は作業の状態です。請求候補、受入れ、財務書類はそれぞれ別の確認手順を通ります。
この業務に合う連携を検討する。
想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。
