アジャイルサムライ

第一部「アジャイル」入門

第一章ざっくりわかるアジャイル開発

本当に大事なことは動くソフトウェア(=価値ある成果)を定期的にお客さんに届けること

価値ある成果を毎週※届けるために必要な6つのこと

※最初は2週間から始めることが多い

大きな問題は小さくする
- 1週間内で成果を上げるには、大きくて厄介な問題は小さくシンプルにして扱いやすくする
本当に大事なことに集中して、それ以外のことは忘れる
- お客さん視点で考えて、本当に価値のあるものに集中する
  - ドキュメントや計画書はあくまで動くソフトウェアを補完するものであり、動くソフトウェアの方が優先度高
- 逆に価値がないものを省いて捨てる必要がある
ちゃんと動くソフトウェアを届ける
- 価値ある成果を届ける=動くソフトウェアを届ける
- 動かないのはダメなので、テストだけはしっかり行う(最重要)
フィードバックを求める
- 自分たちが正しい方向に進んでいるか定期的に確認しないと道に迷う
- お客さん視点でもプロジェクトのハンドルが握れなくなる
必要とあらば進路を変える
- 今週重要なことが翌週にはどうでもよくなることもある
- 計画を頑なに維持するのではなく、現実に即して計画を変える
成果責任を果たす
- 成果責任=お客さんの投資に対する成果をコミットメントすること
- 具体的には以下のようなこと
  - 仕事の質の責任を担保する
  - スケジュールを守る
  - お客さんの期待をマネジメントする
    - 関係者同士でプロジェクトへの期待について話し合い、互いに期待することについて合意しておく
    - 状況が変われば期待する(される)ことが変わるため、絶えずメンテナンスし続ける

誰もがこの働き方を気に入るわけじゃない

お客さんに価値ある成果を毎週届ける=常にお客さんに注目され続ける

気弱な人にはお勧めできない

プロジェクトの状況にはかくし立てがないことを好み、質の高い仕事への情熱を持っていて、価値を生み出すことを心から願うなら、アジャイルチームで働くことは、得ることが多く、楽しい経験になるはず

アジャイルなプロジェクトの計画づくり

マスターストーリーリスト(=スクラムのプロダクトバックログ)を作る
- 実質ToDoリスト
- 開発対象となるソフトウェアで顧客が実現したいと思うフィーチャ(=ユーザーストーリー)を載せる
- フィーチャは概要がわかれば十分
リストの優先順位を顧客が決める
リストを開発チームが見積もる

アジャイルなプロジェクトの進め方

イテレーションの期間で開発チームが顧客にとって最も価値の高いストーリーをソフトウェアへ変換していく
- イテレーションの期間は1,2週間くらいで
- ソフトウェアはテスト済みでちゃんと動くところまで
ベロシティを実測することで自分たちのこなせる仕事量を把握する
- ベロシティ=1回のイテレーションで完了させるストーリーの量
- この先こなせる仕事量を予測する判断材料となる
  - ベロシティの見通しが立つと、信頼できる計画が立てられる
  - できないことを顧客に約束することも防げる
やるべきことが多すぎる場合はやることを減らす
- スコープを柔軟にしておく
  - スコープ=プロジェクトで行う作業範囲と、成果物に何を含めるか定めたもの
現実が計画にそぐわなくなったら、計画を変える
- 結局できないものはできない
- 非現実的な計画が達成される奇跡を望むのではなく、顧客に隠し立てせず、現在の状況についての事実をありのまま伝える。その上で、顧客がスコープ、予算、期日の判断を下してもらう

完了の定義

完了=コードをリリース可能にするために必要なあらゆる作業を終わらせていること
- 分析
- テスト
- 設計
- コーディング
- etc
実際にイテレーション後にリリースするかは別の話
- いつでもリリースできるものを作る心構えが大事

ソフトウェア開発の3つの真実

プロジェクトの開始時点に全ての要求を集めることはできない
- 情報が全て出揃うまで前に進めないというものじゃない
集めたところで、要求はどれも必ずと言っていいほど変わる
- 変化は起きるもで、起きた変化を受け入れ、必要に応じて計画を変更しつつ前に進む
やるべきことはいつだって、与えられた時間と資金より多い
- 全てを達成することは最初から無理
- 優先順位をつけ、一番優先順位の高いものからこなしていきやれるだけやる

究極のアジャイル手法は存在しない

アジャイル開発に関する書籍や記事は、それぞれの著者たちが、自分たちの顧客と実際に試して見た経験から学んだことを共有して入るだけ
- 自分の状況に完全にマッチしたものではない
- 現場ごとで考えて、適用して行く必要がある

用語の読み替え

イテレーション=スプリント
マスターストーリーリスト=プロダクトバックログ
顧客=プロダクトオーナー

第二章アジャイルチームのご紹介

アジャイルなプロジェクトはどこが違うのか

アジャイルなソフトウェア開発プロジェクトでは役割分担がはっきりとわかれていない
- 小さなベンチャー企業のような感覚
- プロジェクトの成功に寄与することならなんだって協力する
分析、設計、実装、テストといった開発工程がどれも、途切れることなく連続的な取り組みになる
- 区切りとしての開発工程はない
チームが一丸となって成果責任を果たすという考え方をとても重視する
- チームが品質に責任を持つ
  - 担当が何かは関係ない

チームをアジャイルにするためのコツ

同じ仕事場で働く
- 質問のレスが早い
- 信頼関係が築きやすい
- 物理的に分散している場合は、最初にプロジェクトメンバーが全員集められるだけの旅費を予算として確保する
  - 最初の段階で共に過ごすことで、まとまった高いパフォーマンスを発揮できるチームのに大きく貢献する
積極的に深く関わる顧客の存在(Engaged Customer)
- 積極的に深く関わる顧客=デモを見にきて、質問に答え、開発チームにフィードバックしてくれる存在
  - 開発チームが必要とする助言や見識を提供し、魅力的なプロダクトを作れるようにするのは顧客の仕事

積極的に深く関わる顧客を作るには

「これから2週間で何かしらお客様の課題を解決します」宣言を顧客にする
2週間後のミーティングでどうやって問題を完全解決したのかを報告
以下繰り返し
- 顧客からの信頼貯金

自己組織化されたチームが望ましい

自己組織化=自らのエゴを押し出しすぎないように気をつけながら、チームで力を合わせること
各自がチームの一員としてどう振る舞えば最善の成果を顧客に届けられるかを考え抜く

自己組織化するには

自分たちで計画を立てる。自分たいtのプロジェクトなんだという当事者意識を持つ
肩書きや役割について気にせず、動くソフトウェアを提供し続けることだけに集中する
自分から動ける人を探す。指示待ち人間はアジャイルチームにはふさわしくない
成果責任と権限委譲
- 実際に顧客の前でソフトウェアのデモをするだけで自分たちの果たすべき成果責任に対してもっと自覚的になれる

職能横断型チームが望ましい

職能横断型チーム=顧客の要望に最初から最後まで答えられる開発チーム
- 開発チームに適切なスキルと専門知識が備わっていて、顧客が必要とするあらゆるフィーチャをきちんと届けられる必要がある
メンバーはゼネラリストが望ましい
- スペシャリストは開発チームに備わっていないスキルが必要な事態に発生した場合
職能横断型チームには他部門との折衝のような余計な手続きが必要なく、仕事が早い

アジャイルチームにおけるよくある役割分担

基本は顧客と開発チーム
プログラマやテスター、アナリストの役割を開発チームメンバーの誰が担当するかは気にしない、その役割における仕事がチームの誰かによってちゃんとこなされるようになっているかが大事

アジャイルチームが果たすべき役割

アジャイルな顧客
- プロジェクトの解決すべき問題領域の専門家
- ソフトウェアの目的や見た目、動作などを心から気にかける人物
- 開発チームに確固たる指針を与え、質問に答え、フィードバックしてくれる存在
- 要求の優先順位づけ、期日決定
  - 顧客の独断で決めるのではなく、開発チームと共同で決める
- 何を作らないかを決める人物
- スクラムでのプロダクトオーナー
アジャイルなアナリスト
- フィーチャの実装に当たって、実現のための詳細を調べ上げる役割
- 顧客と密接に話し合い、顧客の機体を明らかにする
- ユーザーストーリーを書くのを手伝う
- モックアップやプロトタイプの作成
- あらゆるものを使い顧客との意思疎通を図る
アジャイルなプログラマ
- 質の高いソフトウェアを生み出すことに心血をそそぐプロフェッショナル
- 質の高いリリース可能なソフトウェアを生み出すためにテストをたくさん書く
- プロジェクト進行中であっても、アーキテクチャの設計と改善に積極的に取り組む
- コードベースをいつでもリリースできる状態にしておく
- 本番環境へのコードのデプロイも自分で当たり前のようにできる
アジャイルなテスター
- ビルドできることの確認だけでなく、ソフトウェアがちゃんと動くことを確認する役割
- プロジェクトの早い段階から参加できると、ユーザーストーリーの実現ができて入ることを確認するためのテストが定義でき、コードが書かれたらすぐにテストができる
- プロジェクト全体としてのテストにも関心を寄せる
  - 負荷テスト、スケーラビリティ等
アジャイルなプロジェクトマネージャ
- 開発チームの成功を阻む障害を取り除く役割
- 上位のプロジェクト関係者(顧客？)に開発チームに期待できることをマネジメントする
  - できないことはできないと分からせる
- ステークホルダへの状況の報告
- 社内の人間関係の円滑化
- 開発チームに「何をすべきか」の指令は出さない
  - 自己組織化されて入るため指令が必要ない
  - マネージャー不在でもプロジェクトに支障がないのが望ましい
アジャイルなUXデザイナ
- 使いやすく、利便性の高い、魅力的な体験を顧客に提供することに心を砕く役割
- 顧客に提供する価値に注目し、素早いフィードバックを得ながら最高のプロダクトを作る役割
その他
- アジャイルコーチ=スクラムマスター
  - アジャイル開発の原則や考え方をチームに説明し、布教する役割
  - 練度の高いチームなら不要
- アジャイルなチームを作る前にメンバーに複数の役割を担う必要があることについて納得しているかの確認が必要

チームメンバーを探すコツ

ゼネラリスト
- 色々な役割をこなすことに慣れている
曖昧な状況に抵抗がない人
- アジャイルプロジェクトでは、何もかもがきっちり整っていることはない
我を張らないチームプレイヤー
- 自分の縄張りに固執しない人