アジャイル開発のやり方を簡潔にまとめてみた
自分用にアジャイル開発のやり方をまとめました。
アジャイル開発には三つのコンセプトがあります。
- 「チーム」
- 「インクリメント（少しずつ作る）」
- 「イテレーション（反復的に作る）」
の三つです。これらについて、解説していきます。
チーム
職能横断的、つまり複数の専門性を保有し、ソフトウェアを完成させられる能力を有したチームが求められる。
チームを効果的に機能させるため、
- フォーメーション
- チームの共通理解を育む
- チームの活動する場を整える
という三つが重要になる。それぞれについて説明する。
フォーメーション
スキル・メンバーマッピングにより、それぞれのメンバーにどのようなことができるのかを洗い出す。
そしてそれぞれのメンバーがどのように機能するかを決定する。
チームの共通理解を育む
自分たちが果たすべきミッションや守るべき約束事についての理解を深める。プロジェクト、プロダクトの目的や目標、前提や制約を把握しておくこと。またチーム自体への理解（メンバーの考え方や得意技を深めておくこと。こうしたチーム共通の理解を深めていく3つの方法がある）
インセプションデッキ
暗黙的な期待を明らかにして適切に調整をおこなう行為を「期待マネジメント」という。期待マネジメントを行うためのワークショップがインセプションデッキである。重要なのは十個のドキュメントの作成ではなく、これらの問いにチームや関係者全員で向き合い、理解を揃えていく過程が重要なのである。
インセプションデッキの具体的方法：
Whyを明らかにする（①われわれはなぜここにいるのか[プロジェクトやプロダクトで達成したい目的、目標をあげる] ②エレベーターピッチ[プロダクトの特徴を端的に言語化する（解決する問題・対象顧客・重要な利点・代替手段・差別化要因など）]③パッケージデザイン[顧客へ伝えたいメッセージとビジュアルイメージ]④ご近所さんをさがせ[プロジェクト関係者の図示化]）
WhyとHow共通（⑤やらないことリスト）
Howを明らかにする（⑥夜も眠れない問題[プロジェクトのリスクをあげる]⑦トレードオフスライダー[品質・予算・リリース日など、どの基準を優先するか]⑧技術的な解決策[利用する技術やアーキテクチャの図示化]⑨期間を決める⑩何がどれだけ必要か[費用・期間・チームなど必要なリソースの定量化]）
ドラッカー風エクササイズ
チーム内部の期待を明らかにする「ドラッカー風エクササイズ」 = 4つの問いにチームメンバーそれぞれが答え、それに対するフィードバックをエルことでお互いに対する期待に対するズレを解消する。特に④に対する自己認識を正し、チームで合わせるのが狙い
- 自分は何が得意なのか
- どういうふうに仕事をして貢献するつもりか
- 自分が大切に思う価値は何か
- チームメンバーは自分にどんな成果を期待していると思うか
ワーキングアグリーメント
チームの活動を円滑にすすめるために決めておく約束事。
例：
- チームの価値観
- トラブル発生時に決めた再発防止策
- 過去のプロジェクトで発生した問題への対策
- 日々の運用ルール
チームの活動する場を整える
チームの関係性、相互作用を引き出すために、以下の項目を決めておく
- 連絡共有（仮想の場）
- 意思決定（仮想or物理の場）
- 創造（物理的な場）
- 雑談（仮想or物理）
インクリメンタル（少しずつ作る）
インクリメンタルな開発には二つ問題がある。１つは品質を維持することの難しさ、もう一つはプロダクトの全体性への理解欠如
品質を維持することの難しさに対して
品質を維持することの難しさに対して、以下のような対策があげられる。
変更しやすいように作る
これは可能な限り一つの機能が独立して存在できるような設計が求められる（オブジェクト指向設計、ドメイン駆動設計が有名）
テスト
安心して変更できる環境を作る。結合の度に人力でテストとその確認を行うのではなく、その行為自体を自動さする作戦。これを行うには、プロダクトのプログラムとは別にテストを実行するためのプログラムを作り、自動的に実行できる環境を構築する必要がある。
プロダクトの全体性への理解欠如に対して
作るべきものを一覧（スクラム開発ではプロダクトバックログと呼ぶ）で管理して優先順位をつけるアジャイル開発では、順番を入れ替え安くするために、それぞれが明確で、かつほかの項目に依存しないものが望ましく、また1日以内で開発が終わるような規模感にすることで、それぞれの独立性を高める。その結果、項目の内容はわかりやすくなる一方、どういう状況のもとで必要な機能なのかがとらえづらくなる。そこでプロダクトの全体像を、システム視点ではなくユーザー視点で捉えるため、ユーザーストーリーマッピングやユーザー行動フローといった手法を使う。ユーザーの行動を時系列に書き出し並べて、その行動の中で発生する課題をとらえ、さらにそれらの課題を解決するために必要な機能を洗い出す。そして作るべきもの一つ一つの項目を詳細化するという、全体と詳細の両面を捉えるスタイルがインクリメンタルな開発には必要
ユーザー行動フローの例（人工衛星の場合）
- 行動「ロケット打ち上げ → 放出 → 太陽光パネルを広げる → センサー起動 → 地上局へデータ送信 → 日陰では消費 → 日向では充電しながら直接エネルギーを使用…」
- 課題「打ち上げ時振動への耐震性、機体の角度を把握する、太陽エネルギーと消費エネルギーの割合を調整しなければならない、機体温度が高くなるor低くなる、太陽熱で押しやられる、放射線で壊れる…」
- 機能「機体固定機能、ジャイロセンサ、バッテリー状況を地上局へ送信」
- 作るべきもの「機体固定装置、ジャイロセンサ、バッテリー状況把握システム、…」
イテレーティブ（反復的に作る）
チームとプロダクトが対話するように作るのがイテレーティブのイメージ。行動の結果から学びを得て、その次の開発期間で適応するのがアジャイルの開発の狙いだからである。
時間を一定の感覚で区切り運用する考え方を「タイムボックス」と呼び、スクラムでは「スプリント」、スクラム以外では「イテレーション」と呼ぶ。１週間か２週間。毎回アウトプットを作り上げる。そのためのタスクが全て詰まっていなければいけない。何を作るべきか、内容を詳細化する対話や、設計や実装、テスト、どれも欠かせない。
「計画」ではなく「計画作り」をする。スクラム開発のスプリントプランニングでは、第一部のWhat（なにを作るべきか）の計画作りと、第二部のHow（どのようにそれらを実現するか）の計画作りの２部構成で行う
どのようにすれば反復の「やりきり力」を高められるかという問いに向き合うことが大切。これには以下の２つが有効
① プロダクト作りに伴う不確実性は、プロジェクト全体で受け止める = プロジェクトに余白を折り込む
② プロダクト作りの確実性は、反復（スプリント）単位で高める = 反復単位での曖昧性を可能な限り落とすべく、受け入れ条件の定義を行う。これは以下のような3項目に分けられる。
- 受け入れ条件の定義（機能として何ができなければならないのか？「できること」を箇条書きであげる） 例： 商品検索（・商品名と商品説明を対象にキーワード検索できること・商品価格をFrom ~ Toで指定して検索できること・ブランドを指定して検索できること、など）
- 開発（受け入れ条件を満たすように開発を行う（期待とずれにくくなる））
- 受け入れテスト実施（開発された機能に対して、受け入れテストを行う。同じ受け入れ条件を元に作っている機能とテストなので基本的にクリアできるはずである）
反復的な作成物レビュー
スプリントプランニングの対になるのが、スプリントレビュー。開発チームとプロダクトオーナーだけでなく、プロジェクトやプロダクトの関係者を集めて、スプリントの成果を確認しあうための場。プロダクトの機能をデモすることでフィードバックを獲得していく。得られたフィードバックをもとに、プロダクトがもたらす価値をより最適化していくために、何が必要か、何ができるかまで議論する
チームの振り返り
チームがどれだけできるようになったか、振り返りを行う。（スクラムではスプリントレトロスペクティブという）チームとその行為、プロセスを含めてレビューする。反復を繰り返す度に問題を解消し、少しずつ状況を改善し、機能するチームを目指す。
一人で始めるアジャイル開発
一人でアジャイル開発を始める場合、以下のような順序で行う。
