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

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

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

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

関連記事

速効!SEのためのコミュニケーション実践塾[読書感想]

速効!SEのためのコミュニケーション実践塾 (日経ITプロフェッショナルBOOKS) 著者:田中 淳子 私が定期購読している雑誌「日経SYSTEMS」の前身である「日経ITプロフェッショナル」の初期に …

社内でのランチ勉強会

以前、「社内読書会をやってみて」というエントリを書きましたが、今度は社内でやってる「ランチ勉強会」のお話です。 どんなの? 週に1回、(社内の会議室などで)お昼を食べながら、プレゼン+ディスカッション …

Javaの格言―より良いオブジェクト設計のためのパターンと定石[読書感想]

仕事でJavaを使ってのシステム構築をしています。 勉強したり、資格を取るためJavaをさわることはあっても仕事は初めてです。 で、思い立って以前に買って積読していた↓をちゃんと読んでみました。 ■( …

チケットの粒度が難しい

過去のメモを整理していたところ、2年程前のプロジェクトで悩んでいた時に書いたメモが出てきたので備忘録としてアップしておきます。 悩んでいたこと RedmineやTracなどのITS(Issue Tra …

ドキュメント修正の大事さ

プロジェクトメンバー、リーダーとしての振り返りで毎回思っては実現できていなかったことを備忘録として書いておきます。 言いたいこと 仕様書等のドキュメントの作成/修正が後付けになったりして、ソースコード …

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