プロフェッショナルサービス デリバリーメソドロジー

• プロフェッショナルサービス デリバリーメソドロジー (PSDM) とは
• GitLab でのプロジェクト管理
• プロジェクトベロシティとイテレーションスケジューリング
• ステータスプランニング
• ステータスとバーンダウンレポート
• RAID ボードによるリスクの軽減
• 社内レトロスペクティブガイドライン
• カスタマーレトロスペクティブガイドライン
• イテレーションベース PSDM のガイドライン

プロフェッショナルサービス デリバリーメソドロジー (PSDM) とは

プロフェッショナルサービス デリバリーメソドロジー (PSDM) は、GitLab 内のプログラムおよびプロジェクトデリバリーのためのガイディングフレームワークです。その目的は、PS デリバリーチームがカスタマーサクセスを優先しながら、プロジェクトスコープに対して予測可能なタイムフレーム内で運営できるようにすることです。これは以下によって実現されます:

• GitLab.com を Single Source of Truth (SSOT) として使用
• 進捗の管理とレポートのためのラベルガイドラインに従う
• リスクの特定と軽減
• 内部での改善のアクション/追跡
• スプリント/イテレーションベースの SOW に対するイテレーションの実装
• イネーブルメント資料の活用
• 基本的なアジャイルベストプラクティスの適用

GitLab でのプロジェクト管理

GitLab はすべてのプロフェッショナルサービスエンゲージメントにおいて、プロジェクト管理プラットフォームとコラボレーションプラットフォームの両方の役割を果たします。私たちはプロジェクト管理に GitLab の以下の機能/用語を活用しています:

GitLab を操作する際は GitLab ベストプラクティス を参照してください。

GitLab をプロジェクト管理ツールとして初期設定するには、設定ガイド を参照してください。

注意: “internal” としてマークされた Issue でも、GitLab Collaboration プロジェクトに “developer” アクセス権を持つ人は誰でも閲覧できます。これには GitLab 外部の人も含まれます。機密のコミュニケーションには Project の “Internal Epic” を使用することを推奨します。

GitLab でのプロジェクト管理マッピング

アジャイル用語の GitLab へのマッピングについて、より明確な情報は このガイド を参照してください。

ラベルガイドライン

ラベルは、プロジェクトに関するレポートを生成し、プロジェクトチームのニーズに応じて情報を整理するための最も効果的な方法です。チームには特定のプロジェクトレポート要件を満たすラベルを作成する柔軟性がありますが、内部使用のためのラベル生成については確立されたガイドラインがあります。

私たちの CP (Customer Project) 自動化 には、以下のデフォルトラベルが含まれています:

• SOW-# または PO# - GitLab チームがプロフェッショナルサービスグループ内のプロジェクトを検索するのに役立ちます
• PM 名 - GitLab チームが PM 名でソートするのに役立ちます
• PSD ワークフロー（Issue ボード管理用）

社内レトロスペクティブと RAID 追跡/レポート に使用されるラベルは、以下の「イテレーション全体を通したレポート」セクションにあります。

プロジェクトベロシティとイテレーションスケジューリング

イテレーションスケジュールとケイデンス は Iteration 0 で初めて導入され、GitLab カスタマープロジェクト（グループ）内のエンゲージメントチャーターの一部となります。カスタマーキックオフのアウトプットとして顧客がイテレーションスケジュールに同意することが極めて重要です。ただし、これは初期にステークホルダープランニングミーティング中に顧客と協力して開発するべきものです。

イテレーション/スプリントスケジュール内で作業する場合、5 つの主要なコンポーネントがあります:

1. イテレーションプランニング - イテレーションのゴールを設定し作業項目を選択
2. デイリースタンドアップ - 進捗を共有しブロッカーを特定するための簡潔な同期ミーティング
3. バックログリファインメント - 今後の作業を明確化、見積もり、優先順位付け
4. イテレーションレビュー - 完了した作業のデモンストレーションとフィードバック収集
5. レトロスペクティブ - プロセスを振り返り、改善点を特定

イテレーション内で作業しない場合でも、一貫したリソースアラインメントを確保するためにプロジェクトのベロシティを明確に伝えることが重要です。例えば: 「FedRAMP 準拠のため、1000 ユーザーと 2000 プロジェクトを GitLab SaaS から Self-Managed への成功裏なアップグレードとシームレスな移行を実行するために、5 週間にわたり週 40 時間の作業を予定しています。」これはステークホルダープランニングミーティングとカスタマーキックオフ中に検証されます。

ステータスプランニング

アジャイル SOW の場合、プログラムマネージャー / プロジェクトマネージャーは、ビジョン、製品ロードマップ、リリースゴール、イテレーション目標を含むプロジェクトの戦略的方向性を提供します。プログラムマネージャー / プロジェクトマネージャーは、必要に応じてアイテムを挿入、再優先順位付け、リファイン、削除することにより、製品バックログを管理する責任があります。これは、イテレーションスコープが定義され開発チームによってコミットされるまで、いつでも発生する可能性があります。

見積もり、バックロググルーミング、イテレーションプランニングの準備に関するガイダンスについては、バックログマネジメント を参照してください。

作業範囲が SOW でより厳密に定義されている場合、PM はあらゆる変更の影響を評価し、顧客と協力して再優先順位付けまたは変更指示プロセスの開始のいずれかを行うことが期待されます。

ステータスとバーンダウンレポート

誰が何を更新するか?

PM はセレモニーの準備、ステータス報告、Issue 管理を担当しますが、GitLab PSE（プロフェッショナルサービスエンジニア）、TA（テクニカルアーキテクト）、および顧客チームメンバーはすべて、プロジェクトボード内で割り当てられた Issue（タスク）に貢献し更新することが期待されます。これは Iteration 0 中に効果的なワーキングアグリーメントを確立することの重要性を強調しています。

非同期かつリモートで作業することは、独自の課題を提示します。Directly Responsible Individual (DRI) が割り当てられた Issue に積極的に貢献することは、プロジェクトのベロシティを維持するために不可欠です。このアプローチにより、PM は技術チームを混乱から守りつつ、効果的なステータスのロールアップを可能にします。

すべてのプロジェクトがスプリントやイテレーションのケイデンスに従うわけではありません。しかし、ステータス更新は GitLab 内に文書化され、毎週顧客に報告されるべきです。エンゲージメントチャーターを使用して、ステークホルダーを毎週のステータス更新、RAID ログ、その他の関連プロジェクトドキュメントに誘導することを推奨します。

ステータスレポートの例:

• エンゲージメントチャーターの例
• ステータス更新の例 1
• ステータス更新の例 2
• GitLab CP がステータス報告に推奨されるプラットフォームですが、顧客がプレゼンテーション形式を希望する場合は、こちらの テンプレート を参照してください。

プロジェクトバーンダウン

Kantata は財務管理の Single Source of Truth ですが、プロジェクトの進捗に対する追加の監査と進行状況のために、PM は時間と財務のバーンを別途追跡することを推奨します。テンプレートは こちら にあります。週次ステータスレポート内で時間/財務の進捗を追跡することは必須です。

RAID ボードによるリスクの軽減

RAID（Risks、Actions、Issues、Decisions）フレームワークは、プロジェクトのリスクの特定、管理、解決のための Single Source of Truth として機能します。これは以下の主要なメリットを提供します:

• プロジェクトステークホルダーとリーダーシップに対する透明性を作り出す
• Yellow/Red ヘルスステータスを持つプロジェクトのプロアクティブな監視を可能にする
• リスク文書化と緩和戦略を一元化する

RAID のセットアップ

• RAID ボードは PM が CP テンプレートを初期化するときに自動的に作成されます
• テンプレートを「RAID - [Customer Name] - [SOW/PO#]」にリネームします
• PM は RAID の作成と管理を担当しますが、課題と緩和策が変化するにつれ、社内チームメンバーと顧客代表者の両方が更新することが推奨されます
• RAID ログの例 を参照してください

RAID 経由でのリスクのレポート

リスクを文書化する際は、以下のガイドラインに従ってください:

1. 適切なラベルを適用:

   • “PS RAID Log”
   • “PS Risk”
   • “PSD Workflow::Not Started”

2. 優先度ラベルを使用して深刻度を定義:

   • “PS:: Priority High”
   • “PS:: Priority Medium”
   • “PS:: Priority Low”

3. 以下の観点で影響を定量化:

   • スケジュールへの影響
   • スコープの変更
   • 品質への影響
   • 予算への影響

4. オーナーシップを割り当て:

   • リスクの受け入れ、緩和、または解決の責任者を指定

5. 緩和計画の詳細化:

   • リスクを軽減または排除するための具体的なアクションを文書化

6. エスカレーションプロセス:

   • プロジェクトの進捗に影響を与える緊急対応が必要なリスクには “Escalated” ラベルを使用
   • エスカレートされた項目はプロフェッショナルサービスポートフォリオレポートに表面化されるべきです

社内レトロスペクティブガイドライン

社内レトロスペクティブ Issue は、プロジェクトライフサイクル全体を通じた継続的な振り返りメカニズムとして機能し、以下に焦点を当てます:

• チームの成果と称賛のキャプチャ
• 技術的課題と解決策の文書化
• プロセス改善の特定
• ビジネス開発機会の記録
• 将来のエンゲージメントのための組織知識の構築

プロジェクトのマイルストーンで発生し顧客とレビューされるカスタマーレトロスペクティブとは異なり、社内レトロスペクティブは、プロセスを改善するために必要な改善点をキャプチャし、チームの勝利を祝う方法として機能します。

社内レトロスペクティブのセットアップ

社内レトロスペクティブは、カスタマー EPIC が確立されたときに自動的に作成されます:

1. 場所:

   • Issue は社内のカスタマー EPIC 内にあります
   • 簡単にアクセスできるよう、社内プロジェクト Slack チャンネルにリンクされるべきです

2. テンプレート:

   • 標準化を確実にするために 最新テンプレート を使用
   • PM はテンプレートにプロジェクト情報が適切に入力されていることを確認する必要があります

3. アクセス:

   • これは社内専用 Issue です - 顧客アクセスは付与されるべきではありません
   • プロジェクトに従事するすべての GitLab チームメンバーがアクセス権を持つべきです

社内レトロスペクティブへの貢献

チームメンバーはプロジェクト全体を通じて社内レトロスペクティブに貢献するべきです:

何を文書化するか

1. プロジェクトの勝利と称賛:

   • 技術的成果
   • 顧客からの称賛とポジティブなフィードバック
   • チームコラボレーションの成功
   • 革新的なソリューション

2. 学んだ教訓:

   • 技術的課題とその克服方法
   • プロセスのギャップと回避策
   • コミュニケーションの改善
   • 効果的だったツールとテクニック

3. 改善の機会:

   • プロセスを合理化できる領域
   • ドキュメントのギャップ
   • 特定されたトレーニングニーズ
   • ツールの制限

4. 作成された資産:

   • スクリプトとコードスニペット
   • ドキュメントテンプレート
   • 構成ガイドライン
   • 再利用可能性のある顧客固有のソリューション
   • デリバリーキット関連の更新

貢献方法

• 継続的に: チームメンバーは注目すべきイベントが発生するたびに Issue にコメントを追加するべきです
• 週次チェック: PM は週次チームミーティング中に更新を促すべきです
• フェーズ移行時: 各プロジェクトフェーズの終わりに学習をキャプチャすることに特に注意するべきです

社内レトロスペクティブの最終化

プロジェクト完了時、PM は以下を行うべきです:

1. 最終セッションを実施:

   • PS Practice チームメンバーを招待し、30〜60 分の GitLab チームレトロスペクティブコールをスケジュール
   • 貢献をレビューし、主要な学習を統合
   • パターンと主要な持ち帰りを特定

2. 学習を分類:

   • 将来の検索を容易にするため、適切なラベルを適用:

3. フォローアップ Issue を作成:

   • アクションアイテムに対する具体的な Issue を生成
   • 実装のオーナーを割り当てる
   • 完了のための現実的なタイムラインを設定

社内レトロスペクティブの例は こちら] にあります。実施中および完了した社内レトロのリストは、「PS-Plan」GitLab プロジェクト内で「Titles」と「Internal Retro」というテキストを検索することで見つけることができます。

ナレッジ共有

PS リーダーシップは定期的にレトロスペクティブデータをレビューし以下を行います:

• プロジェクト全体の共通課題を特定
• 卓越したチームパフォーマンスを認識
• トレーニングとイネーブルメントの優先事項に情報提供
• デリバリーキットとメソドロジーの更新
• 将来のサービスオファリングの形成

ベストプラクティス

• エントリーは客観的で解決策志向に保つ
• 一般化ではなく具体的な例を含める
• ポジティブな観察と改善の機会のバランスを保つ
• 個人ではなくシステムとプロセスに焦点を当てる
• 可能な限り影響を定量化する（節約された時間、回避された問題など）
• 具体的で実行可能な改善を提案する

カスタマーレトロスペクティブガイドライン

カスタマーレトロスペクティブは、プロフェッショナルサービス デリバリーメソドロジーの重要な構成要素であり、お客様と一緒にエンゲージメントに関する構造化されたフィードバックを提供します。これは以下の役割を果たします:

• エンゲージメントに対する顧客の視点をキャプチャ
• うまくいったこと、改善が必要な領域を特定
• 将来の参考のために成功と課題を文書化
• 協調的な振り返りを通じて顧客との関係を強化
• 将来のエンゲージメントに情報を提供できる洞察を生成
• CSAT 参加を促進

カスタマーレトロスペクティブのセットアップ

カスタマーレトロスペクティブ Issue は、コラボレーションプロジェクトをセットアップする際に自動的に作成されます:

1. 初期セットアップ:

   • プロジェクト CPR をセットアップする際にテンプレートを「[Customer Name], [SOW/PO#]」にリネーム
   • Issue は GitLab および顧客チームの両方がエンゲージメント全体を通じて貢献できるリビングドキュメントとして機能します

2. 継続的な文書化:

   • 社内レトロスペクティブと同様に、エンゲージメント全体を通じて顧客にフィードバックを文書化することを促す
   • 定期的な更新は、新鮮で関連性のある間に洞察をキャプチャするのに役立ちます

カスタマーレトロスペクティブの実施

準備

1. セッションをスケジュール:

   • PS エンゲージメントの終わりに顧客とのクロージャー/レトロスペクティブミーティングを計画
   • チームメンバーがセッション前に事前入力できるよう、ミーティングアジェンダにレトロスペクティブ Issue を共有

2. 参加を促進:

   • 各メインセクションの下のフィードバックの前にイニシャルを追加するよう、チームメンバーに依頼
   • 既存のフィードバックに同意する場合、元の貢献者と共にイニシャルを追加するべきです

セッション中

レトロスペクティブミーティングは、Issue テンプレートに含まれる以下の主要セクションをカバーするべきです:

1. 出席者と日付
2. 提供されたサービスと価値の概要
3. 最終バーンダウンレポート
4. レトロスペクティブディスカッション
   • うまくいったこと
   • 改善できること
   • 学んだ教訓
5. PS プロセスまたはメソドロジーに関するフィードバック
6. 顧客の声

文書化とフォローアップ

レトロスペクティブセッション後:

1. ドキュメントを最終化
2. 適切なラベルを適用
3. アクションアイテムを作成
4. #ps-internal 内で洞察を共有

カスタマーレトロスペクティブのベストプラクティス

• トーンを協調的かつ建設的に保つ
• 具体的で実行可能なフィードバックに焦点を当てる
• 課題の議論と成果の称賛のバランスを取る
• 技術的および プロセス関連の洞察の両方をキャプチャ
• 顧客の声を目立たせる
• 引用と推薦を文書化（適切な許可付き）
• レトロスペクティブを使って顧客との関係を強化する

追加リソース

• レトロスペクティブファシリテーション Issue/ガイド
• カスタマーサーベイテンプレート

イテレーションベース PSDM のガイドライン

完全なイテレーションスケジュールを伴う完全な PSDM 実装は、アジャイル特化型 SOW が以下の場合にのみ必要です

• 5 イテレーションを超える、または
• エンゲージメントが 2 ヶ月を超えると計画されている

「大規模」な顧客エンゲージメントを構成するものを理解するには、アーキタイプ定義 をレビューしてください。

Iteration 0 を計画する際に以下のガイドを使用してください:

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