1. ざっくりわかるアジャイル開発

  • 顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供する
  • 動くソフトウェアこそが最も重要な進捗の尺度

2. アジャイルチームのご紹介

アジャイルの特徴

  • 役割分担がはっきり分かれていない
  • 分析・設計・実装・テストが途切れず連続的に行われる（開発工程のそれぞれが密接に関係しながら進められる）
  • チームが一丸となって説明責任を果たす

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

  • 同じ職場で働く
  • 積極的に関わる顧客の存在

ビジネス側の人と開発者は、プロジェクトを通して一緒に働かなくてはならない

  • 自己組織化（自らのエゴを出しすぎないようにしながらチームで力を合わせる）
    • 自分たちで計画を立て、当事者意識を持つ
    • 役割や肩書きを気にしない
    • 自分から動ける人を探す（指示待ちする人はふさわしくない）

最良のアーキテクチャ・設計・要求は自己組織的なチームから生まれる

  • 成果責任と権限委譲（成果に責任を持つ、またその実現のために自分たちで判断・実行できる権限を持つ）

意欲に満ちた人を集めてプロジェクトを構成する。環境と支援を与え、仕事が無事終わるまで彼らを信用する

  • 職能横断型チーム（顧客の要望に最初から最後まで答えられる開発チーム）

→ 他チームとの折衝のような余計な作業が必要ない

よくある役割分担

大きく分けて2つの役割。もっと細かい役割もあるが、あらかじめ分担を決めるのではなく、メンバーの誰が担当するかをその都度決める。

  • 顧客（＝プロダクトオーナー）
    • 何を作るか決める
    • 優先順位をつける
    • 時間・コストを考慮して何を作らないか決める
  • 開発チーム
    • アナリスト 顧客と密接に協力して、顧客が本当に必要とするものを明らかにする
    • プログラマ
      • テストをたくさん書く
      • リファクタリングに取り組む
      • CI を意識する
    • テスター 何もかもをテストする
    • プロジェクトマネージャ
      • 今どうなっているかを追跡する
      • ステークホルダーに対し、プロジェクトの状況を伝える
      • チームの行く手を阻む障害を取り除く
    • UX デザイナー
      • 使いやすく利便性の高い魅力的な体験を顧客に提供

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

  • ゼネラリスト
  • 曖昧な状況（顧客の要求が出揃っていなかったり、計画がしょっちゅう変わったり）に抵抗がない人
  • 我を張らないチームプレイヤー

3. みんなをバスに乗せる

プロジェクトがダメになるのはなぜか

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

  • ゴールやビジョン、プロジェクトの背景について関係者で話し合って認識を合わせる。
  • プロジェクトを続けるかどうかの判断材料として、ステークホルダーに情報を提供する。

手強い質問（Tough Question）

プロジェクトを開始するときに「質問しにくいこと」を質問しておく。

  • チームはどのくらい経験を積んでいる？
  • 予算は？
  • 本当にこの人数で大丈夫？
  • etc.

インセプションデッキ

10の Tough Question で構成される。プロジェクトの核心まで煮詰めて抽出した共通理解を、広範囲のプロジェクト関係者全員に手軽に伝えるためのツール。

課題の例（自分たちに合わせて改変する）：

  1. 我々はなぜここにいるのか
    • このプロジェクトが始まった理由は？顧客は誰？
  2. エレベーターピッチを作る
    • 30秒以内に2文でプロジェクトをアピールするなら？
  3. パッケージデザインを作る
    • プロダクト・サービスの広告を作るならどんな内容がいいか？そのプロダクトを買いたくなるだろうか？
  4. やらないことリストを作る
  5. 「ご近所さん」を探す
    • 広い範囲のプロジェクト関係者を把握
  6. 解決案を描く
    • 認識が合っていることを確認するために、概要レベルのアーキテクチャ設計図を描く
  7. 夜も眠れなくなるような問題は何か？
    • 重大な問題・心配事について話し合う
  8. 期間を見極める
  9. 何を諦めるのかをはっきりさせる
    • 期間・スコープ・予算・品質のうち、譲れない要素は？譲るのもやむを得ない要素は？
  10. 何がどれだけ必要なのか
    • 必要な期間・コストは？どんなチームならプロジェクトをやり遂げられるか？

4. 全体像を捉える

我々はなぜここにいるのか

  • 現場で自分自身が確かめる（顧客の立場に立ってみる）
  • プロジェクトの目標・目的を簡潔に表現する

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

  • テンプレート
    • [潜在的なニーズを満たしたり課題を解決したり]したい
    • [対象顧客]向けに作られた
    • [プロダクト名]というプロダクトは、
    • [プロダクトのカテゴリー]です。
    • これは[重要な利点・対価に見合う説得力のある理由]ができ、
    • [代替手段の最有力候補]とは違って、
    • [差別化の決定的な特徴]が備わっている。

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

フィーチャそのものではなく、フィーチャが持つ効能をアピールする。

例） x: 245馬力エンジン o: 高速道路でも十分な速度で走れる

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

仕事を「やる」「やらない」（「後で決める」）に分けることで、スコープの境界が定まる。

  • 顧客がプロジェクトに期待できることがわかりやすくなる
  • 開発チームが本当に重要なことにだけ集中できるようになる

ご近所さんを探せ

  • プロジェクトのコミュニティは考えているよりも常に大きい
  • 助けを求めたくなるより前から、コミュニティと信頼関係を築く

5. 具現化させる

解決案を描く

アーキテクチャなどの図を目に見えるように描くことで、

  • 技術的な課題がわかりやすくなる
  • 顧客に対して図を示すことで
    • 顧客がプロダクトに抱く期待をマネジメントできる
    • プロジェクトの境界とスコープを目で見て確認できる
    • リスクを伝えられる

チームを選ぶことはアーキテクチャを選ぶこと 人は自分の得意分野で解決策を考えがち。データベースに強い人が多いチームだと SQL で何でも対応しようとしたり。

→ チームを選んだ時点で、アーキテクチャ設計の第一歩を踏み出している。

ここでやるべきことは、

  1. システムをどのように構築しようとしているのか図で伝える
  2. どこにリスクがあるかを明確にする
  3. みんながその解決策に同意しているかを確認する

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

話し合うべきリスク：

  • チームが同じ仕事場にいない
  • 顧客を巻き込めない
  • 自分の開発環境をコントロールできない
  • その他、プロジェクト成功のために必要だと思われるものが何かしら揃っていない

また、取り出したリスクを「取り組むべきリスク」「どうしようもないリスク・無価値なリスク」に分類する。

こういったリスクについて話し合うことで、

  • プロジェクトの課題を早い段階で明らかにできる
  • 単純に気持ちがスッキリする

期間を見極める

  • 小さく考える
    • 期間が長くなるほどプロジェクト失敗のリスクは増加する。「この機能も追加してよ」などの要求がいつまでも続き、コストがかさんで崩壊する。
      → プロジェクトの開発サイクルの期間は、できるだけ小さな、制御できる単位で設定する。
  • プロジェクトの長さへの期待をマネジメントする
    • プロジェクト開始時点でステークホルダーに示す開発期間の見通しは、「最善を尽くしたあてずっぽう」にすぎない。採れる選択肢には以下の2つがある。
      • 期日を軸にして、そこに収まるようにフィーチャを調整する
      • 中核をなすフィーチャを届けることにはコミットメント（確約）するが、期日については幅を持たせる。

ここで提供する計画はコミットメントではなく、あくまでもざっくりとした予測だということを顧客に理解してもらうことが大事。

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

  • プロジェクトに大きく関わる「荒ぶる四天王」
    • 時間
    • 予算
    • 品質
    • スコープ

筆者は、どれか一つならスコープを動かし、他は固定することを推奨している。

  • トレードオフ・スライダー
    • 時間・予算・品質・スコープの相対的な優先度を可視化する。顧客に優先度を設定してもらうことで、顧客の考えを把握することができる。
時間　　min o--*--*--* max
予算　　min *--o--*--* max
品質　　min *--*--*--o max
スコープ min *--*--o--* max
  • プロジェクトの命運を左右する「捉えどころのないもの（The Intangibles）」
    • ゲームの楽しさやシステム運用の大変さなど、一定の枠に収まらないものも重要。こういった項目のためのツマミもトレードオフ・スライダーに用意しておくと良い。

何がどれだけ必要なのか

  • プロジェクト参加者の中で重要な役割「顧客」
    • 開発者やテスター、アナリストの役割は理解しやすいが、顧客の役割についてはそうではない。
      → お客さんに「プロジェクトに参加する覚悟」があるかを確かめる必要 - プロジェクトのために質問を受けたり会議をしたりする時間が取れるか？ - プロジェクトにまつわる決定を下せるか？
  • 最終判断を下すのは誰か？
    • ステークホルダーが複数いる場合、開発チームに語りかける声は1つにしておかなければ、現場が混乱する。
  • コストがどれくらいかを見積もる
    • 一番お金がかかるのは人間。1人あたりの単位時間のコスト x 人数 x 期間で大雑把に予算が見積もれる。

6. ユーザーストーリーを集める

文書化の難しさ

文書化に頼りすぎることの弊害：

  • 変化に対処できない
  • 顧客の欲しいものに合わせるのではなく、仕様に合わせて作ることに
  • 下手な推測や誤った前提を招き寄せる
  • 多くの時間を無駄にする
  • 文書は誤解を招きやすい

情報を伝える最も効率的・効果的な方法は、面と向かって話をすること

そこでユーザーストーリーですよ

ユーザーストーリー：顧客がソフトウェアで実現したいと思っているフィーチャを簡潔に記述したもの。

  • x：フィーチャのありとあらゆる詳細を書き出す
  • o：フィーチャの本質を捉えるキーワードを書き留めておく

ユーザーストーリー = 会話の約束。しかるべき時が来たら詳細を検討するが、それは本当に必要だという確信を持てるようになってから。

よく書けているユーザーストーリーとは

  • Valuable: 価値がある（ビジネスの観点から評価できる。顧客にわかる言葉で説明されている）
    • ex) x「データベースにコネクションプーリングを導入する」o「10秒かかっているページの読み込みを2秒に縮める」
  • Independent: 他のユーザーストーリーと独立している（トレードオフが判断しやすい）
  • Negotiable: 交渉の余地がある（ストーリーの実現手段に自由度があり、融通がきく）
  • Testable: テストできる
  • Small, Estimatable: 小さい、見積もれる（1〜5日で完了できるサイズにして、完了までの時間を見積もれるように）

以上の頭文字をとってINVESTと呼ぶ。

※ INVEST なストーリーに invest（投資）しようということ

ユーザーストーリーのテンプレート：

  • **<ユーザの種類>として**
  • **<達成したいゴール>をしたい**
  • **なぜなら、<理由>だからだ**

→ 誰のために何をしたいのか、なぜそうしたいのか。

ストーリー収集ワークショップを開く

  1. 大きくて見通しの良い部屋を用意する
    • 図をたくさん書いたり、カードを並べることができる環境
  2. 図をたくさん描く
    • 広く浅くフィーチャを捉えるのに適する
  3. ユーザーストーリーをたくさん描く
    • 1〜5日程度で実装できる、小さくて具体的なエンドツーエンドのストーリーになるよう心がける（もっと大きなストーリーはエピックと呼ばれ、本当に必要か確信は持てないような機能をざっくりくくり出すのに使う）
  4. その他もろもろをブレインストーミング
    • 負荷テストや書類仕事、運用手順書やトレーニング教材の準備など、プロジェクトに必要なものを全てカードに書き出しておく。
  5. リストを磨き上げる
    • もれなくダブりなくストーリーを集められているか？ ストーリー一覧は顧客にとってわかりやすい ToDo リストになっているか？

7. 見積もり：当てずっぽうの奥義

プロジェクトの初期見積もり = あてずっぽう

概算見積もりの問題

不確実性コーン（スティーブ・マコネル）

プロジェクト初期段階では最大4倍もの見積もり誤差がある、とする図。

→ 前もって正確に見積もるのは不可能なので、与えられた期間・リソースでそのプロジェクトをやり遂げられるのかを判断できるようにする。

相対サイズで見積もる

数あるストーリーのうちいくつかを工数の基準として、他のタスクの工数を相対的に見積もる。

ポイントで見積もる

「何営業日かかるか」などではなく、意味のない「ポイント」などを単位とする。

  • 見積もりとは当てずっぽうであることを肝に銘じることができる
  • 見積もりとは純粋にオキサを図るものだと考えることができる
  • 手早く気軽にシンプルに見積もれる

見積もり技法

  • 三角測量
    • ストーリーの中から「S」「M」「L」の代表を選び、他のストーリーをいずれかに分類していく
  • プランニングポーカー

これまでに経験がなく、サイズの検討がつかないとき：

スパイク（ストーリーを見積もれる程度に行う様々な調査）を実施する

8. アジャイルな計画づくり：現実と向き合う

固定された計画の問題

プロジェクトの最中には様々な想定外の事態が起こる。

  • 主力開発車がプロジェクトから外れる
  • 思っていたよりも開発速度が上がらない
  • 顧客からの要望が追加される
  • 期限が短縮される

想定外の事態をを前提とした計画を立てる必要がある。

  • 顧客にとって価値のある成果を届けられる計画
  • わかりやすくありのままを伝える、誠実な計画
  • 約束したことを守り続けられる計画
  • 必要に応じて変更できる計画

アジャイルな計画づくり

プロジェクトにどのくらいのイテレーション（1〜2週間の、アジャイル開発の1サイクル）が必要かを見積もるには、全作業量をベロシティ（開発速度）で割れば良い。

イテレーション数 = 作業量合計 / チームの予想ベロシティ

1イテレーションで10ポイントの作業がこなせるなら、100ポイントのプロジェクトは10イテレーションでこなせる計算になる。

※ このとき、最初の計画を厳密なコミットメントとして扱うと、プロジェクトは死んだも同然

→ 最初に立てた計画にいつまでもこだわらず、計画を変更する

スコープを柔軟に

計画を変更する場合、通常はスコープを調整して対処する。このためには、顧客に「新しいストーリーを追加するときは、必ずどれか既存のストーリーをマスターストーリーリストから削る」と約束してもらう。

→ やれることには限度がある。

最初の計画づくり