サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

チームビルディング 旧館より

「インセプションデッキ」ワークショップをやってみました

投稿日:2011年11月23日 更新日:


先日、社内で「インセプチョンデッキ」のワークショップをやってみました。
社内SNSでの募集期間が1週間も無かったのですが、10人強の方が参加してくれました。参加者の皆様、ありがとうございました。

インセプションデッキとは?

詳しくは「アジャイルサムライ」や色々なブログで紹介されていますので、そちらを。

ワークショップの内容

定時後に約2時間で行いました。

インセプションデッキの説明を行った後、提示する架空のシステムについてグループワークを行いました。
グループは3つに別れ、「やならないことはなにか?」と「トレードオフスライダー」を話し合って、発表してもらいました。

休憩を挟んで個人ワークです。
それぞれの(今or過去の)プロジェクトのインセプションデッキを作ってもらうことにしました。
主に「パッケージデザイン」と「エレベータピッチ」を作って発表してもらいました。

これは社内ということもあり、包み隠さず良い感じの発表が続いたように思いました。
この辺は(部門は違えど)コンテキストが共有できている部分もある点かな?と感じました。

自分なりに考えたインセプションデッキの気づき

何度か作ってみたり、今回のワークショップにあたって思ったことです。
読み返してみるとこちらのエントリで書いたこととほぼ同じだったのですが…

ウォータフォール開発でも使える

「インセプションデッキ」は「アジャイル開発」の文脈で語られる/使われることが多いと思います。
しかし、アジャイルな開発以外でも、十分適用できるものだと思っています。
例えば、弊社でも「プロジェクト計画書」「プロジェクト憲章」を作りますが、それとインセプションデッキは(表現の仕方は違いますが)同じようなことを伝えてようとしていると感じるためです。

意外と(自分もチームも)分かっていない

実際に(自分の取り組んでいるPJについて)作ろうと、いくつかの質問に取りかかると「あれ?これってどうなんだろう??」と思うことがあります。
特に途中参加したり、大きなPJだったりすると余計に顕著かもしれません。
チーム全員が同じような答えになるかと言うとそうでもなく、(エレベータピッチなどを書くと)少しずつ違った形になったりして、それぞれの想いが見えてきます。

10個もできないよ!!

インセプションデッキは10個の質問で構成されています。
「全て」をチーム「全員」でやろうとするとやはり時間がかかります。
そのような場合、2、3つを選んでやっても良いと思っています。
もちろん全てを関係者全員で出来るのが理想ですが。

今のところのオススメだと思うのは…
・エレベータピッチを作る
・何を諦めるのかはっきりさせる(トレードオフスライダー)
…辺りです。

またプロジェクトの途中では…
・やらないことリストを作る
・夜も眠れなくなる問題はなんだろう?
…あたりも良いと思います。

大事なのはインセプションデッキは1回作って終わりでは無いと思います。

継続的に、PJの状況が変化したら、インセプションデッキを確認して更新することで、より「PJの認識を合わせ、何を期待するか?」という点で効果があるように思います。
そのためにも(壁に張り出すなど、手段は色々ですが)「あぁ自分達はこのために、こんな方法で、このPJを進めているんだ」を意識するのが大事かと思います。

ロッカーの奥深くのキングファイルに入れてまま、とか、ファイルサーバの奥深いフォルダで、最終更新日がPJの開始日・・・なんてことのないようにしたいです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo on Visualhunt

-チームビルディング, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

Redmineのチームでの使い方を紹介

Redmine Advent Calendar jp 2011の10日目になります。 私は(プラグインをガリガリ作ったりしてないので)「自分達のチームでの使い方」をいくつか紹介します。 コンテキスト …

我慢することの難しさ

もうずいぶん前の感じがしますが…2009年1月に納品したプロジェクトで、私が感じたことの1つに「自分には我慢が足りないなぁ」があります。 そのエントリにも書いていましたが、PJメンバーにいた新人と若手 …

フリカエリ

[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。 今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカ …

仕様変更における納得感の大事さ

システム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。 その仕様変更決定までの過程によっては、(SIerも含めた)プロジェクト関係者の納得感のある/なしが大きく変わり、それはアウトプッ …

1回の会議・打ち合わせで必ず結論を出す技術[読書感想]

1回の会議・打ち合わせで必ず結論を出す技術 著者:斎藤 岳 題名の通り、会議/打合せでいかに(参加者全員が納得し、次のアクションへつながる)結論を出すかを書いています。 ◆目次 第1章 「結論を出す能 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。