憲章

開発の目的に賛成していても、使える予算や決定権まで合意できているとは限りません。
憲章（Charter）は、取り組みの目的、範囲、責任、権限などを定める文書です。
プロジェクトの文脈では、誰が仕事の開始を認め、責任者がどの資源を使えるかを明確にする役割があります。
PMIの解説も、プロジェクト憲章で権限を明確にする点を重視しています。

仕事の開始条件をそろえる

たとえば、営業部門と開発部門が共同で見積もりサービスを作るとします。
営業は全商品への対応を期待し、開発は一商品だけの試行だと考えていれば、開始後に範囲が食い違います。
最初の憲章には、対象商品、試す顧客、達成したい結果、予算の上限、判断の期限を記します。
「見積もりを自動化する」という目的だけでは、どこまで引き受けたかが定まりません。

責任者については、名前を置くだけでなく、決められることを示します。
調査先を選ぶ、試行の仕様を変える、外部費用を使うといった判断を、どの範囲まで任せるかを確認します。
追加予算や対象商品の変更はスポンサーへ戻すなど、判断の境界も記録します。
これにより、担当者が毎回承認を求める箇所と、自律して動ける箇所が分かれます。

詳細計画と分ける

憲章は、日々の作業をすべて列挙するための文書ではありません。
調査で顧客の条件がわかれば、具体的な作業や順序は変わります。
変えたくない目的と制約を憲章に置き、実行方法は計画やバックログで調整すると、更新の負担を抑えられます。
ただし、目的そのものが不適切だとわかった場合は、憲章の合意も見直します。

先ほどの例で、顧客が見積もり時間より承認待ちに困っていると判明したら、自動計算を続けるかをスポンサーと再検討します。
範囲を変更するなら、その理由、増える費用、失われる当初の成果を示します。
担当者の裁量で別の製品へ変えてから事後承認を求めると、当初の権限との関係が曖昧になります。

形式より合意を残す

分厚い書式を埋めても、スポンサーが内容を理解していなければ判断には使えません。
一枚でも、目的と権限を必要な人が確認し、参照できる状態にすることに意味があります。
開始時の版を残し、主要な変更の際に更新すると、当初からの約束と後で変えた条件を追えます。
憲章があっても、見込みの悪くなった仕事を続ける理由にはなりません。

新製品の探索領域を定める製品イノベーション憲章とは、何を承認する文書かを区別して使います。

参考資料