リソースを管理する立場として、プロジェクトの突発的なスケジュールの空きや延長という課題に直面することがあります。これらの課題は起こりうることでありますが、その度に人のリソース調整に試行錯誤しています。
現在、リソースの管理は次のように期間で管理しています。
Aさん:4月~6月まで○○プロジェクト
Bさん:5月~7月まで○○プロジェクト
普通と言えば普通の管理方法ですが、突発的な日単位でのスケジュールの変更に対して、即座に対応するためにはざっくりとしすぎている管理方法だと感じていました。
例えば、Aさんはプロジェクト内で生じた避けられない事情で5月14日~18日まで作業を進めることができなくなった場合、その空いてしまった期間は次のように調整しています。
「1」の場合、リソースの調整も必要なくプロジェクト内で完結できるため一番ベストな方法です。そのためにもプロジェクト内で先の計画を立て「○○の作業は前倒しで進められる」という判断ができるようにしておくべきです。その判断もできない場合にリソース調整が発生します。
「2」の場合、別のプロジェクトがサポートを必要としている状況であればよいですが、そうでない場合、急遽人を投入することで進行に混乱を生じさせてしまう場合もあります。そうならないように「個々のスキルセットを多様化させ様々な性質のプロジェクトにも参加しやすくする」「プロジェクトの各工程を細分化し作業を依頼しやすくする」といったリソース管理とは別の視点での対策が必要になります。
「3」の場合、その時になって「何かできることはないか?」と探すのではなく、あらかじめ人の空きができたときに対応したい「自社サイトの○○機能の改修」など優先度は低いがいずれ対応したいことをストックしておくことが必要です。
「2」「3」の場合リソースの調整が必要になります。ただし、いずれにしても月単位の期間でのリソース管理に限界を感じており、リソース管理ツールの導入を検討したり、コミュニケーションの量を増やすなど試行錯誤しました。結果として現在はシンプルにカレンダー形式で日単位のリソースを管理するようにしています。それによって突発的なスケジュール変更に対する調整はしやすくなりました。
しかし腑に落ちていない点もあります。このリソース管理と各プロジェクト内でのスケジュール管理が、同じような管理の仕方で二重管理になっている点です。
リソースを細かく管理することで、一定の対応力は持たせられるようになりましたが、まだ解決すべき課題が残されていると感じています。まだまだ試行錯誤は続きそうです。