Adaptive Insights

GitLabがAdaptive InsightsをどのようにGitLabの計画サイクルの計画・予算・予測に使用しているかをご覧ください

一般情報

Adaptive InsightsはWorkdayの一部であり、クラウドベースのコーポレートパフォーマンス管理プラットフォームです。GitLabのFP&Aチームは、GitLabの計画サイクルを計画・予算・予測するためにAdaptive Insightsを活用しています。

管理

バージョン管理

Adaptive Insightsの最も強力な機能の1つはバージョン管理です。管理者は計画のバージョンを作成、編集、ロックすることができます。

GitLabのバージョン命名規則

GitLabの各バージョンは、計画/予測の会計年度とラベルを指定する必要があります。以下はGitLabで使用される命名規則のいくつかの例です

  • FY21 - 0 + 12 Plan
  • FY21 - 1 + 11 Forecast
  • FY 21 - 2 + 10 Forecast

ロール

現在、GitLabのAdaptive Insightsインスタンスには5つの異なるロールがあります

  1. Administrative - Adaptive Insightsへのフルコントロール
  2. Analysis - シート、レポート、ダッシュボード、プロセストラッカーへのアクセス可能。レポートを共有し、プロセストラッカーを使用してタスクを完了することもできます。
  3. IT Administrator - 給与詳細を除くAdaptive Insightsへのフルコントロール
  4. Report Only - Analysisと同じですが、レポート用のファイルをアップロードできます
  5. Standard - 構造の編集・変更・修正を除くAdaptive Insightsへのフルコントロール。Standardは管理者または統合アクセスも持ちません

ユーザー

Adaptive内で、管理者は各ユーザーに名前、ポジション、ユーザー名、ホームページ、タイムゾーン、国、ロール、レベルを割り当てることができます。管理者はユーザーのパスワードをリセットすることもできます。ユーザーはOktaを使用してAdaptive Insightsにサインインし、割り当てられた場合はOne Passwordでパスワードを管理する必要があります。

Adaptive Insightsへのアクセスが必要な場合は、アクセスリクエストを開き、このページのコードオーナーに割り当ててください。

アカウント

前提条件

収益モデル

現在の状態では、収益モデルシートはユーザーが予約、ARR、収益を構築するためにデータを入力する静的なシートです。収益モデルシートにはいくつかのソースからのインプットがあり、シートを構築するインプットとともに以下に文書化されています。

  • 予約

    予約データはSales Financeが所有するモデルから構築され、月に数回モデルに入力されます。予約データの入力は、再予測または計画の際と、Sales Opsチームとの実績の照合の際に行われます。

  • ARR

    毎月4番目の営業日に、コーポレートファイナンスチームはクローズ中の月の終了ARRを記録します。これが進行中の月の期首ARR額になります。例えば、月1の終わりにGitLabのARRが$1Mであった場合、月2の始まりに期首ARRは$1Mとなります。進行中の月は期首ARR額といくつかの他のインプットに基づいて期末ARRを予測します。これらのインプットは「New and Growth Booked Net ARR」、「Booking Timing Adjustments」、「Trueups」です。GitLabはまた、予測モデル内の偏差をもたらすインプットも含めます。これらのインプットはGitLabの予約からARRへの収益予測ウォークの基礎です

    期首ARR + 新規Booked Net ARR + 成長Booked Net ARR + 予約タイミング調整 + (-1*Trueups) + 偏差額 = 期末ARR

    このウォークにより、GitLabはデルタARR値を決定できます。デルタARRは前期の期末ARRと現期の期末ARRの差です。

    期末ARR（現期） - 期末ARR（前期） = デルタARR

  • 収益

    GitLabの収益予測はいくつかのモデルで構成されており、以下に示します。

  • プロフェッショナルサービスモデル

    このモデルはSales Financeが所有し、GitLabのすべてのプロフェッショナルサービス提供についてGitLabが特定の期間に得られると期待する認識済み収益を予測します。期待される認識済み収益の結果は、予約からARRへの収益モデルに入力され、GL勘定科目4002、4010に記録されます。

  • GitLab.comモデル

    このモデルはR&D Financeが所有し、GitLabのすべてのSaaSサービスについてGitLabが特定の期間に得られると期待する認識済み収益を予測します。期待される認識済み収益の結果は、予約からARRへの収益モデルに入力され、GL勘定科目4007に記録されます。

  • 予約からARRへの収益モデル

    このモデルは、Exit MRR（期末ARR / 12）額、GitLab.com額、プロフェッショナルサービス額をまとめて、特定の期間の期待される経常収益を予測します。GitLabはGitLab.com額（GL勘定科目4007に記録）をバックアウトして、サブスクリプション勘定科目GL勘定科目4001を予測します。GitLabは（期末MRR - GitLab.com MRR）を取ることでGL勘定科目4001の金額を導出します。ほとんどの場合、期末MRRは常に認識済み収益以下でなければなりません。

  • テンプレート

    収益モデルテンプレートはGoogle Driveでタイトル「Bookings to ARR to Revenue Walk [Template]」を検索するか、コーポレートFP&Aパートナーに問い合わせることで見つかります。テンプレートは予約から収益へのビルドを分かりやすく追跡しやすいウォーク形式でまとめています。

通貨

配賦ルール

シート

レベル割り当てシート

貸借対照表

貸借対照表は、特定の時点における会社の資産、負債、株主資本を報告する財務諸表です。GitLabの貸借対照表は、Sheetsをクリックし、Balance Sheetをクリックすることで見つかります。

損益計算書

損益計算書は主に特定の期間における会社の収益と費用に焦点を当てます。GitLabの損益計算書は、Sheetsをクリックし、Income Statementをクリックすることで見つかります。

キャッシュフロー

キャッシュフロー計算書は、会社が継続的な事業と外部投資ソースから受け取るすべての現金流入に関する集計データを提供する財務諸表です。また、特定の期間の事業活動と投資のために支払われるすべての現金流出も含まれます。GitLabのキャッシュフロー計算書は、Sheetsをクリックし、Cash Flowをクリックすることで見つかります。

アクティブ人員

アクティブ人員は、部門および事業体ごとのアクティブなヘッドカウントです。GitLabのアクティブ人員は、Sheetsをクリックし、Active Personnelをクリックすることで見つかります。

履歴のヘッドカウント情報とアクティブなヘッドカウントの解約は、終了日を入力してアクティブ人員シートにアップロードすることが推奨されます。これにより、アクティブなヘッドカウント情報のみが予測に含まれることが確保されます。履歴情報により、過去と将来のヘッドカウント比率、ヘッドカウントタイプ別の成長、ランプアップ担当者分析などのヘッドカウント関連分析を実施できます。

計画済み人員

計画済み人員は、特定の期間における部門および事業体ごとの計画済みヘッドカウントです。GitLabの計画済み人員は、Sheetsをクリックし、Planned Personnelをクリックすることで見つかります。

プログラム支出

プログラム支出は、特定の期間に支出されるイベント、サブスクリプション、その他のプログラムの費用に焦点を当てます。プログラム支出は、Sheetsをクリックし、Program Spendをクリックすることで見つかります。

各予測バージョンでは、前期からの費用の実績を手動で入力することが推奨されます。これにより、主要ベンダーごとのトレンドを評価し、必要に応じて将来の期間の予測を調整できます。

費用タイプ

Adaptiveには、異なる計算を持つ4つの費用タイプがあります: （列: EXPENSE_TYPE）

  1. Pre_paid One Time – これは1回限りの前払費用です。
    1. イベント開始日が費用が損益計算書に計上されるタイミングを決定します。
    2. 費用は契約額を契約月数で割って按分されます。
    3. この計算された費用は「GL_EXPENSE_ACCOUNTS」列で選択されたGL勘定科目を決定します。
  2. Pre_paid Amortization – これは前払償却費用です。この計算は以下を考慮します:
    1. イベント開始日が費用が損益計算書に計上されるタイミングを決定します。
    2. 費用は契約額を契約月数で割って按分されます
    3. この計算された費用は「GL_EXPENSE_ACCOUNTS」列で選択されたGL勘定科目を決定します。
    4. 更新の可能性 – %に基づく。
    5. 開始月のアップリフト – 初期契約期間中に発生すると予想されるアップリフトを考慮し、更新月に反映します。
    6. 月次成長率 - 開始月のアップリフトに発生すると予想されるアップリフトの%に基づく。（これは前月比のアップリフトに基づきます）
  3. Per User – これはユーザーごとの費用を計算します。この計算は以下を考慮します:
    1. この計算された費用は「GL_EXPENSE_ACCOUNTS」列で選択されたGL勘定科目を決定します。
    2. ユーザーごとのコスト（列）
    3. 月ごとのユーザー数（タイムスパンで入力）。
  4. Periodic_Expense – これはスポット的な費用です。
    1. この計算された費用は「GL_EXPENSE_ACCOUNTS」列で選択されたGL勘定科目を決定します。
    2. 費用（任意の月のタイムスパンで入力）。

交通費・接待費

交通費・接待費は、ヘッドカウントごとのドル額に基づく交通費・接待費に関連する費用の前提条件です。交通費・接待費は、Sheetsをクリックし、Travel & Entertainmentをクリックすることで見つかります。

ユーザー割り当てシート

グローバル前提条件

州別SUI前提条件

配賦

給与範囲

レベル別人員福利厚生

貸借対照表前提条件

コミッション%

収益モデル

統合

NetSuite

Adaptiveローダー

スケジューリング

数式

レポート

レポート構造

以下の画像は、Adaptive Insightsの現在のレポート構造を示しています。構造内には6つのメインフォルダがあります。「Annual Reports」、「Monthly Reports」、「Quarterly Reports」、「YTD Reports」というラベルのフォルダは本番レポートと見なされ、これらのフォルダのいずれかに移動する前にVP, Financeのサインオフを受ける必要があります。レポートが本番準備できたと見なされる前に、ユーザーは「Sandbox Reports」フォルダでレポートを開始し、VP, Financeの承認を得てから本番準備完了レポートフォルダのいずれかに移動できます。サインオフが承認されたら、ユーザーはAdaptive Insightsの管理者にフォルダをSandboxから本番準備完了フォルダに移動するよう依頼する必要があります。

  1. Annual Reports - 年次レポートを格納するフォルダ
  2. Implementation Requirements - 要件を格納するフォルダ
  3. Monthly Reports - 月次レポートを格納するフォルダ
  4. Quarterly Reports - 四半期レポートを格納するフォルダ
  5. Sandbox Reports - 進行中のレポートを格納し、レポートが作成される本番前フォルダ
  6. YTD Reports - 年度累計レポートを格納するフォルダ

alt text

レポート

ヘッドカウント変動の処理

以下では、発生した変更の種類に基づいてAdaptiveでヘッドカウント変動を処理するプロセスを詳述します。

純増ポジション

GitLabのヘッドカウントを増加させ、チームメンバーのGitLab離脱や部門間異動に関連しない純増採用変動。

  1. 計画済み人員シートで、新しい行を作成し、純増ポジションのポジション詳細を入力します。予定開始日を含め、ヘッドカウント名を「TBH」として入力します。

チームメンバーの退職

GitLabを離れるチームメンバーによるヘッドカウント変動。

  1. チームメンバーがGitLabを離れる場合、ヘッドカウント記録が位置するアクティブ人員シートで、チームメンバーの最終日を「End Date」列に入力します。これにより、Adaptive内の計算に反映され、終了日が過ぎるとそのヘッドカウントに関連するすべてのコストが停止されます。
  2. ポジションをバックフィルする場合は、計画済み人員シートで新しい行を作成し、退職したチームメンバーのポジション詳細を入力します。「Hire Status」フィールドをBackfillにし、退職したチームメンバーがいた同じレベル（部門）に入力されていることを確認します。ヘッドカウント名には「TBH-」+ 名のイニシャル + 姓（例: Joe Bloggsのバックフィルの場合「TBH-JBloggs」）を使用し、そのチームメンバーのバックフィルポジションとして容易に識別でき、ヘッドカウント管理プロセスを支援できるようにします。

昇進（同じジョブファミリー内）、給与引き上げ、新しいHiring Manager等

  1. チームメンバーが同じジョブファミリー内で昇進した場合、給与変更、新しいHiring Managerなどがある場合、新しい情報はアクティブ人員シートのそのヘッドカウントの既存の入力フィールドに上書きされます。アクティブ人員シートのリストをできる限り簡潔に保つことが目的です。
    • 例: Financial Analystがシニアファイナンシャルアナリストに昇進した場合 - Job Titleフィールドを新しいポジション名で上書きし、その他の関連フィールドを更新します。

内部異動

チームメンバーが部門間で異動し、元のポジションがバックフィルされる場合のヘッドカウント変動 - 例: チームメンバーがマーケティングからセールスに移り、マーケティングがそのポジションをバックフィルしたい場合。

  1. アクティブ人員シートで元のヘッドカウント記録に終了日を入力します。
  2. アクティブ人員シートにとどまり、チームメンバーが移動する部門に一致するレベルで新しいエントリ/行を作成し、内部異動ヘッドカウントの詳細を入力します。
  3. 計画済み人員シートで新しい行を作成し、元のポジションの詳細を入力します。ヘッドカウント名には「TBH-」+ 名のイニシャル + 姓（例: Joe Bloggsのバックフィルの場合「TBH-JBloggs」）を使用し、そのチームメンバーのバックフィルポジションとして容易に識別でき、ヘッドカウント管理プロセスを支援できるようにします。

内部採用（バックフィルなし）

候補者が不明で新しいポジションがない内部ヘッドカウント変動 - 例: 3人のアナリストの役職のうち1人を置き換える1人のマネージャーポジションの昇進の機会があるが、誰が昇進するかの可視性がなく、アナリストのポジションはバックフィルされない場合。このプロセスは、採用チームがプレースホルダーエントリーから生成されるGHP IDを使用してGreenhouseにレコードを作成できるようにするために必要です。

  1. 計画済み人員シートで、内部異動のプレースホルダー用のエントリー/行を作成します。ヘッドカウント名を「TBH」、採用ステータスを「Placeholder」として入力し、給与情報が含まれていないことを確認します。これにより、この$0プレースホルダーエントリーの計算が損益計算書に流れないことが確保されます。
  2. 成功したチームメンバーが特定されたら、そのレコードを更新します - 職種、給与情報などを上書きし、計画済み人員シートから内部異動TBHエントリーを削除します。
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License