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

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

Agile 旧館より 開発プロセス

インセプションデッキを書いてみた

投稿日:2011年9月15日 更新日:


社内で「アジャイルサムライ~達人開発者への道~」の読書会をやっています

この読書会。色々な所(道場)があります。詳しくはGitHubにまとめられているWikiをご覧ください。

読書会で作ってみた

その読書会で、(この本の特徴の1つでもある)「インセプションデッキ」を作って発表しました。

最初に読んだ時は「あぁプロジェクト憲章とか計画書かな?」と思っていました。

いざ書き始めてみると、答えに窮する部分が見つかったり、分かっていたつもりでも文章にするとボンヤリとしていてフワッとしていることが明らかになってきました。

チームでもやってみた

(この読書会とは別の日に)チームの何人かと「エレベータピッチ」「トレードオフスライダー」を「みんなはどう思います?」と議論しました。

すると、(幸いにして根本的にはそれ程違いはなかったのですが)それぞれの想いや細かな優先順位の違いがありました。このチームで携わっているプロジェクトはすでに1年半ほど経つのに、それでもこれだけ違うというのは面白い発見でした。

インセプションデッキは、プロジェクトの初期段階に、できればメンバー全員で、最低でも核となるメンバーを含めてやった方が良いと感じました。

マネジメントが主な業務となるプロジェクトマネージャや最後までいない上流工程のコンサルタント的な方が「プロジェクト計画書」なるものを作ったりしますが、それがメンバーに浸透するかというと、まずほとんどしていません。
だから開発の山場で「そもそもこれは何のためなんだ?」となったり、設計方針がぶれたりすることもあります。

「プロジェクト計画書」でも浸透できるようなプロセスが組み込まれていると良いのですが、実際は前述のような人が書いて、メンバーには「読んでおいて」(そしてメンバーは多忙なので読む余裕はない)で終わっていると思います。

その点、インセプションデッキは気軽に始めることができ、チームのみんなで作っていくように組み込まれています。
#その質問の内容自体は本気で考えると手軽ではなく、むしろタフクエスチョンなのですが。

常に意識する、継続的に見直すことができれば、判断に迷った時に「インセプションデッキに照らし合わせるとこうだ!」と言え、それが正解か間違えているかは別としても、少なくとも迷走して疲れ果てることは少なくなると思いました。

セキュリティ的に問題なければ10枚程度のスライドなので壁に貼りだしても常に見えるようにしても良いくらいです。

こんなイベントもあります

2011/09/18(日)には東京で他流試合という名のイベントもあります。社内の読書会メンバーが参加してLTもするので、どんな内容だったか感想を楽しみにしています。

もう1つ、2011/10/08(土)にある「AgileTourOsaka2011」では、監訳者の1人西村直人(@nawoto)さんがインセプションデッキのワークショップをするのでそちらも参加したいです。
日々のタスクに追われていて、「そもそも自分はなぜそれを作っているのは?どうなるのが目的??」というのを意識できないかもしれませんが、まずはできるところだけでもやってみてはいかがでしょう?

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
※アイキャッチ画像:http://www.flickr.com/photos/acain/5418547739/

-Agile, 旧館より, 開発プロセス

執筆者:


comment

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

関連記事

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス[読書感想]

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive) 2011年最初に読んだ本です。 300ページほどの大型 …

小さなチーム、大きな仕事―37シグナルズ成功の法則

< div class=”yellowbox”>小さなチーム、大きな仕事―37シグナルズ成功の法則 (ハヤカワ新書juice) 「37シグナルズ」の理念を書き記しています …

ふりかえり

KPT法を使う場合に気をつけること

 以前、書いたKPT法を実際に1人やプロジェクトの「フリカエリ」で使ってみて感じたことを書きます。 ※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。    KPT …

何かを変えたい(チェンジ)時の5つのコツ

先日「AgileTourOsaka2012 in Minoh」に参加してきました。 箕面という珍しい土地も楽しめましたし、スピーカー3人ともあまり関西ではお話されない方なので、お話が聴けて良かったです …

プロジェクト完了報告書の問題

プロジェクト完了報告書 昔のいたある会社に「プロジェクト完了報告書」というドキュメントがありました。 「そのプロジェクトで得られた教訓を(自分も含めた)組織の別のプロジェクトの改善につなげる」ために作 …

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