Content last updated 2025-10-14

プロダクト開発の役割と責任

プロダクト開発プロセスにおける、プロダクトおよびエンジニアリングチーム間の役割と責任の概要。

プロダクト開発を成功させるためには、チームメンバー全員が共有のアウトカムにコミットすることが必要不可欠です。チーム全体で、GitLab のバリューである Results for Customers と一致した形で、ユーザーへのポジティブなインパクトを届ける責任を共有しなければなりません。

チーム全員の取り組み

役割と責任の概要

高品質なプロダクトを届けるための責任

Roles Leads

品質はみんなの責任

Responsibilities of Leads

役割 vs. 責任

役割(プロダクトマネージャー、エンジニアリングマネージャーなど)と、Lead としての責任領域(プロダクト、テクニカル、デリバリー、リソース、UX など)は、明確に区別する必要があります。「プロダクトマネージャー」や「エンジニアリングマネージャー」のような役割は、特定のリーダーシップ責任と整合することが多いですが、その責任領域はその役割に専属するものではありません。

  • 例:「プロダクトマネージャー」の役割を担うチームメンバーは、Product Lead としての責任を果たすことが多いですが、Product Lead の領域を超えた重要な貢献を行います。プロダクトが社内で使用され、エンドカスタマーと直接対面しない状況では、Product Lead の役割をテクニカル個人貢献者(IC)またはエンジニアリングマネージャーが担うこともあります。
  • 例:「エンジニアリングマネージャー」の役割を持つチームメンバーは、複数の責任を同時にカバーすることが多く、エンジニアリングマネージャーは、特定チームのニーズに応じて Technical Lead、Delivery Lead、Resource Lead の役割の一部またはすべてを果たすこともあります。

上記の注意点を踏まえつつ、GitLab のプロダクト開発において一般的に見られるパターンは次のとおりです:

  • Product 部門は通常、以下の責任をカバーします:
    • Product Lead - 注:例外もあります(特にインフラ領域など)。
    • UX Lead
    • Documentation Lead
  • Engineering 部門は通常、以下の責任をカバーします:
    • Technical Lead
    • Delivery Lead
    • Resource Lead

GitLab のプロダクト開発チームでは、「チームとして勝利し、チームとして敗北する」ことを信条としています。勝利はチームの勝利であり、敗北もチームの敗北です。チーム全体がアウトカムをオーナーシップを持って担い、チームの一部に割り当てられた責任は、実行の卓越性を推進するためのものであり、厳格な境界を設けるためのものではありません。1 人の個人がチームを代表して複数の責任領域をカバーすることもあります:

  • 例:Technical Lead が Delivery Lead を兼任する
  • 例:Delivery Lead がチームの Resource Lead も兼任する
  • 例:Technical Lead が、技術的な卓越性、信頼性、スケーラビリティ、または持続可能性の取り組みのために、Product Lead と Documentation Lead を兼任する

最後に、特定の責任について、プロダクト開発チームが必要とする内容は、プロジェクトの種類、プロジェクトの成熟度、技術領域および Tech Stack の成熟度、開発者の成熟度などによって異なる場合があります。重要なのは、プロダクト開発チームごとに、これらの責任のオーナーシップとアカウンタビリティについて、チームメンバー間および役割間でどのように分散されているかに関係なく、合意とインターロックがあることを確認することです。

Who、What、Why、How、When

プロダクト開発では、「who(誰が)」「what(何を)」「why(なぜ)」「how(どのように)」「when(いつ)」という汎用的な質問手法を活用し、チームが目指すアウトカムを深く理解できるようにしています。私たちはそれぞれ、世界クラスのプロダクトをカスタマーに届けるという目標を達成するために、これらの質問に継続的に答える役割を担っています。下の図では、プロダクト開発チームのメンバーが新しいプロダクト機能を形作る際に、どのように貢献し協働するかを、例を用いて説明しています:

プロダクト開発の役割と責任における who, what, why, how, when

私たちの目的は、各チームがアジャイル手法を活用してプロダクトのカスタマーバリューを開発・提供する自由を維持しつつ、同期型の計画プロセスを導入することで、GitLab のカスタマーが当然期待する予測可能性と品質をもってデリバリーすることです。

主要イベントとアクティビティの責任へのマッピング

作業の階層

  • 方向性 (Direction)
    • 大規模イニシアチブ (Big Initiative)
      • トップレベルエピック (Top-level Epic)
        • 能力 (Capability)
          • 複合的成果物 (Composite Deliverables)
            • 原子的成果物 (Atomic Deliverables)

凡例

  • ✅: 主導
  • ✔️: 関与
#主要イベントとアクティビティプロダクトマネジメント LeadTechnical LeadDelivery LeadResource Allocation LeadProduct Design LeadTechnical Writing Lead
1担当領域における 1 年間の方向性を定義し、(1) 会社の 3 年戦略、(2) リーダー(CPO/CTO)の方向性、(3) 現在の会社の目標、(4) カスタマーニーズと整合させる
プロダクト中心

テクニカル中心

ユーザー中心
2方向性を、担当領域の成熟度を高める大規模イニシアチブに分解する
プロダクト中心

テクニカル中心
✔️
ユーザー中心
3大規模イニシアチブを、向こう X 日間(X は 90 日、180 日など)の計画・洗練・スコープ設定が可能なトップレベルエピックに分解する
プロダクト中心
✔️
テクニカル中心

テクニカル中心
✔️
4品質とユーザー体験に焦点を当てつつ、トップレベルエピックの目標を達成するために、トップレベルエピックを能力に分解する
プロダクト中心
✔️
テクニカル中心

テクニカル中心
✔️
ユーザー中心 ✔️

ドキュメント中心
5トップレベルエピックに基づいて、能力のバックログを最新に保つように優先順位付けする
プロダクト中心
✔️
テクニカル中心

テクニカル中心
✔️✔️✔️
6能力を、開発者チームに割り当て可能な複合的成果物に分解する✔️✔️✔️
7マイルストーンの計画に向けて、複合的成果物のバックログを最新に保つように優先順位付けする✔️✔️✔️
8マイルストーンに対してコミットする成果物についてインターロックする
9計画に基づいて更新された R&D ロードマップについてインターロックする
10複合的成果物を、開発者に割り当て可能なフロントエンド、バックエンド、インフラストラクチャなどの原子的成果物に分解する✔️
ドキュメント中心
11マイルストーンの計画に向けて、原子的成果物のバックログを最新に保つように優先順位付けする✔️
12原子的成果物を開発者に割り当てる✔️
13マイルストーン期間中の原子的成果物の進捗を追跡し、主要ステークホルダーに報告する
14技術的な作業と品質レベルが受け入れ基準および Definition of Done を満たしていることを検証する✔️
15マイルストーンの終了時にステータスを報告し、次のマイルストーンの計画を整合させる手助けをする
16複合的成果物の達成の一部として、能力の達成の一部として、そしてトップレベルエピックの達成の一部として、原子的成果物のステータスを報告する
17最新のマイルストーン結果に基づいて、方向性とイニシアチブに対する進捗を更新する
プロダクト中心

テクニカル中心
18実績に基づいて更新された R&D ロードマップについてインターロックする
19PMM および DevRel と連携し、メッセージングが正しく最新であることを確認し、必要に応じて GTM 資料の作成をサポートする
プロダクト中心
✔️
20セールスの機会をサポートするため、または既存カスタマーへの最新情報として、プロダクトの一部および関連するロードマップをカスタマーに提示する