Content last updated 2026-10-06

Plan:Work Items チーム

Plan:Work Items チーム

Plan:Work Items チームは、Plan ステージの GitLab の Work Items グループに取り組みます。 このグループは、FY27 の組織再編で Project Management から改名しました。

私たちの担当範囲

このグループは 3 つのカテゴリと、それらの基盤となるワークアイテムのフレームワーク(ウィジェット、およびワークアイテム用の GraphQL API と REST API)を担当します。

  • Team Planning:Issue、タスク、ラベル、マイルストーン、担当者、ウェイト、日付、ステータス、タイムトラッキング、ディスカッション、内部メモ、説明テンプレート、クイックアクション、ワークアイテムの種類と設定、およびマージリクエストとのリンク。計画と追跡のドキュメントを参照してください。
  • Service Desk:サービスデスクの Issue、カスタムメールとブランディング、および顧客関係管理(CRM)。Service Desk のドキュメントを参照してください。
  • Notifications:ウェブとメールの通知、および To-Do。通知のドキュメントを参照してください。

チームメンバー

NameRole
Alexandru CroitorAlexandru CroitorEngineering Manager, Plan:Spec-Driven Development and Plan:Work Items
Agnes SlotaAgnes SlotaBackend Engineer, Plan:Work Items
Senior Frontend EngineerSenior Frontend EngineerSenior Frontend Engineer, Plan:Work Items
Deepika GulianiDeepika GulianiSenior Frontend Engineer, Plan:Work Items
Mario CeliMario CeliSenior Backend Engineer, Plan:Work Items
Marc SaleikoMarc SaleikoStaff Fullstack Engineer, Plan:Work Items

固定の連携担当者

NameRole
Costel MaximCostel MaximSenior Security Engineer, Application Security, Plan (Project Management, Product Planning, Certify), Create:Source Code, Growth, Fulfillment:Purchase, Fulfillment:Provision, Fulfillment:Utilization, Systems:Gitaly
Gabe WeaverGabe WeaverSenior Product Manager, Plan:Spec-Driven Development, Plan:Work Items, Plan:Planning Views, and Plan:Portfolio Planning
Heinrich Lee YuHeinrich Lee YuPrincipal Engineer, Plan
Natalia TepluhinaNatalia TepluhinaPrincipal Engineer, Plan

Technical Writer は Brendan Lynch です。UX に関する質問は、Plan ステージの Product Design の窓口である Nick Brandt または Sunjung Parkに @ メンションしてください。

私たちの働き方

Plan ステージのページには、ステージとしての働き方が記載されています。

特にバックエンドチームでは、GitLab 標準の エンジニアリングワークフローを使用します。Plan:Work Items チームに連絡するには、 関連するプロジェクト (通常は GitLab)で Issue を作成し、~“group::work items” ラベルと その他の適切なラベルを追加してください。その後、上記に記載された該当する Product Manager または Engineering Manager にメンションしてください。

簡単な質問には、Slack の #g_work_itemsを使用してください。#s_planはステージ全体のチャンネルで、#s_plan_standupは非同期スタンドアップ用です。

エラーバジェット

エラーバジェットのダッシュボードには、グループの可用性目標に対する達成状況が表示されます。

Engineering Excellence ダッシュボード(社内向け、サインインが必要)には、Plan ステージのベロシティ、信頼性、正確性、セキュリティ、効率性が表示されます。

キャパシティ計画

工数の見積もり

今後の作業に関わる工数を見積もる際は、Plan ステージのほかのグループと同じ方法と数値尺度を使用します。

バグのウェイト付け

機能開発作業の詳細化と整理

固定の連携担当者との認識合わせを促し、進捗を可視化し、ビジョンを一連の MVCに分解するため、~workflow::planning breakdownの段階で Product および UX と協力して、~type::feature の成果物を次の構造に詳細化・整理します。

  • 機能(エピック)- 対応するフィーチャーフラグをデフォルトで「on」にするために必要な、機能を縦に分割したすべての単位を含みます。機能エピックは、対応するリリース投稿項目の MR を作成する場所としても機能します。機能エピックの範囲は、顧客価値を提供する最小限の機能に絞ってください。将来の拡張として予定している追加の範囲は、後続のエピックに記載してください。
    • スパイク(Issue)- 機能の実装に必要な工数を正確に見積もれない場合は、まずスパイクを実施します
    • UX(Issue)- 大規模な取り組みでは、UX が別の UX Issue を作成し、設計目標、設計の草案、設計に関する議論や批評、実装するものとして選ばれた設計方針の SSOT とします。UX Issue の詳細を参照してください。
    • 機能を縦に分割した単位(Issue)- 1 つのマイルストーン内で完了でき、本番環境の plan-stage グループ内でテストおよび検証できる機能の一部です。
      • エンジニアリングタスク(タスク - 任意)- 機能を縦に分割した単位を提供するために完了する必要がある、1 つ以上のエンジニアリングタスクです。タスクの範囲は通常、1 つの MR に対応するようにしてください。

~workflow::planning breakdown フェーズ中に、すべての Issue にウェイトを付ける必要があります。これにより、機能エピックを「適切なサイズに調整する」際に、Product および UX と効率的かつ効果的に協力できます。すべての Issue を、製品の特定領域で提案しているより広い改善内容を記した親エピックに関連付けることを推奨します。目指すのは、範囲をできる限り小さくし、イテレーションの余地を最大化し、提供に向けた全体の進捗を容易に追跡できるようにしながら、意味のある価値を提供し、顧客に過度な「変更疲れ」を与えないことです。

バックエンドとフロントエンドの連携

~“backend complete” ラベルの使用

~“backend complete” ラベルは、複数の専門領域(通常はバックエンドとフロントエンド)にまたがる Issue に追加して、 バックエンド部分が完了していることを示します。バックエンドの作業が 機能面で完了し、マージと検証が済んでいて、フロントエンドなどの作業が続いている場合に、このラベルを追加してください。

取り組む作業の選択

このマイルストーンの作業には、現在のマイルストーンのうち group::work items ラベルが付いた Issueを使用し、すべての作業を見るには全件の一覧を使用してください。~backend で絞り込むと、バックエンドエンジニア向けの Issue が表示されます。

解決できる自信がなければ、最上位の項目を選ばなくても 構いません。その場合は、#g_work_itemsに投稿してください。おそらく、 Issue の仕様をより明確にする必要があります。

重大度の高い Issue

スケジュールされていない Issue への取り組み

私たちは当事者意識という行動原則に従います。作業に最も近い人が、その作業について意思決定し、結果に責任を持ちます。また、私たち自身の活動量ではなく、顧客の成果で自分たちを評価します。 スケジュールされていない重要な作業を見つけたら、スケジュールへの追加を依頼するか、 自分で提案に取り組むことができます。自分にアサインし、#g_work_itemsで共有してください。