「アジャイルサムライ - 達人開発者への道」を読んでみた
「アジャイルサムライ - 達人開発者への道」を読んでみた
ThoughtWorks社でアジャイルコーチを務めていたJonathan Rasmusson氏の著書であり、アジャイルについて調べようとすると必ず目にする本ではないでしょうか。
私が、アジャイル開発について学ぼうと思い立ったときに、はじめて手にしたのがこの本でした。最初に読んだときから期間も経ったので、改めて読み直してまとめてみようと思います。
お目にかかれて光栄です
「アジャイル」はソフトウェア開発の進め方のひとつ
- コードを実行するのはコンピュータかもしれないが、そのコードを生み出し、保守するのは私たち人間なんだと言うこと
- フレームワークであり、心構えであり、ソフトウェアを無駄なく、早く早く届ける手法
ざっくりわかるアジャイル開発
お客さんの視点に立って考えてみると、本当に大事なことである動くソフトウェアを定期的に届けることができていなかったことがわかる。
ソフトウェアを届けるということを、お客さん側の視点に立って考えてみると、動くソフトウェアを定期的に届けることが本当に大事なことだとわかる。
価値ある成果を毎週届ける
お客さんの立場になって考えてみると、大量のドキュメントを納品するチームとテスト済みのソフトウェアを毎週届けてくれるチームどちらが信頼に足るか
そして「価値ある成果を毎週必ず届ける」ために必要なことが以下
- 大きな問題は小さくする - 小さくシンプルにして扱いやすく
- 本当に大事なことに集中して、それ以外のことは忘れる - 無駄を省いて、価値につながらないものを捨てるしかない。
- ちゃんと動くソフトウェアを届ける - こまめにテストをする習慣を
- フィードバックを求める - 定期的にお客さんにフィードバックを求める
- 必要とあらば進路を変える - 計画を乱すような現実に遭遇したら、計画を変える。現実を変えるんじゃない
-
成果責任を果たす - 成果責任を果たすためにやるべきことは以下
- 仕事の質に責任を持つ
- スケジュールを守る
- お客さんの期待をマネジメントする
- 身銭を切るかのような覚悟でお客さんの資金を扱う
※ 誰もがこの働き方を気に入るわけじゃない
アジャイルな計画づくりがうまくいく理由
先に用語の整理。
| 用語 | 意味 |
|---|---|
| マスターストーリーリスト[1] | プロジェクトのToDoリスト。顧客がプロジェクトの中で実現したい事を記述した一覧表。 |
| ユーザーストーリー | プロジェクトのToDoリストのタスク。 |
| プロダクトバックログ | マスターストーリーリストと同じ |
| フィーチャ | ソフトウェアの機能、特性や特徴、性能目標、見た目や使い勝手など、いわゆる「売り文句」などを総称する言葉。ソフトウェアを使う側の視点から記述している。そのため非機能要件も含まれる。ユーザーストーリーとして表現される。 |
| ベロシティ | １回のイテレーションで完了させられるストーリーの量 |
| スコープ | プロジェクトで行う作業の範囲と、成果物に何を含めるかを定めたもの |
アジャイル開発では、「マスターストーリーリスト」がプロジェクトのToDoリスト。
このリストに載せるのは、開発対象となるソフトウェアで顧客が実現したいと思うフィーチャ。記述レベルは、概要がわかれば十分。 リストの項目に顧客が優先順位をつけて、開発チームが見積もったら、プロジェクトの計画の土台が出来上がる。
次に、１週間か２週間のイテレーションの期間を使って、顧客が最も価値が高いと思うものから順番に、ストーリーをテスト済みの動くソフトウェアへの変換する。
それから、開発チームはベロシティを実装することで、自分たちのこなせる仕事量を把握できる。これによって、計画は信頼できるものになる。
もし、やるべきことがあまりにも多すぎるという事態に直面したら、やることを減らす。つまりスコープを柔軟にし、現実が計画にそぐわなくなったら、計画を変える。現実に適応する計画づくりはアジャイルに価値を届けるための基本である。
「完了」とは完了のことだ
アジャイル開発の文脈で「フィーチャを届ける」というのは、コードをリリース可能にするために必要なあらゆる作業を終わらせていることを意味する。
※心構えの問題で、最初からオプション機能を全部揃える、各イテレーションで完成したばかりの能を公開するしろという意味ではない。
３つの真実
ソフトウェア開発の３つの真実。これらを認め、受け入れることで、不安やストレスの多くから解放される。
- プロジェクトの開始時点にすべての要求を集めることはできない - 情報がすべて出揃っていなくても、前に進むことを厭わない
- 集めたところで、要求はどれも必ずといっていいほど変わる - 必要に応じて計画を変更しつつ、前へ進んでいく
- やるべきことはいつだって、与えられた時間と資金よりも多い - 一番優先順位の高いものからこなしていく
やり方はたった１つなんてことはないんだ！
万人が従う唯一無二なる究極のアジャイル手法は存在しない。自分の頭で考えて、プロジェクト固有の性質と、そのときの状況に合わせて適用していく必要がある。
| 手法 | 説明 |
|---|---|
| スクラム | アジャイルプロジェクトを包んで、プロジェクトマネジメントの装いを与えてくれる運営の手法 |
| エクストリーム・プログラミング | どんなアジャイルプロジェクトにも欠かせないソフトウェア開発のプラクティスを規律正しく実践する手法 |
| リーン | 能率を上げることをとことん追い求める。たゆまぬ改善を続ける企業のためのトヨタ生産方式 |
用語と言葉づかいについて少し
本書とスクラムとの用語の対応
| 本書 | スクラム |
|---|---|
| イテレーション | スプリント |
| マスターストーリーリスト | プロダクトバックログ |
| 顧客 | プロダクトオーナー |
アジャイルチームのご紹介
アジャイルなプロジェクトはどこが違うのか
アジャイルプロジェクトの３つの特徴
- きっちりと区別しない役割分担
- 継続的な開発工程
- チームで成果責任を果たす
チームをアジャイルにするためのコツ
同じ仕事場で働く
チームの生産性を劇的に改善できる方法は、全員が同じ仕事場に集まって働くことだろう
積極的に深くかかわる顧客の存在
積極的に深くかかわる顧客（Engaged Customer）は、開発チームにフィードバックをくれる存在。開発チームが必要とする助言や見識を提供し、魅力的なプロダクトを作れるようにするのは顧客の仕事だ。顧客はチームのコアメンバーである。
積極的にかかわってくれる顧客がいない。そんなときは、少しずつ信頼貯金を増やしていき、お客さんとのあいだに信頼関係を築いていくこと。
自己組織化
自己組織化とは、自らのエゴを押し出しすぎないように気をつけながら、チームで力を合わせるということ。
自己組織化を進めるためのヒント。
- 自分たちで計画を立てる
- テスト済みの動くソフトウェアを届けることに心を砕く
- 自分から動ける人を探す
要するに、チームに仕事を任せて信頼し、必要な権限を与えること。
成果責任と権限委譲
よく訓練されたアジャイルチームは自分たちがもたらす成果に対する成果責任を果たそうとする。ただし、成果責任を果たせるようになるには、権限が開発チームへと適切に委譲されていなければならない。権限が与えられていれば、チームは自発的に自分たちのやり方で物事を進めていくようになる。
もし、成果責任を果たせるかどうかに自信がないなら、実装しているソフトウェアをお客さんにデモすることが以下のようなことから効果的である。
- ソフトウェアを期待している人の存在に気づくことができる
- 一度でもデモに失敗すると、フィードバックを得る準備が整っているか気を配るようになる
デモを続けていけば、チームは自分たちの成果に確信を持てるようになるために必要な権限を要求し始めるだろう。
職能横断型チーム
職能横断型チーム（Cross-Functional Team）とは、顧客の要望に要望に最初から最後まで応えられるチームのこと。開発チームに参加するメンバーを探すなら幅広い作業をこなすことを厭わないゼネラリストが望ましい。
職能横断型チームの真骨頂は物事をこなしていくスピードにある。他部門との折衝のような余計な手続きを必要としないので、初日から成果を上げることができる。
よくある役割分担
アジャイルチームでは、チームメンバーにどの役割があてられているかは気にしない。気にかけるのは、その役割によって果たされる仕事が、チームの誰かによってちゃんとこなされるようになっているかどうか。
アジャイルな顧客
アジャイルな顧客はプロジェクトを流れていくあらゆる要求の「真実の源」。
- 何を作るかを決める
- 優先順位をつける
- スコープについて厳しい決断を下す
プロジェクト専任の顧客を、XPでは「オンサイト顧客」、スクラムでは「プロダクトオーナー」と呼ぶ。顧客をじかに開発へ巻き込めば巻き込むほど、プロダクトは良くなっていく。
開発チーム
アジャイルな開発チームは職能横断的なメンバーで構成される。
アジャイルプロジェクトでは、役割分担は実に曖昧なもの。従来型のソフトウェア開発のやり方に慣れているチームに対して説明する場合、以降に説明するような馴染みのある用語で、説明することで円滑に進むことがある。
アジャイルなアナリスト
フィーチャの実装にあたって、どうやって実現するかをしっかりと詳細まで調べ上げる。
- ユーザーストーリーを書くのを手伝う
- 詳細な分析をこなす
- 必要な調査をしっかりやり遂げる
アジャイルなプログラマ
- ユーザーストーリーを動くソフトウェアにする
- チームのみんなと見積もる
- 技術的な判断を下す
- ツール/アーキテクチャ
- 設計
- 開発プラクティス
アジャイルプログラマが実践しているプラクティス
- テストをたくさん書く
- プロジェクト進行中にも、アーキテクチャの設計と改善に継続的に取り組む
- コードベースをいつでもリリースできる状態にしておく
何を作るべきかをはっきりさせ、できるだけシンプルに実現する。
アジャイルなテスター
- ユーザーストーリーのテストを書くのを手伝う
- ストーリーが期待通りに動くことを確認する
- テストの全体像を考える
アジャイルなプロジェクトマネージャー
- いまどうなっているかを追跡する
- プロジェクトの状況を伝える
- チームの行く手を阻む障害を取り除く
アジャイルなUXデザイナ
アジャイルなUXデザイナは、使いやすく、利便性の高い、魅力的な体験を顧客に提供することに心を砕く。
その他の役割
データベース管理者、システム管理者、インフラ管理者、ネットワーク管理者などの役割も開発チームに含まれるし、他のメンバーと同じように扱われる。
アジャイルコーチとかっこいいプロジェクトマネージャーを合わせたような感じのスクラムマスターというものも存在する。
役割という名の帽子を複数かぶり分けることを、納得しているか確認する必要がある。例えば、アナリストにプログラマが直接顧客とやりとりしても構わないか確認するなど。
チームメンバーを探すコツ
- ゼネラリスト - ゼネラリストはいろんな帽子をかぶることに慣れている。
- 曖昧な状況に抵抗がない人 - アジャイルプロジェクトでは、あらかじめなにもかもがしっかりきっちり整っていることはない。変化球が投げられても慌てない人を、それを打ち返せる人を探す。
- 我を張らないチームプレイヤー - アジャイルプロジェクトがうまくいくのは、チームがまるで合奏団のように、我を張らないことに自覚的なメンバーで構成されているとき。
みんなをバスに乗せる
プロジェクトがだめになるのはなぜか
プロジェクトが新しく始まった時点では、その成功について思い描く姿は人によってそれぞれ大きく異なるもの。問題は、関係者全員でプロジェクトについて話し合うより前にプロジェクトをはじめてしまうことにある。そうならないためには、
- ゴールやビジョン、プロジェクトの状況や背景についてチームでよく話し合っておくこと。そうすれば、チームは状況に応じて、適切な判断を下せる。
- ステークホルダーに情報を提供すること。彼らにはプロジェクトを続けるかどうか決断するための材料が必要だ。
手ごわい質問をする
プロジェクトを始めるときに、手強い質問（Tough Question）をすることは重要。まだこれから始める段階であれば、終盤とは違っていろんなことを質問をする余地があって、しかも質問するのに大した手間もかからない。
手ごわい質問の例
- ご予算はどれぐらいですか？
- ２人のアナリストに３０人のプログラマという体制で何も問題ない、と仰るのでしょうか？
手ごわい質問は先に済ませる。
インセプションデッキのご紹介
インセプションデッキは、１０の手ごわい質問と課題から構成されており、いずれの課題もプロジェクトを開始する前に聞いておかないとまずい質問ばかり。
インセプションデッキは、プロジェクトを核心まで煮詰めて抽出した共通理解を、開発チームだけじゃなく、より広範囲なプロジェクト関係者全員（いわゆるプロジェクトコミュニティ）へ手軽に伝えるためのツール。
インセプションデッキの仕組み
インセプションデッキの背後にある考えは、「しかるべき人をみんな同じ部屋に集めて、プロジェクトにまつわる適切な質問をすれば、自分たちのプロジェクトに対する期待を共有して、認識を合わせることができるはずだ」。
インセプションデッキの作成に参加するのにふさわしい人物は、プロジェクトに直接関係する人物なら誰にでもその資格がある。プロジェクトを円滑に進めていくことへ具体的に貢献できる全員が該当者。その中でもステークホルダーを巻き込むことがとても重要。ステークホルダーが「それでもなお、プロジェクトをやるのか？」という極めて重要な決断を下すうえで有用な情報を提供してくれるからだ。
また、インセプションデッキの作成に要する期間は、数日から２週間程度を見込んでおけばよい。プロジェクトの状況や方針に大幅な変更があれば、そのタイミングで改訂すること。
インセプションデッキの課題一覧
-
我われはなぜここにいるのか？
何のためにチームを組むのか。顧客は誰か。プロジェクトが始まった理由を再確認する。 -
エレベーターピッチを作る
３０秒以内に２センテンスでプロジェクトをアピールするとしたら、何をつたえるか。 -
パッケージデザインを作る
雑誌のページに、自分たちのプロダクトやサービスの広告が載っているとしたら、どんな内容にするか。見た人は買いたくなるか。 -
やらないことリストを作る
やらないことをわかりやすく一覧にする。 - 「ご近所さんを探せ」
プロジェクト関係者と関係をもつ。 -
解決案を描く
概要レベルのアーキテクチャ設計図を描く。 -
夜も眠れなくなるような問題は何だろう
プロジェクトの心配事について話し合う。 -
期間を見極める
どれぐらいの期間が必要か。 -
何を諦めるのかをはっきりさせる
期間、スコープ、予算、品質のうち譲れない要素は。 -
何がどれだけ必要なのか
期間、コスト、人員がどれだけ必要か。
以降の内容については、随時更新していきます。
更新履歴
| 更新日 | 改訂内容 |
|---|---|
| 2023/4/30 | 投稿 |
| 2023/5/4 | 第２章 アジャイルチームのご紹介を追記 |
| 2023/5/5 | 第３章 みんなをバスに乗せる |
-
マスターストーリーリストは、この本独自の用語。 ↩︎
Discussion