レコード、役割、ルール、導入
リソース管理システムの設計方法
まず、需要、人材、稼働可否、申請、アサインのレコードを定義します。キャパシティの分母や担当者不在の承認が未定義のままでは、ソフトウェアでも解決できません。
サンプルアプリを確認するにはサインインし、サンプルデータ付きでインストールしてレコードと審査経路を試します。
設計原則
リソース管理システムとは、需要と実働可能キャパシティを合わせるためのレコード、役割、ルール、レビュー頻度、指標、ソフトウェアの組み合わせです。1つの計画期間と少数の判断から始め、入力情報への信頼が得られてから拡張します。
- 設定前に定義を固める
- 計画情報ごとに責任者を1人設定
- 初回導入では画面数ではなく判断を検証
システム設計
変化する情報ごとに明確な責任者を置く
レコードを分けることで曖昧さを減らし、システム連携も可能になります。
| レコード | 最低限必要な項目 | 業務責任者 |
|---|---|---|
| 人材・スキルプロファイル | 固定ID、チーム、レベル、スキル、勤務キャパシティ、次回稼働可能日 | キャパシティ管理または人員運用担当 |
| 稼働状況の変更 | 担当者、種類、開始日、終了日、影響工数、承認状態 | 本人と承認マネージャー |
| 業務需要 | 成果、担当者、スキル、レベル、工数、日程、確度、優先度 | プロジェクト、サービス、ポートフォリオ責任者 |
| 要員申請 | 需要、候補者、工数、日程、適合度、競合、判断 | リソースまたはキャパシティ責任者 |
| アサイン | 確定業務、担当者、工数、日程、状態、保護設定、進行状況 | デリバリー責任者とキャパシティ責任者 |
| 例外 | シグナル、影響を受けるレコード、重大度、判断、担当者、期限 | 指名された意思決定者 |
意思決定権
ワークフローを作る前に運用ルールを合意
責任を明確にしつつ、すべての変更を委員会任せにしないシステムにします。
需要責任者
業務、成果、日程、必要能力、優先度を定義します。
キャパシティ責任者
計画前提を維持し、複数業務間の競合を審査します。
人材マネージャー
不要な人事情報を公開せず、稼働可否と能力の制約を確認します。
デリバリー責任者
業務開始後の進行状況と計画・実績の変化を報告します。
導入手順
繰り返し発生する1つの判断を最初から最後まで試行
広範囲でも受動的な台帳より、小さくても完結したループの方が多くを学べます。
定義と境界を合意
計画期間、キャパシティの分母、需要状態、承認時点、正本システムを決めます。
整理済みの実データを取り込む
稼働中の人材、現在の稼働状況、確定業務、限定的な予測を読み込みます。
実際の要員判断を実行
代表的な申請で、提出、差し戻し、承認、アサイン、訂正を行います。
指標と運用上の摩擦を確認
拡張前に、古い入力、未解決のギャップ、判断時間、日程変更、ユーザーによる修正を確認します。
指標
システムによって判断が改善したかを測る
高い稼働率だけを成果指標にしないでください。
要員判断までの時間
不備のない申請から、承認、差し戻し、却下の結果が出るまで。
未充足需要の経過日数
着手可能な業務に妥当な要員が決まらない期間。
開始前に解消した過負荷
計画業務の開始前に修正できた競合の割合。
計画精度
業務種類・計画期間別の計画工数と実績工数の差。
修正率
ユーザーが古い稼働状況、スキル、需要前提を修正する頻度。
実務的な質問
設定前に決めるべきシステム設計の質問
正本レコード、意思決定者、レビュー頻度、実際の要員判断を検証する初回導入を決めます。
リソース管理システムでは、どの計画単位を使うべきですか？
工数は実用的な共通尺度ですが、それだけでは十分ではありません。この例では、計算上は空いていても適任ではない人を選ばないよう、スキル、役割レベル、タイムゾーン、稼働可否、日程、優先度、進行状況も工数と並べて管理します。 チームが継続的に管理できる分母を選び、スキル、日程、稼働可否、優先度を併記して、数値を解釈できる状態に保ちます。
リソース管理システムには初日から自動最適化が必要ですか？
いいえ。人が判断できるように、キャパシティ、スキル、日程、ワークロード、競合の根拠を可視化する仕組みです。大規模環境では自動最適化が有効な場合もありますが、合意済みの制約や優先順位、専門機能が必要です。Jodooは、業務部門が運用ルールや承認経路を柔軟に設計したい場合に特に適しています。 まず、信頼できる入力と責任者のいる審査から始めます。高度な最適化でも、曖昧な定義や欠けた意思決定権は補えません。
リソース管理システムを変更できるのは誰ですか？
トレーニングを受けたJodoo管理者なら、従来型アプリを作り直すことなく、項目、選択肢、ビュー、ルーティング、ダッシュボードを追加できます。ただし、特に承認、アクセス権、レポート指標に影響する変更には、責任者による管理、テスト、周知が必要です。 トレーニングを受けた業務管理者を任命し、承認、アクセス、指標の変更は統制・テストできるようにします。
従業員の稼働状況はどのシステムで管理すべきですか？
既存の人事、休暇、要員管理システムを正本とし、リソース判断に必要な承認済み計画情報だけを取り込みます。小規模なプロセスなら、Jodooの例で稼働変更を管理したり、連携によって調整したりできます。
最初の導入範囲には何を含めるべきですか？
繰り返し需要と実際の要員判断がある1チームを選びます。通常、過負荷、稼働不可、差し戻し、承認済み、変更済みの各ケースを含めます。取り込んだレコードを表示するだけでは、より良い判断に役立つかを検証できません。
設計から実用システムへ
自社向けに設定する前に、一連の計画サイクルを確認
人材と需要から、審査、アサイン、例外、計画・実績の学習まで、データの流れをたどります。