プラクティスのナレッジベース
リソース要求プロセス
リソース要求プロセスは、設備、予算、人員、時間といったリソースの明確な調達経路を定め、決定が個人的な交渉に依存しないようにします。
組織
resource-request-process
ドキュメントのセクション
これは何か
これは、従業員やチームが必要なリソースを要求し、決定の状況を確認するための作業手順です。このプロセスでは、基準、オーナー、回答期限、却下理由を明記します。このプラクティスは、遅延、隠れた承認プロセス、誰が設備、予算、人員、時間を割り当てられるかという論争の問題を解決します。
役立つとき
- チームが、人員、予算、設備、または追加時間の要求方法を知らず、タスクが遅延している場合。
- リソースに関する決定が個別のチャットで行われ、他のメンバーには、なぜある要求が承認され、別の要求が却下されたのかが理解できない場合。
- マネージャーが、完全な要求を最初から確認するのではなく、何度も確認に時間を費やしている場合。
- 要求のステータスが不明確になり、依頼者が誰が検討しているのか、いつ回答が得られるのかを理解できない場合。
- 緊急の要求と通常の要求に共通の基準がないため、優先順位をめぐって対立が生じる場合。
始め方
- 1 要求の受付チャネルを1つに決めてください。依頼者、リソース、理由、希望期限がわかるフォーム、スプレッドシート、またはタスクトラッカーを使用します。
- 2 プロセスのオーナーを任命してください。そのオーナーは、要求の完全性を確認し、決定権限者に回付します。
- 3 最低限の基準を明文化してください：リソースの必要性、要求が解消するリスク、検討済みの代替案。
- 4 要求のステータス（受付済み、要確認、承認済み、却下、保留）を定義し、各ステータスのオーナーを指定してください。
- 5 最初の週に提出された要求を確認し、意思決定に役立たない項目や承認手順を削除してください。
期待される効果
チームは、リソースをどこに要求しに行けばよいか、何を正当化すべきかをより早く理解できるようになります。マネージャーは、比較可能な要求を受け取り、決定のキューを確認でき、同じような確認を繰り返すことが少なくなります。
よくある間違い
- フォームが長すぎること：人々は個人的な交渉でプロセスを迂回し始めます。
- ステータスのオーナーを任命しないこと：要求は形式的に提出されても、次のステップへ進める担当者がいません。
- 却下の理由を隠すこと：チームはその決定を恣意的と捉え、同じリソースについて再び論争を繰り返します。
- 緊急の要求と通常の要求を同じ方法で処理すること：重要なブロッカーが全体的なキューに埋もれてしまいます。
- 定期的なキューの確認なしにプロセスを開始すること：ステータスが古くなり、管理の役に立たなくなります。
さらに詳しく読む
- 本：Gene Kim, Kevin Behr, George Spafford『The Phoenix Project』
- 本：Eliyahu M. Goldratt『Critical Chain』
- ガイド：Project Management Institute『PMBOK ガイド』リソースマネジメントおよび調達マネジメントのセクション
- 本：David J. Anderson『Kanban: Successful Evolutionary Change for Your Technology Business』
FAQ
プロセスオーナーは誰が務めるべきですか？
通常はオペレーション責任者、機能責任者、またはPMOです。オーナーは、決定の責任者を任命し、定期的に要求キューを整理できることが重要です。
新しいシステムなしで開始できますか？
はい。既存のトラッカーのスプレッドシートやタスクで始められます。重要なのは、入口を一つにし、明確な項目、ステータス、次のステップの担当者を可視化することです。
プロセスが機能しているかどうかは、どのように判断すればよいですか？
繰り返しの確認、失われた要求、個人チャットでの決定が減ったかを確認してください。有益なシグナルは、依頼者自身がステータスを確認でき、誰が決定を下しているかを把握していることです。
マネージャーがプロセスを迂回する場合、どうすればよいですか？
何が不足しているかを分析してください：スピード、例外を認める権限、使いやすいフォーマット。緊急のブロッカーには迅速な経路を残しつつ、決定と理由は全体のキューに記録してください。