書籍情報
書籍名: アジャイルサムライ――達人開発者への道
著者: Jonathan Rasmusson（ジョナサン・ラスマセン）
訳者: 西村直人、角谷信太郎、近藤修平、角掛拓未
出版社: オーム社
発売日: 2011年7月16日
価格: 2,618円（税込）
著者について
Jonathan Rasmusson（ジョナサン・ラスマセン）
カナダのソフトウェア開発者であり、アジャイル開発の実践者。エクストリームプログラミング（XP）やスクラムなどのアジャイル手法を現場で実践し、その経験を本書に集約している。
訳者について
本書の日本語訳は、日本のアジャイル開発コミュニティで活躍する4名の実践者によって行われている。
- 西村直人: アジャイルコーチ、スクラムマスター
- 角谷信太郎: Railsコミッタ、アジャイルコーチ
- 近藤修平: アジャイル開発実践者
- 角掛拓未: アジャイル開発実践者
読書動機
1. アジャイルな計画づくりの具体的な方法を学びたい
ユーザーストーリーの書き方、見積もり、ベロシティの計測など、アジャイル開発における計画づくりの実践的な手法を理解したかった。
2. 現実的な計画の立て方を知りたい
従来のウォーターフォール型の計画づくりとは異なる、変化に対応できる柔軟な計画の立て方を学びたかった。
学習メモ
本書から学んだ内容を実際のプロジェクトで活用するため、重要な概念をノートにまとめました
学んだこと
1. 文書の難しさ（p.101）
実際のソフトウェアプロジェクトで重厚な文書化が要求を捉える手段として、本当にうまく機能したことなんて一度もない。顧客は自分たちの欲しいものを手に入れることはほとんどなく、開発チームは求められたものを構築しきれない。
学び: 重厚な文書化は、変化に対応できず、結果的にプロジェクトの成功を妨げる。
2. そこでユーザーストーリーですよ（p.105）
ユーザーストーリーは、顧客がソフトウェアで実現したいと思っているフィーチャーを簡潔に記述したものだ。通常、ユーザーストーリーは、あまり大きくないインデックスカードに書く（なんでもかんでも書き出そうとすることを物理的に制限するためだ）。
インデックスカードには簡潔にしか記述しないので、詳細は顧客のところへ出向いて直に会話をすることを促進する仕掛けになっているのだ。
フィーチャの本質を捉えるキーワードを書き留めておくことなんだ。あとでお客さんと何の話をするんだったかを思い出せるようにね。
なぜキーワードだけ？
要求を事細かに聞き出さないのは、フィーチャを思いついたばかりの時点では、それが本当に必要になるかどうかはまだわからないからだ。
3. 顧客の代わりにストーリーを書いたってかまわない（p.113）
確かにユーザストーリーの中身は顧客が提供すべきだ（なぜなら、開発チームが何を作るべきか本当にわかるのは顧客だけだからだ）。というもの、現実には、ほとんどのストーリーは君が書くことになるだろう。
大事なのは、顧客が要求収集のプロセスに参加してくれていることと、彼らのニーズを君がちゃんと押さえていて、それがカードに書き留められているかってことなんだから。
4. ユーザーストーリーのテンプレート（p.116）
テンプレート:
「＜ユーザの種類＞として、＜達成したいゴール＞をしたい。なぜなら＜理由＞だからだ。」
ユーザーストーリーのテンプレートの利点は、３つの大事な疑問に答えている所だ：
- 誰が（ユーザの種類）
- 何を（達成したいゴール）
- なぜ（理由）
このテンプレートに従うことでコンテキストが明らかにできるし、ビジネスの視点に集中できる。これは実にいい。
5. ストーリー収集ワークショップを開催しよう（p.117）
ワークショップでは開発チームと顧客が一緒になって開発対象のソフトウェアのユーザーストーリーを書く。
フィーチャーをたくさん出すのは、すべてを実装するためじゃない。なるべく多くの事柄を議論の俎上にのせて、全体像をつかむことが目的だ。
6. ユーザストーリーをたくさん書く（p.121）
ユーザーストーリーの抽出にあたっては、小さくて、具体的なE2Eの機能にすることを心がけよう（一日から五日で実装できるサイズを目安にしよう）。
もちろん、中にはもっと大きなストーリーもある。そういったストーリーのことをエピックと呼んでいる。
7. 概算見積もりなんてあてずっぽうだ（p.127）
プロジェクト初期段階での概算見積もりには最大で4倍の誤差があるかもしれないということだ。
学び: 初期見積もりの不確実性を受け入れ、プロジェクトが進むにつれて精度を上げていく。
8. プロジェクトをクビになったときのこと（p.149）
だから君は、自分のお客さんにちゃんとわかってもらえるように説明することを心がけよう。アジャイルな計画づくりはどうしてうまくいくような仕組みになっているのか。それから、現実と計画とが食い違ってきたら、それに対応するためには計画のほうを柔軟に変えていくんだ、ってことをね。
9. アジャイルな計画づくり（p.150）
乱暴にまとめると、アジャイルな計画づくりとは、チームの開発速度を計測して、その速度をもとにプロジェクトの完了時期を見通せるようにすることでしかない。
アジャイル開発では、プロジェクトでこなすべきToDoリストを「マスターストーリーリスト」と呼ぶ。リストの項目では、顧客がソフトウェアで実現したいと思っているありとあらゆるフィーチャを記載する。
アジャイルな計画作りでは、チームがユーザーストーリーを動くソフトウェアに変換する速度を「ベロシティ」と呼ぶ。ベロシティはチームの生産性の計測とプロジェクトの完了日の見通しを立てるのに使われる。
10. スコープを柔軟に（p.152）
スコープを柔軟にしておくこと。これこそがアジャイルプロジェクトで計画を誠実なものに保ち続けるための秘訣だ。
そのために、君がお客様に強くお願いしておくべきことがある。それは新しいストーリーを追加するときには、必ずどれかひとつ既存のストーリーをマスターストーリーリストから削ってもらうんだ。
11. アジャイルの原則：変更を歓迎する（p.153）
アジャイルの原則: 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
初回の計画づくり:
プロジェクト初回の計画づくりは、いろんな予定が立て込んでいる週末の準備とそう変わらない。どちらもまずはしっかりとしたリストを作ることから始める。マスターストーリーリストは、フィーチャ（ユーザストーリーとして表現する）の一覧だ。リストには顧客がソフトウェアで実現したいものを載せていく。載せた項目は顧客が優先順位をつけて、開発チームが見積もる。その結果が計画の土台になる。
12. アジャイル開発の原則：シンプルさ（p.156）
アジャイル開発の原則: シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
MMF（Minimum Marketable Feature）の二番目のMは「市場価値があること（Marketable）」だ。これは、つまりそのリリースは、お客様にとっての価値がなきゃだめだってことだ（そうじゃないと使ってもらえない）。
13. バーンダウンチャート（p.165）
バーンダウンチャートは、チームがどれくらいの速度でストーリーを実装しているかをひと目でわかるようにした図のことだ。
バーンダウンチャートがプロジェクトの状況を可視化する優れたツールなのは、次の４つが一目瞭然になることによる：
- どれだけ仕事を完了させたのか？
- どれだけ仕事が残っているのか？
- チームのベロシティ
- いつ頃すべて完了させられそうか
14. バーンアップチャート（p.167）
バーンダウンチャートによく知られている別の形式がある。バーンアップチャートだ。基本は同じだが上に向かって積み上がっていくところが違う。
バーンアップチャートのほうが好みだという人もいる。こちらのほうがストーリーが追加されたことがわかりやすいというのがその理由だ。図の左下から右上に向けて曲線を引けば、途中でスコープが広がってしまった場合にはそれがすぐにわかる。
15. プロジェクトを途中からアジャイルにしていく（p.169）
プロジェクトをアジャイルにしていく作戦なんていくらでもある。たとえプロジェクトの途中だったとしてもね。こんなことを質問してきたということは、君の今の状況は次のどちらかに当てはまるんじゃないかな？
a) 今やっている開発がうまくいかない
b) とにかく早く、何らかの成果をあげないといけない
今うまくいっていない要因が、チームの方向性にまつわるものなら、インセプションデッキを作ってみよう。
16. 知らぬが仏とはよく言ったものだ（p.171）
とある事業部長に、アジャイル開発についてどう思うか尋ねたことがある。彼の答えはこうだった。「愛憎半ばする思いだよ」と。
その事業部長は、アジャイル開発がプロジェクトにもたらす見通しの良さは気に入ってるそうだが、その一方で、その見通しの良さを気に食わないとも感じているようだ。
なぜなら、以前なら都合の悪いことがあっても、何もかもうまくいってる振りをしていればよかった。
学び: アジャイル開発は透明性が高く、問題を隠せない。それが強みであり、時には辛いところでもある。
17. シナリオその１：お客さんが新しい要求を発見したら（p.172）
お客さんがソフトウェアで本当に実現したいことに気づいたら、それをどうしたいかを尋ねよう。期日を延ばしてもらってもいいし（開発費用は追加になるけど）、それほど重要じゃないストーリーをスコープから外してもらってもいい。
もしもお客さんがどうするかを決めかねているようなら、「あるといいな（Nice to have）」リストを用意してお客さんにこう伝えよう。
「もしもプロジェクトの終了までに余裕ができた場合は、あるといいなリストにのっているストーリーに取り組みます」と。
18. シナリオその２：思っていたほどは早く進んでいないとき（p.173）
イテレーションを3、4回をこなしてみたところ、チームベロシティが思ったほど高くないことが判明した。でも慌てなくていい。そんなことは想定の範囲内だ。
ベロシティが思ったほど高くないことが今の時点でわかったということは、これから必要に応じて進路を調整すればいいのだから、悪いことばかりというわけでもない。
対応策:
- スコープを柔軟にしておく（推奨）
- 要員の追加を検討する（実際に人が増えると最初は速度が落ちる）
- 期日を延ばす
19. スパルタ戦士の流儀（p.174）
スパルタ式の実装は、具体的にこんな風になる。極めて重要なフィーチャを１つか２つ選んで（アーキテクチャをE２Eで貫く、アプリケーションの中核をなすフィーチャが良い）その実装にどれくらいかかるか計測する。
学び: 重要なフィーチャを先に実装することで、早期にリスクを洗い出し、ベロシティを正確に測定できる。
20. シナリオ３：大切なチームメンバーが居なくなったら（p.175）
かけがえのないチームメンバーを失ってしまったとき、その影響を測ることは、一筋縄じゃいかない。チームにとって大きな打撃となることはわかりきっていたけど、どれぐらいの打撃なんだろうか？
チームメンバーの変更にまつわる期待マネジメントでは、あまり科学的になる必要はない。お客さんには、プロジェクトが打撃を受けることはあきらかだと伝えればそれでいい（もし可能なら、ベロシティのインパクトを計測する）。
21. シナリオその4：時間が足りなくなったら（p.176）
時間が足りなくなったときの教科書的な回答はこうだ。スコープを調整せよ。期間が半分になったら、実装できるフィーチャも半分にするしかない。極めて単純な話だ。
だからといって、開発チームが実現できそうな約束を無理矢理押しつけられるような状況は非常にまずい。そんなやり方は誰のためにもならない。
こうした場合のやりとりは、双方向でなきゃならない。正直にどうすべきなのかを話し合うことだ。
感想
全体的な印象
三部は実践的なテクニックが多く、すぐに個人開発で試せる内容だった。特にユーザーストーリーの書き方、ベロシティの計測、バーンダウンチャートの活用は、個人開発のタスク管理にも応用できる。
個人的な気づき
見積もり誤差は当たり前
見積もり誤差が最大4倍あることを知り、安心した。完璧な計画を立てようとするのではなく、柔軟に調整していくことが重要だと理解できた。
スコープの柔軟性が鍵
時間、予算、品質を固定し、スコープで調整するという考え方は、個人開発でも非常に有効。完璧を目指すのではなく、MVPを素早くリリースして改善していく姿勢が大切。
透明性の価値
バーンダウンチャートなどで進捗を可視化することで、問題を早期に発見できる。隠すのではなく、オープンにすることが結果的にプロジェクトを成功に導く。
実践できること
短期
-
ユーザストーリーをたくさん書く（参照: p.121）
- 個人開発の機能や、業務改善の項目などをユーザーストーリー形式で記載
- テンプレート：「＜ユーザの種類＞として、＜達成したいゴール＞をしたい。なぜなら＜理由＞だからだ。」
-
GitHubプロジェクトでバーンアップチャート、バーンダウンチャートを試す（参照: p.165-167）
- 進捗を可視化してベロシティを測定
-
「あるといいな（Nice to have）」リストを作成（参照: p.172）
- 優先度の低い機能を別リストで管理
中長期
-
ベロシティを定期的に計測する習慣を確立（参照: p.150）
- 個人開発でも完了したタスク量を記録し、計画精度を向上
-
スコープ調整を前提とした計画づくり（参照: p.152-153）
- 期日と品質は守り、スコープで調整する習慣
-
マスターストーリーリストの継続的な更新（参照: p.150）
- 新しいアイデアをリストに追加し、優先順位を定期的に見直す
定量評価（1年後に記入）
注意: このセクションは読書直後ではなく、1年後など実際の効果が見えてから記入してください。数値化できない学びの価値（思考力、創造性、教養など）も重要です。見積もりは保守的に行い、過度に楽観的な数値は避けてください。
記入日: （未記入）
スキル・知識の評価
| 評価項目 | 評価 | コメント |
|---|---|---|
| 長期的な有用性 | ⭐⭐⭐⭐⭐ (5/5) | ユーザーストーリー、ベロシティは普遍的 |
| 実践のしやすさ | ⭐⭐⭐⭐⭐ (5/5) | 個人開発ですぐ実践可能 |
| 汎用性 | ⭐⭐⭐⭐⭐ (5/5) | タスク管理全般に応用可能 |
スキルスコア: 15/15点
経済的インパクト
時給の計算: 年収 ÷ 2,000時間で計算。参考: エンジニア平均¥3,000（年収600万円相当）
投資コスト
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 書籍価格 | ¥2,618 | Amazon価格 |
| 読書時間 | 8時間 | 第3部通読 + ノート作成 |
| 読書時間コスト | ¥24,000 | 8時間 × ¥3,000/時間 |
| 総投資額 | ¥26,618 | 書籍価格 + 読書時間コスト |
リターン（1年後に記入）
| 項目 | 数値 | 根拠・計算 |
|---|---|---|
| 時間削減効果 | XX時間/月 | [タスク管理効率化による削減] |
| 時間削減の金額換算 | ¥XXX,000/月 | [削減時間 × 時給] |
| 計画精度向上効果 | ¥XXX,000/年 | [見積もり精度向上による手戻り削減] |
| 年間経済効果 | ¥XXX,XXX | [時間削減 + 計画精度向上] |