リソースの移行：Microsoft Project からのキャパシティ計画

Project Server をうまく運用している PMO にとって、その価値がプロジェクト計画そのものにあることはまれです。価値はその下にある運用の層でした。すべてのプロジェクトが使う一つの組織のリソース プール、請求と収益認識に流れ込むコスト付きタイムシート、ひとりでに伝わるカレンダーの例外、そしてリソース マネージャーが毎週実データで人の配置を決めるプロジェクト横断のビューです。かかっているのは、この運用の層です。計画は移行できます。運用の層は、移行できないことがよくあります。

PMO がこれを甘く見るたびに、三つの失敗のパターンが繰り返されます。

• 「リソースは後で追加する」という罠。チームが計画をきれいに移行し、リソース プールを次のスプリントに回します。その時が来るころには、各プロジェクトの責任者がすでに自分のプロジェクトに重複したリソースを作っていて、リソース マネージャーは、プロジェクト横断のキャパシティ ビューを成り立たせていた唯一の信頼できる情報源を失っています。
• 「コスト単価は立ち上げに必須ではない」という罠。標準単価がフェーズ 2 の整理に回されます。二か月後、経理部門は、月次決算に必要なコスト付きタイムシートのデータが新しいプラットフォームにはもう存在しないことに気づきます。時間を記録した時点で単価が読み込まれていなかったからです。データは後から作り直せず、収益認識が止まります。
• 「Planner Premium で足りるだろう」という罠。PMO は、Microsoft のクラウド製品が同じ用途をカバーすると思い込みます。リソースのモデル化については、カバーしません。Planner Premium には、組織のリソース プールも、コスト付きタイムシートも、プロジェクト横断のリソース ビューもありません。移行後に気づいたのでは遅すぎます。

三つすべてに共通する構造上の理由：リソース モデルは、短い製品デモで Project Server のうち最も目立たず、ベンダーの比較表でも最も扱われない部分です。計画、ガントチャート、ダッシュボードはデモで見栄えがします。組織のリソース プールは、見栄えがしません。そのため購入者はプラットフォームを選ぶときにリソース モデルの対応範囲を軽く見て、本番になって穴に気づきます。このガイドは、最も大事な判断はどの移行先プラットフォームを選ぶかだという前提に立って、まずモデルを、次に移行の進め方を示します。

何を移行するか決める前に、手元にあるものを棚卸ししてください。Project Server のリソース モデルには六つの層があり、それぞれ移行の仕方が違います。

すべての PMO がすべての層を使っているわけではありません。棚卸しで問うべきは「このうち、チームが判断に実際に頼っているのはどれか」です。コスト付きタイムシートを使っていなければ、単価表の層は飾りにすぎず、なくても困りません。汎用リソースを需要のモデル化に使っていなければ、統合してかまいません。使っているなら、その機能は移行先プラットフォームで譲れません。

プラットフォームを比べる前に棚卸しをしてください。その成果は移行先プラットフォームに欠かせない機能の一覧で、その一覧が移行の残りの形を決めます。次のセクションは、その一覧がすでに手元にある前提で進みます。

リソース モデルの対応範囲で絞り込むと、プラットフォームの比較は狭まります。上の六つの層の順に並べた、正直な全体像です。それぞれについて、対応、一部対応、非対応を示します。

Microsoft のクラウド製品（Planner Premium / Project for the Web、SKU のラベルが違うだけの同じ製品）は、リソース モデルのほとんどを含みません。これは意図的な位置づけです。プロジェクトの層を持つチームのタスク ツールであり、PMO のためのプラットフォームではありません。Project Server のリソース モデルを本格的に使っている PMO は、大事な機能を失わずに Planner Premium へ置き換えることはできません。

Smartsheet の Resource Management モジュールと Workfront は、どちらも組織のプールの概念を保ちます。違いは細部にあります。Smartsheet RM は別の SKU で、ユーザーあたりの費用がかなり増えます。Workfront のプールはしっかりしていますが、ユーザーあたりの価格は四つの中で最も高くなります。Onplana には別のリソース プールはありません。一人ひとりが組織のメンバーで、そのリソース モデルは、すべてのプロジェクトにわたるその人の週のキャパシティ（Professional プランから）、三つの階層（人、役割、組織の既定値）の単価、名前付きの例外を持つ稼働日カレンダーで、有料のアドオンはありません。汎用リソース、人ごとのカレンダー、正式な RBS はありません。価格は ユーザーあたり月額 12 米ドル（Professional）からです。Planner Premium との正直な比較はPlanner との比較ページにあります。

表にしにくい次元がもう一つあります。プロジェクト横断のキャパシティ ビューの質は、基本の機能があってもプラットフォームによって大きく違います。タスクへの直接の割り当てだけを示すものもあれば、サブプロジェクトの集計を含むものも、汎用のプレースホルダーの割り当てを含むものもあります。リソース マネージャーが毎週このビューで人の配置を決めているなら、評価の間に、割り当て時間の多い上位 25 人のリソースで並べて比べてください。

何かをエクスポートする前に、リソース モデルを完全に棚卸ししてください。これはプロジェクト一覧の棚卸しとは別のものです。あちらはプロジェクトを目録にし、こちらはその下にあるリソースの層を目録にします。成果はリソース移行準備レポートで、リソースのあらゆる要素について、今どこにあるか、どこへ移るか、誰が移すかを一覧にします。

1. 属性付きのリソース一覧。組織のリソース プール全体を、名前、種類（名前付き／汎用／コスト）、メール アドレス（名前付きの場合）、最大単位数、標準単価、役割／資格、RBS 上のパスとともにエクスポートします。OData の /Resources エンドポイントが基準となる情報源です。Reporting Database には派生フィールドがもっとありますが、オンプレミスの Project Server にしかありません。
2. コスト単価表。Microsoft Project は、リソースごとに最大 5 つのコスト単価（単価 A から単価 E）を有効期間の範囲付きで扱えます。すべての単価の階層と、有効期間のすべての行をエクスポートしてください。PMO が単価 A しか使っていなければ B–E は無視できますが、そう決めつける前に本当にそうか確かめてください。
3. カレンダーの例外。リソースごとに、名前付きのカレンダーの例外の一覧を、日付の範囲と変更後の勤務時間とともにエクスポートします。移行先プラットフォームが名前付きの例外を保てない場合は、名前を補助の CSV に保存して、理由（「学会の週」「休暇による休業」）が残るようにします。
4. RBS の階層。リソース分解構成をエクスポートします。すべてのノード、親子の関係、各ノードに割り当てられたリソースです。この階層があるからこそ、リソース マネージャーは自分の報告系統に沿ってキャパシティ ビューを絞り込めます。
5. 進行中の割り当て。進行中のすべてのプロジェクトの、進行中のすべての割り当てのスナップショットを取ります。どのリソース、どのプロジェクト、どのタスク、割り当て時間、実績時間、計画上の開始と終了です。これが検証の土台で、移行後に移行元と移行先の割り当て量を比べます。
6. リソースのカスタム フィールド。PMO がリソースに Enterprise Custom Fields（セキュリティ クリアランスのレベル、請求可能のフラグ、契約の種類）を定義しているなら、リソース一覧と一緒にエクスポートしてください。移行先プラットフォームによって、組み込みのフィールドとしてモデル化するもの、カスタム フィールドとしてモデル化するもの、対応しないものがあり、それが後のフィールドの対応付けを決めます。

完成した準備レポートが、移行の残りの土台になります。踏み切る前にエクスポートの質を確かめるには、サンプルのプールを移行プレビュー ツールに通してください。リソース プールの代表的な一部を読み込むと、どのフィールド、単価、例外がきれいに移るかがそのままわかります。

五つのフェーズがあり、それぞれに成果と、先へ進むかを決める判定ポイントがあります。全体の期間は、リソース 100–250 人のプールでふつう 3–5 週間です。コスト単価表を大きくカスタマイズしている場合や、RBS が大きい場合はもっとかかります。

フェーズ 1：棚卸しと決定（1 週間）

上で説明した事前の棚卸しを終え、チームにとってリソース モデルのどの層が譲れないかに基づいてプラットフォームを決めます。決定を理由とともに記録してください。選んだプラットフォームになぜ機能 X がないのかと誰かに聞かれたとき、読み返すのはこの部分です。

• 稼働中のテナントで棚卸しを行う
• 欠かせない層の一覧に照らして各移行先プラットフォームを評価する
• 移行先を選び、その理由を記録する
• 選んだプラットフォームについて PMO の責任者の承認を得る

判定ポイント：準備レポートに署名済み。移行先プラットフォームを選定済み。

フェーズ 2：プールをエクスポートする（2–3 日）

Project Server がまだ稼働しているうちにエクスポートし、エクスポートに一覧のすべての層が含まれていることを確かめます。リソース プールについては .mpp ファイルのエクスポートに頼らないでください。含まれるのはプロジェクト ローカルのリソースの割り当てだけで、単価、カレンダー、RBS を持つ組織のプールは含まれません。

• リソース一覧：/Resources から
• カレンダーの例外：/Resources/Calendars から
• コスト単価表（オンプレミスなら Reporting DB）
• RBS：OData に相当するものがない SOAP API のエンドポイントから
• 進行中の割り当て：/Assignments から
• 準備レポートと一致する件数

判定ポイント：すべての層で、エクスポートした件数が準備レポートの件数と一致する。

フェーズ 3：移行先で作り直す（3–7 日）

プールを移行先プラットフォームにインポートし、プラットフォームの比較で見えた移行の穴を層ごとに埋めます。移らない汎用リソースは、名前付きのプレースホルダーとして作り直します。移らないカレンダーの例外の名前は保管します。リソースのカスタム フィールドは、移行先の組み込みのフィールドかカスタム フィールドの定義に対応付けます。

• リソース一覧をインポートする（一括インポートまたは移行先の API）
• RBS の階層を作り直し、リソースを各ノードに割り当てる
• 割り当てを読み込む前に、標準単価とコスト単価表を読み込む
• リソースごとにカレンダーの例外を適用する
• プラットフォームのモデルに沿って汎用リソースを移す
• リソースのカスタム フィールドを対応付ける

判定ポイント：プールの件数、RBS の階層、単価表の件数が移行元と一致する。

フェーズ 4：割り当てて検証する（1 週間）

タスクの割り当てをプロジェクトごとに、担当チームでまとめた波に分けて移行します。各波の後、受け取ったチームが 48 時間以内に、自分たちのプロジェクトについて移行先の割り当て量を移行元と照らして検証します。波がきれいになるまで先へ進まないでください。多くのプロジェクトにたまった割り当てのずれを追いかけるのは、プロジェクトごとに直すよりはるかに難しくなります。

• 割り当てを 10–25 件のプロジェクトの波で移行する
• リソースとプロジェクトごとの割り当て量の差：移行元と移行先
• > 5% のずれはすべて調べる
• 過去のタイムシートのサンプルで、コスト付きタイムシートの計算を照合する

判定ポイント：すべてのプロジェクトで、リソースごとの割り当て量の差が < 5%。

フェーズ 5：キャパシティ ビューと照合（1 週間）

リソース マネージャーが実際に使っているキャパシティ ビューを作り直し、少なくとも 5 営業日、Project Server と並行して動かします。毎日の差分レポートが、新しいプラットフォームのキャパシティの計算が古いものと違うところをすべて示します。違いはすべて調べてください。本当の違いは既知の制限として記録します。

• 主要な 5 つのキャパシティ ビューを移行先で作り直す
• 割り当て時間の多い上位 25 人のリソースについて毎日の差分レポートを作る
• > 5% のずれを調べ、プラットフォーム間の本当の違いを記録する
• リソース マネージャーに新しいキャパシティ ビューの画面を教える
• 切り替え：移行先が信頼できる情報源になり、Project Server は読み取り専用になる

判定ポイント：毎日の差分レポートが 5 営業日続けてきれい。リソース マネージャーが新しいキャパシティ ビューの画面を承認する。

リソース モデルで最もよく起きる五つの失敗のパターンと、それぞれの防ぎ方です。

五つすべてに共通するパターン：どれも、その場では安く本番では高くつく「後で考える」という判断です。照合の作業は、当初の予算で最も見落とされがちな費用の一つです。移行費用の計算ツールでは、並行運用に含まれます。

検証のフェーズには三つの確認があり、それぞれが証拠を残します。準備レポートと一緒に保管してください。合わせて移行の監査証跡になります。

1. リソースごとの割り当て量の照合。今後 90 日間に割り当て時間の多い上位 25 人のリソースについて、移行元と移行先の割り当て量を比べます。許容範囲：±5%。それより大きいずれは、割り当ての移行でデータが失われたか、移行先のキャパシティの計算が Project Server と構造的に違うことを意味します。どちらも調べる必要があります。証拠：リソースごとの差分レポート。
2. コスト付きタイムシートのサンプルの照合。5 人の異なるリソースの、締め済みの最新のタイムシートを 10 件選びます。同じ時間の記録で、移行先でコストを計算し直します。許容範囲：±1%（お金なので、割り当て量より許容範囲が狭くなります）。> 1% のずれは、単価の誤り、失われたカレンダーの例外、またはその両方を示します。証拠：並べたコストの計算。
3. プロジェクト横断のキャパシティ ビューの一致。リソース マネージャーが最もよく使う 3 つのキャパシティ ビューを再現します。同じ期間の Project Server の最後の実行と比べます。二つのビューが割り当てを違う形で分類する（直接かサブプロジェクトか、名前付きか汎用か）のはふつうのことです。それは移行後の手引きに、プラットフォーム間の既知の違いとして記録してください。証拠：記録した違いを添えた、並べたスクリーンショット。

検証のフェーズの成果は、何を移行し、何を移行せず、何が未解決かを示す移行結果レポートです。フェーズ 1 の準備レポートと合わせて、二つで監査証跡の全体を記録します。

移行の手引きは PMO の責任ですが、リソース モデルには、誰かが前もって持ち出さなければ経理チームが切り替え後に気づく影響があります。コストを持つリソースの移行では毎回三つのパターンが現れ、それぞれ PMO 側の問題とは違う形で響きます。

混同されやすい三つの単価の概念

Project Server は、リソースごとに似た響きでも入れ替えのきかない三つの単価を扱います。標準単価（割り当てをモデル化するための社内の一時間あたりのコストで、多くは人件費の総額）、コスト単価（タイムシートの会計上のコストを計算するための単価で、タスクの種類ごとに A から E の単価表に分かれていることもある）、そして請求単価（案件の請求可能な時間について顧客に請求する単価）です。三つの概念すべてに一つの単価を使う PMO もあれば、概念ごとに別の単価を使う PMO も、各概念の中で単価表の階層を使う PMO もあります。

エクスポートの前に、経理部門に、実際にどの単価の概念を使っているか、どの単価表の階層がどの作業に対応するか、それぞれの単価が移行先プラットフォームのどのフィールドに流れるかを聞いてください。エクスポートは単価とリソースごとに一行です。インポートは、次の四半期の収益認識レポートが合うかどうかを決める対応付けの判断です。よくある、取り返しのつく誤りは、請求単価をコスト単価のフィールドに読み込むことです。そうするとコスト付きタイムシートが請求単価で計算され、損益のレポートはコストが膨らんで見え、直し方はもう一度エクスポートして読み込み直すことです。もっと悪く、直しにくい誤りは、コスト単価を請求単価のフィールドに読み込むことです。誤った単価で発行した請求書は再発行が必要になり、顧客との是正の話し合いはただでは済みません。

資産計上のルールはひとりでには移らない

規制のある組織や投資の多い組織の PMO は、「資産計上できるプロジェクトのエンジニアリングの時間は、費用ではなく貸借対照表の資産に流れる」といった人件費の資産計上の方針を持っていることがよくあります。Project Server では、こうしたルールはふつう OData のフィードの上に作ったビューやレポートとして存在し、プロジェクトごとやタスクごとのフラグを伴うこともあります。その仕組みのどれも、ひとりでには移行されません。フラグはエクスポートできます（カスタム フィールドの値）。ビューとレポートは、できません。経理部門は、同じフラグ付きのデータの上に、新しいプラットフォームで資産計上のレポートを一から作り直す必要があります。

リスクは、資産計上のレポートが作り直されず、資産計上すべき時間が費用に入り、期間が誤った数字で締まる、静かな四半期です。ここでの重大な誤りは内部統制上の指摘になります。経理部門には、資産計上の作り直しを移行の後追いではなく並行する作業の流れとして立ててもらい、切り替えは、並べた資産計上のレポートが合う締め済みの期間が少なくとも一つあることを条件にしてください。

請求可能な稼働率のレポートには明示的な設定が要る

プロフェッショナル サービスの PMO は、請求可能な稼働率（請求可能な時間を有給の時間で割ったもの、リソースごとと合計）で動いています。Project Server は、タイムシートのデータと、割り当てやタスクの「請求可能」フラグを組み合わせてこれを出します。フラグはきれいにエクスポートできますが、レポートはできません。上の比較表のとおり、請求可能な稼働率のネイティブのレポートへの対応は移行先プラットフォームによって違います。Onplana、Smartsheet RM、Workfront はこのレポートを主要な機能として備え、Microsoft の Planner Premium には請求可能の概念がありません。

請求可能な稼働率に対応するプラットフォームへ移行する PMO は、直近 4 週間の並べたレポートが ±2% 以内で合うことを切り替えの条件にしてください。それより大きいずれは、単価の対応付けの誤り、請求可能フラグの欠落、または移行されていない割り当てを示します。移行先プラットフォームが請求可能な稼働率にネイティブで対応していない PMO は、OData のスナップショットを下流の BI ツール（Power BI、Looker、Sigma）に取り込み、そこでレポートを作り直す計画を立ててください。どちらの場合も、古いプラットフォームを止める前に、経理部門がレポートの正しさを承認するべきです。そうしないと、新しいプラットフォームでの最初の月次決算が穴の見つかる時になり、それは考えうる最悪の時です。

経理部門を切り替えの前に巻き込むべき理由

経理部門の参加が遅れた移行では、毎回同じ三つの問題が起きます。どの単価がどれかについて経理部門が PMO の解釈を共有していなかったので、単価の対応付けをやり直すことになる。資産計上のレポートが作り直されておらず、新しいプラットフォームでの最初の四半期決算で、資産計上した作業が誤って報告される。経理部門が別のルールを使っているので、請求可能な稼働率のずれが PMO の許容範囲を超える。どれもプラットフォームの問題ではなく、すべて調整の誤りです。解決は安く済みます。フェーズ 1（棚卸し）とフェーズ 4（割り当てと検証）で、経理部門を指名された承認者に加えてください。その承認が、単価の対応付け、資産計上のレポート、請求可能な稼働率の許容範囲についての輪を閉じます。それがなければ、PMO は移行を引き渡し、経理部門は数週間後に費用に気づきます。ほとんどの場合は月次決算の最中で、落ち着いてやり直せる時期であることはまずありません。

移行は出発点にすぎません。長期的な問いは、PMO のキャパシティ計画の実践が新しいプラットフォームでも機能し続けるかどうかです。厳密さを保つチームと、途中でそれを失うチームを分ける四つの習慣があります。

• 唯一の信頼できる情報源を徹底する。組織のリソース プールが基準です。プロジェクトの中でローカルのリソースを作るのは、ずれの早い兆しです。プロジェクトごとに作成の権限を締められるプラットフォームもあります。使えるならそれを使い、使えなければ、各プロジェクトのリソース一覧を組織のプールと比べる週次の見直しをしてください。
• 四半期ごとの単価の見直し。12+ か月見直されない標準単価は、人件費の実際の総額から離れていきます。するとコスト付きタイムシートが財務の実態から離れていきます。四半期ごとに単価表を見直して更新するリズムを決めてください。
• 名前付きの例外の規律。カレンダーの例外は静かにたまっていきます。3 年で名前付きの例外が 30 件あるリソースはふつうです。見直しのリズムがなければ、例外は化石のように残ります。毎年、リソースごとの例外の件数を見直し、方針の保存期間を過ぎたものはすべて削除してください。
• RBS の進化。移行時に正しかった報告の階層は、組織の再編とともに古くなります。組織の体制の全体的な見直しのサイクルの中で、6 か月ごとに RBS の見直しを予定し、キャパシティ ビューの分け方が意味を持ち続けるようにしてください。

リソース モデルの移行について PMO が最もよく尋ねる質問です。FAQPage の完全なスキーマはこの記事の構造化データに含まれているので、これらの質問は Google の「他の人はこちらも質問」に表示されます。

拡大