稼働計画テンプレート
信頼できる要員判断を支えるリソース稼働状況トラッカー
要員配置を確定した後で休暇やサポート当番が判明しないよう、稼働状況を十分な頻度で更新します。
5ユーザーまで無料。クレジットカードは不要です。
コードを書かずに、項目・ワークフロー・ダッシュボードを調整できます。 1,000以上のアプリテンプレートと活用例を見る
サンプルアプリを確認するにはサインインし、サンプルデータ付きでインストールしてレコードと審査経路を試します。
このトラッカーの役割
リソース稼働状況トラッカーは、基準となる勤務パターンと、承認済みの休暇、研修、運用サポートなどの変更を組み合わせ、現在のアサインと次に使える日付を示します。不要な個人情報は公開しません。
- 基準値と変更を分けて管理
- 復帰日を可視化
- 計画に個人情報の詳細は不要
稼働状況の情報源
実際に変化するレコードから計画情報を作成
「稼働可能／不可」の選択肢だけでは情報が足りません。
| 情報源 | 計画に必要な情報 | 非公開にする情報、または別システムを正本とする情報 |
|---|---|---|
| 勤務パターン | 計画期間の勤務時間と勤務日 | 雇用契約の詳細 |
| 承認済み休暇 | 開始日、終了日、影響工数、復帰日 | 機密性の高い医療上または個人的な理由 |
| 研修 | 日程、工数、出席確定の有無 | 学習評価の詳細 |
| 運用サポート | 保護された工数または対応時間帯 | チケットまたはインシデントの内容 |
| 現在のアサイン | 日程、工数、状態、優先業務の保護 | 詳細なタスク実行 |
要員配置への引き継ぎ
稼働状況は選定判断の全てではなく、入力情報として使う
カレンダーに空きがあっても、スキルや適性があるとは限りません。
対象期間を確認
業務需要とアサイン案に同じ日程を使います。
スキルとレベルを確認
人材プロファイルを開き、提案の根拠を残します。
既存の確約を確認
保護された業務と、突発業務に必要な余裕を含めます。
承認、差し戻し、代替要員の選択
別の予約を黙って上書きせず、影響を記録します。
データ保守
HRISを重複させず、稼働状況レコードを最新に保つ
各入力に責任者と更新ルールを1つずつ設定します。
固定の担当者ID
取り込みまたは同期した稼働情報を正しい人に紐づけます。
承認状態
承認または確定された不在だけを、確定済みの計画前提に反映します。
適用日
復帰日が分かっている場合、無期限の稼働不可状態にしないでください。
修正経路
古い勤務パターンや漏れているサポート当番を報告できるようにします。
必要最小限の詳細
不在の機密情報ではなく、計画への影響を公開します。
実務的な質問
稼働状況データを信頼する前の質問
情報源、更新ルール、プライバシー境界、カレンダーの空きと適切なアサインの違いを定義します。
稼働状況トラッカーには週次工数だけを保存すればよいですか？
工数は実用的な共通尺度ですが、それだけでは十分ではありません。この例では、計算上は空いていても適任ではない人を選ばないよう、スキル、役割レベル、タイムゾーン、稼働可否、日程、優先度、進行状況も工数と並べて管理します。 計画レコードには、適用日、休暇・研修の影響、現在の確約、スキル、次回稼働可能日も必要です。
チーム管理者は稼働状況の情報源やビューを変更できますか？
トレーニングを受けたJodoo管理者なら、従来型アプリを作り直すことなく、項目、選択肢、ビュー、ルーティング、ダッシュボードを追加できます。ただし、特に承認、アクセス権、レポート指標に影響する変更には、責任者による管理、テスト、周知が必要です。 人事部門が管理する情報、プライバシー境界、承認状態を明確に統制しながら、アプリを変更できます。
休暇はこのアプリに直接入力すべきですか？
小規模な単独プロセスなら可能ですが、既存の人事・休暇システムがある場合は、そちらを正本とします。承認済みの日程と計画への影響だけをリソースプロセスに取り込み、機密性の高い理由を複製しないでください。
「稼働可能」なら、その人をアサインすべきですか？
いいえ。稼働可能はキャパシティが存在する可能性を示すだけです。要員判断には、スキル、役割レベル、タイムゾーン、現在の業務、優先度、引き継ぎコスト、本人の上司またはキャパシティ責任者も考慮します。
稼働状況はどのくらいの頻度で更新すべきですか？
計画期間と変動性に十分対応できる頻度で更新します。直近の要員配置は毎日、中期予測は週次の定期更新でも対応できます。変更の適用日と責任者は必ず表示してください。
データ入りレコードから開始
変更前に実際に動くトラッカーを開く
通常、保留中、過負荷、変更済み、完了済みの例を確認し、チームに必要な項目とビューだけを残します。