コンテンツにスキップ
pentaglyph

PEL ― Project Engagement Layer（バインダー）

PEL（Project Engagement Layer） は pentaglyph の 6 つめのスロット ですが、スロット 1-5 とは異なり 対等な標準ではありません。8 つの well-known クライアント engagement プリミティブを 1 か所にまとめる バインダー で、コンサル / アドバイザリ業務が技術 docs と並べてクライアント向け artefact を保てるようにします。

何を組み合わせるか8 つのクライアント engagement プリミティブ（下記）
なぜ標準ではなくバインダーかクライアント engagement 空間には単一の正本フレームワークがない ― 既存プリミティブを組み合わせる方が、6 つめの対等標準を発明するより誠実
キット内の hometemplate/docs/client-engagement/
pentaglyph 内のスロット#6（バインダー） ― 対等な標準ではない

PEL は何を解決するのか

Section titled “PEL は何を解決するのか”

コンサル / アドバイザリ業務はエンジニアリング docs に きれいに収まらない クライアント向け artefact を生む必要があります:

  • キックオフ用の inception deck
  • ステアリングコミッティ向け週次ステータス
  • 経営スポンサー向け 1 ページステータスレポート
  • RACI / DACI サインオフ向け決定ドキュメント
  • RAID ログ（Risks、Assumptions、Issues、Dependencies）
  • プレスリリーススタイルのプロダクト発表（Amazon 風 PR-FAQ）

これらの artefact は well-known な プリミティブ を持ち（それぞれに正本ソース）、しかし全てをカバーする単一の業界標準は存在しません。PEL は 新フレームを発明することなく、それらに共有ローカルディレクトリを与えます。

組み合わせる 8 プリミティブ

Section titled “組み合わせる 8 プリミティブ”
プリミティブ起源用途
Inception DeckJonathan Rasmusson, The Agile Samurai (2010)10 スライドのプロジェクトキックオフ
GitLab Handbook 週次更新GitLab Handbook公開の週次進捗 + ブロッカー
Atlassian 週次ステータスAtlassian Team Playbook内部チーム週次ステータステンプレ
Basecamp HeartbeatBasecamp / 37signals非同期マイルストーン更新
Amazon 6-pagerAmazon 内部慣行（Bezos 2004 メモ）決定会議向け 6 ページナラティブ（スライド置換）
Now-Next-Later roadmapProdPad / Janna Bastow日付なしのゴール駆動ロードマップ
DACI 決定ドキュメントAtlassian Team PlaybookDriver / Approver / Contributor / Informed ― グループ決定テンプレ
RAID logPMI / PRINCE2 practiceRisks / Assumptions / Issues / Dependencies トラッカー
PR-FAQAmazon working-backwards methodプロダクトを作る 前 に書くプレスリリース + FAQ

（表は 9 件 ―― PR-FAQ と 6-pager をまとめて数える場合もありますが、対象読者が異なるため pentaglyph は別プリミティブとして扱います）

pentaglyph での PEL の使い方

Section titled “pentaglyph での PEL の使い方”
template/docs/client-engagement/
├── inception-deck/
├── weekly-update/         ← GitLab + Atlassian + Basecamp variants
├── 6-pager/
├── pr-faq/
├── now-next-later/
├── daci/
└── raid/

各サブディレクトリにテンプレ + 1 ページ how-to が入り、プリミティブの 正本ソースへ link-out します。pentaglyph はプリミティブを再執筆せず、予測可能な置き場所だけを与えます。

なぜ「バインダー」で「6 つめの対等標準」ではないのか

Section titled “なぜ「バインダー」で「6 つめの対等標準」ではないのか”

スロット 1-5（arc42、C4、MADR、Diátaxis、TiSDD）は 3 つの性質を共有します:

  1. 単一の正本ソース（1 つの URL、1 メンテナ、1 canonical spec）
  2. 広い業界採用（数十の主要組織で利用）
  3. 10 年安定（10 年以上 breaking change なし）

クライアント engagement 空間には そのいずれもない。数十の部分的フレームワークが異なるベンダー（Atlassian / Basecamp / Amazon / GitLab）でメンテされ、慣行も数年おきにシフトします。「6 つめの対等標準」を発明することは、もろく opinionated なフレームワークを作ることになる ―― pentaglyph の設計哲学が避けるまさにそのもの。

バインダー はこれに正直: 「我々が使うプリミティブはこれら、置き場所はここ、各 upstream ソースが正本」

PEL を使うべきとき

Section titled “PEL を使うべきとき”
  • コンサル / アドバイザリ業務 ― クライアントキックオフ、週次更新、決定ドキュメント
  • 経営ステークホルダーのいる内部チーム ― Amazon 6-pager と PR-FAQ はエンジニアリング組織内でも有用
  • クロスファンクショナルなプロジェクト ― 決定追跡を共有する DACI と RAID

PEL を使う べきでない とき

Section titled “PEL を使う べきでない とき”
  • 外部ステークホルダーや経営報告のない純粋な内部エンジニアリングチーム
  • 単一開発者プロジェクト

正本リンク（プリミティブごと）

Section titled “正本リンク（プリミティブごと）”

関連

Section titled “関連”