
無料のKindleアプリをダウンロードして、スマートフォン、タブレット、またはコンピューターで今すぐKindle本を読むことができます。Kindleデバイスは必要ありません 。詳細はこちら
Kindle Cloud Readerを使い、ブラウザですぐに読むことができます。
携帯電話のカメラを使用する - 以下のコードをスキャンし、Kindleアプリをダウンロードしてください。
アジャイルサムライ−達人開発者への道− 単行本(ソフトカバー) – 2011/7/16
Jonathan Rasmusson (著) 著者の作品一覧、著者略歴や口コミなどをご覧いただけます この著者の 検索結果 を表示 |
西村 直人 (監訳) 著者の作品一覧、著者略歴や口コミなどをご覧いただけます この著者の 検索結果 を表示 |
角谷 信太郎 (監訳) 著者の作品一覧、著者略歴や口コミなどをご覧いただけます この著者の 検索結果 を表示 |
近藤 修平 (翻訳) 著者の作品一覧、著者略歴や口コミなどをご覧いただけます この著者の 検索結果 を表示 |
購入を強化する
動くソフトウェアを素早く開発するための「アジャイルソフトウェア開発手法」を、実際に導入するにはどうすればよいかを、豊富な図を使い親しみやすい言葉で解説しています。経験豊かな著者が具体的なノウハウをまとめた本書は、アジャイル開発を導入したいと考えている組織や人のための「現場のマニュアル」として役立ってくれることでしょう。
- 本の長さ288ページ
- 言語日本語
- 出版社オーム社
- 発売日2011/7/16
- 寸法15 x 1.9 x 21 cm
- ISBN-104274068560
- ISBN-13978-4274068560
この商品を見た後に買っているのは?
商品の説明
著者からのコメント
君がこの本を手に取ったことに祝福を。おめでとう。というのも、君にはすごく大事な2つのことが備わってるってことだからだ。
1. 君は学ぶことが心から好きだ。
2. 君はソフトウェアのことを大切に思っている。
このどちらもが大切なんだ。君が学びたいという気持ちを抱かなければ、私との旅がこうして幕を開けようとすることもなかった。君がソフトウェアのことなんて気にしない人物だったら、私たちの世界は今よりも暮らしづらいものになっていただろう。
なぜなら世界はソフトウェアを必要としてるわけだから。世界はソフトウェアを作ることを手助けする人を必要としてるんだ。そう、君みたいなね。私たちが、君みたいに才気煥発で、頭が良くて、思慮深い、情熱にあふれた人達をもっと惹きつけられるようになるには、もっと成果をあげるソフトウェアの作り方が必要なんだ。わくわくするような、毎朝目を覚ますたび、今日一日またソフトウェアを作ることが楽しみで仕方がないようなやつがね。
そのために私は本書を書いた。もっとうまくソフトウェアを届けるやり方を探し求め、分かちあい、見出していこう(でもあんまり深刻に受け止めすぎないで。楽しみながらやっていこう)。
君の探してることが、本書を読んで見つけられることを願っている。もし見つからなかったとしても、探し続けることを止めないでほしい。
2011年4月26日
ジョナサン・ラスマセン
(日本語版序文より)
----
本書の特長
タイトルに加えて、ジョナサン独特の筆致と妙な味わいの挿絵に幻惑された読者がいるかもしれませんが、本書は見た目によらず硬派な1冊です。監訳者たちが本書の価値と特長だと捉えている点を、簡単にまとめておきます。1)開発者------もっといえばプログラマ向けに焦点を合わせていること、2)アジャイルな開発の進め方をひと通りすべてカバーしていること、3)よく練られた5部15章の構成になっていること、4)特定の方法論を前提としていないこと、5)ユーモアと楽しむ気持ちを忘れていないこと。これだけの内容を300ページ以内に収めたジョナサンたち原著執筆チームの力量には「お見事!」と喝采を送りたいです。
...
よく誤解されることなのですが、アジャイル開発は腕自慢の「優秀な」プログラマでなければ実践できない、というものではありません。たとえば、監訳者2人はアジャイル開発を実践していますが、プログラマとしてはいたって普通です。ですから、顧客にちゃんと価値を届けるためには、エンジニアリングプラクティスという先人の知恵の集大成を「問答無用」で「規律正しく実践」しなければなりません。それに、普通のプログラマは独りで実現できることもたかが知れています。だからチームを組むのです。
本書の冒頭でジョナサンは宣言します。「コードを実行するのはコンピュータかもしれないが、そのコードを生み出し、保守するのは私たち人間なんだ」と。私たちプログラマの多くは、普通のプログラマです(たくさんいるから「普通」なのです)。そんな私たちがチームを組んで成果をあげるには、物事をうまく運ぶための仕組みやプラクティスが必要です。だからといって、既存のアジャイル開発手法の提示するやり方を形だけなぞってもなかなかうまくいきません。
スケジュールを2週間単位で分割したMicrosoft Execlのシートを作ればイテレーションなのか?毎朝集まればデイリースタンドアップなのか?テストを先に書けばテスト駆動開発なのか?------「そうじゃないんだ」とばかりに、ジョナサンは「12の原則」を、字面だけでなく真に理解して体現した「圧倒的なアジャイルプロジェクトの姿」を私たちに示してくれます。10.6「デイリースタンドアップ」(p. 213)などはその好例です(毎朝、天地神明に誓ってから仕事をしてますか?ただ突っ立ってボソボソしゃべってるような開発者はいねがー?)。
私たちのソフトウェア開発の現場をどうにかできるのは私たちだけです。しかも、一つとして同じ現場はありません。だから「どんな書籍も手法も、君が必要とするありとあらゆるものを用意することなんてできない」のです。私たちは「自分の頭で考えるのをやめちゃだめ」なのです。
(「監訳者あとがき」より)
内容(「BOOK」データベースより)
著者について
著者
Jonathan Rasmusson(ジョナサン・ラスマセン)
ジョナサン・ラスマセンは実務経験豊かな起業家であり、前職ではThoughtWorks 社のアジャイルコーチを務めていた。ジョナサンは世界をまたにかけたコンサルディングを行っており、一丸となって楽しみながら働ける現場の実現に尽力している。仕事以外では、息子のホッケーチームのコーチや、カナダの厳しい寒さのなかでのサイクリングを楽しんでいる。そうした多忙な暮らしの合間をぬって、自身のブログを通じて、自分自身のアジャイル開発の経験を読者と分かちあう活動を続けている。
監訳者
西村直人(にしむらなおと)
株式会社永和システムマネジメントサービスプロバイディング事業部アジャイルコーチ。スクラム道プロダクトオーナー。もっと仕事をアジャイルにしたいという思いを抑え切れず、2005 年に現職へ転職。そこから自分のチームや現場を軸にアジャイルなソフトウェア開発を実践してきた。2009 年に認定スクラムマスターの取得を機に、アジャイルコーチという肩書でお客様の組織や現場をアジャイルにするお手伝いをする事に情熱を傾けている。日本でもアジャイルなソフトウェア開発がもっと自然な形で定着してほしいと考え、ほんの少しでも力になればという思いから講演やコミュニティ運営なども行っている。心のマスター・センセイは、僕がこれまで関わってきた人達。
角谷信太郎(かくたにしんたろう)
株式会社永和システムマネジメントサービスプロバイディング事業部コミュニティマネージャ。日本Ruby の会理事。Asakusa.rb メンバー。20 世紀最後の年に『XP エクストリーム・プログラミング入門』と『達人プログラマー』という白と黒の書籍を読んでしまったときの思いを3 年余かけてこじらせたあげく、現職に転職。2004 年7 月からアジャイルなソフトウェア開発を実践。以来、エクストリーム・プログラミングの理念である「新たな社会構造」のために自分がやれることをやっている。心のマスター・センセイはJim Coplien。翻訳・監訳書は『アジャイルな見積りと計画づくり』『インターフェイス指向設計』『アジャイルプラクティス』『Java からRuby へ』。他にも寄稿や翻訳記事、講演など多数。
訳者
近藤修平(こんどうしゅうへい)
株式会社永和システムマネジメントサービスプロバイディング事業部所属。認定スクラムマスター。オブジェクト指向プログラミングとアジャイル開発手法に出会い、より楽しくより価値のあるソフトウェア開発を求めて2005 年に現職に転職し、プログラマ・現場リーダーとしてアジャイルなソフトウェア開発の研鑽に明け暮れている。心のマスター・センセイはトム・デマルコ。ソフトウェアは人がつくり、人が使い、人が育てるという観点から、最近は人とソフトウェアとのインターフェイスに新しい挑戦の場を求めている。著書には『iOS プログラミング逆引きリファレンス108』『サンプルプログラムでマスターするiPhone SDK プログラミング実践ガイド』。
角掛拓未(つのかけたくみ)
株式会社永和システムマネジメントサービスプロバイディング事業部所属。つかう人が喜ぶのはもちろん、つくる人も楽しむプロジェクトの「あり方」と「やり方」を模索している。心のマスター・センセイはこれから探していく。自分だからこそ生み出せる価値は何かをとことん考え形にしていきたいと強く思っている。哲学に「学習は楽しくあるべきだ」を掲げ、手始めに英単語を語源で楽しく効率よく学習するサービスD.D.(ディーツー), D.D. Bot(@ddbot)を公開している。これからの展開にも乞うご期待。
著者略歴 (「BOOK著者紹介情報」より)
実務経験豊かな起業家であり、前職ではThoughtWorks社のアジャイルコーチを務めていた。世界をまたにかけたコンサルティングを行っており、一丸となって楽しみながら働ける現場の実現に尽力している
西村/直人
株式会社永和システムマネジメントサービスプロバイディング事業部アジャイルコーチ。スクラム道プロダクトオーナー
角谷/信太郎
株式会社永和システムマネジメントサービスプロバイディング事業部コミュニティマネージャ。日本Rubyの会理事。Asakusa.rbメンバー
近藤/修平
株式会社永和システムマネジメントサービスプロバイディング事業部所属。認定スクラムマスター
角掛/拓未
株式会社永和システムマネジメントサービスプロバイディング事業部所属(本データはこの書籍が刊行された当時に掲載されていたものです)
About this Title
みんなをバスに乗せる
スタートを切る前からだめになってしまうプロジェクトは実に多い。主な理由は次の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)で「どうやって」を詳しく検討していく。
じゃあまず、プロジェクトの「なぜ」から考えていこう。
Kindle をお持ちでない場合、こちらから購入いただけます。 Kindle 無料アプリのダウンロードはこちら。
登録情報
- 出版社 : オーム社 (2011/7/16)
- 発売日 : 2011/7/16
- 言語 : 日本語
- 単行本(ソフトカバー) : 288ページ
- ISBN-10 : 4274068560
- ISBN-13 : 978-4274068560
- 寸法 : 15 x 1.9 x 21 cm
- Amazon 売れ筋ランキング: - 10,376位本 (の売れ筋ランキングを見る本)
- - 79位ソフトウェア開発・言語
- カスタマーレビュー:
著者について
1974年愛知県に生まれる。
主にiOSアプリやWebアプリケーションのソフトウェア開発に従事する。
オブジェクト指向技術とアジャイルな開発手法で楽しく開発をすることをモットーに日々鍛錬を重ねている。
著者の本をもっと発見したり、よく似た著者を見つけたり、著者のブログを読んだりしましょう
カスタマーレビュー
上位レビュー、対象国: 日本
レビューのフィルタリング中に問題が発生しました。後でもう一度試してください。
ベンダー(元請け) -- 顧客(情報システム部、人事部)
二次請け アウトソーシング先企業(エンドユーザー)
三次請け
四次請け(自分)
といった形で、この人事システムを使っているのは、顧客が事務をアウトソーシングしている企業ということだった。
法改正対応で、ほぼ引き継ぎなしでやることになったのだが、元請けは仕様を知らず(二次、三次請けはただのトンネル)、顧客の情シスもわからず、人事部門も「うちは使ってないからわからない」ということだが、アウトソーシング先の企業を打ち合わせに呼ぶのは契約外で難しい、といった難題にぶちあたったことがあった。
(結局、つてを頼ってアウトソーシング先の担当者の電話番号を入手した。)
*
本書の最初のほうに「チームをアジャイルにするためのコツ」として「同じ仕事場で働く」「積極的に深くかかわる顧客の存在」とあって、そもそも会えない客がいたなと笑いながらつい思い出したのだが、まあこの本はシステム開発におけるコミュニケーションをうまく行かせるための本だと感じた。さすがに10年売れているロングセラーだけあって面白い部分も多いが、個人的には文体が合わなかった。
日本ではWeb系企業の内製で使われることが多かったが、IPAが「準委任契約を前提として」のアジャイル契約書類型を出したりで、エンプラ向けでも今後も広がっていくと思う。アジャイル(準委任)が良いというより、ウォーターフォール(請負)の欠点が大きいからだが、その際の課題は「消極的で関わりたがらない顧客の存在」だろうか。
まあ、ウォーターフォール型でも朝会(デイリースタンドアップ)や課題管理表(ユーザーストーリー、プロダクトバックログ)でのトリアージ(トレードオフスライダー?)はやってるとこも多いと思うし、この本のエッセンスを取り入れることは出来ると思う。
しかし、この本でも言ってるが、アジャイルも「銀の弾丸」ではないわけだが、「アジャイルでエンジニアが生き生き働くようになった」「自律的に楽しんで仕事するように」とか「アジャイルはワクワクする」とか、意識高い系の道具になってる部分はげんなりだ。経営者向けメディアで夢物語として取り上げられているのも危うい。普通の人が普通に仕事を進めるやり方として日本で定着することを願いたい。
プログラムの書き方やアーキテクチャの組み上げ方などは教わることも多いし、Webにたくさん転がっていますが、そもそもの土台になる「仕事の進め方」を学べる機会ってそう多くないように思えます(少なくとも自分の狭い観測範囲では)。
仕事を進めていると当たり前に行うゴールの設定も、いきなり遠くのゴールの的に矢を射るのではなく、途中途中に実現可能なチェックポイントを設定し、一つ一つ達成していく。その過程でゴールへの道筋が間違っていればその都度修正するべきだ。なんてことが書かれています。言われれば当たり前で普段からそうしているつもりでも、改めて意識しなくては、と気付かされます。
ただ、後半の章になると具体的なアジャイル開発の手法の説明になってくるので、読んでもいいしさらっと眺めるだけにしておくのもいいかと思います。
そんな感じで、システムエンジニアなら読んでおいて損はない本です。
個人的に気に入っているのは「(スケジュールが足りないなどの理由で)できないことは、結局のところできないんだ」というところです。できないことを無理やりスケジュールに詰め込んでデスマーチへ…なんてことが未だに起きる業界で、できないことはできない、とはっきり認識し、それを解決するために建設的なアプローチをする、というのは業界全体がそうあるべきだと思わせてくれます。
更に難しくなっている本が多いです。
Header Firstシリーズのように絵が多く、要点がまとまっていれば
サクサク読み進められますがアジャイル開発で要点がまとまっており
メモやノートを取らずとも頭に残る書籍はこれぐらいだと思います。
実業務に反映出来ているかは謎ですが頑張って読み進めても
頭に残らず読んだ気になるタイプの本ではなく
調度良いバランスできちんと頭に残る良い本です。