PnP（Project in Project）概念の導入

概要

会社の評価項目に「プロジェクト管理」という項目がありますが、実際にプロジェクトを管理する業務が少ないケースが多いです。一部のメンバーだけがプロジェクト管理を担当しており、他のメンバーもプロジェクト管理の観点で評価できる仕組みが必要になりました。

今回のブログポストでは、この課題を解決するためのPnP（Project in Project）概念と導入方法について紹介します。

PnPはProject in Projectの略で、現在進行中のプロジェクトのタスクを別のプロジェクトとして切り出して運用する概念です。

PnP - AgileのTheme、Epic、Story、Task構造

メインプロジェクト（Main Project）: チームが管理するサービスレベルのプロジェクトです。Agileではテーマ（Theme）レベルに当たります。
PnP: メインプロジェクトの中でプロジェクト化して管理できる大きなタスクです。Agileではエピック（Epic）レベルに当たります。

例えば、メインプロジェクトが「サービスA」であれば、PnPとして管理できるタスクは以下のようなものがあります。

このようにPnPを活用すれば、プロジェクトの中でさらにプロジェクトを作って運用することができます。

PnP概念を導入する理由は、メンバーの認識を合わせて、開発プロセスの一部として体系化するためです。PnPを通じて、より多くのメンバーがプロジェクト管理の経験を積むことができ、評価にも反映できる仕組みを作ることができます。

PnPを導入すると決めたら、チームレベルとPnP担当者として、以下のように進めることができます。

PnP専用の朝会や定例ミーティングを作る必要はなく、メインプロジェクトに載せる形で進めます。

サービスAにテスト（Unit、E2Eテスト）を導入するPnPの例です。

プロジェクト概要
1. サービスのバグを事前に発見してバグ発生率を減らす。
2. 追加開発によるリグレッションを減らす。
プロジェクト目標
1. UnitテストとE2Eテストの方針を決める。
2. UnitテストとE2Eテストを作成する。
範囲
1. 複雑なロジックを持つコンポーネントや関数に対してUnitテストを作成する。
2. ページ単位のテストケースを参考にしてE2Eテストを作成する。
3. GitHub Actionsでテストコードを実行する。
方針決定・検討事項
1. バグやリグレッションが発生した場合、必ずテストケースを書いてから修正する。
2. テストケースをベースにE2Eを作成する。
3. 複雑なコンポーネントや関数を選定して追加する。
4. 開発時に複雑だったり条件が多い場合、テストケースを作成する。
5. コードにコメントを入れる必要がある場合、その部分に関するテストケースを作成する。
スケジュール
1. 26ページ、6ヶ月（24週）＝1スプリント: 2〜3ページ
2. バグ・リグレッション発生時にテストコード作成
3. 複雑なコンポーネントや関数: 1スプリントあたり1〜2個