Content last updated 2026-02-06

GitLab を使った作業計画

私たちは GitLab を使って製品戦略をドキュメント化し、バックログを管理しています。このプロセスのカギとなるコンセプトは次のとおりです:

マイルストーン: 当社の製品リリースと整合し、グループの計画タイムボックスとして使用します。
Issue: 単一のマイルストーン内で提供できるユーザー価値の単位を捉えます。
タスク（オプション）: Issue を、より詳細な実装ステップに分解します。
エピック: 関連する Issue をテーマや目標にグループ化します。エピックを永続的なコンテナにするのではなく、具体的な作業範囲を表し、作業が完了したらエピックをクローズできることを目標とするのがベストプラクティスです。
ボード: 製品開発フローを進行する作業を可視化し、マイルストーン計画に役立ちます。
ロードマップ: エピックをタイムラインビューで可視化するのに役立ちます。

Issue

Issue を使って、狭くスコープを絞った作業項目を定義します。Issue はさまざまなトピックに焦点を当てることができます: UX 問題、実装要件、技術的負債、バグなど。エクスペリエンス関連の Issue の良いガイドラインは、1 つのユーザーストーリーのみを扱うことです。複数のユーザーストーリーを含む場合、それはおそらくエピックです。

Issue を作成するタイミング

次の場合に Issue を作成すべきです:

書こうとしている内容の Issue がまだ存在しない。まず検索してください
#product、#competition などのチャットチャンネルや他の場所で機能について言及されている
顧客が特定の機能を要求している

次の場合は Issue を 作成しない ことを検討すべきです:

実装よりはるかに先の作業を分解している場合。遠い将来の機能については、Issue の総数を最小化し、実装に近い時期にプランをイテレーションする柔軟性を維持するため、大まかな Issue またはエピックを作成してください。
既に存在する Issue がある場合。品質が低くても、誰かがリンクしているかもしれません。代わりに説明を書き直し、そうしたとコメントを残すことを検討してください。

新しい Issue を提出する方法

類似の Issue が既に存在するかどうか GitLab プロジェクトを検索します。避けられる場合は重複を作成すべきではありません。
すべての適切なデータ要素を捉えるために Issue テンプレートを使用します:
- Basic proposal 小さなタスクや、より大きな Issue を追跡するための技術的詳細用。
- Lean feature proposal 提案を行い、リリース投稿項目となりうるすべての機能拡張用。
- Feature proposal より多くの情報や詳細を必要とし、リリース投稿項目となる大規模な新機能用。
- Bug 望ましくないまたは不正な動作を報告するため。
次のことはしないでください:
- Issue に誰かを割り当てる
- マイルストーンを割り当てる
- 期限を設定する
- weight を追加する - weight は技術的な複雑さを表し、開発者によって定義されるべきです
作業タイプ分類のためのラベルを割り当てます。
コメントを残してプロダクトマネージャーにタグを付け、Issue をトリアージしてもらいます。 Issue コメントで誰かをメンションすると、メンションされた人が選択した通知メカニズムがトリガーされます。したがって、Issue が作成された後に他のチャンネル（Slack、メール）で人に通知する必要はありません。

機能 Issue

機能 Issue は、機能の実装をサポートするおよび／またはユーザーエクスペリエンスの改善をもたらす作業を識別します。

Issue が欠落している機能かバグかを検討する際は、ほとんどの場合に役立つ一般的なガイダンスとして MVC の定義と完了の定義を参照してください。
何かがそこにあると期待できるかどうか、または機能するかどうかについて疑問がある場合、それは欠落している機能です。
私たちは機能を提供するためにイテレーションを行うので、人々が期待する機能がないことがよくあります。このため、「人々がこの機能が合理的に期待できる」というだけではバグにはなりません。
コードがユーザー向けの更新につながるかどうかに関わらず、機能の構築の一部であれば、そのようにラベル付けすべきです。
パフォーマンス改善とユーザーインターフェースの改善はエンドユーザーのエクスペリエンスを改善するため、~"type::feature" とラベル付けすべきです。
REST と GraphQL の両方を含む API 追加も ~"type::feature" とラベル付けすべきです。
欠落している機能に人々が関心を持ち、解決策が明確な場合、その Issue は ~"Seeking community contributions" とマークすべきです。
欠落している機能が顧客によって報告された場合、その Issue は ~"customer" とマークすべきです。

バグ Issue

バグ Issue は、次のような望ましくないまたは不正な動作を報告します:

出荷されたコードの欠陥。
不正確な表示やデータ。
GitLab の一部がドキュメントや普遍的な期待に従って動作していない。
機能が意図せず壊れた、または本来の動作から変わった。これはリグレッションでもあります。
脆弱性であると判断されたセキュリティ Issue は、~"type::bug" と ~"bug::vulnerability" とラベル付けすべきです。
製品を意図どおりまたはドキュメントどおりに使用中のデータ損失。データの破損／損失は、バグを severity::1 として分類する基準の 1 つです。

エピック

同じ機能に関連する Issue は、エピックにまとめるべきです。

単一イテレーションのためのエピック

機能は、MVC だけをターゲットにしていても複数の Issue を含む場合があります。この場合、それらを 1 つの場所に集めるためにエピックを使うべきです。このエピックには開始日と終了日があり、3 つを超えるリリースにまたがるべきではありません。さもなければ、エピックが無期限に長引くリスクがあります。

これらの Issue が完成してクローズされたとき、エピックのゴールを成功裏に達成しているべきです。この種のエピックの良い例は、新機能の最初のイテレーションです。MVC を表すエピックは、タイトルの末尾に明確に MVC と記載し、カテゴリ戦略やメタエピックに対する親エピックの関係を持つべきです。

複数イテレーションのためのエピック

マルチレベルエピックは、完全な実装に複数のイテレーションを必要とする機能を追跡するために使用できます。これらのエピックは通常、特定の終了日を持ちません。継続的な開発領域を表すためです。ただし、明確なゴールと成功の定義は持つべきです。

複数イテレーションエピックの例には次のものがあります:

製品領域の長期的なビジョンを概説するカテゴリ戦略エピック
時間をかけて段階的に構築される大規模で複雑な機能のエピック

複数イテレーションエピックを作成する際は:

全体的なゴールと成功基準を明確に定義する
作業を小さく管理可能なイテレーションまたはフェーズに分解する
各イテレーションのために子エピックまたは Issue を作成する
作業の進捗と優先順位の変化に応じて、エピックを定期的に見直し、更新する

長期的なビジョンを持つことと、ユーザーフィードバックや変化する優先順位に基づいて適応する柔軟性を維持することのバランスをとることが重要です。複数イテレーションエピックを定期的に再評価し、製品戦略とユーザーニーズと整合していることを確認してください。

特定の日付に到達することは機能開発の終了基準として考えるべきではないため、時間枠のためのエピックの作成は避けるようにしています。代わりに、明確なユーザーエクスペリエンスの目標を念頭に置いた製品機能のためのエピックをスコープしてください。

より長期的な項目のためのメタエピック

Issue やエピックをテーマや長期項目に分類するには、ラベルの使用をお勧めします。特定のトピックに関連する多くの Issue を追跡するためにエピックを使用することもできます。出荷の特定のタイムラインがなくてもです。これらのエピックは ~meta としてマークすべきで、特定の開始日や終了日を持たず、単一イテレーションエピックを含むことがあります。このアプローチは、メタエピック内のエピックや Issue が作業分解構造を表すために再ペアレント化が必要になり、メタエピックの関係を失う可能性があるため、問題があることがあります。

作業項目の状態

Issue またはエピックがオープンであることは、その変更を実装する意図または検討中であることを示します。近い将来に実装を検討していない項目はクローズすることが重要です。それにより顧客や同僚との不確実性を作り出さないようにします。

Issue またはエピックをクローズするタイミング

ステークホルダーに何をするかを明確に伝えるために、ポジティブな見方（何をするか）だけでなく、ネガティブな見方（何をしないか）を明確にすることが重要です。これはステージとカテゴリ戦略で伝えるべきですが、作業項目（Issue、エピック、タスク）から始まります。機能要求やマージリクエストを拒否することは簡単ではありません。人々は自分のアイデアに非常に保護的になることがあります。彼らはそれらのアイデアを書くために多くの時間とエネルギーを投資しているかもしれません。アイデアを考えた人を傷つけないために、機能を受け入れたくなることがあります。さらに悪いことに、アイデアを厳しく拒否しすぎると、他の人々が貢献するのを思いとどまらせる可能性があり、これは私たちが避けるべきことです。

プロダクトマネージャーとして、次の理由で作業項目をクローズすべきです:

重複 Issue: GitLab には大きな Issue トラッカーがあり、同じ要求やバグの可能性のある他の Issue をユーザーが見つけるのが難しい場合があります。PM は重複 Issue をクローズするために定期的に Issue リストをトリアージし、ユーザーが探している Issue を見つけやすくし、PM が要求の需要を理解しやすくする必要があります。これらをクローズし、正規の Issue にリンクするために /duplicate クイックアクションを使用してください。
当社のビジョンの範囲外、または反対するもの。 GitLab は大きなプラットフォームであり、すべての要求が製品の長期的な方向性と整合するわけではありません。このビジョンと整合しないため、決して行わない Issue をクローズすることは問題ありません。ただし、カテゴリの方向性の一部として現時点で優先順位付けされていないというだけで Issue をクローズすべきではありません。
セキュリティリスクを提示している。 一部の要求では、その提案が GitLab または当社の顧客にセキュリティリスクを与えずに提供できるかを評価する必要があります。要求について不明な場合は、Application Security に連絡してください。
複雑すぎる: 複雑なことを行うシンプルでユーザーフレンドリーな製品を目指しており、その逆ではありません。過度に複雑な、または狭いユースケースのみを解決する製品の使用は、このカテゴリに該当する可能性があります。
別の設定は望まない: 可能な限り、設定を持たないようにします。GitLab は新しい提案を評価する際、設定より規約の原則に従います。追加の設定が加える可能性のあるユーザーエクスペリエンスへの影響をすべて考慮することが重要です。一部の設定は避けられませんが、ほとんどはそうではありません。
機能のティアを変更する: この問題は Stewardship ページですでに扱われています。
もはや関連しない: 機能が他の解決策を通じて既に提供された、またはバグが別の取り組みを通じて解決または排除された可能性のある Issue はクローズすべきです。
非推奨、削除、またはサポートされなくなった機能: その機能が正式に非推奨または削除された、またはサポート終了に達したため作業されない Issue はクローズすべきです。可能な限り作業項目をクローズすることはあなたの仕事の重要な一部であり、次に何をするかの明確なビューを保つのに役立ちます。

作業項目をクローズする際は、クローズする理由を説明するコメントを残し、関連するもの（他の重複、これがイテレーションされている元の機能など）にリンクしてください。機能要求／マージリクエストの提出にかけた時間と労力に対して作者に感謝することを忘れないでください。すべての場合で例外なく、ユーザーや顧客と対話するときは丁寧で礼儀正しくしてください。

Issue またはエピックをクローズすべきでないとき

低優先度: 時には機能は興味深いものですが、実装する余裕が単純にない場合があります。その場合は、単に真実を伝え、現時点でそれを行う十分なリソースが当社にないことを示してください。~low priority ラベルを使って低優先度を示します。
あなたの方向性の一部ではない: これらの項目は良いアイデアですが、グループ内で PM が優先順位付けすべきリストのトップにはありません。~low priority ラベルを使って低優先度を示します。
要求の需要が低い: あなたの方向性と一致しているが、非常に低優先度で、アップボートがない（または少ない）もの。クローズではなく、%“Awaiting further demand” マイルストーンを使用します。
divested カテゴリ: 投資撤退したがカテゴリを削除していないカテゴリの Issue。投資撤退による優先順位付けがないことを示すために ~divested ラベルを使用します。
Issue の年齢: 年齢だけを理由にクローズする。クローズの候補を探すために年齢でフィルタリングすることはよいですが、Issue が依然として製品の方向性と整合し、コミュニティの関心がある場合、将来の機会のためにオープンに保つべきです。
複雑なソリューション: 時々、Issue が過度に複雑な提案を伴うか、GitLab のアーキテクチャの現状や他の技術的要因により、ソリューションが実装するには複雑すぎる場合があります。これらの Issue は、解決すべき問題が有効である場合はオープンのままにすべきです。解決すべき問題について学ぶにつれてソリューションが進化する可能性があるためです。

ロードマップ

グループのロードマップは、タイムライン指向の長期的な取り組みを追跡するのに役立ちます（こちらが例）。これは作業を整理し、進捗を追跡し、依存関係を浮き彫りにするのに役立ちます。

ボード

計画プロセスの一環として、グループの優先順位付けされた Issue ボードを維持することが重要です。これらのボードは慣例的に STAGE - GROUP - Planning と呼ばれ、グループラベルを持つすべての Issue にフィルターし、各マイルストーンを列として構成します（こちらが例）。

マイルストーンの優先順位付けの DRI として、計画ボード上のすべての項目がマイルストーンにスケジュールされ、マイルストーン内およびマイルストーン間で優先順位付けされていることを確認する責任があります。これは、現在のマイルストーンの最も低い優先順位は、一般的に次のマイルストーンの最高優先順位になるという意味です。この点で、計画演習は近い将来の Issue の完全な優先順位付けです。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)

ページのソースコードを見る - ページの編集 - please contribute.