再帰配賦と相互配賦

コストモデルによっては、ある配賦のターゲットが次の配賦のソースになる必要があります。たとえば、共有サービスが互いにサービスを利用する場合です（ITがHRにサービスを提供し、HRもITにサービスを提供する）。PlaidCloudでは、単一の自動ソルバーではなく、配賦ステップを明示的な段階的パスとして連結することでこれをモデル化します。

複数パスが必要な場合

• 相互サービス — 互いにサービスを利用し合う2つのコストプール。
• 階層的な配分 — 部門のコストが階層を下って流れ、下位レベルが上位レベルを吸収してから再配賦する必要がある場合。
• 反復的なバランス — モデルが複数パスを経て安定した結果に近づく場合（プールAがBに一部を配賦し、BがAに一部を戻す、といった具合）。

モデル化の方法

PlaidCloudには、組み込みの「再帰モード」も自動収束ソルバーもありません。パスごとに個別のAllocation Splitステップを追加し、順番に連結することで、再帰を自分で構築します。

1. 最初のパスを通常のAllocation Splitとして実行します。
2. 次のパスでは、前のパスの出力を含むソースを構築します。通常は、前の結果をプールにユニオンまたは結合して戻し、再度配賦します。
3. モデルに必要な数だけ繰り返します。

各パスは明示的なステップであるため、実行するパス数はお客様が決定します。エンジンは相互関係を単一の連立方程式として解くことはなく、ループを自動的に止める許容値の設定もありません。再配賦が必要な残差が目的に対して十分小さくなるまで、パスを追加してください。

ヒント

• まず単一パスの配賦から始め、単純なモデルが期待どおりに動作することを確認してから、パスを追加します。
• 各パスの後で、未配賦の残差を確認します。パスを重ねても減少しない場合は、ドライバーの関係を見直してください。真の循環依存は、パスをいくら追加しても収束しません。
• 各パスはソースを再処理するため、大規模なデータセットでは再帰のコストが大きくなります。ソース全体で実行する前に、一部のデータで試してください。

関連項目

• 配賦を構成する — 基本的な構成
• Allocation Splitステップ — パスごとに連結するワークフローステップ
• 配賦のトラブルシューティング — 残差が合わない場合