本文へスキップ
機能の詳細

プロジェクトの工数

何に使った時間か、わかるうちに記録する

Timeで利用できるプロジェクト作業を選び、内容を書いて計測。作成した記録にはタスクとプロジェクトの参照が残ります。

説明用の例実際のプロジェクトタスクで時間を計測

仕事を特定できる間に工数を残す

忙しい一日を記憶から復元すると、複数の顧客案件を混同しがちです。プロジェクト作業にタイマーを結べば、どの案件と顧客の文脈かが明確になります。Tsumiraは対応する作業参照をTimeへつなぎます。操作する本人が自分のセッションを開始、停止、確認でき、別に非公式な時間表を作り続ける必要を減らせます。

実際に使える作業を選ぶ

Timeの選択肢は、関連する作業文脈から提供されるプロジェクトとタスクの参照を使います。名称とリンクがあるため、自由入力の案件名だけより根拠が明確です。限定プロジェクトの公開範囲や担当の規則も適用されます。古い識別子を知っているだけで、利用できなくなったタスクを選べるわけではありません。今回の作業に合う対象を選びます。

  • 対応するプロジェクト・タスク参照
  • 作業文脈に名称とリンク
  • 選択時にも利用可能性と権限を確認

意図して開始し、確認できる記録へ

作業の説明と請求対象かどうかを設定します。現在の手順では、一人につき一つの実行中タイマーを持てます。停止すると時間記録が作られ、仕事の根拠にしない場合は別途破棄します。何をしたかが明確なうちに説明と対象を確認してください。経過した時間だけで、顧客に提供した内容まで十分に説明できるとは限りません。

  • 一人一つの実行中タイマー
  • 作業説明と請求対象の設定
  • 停止で記録、必要なら明示的に破棄
説明用の例停止して記録するか、明示的に破棄

工数・完了・価格を分ける

タスクの見積は予定工数で、タイマーは実際の作業セッションです。止めてもタスクの完了を意味せず、タスクを完了しても時間承認の代わりにはなりません。記録はTimeの確認と承認へ進みます。対応する財務上の価格設定や請求は、その後の別判断です。明確なタスク参照は金額の理由に役立ちますが、測ったすべての分が自動で請求されるわけではありません。

  • 見積と実際のセッションを区別
  • タスク完了と時間承認を分離
  • 財務利用前に記録を確認
具体的な業務の流れ
  1. 作業文脈を選ぶ

    開始前にTimeで利用できるプロジェクトタスクを選びます。

  2. 活動を説明

    実際に行う仕事と請求対象の扱いを記入します。

  3. 計測して停止

    タイマーを開始し、セッションの終わりに止めて時間記録を作ります。

  4. 記録を確認

    内容と対象を確認し、必要な提出・承認手順へ進めます。

実務を想定した例

例:顧客仕様のレビュー

担当者は顧客プロジェクトの仕様確認タスクを選び、作業内容を書いてタイマーを開始します。確認作業が終わったら停止し、できた記録を見直します。成果を同僚が確認するため、タスク自体はレビューのままです。時間は別に提出できるので、費やした工数と成果の最終確認を混ぜずに管理できます。

この機能についての質問

タイマーが作業内容を自動監視しますか。

いいえ。本人が意図して開始し、作業の文脈を指定します。従業員の自動監視として説明するものではありません。

複数案件のタイマーを同時実行できますか。

現在の手順は一人につき一つです。次の開始前に、実行中のセッションを停止または破棄します。

止めるとタスクも完了しますか。

いいえ。計測と実行状態は別です。タスクは実際の成果に合わせて更新します。

停止した時間はすぐ請求されますか。

いいえ。Timeの確認・承認を通り、請求対象や対応する価格設定も別の条件になります。

この業務に合う連携を検討する。

想定される連携のアイデアです。シナリオを利用する前に、各アプリの実際の利用可否、権限、対応データをご確認ください。

すべての連携を見る

会社の仕事を、ひとつにつなぐ。

チームとともに、具体的な業務フローから始めましょう。

無料で始める