Zip リクエスト提出のヒント

個人業務用のホームオフィス機器やソフトウェアを5,000ドル未満で購入する場合は、その他のサービスを参照してください。このような場合は Zip 購買リクエストは不要です。

Zip の使い始め方

  1. Okta ホームページから Zip にログインします。
  2. Zip へのアクセスが必要な場合は、こちらでアクセスリクエストを提出してください
  3. Zip のトレーニング資料を確認します:
    • Zip エンドユーザーガイド - さまざまな種類のリクエストの提出方法、承認者グループとしてのリクエストのレビューと承認方法、リクエストのステータス確認方法などの段階的なガイド。

リクエストタイプのヒント

リクエストのコモディティタイプに応じて、Zip リクエスト入力フォームに特定の条件付き質問が表示され、ワークフローに必要な承認グループが含まれ、リクエストのレビューに必要な情報が提供されます。SLA 内でリクエストが完了するよう、以下のヒントに従ってください。

説明とカテゴリ

購入の簡単な説明を提供し、正しいカテゴリ、サブカテゴリ、購入タイプを必ず選択してください。

  • 新規購入は、全く新しい製品またはサービスです。
  • 更新は、既存ベンダーとの更新または追加です。

コンティンジェントワーカーのリクエスト提出

GitLab では2025年3月よりコンティンジェントワーカーポリシーが施行されています。このポリシーは、チームメンバーに対してコンティンジェントワーカーの種類と、それぞれをいつどのように利用すべきかについての概要とガイドラインを提供するために作成されました。確認後、採用を検討しているコンティンジェントワーカーの種類を特定する必要があります。GitLab には3種類のコンティンジェントワーカーがいます:

  • スタッフ増員ワーカー
  • コンサルタントサービス
  • 独立コントラクター

スタッフ増員ワーカー

スキルギャップを埋めるか追加のプロジェクトリソースを提供するために一時的に使用される補完的な非チームメンバースタッフで構成されます。スタッフ増員ワーカーは常に派遣会社によって提供されます。スタッフ増員ワーカーが派遣会社を通じていない場合は、独立コントラクターとして資格を得る必要があります。スタッフ増員ワーカーは GitLab の採用マネージャーの一般的な指導のもとで GitLab 組織内で勤務します。GitLab は業務の成果物に責任を持ちます。ほとんどまたは全く責任がベンダーまたはそのスタッフに移転されません。知識は提供されたワーカーのみから提供されます。GitLab が業務の期間を管理します。「何を」提供し「いつ」提供するかに加えて、GitLab は以下についてもコントロールを維持します。

  • サービスを提供する「誰が」
  • サービスが提供される「どこから」
  • サービスが提供される「どのように」

サービスはフルタイムまたはパートタイムで必要となる場合がありますが、常に恒久的ではなく一時的です。これらのスタッフ増員ワーカーの限られた詳細は、契約ワーカーが Okta とコア GitLab アプリケーションへのアクセスを必要とする場合に Workday に保存されます。

このワーカータイプの最大期間は24ヶ月です。業務終了日は発注書に定められたとおり事前に設定する必要があります。同じスタッフ増員ワーカーは3ヶ月間の空白なしに業務終了後 GitLab に復帰することはできません。

コンサルタントサービス

コンサルタントサービスは、特定の知識領域における専門的なアドバイスを含むプロフェッショナルサービスを提供するために GitLab と契約するベンダーによって提供されます。GitLab は特定のサービスのために第三者と契約を結び、その契約は個々のワーカーではなく作業範囲、つまりサービスや製品のための契約であり、GitLab はそのお客様です。この契約は、専門会社に代わって実行を信頼するコア以外の業務のためのものであり、ビジネスのピーク時に補助労働力を必要とする状況のためではありません。第三者はワーカーに責任を持ち、誰が業務を遂行し、どのように業務を達成するかを決定します。ベンダーは業務委託書(Statement of Work)に記載されたサービス提供の一部またはすべての責任を引き受けます。スタッフの提供に加えて、ベンダーはサービス提供のために自社の知的財産へのアクセスを提供することが期待される場合があります。ベンダーはスタッフを管理します(例:離職)。GitLab は「何を」提供し「いつ」提供するかについての責任を維持しますが、ベンダーは以下についてコントロールを維持します。

  • サービスを提供する「誰が」(スタッフィング)
  • サービスが提供される「どこから」
  • サービスが提供される「どのように」

これらのコントラクター人員の限られた詳細は、契約ワーカーが Okta とコア GitLab アプリケーションへのアクセスを必要とする場合にのみ Workday に保存されます。

契約期間に制限はなく、適用される契約と MSA によって決定されるスコープを完了するために必要な業務期間となります。GitLab は必要に応じて MSA をレビューおよび更新する権利を有します。

独立コントラクター(推奨されないオプション、例外的にのみ使用)

業務委託書(SOW)に組み込まれた成果物のプロジェクト成果物を提供するために自社(個人事業主)を所有する個人。その個人は真に独立して業務を行い、サービスの遂行の詳細、方法、手段について行動の自由が与えられている必要があります。独立コントラクターは通常、複数の企業にサービスを提供します。独立コントラクターは、成果または節目に基づくアレンジメントで業務を行う場合(事業者が達成された成果物に基づいてコントラクターに支払う)や、時間と材料ベースで支払われる場合があります。このコンティンジェントワーカータイプは特定の状況で使用される場合がありますが、その使用は例外的なものにとどまります。全ての独立コントラクターは独立コントラクターサービス契約(ICSA)を使用して契約する必要があります。

独立コントラクター(コンサルタント、フリーランサー、自営業者とも呼ばれる):

  • 成果またはプロジェクトベースの専門知識のために使用される
  • GitLab は「何を」提供し、「誰が」サービスを提供し、「いつ」提供するかについての責任を維持しますが、独立コントラクターは以下についてコントロールを維持します:
    • サービスが提供される「どこから」
    • サービスが提供される「どのように」

関係は GitLab と独立コントラクター間の契約に定義されます。

これらのコントラクター人員の限られた詳細は、契約ワーカーが Okta とコア GitLab アプリケーションへのアクセスを必要とする場合に Workday に保存されます。

このワーカーの最大期間は24ヶ月で、3ヶ月の休止が必要です。終了日は事前に設定する必要があります。

コントラクターの Zip リクエスト提出方法

  1. コンティンジェントワーカーの Zip リクエストを提出する前に:

    • FP&A と管理職からコンティンジェントワーカーを採用するための内部承認を得ていること、およびこの役割が (i) 現在 GitLab 従業員によって実行されていない、または (ii) この役割のオープンなヘッドカウントポジションがないことを確認してください。
    • コンティンジェントワーカーが Okta および/またはコア GitLab アプリケーションへのアクセスを必要とする場合、GitLab ラップトップが発行され、その後 IT Ops がラップトップの発行を確認する Zip 承認を行う必要があります。
    • コンティンジェントワーカーが GitLab 機器(オレンジまたはレッドデータへのアクセスが必要)を必要とする場合は、機器の注文と発送のための通常の承認タイムラインより10日前に Zip 購買要求を提出する必要があります。特定の場所では機器提供前に IT 承認が必要です。IC が GitLab 機器を必要とするかどうかわからない場合は、Slack の #it_help チャンネルにご連絡ください。セキュリティレビューが必要です。
      • リードタイムは購買要求が完全に承認されて PO がリリースされた時点から開始されます。この時間と Zip 承認時間を考慮して、IC の開始日のどのくらい前に Zip リクエストを提出する必要があるかを決定してください。
  2. Zip を開いてコンティンジェントワーカーのリクエストを提出するには、「新規リクエスト」を選択してから「購買リクエスト - コンティンジェントワーカーまたはコンサルタントサービス」を選択します。

  3. 「一般情報」セクションでは、以下の情報を入力する必要があります:

    • リクエスターは誰ですか?*(ほとんどの場合、自分自身です)
    • このリクエストのタイトルを提供してください *(ベストプラクティス:「ベンダー名 - FYXX サービス名/説明」)
    • あなたの購入に最も合う詳細カテゴリを選択してください?*(スタッフ増員、コンサルタントサービス、または独立コントラクターを選択)
    • この購入のタイプは何ですか?*(新規、更新、または延長を選択)
    • このベンダーへの支払いにバーチャルカードを使用しますか?*
    • ベンダーの名前は何ですか?(まず GitLab で以前に使用されたことがあるかどうかを確認してください。ない場合は新規ベンダーを作成する必要があります)
    • コンティンジェントワーカーはどの国で働いていますか?*
    • この業務に対して複数のコンティンジェントワーカーをオンボーディングしますか?*
    • リクエストされたオンボーディング対象者の連絡先情報と個人メールアドレスを持っていますか?*(これはコンティンジェントワーカーを Workday で追跡するために必要です。注:この情報は後日提供できますが、全てが確定する前には必要です)
    • コンティンジェントワーカーのマネージャーは誰ですか?*
    • このコンティンジェントワーカーのビジネスタイトルは何ですか?*
    • コンティンジェントワーカーの GitLab 以外のメールアドレスは何ですか?*
    • コンティンジェントワーカーの法的な名前(ファーストネーム)は何ですか?*
    • コンティンジェントワーカーの法的な名前(ラストネーム)は何ですか?*
    • コンティンジェントワーカーの優先ファーストネームは何ですか?*
    • コンティンジェントワーカーの優先ラストネームは何ですか?*
    • コンティンジェントワーカーの住所は何ですか?*
  4. 「支出情報」セクションでは、以下の情報を入力する必要があります:

    • この購入はどの子会社のためですか?*(FP&A がこの回答を助けることができます)
    • この購入・契約の希望する開始日と終了日はいつですか?*(注:スタッフ増員の場合、開始・終了日は24ヶ月を超えてはなりません)
    • この購入に必要な予算はいくらですか?*
    • ライン種別(「金額」を選択)
    • Coupa 子会社(通常は GitLab Inc のような法人)
    • Coupa 部門(通常は所属する組織)
    • Coupa GL アカウント(6017 コンサルティング費用を選択)
    • 以下の支援書類はありますか?*(MSA、SOW など)
  5. 「IT、セキュリティ、プライバシー情報」セクションでは、以下の情報を入力する必要があります:

    • ベンダーはデータや情報にどのような種類のアクセスを必要としますか?*
    • 個人デバイスを通じた GitLab リソースへのアクセスは許可されていません。コンティンジェントワーカーにはベンダーが管理するラップトップが発行されていますか?*
    • このリクエストには Web アプリケーション、Web ポータル、またはソフトウェアシステムの使用が含まれますか?*
  6. Zip リクエストは該当するステークホルダーによってレビューされます

  7. Zip リクエストが承認されたら、個人コントリビューターオンボーディング Issue を開いて完了します。

  • IC の契約期間を延長する必要がある場合は、Zip 変更リクエストを提出します。

  • コントラクターの契約を指定された期間より前にキャンセル/終了する必要がある場合は、キャンセルプロセスを確認し、#procurement Slack チャンネルで購買チームに連絡してください。

オレンジおよびレッドデータへのアクセスが必要なコンティンジェントワーカーで、GitLab のシステム外で処理または保存されるものは「プロフェッショナルサービス」とみなされ、完全なセキュリティレビューの対象となります。詳細については、セキュリティサードパーティリスク管理ハンドブックをご覧ください。

新規ソフトウェアリクエストの提出

  1. 新規ソフトウェア購入もITによるレビューが必要です。
  2. 新規ソフトウェアベンダーはIT アンケートタブに記入する必要があります。
    • IT はこの情報をアプリケーションを GitLab の技術要件に対して包括的に評価するために使用します。
    • このタブのコピーを作成し(正式な RFP 中に記入されていない場合)、ベンダーに記入してもらい、IT レビューのために Zip リクエストの書類セクションに添付してください。
  3. IT アンケートに関するご質問は、#enterprise-apps Slack チャンネルでエンタープライズアプリケーションチームにお問い合わせください。

リクエスト提出のその他のヒント

  1. このベンダーへの支払いにバーチャルカードを使用しますか?
    • これは、サプライヤーがオンラインクレジットカード決済のみを受け付ける場合や、イベントなどの一回限りのベンダー使用に適用されます。許可される使用の詳細はこちら
    • バーチャルカードを使用したリクエストの提出方法については、Zip エンドユーザーガイドの詳細をご覧ください。
  2. ベンダー名と主要連絡先
    • 既存のベンダーまたはわからない場合は、Zip でベンダー名を入力し始めてください。ベンダーが存在する場合、Zip がドロップダウンに表示します。既存の主要ベンダー連絡先を選択するか、「新規連絡先を追加」を選択して連絡先情報を入力できます。
    • 新規ベンダーの場合:
      • ベンダー選定プロセスRFP ガイドラインを確認するか、ご質問やサポートが必要な場合は購買カテゴリマネージャーに連絡してください。
      • このサプライヤーがシステムにまだ登録されていない場合は、サプライヤー名を入力した後に「新規追加」オプションをクリックする必要があります。購買チームが新規ベンダーオンボーディング手順を完了できるよう、全ての詳細を入力してください。現在は Zip を内部で使用していますが、Coupa は依然としてサプライヤーへの支払いに使用するツールです。
  3. 支出情報
    • 必要な予算額、契約期間、および明細項目の詳細を含む全ての支出詳細を提供してください。
    • 明細内訳は注文フォーム/契約書の明細項目と一致させ、複数年契約の場合は各年について個別に入力してください。
    • 明細項目の合計は予算に入力された金額と一致する必要があります。
    • 受け取った支援書類のチェックボックスにチェックを入れてください。これらはリクエストプロセスの最後に書類セクションでアップロードします。
  4. IT & セキュリティ情報:
    • データ情報セクションを入力してください。選択内容に応じて、追加の必須質問が表示されます。
    • データが共有される場合、ベンダーセキュリティレビューが実施されます。ベンダーはセキュリティプロトコルに関する情報を要求する GitLab のセキュリティリスクチームからのメール通知を受け取ります。
    • 個人データが共有またはアクセスされる場合、プライバシーレビューが必要な場合があります。ベンダーはデータプライバシー慣行に関する情報を要求する Zip からの通知を受け取ります。
    • ベンダーおよび/またはシステムがアクセスするデータの種類、およびそのデータをどのように受け取るかについての具体的な詳細をできるだけ明記してください。このセクションを正確に入力しないと、リクエストのレビューと承認が遅延します。
    • 個人データが共有される場合、ベンダーは州および/または国の法的要件に従って DPA と SCC に署名する必要があります。
    • ヒント: 承認速度を上げるには、サプライヤー連絡先に GitLab の DPA/SCC を今すぐ送って確認を依頼してください。DPA については、スケジュール1とスケジュール3をサプライヤーが記入する必要があることをサプライヤー連絡先に知らせてください。また、セキュリティの完了のために GitLab のセキュリティリスクチームからの、プライバシーレビューの完了のために Zip からのリクエストに注意するよう伝えてください。これらなしではレビューと承認を開始できないことを伝えてください。
  5. 書類とアンケート:
    • 使用量に基づくソフトウェアの更新/追加(例:ユーザー数)については、購買レビューのために使用量レポートが必要です。これはリクエストプロセスの最後の「追加参考ファイルを添付してください」の下にある書類セクションでアップロードできます。
      • 使用量レポートに基づいて、購買は数量を増加、減少、または現状維持するためのリクエストをレビューします。
    • 受け取った契約書および/または見積もりをアップロードしてください。
      • ドラフト契約書でも可能です。まだ最終決定されていない条件および/または価格についてはメモを残してください。これはリクエストを提出した後のコメントセクションで行えます。

Zip 変更リクエスト

既存のサプライヤーとの PO があり、コストが増加、終了日が変更、および/または範囲や条件が変更になった場合は、Zip 変更リクエストを提出することができます。

Zip 変更リクエストを提出することで、該当する承認者が Zip ワークフローに追加されてレビューを行い、購買チームがあなたに代わって Coupa の PO を修正します。なお、既存の PO への変更も新規購買リクエストと同様に Coupa で財務、機能、エグゼクティブ(該当する場合)チームメンバーによる承認が必要です。

購買リクエストが承認されたら

  1. Zip と Coupa の購買リクエストが承認されると、PO が生成され、GitLab は正式に購入の注文を行ったことになります!これにより業務を開始し、製品・サービスを取得することができます。
  2. サプライヤーは売掛金用として提供したメールアドレスに PO の注文と番号のコピーを受け取ります。
  3. サプライヤーは Coupa から次の2つの方法のいずれかで支払いの仕方を知らせる通知を受け取ります:
    • Coupa ポータルで直接
    • PO 番号を請求書に記載して [email protected] に請求書を送付
    • これらの指示に従わないと支払いが遅延します
    • GitLab チームメンバーが Coupa にアップロードした請求書は支払いのためにルーティングされません。
  4. リクエストに新規ソフトウェアが含まれていた場合は、Zip リクエストが完全に承認されて契約が署名されたら、HelpLab のテックスタック更新フォームを通じてシステムの詳細を提出してください。

購買オフィスアワー

ハンドブックに記載されていないご質問や懸念がある場合は、毎週水曜日の購買オフィスアワーにご参加ください。この専用の時間に、購買チームがご質問にお答えし、ご支援します。コールに参加できない場合は、アジェンダにご質問を提出いただければ、迅速に回答いたします。