アジャイルサムライ−達人開発者への道−

著者 : Jonathan Rasmusson 近藤修平 角掛拓未

• オーム社 (2011年7月16日発売)

感想・レビュー・書評

[ega4432さんの感想 · 2021年1月1日]

質の高いソフトウェアを高速に届け続けるための開発手法、アジャイル。 変化が多く、スピーディなアウトプットが求められる環境ではめちゃくちゃぴったりな手法だと思う。

[j-okさんの感想 · 2020年5月9日]

# 読む前
３年半前にアジャイル開発を始めることになった時にアジャイル入門書として読んだ本。自身の役割が初めてプロダクトオーナーになったので違う目線で改めて読んでみる。

# 内容

アジャイルな方向づけ
アジャイルな開発プロセス（計画・運営）
アジャイルにやるためのプラクティス

アジャイルにやれてるかどうかを確認する問い
・継続的に価値ある成果をあげてるか？
・カイゼンを続けているか？

# 所感

初めてこの本を手にした時、入門書と思って読んでいたけれど、改めて読み返してみると、具体的な手法が多く書かれているわけでもなく、アジャイル開発を経験していない人には少しとっつきにくいかもと思った。決まったルール、お作法があるわけではなく、原則（マインド？）に従いやり方はチームや環境に合わせていくというのがアジャイルの考え方だから仕方のないことなんだと思うけど。

アジャイル開発にしばらく慣れて、やり方、考え方が固定化してきちゃってるかなぁ、という時に立ち返るために読み返すのにも適していそうだと思った。

今回の改めての気づきというか意識しておきたいなと思ったのは「期間を見積もる」の章で触れられていた、プロジェクトそのものも長期になると不確実性やリスクが増すということ。（開発サイクル（イテレーション）としての「短く期間を区切る」という考え方だけでなくプロジェクトも短く。）

もう１個の気づき（本書に対する気づき）、もともとPO側の視点で、が再読のきっかけだったけど、本書の中ではPOは「お客様」という表現でちょっと外の人の扱いだった。。。

[akkumaさんの感想 · 2020年5月6日]

顧客とプロジェクトの状況を正直に包み隠さずに共有出来ることが、ベースとしての大事な考えだと感じた。
ただ、上記はこれまで経験してきたプロジェクトや契約の習慣とは大きく異なっていて、それがアジャイルをイマイチ有効活用できてない原因なのかもと。
もう一度本書を元にチームで原点に立ち返ってみようかと思う。

[kanabun_desuさんの感想 · 2020年5月3日]

アジャイルも一般的になっています。
学ばねば。

[dokutokuさんの感想 · 2020年3月11日]

2011年の出版。それでも色あせていない。インセプションデッキという考え方。相対サイズの見積、リファクタリング、テスト駆動開発、継続的インテグレーションといったアジャイルならではの手法。「イテレーション計画ミーティング」「ショーケース」「デイリースタンドアップ」「ミニふりかえり」というイテレーションの運営。アジャイルに必須の要素が詰まっている。お陰様でアジャイル検定レベル１に合格できた。実践に使えるかはこれから。

[mikumotousanさんの感想 · 2020年3月8日]

アジャイル開発の概要を理解したいときに読む本。
事例を踏まえて学びたいときは、次に「アジャイルな見積りと計画づくり」を読むとよい。

アジャイル開発は、実態を可視化しづらいウェブアプリを前提としており、実態やプロトタイプを作る組み込みの世界にそのまま適用できなさそう。
特に、エンドユーザが直接的に価値を感じ取れないデバイス系や、Tire2サプライヤの開発には適用が難しいと思った。

組み込みの世界に適用できないところ。
　１．部分発注
　２．途中からの機能ドロップ
　３．ストーリベースの開発
　　　　ハードウェア上でソフトウェアが動くので、
　　　　どうしてもソフトウェア階層の下位から上位へ開発が進むので、エンドユーザへリリースできない。

組み込みの世界に適用できるところ。
　１．インセプションデッキでプロジェクトの外観を知る
　２．TDD　検証基準で顧客と合意しておく。

[mamohacyさんの感想 · 2020年2月17日]

<b>【一口感想】</b>
　「価値ある成果を毎週生み出し、改善のためのたゆまぬ努力を続けらているなら、あなたはアジャイルだ」

<b>【３行要約】</b>
　・アジャイル(not スクラム)の根本的なマインドと具体的な手法について描かれている
　・アジャイルをプロジェクトへ導入するにあたり、方向付け/計画/運営/製造の順に解説
　・所々にある挿絵と各章の最後に出てくるマスター先生と弟子の対談は理解が深まる

<b>【所感】</b>

本書は、アジャイルを学ぶ者にとっては「バイブル」のような扱いだそうだが、まさにその通りだと思う。

というのも、他のアジャイル系の本の多くがその手法（メソッド）に関して言及しているなかで、本書はどちらかというと「アジャイルそのものの概念や考え方」がメインに置かれているからだ。
もちろん具体的な手法も導入ステップやプロジェクトのタームに合わせて記載されてはいるもののそのところどころで「アジャイルにおいてこれはどう考えるべきか？」というスタンスで物事をとらえ、その解き方の例を提示してくれている。

監訳の角谷さんのブログに全体の目次があったので、それらから章立てのみをピックアップしてみる。

↓『アジャイルサムライ』の書影と主な目次が出てこないから自分で貼るよ - 角谷HTML化計画(2011-07-02)
http://kakutani.com/20110702.html#p01

<blockquote>第1章 ざっくりわかるアジャイル開発
第2章 アジャイルチームのご紹介
第3章 みんなをバスに乗せる
第4章 全体像を捉える
第5章 具現化させる
第6章 ユーザーストーリーを集める
第7章 見積り：当てずっぽうの奥義
第8章 アジャイルな計画づくり：現実と向きあう
第9章 イテレーションの運営: 実現させる
第10章 アジャイルな意思疎通の作戦
第11章 現場の状況を目に見えるようにする
第12章 ユニットテスト：動くことがわかる
第13章 リファクタリング：技術的負債の返済
第14章 テスト駆動開発
第15章 継続的インテグレーション：リリースに備える
</blockquote>

各章は、分かりやすい口語調の解説と実例、そしてアジャイルの師匠「マスターセンセイ」とその弟子の会話というスタイルで展開される。このうち私が気に入ったのは最後の「マスターセンセイと弟子の会話」だ。

たとえば、８章。

<blockquote><b>センセイ</b> このプロジェクトは政府機関向けの大規模プロジェクトだ。納税者の税金を使うわけだから綿密な監査を受けておる。スコープ、予算、期日のどれひとつとして変更の余地がない。何もかも固定されているのだ。このプロジェクトで成果を上げるために、アジャイル開発手法の採用を検討すべきかね？
</blockquote>

アジャイルを導入したいと考えているプロジェクトにとって必ずぶち当たるこの問題。
迷える弟子との会話が進んで行く。マスターはこう導く。

<blockquote>荒ぶる４天王（新しい要件の発見、ベロシティが上がらない、メンバーの欠落、時間の不足）は誰も抑えることはできない。
我々にできることは、変化を目に見えるようにすることだ。
変化はいつもそこにある。いかにして変化を見えるようにして対処していくべきかを、自らの頭で考えぬかねばならぬ時もある。
</blockquote>

本文では「パーキングロットチャート」という具体例も示されているが、それよりもむしろアジャイルを先導する立場にある者、スクラムでいえばスクラムマスターが、どういった思想と志向を持って行動すべきか？といったことが示されているところがポイントだ。アジャイルを組織に導入する時のキモは、メソッドやツールの導入ではなく、文化や思想そのものを変えていくことだとよく言われるが、本書はまさにその核心を突いていると言える。バイブルと呼ばれる所以はここにあるのかもしれない。

ただ、個人的には少し気になった点がある。

たしかに、読みやすい文体ではあるものの、全体としてそれなりに長い。
本文内に挿絵が多いのは評価できるが、逆に全体像を捉えた要約図が殆ど出てこない。
その結果、一度サラッと読んだだけでは頭の中にスッと入ってこない。マッピングがされていないので、記憶に残りにくく、読書の進捗が見え難いのだ。

原著がそうだったろうから仕方ないとは思うのだが、もしかすると概念図のようなものを追加して改版するとより良くなるのかもしれない。そのせいか、他のアジャイル本のうち本書から概念を吸収して別の図と文章に置き換えて表現しているものは少なくない。まさに本書で全体像が把握できなかった読者を狙い撃ちにしていると言える。
良書であるがその１点だけが残念だ。

そういう意味では、アジャイルを指向する者の原典として読むのはまったく間違ってはいないし、アジャイル開発に身を置くものとしては「必読書」であると言える。
私もことあるごとに見直しをしたいと思う。

[yuuotaniさんの感想 · 2019年11月24日]

【読書メモ】
・アジャイル開発ではToDoリストのことをマスターストーリーリストとかユーザーストーリーと呼ぶ（スクラムで言うプロダクトバックログ）
・〃プロジェクトで具体的に成果を上げていくためのエンジンをイテレーション（1，2週間）と呼ぶ（スクラムで言うスプリント）
・〃一回のイテレーションで完了させられるストーリーの量をベロシティと呼ぶ「どれくらいの速さで進んでいけるか」
・〃プロジェクトで行う作業の範囲と成果物に何を含めるかを定めたものをスコープと呼ぶ
・スコープは柔軟にしておく。やることを減らし、計画のバランスを保ってやると決めたことはやり遂げる
・顧客（スクラムでいうプロダクトオーナー）
・ソフトフェア開発の3つの真実は①プロジェクト開始時点ですべての要求を集めることはできない　②集めたところで要求は必ずといっていいほど変わる　③やるべきことはいつだって与えられた時間と資金よりも多い
・アジャイルなチームは役割分担がはっきりしていない。帽子をかぶり分ける
・アジャイルなプロジェクトは分析、設計、実装、テストといった開発工程が連続的に取り組まれている
・アジャイルなチームは、チームが一丸となって責任を果たす
・同じ仕事場で働くことがコツ。冗談を言い合ったり食事をとったり、旅行に行ったり。お互いをよく知ることがまとまった高いパフォーマンスを発揮できるチームになるコツ
・チームを自己組織化させるために、計画を自分たちで行う、肩書や役割を気にせず、テスト済みのちゃんと動くソフトウェアを提供し続けることに心を砕く、自ら動ける人を探す

■アジャイルな開発チームは職能横断的なメンバーで構成されている

★アジャイルなアナリスト：冷静な探偵「お客さまからの宿題は僕にお任せ！イテレーションごとにきっちり片づけていくよ！」
・ストーリーを書くのを手伝う
・分析
・プロトタイプ作成
・顧客と意思疎通を図る

★アジャイルなプログラマ：質の高いプログラムを生み出すことに心血を注ぐプロフェッショナル「僕のことはキーボードをもった顧客と思いねえ！」
・テストをたくさん書く
・プロジェクト進行中でもアーキテクチャの設計と改善に継続的に取り組む
・コードベースをいつでもリリースできる状態にしておく

★アジャイルなテスター：「うまく動いたら知らせるよー。うまく動かなくても知らせるよー。本番環境でコケるとかありえないからね」
・アジャイルプロジェクトでは何もかもがテストされなければならず、随所に登場する
・顧客の隣に座って要求をテストの形式に書き出す
・開発者の側でテストの自動化を手伝う
・ソフトウェアの不具合を一緒に探す
・プロジェクト全体のテストにも関心をもつ

★アジャイルなプロジェクトマネージャ：「やあ！なんか手伝えることある？いつも着地点をきにするよ」
・プロジェクトを成功させる唯一の方法は、開発チームを成功させることだと心得ている。チームの成功を阻む障害を取り除くためなら地の果てまで行く
・今どうなっているかを追跡する→プロジェクトの状況を伝える→チームの取り組む障害を取り除く
・より上位のプロジェクト関係者へ向けて、開発チームに期待できることをマネジメントする
・ステークホルダーへの状況報告
・社内の人間関係を円滑にする
・チームを外から守る盾になる
・優れたアジャイルマネージャの条件は1週間姿をくらましてもプロジェクトの業務に何の支障も出ないようにできること

★アジャイルなUXデザイナ：I ♡ customers.　利便性の高い、魅力的な体験を顧客に提供することに心を砕く「お客さんのことを考えるのってクールだよね」
・イテレーションを通して少しずつ積み重ねていくことにためらいがない
・他のあらゆる作業に先立ってすべてをデザインしてしまうのではなく、フィーチャーを実装するタイミングに合わせて少しずつデザインする
・ペルソナ、絵コンテ、ペーパープロトタイプ、コンセプトデザイン、、あらゆる技術を駆使する

■チームメンバーを探すコツ
・ゼネラリスト：フロントエンドからバックエンドまで、分析とテスト
・曖昧な状況に抵抗がない人：要求は出揃ってないし（それを見つけ出すところから）、計画は変わる。変化球を投げられても慌てず打ち返す。脱線事故が起きたら冷静に電車を乗り換えられる人
・我を張らないチームプレイヤー：合奏団のようなチーム。自分のありのままの姿を受け入れ、人と分かち合うことをためらわず、互いに学び合って成長することを心から楽しめる人

■プロジェクトを始めるときに4つの質問をしてみたら？
・自分は何が得意なのか？
・自分はどうやって貢献するつもりか
・自分が大切に思う価値観は何か？
・チームメンバーは自分にどんな成果を期待していると思うか？

■インセプションデッキ
①我々は何故ここにいるのか
②エレベーターピッチを作る
・エレベーターで同乗している30秒の間に新規事業の説明を説明をしなきゃならないことが語源。成功すれば資金援助、失敗すればまたカップラーメンをすする生活
③パッケージデザインを決める
④やらないことリストを作る
⑤「ご近所さん」を探せ
⑥解決案を描く
⑦夜も眠れなくなるような問題は何だろう？
・失敗しそうなありとあらゆることを紙に書き出す→防止策を真剣に考える→破り捨てる
・取り組む値打ちのあるリスク：低スペックな開発マシン、お客さんに時間を割いてもらえない、作業場所が分散している
・取り組む値打ちのないリスク：不景気、会社の買収、お客さんの人事異動
・変えることのできない物事を受け入れる落ち着き、変えることのできる物事を変える勇気、その違いを常に見分ける知恵 by ニーバーの祈り
⑧期間を見極める
・開発のプロジェクトは長くても6ヶ月以内で。期間に応じてプロジェクト失敗のリスクが増加する
・小さく分解する
⑨何を諦めるのかをはっきりさせる
・トレードオフスライダーを使う
・時間、予算、品質は固定されたもの。スコープ（計画）は柔軟に扱える
・同じ目盛りの項目を２つ作らない
・捉えどころのないものを忘れない。「思わずハマっちゃうくらい楽しいコンピュータゲーム」「コールセンターへの問い合わせを20％削減する」「顧客が自分で問題を解決できる」
⑩何がどれだけ必要なのか
・プロジェクトの予算：メンバーの人数×プロジェクト期間中の時間当たりのコスト
・期間と費用をざっくり、いい線行ってるあてずっぽうでも出す

・プロジェクト契約までのスコープ設定や計画に何か月も時間をかける必要はない。インセプションデッキを使って数日で。
・ユーザーストーリーはポイントを使って相対サイズで見積もる

■アジャイルな計画づくり
・マーフィーの法則：失敗する余地があるなら失敗する。トーストバターカーペットの例
・アジャイル開発の原則：シンプルさ
・リリース単位のことをMMFという
→Minimal Marketable Feature。20％くらいの早いうちから価値や成果を届けたい
・チームのベロシティ＝完了させたストーリーポイントの合計/イテレーション
・期日固定orフィーチャセット固定

[bookperさんの感想 · 2019年9月24日]

アジャイルの入門書。アジャイルとはなんぞや？から始まり、計画やプロジェクトの運営方法、プログラム、テストまでの流れが記載されている。あくまでも考え方がのっているものなので、そのままプロジェクトに適用できるかと言ったら怪しいかもしれない。ただこの本は所々に挿絵があったり、文章が口語体になっていたりして、非常に読みやすい。すぐに読みきることができた。

[ドナさんの感想 · 2019年7月27日]

アジャイル開発の方法・志を説明している本です。
軽快な文章であり、それに加えて300ページほど文量なので非常に読みやすかったです。
開発者ならアジャイルについて理解するためにも読むべき本だと感じました。