聞かれたから書いてみる
あくまで私の理解である。
キャンバスには詳しくないので間違いもあると思う
結論
どちらも重要
違い(追記した)
ビジネスマップキャンバスは開発チームの外の人に、主にネクタイを締めた人に、「何を作りどう稼ぐか」という憲章である
対してインセプションデッキは上記に加え、開発チームも含んだ憲章である
xxキャンバス
ビジネスマップキャンバスとかリーンキャンバスとかいわれるやつ
これはビジョンを明示するものである。
資金調達の際にエンジェルや銀行、VCに見せて、「こいつらに金を出す価値あるか？」を判断させるものである
また、ジョインする人間にこのチームはどこにむかっているか、どこで稼ぐかを明示し、同じ方向に走らせるためのもの。
「あーこいつらとは合わないわ」を事前に知るためのものでもある
インセプションデッキ
デッキは、「ビジョンを明示するもの」であると同時に「プロジェクトの憲章」でもある
憲章
結論
チームの体制、目的、開発の進め方などを示したチームの基本方針である
マネージャーや顧客側担当者の交代によって、チームの同意事項や成果、あるいは努力して作り上げてきた文化がちゃぶだい返しをくらわないために作る
前置きの世界史の話
中世、中国や西欧では重臣がそれぞれ派閥を形成していて、重臣が失脚するとその下についていた人間もまとめて首を切られる
粛清とか解官とか左遷とかそういう形で。
そうするとそういう人たちについていた人間も利権や財産の没収が行われたりする
Give and Takeで、見返り目当てにいろいろ尽くしてきたのに、リターンの部分だけ持ってかれたりする
お国のためにいろいろ頑張っても代替わりしたら全部没収されたらやる気にならない、そこでマグナカルタのような憲章が要求された
憲章を作りたかった目的
憲章の改正には国王といえどそう簡単にできない
国王や偉い大臣、大貴族の上に憲章をおくことで、「そう簡単に体制はかわらない」＝「今の努力の成果が途中で取り上げられたりしない」ことを保証しようとした
開発チームで憲章を作ることの意味
トップやマネージャーがかわるとプロジェクトの体制がガラッと変わってしまう。
それは避けたい
残された開発者が欲しかったもの - プロマネブログ http://getlife.hateblo.jp/entry/2015/03/30/031101
要は、
ドキュメント ・・・ 都度メンテナンス → ドキュメント不要。ソース見りゃいいでしょ。
テストコード ・・・ seleniumを使って自動でテスト → メンテが面倒。PrintScreenでエビデンスを貼り付けろ。
リファクタリング ・・・ 気にならなくてもこまめに改善。問題発生前に先手を打つ → 別に直さなくてもよし。困ったときに何とかすれば。
進捗管理 ・・・ マイルストンが守られれば細かい進捗はあまり気にしない。ガントチャートでの進捗管理は面倒だし不正確なことも多いので不要。 → excelのガントチャートで進捗度合い書け。定量で進捗率を出せ。毎日報告書を提出しろ。
などなどのような形で、今までの組織運営の考え方がガラリと変わったら。。。みたいなコトが心配ってわけですね。
ということを避けるためにもインセプションデッキは作りたい
上の例は開発チームに寄りすぎているが、実際にはよりプロダクトオーナー寄りになる。
私の感覚では、インセプションデッキは判断基準を定義することで、文化を定義しようとしているように見える
ビジョンを示すことを重要だが、それ以上に文化を定義することが重要なんだと思った。まる。