書籍情報
書籍名: アジャイルサムライ――達人開発者への道
著者: Jonathan Rasmusson（ジョナサン・ラスマセン）
訳者: 西村直人、角谷信太郎、近藤修平、角掛拓未
出版社: オーム社
発売日: 2011年7月16日
価格: 2,618円（税込）
著者について
Jonathan Rasmusson（ジョナサン・ラスマセン）
カナダのソフトウェア開発者であり、アジャイル開発の実践者。エクストリームプログラミング（XP）やスクラムなどのアジャイル手法を現場で実践し、その経験を本書に集約している。
訳者について
本書の日本語訳は、日本のアジャイル開発コミュニティで活躍する4名の実践者によって行われている。
- 西村直人: アジャイルコーチ、スクラムマスター
- 角谷信太郎: Railsコミッタ、アジャイルコーチ
- 近藤修平: アジャイル開発実践者
- 角掛拓未: アジャイル開発実践者
読書動機
1. プロジェクト開始前の準備方法を学びたい
アジャイル開発におけるプロジェクトの立ち上げ方、特にインセプションデッキの作り方を実践的に理解したかった。
2. ステークホルダーとの期待値調整方法を知りたい
プロジェクトにおける期待のマネジメント方法、特に顧客やチームメンバーとの認識合わせの具体的な手法を学びたかった。
学習メモ
本書から学んだ内容を実際のプロジェクトで活用するため、重要な概念をノートにまとめました
学んだこと
1. みんなバスに乗せる：インセプションデッキの重要性（p.43）
スタートを切る前からだめになってしまうプロジェクトは実に多い。主な理由は次の２つだ。
- 答えるべき問いに答えられない
- 手強い質問をする勇気を持てない
本章では、プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキを紹介する。インセプションデッキは１０の課題で構成されている。いずれの課題も、プロジェクトを開始する前に解いておかないとまずい質問ばかりだ。
2. プロジェクトがだめになる理由（p.44）
チームメンバーが誰もいないところで、合意したことを前提にしているから、プロジェクトがだめになるんだ。
そうならないために２つを満たすための工夫が必要だ：
- ゴールやビジョン、プロジェクトの状況や背景についてチームで話し合っておくこと。そうすれば、チームや状況に応じて適切な判断を下せる。
- ステークホルダーに情報を提供する。彼らにはプロジェクトを続けるかどうかを判断するための材料が必要だ。
3. インセプションデッキの仕組み（p.47）
インセプションデッキの背後にある考えはこうだ。
「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ。」
インセプションデッキの作成に要する期間は、数日から二週間程度を見込めば良いでしょう。
4. インセプションデッキの10の課題（p.48）
- 我々はなぜここにいるのか？
- エレベーターピッチを作る
- パッケージデザインを作る
- やらないことリストを作る
- 「ご近所さん」を探す
- 解決策を描く
- 夜も眠れなくなるような問題は何だろう
- 期間を見極める
- 何を諦めるのかをはっきりさせる
- 何がどれだけ必要なのか
5. 我々はなぜここにいるのか？（p.52）
そのプロジェクトを成功させたいと思うなら、まずは作ろうとしているものの背景にある**「なぜ」**をつかまなければならない。「なぜ」を理解できたチームの振る舞いはこうなる：
- これまでよりも新しい情報に基づいて的確な判断を下せる
- 対立点やトレードオフのバランスをこれまでよりうまく保てる
- 自分たちが考える権利を与えられているので、これまでよりすぐれた、斬新な解決策を生み出せる
6. トヨタ：現地現物の達人（p.53）
チーフエンジニアがどうやって自身の職務を果たしたかというと、彼は北米の人たちがどうやって暮らし働いているか、自家用車とどうやって付き合っているのかを実感するために、シエナに乗って全米の州という州をすべて運転したのだ。
チーフエンジニアが自ら現場に赴いて体験しなければ、このレベルでの理解はできなかっただろうし、課題も吟味できなかっただろう。
学び: 顧客の考えていることや必要としていることを本当に知りたいのなら自分自身が現場に行って、現場に向かうってことだ。
7. 「司令官の意図」をつかむ（p.54）
「司令官の意図」は、プロジェクトや任務に関する目標や目的を、簡潔な言い回しや声明あるいは文章として表現したものだった。こうした声明文やガイドラインがあると、激戦の土壇場で攻めるか引くか決定を自分たちで判断する指針としても役立つ。
8. パッケージデザインを作る（p.60）
進め方
ステップ１: プロダクトの効能をブレインストーミングする
お客さんにはフィーチャを伝えようとしちゃだめだ。なぜなら、そんなことはどうでもいいからだ。お客様が関心を持つのは、君のプロダクトでどれだけ楽になるかだ。フィーチャそのものじゃなく、フィーチャの効能をアピールしよう。
ステップ２: キャッチコピーを決める
よく練られたキャッチコピーというのはどれも、極限まで切り詰めた少ない語数で表現されています。
9. やらないことリストを作る（p.63）
やらないことリストはとてもすぐれた視覚ツールだ。プロジェクトの何がスコープ内で、何がスコープ外なのかを一目瞭然にできる。リストを作るときには開発チームとお客さんとが話し合いながら、埋めていこう。ソフトウェアで実現したいと思うフィーチャをブレインストーミングしながら進めていくんだ。
10. 100万ドルの質問（p.65）
カナダの大規模な公共事業プロジェクトでインセプションデッキを作ったときの話だ。担当部門の統括責任者がこんな質問をした。
「新システムはどうやって既存の古いメインフレームと統合するつもりなのかな」と。
実は、旧システムが新システムに統合される日は永遠に来ないことを理解していなかったのだ。旧システムは完全に置換されてしまう予定なのに。
学び: インセプションデッキを作ることで、このような重大な認識のずれを早期に発見できる。
11. 「ご近所さん」を探せ（p.66）
君のプロジェクトにも「ご近所さん」がいる。彼らがやってくるのは、データベースの管理や、セキュリティ監査、ネットワークの保守といった仕事だ。ここで一番大切なのはうまくいってるプロジェクトコミュニティなら必ず備えている基礎を築くことだ。つまり、信頼関係をね。
「ご近所さん」を探せの課題では、誰かがプロジェクトコミュニティに関わっているのかをしっかり洗い出して、彼らの存在に気を配るようにしよう。助けを求めたくなる前から知り合いになっておくんだ。
12. 解決案を描く（p.74）
開発チームが顧客の前で、解決案について話し合って、それを図として示すことの利点はいくつかある：
- ツールの技術に抱く期待をマネジメントできる
- 想定しているプロジェクトの境界とスコープを目で見て確認する
- リスクを伝えられる
もし仮に、解決策にチームの全員が同意しているかと思っていたとしても、それでもやはり、とにかく目に見える形にして確かめるんだ。
13. リスクを話し合うのは良いことだ（p.77）
プロジェクトは絶対にうまくいっこないってことをはっきりさせておくんだ：
- チームが同じ仕事場にいない
- 顧客を巻き込めない
- 自分の開発環境をコントロールできない
- その他、プロジェクトを成功させるために君が必要だと思うものが何かしら揃っていない
14. 小さく考える：ランディ・モットの6ヶ月ルール（p.81）
ランディ・モットという界隈でのロックスターがいる。彼は開発サイクルを6ヶ月を超えないことへのこだわりだという。ゴールのはっきり定まっていない大規模プロジェクトの問題は、果たされることのない約束が交わされてしまうことと、届けられる成果が不十分になりがちなことにある。
ランディのITプロジェクトの守備範囲は6ヶ月以内だ。彼の見立てでは、これ以上の期間を要するプロジェクトは危険過ぎるというわけだ。
15. 何を諦めるのかをはっきりさせる：荒ぶる四天王（p.84-87）
プロジェクトには、守らねばならない決まりや無視できない影響力を及ぼす力が存在している。
時間
時間は有限だ。時間を生み出すことはできん。保存しておくのも無理だ。我々にできることはただ与えられた時間を有効に使っていくことのみだ。まさにこれはアジャイルサムライが期日を守るためにタイムボックスを始める理由だ。
予算
予算も、時間も同じ性質を備えておる。予算もまた定められた枠の有限の資源であり、利用可能な資源が潤沢だということはまずない。
品質
世の中には、時間を優先するためなら品質を犠牲にできると信じている輩もいるようだが、それは間違いだ。品質を犠牲にすることで成立している取り組みなのであれば、それはまやかしでしかない。
スコープ
時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。するとたった一つだけ動かすことのできるフォースが残る。それがスコープだ。
16. 君の「Aチーム」を編成する（p.93）
私がインセプションデッキでこの課題に取り組むときに、いつも少し時間をとって説明している役割がある。それは**「顧客」**だ。その理由は２つある：
- この役割がプロジェクトにとって極めて重要だから
- ほとんどの企業では顧客の役割が文化として根付いていないから
私がこの話をするときには、お客さんの目を見て説明することを心がけている。その理由は、アジャイルプロジェクトへの参加を決めるということが一体何をすることになるのか、お客さん自身が覚悟できているのかを確かめたいからだ。
「プロジェクトのためにお時間をきちんと割いていただけますか。」
「必要な決定を下せるだけの権限は与えられていますか。」
17. 最終判断を下すのは誰か（p.95）
たとえ今の時点で、誰が判断を下すのかを君はわかっているつもりだとしても、とにかく一度訊いてみてほしい。大事なのは余計な不安を取り除くことだけじゃない。誰が本当に最終決定権を持っているのか？それをチームや他のステークホルダーにもはっきりと示すことが大事なんだ。
18. 最後のスライドを仕上げる（p.96）
インセプションデッキで最後に作るスライドが、顧客が喉から手が出るほど欲しがるスライドだ。なぜなら、結局のところ彼らが欲しい答えは次の２つだけだからだ：
- いつ完了するのか
- いくらかかるのか
ここではっきりさせておきたいのは、期日や開発チームの仕事のスピード、それから金額といった様々な数値について、今この時点では１００％のコミットメントはできないということだ。
感想
全体的な印象
二部は学びとれる要素が多かった。読んだ当時の職場では、実践できない部分も多いが、個人開発では自由なので、個人開発で試していきたい。
個人的な気づき
インセプションデッキの汎用性
インセプションデッキの10の課題は、業務プロジェクトだけでなく、個人開発においても非常に有用だと感じた。特に「やらないことリスト」と「何を諦めるのか」は、個人開発でスコープクリープを防ぐのに役立つ。
期待値調整の重要性
プロジェクトが失敗する最大の理由は技術的な問題ではなく、ステークホルダー間の認識のずれであることが理解できた。インセプションデッキはそのずれを早期に発見する強力なツールだ。
実践できること
短期
-
個人開発のゴール、ビジョン、プロジェクトの状況について明示しておく（参照: p.43-48）
- インセプションデッキを作成する（3ヶ月毎に作る）
-
パッケージデザインを作る（参照: p.60）
- 機能毎のアピールをする
- キャッチコピーを決める
- 題材は、RAGの奴とか、.NETの教育コンテンツとか
-
やらないことリストを作る（参照: p.63）
- draw.ioで描く
中長期
-
プロジェクト開始時のインセプションデッキ作成を習慣化（参照: 第2部全体）
- 新規プロジェクト開始時は必ずインセプションデッキを作成
-
荒ぶる四天王のバランスを常に意識（参照: p.84-87）
- 時間、予算、品質は固定、スコープで調整する
-
最後のスライドを作る習慣（参照: p.96）
- プロジェクトの見通しを定期的に可視化
定量評価（1年後に記入）
注意: このセクションは読書直後ではなく、1年後など実際の効果が見えてから記入してください。数値化できない学びの価値（思考力、創造性、教養など）も重要です。見積もりは保守的に行い、過度に楽観的な数値は避けてください。
記入日: （未記入）
スキル・知識の評価
| 評価項目 | 評価 | コメント |
|---|---|---|
| 長期的な有用性 | ⭐⭐⭐⭐⭐ (5/5) | インセプションデッキは普遍的な手法 |
| 実践のしやすさ | ⭐⭐⭐⭐☆ (4/5) | 個人開発でも適用可能 |
| 汎用性 | ⭐⭐⭐⭐⭐ (5/5) | プロジェクト管理全般に応用可能 |
スキルスコア: 14/15点
経済的インパクト
時給の計算: 年収 ÷ 2,000時間で計算。参考: エンジニア平均¥3,000（年収600万円相当）
投資コスト
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 書籍価格 | ¥2,618 | Amazon価格 |
| 読書時間 | 8時間 | 第2部通読 + ノート作成 |
| 読書時間コスト | ¥24,000 | 8時間 × ¥3,000/時間 |
| 総投資額 | ¥26,618 | 書籍価格 + 読書時間コスト |
リターン（1年後に記入）
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 時間削減効果 | XX時間/月 | [プロジェクト立ち上げの効率化] |
| 時間削減の金額換算 | ¥XXX,000/月 | [削減時間 × 時給] |
| 手戻り削減効果 | ¥XXX,000/年 | [認識のずれによる手戻り削減] |
| 年間経済効果 | ¥XXX,XXX | [時間削減 + 手戻り削減] |