書籍「アジャイルサムライ」で紹介されているインセプションデッキは顧客と開発者の境界を溶かすという意味で面白いツールだと思っている。PMBOKで定義されるプロジェクト憲章は、プロジェクトの全体像を明確化するという意味では重要だったけど、顧客と開発者、あるいは発注者と受注者の境界を明確にしすぎてしまうためプロジェクト成功の足枷になってしまう場合がある。
PMBOKで定義されているプロジェクト憲章の作成には長い時間がかかってしまいます。また、契約や調達に関する情報が多くなり、チームのメンバに見てもらえなかったり、読んでも理解が困難になる可能性もあります。そこで、コミュニケーションに重きを置くアジャイルプロジェクトにおいては、インセプションデッキを用いてプロジェクトに対する期待をマネジメントします。
http://blog.nextscape.net/index.php/research/agile/inceptiondeck
上記のページはインセプションデッキとプロジェクト憲章を労力の観点で比べているけれど、プロジェクトにおける顧客と開発者の立場・関係でどのツールを使うべきかを選べば良いと思う。
インセプションデッキとプロジェクト憲章の差
インセプションデッキのコンセプトは例えば書籍「アジャイルサムライ」ではこう紹介されている。
「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ」
アジャイルサムライ−達人開発者への道−
ポイントは、ここで言う「しかるべき人」には顧客もアナリストも開発者も含まれているということと、「同じ部屋に集める」という事だろう。
インセプションデッキを構成する質問も、顧客や開発者の立場を問わないようなものになっている(例えば「我われはなぜここにいるのか」)
これに対してプロジェクト憲章は、一種の契約として書くべきものとされている(PMBOK上では)。発注者 VS 受注者の関係を意識せざるをえない。ここが大きな差異だろう。
逆に言えば、インセプションデッキは「発注者 と 受注者」の関係を定義するツールとしては使えない。だから、インセプションデッキを活用する場合は別途、契約などの段階で責任範囲について合意しておく必要があると思う。
参考
- http://blog.nextscape.net/index.php/research/agile/inceptiondeck
- http://capsctrl.que.jp/kdmsnr/wiki/bliki/?CustomerAffinity
【追記】いろいろ誤字があったので修正しました。指摘いただいた皆さんThanks！
