2. はじめに ✤ この資料にはアジャイルプロジェクトのはじめ方について記述しています ✤ スクラムを利用した場合の例になっています ✤ スクラムではプロダクトバックログがある状態から開始となりますが、実際のプ ロジェクトではその前に準備が必要です ✤ あくまでやるべきことの一例として書いていますので、現場にあわせて始め方を 考えてください ✤ そのほかインセプションデッキなども利用可能です ✤ 準備期間に何ヶ月もかけてはいけません。最長でも1ヶ月程度にしてスプリント を開始すること
3. プロダクトゴールや価値の明確化 ✤ これから作るもののビジネス価値やプロダクトビジョンを明確にする ✤ やらないことが明らかにできているのも良い ✤ これから作るものの責任を負っている人はだれなのかを明らかにする ✤ 作るものの特性が分からないとどんな開発の仕方をするか決まらない
4. アジャイル開発導入の合意 ✤ 対象プロダクトの特性を踏まえてアジャイル開発がよいのであれば、その合意を ステークホルダーから取る ✤ 従来のプロジェクトマネジメントとは考え方が大きく異なるので、合意が取れて いないと後で従来型とのギャップに苦しむことになる ✤ 必要に応じて関係者にはアジャイル開発の価値観、従来型との違いを説明して理 解してもらう ✤ 従来の報告の仕方とは異なる可能性が高いので、どのような報告が必要かを確認 しあわないものは交渉してやめる
5. 適切なメンバーの選定 (1) ✤ これからアジャイル開発用チームをつくる場合にはそれに適したチームを作る。 適任者の特性として以下のようなことがあげられる ✤ 新しいことに抵抗がない ✤ 常に変化する状況にストレスを感じない（ルール明文化を過度に求めない） ✤ 個人の責任範囲ではなく、全体の成果を気にすることができる ✤ 自分のことばかりではなく、人が困っているときに助けられる ✤ 意見や反論を言える ✤ コードが書ける・インフラが作れる
6. 適切なメンバーの選定 (2) ✤ 他のプロジェクトを兼任しているとそれに引きづられてプロジェクトに十分にコ ミットできなくなってしまうため、メンバーを兼任から解放し、プロジェクトに 専任でアサインする（ことが原則） ✤ チームをこれから形成する場合、同じキャリアや考え方に 様性を持たせる ✤ メンバーが分散している場合は1箇所に集めて全員同席になること ✤ い過ぎないように多 特に導入初期からリモートにするのは難しいので要注意
7. 適切なメンバーの選定 (3) ✤ 既存のチームで実施する場合は、ここまでの内容を踏まえる ✤ あまりにアジャイル開発にあわないチームで実施するのはリスクが高い ✤ リスクが高い例 ✤ パートナー比率が非常に高い (開発者が全員パートナー) ✤ 既存のチームが強力な指示型で運営されている ✤ 開発経験が非常に少ないメンバーだけで構成されている
8. ロールの明確化 ✤ プロダクトオーナーは誰？ ✤ 忙しすぎるとうまくいかない ✤ 開発チームは誰？ ✤ スクラムマスターは誰？ ✤ 利害関係者は誰？を明らかにする
9. ファシリティ ✤ スクラムチーム全員が集まれる場所を用意する ✤ プロジェクトルームが用意できると心理的にも安全にしやすい ✤ ✤ 特に社内で初めてのアジャイルプロジェクトで、かつ日常的に静かな環境の 場合、他のチームからクレームがつく場合がある 付箋紙、模造紙、ホワイトボード、大きなスクリーン、コーヒー、おやつ、その 他文房具類の準備
10. ワーキングアグリーメントの設定 ✤ スクラムチームが一緒に働く上での約束事を決めてそれを守る ✤ デイリースクラムの時間やその他のイベントの時間 ✤ 日々のコミュニケーションの仕方 ✤ コーディング規約 ( => 完成の定義) ✤ コミットルールやレビュールール (=> 完成の定義)
11. スクラムチームに対するスクラムのトレーニング ✤ スクラムチーム(プロダクトオーナー、開発チーム、スクラムマスター)全員の知 識レベルを える ✤ 価値観や仕事の流れを中心とする ✤ これから行う活動において従来型の考え方をそのまま持ち込んでしまってム ダが発生するのを防ぐ ✤ その後も定期的に短時間のトレーニングを行う ✤ ステークホルダーもトレーニングに参加して貰うと更によい
12. 初期のプロダクトバックログの準備 ✤ プロダクトビジョンややらないことが先に決っているとよい ✤ 全部が ✤ 優先順位で並び替える ✤ 上位の項目ほど具体的に、下位の項目は詳細化しすぎなくてよい ✤ それぞれの項目を見積もる ✤ 上位の項目には受け入れ基準を用意する ✤ ユーザーストーリーマッピングを使ってみるとよい っている必要はないが、優先順位が高い項目は洗い出す
13. おおよそのリリースプランニング ✤ いつごろにどのような内容でリリースしたいのかをプロダクトオーナーが中心と なって考える（ステークホルダーの意向も影響する） ✤ それが実現できるかどうかは早い段階で分かる
14. アーキテクチャや開発言語などの選定 ✤ 非機能要件は何か (性能やセキュリティ、プラットフォームなど) ✤ プロダクトのアーキテクチャをどのようにするか ✤ どの開発言語でどんなフレームワークを使うか ✤ テスト自動化にはどんなライブラリを使うのか
15. 開発環境の作成 ✤ 個人の開発環境を用意する ✤ 後から参加した人が簡単に開発環境を手に入れられるように仮想化や自動化など を組み合わせる
16. 技術検証(スパイク) ✤ プロダクトバックログ項目のうちプロダクトの開発を進める上でブロッカーにな るような優先順位が高くかつ技術難易度が高いものの検証を行う ✤ 結果によってはアーキテクチャや要素技術を変更したり、プロジェクトを中止す ることもあり得る
17. 完成(Done)の定義の作成 ✤ 完成の定義はプロダクトの性質やビジネスのゴールによって変わる ✤ プロダクトオーナーと合意する ✤ 社内に品質管理部門がいる場合は作成の支援に入ると良い ✤ テスト自動化の範囲、カバレッジ基準値、必要なドキュメントなどなど ✤ 本番にリリースするために必要なことと、スプリントでやることに差が少ないほ どいつでもリリース可能になる（が成熟度に依存する）
18. ツールセットの準備 ✤ コードは初期から全てバージョン管理システムに登録する ✤ バージョン管理システムのメインライン、ブランチ等の使い方を教育 ✤ これができない人には本番コードを書かせない ✤ CI/CDサーバの構築等 ✤ 要求やバグなどのチケット管理システム ✤ テスト環境など ✤ プロダクトバックログの上位に入れることもある
19. スプリントの長さを決める ✤ プロダクトオーナーが要求の変更を我慢でき、開発チームが持続可能なペースと なる期間を設定する ✤ プロダクトの規模にも依存する ✤ 小規模なら1∼2週。大規模なら2∼4週であることが多い ✤ 実は期間が長い方が難しい
20. プラクティスの選択 ✤ スクラムは3つのロール、3つの作成物、5つのイベントすべてを実施しないとい けない ✤ XPでは必要なものを選べばよい ✤ ほかにも必要なプラクティスを選択する。後で変えても良い
21. その他 ✤ 最初から完璧であることはないので、実際にスプリントを開始して少しづつ改善 を繰り返すようにすること ✤ 透明性を維持するようにすること。一方で最初から過度にメトリクスを取ろうと しないこと
