# はじめに
## 本書の目的
スクラムでは、以下の図のとおりプロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。
つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。 言い換えるとそれらがないとスプリントが開始できません。 本書では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察していきます。
## 本書の前提
本書では、すでにスクラムのフレームワークの全体像を理解していることを前提としています。 スクラムのイベント、作成物、ロールなどについて詳しく知るには、[スクラムガイド](https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf)を参してください。
## 自分たちで考える
Management 3.0の作者、Jurgen Appelo氏は以下のように言っています。
> 優れたプラクティスのコレクションを固定的なメソッドやフレームワークとして扱うのは、複雑系の特性を無視してしまっている。 複雑系（人間を含む）は、固定と停滞から学ばない。不確実性、変動性、驚きから学ぶのだ。
>
> –Jurgen Appelo 『Management 3.0』、『How to Change the World』などの著者
また、Andy Hunt氏は以下のように言っています。
> あなたのスキルレベルによってプラクティスは異なる。他の人の経験はあなたのものと同じではない。ゆえに、単純に “カーゴ・カルト”することはできないのだ。
>
> –Andy Hunt 『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』、『リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法』などの著者
カーゴ・カルト（積荷崇拝）とは、いつの日か、先祖の霊・または神が、天国から船や飛行機に文明の利器を搭載して自分達のもとに現れる、という現世利益的な信仰で、ニューギニア諸島で多く見られたものです。 つまり、ある戦略が成功を導いた理由や状況を完全に理解せずに、見よう見まねで行動を真似たり、ツールを導入したりすることをカーゴ・カルトと呼びます。 ですがこのようなやり方ではうまくいきません。
「◯◯というプラクティスをやっておけばよい」という思考は捨ててください。 どれだけ流行っていたりメジャーなプラクティスでも同じです。 つまり初期フェーズの組み立てを自分たちで考える必要があるということになります。 もちろん、プロジェクトやプロダクトがうまくいかない点には類似性があり、既存の知識やプラクティスは参考にはなりますので、全てをゼロから考えなければいけないわけではありません。
## 立ち上げ時によく使われるプラクティスと4つの観点
初期の段階で行われることが多いプラクティスの1つにインセプションデッキがあります。 アジャイル開発のプラクティスの1つで、どの方法論や手法にも属してない独立したものです。
開発を始める前に明らかにしておくべきこと11個の質問に答える形で整理し、チーム全員で話し合い合意したものを見える化していきます。 こうしてこれから向かう先や考え方を共有していきます（憲章）。 もちろん状況は刻一刻と変わるので、必要に応じて定期的に更新していきます。
インセプションデッキには上図のとおり次の11個の質問が含まれます（なお書籍では10個のプラクティスとされていますが、著者が公開しているインセプションデッキのテンプレートには11個の項目が含まれているため、ここでは11個として扱います）。
* 我々はなぜここにいるのか
* エレベーターピッチ
* パッケージデザイン
* やらないことリスト
* ご近所さんを探せ
* 技術的な解決策の概要
* 夜も眠れなくなる問題は何？
* 俺たちのAチーム
* 期間を見極める
* トレードオフを決める
* 初回リリースに必要なもの
これらの質問に答えるわけですが、忘れてはいけないいちばん重要な点として、ドキュメントを作ることが目的ではないことが挙げられます。 形骸化したドキュメント、使われないドキュメント、本音が隠された建前のドキュメントなどに意味はありません。 インセプションデッキの目的は共通理解の形成であり、この11個の質問は共通理解を形成すべき領域を明らかにしていると考えれば良いでしょう。 本書ではインセプションデッキを作るのではなく、インセプションデッキに含まれる項目をそれぞれブレークダウンして考えて行きます。
インセプションデッキの11個の質問を共通理解を形成する観点でざっくり分類すると以下のようになります。
* プロダクトに対する観点
* 我々はなぜここにいるのか
* エレベーターピッチ
* パッケージデザイン
* やらないことリスト
* 人に対する観点
* ご近所さんを探せ
* 俺たちのAチーム
* 技術や品質に対する観点
* 技術的な解決策の概要
* トレードオフを決める
* 計画やマネジメントに対する観点
* 夜も眠れなくなる問題は何？
* 期間を見極める
* 初回リリースに必要なもの
これらの4つの観点は相互に影響を与えます。 本書ではそれぞれを順番に見て行きます。
## 著者について
吉羽 龍太郎（よしば りゅうたろう）
株式会社アトラクタ Founder兼CTO / アジャイルコーチ。
アジャイル開発、DevOps、クラウドコンピューティングを中心としたコンサルティングやトレーニングに従事。 野村総合研究所、Amazon Web Servicesなどを経て現職。 Scrum Alliance認定チームコーチ（CTC） / 認定スクラムプロフェッショナル（CSP） / 認定スクラムマスター（CSM） / 認定スクラムプロダクトオーナー（CSPO）。 Microsoft MVP for Azure。青山学院大学非常勤講師（2017-）。 著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、『業務システム クラウド移行の定石』（日経BP社）など、訳書に『カンバン仕事術』（オライリー・ジャパン）、『ジョイ・インク』（翔泳社）など多数。
Twitter：[@ryuzee](https://twitter.com/ryuzee) ブログ：
### 著作について
本書のほかに執筆、翻訳した書籍のうちお勧めのものについて紹介します。
* [レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス](https://amzn.to/2Ko2ZRm)
* [Effective DevOps ―4本柱による持続可能な組織文化の育て方](https://amzn.to/2GvK1Dt)
* [変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】](https://amzn.to/2pYztcg)
* [ジョイ・インク 役職も部署もない全員主役のマネジメント](https://amzn.to/2hcYzuL)
* [アジャイルコーチの道具箱) – 見える化の実例集](https://leanpub.com/agiletoolbox-visualizationexamples-japanese)
* [カンバン仕事術 ―チームではじめる見える化と改善](https://amzn.to/2qMvhba)
* [SCRUM BOOT CAMP THE BOOK](https://amzn.to/2DDdNap)
## ライセンス
本書記載の内容は引用部分を除き著者が著作権およびその他隣接する権利を有しています。本書の一部または全部の複製、改変、頒布はできません。
本書は著者の経験などをまとめたものであり、著者の文脈で機能したやり方の1つとして紹介するものです。 すべての状況において当てはまるものでもなく、本書を利用した以下なる結果についても著者は責任を持ちかねますので予めご了承ください。
## 本書に関するご意見、お問い合わせ
本書に関するご意見、お問い合わせは、Twitter：[@ryuzee](https://twitter.com/ryuzee)までお願いします。
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://scrum-starter.ryuzee.com/master.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.