プロジェクトのライフサイクルと、プロジェクトエディターの役割

2018年に『予定通り進まないプロジェクトの進め方』でプロジェクトの設計図の道具として『プ譜』を世に出したのと同時に、プ譜を使ってプロジェクトを進める「プロジェクトエディター（以下、PE）」という役割を名乗ってきました。

上記の記事を書いたのが2019年で間もなく5年が経とうとしています。その間に経験したことを整理し、あらためてPEとプ譜の役割を記述しておこうと思いました。

PEは、すべてのステークホルダのニーズに合致するプロジェクトの進め方を設計および文書化して導く役割を担います。この設計のための道具と文書がプ譜です。
この役割には、4つの局面があります。

1. プロジェクトの関係者（ステークホルダ）を特定してプ譜づくりに参加させること

2. 関係者の関心事を理解してとらえること

3. それらの関心事に対応するプ譜を作成して、その所有者となること

4. プ譜に書いたプロジェクトの設計情報を、物理的な製品やシステムに“転写”するにあたり、状況に合わせてプ譜を修正・更新すること

PEとしての1つの責務は、プロジェクトの仮説・計画段階において、製品やシステムを構成する主な要素とその関係性を俯瞰し、構成要素をプロジェクトにとって望ましい状態にするための施策との因果関係に飛躍がないかを把握することです。 それが、次の詳細設計や探索・実行段階におけるや形成評価（ふりかえり）に用いられます。

探索・実行段階では、最初に立てた仮説としてのプ譜が、実際の状況に適するように修正・更新していく必要があります。

プロジェクトの進行に伴って、プ譜が更新されていく例。プ譜とプ譜の間に関連資料を挟むことで、プロジェクトポートフォリオを作成していく。

つまりPEはプロジェクトの開始段階に深く関わるだけでは終わりません。
プ譜というプロジェクトの設計図はあくまでも想像の産物であり、実在するのは現場のモノでありコトです。建築家や設計士が設計図を書いた後も建築現場に足を運んで、自分の書いた図面通りに現場に再現できているのかを確認し、設計図が現状に適していなければ修正・変更を加えなければならないのです。

プロジェクトのライフサイクル中でのPEの関与は、 通常、 下図のようになります。

仮説・計画段階ではプロジェクトの構成要素、要素をあるべき状態にするための施策の洗い出しと因果関係の確認、要素間の関係性に注意を払うことにかかりきりになります。また、関係者と成功の定義（勝利条件）をはじめスコープに合意することにも力を注ぎます。
具体的な施策の実行や実装作業の局面では、PEの関与は少なくなりますが、この期間、PEはふりかえりのファシリテーターとプ譜の修正と更新を行う役割を担います。

上記はあくまでPEを一人の人物が担う場合です。Saasベンダーでは営業が商談の現場で書いたプ譜を、受注後にカスタマーサクセスが引き継いで、顧客のプロジェクト進行を支援するという、PEの役割を分担する体制も存在します。みなさんのプロジェクトの実情に合わせ、PEという役割とプ譜を活用していただければ幸いです。

※余談だが
PEってPMOみたいですねとよく言われます。プ譜という設計図であり議事録にもなる文書の管理・更新をするのがPMOのようだということです。そのような役割もありつつ、PEは上述したようにファシリテーター役を務めることもありますし、スクラムマスターのようにふるまうこともあります。「PEはこうじゃなきゃいけない」というこだわりはそんなになくて、文字通り現場に合わせて「編集」してもらえばいいと思っています。