Content last updated 2026-05-22

GitLab におけるプロダクトマネージャーの役割

このページでは、GitLab でプロダクトマネージャーとして働くための概要と、それに役立つリソースへのリンクを掲載しています。

このページでは、GitLab でプロダクトマネージャーとして働くための概要と、それに役立つリソースへのリンクを掲載しています。GitLab でプロダクトマネージャーの仕事をどのように評価するかをよりよく理解するには、プロダクトマネジメントの CDF とコンピテンシーをご覧ください。

Principles - Processes - Categories - GitLab the Product - Being a PM - Leadership

プロダクトの組織構造

GitLab の Product チームには、さまざまなレベルのプロダクトマネジメントの職位およびプロダクトマネジメント - リーダーシップの職位のチームメンバーが含まれます。彼らは私たちの組織レベルにマッピングされ、下記の表に概説されているプロダクト階層のさまざまなポイントでスコープを持ちます。

  • プロダクト組織は GitLab のレイヤー構造に従います。場合によっては、レイヤーをまたいだピアが同じ職位を持たないケースもあります。
レベル職位階層スコープ
ICProduct Manager, Senior PM, Principal PMGroup, Stage
ManagerGroup Manager Product, Director of ProductCollection of Groups, Stage, Section
DirectorDirector of Product, Senior Director of ProductSection, Collection of Sections
Senior LeaderVPAll Sections（ただしスコープやビジネスニーズによっては、それより少ない範囲をカバーすることもあります）
ExecutiveChief Product Officerファンクション全体

GitLab で PM として働く

責任

PM としてのあなたの仕事は、プロダクトマネージャーの責任に概説されています。

GitLab で PM として始めるにあたって

最初にすべきことは、以下のハンドブックページに慣れ親しむことです

GitLab のプロダクトマネージャーとして、あなたのプロダクトスコープは膨大です! 最初は気が遠くなるかもしれませんが、GitLab はあなたが成功できるように、プロセスと組織を絶えずイテレーションしています。すべてはドラフトなので、物事を改善するためにプロポーザルを作成してください。

PM として、人々から頼まれるすべてのことをやろうとすると、極端に忙しくなる可能性があります。これはこの役割に対する私たちの期待ではありません。 私たちは、あなたが巧みに優先順位をつけ、マネージャー・オブ・ワンであることを期待しています。そして、あなたのコアの責任が何であるかを覚えておいてください! もし To-Do に溺れていることに気づいたら、一歩下がって優先順位をつけ、押し返し、最も重要なことにエネルギーを集中させてください。PM が何を所有するかの詳細については、Product Manager の職種ファミリーを参照してください。

役立つリマインダーをいくつか:

  • PM として、あなたは新しいイニシアチブを立ち上げる人です。あなたは何かを期限内に出荷する責任を負っているわけではありませんが、行動を起こし、ディレクションを設定する責任は あります。あらゆる場所で活発に動き、過剰に伝え、自分が重要だと思うことをチームやコミュニティの残りのメンバーに売り込んでください。
  • PM として、あなたはエンジニアリングのバーを設定する必要があります。つまり、エンジニアリングや会社の他の部分を後押しするということです。プロダクトが設定するペースについて、エンジニアリングがほとんど不満を漏らすくらいが望ましいのです。私たちのデフォルトの本能はペースを落とすことですが、それに屈してはいけません。
  • PM として、あなたはプロダクトを所有しているわけではありません。他の人にフィードバックを求め、あなたの直接的な介入なしにチームメンバーやコミュニティが提案したり物事を作り出したりできる余地を与えてください。物事が決定され、計画されることを確実にするのがあなたの仕事であり、あらゆるアイデアや変更を考え出すことではありません。

助けが必要なときはどこを見ればよいですか?

  • 最初にすべきことは、このページとこのページからリンクされているページを注意深く読むことです。
  • ほとんどの答えはハンドブックにも記載されています。答えが見つからない場合は、ぜひプロポーザルを追加してください!
  • プロダクトに関連する質問は #product Slack チャンネルで尋ねることができます。
  • 一般的な質問は #questions で尋ねるべきです。
  • Git 固有の質問は #git-help で尋ねるべきです。
  • MR に問題がある場合は、#mr-buddies で尋ねてください。
  • HR の質問は HelpLab で尋ねるべきです。
  • リリース投稿関連のことはすべて、リリース投稿ハンドブックおよび #release-post で見つけることができます。

職務要件

Product Manager、Sr. Product Manager、Principal Product Manager、Group Manager, Product Management、 Director of Product、 VP of Productの職務要件と期待は、私たちの職種ファミリーページに概説されています。

プロダクトマネージャーがプロダクトのキャリアで前進するにつれて、私たちはプロダクトマネージャーが新しいプロダクト領域に移ることで新しい挑戦に取り組むことを奨励しています。あるいは、IC の PM がマネジメントトラックの役割に応募することも、その逆も奨励しています。

プロダクトの役割における戦術的、運用的、戦略的な責任配分の進行は、このチャートでよく示されています。

GitLab PM 責任配分チャート

ソースファイル。注 - インスピレーションをくれた Melissa Perri に感謝します

PM が念頭に置いておくべき重要な日付

毎月 4 日:

次のリリースに含まれる Issue のドラフト。 エンジニアリング／UX とのキャパシティおよび技術的な議論を開始します。

毎月 12 日:

リリーススコープが確定されます。スコープ内の Issue にマイルストーンを付けます。 キックオフドキュメントが、含めるべき関連項目で更新されます。

毎月 15 日:

グループのキックオフコールが、その日の終わりまでに録画されアップロードされます。

Product Development Timelineも参照してください。

責任の範囲

プロダクトチームは、GitLab のほとんどのプロダクトおよびプロジェクトのイテレーションに責任を負います:

  • GitLab CE および EE
  • GitLab.com
  • about.gitlab.com
  • customers.gitlab.com
  • version.gitlab.com

これにはスタック全体とそのすべての側面が含まれます。プロダクトチームは、バグ、機能、リグレッション、パフォーマンスだけでなく、GitLab の卓越性を確保するために必要なアーキテクチャの変更やその他の側面も比較検討し、優先順位をつける必要があります。プロダクトマネージャーは、全体的な作業の優先順位付けの DRI ですが、各作業タイプから正しい優先順位が考慮されることを確実にするために、EM および UX の安定したカウンターパートと協力して作業します（それぞれ異なる DRI がいるため）。

プロダクトマネジメントのための学習と開発

私たちは、GitLab での仕事において、またそれを超えて長期的なキャリア目標を達成するために、プロダクトマネージャーの成長と成功をサポートする最高のリソースを収集しハイライトすることに特化したライブラリを用意しています。私たちは、プロダクトマネージャーがマネージャーと協力して改善すべき領域を特定し、それに応じてプロダクトマネジメントのための学習と開発のリソースを活用することを奨励しています。

プロダクトマネージャーのオンボーディング

プロダクトマネージャーのオンボーディングは、2 つの関連する Issue テンプレートで構成されています。

GitLab People Operations オンボーディング Issue は、新入社員の入社日のおよそ 4 〜 10 営業日前に People Operations によって生成されます。詳細は GitLab オンボーディングプロセスで確認できます。この Issue は採用マネージャーに割り当てられ、採用マネージャーは自身のタスクを実行した後、新しいプロダクトマネージャーの採用者に割り当てます。この Issue にはプロダクト固有のセクションがあり、最初の 4 週間以内に完了する必要があるクラリカルなプロダクトタスク（例: チームとの紹介コールのスケジュール設定）が含まれています。採用マネージャーは、Issue 内で割り当てられた People Operations チームメンバーにメンションするか、HelpLab で助けを求めることができます。プロダクトマネージャーはこの一般的なオンボーディングに 4 週間以上を費やすべきではなく、必要に応じてテンプレート内の項目に優先順位をつけて時間的なコミットメントを管理するためにマネージャーと相談すべきです。

さらに、プロダクトチームには最初の 100 日テンプレートがあります。

採用マネージャーは 最初の 100 日テンプレート を準備／パーソナライズします。私たちはバリューに従ってこれらの Issue をデフォルトで公開することを奨励していますが、機密情報や個人データがある場合は、マネージャーの裁量で confidential とマークされることがあります。最初の 100 日 Issue は、新しいプロダクトマネージャーの入社日にオープンになっているべきです。彼らがこの Issue に取り掛かることは期待されていませんが、これから来ることの一般的なイメージを与えることを意図しています。一般に、最初の 100 日 Issue は、プロダクトマネージャーの入社日からおよそ 2 〜 4 週間後の、新しいマイルストーンの開始頃に立ち上がります。このタイミングは、新しいプロダクトマネージャーが「職場」での最初の 100 日がより戦略的にどのようなものになるかを把握し始める前に、戦術的／一般的なオンボーディングのための十分な時間を確保できるようにすることを意図しています。ただし、最初の 100 日のタイミングや内容は、最終的にはプロダクトマネージャーとそのマネージャーの間で合意することになります。

新入社員も、最初の 100 日テンプレート の目標を定義し追加することに参加すべきです。マネージャーは、この目標志向のオンボーディング Issue を、新しいプロダクトマネージャーの最初の CDF レビューに活用し、PM が GitLab での役割に落ち着くのを支援する形でチームメイトを効果的に整合させることが推奨されます。これらの最初の 100 日オンボーディング Issue を例として見てみてください: 3291 と 2809。

私たちは 2 つのテンプレートを使用しているため、プロダクトマネージャーは最初の 1 か月間、より緊急で戦術的なタスクを伴う GitLab のオンボーディングに集中できます。新しいプロダクトマネージャーが GitLab により慣れてくると、GitLab での最初の 3 か月で、より戦略的で時間的制約の少ないオンボーディングタスクに移行できます。

オンボーディング Issue は、Product Onboarding Issue ボードで追跡できます。

プロダクトマネージャーのオンボーディングバディ

オンボーディングの一環として、新入社員にはオンボーディングバディが割り当てられます。プロダクトマネージャーのオンボーディングバディとして、新入社員と共有すべき多くのプロセスとリソースがあります。プロダクトマネージャー固有のタスクとリソースのリストはこちらで見つけることができます。

プロダクトマネジメント候補者の面接

プロダクトマネジメント候補者の面接プロセスにおける独特で重要なステップが、私たちの Deep Dive 面接です。この面接の目標は、候補者が長期的なビジョンと短期的な MVC の両方を、面接そのものの中で口頭で、また 2 つのフォローアップ Issue を通じて文章で伝える能力を理解することです。Issue を読む準備ができたら、フィードバックを提供し、候補者がそのフィードバックにどう反応するかを見る機会となります。

Deep Dive 面接に関する詳細と手順はこちら（社内のみ）で見つけることができます。私たちの採用プロセスに関する情報は、採用ハンドブックページをご覧ください。 |

休暇を取る

チームメンバーは、年に 2 週間連続の休暇を取ることを強く推奨されています。no ask, must tell（聞かなくてよい、ただし伝えること）の GitLab 有給休暇より長い長期休暇は、特に育児休暇では一般的です。長期間離れることは気が引けるかもしれませんが、あなたの rest ethic（休む倫理）が work ethic（働く倫理）と釣り合っていることを確保し、また会社に単一障害点がないことを確保するために、これは非常に重要です。プロダクトマネージャーがこの期間を計画するのに役立ついくつかの提案を以下に示します。

高レベルでは、これらが最も重要な 2 つのことです:

  1. 休暇を伝える
  2. PM カバレッジ Issue を作成する（詳細は下記）

PM カバレッジ Issue の作成

この Issue テンプレートを使用して、ハンドシェイクの責任を定義できます。 長期休暇の場合、あなたが不在の間にプロダクトの意思決定を行える 1 名以上の Directly Responsible Individual（DRI）を見つけることが重要です。 これは、あなたのマネージャー、別の PM、あるいはあなたのチームのエンジニアリングマネージャーかもしれません。カバレッジ Issue には、DRI があなたの不在中に適切な決定を下すために必要なすべての情報を含めるべきなので、必要なだけ詳細を含めるようにしてください。

Issue を作成することに加えて、あなたが離れる前に全員が同じ認識を持っていることを確実にするために、専用の引き継ぎミーティングを持つことが役立つ場合があります。

カバレッジタスクの割り当てのために部門横断的なチームメイトのキャパシティを検討する際は、マネージャーや Quad のメンバーと協力することが推奨されます。たとえば、PM、EM、PD は、顧客やユーザーを含む自分たちのプロダクト領域に関する共有知識を持っているため、互いをカバーし合うのが最適ですが、UX のチームメイトは PM 固有の責任をカバーする帯域幅や専門知識を持っているとは限りません。あるいは、PM のマネージャーや同じステージの別の PM がカバレッジを支援する方が良い場合もあります。チームやマネージャーをまたいで必要な会話を持つよう計画してください。

休暇からの復帰

休暇からの復帰は、圧倒されたり気が引けたりすることがあります。あなたは DRI と協力して、不在中に何が変わったか、現在の優先事項が何かを理解すべきです。また、あなたが追いつこうとしているために返信が遅くなる可能性があることを透明性をもって伝えてください。休暇後の職場復帰の方法に関する追加のヒントもいくつかあります。

エンジニアリングとのプロダクトシャドーイング

Product Shadowing プログラムは、CEO Shadow プログラムを大まかに基にしており、ステージ内のプロダクトマネージャーとエンジニアの間のより深い理解を促進するように設計されています。このプログラムは Plan ステージで試験的に実施され、成功を収めました。

プロダクトマネージャーは、自分のステージ内のエンジニアをホストして、2 営業日にわたって、または役割のさまざまなファンクションでの経験を最大化するために複数日に分割した同等の時間にわたって、シャドーイングしてもらうことができます。

シャドーイングを提案するには、他のシャドーイング Issue を例として使用し、ステージの Issue トラッカーに Issue を作成してください（例）。

プロダクトリーダーシップ

別のページ Product Leadership では、プロダクトマネジメント組織で効果的なリーダーになる方法を扱っています。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License