「アジャイルサムライ」を読みました

これも定番中の定番ですが、特にプロジェクトキックオフ時の取り組みに関してインセプションデッキを追求したくて、読もうと思いました。

作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
出版社/メーカー: オーム社
発売日: 2011/07/16
メディア: 単行本（ソフトカバー）
購入: 42人クリック: 1,991回
この商品を含むブログ (255件) を見る

第3章みんなをバスに乗せる

はい、インセプションデッキの章です。

今までも、プロジェクトの概要や目的を明文化するような取り組みとして、"インターナルプレスリリース"という取り組みを社内でやってきていました。これは、Amazon流の開発術では、まずプレスリリースを作る | fladdictに習って、先にプレスリリースを書いてみるというものです。ただ、インセプションデッキを試した後に気づいたことは、「インターナルプレスリリース作成前に、プロジェクトメンバーみんなで認識を合わせる場があったら、もっとよりよくできたのかもしれない」ということです。

インターナルプレスリリース

インターナルプレスリリースは、以下の流れで作成していました。

ある一人が、プロジェクトの概要をプレスリリースとして明文化する作業を行う
明文化したものを、プロジェクト内外に共有する
フィードバックを受けて、ブラッシュアップする

インターナルプレスリリースの目的の一つに、「プロジェクト外の人に、プロジェクトの概要を周知するため」がありました。これは、会社が大きくなっていくにつれて、他のプロジェクトが何をやっているのかが分かりづらくなってきたという課題を解決するものです。インターナルプレスリリースによって、実際にプロジェクト外の人が該当のプロジェクトの概要を分かるようになりました。

ただ、インターナルプレスリリースを続けていくに従って、以下の点が問題点・改善できそうな点としてあがってきました。

プロジェクトの概要を明文化するのは思いのほか難しく、一人で考えていると煮詰まってしまう
プロジェクトメンバーでさえも、プレスリリースを眺めても深く入ってこない

上記の課題に、インセプションデッキ作成はぴったりはまりました*1。プレスリリースとして明文化する作業の前にインセプションデッキ作成を行っておくと、「プロジェクトメンバーが、プロジェクトの概要や目的をより深く認識・共有する」ことができるようになります。その前提だと、デッキを作成するときに話した内容を元にインターナルプレスリリースを作成することができます。これによって、プレスリリース作成者が煮詰まることが少なく、多少煮詰まっても他メンバーと相談していくことができます*2。

テンプレート化 on Cacoo

インセプションデッキを実際に作ってみると想像以上によかったのですが、ちょっとだけ手間がかかるところがありました。当初、本書のサポートサイトで配布されているテンプレートを使ってたのですが、更新が入るたびに毎度更新して、ファイルサーバ上に置きつつチャットにキャプチャ貼って・・・みたいなことをやってたんですよね。

で、こういう手間を無くすために、うちらはCacooというサービスを作っていたのでした。というわけで、インセプションデッキもCacoo化して、合わせて社内の他のプロジェクトでも手軽に利用できるようにテンプレート化。

多分このままだと、見ることはできても社外の人はコピーして流用するのはできなさげですが、欲しい人がいたらコメントか何かもらえると。コピーできるように、もうちょい設定します*3。

第4章全体像を捉える / 第5章具現化させる

インセプションデッキの中でも、うちらの中では以下の2つが重要だなと実感しています。

我々はなぜここにいるのか？
エレベーターピッチ

「なぜ」これを作るのかという問いだと思いますが、エンジニア目線だとどうしてもこの辺が疎かになってしまうことがあります。結果として、何の役に立つのか・誰に向けた機能なのかがゆるふわになったり、当初のスコープより想定以上に膨らんだりしちゃいます。「なぜ」をプロジェクト初期にちゃんと考え抜いて、何かあったときにまたこの場所に戻って来れるようにしておくことは、当たり前といえば当たり前ですが大事なことですよね。

あとは、「パッケージデザイン」が上記のインターナルプレスリリースのたたき台に使えるんじゃないかとか、「やらないことリスト」「トレードオフスライダー」でプロジェクトで重要視するものを考えるきっかけになるよねとか、感じています。

そうそう、「期間を見極める」のところで出てきた、「プロジェクトの期間は6ヶ月以内が望ましい」ってのはまさにその通り。長いと、どうしても曖昧になってしまって、あれもこれもと夢を詰め込みがちになりますしね。

第6章ユーザーストーリーを集める

ユーザーストーリーの洗い出しについていつも悩むんだけど、よさげなやり方が紹介されてました。フローチャートを書いてそこからストーリーを抽出していく方法と、画面モックからストーリーを抽出する方法。両方よさげ。

f:id:ikikko:20170206223450j:plain

あと、あまり詳細に立ち入りすぎないようにってアドバイスもよかった。これもそのまま引用。

ストーリー収集ワークショップでは、1日かけて開催した場合で、ざっくりとしたストーリーを10~40ぐらい書き出せれば十分だろう。これぐらいあれば、向こう3ヶ月から6ヶ月ぐらいの計画を立てられる。書き出したストーリーが数百もあるのだとしたら、それは半年以上先の遠くまで計画を立てようとしているか、詳細に立ち入りすぎているかのどちらかだ。今の時点で優先すべきは幅だ（孵化さじゃない）。深みにはまって身動きが取れなくなっちゃいけない。

第8章アジャイルな計画づくり：現実と向きあう

バーンダウンチャートではなくバーンアップチャートにして、かつスコープの広がりを表すもの。「アジャイルな見積もりと計画づくり」を読みました - @ikikko のはてなブログにも、バーンダウン棒グラフだったっけな？スコープも表現するようなものはあったけど、こっちのほうがシンプルでよさそう。今のプロジェクトに提案してみようかな。

f:id:ikikko:20170206223506j:plain

最初の一歩の人に進めるときにいい一冊。アジャイル全般ならこの本で、もうちょいスクラムに絞った本ならばSCRUM BOOT CAMP THE BOOK、カンバンならばカンバン仕事術かな。本のWIPは1冊＆読書感想ブログを書くのを自分ルールに決めてるのであまり色々な本を読めておらず、もっと適切な本もあるかもですが。