Comments
Transcript
How Agile Masters Deliver Great Software
アジャイルサムライ——達人開発者への道 How Agile Masters Deliver Great Software Jonathan Rasmusson 西村直人, 角谷信太郎 近藤修平, 角掛拓未 P1.0P8.0, 2011 年 7 月 25 日 2012 年 5 月 15 日 Build date: 2012 年 5 月 15 日 (m-sl b-n bc-n) Original English language title: The Agile Samurai by Jonathan Rasmusson Published by The Pragmatic Programmers, LLC Copyright © 2010 Jonathan Rasmusson Translation Copyright © 2011 Ohmsha, Ltd. All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. 本書を発行するにあたって、内容に誤りのないようできる限りの注意を払いましたが、 本書の内容を適用した結果生じたこと、また、適用できなかった結果について、著者、出 版社とも一切の責任を負いませんのでご了承ください。 本書に掲載されている会社名・製品名は一般に各社の登録商標または商標です。 本書は、 「著作権法」によって、著作権等の権利が保護されている著作物です。本書の複 製権・翻訳権・上映権・譲渡権・公衆送信権（送信可能化権を含む）は著作権者が保有し ています。本書の全部または一部につき、無断で転載、複写複製、電子的装置への入力等 をされると、著作権等の侵害となる場合がありますので、ご注意ください。 本書の無断複写は、著作権法上の制限事項を除き、禁じられています。本書の複写複製 を希望される場合は、そのつど事前に下記へ連絡して許諾を得てください。 • オーム社開発部「アジャイルサムライ」係宛、E-mail （[email protected]） または書状、FAX（03-3293-2825）にて 読者の声 ジョナサン・ラスマセンが今、本書を通じて伝えようとしていることは何か。それは、ア ジャイルマニフェスト*1 を書き上げたあの頃の私たちの熱狂であり、私たちにとってのア ジャイルソフトウェア開発の価値である。師を仰ぎ、師を追いかけ、師に歩調を合わせ、 師の意図を汲み、そして自らが師になるのだ。 ä Ron Jeffries www.XProgramming.com アジャイルマニフェスト共著者 私は、その手を真っ黒に汚した実践者の書いた書籍が大好きだ。ジョナサンには何年にも わたるアジャイル開発の実務経験があり、本書は彼の貴重な知見で埋め尽くされている。 あなたがアジャイル開発を始めたばかりであるとか、プラクティスの改善をしようと思っ ているのなら、本書から学べることが沢山あるはずだ。 ä Joshua Kerievsky Industrial Logic, Inc. Founder and CEO ジョナサンは何年にもわたって、数多くのアジャイルプロジェクトの現場を経験している。 本書には、その経験のエッセンスが凝縮されている。語り口には彼独特の思いやりと見識、 そしてユーモアがあふれている。アジャイルにソフトウェアを届けたいチームなら、本書 を必読書リストに入れるべきだ。特に、インセプションデッキの章は、新しくプロジェク トを始めようとしているのなら必読だ（既に厄介な状況に陥っているプロジェクトを救う のにも使える！）。 ä Dan North DRW Senior Developer 最初は、軽いノリの入門書だろうと高をくくっていた。「マスター・センセイ」だし、そも そも「サムライ」だし。でも、そんなに甘くない。軽い文体とは裏腹に、アジャイルな開 発のありかたが、きわめてロジカルかつ網羅的に語られている。ありそうで、なかった本。 手元に置いておけば、きっといいことがあるはずだ。 ä 和智右桂 『エリック・エヴァンスのドメイン駆動設計』訳者 映画「七人の侍」の旗を見たことがあるだろうか。侍を示す 6 つの⃝印と、菊千代（三船 敏郎）を示す 1 つの△印が描かれている。彼のような侍と百姓（顧客）の心をつなぐサム ライこそが、本書を読み終えたアジャイルサムライ△なのだ。 ä 角征典 『アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き』 訳者 *1 ［訳注］付録 A「アジャイルソフトウェア開発の原則」 （p. 291）参照。 iii iv 読者の声 顧客に強くかかわってもらい、顧客の期待をマネジメントしながら、チームで成果をあげ ていく。こういった仕事のやりかたを、あなたが具体的にもっと知りたいと思っているな ら、『アジャイルサムライ』はピッタリの一冊だ。 ä 木下史彦 株式会社永和システムマネジメント マネージャ, 『アート・オブ・アジャイル デベ ロップメント―組織を成功に導くエクストリームプログラミング』監訳者 アジャイルな開発手法は顧客に価値を定期的に繰り返し提供していくための方法だが、実 際にやってみると何から手をつけたらよいのか困ってしまう人も多いだろう。本書では経 験に裏打ちされたアジャイルなプロジェクトの進め方がわかりやすく示されている。是非 一度ではなく定期的に読み返してほしい。そのたびに新しい気づきを与えてくれるだろ う。そして困ったときにはこう自問してほしい「マスター・センセイなら何と答えるだろ うか」と。 ä 吉羽龍太郎 アジャイルコーチ 一人の若手のソフトウェアエンジニアとして、この本と出会えたことに感謝しています。 たった一冊でアジャイルな開発について網羅的に教えてくれる本書と出会っていなけれ ば、この数ヶ月で現場に新しい開発手法を導入して、かつ成果を上げることは不可能でし た。そして、付録にもあるアジャイルソフトウェア開発宣言がいかに意義深い宣言かを知 ることもなかったでしょう。 ä 澤田径 株式会社ニジボックス ソフトウェアエンジニア アジャイル開発は、ちょっとした勇気と、共通する価値、顧客も含むチームメンバ同士の 敬意があれば、誰でも始められます。だからといって何の予備知識もなく始められるわけ ではありません。『アジャイルサムライ』では、その入口で必要なことを基本的な考えから 具体的な進め方まで、シンプルに、優しい語り口を通して、学ぶことができます。新人開 発者や熱心なお客様にもお勧めしたい良書です。 ä 内山滋 株式会社エリジオン 品質管理マネージャ アジャイルを始めたいですか？ それならこの本を読み込んで噛み締めて実践してくださ い。あなたのソフトウェアにかける情熱に、この本はいつでも味方です。 ä 小久保祐介 a heartful Redmine user タイトルに騙されることなかれ。この本には、いかにも欧米人が持ちそうな東洋の誤解が 満ちています。そこが味である一方、拒否反応を示し、本を閉じてしまう方もいるでしょ う。しかし、それは大変もったいない。アジャイル開発の本質がリラックスしながら掴め る一冊です。 ä 今給黎隆 株式会社バンダイナムコゲームス 認定スクラムマスター v 本書はウォーターフォールで開発している人たちにこそ読んでほしい本だと思いました。 少しでも今の環境を良くしたい、少しでも良いソフトウェアを顧客に提供したい。そんな 想いをもっている、一人でも多くの開発者の手に渡り、一つでも多くの開発の現場が幸せ になることを願っています。 ä 中村薫 Shibuya.trac 認定スクラムマスター アジャイル宣言の背後にある原則から実践的なプラクティスまで、先駆者達の暗黙知にし か見えなかったものが余す所なく書かれています。アジャイルサムライにとっての五輪の 書と言える一冊。 ä 髙橋健一 株式会社永和システムマネジメント ソフトウェアエンジニア この本を 1 年前の自分に読ませたかった。転職して初めて任されたプロジェクトで、私は 完全に道を見失っていた。あの当時にインセプションデッキを作成して「夜も眠れなくな るような問題」をお客さまと共有して「ご近所さん」をしっかり把握していれば、毎朝 2 時間早く出社して仕事をこなす日々を送らずに済んだはずだ！ ä 柴田博志 株式会社永和システムマネジメント ソフトウェアエンジニア 経験豊かなコーチに囲まれ、アジャイルに造詣の深い仲間に恵まれている環境の人は、ま だまだ少ないと思います。この本を手にする人は、マスター・センセイの薫陶を受けなが ら、兄弟弟子のサムライくんとともに切磋琢磨していくことができるでしょう。 「アジャイ ル開発を最近始めたんですけど、何かおすすめの本ありますか？」と聞かれることがあれ ば、私は間違いなくこの本を推薦します。 ä 永瀬美穂 アジャイルコーチ, ナイスビアの人 君は始まりの始め方を考えたことがあるだろうか。誰をバスに乗せ、どうやってそのバス を進めるか。もし君が「ぼくらはもっと良いやり方でソフトウェアを開発できるはずだ」 と信じるなら、この本を読むといい。この本は、みんなと力をあわせて確かな成果をあげ ていくための手がかりで満ちている。君は今バスに乗りこむ。この本は進むべき方向を示 し、勇気を与えてくれるだろう。 ä 島田浩二 株式会社えにしテック 社長 本書はすごく実践的で、開発現場でよく直面する問題を解決できるテクニックとコツが詰 まっている。『アート・オブ・アジャイルデベロップメント』が教科書なら、『アジャイル サムライ』は現場で使えるマニュアルだ。リアルなソフトウェア開発現場で闘ってきた JR 先生の秘伝書をよく読んで、よく考えて、自分のモノにしよう。ご武運を！ ä Leonard Chin（レオ） 株式会社ドワンゴ ソフトウェアエンジニア 日本の読者の皆さんへ 君がこの本を手に取ったことに祝福を。おめでとう。というのも、君にはすご く大事な 2 つのことが備わってるってことだからだ。 1. 君は学ぶことが心から好きだ。 2. 君はソフトウェアのことを大切に思っている。 このどちらもが大切なんだ。君が学びたいという気持ちを抱かなければ、私との 旅がこうして幕を開けようとすることもなかった。君がソフトウェアのことなん て気にしない人物だったら、私たちの世界は今よりも暮らしづらいものになって いただろう。 なぜなら世界はソフトウェアを必要としてるわけだから。世界はソフトウェア を作ることを手助けする人を必要としてるんだ。そう、君みたいなね。私たちが、 君みたいに才気煥発で、頭が良くて、思慮深い、情熱にあふれた人達をもっと惹 きつけられるようになるには、もっと成果をあげるソフトウェアの作り方が必要 なんだ。わくわくするような、毎朝目を覚ますたび、今日一日またソフトウェア を作ることが楽しみで仕方がないようなやつがね。 そのために私は本書を書いた。もっとうまくソフトウェアを届けるやり方を探 し求め、分かちあい、見出していこう（でもあんまり深刻に受け止めすぎないで。 楽しみながらやっていこう）。 君の探してることが、本書を読んで見つけられることを願っている。もし見つ からなかったとしても、探し続けることを止めないでほしい。 2011 年 4 月 26 日 ジョナサン・ラスマセン vii 謝辞 愛する妻タニスと素晴らしい 3 人の子供たち、ルーカス、ローワン、ブリン。 これまでの道のりで私を支え、愛してくれた家族がいなければ、本書を完成でき なかったと思う。 本書のような一冊が世に出ることができたのは、素晴らしい編集者と出版社が あったからこそだ。本書にすぐれているところがあれば、それは全部スザンナ・ プフェルツァーのおかげだ。そうじゃないところは私のせいだ。 それから、今の私があるのは、偉大な先達たちが道を切り拓いてくれたおかげ だ。ケント・ベック、マーチン・ファウラー、ロン・ジェフリーズ、ボブ・マーティ ン、ジョシュア・ケリーエブスキー、トム・ポッペンディーク、メアリー・ポッ ペンディーク、キャシー・シエラ、そして ThoughtWorks 社の素晴らしい面々。 執筆にあたっては、レビュワーとコメンテーターの皆さんから、とてもたくさ んのフィードバックを寄せていただき、その知見を惜しみなく披露していただい た。ノエル・ラッピン、アラン・フランシス、ケビン・ギシ、ジェシカ・ワトソ ン、トマス・ジェンドロン、デイヴ・クライン、マイケル・シコースキ、ダン・ ノース、ジャネット・グレゴリー、サンジェイ・マンキガンティ、ウェンディ・リ ンデマン、ジェイムズ・エイヴリ、ロビン・ダイモンド、トム・ポッペンディー ク、アリス・トス、イアン・ディーズ、ミーガン・アームストロング、ラム・スワ ミナサン、ヘザー・カープ、チャド・フォーニエ、マット・ヒューズ、マイケル・ メナード、トニー・セマナ、キム・シュライアー、リヒュール・クリストフ。本書 をこのような形に仕上げられたのは彼らのおかげだ。また、キム・ウィンプセッ トとスティーブ・ピーターによる世界随一の編集と組版技術には特に感謝したい。 父さんと母さんへ。いつも愛と励ましをありがとう。 最後に、デイブとアンディに感謝を。熱い思いを抱えた若者が書籍を執筆して、 世界中の人に届けられる会社を作ってくれてありがとう。 ix お目にかかれて光栄です アジャイルサムライ―――それはソフトウェアを顧客に届ける猛々しきプロフェッショナル だ。たとえプロジェクトがきわめて過酷な状況であろうと、かつてなく手ごわい期日であ ろうと、成果をあげる力量を備え、しかも品格と平静さを失うことがないのだ。 マスター・センセイ 「アジャイル」はソフトウェアの開発の進め方のひとつだ。アジャイルなソフ トウェア開発が私たちに言い聞かせていることは、コードを実行するのはコン ピュータかもしれないが、そのコードを生み出し、保守するのは私たち人間なん だということだ。 「アジャイル」はフレームワークであり、心構えであり、ソフトウェアを無駄な く、早く届ける手法だ。しかも、現場で実際に使える。確かに「銀の弾丸」なん てない*2 。けれども、チームの持てる力を最大限に引き出すことで、プロジェク トがうまくいく確率を格段に向上させるんだ。 本書で私は君に、圧倒的なアジャイルプロジェクトの姿を見せたい。それも場 外ホームラン級のやつをね。プロジェクトの期日と予算を守れるようになるだけ じゃあ物足りない。お客さんはソフトウェアを心から喜んで使ってくれるし、君 との仕事も気に入る。開発を進めていくプロセスにだって積極的に参加してくれ る― ― ―そんな風になるために、本書ではこんなことを学んでいく。 • アジャイルプロジェクトの準備とキックオフをうまくやる方法。プロジェ クトの意義や目的をはっきりさせておけば、誰のために何をしたらいいの かよくわからない、といった混乱とは無縁になれる。 • 要求を集めて見積もり、計画を立てる方法。それもわかりやすく、風通し よく、誠実なやり方で。 • ものすごい勢いで成果をあげていくための手法。プロジェクトを手入れの 行き届いた機械のようにして、質の高い、リリース可能なコードを生み出 し続けられるようになるにはどうすればいいか。 君がプロジェクトを率いる立場にあるなら、プロジェクトの最初から最後まで *2 ［訳注］ 「銀の弾丸」は「狼男を倒せる武器」から転じて「困難な課題を解決する決め手」の意 味。ソフトウェア開発業界では古典『人月の神話 狼人間を撃つ銀の弾はない』[Bro75] を通し て広く知られている。 xi お目にかかれて光栄です xii メンバーを導いていくためのツールとして本書を使える。アナリスト、プログラ マ、テスター、UX デザイナ*3 、プロジェクトマネージャといった役割なら、ア ジャイルチームにとってかけがえのないメンバーになるために考え抜かねばなら ないことや、身につけねばならないことを本書から学べるはずだ。 本書の読み方 読みたい章から好きに読んでもらって構わない。ただ、物事を最初から適切に 運んでいくための段取りを知りたいのなら、第 1 章から順番に読み進めていくこ とをおすすめする。 第 I 部では、アジャイルなソフトウェア開発の全体像と、アジャイルチームが どう機能するかを説明する。 第 II 部では、プロジェクトに対する期待をマネジメントするためのすぐれた ツールを紹介する。その名はインセプションデッキ。君のチームも、きっと気に 入ってくれるはずだ。 第 III 部では、アジャイルプロジェクトでのユーザーストーリーの扱い方、見積 り手法、最初のプロジェクト計画の立て方を説明する。 第 IV 部のテーマはプロジェクト運営だ。立てた計画を、君のお客さんが実際 に使えるソフトウェアとして具現化するための作戦を学ぶ。 本書を締め括る第 V 部では、アジャイルなソフトウェアエンジニアリングのコ アプラクティスをざっと見ていく。ソフトウェアの品質を上げていきたいとか、 長期的な保守コストを下げたいと思うなら、ここで説明するエンジニアリングプ ラクティスが欠かせない。 からかってるわけじゃあないんだよ 本書の内容をあまり堅苦しく受け止めないでほしい。楽しんで読んでもらえた ほうがうれしい。 そうするためには、絵を添えたり、物語仕立てにしたり、エピソードを挟むの がいいんじゃないかと考えた。アジャイルプロジェクトで働くのがどんな感じな のかを親しみやすく伝えたかったんだ。 *3 ［訳注］UX は User eXperience（ユーザーエクスペリエンス）の略。ユーザーが製品を利用し た際に、真にやりたい事を楽しく、快適に実現できるかどうかを重視した考え方の総称。 xiii サムライ戦記では、アジャイルプロジェクトの現場で実際にうまくいったり、 いかなかったりしたエピソードを紹介する。いずれも私自身や、私の周囲でのア ジャイル開発の実践経験に基づいたものだ。 今すぐやってみようの課題に出くわしたら、読み進める手をちょっと止めても らいたい。自分の頭で考えてみたり、実際に手を動かしてみたりしてほしい。 それから、我らがマスター・センセイを紹介しておこう。伝説のアジャイルマ スター。熟練のソフトウェア開発者。いかなる状況においてもアジャイルにソフ トウェアを届ける達人だ。 マスター・センセイは、君のアジャイル開発者としての旅の案内人であり、ア ジャイル精神の指導者だ。必要に応じて、肝に銘じておくべきアジャイル原則*4 を *4 ［訳注］アジャイル原則の訳文は「アジャイルソフトウェアの 12 の原則」の公式日本語訳を 引用した。付録 A「アジャイルソフトウェア開発の原則」 （p. 291） にも収録している。 お目にかかれて光栄です xiv 示してくれる。たとえばこうだ。 アジャイル開発の原則 動くソフトウェアを、 2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 マスター・センセイは各章の終わりにも登場する。アジャイル開発のプラク ティスを自分の現場に適用していくにあたって深めておくべき考え方や、進め方 の指針をマスター・センセイが示してくれる。 本書のオンラインリソース 本書専用のウェブサイトを http://pragprog.com/titles/jtrap に用意し た*5 。サイトには本書の追加情報や、書籍の内容へフィードバックするための仕 組みを提供している。 • ディスカッションフォーラム。君以外の読者や、アジャイルに熱心な人が いるだろうから参加してほしい。もちろん私もいる。 • 読者が投稿できる正誤表。内容についての改善案や誤字があれば投稿して ほしい。 じゃあ、始めようか。 *5 ［訳注］日本の読者向けのサポートページは本書の翻訳チームが https://github.com/agile- samurai-ja/support に用意している。翻訳についてのフィードバックはこちらに寄せてほし い。 目次 日本の読者の皆さんへ vii 謝辞 ix お目にかかれて光栄です xi 本書の読み方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . からかってるわけじゃあないんだよ . . . . . . . . . . . . . . . . . . . . . 本書のオンラインリソース . . . . . . . . . . . . . . . . . . . . . . . . . xii xii xiv 第 I 部 「アジャイル」入門 1 第1章 3 1.1 1.2 1.3 1.4 第2章 2.1 2.2 2.3 2.4 ざっくりわかるアジャイル開発 価値ある成果を毎週届ける . . . . . . . . . . . . . . . . . . . . . 3 つの真実 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 8 11 12 アジャイルチームのご紹介 17 アジャイルなプロジェクトはどこが違うのか . . . . . . . . . . . 17 20 27 38 アジャイルな計画づくりがうまくいく理由 . . . . . . . . . . . . 「完了」とは完了のことだ . . . . . . . . . . . . . . . . . . . . . チームをアジャイルにするためのコツ . . . . . . . . . . . . . . . よくある役割分担 . . . . . . . . . . . . . . . . . . . . . . . . . . チームメンバーを探すコツ . . . . . . . . . . . . . . . . . . . . . 第 II 部 アジャイルな方向づけ 41 第3章 みんなをバスに乗せる 43 プロジェクトがだめになるのはなぜか . . . . . . . . . . . . . . . 44 45 46 47 3.1 3.2 3.3 3.4 手ごわい質問をする . . . . . . . . . . . . . . . . . . . . . . . . . インセプションデッキのご紹介 インセプションデッキの仕組み xv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi 3.5 第4章 4.1 4.2 4.3 4.4 4.5 第5章 5.1 5.2 5.3 5.4 5.5 目次 インセプションデッキの課題一覧 . . . . . . . . . . . . . . . . . 48 全体像を捉える 51 我われはなぜここにいるのか？ . . . . . . . . . . . . . . . . . . 「ご近所さん」を探せ . . . . . . . . . . . . . . . . . . . . . . . 52 56 59 63 66 具現化させる 73 解決案を描く . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 76 80 84 92 エレベーターピッチを作る . . . . . . . . . . . . . . . . . . . . . パッケージデザインを作る . . . . . . . . . . . . . . . . . . . . . やらないことリストを作る . . . . . . . . . . . . . . . . . . . . . 夜も眠れなくなるような問題は何だろう？ . . . . . . . . . . . . 期間を見極める . . . . . . . . . . . . . . . . . . . . . . . . . . . 何を諦めるのかをはっきりさせる . . . . . . . . . . . . . . . . . 何がどれだけ必要なのか . . . . . . . . . . . . . . . . . . . . . . 第 III 部 アジャイルな計画づくり 第6章 6.1 6.2 6.3 6.4 第7章 7.1 7.2 7.3 第8章 8.1 8.2 8.3 8.4 8.5 ユーザーストーリーを集める 99 101 文書化の難しさ . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 そこでユーザーストーリーですよ . . . . . . . . . . . . . . . . . 105 よく書けているユーザーストーリーとは . . . . . . . . . . . . . . 107 ストーリー収集ワークショップを開催しよう . . . . . . . . . . . 117 見積り：当てずっぽうの奥義 125 概算見積りの問題 . . . . . . . . . . . . . . . . . . . . . . . . . . 125 ピンチをチャンスに . . . . . . . . . . . . . . . . . . . . . . . . . 128 見積り技法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 アジャイルな計画づくり：現実と向きあう 145 固定された計画の問題 . . . . . . . . . . . . . . . . . . . . . . . 145 アジャイルな計画づくり . . . . . . . . . . . . . . . . . . . . . . 150 スコープを柔軟に . . . . . . . . . . . . . . . . . . . . . . . . . . 152 初回の計画づくり . . . . . . . . . . . . . . . . . . . . . . . . . . 154 バーンダウンチャート . . . . . . . . . . . . . . . . . . . . . . . 165 xvii 8.6 8.7 プロジェクトを途中からアジャイルにしていく . . . . . . . . . . 169 現場で実践する . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 第 IV 部 アジャイルなプロジェクト運営 第9章 9.1 9.2 9.3 9.4 9.5 9.6 9.7 イテレーションの運営：実現させる アジャイルなイテレーション . . . . . . . . . . . . . . . . . . . . 184 【急募】アジャイルチーム【切実】 . . . . . . . . . . . . . . . . 186 ステップ 1：分析と設計：作業の段取りをする . . . . . . . . . . 187 ステップ 2：開発：作業する . . . . . . . . . . . . . . . . . . . . 193 ステップ 3：テスト：作業の結果を確認する . . . . . . . . . . . 197 カンバン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 205 イテレーションでやるべき 4 つのこと . . . . . . . . . . . . . . . 205 ストーリー計画ミーティング . . . . . . . . . . . . . . . . . . . . 206 ショーケース . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 イテレーション計画ミーティング . . . . . . . . . . . . . . . . . 209 ミニふりかえり . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 デイリースタンドアップ . . . . . . . . . . . . . . . . . . . . . . 213 自分たちに合った手段を選ぼう . . . . . . . . . . . . . . . . . . 214 第 11 章 現場の状況を目に見えるようにする 11.1 11.2 11.3 11.4 11.5 183 価値ある成果を毎週届ける . . . . . . . . . . . . . . . . . . . . . 183 第 10 章 アジャイルな意思疎通の作戦 10.1 10.2 10.3 10.4 10.5 10.6 10.7 181 219 これは……荒れる！ . . . . . . . . . . . . . . . . . . . . . . . . . 220 貼りものの作り方 . . . . . . . . . . . . . . . . . . . . . . . . . . 224 チームの意思を明確にする . . . . . . . . . . . . . . . . . . . . . 226 プロジェクトで使う言葉を共有する . . . . . . . . . . . . . . . . 228 バグを監視する . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 第 V 部 アジャイルなプログラミング 233 第 12 章 ユニットテスト：動くことがわかる 235 12.1 12.2 ラスベガスへようこそ！ . . . . . . . . . . . . . . . . . . . . . . 236 はじめてのユニットテスト . . . . . . . . . . . . . . . . . . . . . 238 xviii 目次 第 13 章 リファクタリング：技術的負債の返済 13.1 13.2 13.3 247 どうしてこうなった . . . . . . . . . . . . . . . . . . . . . . . . . 247 技術的負債 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 リファクタリングで技術的負債を返済する . . . . . . . . . . . . 251 第 14 章 テスト駆動開発 14.1 14.2 261 テストを先に書く . . . . . . . . . . . . . . . . . . . . . . . . . . 261 テストを使って複雑さに立ち向かう . . . . . . . . . . . . . . . . 266 第 15 章 継続的インテグレーション：リリースに備える 15.1 15.2 15.3 15.4 15.5 15.6 15.7 15.8 リリースに備える文化 . . . . . . . . . . . . . . . . . . . . . . . 276 継続的インテグレーションとは . . . . . . . . . . . . . . . . . . 277 どうすればうまくいくのか？ . . . . . . . . . . . . . . . . . . . . 279 チェックイン手順を習慣づける . . . . ビルドを自動化する . . . . . . . . . . . 作業単位を小さくする . . . . . . . . . この先どこへ向かえばいいのか？ . . . 第 VI 部 付録 付録 A A.1 A.2 273 ショータイム . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 アジャイルソフトウェア開発の原則 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 281 283 285 289 291 アジャイルソフトウェア開発宣言 . . . . . . . . . . . . . . . . . 291 アジャイルソフトウェア開発の 12 の原則 . . . . . . . . . . . . . 292 付録 B オンラインリソース 293 付録 C 参考資料 295 監訳者あとがき 299 索引 309 著者・監訳者・訳者について 315 第I部 「アジャイル」入門 第1章 ざっくりわかるアジャイル開発 2月 月 火 水 木 金 ߅ቴߐࠎߦߣߞߡଔ୯ࠆᚑᨐࠍዯߌࠆ̖̖ Ფㅳߨ㧋 動くソフトウェア お客さんにとって価値ある成果を毎週必ず届けたいと思ったら、どうすればい いだろう？ この問いこそ、本章で答えようとしているものだ。ソフトウェアを届けるとい うことを、お客さん側の視点に立って考えてみると、これまで私たちがお客さん にしてきたことにどれだけ無駄が多かったかがわかる。それと同時に、本当に大 事なことがどれだけできていなかったかもわかる。本当に大事なこと、それは動 くソフトウェアを定期的に届けることだ。 本章を読めば、次の 3 つがざっくりわかる。1 つ目は、アジャイルな計画の立 て方。2 つ目は、プロジェクトがうまくいっている度合いを測る方法。最後に、3 つの真実を受け入れることの効能について。この真実を理解できれば、厳しい期 日にも勇気を持って立ち向かえるようになるだろうし、プロジェクトが極めて過 酷な状況であっても、開発者としての品格と平静さを失わずに仕事を進められる ようになるはずだ。 1.1 価値ある成果を毎週届ける いったん「アジャイル」のことは忘れて、お客さんの立場になって考えてみよ う。これは君の資金を投じた君のプロジェクトだ。成果をあげるために選り抜き 3 4 第 1 章 ざっくりわかるアジャイル開発 のメンバーも揃えた。 さて、君が信頼に足ると判断するのは次のどちらのチームだろうか？ 実施計画 書や大量の製品文書、作業報告書を納品してくれるチーム？ それとも、一番大事 だと君が思う機能を実装して、テスト済みのソフトウェアとして毎週必ず届けて くれるチーム？ 「価値ある成果を毎週必ず届ける」ということをお客さんの視点で考えてみる と、開発チームとして何を大事にしなければならないかも見えてくる。ここでは そのために必要なことを 6 つに分けて説明したい。 1. 大きな問題は小さくする トップページ ユーザーアカウント ブログ ᣣ ࠙ࠚࡉࠨࠗ࠻ߩ᭴▽ ࡩ ᣣ ᣣ FAQ 利用規約 運営会社について 「毎週届ける」といっても、1 週間は短かい。1 週間で何もかもを終わらせ るなんて到底無理だ！ だから成果をあげるには、大きくて厄介な問題は、 もっと小さくシンプルにして扱いやすくしなきゃいけない。 2. 本当に大事なことに集中して、それ以外のことは忘れる これまで私たちはいろんな成果物を納品してきたけれども、お客さんの視 点で考えてみると、実はその大部分は、ほとんど（あるいはまったく）価 値がないものばかりだった。 もちろん、ドキュメントは書かなきゃだめだ。実施計画書だって必要だろ う。しかし、これらはあくまでも動くソフトウェアを補完するものでしか ない。 お客さんにとって価値ある成果を毎週届けたいなら、無駄を省いて、価値 につながらないものを捨てるしかない。これができれば、君はもっと身軽 になれる。本当に必要なことだけに集中できるようになるんだ。 3. ちゃんと動くソフトウェアを届ける お客さんに価値を毎週届けるということは、届けたものは動かないといけ ない。ということは、もっとテストしなきゃだめだってことだ。もっと早 1.1 価値ある成果を毎週届ける 5 めに、もっとこまめに。もっとたくさんテストするんだ。 プロジェクトの途中で何かを捨てなきゃならなくなったとしても、日々の テストだけは疎かにしちゃいけない。テストする習慣を守る責任は君に ある。 4. フィードバックを求める 定期的に立ち止まってお客さんに尋ねないで、どうやって狙いどおりに進 んでいることを確かめるんだい？ フィードバックは行く手を照らすヘッドライトだ。霧のたちこめる高速道 路を時速 100km でかっ飛ばしながら、道に迷わないようにするためには絶 対に欠かせない。もしもプロジェクトの進行中に、開発チームからお客さ んへのフィードバックが一切なかったとしたら、お客さんはプロジェクト のハンドルをうまく切れなくなってしまう。そうなれば、結局は君も動き が取れなくなってしまうんだ。 5. 必要とあらば進路を変える 当初の計画 実際の計画 プロジェクトではいろんなことが起こる。万物は流転する。今週はきわめ て重要だったことが、翌週にはどうでもよくなることだってある。立てた 計画に疑問を抱くことなく、ただ従ってちゃだめだ。大きな変化が起きた ときに、その衝撃に耐えられなくなる。だから計画を乱すような現実に遭 遇したら、計画を変えるんだ。現実を変えるんじゃない。 6. 成果責任を果たす 価値ある成果を毎週届けることをお客さんにコミットメントして、彼らの 資金の使いみちを示すことができたら、君は成果責任（Accountability）を 果たしたといっていい。ただし「成果責任を果たす」と言うのは一言だが、 そのために君がやらねばならないことがいくつもある。 6 第 1 章 ざっくりわかるアジャイル開発 • • • • 君は、仕事の質に責任を持たなきゃならない。 君は、スケジュールを守らなきゃならない。 君は、お客さんの期待をマネジメントしなきゃならない。 君は、身銭を切るかのような覚悟でお客さんの資金を扱わなきゃなら ない。 期待をマネジメントする†1 ソフトウェア開発プロジェクトでは、チーム内外にさまざまな期待が存在 する。しかも、そうした期待には明示的な期待と暗黙的な期待がある。顧客 側、開発チーム側双方の所属する組織からそれとなく期待されていることも あるだろうし、プロジェクトを進めていくうえで付き合うことになる「ご近 所さん」 （4.5「 「ご近所さん」を探せ」 （p. 66） ）に期待している・されているこ ともあるだろう。明示的に期待されていることはまだ相手にしやすい。厄介 なのは、暗黙的な期待だ。 何もかもうまくいっていれば、暗黙的な期待がプロジェクトに牙をむくこ とはない。だが、暗黙的に期待されていることにプロジェクトやチームが応 えられない状況が続くと、事態はだんだんとこじれていく。しかも暗黙的な 期待は、定義により議論の俎上に載りづらい。「顧客は何もわかってない」と か「開発チームは自分たちのやりやすさだけを優先している」とか「あそこ の部署は自分たちの都合を押しつけてばかりだ」といった不穏な空気は、暗 黙的な期待の行き違いに起因していることも少なくない。 本書の読者の皆さんにならプロジェクトのマネジメント―――継続的に世話 をしながらうまくやりくりをしつつ、なんとか事をやり遂げることが重要だ という認識には同意してもらえると思う。期待についても同様だ。プロジェ クトと同じく、プロジェクトにまつわる人々が抱く明示的・暗黙的な期待も 「マネジメント」してほしい。 プロジェクトやチームへの期待は一方的に「設定」して終わりじゃない し、進退窮まってから「調整」してどうにかなる代物でもない。かといって あらかじめ定められた手順で「管理」もできない。期待は継続的に「マネジ メント」するものだ。思っている以上に私たちはお互いに期待を伝え合って いない。だから、関係者同士でプロジェクトへの期待について話し合い、自 分たちが何をどれだけ期待しているのかを合意しよう。そして、その合意を メンテナンスし続けよう。状況が変われば期待できることも変わる。開発を 1.1 価値ある成果を毎週届ける 7 アジャイルにして期待に見合う成果をあげ続けるためには、期待そのものも マネジメントし続けねばならないのだ。 †1 ［訳注］本コラムは日本語版監訳者による。 - 警告 - 誰もがこの働き方を 気に入るわけじゃない いつの日にか、誰もがこんな働き方をするようになるだろうか？ まさか。みん ながみんな、食べ過ぎをやめて運動してるわけじゃないのと同じだ。 警告しておくと「お客さんに価値ある成果を毎週届ける」というのは、気弱な人 にはおすすめできない。たとえるなら、アジャイルに開発するというのは、これ まで経験したことのないほど強烈なスポットライトを浴びてるみたいな感覚だ。 もはや隠れる場所はない。価値を生み出すか、生み出さないか。二つに一つだ。 もし君が、プロジェクトの状況には隠し立てがないことを好み、質の高い仕事 への情熱を持っていて、価値を生み出すことを心から願うなら、アジャイルチー ムで働くことは、とても得ることの多い、楽しい経験になると思う。 念のため補足しておくと、 「価値ある成果を『毎週』届ける」という物言いにプ レッシャーを感じてるなら、そこは心配しなくていい。大抵のアジャイルチーム が最初は 2 週間単位で届けることから始めている（本当に大規模なチームだと 3 週間単位だ） 。 「毎週」というのは言葉のあやだ。大事なのは考え抜くことなんだ。動くソフト ウェアを定期的にお客さんの目の前に届けて、そこからフィードバックを得る。 そして必要とあらば進路を変えていく。これを続けるにはどうすればいいか？ た だそれだけのことなんだ。 第 1 章 ざっくりわかるアジャイル開発 8 アジャイル開発の原則 顧客満足を最優先し、 価値のあるソフトウェアを 早く継続的に提供します。 じゃあ次はアジャイルな計画づくりの話をしよう。 1.2 アジャイルな計画づくりがうまくいく理由 アジャイルなプロジェクトの計画づくりは、いろんな予定が立て込んでる週末 の準備とそう変わらない。違いがあるとすれば、ToDo リストやタスクのことを マスターストーリーリスト*1 とかユーザーストーリーといったこじゃれた名前で 呼ぶことぐらいだ。 マスターストーリーリスト 見積り 1日 2日 5日 3日 1日 …… 1日 5日 ユーザーストーリー ユーザーを追加する 注文を印刷する プロフィールを作成する 日付で検索する ホテルを更新する チー ムの ベロ シテ ィ 旅行をキャンセルする 領収書を印刷する 300日 優先順位づけされている 1 2 3 n イテレーション このあたりで完了 できそうな予感 アジャイル開発では、 「マスターストーリーリスト」がプロジェクトの ToDo リ ストだ。このリストに載せるのは、開発対象となるソフトウェアで顧客が実現し *1 ［訳注］顧客がプロジェクトの中で実現したい事を記述した一覧表。本書独自の用語。スクラ ムではプロダクトバックログと呼ばれているものと同じ。 1.2 アジャイルな計画づくりがうまくいく理由 9 たいと思うフィーチャ*2 （ユーザーストーリーとして表現する）だ。フィーチャ の記述レベルは、概要がわかれば十分だ。リストの項目に顧客が優先順位をつけ て、開発チームが見積もったら、プロジェクト計画の土台はできあがりだ。 そして、アジャイルプロジェクトで具体的に成果をあげていくためのエンジン となるのがイテレーションだ。イテレーションの長さは 1 週間か 2 週間にしてお く。このイテレーションの期間を使って、開発チームは顧客が最も価値が高いと 思うものから順番に、ストーリーをテスト済みのちゃんと動くソフトウェアへと 変換していくんだ。 それから、開発チームはベロシティ（1 回のイテレーションで完了させられる ストーリーの量）を実測することで、自分たちのこなせる仕事量を把握できる。 継続的に記録したベロシティがあれば、自分たちがこの先こなせる仕事量を予測 する判断材料になる。ベロシティの見通しが立っていれば、計画は信頼できるも のになるし、開発チームが自分たちの限界を超えた成果をあげることを顧客にコ ミットメントしてしまうことも避けられる。 やるべきことがあまりにも多すぎるという事態に直面したらどうするか。その ときは、やれることをやるだけさ―――つまり、やることを減らすんだ。スコープ を柔軟にしておく*3 ことが、計画のバランスを保ち、やると決めたことはやり遂 げていくための秘訣だ。 だから、現実が計画にそぐわなくなったら、計画を変えるんだ。現実に適応す る計画づくりはアジャイルに価値を届けるための基本だ。 アジャイルな計画づくりについては、第 8 章「アジャイルな計画づくり：現実 と向きあう」 （p. 145） でもっと詳しく説明する。 *2 ［訳注］フィーチャは、ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手など、 いわゆる「売り文句」などを総称する言葉として使っている。要求仕様、機能要件、大機能、 ユースケースといった言葉が指すものとよく似ているが、決定的な違いは、ソフトウェアを使 う側の視点から記述している点である。フィーチャはユーザにとっての価値なので、たとえば 性能目標やセキュリティといったいわゆる非機能要件も含まれる。 *3 ［訳注］スコープとは、プロジェクトで行う作業の範囲と、成果物に何を含めるかを定めたも の。 10 第1章 ざっくりわかるアジャイル開発 ߜࠂᓙߜ̖̖ߕ߱ࠎ◲නߦ ⸒ߞߡߊࠇࠆߓ߾ߥߩޕ ߽ߒ㊄㗵࿕ቯߩ৻ᄾ⚂ߛߞߚࠄ ߤ߁ߔࠎߩ㧩ోㇱ߿ࠅ߈ࠄߥߣ Ვߐࠇߜ߾߁ࠃ㧩 「殺されちゃうよ？」とは随分と物騒な物言いだけど、その仕事には、君が身を 捧げるだけの意義が本当にあるだろうか？ よく考えてみてほしい。まさか 1 年 前の勤務評定面談で交わした非現実的な約束を守ろうとしてるだけじゃないだろ うね？ まあ、そうはいっても、現実には守れもしない約束が交わされることもあれば、 チームがそれに対して「できません」と言えないこともある。というか、実によ くある話だ。でも結局のところ、できないものはできないんだ。それでもなお、 見せかけだけの「奇跡によるマネジメント」を続けるのなら、それはプロジェク ト運営として実に残念であると言わざるをえないし、顧客の期待をマネジメント する作戦としてもたちが悪い。 非現実的な計画 奇跡 動くソフトウェア アジャイル手法なら、こんな奇跡は必要なくなる。なぜなら、当初から顧客に は隠し立てをせず、誠実に仕事を進めるからだ。開発者は顧客に事実をありのま まに伝える。顧客は現在の状況について十分な情報を得たうえで、スコープ、予 算、期日の判断を下す。 これはつまり、君がどうしたいかってことなんだ。物事とは魔法のように好転 するものだという神話を存続させることを選んでも構わない。でもそうじゃなく て、お客さんと一緒に信じることのできる計画を立てて仕事を進めていくのを選 ぶことだってできるんだ。 1.3 「完了」とは完了のことだ 11 もしこの先へ歩みを進めたいと思ったなら、まずアジャイル開発では「完了」 をどう定義しているかを知る必要がある。 1.3 「完了」とは完了のことだ たとえば、君のおじいちゃんとおばあちゃんが、お隣さんの息子に小遣い稼ぎの 仕事を頼んだとしよう。庭の落ち葉を熊手で集めてゴミ袋に詰めるんだ。さて、 その子が仕事を終えたと頼んだ二人が判断するのはどのタイミングだろうか？ • • • 熊手をかける計画書を提出したとき かっこいい熊手の使い方を思いついたとき 綿密な落ち葉回収作業完了確認計画を立てたとき どれもありえないよね！ 落ち葉をすべてかき集め、袋に詰めて家の脇に置くま で、彼が小遣いを手にすることはない。 アジャイル開発の「完了の定義」も小遣い稼ぎの落ち葉集めと同じだ。アジャ イル開発の文脈で「フィーチャを届ける」というのは、コードをリリース可能に するために必要なあらゆる作業を終わらせていることを意味する。 マスターストーリーリスト ユーザーの追加 プロフィールの作成 予約を入れる 基本的な検索 分析 テスト 設計 コーディング その他もろもろ 100％完了 ߎࠇߢᄢਂᄦ㧋 「あらゆる作業」には、分析、設計、コーディング、テスト、それから UX デザ イン―― ―こうした何もかもすべてが含まれる。だからといって勘違いしないでほ 12 第1章 ざっくりわかるアジャイル開発 しいのは、これは最初からオプション機能まで全部揃えろとか、各イテレーショ ンで完成したばかりの機能を公開しろという意味じゃない。これは心構えの問題 なんだ。もしお客さんから「じゃあリリースしてください」と言われたら、すぐ にリリースできるように備えておくということなんだ。 もしも君の作業がそうなってない、つまり蓋を開けてみるまでリリース可能か どうかわからないんだとしたら、その作業は「完了」じゃない。そんなことにな らないように、私たちはアジャイル開発者として、このアジャイル開発の原則を 受け入れねばならない。 ࠕࠫࡖࠗ࡞㐿⊒ߩේೣ 動くソフトウェアこそが進捗の最も重要な尺度です。 これに加えて、いまから説明する 3 つの真実も受け入れる必要がある。 1.4 3 つの真実 ソフトウェア開発の 3 つの真実をお伝えしよう。ひとたびこれらを認め、受け 入れたならば、プロジェクトにありがちな、チームの雰囲気がぎくしゃくしてし まうとか、突然ちゃぶ台を引っくり返されるような事件とは無縁でいられるよう になる。