Content last updated 2026-07-08

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

個人の業務利用のために Home Office Equipment および / または Software を購入し、その金額が <$5K USD の場合、これらのケースでは Zip Purchase Request は不要なため、Other Servicesを参照してください。

Zip の始め方

  1. Okta home pageから Zip にログインします。
  2. Zip アクセスが必要な場合は、こちらからアクセスリクエストを提出してください。
  3. Zip トレーニング資料を確認します。
    • Zip End Users Guide - さまざまなタイプのリクエストの提出方法、承認者グループ向けのリクエストのレビューおよび承認方法、リクエストステータスの確認方法などを段階的に説明しています。

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

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

説明とカテゴリ

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

  • New purchase は、まったく新しいプロダクトまたはサービスを指します。
  • Renewal は、既存ベンダーとの更新またはアドオンを指します。

Contingent Worker のリクエスト提出

GitLab では、2025 年 3 月から Contingent Worker Policyを導入しています。このポリシーは、利用可能な各種 contingent worker の概要とガイドライン、およびそれぞれをどのように、いつ使用すべきかをチームメンバーに提供するために設計されています。確認後、採用したい contingent worker のタイプを特定する必要があります。GitLab には contingent worker のカテゴリが 3 つあります。

  • Staff Augmentation Workers
  • Consultancy Services
  • Independent Contractors

Staff Augmentation Workers

スキルギャップを埋める、または追加のプロジェクトリソースを提供するために一時的に使用される、Team Member ではない補助スタッフで構成されます。Staff Augmentation Workers は常にエージェンシーから提供されます。Staff Augmentation Worker がエージェンシー経由でない場合、Independent Contractor として適格でなければなりません。Staff Augmentation Worker は、GitLab hiring manager の一般的な指示の下で GitLab organization 内で働きます。GitLab は作業成果物に対する責任を維持します。ベンダーまたはそのスタッフに移転される責任はほとんど、またはまったくありません。知識は提供された worker からのみ提供されます。GitLab がアサインメントの期間を管理します。提供される「what」と「when」に加えて、GitLab は以下を管理します。

  • サービスを提供する「who」
  • サービスが提供される「where」
  • サービスが提供される「how」

サービスはフルタイムまたはパートタイムで必要になる場合がありますが、常に恒久的ではなく一時的なものです。これらの Staff Augmentation Worker の限定的な詳細は、contract worker が Okta と主要な GitLab アプリケーションへのアクセスを必要とする場合、Workday に保持されます。

この worker タイプの最長期間は 24 ヶ月です。アサインメント終了日は、Purchase Order に定められるとおり、事前に設定されている必要があります。同じ Staff Augmentation worker は、アサインメント終了後 3 ヶ月間 GitLab に戻ることはできません。

Consultancy Services

Consultancy Services は、特定の知識領域における専門的助言を含むプロフェッショナルサービスを提供するため、GitLab と契約するベンダーによって提供されます。GitLab は特定のサービスについて第三者と契約し、その契約は作業範囲、つまり個人 worker ではなくプロダクトまたはサービスの契約であり、GitLab が顧客です。この取り決めは、専門企業に GitLab の代理として実行してもらうことを信頼するノンコア作業のためのものであり、ビジネスのピークを支援する補助労働力が必要な状況のためのものではありません。第三者は worker(s) に責任を持ち、誰が作業を行い、どのように作業を達成するかを決定します。Vendor は Statement of Work に詳述されているとおり、サービス提供の一部または全部の責任を負います。スタッフの提供に加えて、Vendor はサービス提供のために自社の Intellectual Property へのアクセスを提供することが期待される場合があります。Vendor は自社スタッフを管理します（例: 離職）。GitLab は提供される「what」と「when」に対する責任を維持しますが、vendor は以下を管理します。

  • サービスを提供する「who」（staffing）
  • サービスが提供される「where」
  • サービスが提供される「how」

これらの Contractor Personnel の限定的な詳細は、contract worker が Okta と主要な GitLab アプリケーションへのアクセスを必要とする場合にのみ、Workday に保持されます。

契約期間に制限はなく、該当する契約と MSA によって決定される作業範囲を満たすために必要なアサインメント期間になります。GitLab は必要に応じて MSA をレビューおよび更新する権利を有します。

Independent Contractor（推奨されないオプション、例外的にのみ使用）

Statement of Work（SOW）に組み込まれるプロジェクト成果物を提供する、自分が所有する会社（個人事業）で働く個人です。その個人は、サービスを実行する詳細、方法、手段について行動の自由を与えられ、真に独立して働かなければなりません。Independent contractors は通常、複数の会社にサービスを提供します。Independent contractors は、ビジネスが達成された成果物に基づいて contractor に支払う成果ベース / マイルストーン型の取り決めで働く場合も、時間と材料ベースで支払われる場合もあります。この contingent worker タイプは特定の状況で使用される場合がありますが、その使用は例外的な場合に限られます。すべての Independent Contractors は、Independent Contractor Service Agreement（ICSA）を使用して契約する必要があります。

Independent contractors（consultants、freelancers、self-employed workers とも呼ばれます）:

  • 成果またはプロジェクトベースの専門知識に使用されます
  • GitLab は提供される「what」、「who」、および「when」に対する責任を維持しますが、Independent Contractor は以下を管理します。
    • サービスが提供される「where」
    • サービスが提供される「how」

関係は GitLab と independent contractor の間の契約で定義されます。

これらの Contractor Personnel の限定的な詳細は、contract worker が Okta と主要な GitLab アプリケーションへのアクセスを必要とする場合、Workday に保持されます。

この worker の最長期間は 24 ヶ月で、3 ヶ月の休止期間があります。終了日は事前に設定されている必要があります。

Contractor の Zip Request を提出する方法

  1. Contingent Worker の Zip request を提出する前に:

    • contingent worker を採用するために FP&A とマネジメントから内部承認を得ていること、またこのロールが (i) 現在 GitLab Employee によって実行されていない、または (ii) このロールに対する未充足の headcount ポジションが存在しないことを確認してください。
    • Contingent Worker が Okta および / または主要な GitLab core applications へのアクセスを必要とする場合、GitLab laptop を発行し、その後 IT Ops による laptop 発行の検証として Zip 承認が必要です。
    • Contingent Worker が GitLab equipment（例: Orange または Red data へのアクセス）を必要とし、それにより Security Reviewが必要になる場合、機器の注文と配送を考慮するため、通常の承認タイムラインの 10 日前に Zip purchase requisition を提出する必要があります。特定の場所では、機器提供前に IT Approval が必要です。IC に GitLab equipment が必要か不明な場合は、Slack の Compass app（上部の検索バーに “Compass” と入力して見つけてください）または [email protected] から IT にお問い合わせください。
      • Lead times は、purchase requisition が完全に承認され、PO がリリースされた時点から始まります。この時間と Zip approval timesを考慮して、IC の開始日前にどれだけ早く Zip Request を提出する必要があるかを判断してください。

  2. Zip を開き、“New Request” を選択してから “Request a Purchase - Contingent Worker or Consultancy Services” を選択し、contingent worker のリクエストを提出します。

  3. “General Information” セクションでは、以下の情報を入力する必要があります。

    • リクエスト者は誰ですか？ *（多くの場合、これはあなた自身です）
    • このリクエストのタイトルを入力してください *（ベストプラクティス: “Vendor Name - FYXX Services Name/Description”）
    • あなたの購入を最もよく表す詳細カテゴリはどれですか？ *（Staff augmentation、Consultancy Services、または Independent Contractor のいずれかを選択）
    • これはどの種類の購入ですか？ *（new、renewal、または extension を選択）
    • この vendor への支払いに virtual card を使用しますか？ *
    • vendor 名は何ですか？（その vendor が以前 GitLab で使用されたことがあるかを先に確認し、なければ新しい vendor を作成する必要があります）
    • contingent worker はどの国から勤務しますか？ *
    • この engagement で複数の contingent workers をオンボーディングしますか？ *
    • リクエストされた onboardee の連絡先情報と個人用メールアドレスを持っていますか？ *（これは Workday で contingent workers を追跡するために必要です。注: この情報は後日でも構いませんが、すべてが確定する前でなければなりません）
    • Contingent Worker の Manager は誰ですか？ *
    • この Contingent Worker の Business Title は何ですか？ *
    • Contingent Worker の GitLab 以外のメールアドレスは何ですか？ *
    • Contingent Worker の法的な First Name は何ですか？ *
    • Contingent Worker の法的な Last Name は何ですか？ *
    • Contingent Worker の Preferred First Name は何ですか？ *
    • Contingent Worker の Preferred Last Name は何ですか？ *
    • Contingent Worker の住所は何ですか？ *

  4. “Spend Information” セクションでは、以下の情報を入力する必要があります。

    • この購入はどの subsidiary 向けですか？ *（FP&A が回答を支援できますか?）
    • この購入 / 契約の希望開始日と終了日はいつですか？ *（注: Staff Augmentation の場合、Start/End date は 24 ヶ月を超えてはいけません）
    • この購入にはどれくらいの予算が必要ですか？ *
    • Line type（“amount” を選択）
    • Coupa Subsidiary（通常は US の GitLab Inc のようなあなたの entity です）
    • Coupa Department（通常はあなたが所属する org です）
    • Coupa GL Account（6017 Consulting Fees を選択）
    • 以下の補足資料のいずれかを持っていますか？ *（MSA、SOW など）

  5. “IT, Security, and Privacy Information” セクションでは、以下の情報を入力する必要があります。

    • vendor はデータや情報に対してどの種類のアクセスを必要としますか？ *
    • 個人所有デバイスから GitLab resources へアクセスすることは許可されていません。contingent worker には vendor 管理の laptop が支給されていますか？ *
    • このリクエストには web application、web portal、または software system の使用が含まれますか？ *

  6. Zip Request は該当するステークホルダーによってレビューされます。

  7. Zip Request が承認されたら、Individual Contributor Onboarding Issueを開いて完了します。

  • IC の契約期間を延長する必要がある場合は、Zip Change Requestを提出してください。

  • Contractor の契約を指定期間より早くキャンセル / 終了する必要がある場合は、Cancellation processを確認し、#procurement Slack channel で Procurement Team に連絡してください。

Orange and Red Data へのアクセスが必要で、GitLab のシステム外で処理または保存される Contingent Workers は “Professional Services” とみなされ、完全な security review の対象になります。詳細については、Security Third Party Risk Management Handbookを参照してください。

New Software のリクエスト提出

  1. すべての新規ソフトウェア購入は、ITによるレビューも必要です。
  2. 新規ソフトウェアベンダーは、IT Questionnaire tabを完了する必要があります。
    • IT は、GitLab の技術要件に照らしてアプリケーションを包括的に評価するため、この情報をリクエストします。
    • このタブのコピーを作成し（正式な RFP 中に入力されていない場合）、ベンダーに記入してもらい、IT レビューのために Zip Request の documents セクションに添付してください。
  3. IT Questionnaire に関する質問がある場合は、#enterprise-apps Slack channel で Enterprise Applications team にお問い合わせください。

リクエスト提出に関するその他のヒント

  1. このベンダーへの支払いに virtual card を使用しますか？
    • これは、supplier がオンラインのクレジットカード決済のみを受け付ける場合、またはイベントなど 1 回限りの vendor 利用の場合に適用されます。許可される用途の詳細はこちらです。
    • virtual card を使用したリクエスト提出方法の詳細は、Zip End Users Guideにあります。
  2. Vendor Name と Primary Contact
    • 既存 vendor、または不明な場合は、Zip で vendor 名の入力を開始してください。vendor が存在する場合、Zip がドロップダウンに表示します。その後、既存の Primary Vendor Contact を選択するか、‘Add new contact’ を選択して連絡先情報を入力できます。
    • New Vendor の場合:
      • Vendor Selection Processと RFP guidelinesを確認するか、質問やサポートが必要な場合は Procurement Category Manager に連絡してください。
      • この supplier がまだシステムにない場合、supplier 名を入力した後に “add new” オプションをクリックする必要があります。Procurement team が New Vendor Onboarding stepを完了できるよう、すべての詳細を必ず入力してください。現在は社内で Zip を使用していますが、suppliers への支払いには引き続き Coupa が使用されます。
  3. Spend Information
    • 必要な budget amount、contract term、line item details を含む、すべての spend details を提供してください。
    • Line Item Breakdown は Order Form/Contract の line items と一致している必要があり、multi-year term の場合は契約の各年について個別に入力する必要があります。
    • Line Items の合計は、budget に入力した金額と一致している必要があります。
    • 受領済みの supporting documentation のボックスにチェックを入れてください。リクエストプロセスの最後に Documents セクションでこれらをアップロードします。
  4. IT & Security Information:
    • Data Information セクションを完了してください。選択内容に応じて、追加の必須質問が表示されます。
    • データが共有される場合、Vendor Security Review が完了されます。ベンダーは GitLab の Security Risk Team から、セキュリティプロトコルに関する情報を求めるメールを受け取ります。
    • 個人データが共有またはアクセスされる場合、Privacy Review が必要になる場合があります。ベンダーはデータプライバシー慣行に関する情報を求める Zip からの連絡を受け取ります。
    • ベンダーおよび / またはシステムがアクセスできるデータの種類と、そのデータをどのように受け取るかについて、できるだけ具体的に記載してください。このセクションを正確に完了しないと、リクエストのレビューと承認が遅れます。
    • 個人データが共有される場合、ベンダーは州および / または国の法定要件に従って、GitLab の DPA および SCC’s に署名する必要があります。
    • TIP: 承認速度を上げるため、サプライヤー担当者に GitLab の DPA/SCCsをすぐにレビューしてもらってください。DPA については、Schedule 1 と Schedule 3 をサプライヤーが記入する必要があることをサプライヤー担当者に伝えてください。また、GitLab の Security Risk Team からのセキュリティ完了確認と Zip からのプライバシーレビュー完了確認のリクエストについても知らせてください。これらがないとレビューと承認を開始できないことを伝えてください。
  5. Documents & Surveys:
    • usage（例: user quantities）に基づく software renewal/add-on については、Procurement のレビュー用に usage report が必要です。これはリクエストプロセスの最後に Documents セクションの ‘Please attach any additional files for reference’ にアップロードできます。
      • usage report に基づいて、Procurement は quantities を増やす、減らす、または横ばいに保つリクエストをレビューします。
    • 受領した契約書および / または見積書をアップロードしてください。
      • Draft contracts でも問題ありません。まだ確定していない terms および / または pricing がある場合は、リクエスト提出後に Comments セクションでメモしてください。

Zip Change Requests

既存 supplier の PO があり、コストが増加した、終了日が変更された、または scope や terms and conditions の修正が必要な場合は、Zip Change Requestを提出できます。

Zip Change Request を提出すると、該当する approvers がレビューのため Zip workflow に追加され、Procurement team があなたに代わって Coupa の PO を修正します。なお、既存 PO への変更も、新しい Purchase Request と同様に、Coupa 内で Finance、Functional、Executive（該当する場合）team members による承認が必要です。

Purchase Request が承認された後

  1. Zip と Coupa の Purchase Request が承認されると、PO が生成され、GitLab はあなたの購入について正式に注文を行います。これで作業および / またはプロダクト / サービスの取得を開始できます。
  2. supplier は、Accounts Payable 用に提供したメールアドレスで PO order と number のコピーを受け取ります。
  3. supplier は、Coupa から以下 2 つの方法のいずれかで支払いを行う方法について連絡を受け取ります。
    • Coupa portal で直接
    • PO number を invoice に含めて [email protected] に invoice を送信
    • これらの指示に従わないと支払いが遅れます
    • GitLab team member によって Coupa にアップロードされた invoices は支払いにルーティングされません。
  4. リクエストが new software を含む場合、Zip Request が完全に承認され契約が署名されたら、HelpLab の Tech Stack Update Formを通じて system details を提出してください。

Procurement Office Hours

ハンドブックで扱われていない質問や懸念がある場合は、毎週水曜日の Procurement Office Hours への参加を歓迎します。この専用時間中、Procurement Team が支援し、質問に回答します。通話に参加できない場合は、Agendaに質問を自由に提出してください。迅速に回答できるようにします。

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License