Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。

  • Apple
    Apple
  • Android
    Android
  • Windows Phone
    Windows Phone
  • Click here to download from Amazon appstore
    Android

無料アプリを入手するには、Eメールアドレスを入力してください。

kcpAppSendButton

購入オプション

割引: ¥ 286 (10%)
Kindle 価格: ¥2,574

(税込)

獲得ポイント:
26ポイント (1%)

これらのプロモーションはこの商品に適用されます:

一部のプロモーションは他のセールと組み合わせることができますが、それ以外のプロモーションは組み合わせることはできません。詳細については、これらのプロモーションに関連する規約をご覧ください。

Kindle App Ad
[JonathanRasmusson, 西村直人, 角谷信太郎, 近藤修平, 角掛拓未, 西村 直人, 角谷 信太郎]のアジャイルサムライ――達人開発者への道

著者をフォローする

 全てをチェック
何か問題が発生しました。後で再度リクエストしてください。


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

5つ星のうち4.4 107個の評価

その他 の形式およびエディションを表示する 他の形式およびエディションを非表示にする
価格
新品 中古品
Kindle版 (電子書籍)
¥2,574
この本はファイルサイズが大きいため、ダウンロードに時間がかかる場合があります。Kindle端末では、この本を3G接続でダウンロードすることができませんので、Wi-Fiネットワークをご利用ください。
【注目の新刊】: 紙とKindle本が同日発売の新刊、予約中のタイトルをご紹介。 今すぐチェック【待望のKindle化】: 紙書籍で人気を博した本の電子化新着情報をご紹介。 今すぐチェック
※この商品は固定レイアウトで作成されており、タブレットなど大きなディスプレイを備えた端末で読むことに適しています。また、文字列のハイライトや検索、辞書の参照、引用などの機能が使用できません。

タブレット端末での読書には無料アプリ Kindle for iPadKindle for Android をご利用ください。

商品の説明

著者からのコメント

日本の読者の皆さんへ

君がこの本を手に取ったことに祝福を。おめでとう。というのも、君にはすごく大事な2つのことが備わってるってことだからだ。

1. 君は学ぶことが心から好きだ。
2. 君はソフトウェアのことを大切に思っている。

このどちらもが大切なんだ。君が学びたいという気持ちを抱かなければ、私との旅がこうして幕を開けようとすることもなかった。君がソフトウェアのことなんて気にしない人物だったら、私たちの世界は今よりも暮らしづらいものになっていただろう。

なぜなら世界はソフトウェアを必要としてるわけだから。世界はソフトウェアを作ることを手助けする人を必要としてるんだ。そう、君みたいなね。私たちが、君みたいに才気煥発で、頭が良くて、思慮深い、情熱にあふれた人達をもっと惹きつけられるようになるには、もっと成果をあげるソフトウェアの作り方が必要なんだ。わくわくするような、毎朝目を覚ますたび、今日一日またソフトウェアを作ることが楽しみで仕方がないようなやつがね。

そのために私は本書を書いた。もっとうまくソフトウェアを届けるやり方を探し求め、分かちあい、見出していこう(でもあんまり深刻に受け止めすぎないで。楽しみながらやっていこう)。

君の探してることが、本書を読んで見つけられることを願っている。もし見つからなかったとしても、探し続けることを止めないでほしい。

2011年4月26日

ジョナサン・ラスマセン

(日本語版序文より)

----

本書の特長

タイトルに加えて、ジョナサン独特の筆致と妙な味わいの挿絵に幻惑された読者がいるかもしれませんが、本書は見た目によらず硬派な1冊です。監訳者たちが本書の価値と特長だと捉えている点を、簡単にまとめておきます。1)開発者------もっといえばプログラマ向けに焦点を合わせていること、2)アジャイルな開発の進め方をひと通りすべてカバーしていること、3)よく練られた5部15章の構成になっていること、4)特定の方法論を前提としていないこと、5)ユーモアと楽しむ気持ちを忘れていないこと。これだけの内容を300ページ以内に収めたジョナサンたち原著執筆チームの力量には「お見事!」と喝采を送りたいです。

...

よく誤解されることなのですが、アジャイル開発は腕自慢の「優秀な」プログラマでなければ実践できない、というものではありません。たとえば、監訳者2人はアジャイル開発を実践していますが、プログラマとしてはいたって普通です。ですから、顧客にちゃんと価値を届けるためには、エンジニアリングプラクティスという先人の知恵の集大成を「問答無用」で「規律正しく実践」しなければなりません。それに、普通のプログラマは独りで実現できることもたかが知れています。だからチームを組むのです。

本書の冒頭でジョナサンは宣言します。「コードを実行するのはコンピュータかもしれないが、そのコードを生み出し、保守するのは私たち人間なんだ」と。私たちプログラマの多くは、普通のプログラマです(たくさんいるから「普通」なのです)。そんな私たちがチームを組んで成果をあげるには、物事をうまく運ぶための仕組みやプラクティスが必要です。だからといって、既存のアジャイル開発手法の提示するやり方を形だけなぞってもなかなかうまくいきません。

スケジュールを2週間単位で分割したMicrosoft Execlのシートを作ればイテレーションなのか?毎朝集まればデイリースタンドアップなのか?テストを先に書けばテスト駆動開発なのか?------「そうじゃないんだ」とばかりに、ジョナサンは「12の原則」を、字面だけでなく真に理解して体現した「圧倒的なアジャイルプロジェクトの姿」を私たちに示してくれます。10.6「デイリースタンドアップ」(p. 213)などはその好例です(毎朝、天地神明に誓ってから仕事をしてますか?ただ突っ立ってボソボソしゃべってるような開発者はいねがー?)。

私たちのソフトウェア開発の現場をどうにかできるのは私たちだけです。しかも、一つとして同じ現場はありません。だから「どんな書籍も手法も、君が必要とするありとあらゆるものを用意することなんてできない」のです。私たちは「自分の頭で考えるのをやめちゃだめ」なのです。

(「監訳者あとがき」より) --このテキストは、tankobon_softcover版に関連付けられています。

About this Title

第3章

みんなをバスに乗せる

スタートを切る前からだめになってしまうプロジェクトは実に多い。主な理由は次の2つだ。

.答えるべき問いに答えられない。
.手ごわい質問をする勇気を持てない。

本章では、プロジェクトに対する期待をマネジメントするためのすぐれたツールであるインセプションデッキを紹介する。インセプションデッキは10の課題で構成されている。いずれの課題も、プロジェクトを開始する前に聞いておかないとまずい質問ばかりだ。インセプションデッキを活用すれば、プロジェクトというバスに然るべき人が乗っているか、バスが然るべき方向を向いているかを、プログラマが最初の1行目のコードを書き始めるよりもずっと前にしっかりと確認できるようになる。

3.1プロジェクトがだめになるのはなぜか

プロジェクトが新しく始まった時点では、その成功について思い描く姿は人によってそれぞれ大きく異なるものだ。

これはプロジェクトにとって実にまずい状況だ。なぜなら、同じ言葉や言い回しを使って欲しいものを説明しているつもりなのに、いざソフトウェアができあがってみると、自分たちが実はお互いにまったく違うことを考えていたことに気づく羽目に陥るからだ。

ここでの問題は、プロジェクトの開始時点で関係者の認識が揃っていないことじゃない(それはむしろ自然なことだ)。問題は、関係者全員でプロジェクトについて話し合うよりも前にプロジェクトを始めてしまうことにある。

チームメンバーが誰もいないところで合意したことを前提にしているから、プロジェクトがだめになるんだ。

そうならないためには次の2つを満たすための工夫が必要だ。

.ゴールやビジョン、プロジェクトの状況や背景についてチームでよく話し合っておくこと。そうすれば、チームは状況に応じて適切な判断を下せる。
.ステークホルダーに情報を提供すること。彼らにはプロジェクトを続けるかどうかを決断するための材料が必要だ。

これを実現するには、尋ねたり答えたりするのがためらわれるような、手ごわい質問をするしかない。

3.2手ごわい質問をする

オーストラリアで仕事をしていたときに、たまたまThoughtWorks社*1のトップセールスの助手席に座る機会があった。その紳士の名前はキース・ドッズ。キースは私にいろんなことを教えてくれた。そのうちのひとつが、新しく契約を交わしたり何かを販売し始めたりするときに、手ごわい質問(Tough Question)をすることの重要性だ。

契約もプロジェクトも、まだこれから始める段階であれば、終盤とは違っていろんなことを質問をする余地があって、しかも質問するのに大した手間もかからないことはわかってもらえると思う。たとえば、次のようなあけすけな質問だって許されるだろう。

.どれぐらい経験を積んでいるチームですか?
.では、あなた自身はこの手の仕事の経験はありますか?
.ご予算はどれぐらいですか?
.このプロジェクトを統括するのはどなたですか?
. 2人のアナリストに30人のプログラマという体制で何も問題ない、と仰るのでしょうか?
.お尋ねしたいのですが、過去のプロジェクトで、オブジェクト指向の経験がほとんどない新人開発者ばかりのチームを率いて、レガシーなメインフレームのシステムをアジャイル手法を使ってRuby on Railsでリプレイスするのを成功させた事例はございますか?

アジャイルプロジェクトを始めるときも、これと同じだ。手ごわい質問は先に済ませておこう。それを手助けするツールがインセプションデッキだ。

3.3インセプションデッキのご紹介

インセプションデッキは、君のプロジェクトの視界をさえぎる濃い霧の向こうを照らすフラッシュライトだ。インセプションデッキは10の手ごわい質問と課題から構成されており、いずれの課題もプロジェクトを開始する前に聞いておかないとまずい質問ばかりだ。

ThoughtWorks社では、プロジェクトのスムーズな開始をサポートするのにインセプションデッキをよく使っていた。エクストリーム・プログラミングやスクラムのようなアジャイル手法は、プロジェクト憲章*2の作り方は教えてくれないのだ。現状分析と要件収集に6ヶ月も費やすことを正しいとはとても思えなかったが、さりとてその手軽な代替案もなかった。こうした状況を受けて、ロビン・ギボンズがインセプションデッキの原型を考え出した。インセプションデッキは、プロジェクトを核心まで煮詰めて抽出した共通理解を、開発チームだけじゃなく、より広範囲なプロジェクト関係者全員(いわゆるプロジェクトコミュニティ)へ手軽に伝えるためのツールだ。

3.4インセプションデッキの仕組み

インセプションデッキの背後にある考えはこうだ。「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ」と。

チームでこなしたインセプションデッキの課題の成果をそれぞれスライドとして並べていくと、どんなプロジェクトなのかということがだいたいわかる(普段私はこれをPowerPointを使ってやっている)。このプロジェクトは何であって、何でないのか。価値を届けるためにどこに力を注ぐべきか。などなど。このスライドの組(デッキ)がインセプションデッキだ。

インセプションデッキの作成に参加するのにふさわしい人物は誰か?プロジェクトに直接関係する人物なら誰にでもその資格がある。顧客、何かしらかかわりのあるステークホルダー、チームメンバー、開発者、テスター、アナリストなど、プロジェクトを円滑に進めていくことへ具体的に貢献できる全員が該当者だ。インセプションデッキの作成にあたっては、ステークホルダーを巻き込むことがとても重要だ。というのも、インセプションデッキは我われ開発チームだけのものではないからだ。インセプションデッキはステークホルダーにとっても役に立つ。「それでもなお、プロジェクトをやるのか?」というきわめて重要な決断を下すうえで有用な情報を提供してくれるからだ。

インセプションデッキの作成に要する期間は、数日から2週間程度を見込んでおけばよいだろう。インセプションデッキは、プロジェクトの今後半年間の見通しを立てるのにも向いているが、プロジェクトの状況や方針に大幅な変更があれば、そのタイミングで改訂しなければならない。

インセプションデッキは実際に使われる、生きた成果物だ。だから、作りっぱなしで棚にしまっておくようなものじゃない。仕事場の壁に貼り出すのがいいだろう。ときどきそれを眺めて思い出そう。何を作ろうとしているのか。そしてそれはなぜなのか。

改めて言うまでもないかもしれないが、本書で紹介しているインセプションデッキも単なるとっかかりにすぎない。他にも適切な質問や課題はないか、自分でも考えてみよう。君がプロジェクトを始める前にはっきりさせておきたいと思っていることは何だろう?

私がこれから紹介するインセプションデッキは出発点だと考えよう。盲信しちゃだめだ。ためらうことなく自分たちに合わせて改変してほしい。

インセプションデッキの10の設問と課題のそれぞれを詳しく見ていく前に、まずは一覧にして紹介しておこう。課題のそれぞれに簡単な説明もつけておいた。

1.我われはなぜここにいるのか?

何のために自分たちはチームを組むのか。自分たちの顧客は誰なのか。そもそもこのプロジェクトが始まった理由は何なのか。こうしたことを再確認する。

2.エレベーターピッチを作る

30秒以内に2センテンスでプロジェクトをアピールするとしたら、何を伝えるべきだろうか?

3.パッケージデザインを作る

何気なくめくった雑誌のページに、自分たちのプロダクトやサービスの広告が載っているとしたら、それはどんな内容がいいだろうか?それからもっと大事なのは、その広告を見た人は君のプロダクトを買いたくなるだろうか?

4.やらないことリストを作る

プロジェクトで実現したいことというのはかなり明確になっているものだ。それと同じかそれ以上に、やらないこともはっきりさせよう。そしてそれをわかりやすく一覧にするんだ。

5.「ご近所さん」を探せ

「プロジェクトの関係者」に含まれる範囲というものは、自分たちが思っているよりもずっと広いものだ。そうした「ご近所さん」を招いて、コーヒーでもごちそうしながら自己紹介ぐらいしてもいいんじゃないだろうか。

6.解決案を描く

チーム全員の認識が揃っていることを確認するために、概要レベルのアーキテクチャ設計図を描こう。

7.夜も眠れなくなるような問題は何だろう?

プロジェクトで起きる問題のなかには、考えることすら恐ろしいものだってある。だが、あえてそうした心配事について話し合おう。どうすれば最悪の事態を避けられるだろうか?被害を最小限に食い止める方法はあるだろうか?

8.期間を見極める

どれぐらいの期間が必要なプロジェクトだろうか? 3ヶ月?半年?それとも9ヶ月?

9.何を諦めるのかをはっきりさせる

プロジェクトにはいくつか操作可能な要素がある。期間、スコープ、予算、それから品質。現時点で譲れない要素はどれだろう?譲ることになるのもやむを得ない要素はどれだろう?

10.何がどれだけ必要なのか

期間はどれぐらいかかりそうか?コストは?どんなチームならプロジェクトをやり遂げられるだろうか?

インセプションデッキはこの後に続く2章を割いて説明する。まずは第4章「全体像を捉える」(p. 51)でプロジェクトの背後にある「なぜ」をじっくり考える。それから第5章「具現化させる」(p. 73)で「どうやって」を詳しく検討していく。

じゃあまず、プロジェクトの「なぜ」から考えていこう。 --このテキストは、tankobon_softcover版に関連付けられています。

登録情報

  • ASIN : B00J1XKB6K
  • 出版社 : オーム社 (2011/7/15)
  • 発売日 : 2011/7/15
  • 言語 : 日本語
  • ファイルサイズ : 41280 KB
  • Text-to-Speech(テキスト読み上げ機能) : 有効
  • X-Ray : 有効
  • Word Wise : 有効にされていません
  • 本の長さ : 458ページ
  • カスタマーレビュー:
    5つ星のうち4.4 107個の評価

カスタマーレビュー

5つ星のうち4.4
星5つ中の4.4
107 件のグローバル評価
評価はどのように計算されますか?

この商品をレビュー

他のお客様にも意見を伝えましょう

気になるトピックのレビューを読もう

上位レビュー、対象国: 日本

2020年6月21日に日本でレビュー済み
Amazonで購入
7人のお客様がこれが役に立ったと考えています
違反を報告
2020年5月20日に日本でレビュー済み
Amazonで購入
4人のお客様がこれが役に立ったと考えています
違反を報告
2019年8月17日に日本でレビュー済み
Amazonで購入
3人のお客様がこれが役に立ったと考えています
違反を報告
2016年4月7日に日本でレビュー済み
Amazonで購入
9人のお客様がこれが役に立ったと考えています
違反を報告
2021年1月19日に日本でレビュー済み
Amazonで購入
2019年5月13日に日本でレビュー済み
Amazonで購入
2人のお客様がこれが役に立ったと考えています
違反を報告
2013年1月2日に日本でレビュー済み
Amazonで購入
12人のお客様がこれが役に立ったと考えています
違反を報告
2016年5月4日に日本でレビュー済み
Amazonで購入
2人のお客様がこれが役に立ったと考えています
違反を報告
click to open popover