リソース管理 (英語): ホワイト ペーパー

このホワイト ペーパーは、「最前線の現場から」コレクションの一部です。 リソース管理のさまざまな面における問題点について説明し、リソース管理システムを作成する場合の提案事項を紹介します。

このホワイト ペーパーの Word 版をダウンロードするには、「リソース管理」を参照してください。

その他のホワイト ペーパーについては、「最前線の現場から」のホワイト ペーパーを参照してください。

リソース管理

リソース管理は、組織が個別のプロジェクト管理から、Microsoft Office Project Server などのシステムを利用したエンタープライズ プロジェクト管理に切り替える最も一般的な理由です。

これを聞くと、このようなシステムから最適なリソース管理を実現する方法について幅広い戦略があればと考えるかもしれません。

そのような戦略はあるでしょうか。

リソース管理の定義

エンタープライズ システムの多くの側面と同様、最初の問題は、"リソース管理" の意味について正確に定義することです。 考え方によっても異なりますが、リソース管理には多くの要素があります。

リソースの平準化

純粋な視点から見ていきましょう。 これは、15 年以上にわたる業界での経験から来ています。 プロジェクト管理ソフトウェアが商用製品として最初に販売されたとき、その製品はクリティカル パス法 (CPM) のスケジューリング ツールでした。 初期のシステムでは、リソースの要素はまったく考慮されていませんでしたが、 システムからスケジュールを取得するには十分なものでした。その後、ロール フィード プロッター (ほとんどが製図業種用) の登場により、プロジェクトを棒グラフや論理 (ネットワーク) 図で表示できるようになりました。

このようなシステムにリソースの要素が入るようになると、リソースを追加することで、従来の計算方法を強化できるようになりました。 アルゴリズムは変わりましたが、その目的は、スケジュールの遅れ (取引数の不足により遅れが長引く場合) などを事前に確認し、それに合わせて人材を確保して仕事を割り振ることです。 リソース平準化については、この後でも説明します。

クリティカル チェーン計画

一部の人にとって、クリティカル チェーンの概念は新鮮なものですが、クリティカル チェーンには実際長い歴史があります。 クリティカル チェーンでは、スケジュール中心の人向けに、リソース制約をスケジュールに組み込み、スケジュールの実施に大きな影響を持つリソースを探します。 このような考え方は、おそらく CPM には最初からない概念であり、リソース制約を適切な状況でいつ適用するかが非常に重要になります。

リソース キャパシティ計画

考え方を少し広げると、最初の 2 つの定義は、リソース キャパシティ管理という幅広い概念に含めることができます。 これは、エンタープライズ プロジェクト管理の導入で求められる最も一般的な概念です。 リソース キャパシティ計画の目的は、組織の意思決定者に対して次のような質問に答えることです。

  • 人材に対してすでに行ったコミットメントを実行できますか。

  • そうでない場合、どのような人材の変更がコミットメントに必要になりますか。

  • そのような場合、どのような余分なキャパシティが追加のコミットメントに必要になりますか。

  • 追加のプロジェクトが割り当てられた場合、既存の人材で達成できますか。

  • 人材を変更できない場合、そのプロジェクトの達成に必要な新たな作業にどのような 影響がありますか。

リソース キャパシティ計画には、プロジェクト管理プロセスの一部として実施する必要のある複数の概念が含まれます。 これには次のものが含まれます。

  • リソース投入

    リソース キャパシティ計画を開始するには、最初に、必要な作業の量を確認します (必要な作業がない場合は、リソースを管理する必要はありません)。タスクごとの正確な作業量と、その作業の完了に必要な人材を把握することは、正確な分析に不可欠です。

  • スキルのスケジューリング

    Microsoft Project などの現在のプロジェクト管理ツールでは、部門や個人だけでなく、スキルとしてもリソース要件を管理できます。 スキルのスケジューリングには、リソース要件だけでなく、スキルの利用状況をインベントリとして管理することも含まれ、利用可能な人数を部門ごとに管理するよりも、全体的に効果的になるようです。 データベース管理部門に SQL Server 2008 のスキルを持つ人材がおらず、そのスキルが次のプロジェクトに必要になる場合は、プロジェクトの完了に必要なスキルが不足していることになります。

  • リソースの割り当て

    どのようなリソースをだれが割り当てるのでしょうか。 リソース要件をどのように定義して解決するかを決定するのに、作成するプロセスがあります。 リソースのカテゴリまたはコンピテンシーの依頼から始めるべきでしょうか。 "仮予約" モードで各リソースを依頼し、権限のある人に "本予約" してもらうべきでしょうか。 仮予約した個別のリソースをさまざまなプロジェクトに含めるべきでしょうか。 プロジェクト マネージャーが各部門からのリソースをコミットできるようにすべきでしょうか。また、各部門の責任者に権限を与えるべきでしょうか。

  • リソースの利用状況

    プロジェクトでリソースが必要な場合に、どのようなリソースを利用できるでしょうか。 プロジェクトとプロジェクト以外の作業に各リソースを利用できる時間を決定するのは だれですか。 休暇の取得時期を決定するのはだれですか。 1 日に作業可能な超過時間をどのように決定しますか。 いわゆる "サービス残業" をどのように扱いますか。 それは代休の対象になりますか。

  • リソースの平準化

    プロジェクトにリソースが必要で、そのリソースの利用状況が確認できる場合、その 2 つを比較すれば、過度に割り当てられている部分がわかり、割り当て超過に対処する必要が出てきます。 限られたリソースを有効活用できるように、プロジェクトに優先順位を付ける必要がありますか。 限られたリソースを有効活用できるように、タスクに優先順位を付ける必要がありますか。 自動化されたリソースの平準化を使用すべきですか。 手作業によるタスクの移動についてはどうですか。 社内で作業が競合し、別の部署の作業が終了するのを待つような場合、調整する役はだれですか。

リソース契約

この用語は、リソースのグループを管理する部門長と、これらのリソースを必要とする作業を管理するプロジェクト マネージャーで構成されるようなマトリクス組織に一般に見られます。 "リソース契約" という用語は、リソースを特定の作業にコミットするために、プロジェクト マネージャーと各部門長の間で行われる交渉のことです。 この交渉では、最初に、プロジェクト マネージャーが利用したい人物と日時を要請します。 部門長からは、「同じようなスキルを備えた別の人物ではどうか」とか「依頼された人物は別の日であれば空いています」などの返答が返ってくることがあります。 プロジェクト マネージャーは、その返答を受け入れるか、リソースの要件が満たされるまで、さらに交渉することになります。

リソース追跡

組織によっては、リソース管理の最も重要な側面は、計画ではなく、実際に起こったことの確認です。 上級エグゼクティブからは、「社員が実際にどのような業務をしていたかの報告があれば、 より効率的になるのに」という声がよく聞かれます。 このような組織にとっては、エンタープライズ プロジェクト管理システムのタイムシートの側面が最も重要になります。 プロジェクト計画に統合しなくても、アクティビティ別に処理すれば、各タスクの費用対効果を管理するための豊富なデータを得ることができます。 プロジェクトの作業に利用できる時間について興味深い実態が見えるようになり、プロジェクトの作業以外に使われている時間も把握できます。 タイムシートのコレクションをプロジェクト計画に統合できれば、リソース管理を予算対実績分析に 拡大できます。 計画したタスクごとに必要な時間、これまでのタスクの進捗とタスクの終了予定に与える影響、それにより影響を受けるその他のタスクを確認できます。

リソース コミュニケーション

巨大建設プロジェクトの世界では、リソース コミュニケーショについてあまり心配することはありませんでした。 現場監督は、最新の情報をプロジェクトの事務所から朝入手し、作業開始前に必要な情報を作業員に伝えます。 ホワイト カラーのハイテク関連のプロジェクト環境では、状況がまったく異なります。 プロジェクト チームは、プロジェクト スケジューラや作業を行うリソースだけでなく、エグゼクティブ後援者、ユーザー、顧客、下請業者、外注の開発者など、 あらゆる種類のリソースで構成されているからです。 部署の垣根だけでなく、組織の境界を越えたプロジェクト チームになることも珍しくはありません。 このような環境では、コミュニケーションがさらに重要になります。 このような状況でリソース管理ができれば、プロジェクト管理プロセスに関与するすべてのリソースと効果的に連携できます。

リソース コミットメント

プロジェクト管理システムについて話すとき、アルゴリズムの環境に話が行きがちですが、プロジェクト内のリソースのコミットメントの管理もまた、プロジェクト管理の重要な側面になります。 プロジェクト チームのリーダーには、要請したコミットメントと実行したコミットメントを管理することが求められます。 あるリソースが「金曜日までそれを終わらせます」と言ったとき、これはコミットメント、つまり約束になります。 これは、スケジュール内の終了予定日と一致する場合や一致しない場合もありますが、 それはコミットメントであり、スケジューリング アルゴリズムが算出した終了予定とは異なります。 リソース コミットメントは、Outlook や Office SharePoint Server、ホワイトボードやその他のコミットメント ツールなど、何らかの形で管理する必要があります。

リソースの下請け契約

組織によっては、他の会社から請け負ったリソースの管理だけで十分なリソース管理になります。 下請け契約が伴う場合、下請け業者との契約内容を管理し、その契約に基づいて適切な報酬が支払われ、下請け業者が契約を順守することがプロジェクトの成功を左右します。

Microsoft EPM ソリューション内にツールが用意されているため、 リソース管理のこのようなすべての側面に簡単に対応できます。 リソースの平準化、リソースの割り当て、リソースの投入、スキルのスケジューリングは、Project Server の基本機能から (Project Standard または Professional でも) すべて利用できます。 複数プロジェクトのリソース割り当ては、Project Server のチーム ビルダーのリソースの切り替えウィザードで実行できます。 リソースの追跡は、Project Server のタイムシートで実行できます。 リソース契約には、既定ではあまり多くのインターフェイスが用意されていませんが、ここでは仮予約と本予約という考え方が導入されているため、 リソース要求を処理する堅牢なインターフェイスを Office SharePoint Server の Web ベースのフォームで実行し、機能に直接組み込むことができます。 リソースの下請け契約も Office SharePoint Server の機能で処理できます。

課題

ここまで、リソース キャパシティ計画について詳しく話しませんでしたが、別にできなかったからではありません。 リソース キャパシティ計画は、一般的に EPM の導入で最も要求される側面ですが、実際に実行することが最も難しいものの 1 つです。

リソースの平準化アルゴリズムを高度なスキルのリソース グループに適用しようとすると、根本的な問題が発生します。 この問題を理解するには、リソースの平準化アルゴリズムの開発時の当初の設計思想に立ち戻ってみてください。 この記事の前半で、リソースの平準化とクリティカル チェーン分析について後で説明すると述べましたが、これがその理由です。

リソース平準化エンジンは、最初は工学用途に設計されていました。 最初のプロジェクト スケジューリング ツールは、プロジェクトごとに計算を実行する重工業や建設プロジェクト向けに開発されました。 実際、1 つのプロジェクトを納品するために組織全体が作成されることもありました。 最初の商用ツールは、防衛産業や石油/ガス業界を対象としており、膨大なデータを活用して、これらのツールで管理していました。 しかし、このようなプロジェクトでリソースを考える場合、常に考慮するのは、一般的なリソースです。

このようなプロジェクトのリソース スケジューリングは、必然的にスキル単位で実行されます。 プロジェクト スケジューラが考えるのは、必要な機械技師、電気技師、配管工員の数であり、 このような問題にはリソース平準化アルゴリズムが最適です。 多数のリソースがある場合でも、タスクを平準化すれば、フルタイムのスタッフの数を必要に応じて増減できます。 リソースの数が多い場合でも、同じ種類の交換可能なリソースであれば、このアルゴリズムで十分に機能します。

現在のプロジェクト管理では、交代可能な多数のリソースを伴う巨大プロジェクト用に当初開発された概念を拡大し、個々のレベルまで適用しています。 このアルゴリズムでも理論上はまだ機能すると思われます。デモでは、一度に 1 つのリソースしか使用しないため、十分機能しています。

次の例について見てみましょう。

Chris への割り当てが多すぎることを示す Microsoft Project ビュー

ここで取り上げるのは、Project Professional 2007 の簡単なプロジェクトです。 プロジェクトをマイルストーンで開始し、マイルストーンの完了後すぐに開始する 2 つのタスクを追加しています。 Chris を両方のタスクに割り当てるとすぐに、リソースの平準化の問題が発生しました。 分割画面からもわかるように、Chris は自分の能力の 2 倍割り当てられているため、問題が発生するのも当然です。

それでは、Project のリソース平準化アルゴリズムを使用してプロジェクトを平準化してみましょう。

Chris の連続タスクを表示して、過剰にタスクが割り当てられていないことを確認できる Microsoft Project のビュー

問題が解決しました。 Chris のタスクは 1 週間から 2 週間に延期されています。タスクをすべて完了するには、もう 1 つのタスクを第 2 週に延期する必要があります。 また、Chris は、第 1 週から第 2 週にかけて連続して作業することが示されています。

この計算に別のリソースを追加するまでは、これで問題ないと思われます。 では、最初に状況に戻り、いくつかの追加タスクをプロジェクトに追加してみましょう。この場合は、別の人に割り当てます。

小林さんと松本さんのタスクを表示する Microsoft Project ビュー

今度は、一度に 2 人のリソースに作業してもらいます。 Chris は割り当て超過の状態に戻っています (Chris には、2 つのタスクの両方が第 1 週に割り当てられています)。同時に開始する John には、3 つのタスクが追加されています。 John のタスクでは順序が設定されているため、すでにリソースが平準化された状態になっており、 John の状況は問題ありません。 John は第 1 週から第 2 週にかけて連続して作業することになりますが、ここでリソースの平準化アルゴリズムを適用したらどうなるでしょうか。

青木さんと伊藤さんのタスクおよび伊藤さんの 1 週間の遅れを示す Microsoft Project のビュー

プロジェクトでは、最初に平準化したのと同じように Chris の時間が平準化され、 Chris は第 1 週から第 2 週にかけて連続して作業することになります。 John は、Chris が 2 番目のタスクを完了するまで待つことになるため、作業が丸々 1 週間空きます。 その間、John がやることがなくなる (デスクで新聞を読むくらいしかない) のはありえないため、彼らの上司が John と Chris のスケジュールを調整する必要があります。

ここでは、2 人のリソースの簡単な例について見てきました。 チーム全体の話になると、影響のあるプロジェクトが複数になったり、各タスクに複数のリソースを割り当てたりするなど、問題はさらに複雑になります。

これは、プロジェクトの問題ではなく、 リソースの平準化を実行するほぼすべてのスケジューリング ツールで発生する問題です。 このようなスケジューリング ツールでは、最初にクリティカル パスを計算し、選んだオプションに基づいて、リソース制約をスケジュールに適用します。 システムによってオプションは異なりますが、最終的にはリソース平準アルゴリズムをそれぞれのリソースに適用します。 現在のプロジェクト スケジューラは、スケジューリングを個人レベルで実行する必要がある場合は、従来のリソース平準化を適用しないようにしています。

このことは、Project などの分析ツールで情報を Outlook などのリソース コミットメント システムにプッシュしない根本的な理由の 1 つでもあります。 Outlook は、根本的に個人のコミットメント システムと考えることができます。 来週の午後 2 時に会う約束をしたり、 今週火曜日までに作業を終わらせると約束したり (自分自身に約束する場合もあります)、 また、今日予定の作業や約束を確認し、 システムのコミュニケーション機能を使用して、実行中や依頼中のコミットメントについて返信したりするなど、Outlook では、日々のコミットメントを行います。

Project は基本的に分析システムですが、Outlook を Project と統合することを想像してみてください。 アクティビティを Project や Project Server から Outlook に移行し、アクティビティの進行状況を確認することはその 1 つです。 Outlook のすべてのタスクがスケジュールに統合されたらどうなるでしょうか。 来週の午前中に歯医者の予定を入れた場合、 歯医者に 4 時間取られることで、スケジュールしていたすべてのタスクに影響が出てもよいでしょうか。 すべてのタスクを 4 時間遅らせるべきでしょうか。 関係者全員のすべてのスケジュールや、4 時間遅れることで彼らのタスクが影響を受けることについてはどうでしょうか。 スケジュールが 4 時間遅れることをメールで社内全体に通知すべきでしょうか。 ちょっと待ってください。これは個人の問題です。 全員の Outlook のコミットメントが社内全員のすべてのタスクに影響するとしたらどうなるでしょうか。 それこそ社内全体が混乱してしまいます。

Outlook などのリソース コミットメントやリソース コミュニケーションのツールを Project や Project Server などのリソース キャパシティ計画ツールと統合する場合は、2 つのツールの設計思想の違いを考慮する必要があります。 Project からタスクを受け取り、これらのタスクを Outlook の予定表やタスク リストに統合することはできますが、 Outlook から Project Server にタスクを "プッシュ" することはできないなど、 Project Server から Outlook のリンクが設計されている場合は、このような点が考慮されます。

リソース管理システムの構築

ここまでいろいろ説明してきましたが、次に、リソース管理の構築方法について、いくつかアドバイスしたいと思います。

最初に、リソース管理のどのような側面が組織に適用され、どのような側面をすぐに活用できるかについて説明しましょう。 リソース管理の側面には、実行することが難しい部分と、そうでない部分があるのが一般的です。 低い位置にぶら下がっている果実 (実行できそうな部分) を最初につかみ取りたいといつも考えるものです。 リソース キャパシティ計画などに最も関心がある場合、このようなプロセスを構築し、 すべてのデータを集約して、一貫したプロセスを構築することは困難な課題です。 しかし、タイムシート システムでリソース追跡を実行することは、それほど難しくはないでしょう。 このため、リソース管理のどの部分で他の側面を考慮するかについて、視野を広げることから始めてください。

リソース キャパシティ計画を見ると、リソース平準化アルゴリズムでは、個人レベルでのリソース定義が難しいため、 スキルや一般的なレベルに対してはリソースの平準化を行い、個々の割り当てはチーム リーダーに任すことを検討できると思います。 これは、EPM 導入の領域になる場合が多く、上級エグゼクティブにとって面倒な作業になります。 これらをすべて考慮しないと、分析が中央で実行され、全員の毎日の予定表と個人や会社のコミットメントを適切に調整して、コミットメントを毎日実行できるシステムを想像してしまうでしょう。

リソース キャパシティ計画に関心がある場合は、あまり提案していない考えがあるので紹介します。 ハイテク組織では、個人レベルでのスキルのスケジューリングが一般的ですが、その理由は、多くの人が特定の種類の作業に適した独自のスキルと知識を持っているためです。 このような状況の場合は、"重要リソース プロジェクト" を作成することを検討してください。 私の経験では、組織の重要リソースは、全リソースの 5% もいません。 このような重要なリソースは、すべてのプロジェクトにとって不可欠な人材です。 彼らは、他にないスキルと知識を兼ね備えており、優秀なプロジェクト マネージャーであれば、プロジェクトを成功させるために、彼らのようなリソースを 1 人でも多くプロジェクトに引き入れることが重要であることを理解しています。

重要リソース プロジェクトは、このような人材にのみ割り当てられるすべてのタスクの一覧になります。 彼らの作業のリソース平準化を行い、その他すべてのリソースをスケジュールすることは、チーム リーダーの役割です。 これはすぐに実行でき、労力も比較的少なくて済みます。 このように試行を続ければ、全員に関係するプロセスの文化的な課題や、プロセスの改善という課題が発生することなく、リソースの平準化という頭痛の種の多くを解決できるようになります。

Microsoft で Project チームが行っているように、ソリューションを Project Server の範囲を超えるものとして考えることも重要です。 "Microsoft EPM ソリューション" は、テクノロジのスタックであり、 リソース管理のさまざまな側面を考慮すると、Windows SharePoint Services、Windows Workflow、Office SharePoint Server (フォーム用)、SQL Server はすべて、組織のニーズに合わせた環境の構築に不可欠な要素になります。

著者について

Chris Vandersluis 氏は、Microsoft 認定パートナーであり、モントリオール (カナダ) に拠点を置く HMS Software の社長兼創業者です。 マギル大学で経済学の学士を取得し、プロジェクト制御システムの自動化に 30 年以上携わってきました。 PMI (プロジェクト マネジメント協会) の古くからの会員であり、MPUG (Microsoft Project Users Group) のモントリオール、トロント、ケベックの支部の設立を支援しました。 氏は、Fortune、Heavy Construction News、Computing Canada Magazine、PMI の PMNetwork などにも寄稿しており、Project Times のレギュラー コラムニストでもあります。 マギル大学では上級プロジェクト管理について教えており、北米および世界中のプロジェクト管理団体の会合でもたびたび登壇しています。 HMS Software は、プロジェクト指向型の時間管理システム TimeControl のベンダーであり、1995 年から Microsoft Project Solution Partner です。

Chris Vandersluis 氏のメールの連絡先は chris.vandersluis@hms.ca です。

Chris Vandersluis 氏の EPM 関連のその他の記事については、 HMS 社の EPM ガイダンスのサイト (http://www.epmguidance.com/?page_id=39) を参照してください。

スキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×