みなさんこんにちは。@ryuzeeです。

スクラムでスプリント1を開始する前にどんな準備をしておくと良いかについては、Regional Scrum Gathering Tokyo 2018で話をしたのですが、改めて文章化してみました。なお、かなり長いので関係なさそうなところは適宜読み飛ばしてください。

1. はじめに

1.1 この記事の目的

スクラムでは、プロダクトバックログが用意されていて、それを元にスクラムチームでスプリントプランニングを実施し、スプリント期間中毎日デイリースクラムを行い、最後にスプリントレビューとレトロスペクティブを実施することになっています。

つまりプロダクトバックとスクラムチームが存在するところがスタート地点になっています。言い換えるとそれらがないとスプリントが開始できません。本稿では、実際にスクラムでスプリントを開始する前にどんな準備を行うと良いのかを考察していきます。

なお本稿は筆者の経験などをまとめたものであり、筆者の文脈で機能したやり方の1つとして紹介するものです。すべての状況において当てはまるものでもなく、本稿を利用した以下なる結果についても筆者は責任を持ちかねますので予めご了承ください。

1.2 本稿の前提

本稿では、すでにスクラムのフレームワークの全体像を理解していることを前提としています。スクラムのイベント、作成物、ロールなどについて詳しく知るには、スクラムガイドを参照してください。

1.3 自分たちで考える

優れたプラクティスのコレクションを固定的なメソッドやフレームワークとして扱うのは、複雑系の特性を無視してしまっている。複雑系（人間を含む）は、固定と停滞から学ばない。不確実性、変動性、驚きから学ぶのだ。

–Jurgen Appelo 『Management 3.0』、『How to Change the World』などの著者

あなたのスキルレベルによってプラクティスは異なる。他の人の経験はあなたのものと同じではない。ゆえに、単純に “カーゴ・カルト”することはできないのだ。

–Andy Hunt 『アジャイルプラクティス達人プログラマに学ぶ現場開発者の習慣』、『リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法』などの著者

カーゴ・カルト（積荷崇拝）とは、いつの日か、先祖の霊・または神が、天国から船や飛行機に文明の利器を搭載して自分達のもとに現れる、という現世利益的な信仰で、ニューギニア諸島で多く見られたものです。つまり、ある戦略が成功を導いた理由や状況を完全に理解せずに、見よう見まねで行動を真似たり、ツールを導入したりすることをカーゴ・カルトと呼びます。ですがこのようなやり方ではうまくいきません。

「◯◯というプラクティスをやっておけばよい」という思考は捨ててください。どれだけ流行っていたりメジャーなプラクティスでも同じです。つまり初期フェーズの組み立てを自分たちで考える必要があるということになります。もちろん、プロジェクトやプロダクトがうまくいかない点には類似性があり、既存の知識やプラクティスは参考にはなりますので、全てをゼロから考えなければいけないわけではありません。

1.4 立ち上げ時によく使われるプラクティスと4つの観点

初期の段階で行われることが多いプラクティスの1つにインセプションデッキがあります。アジャイル開発のプラクティスの1つで、どの方法論や手法にも属してない独立したものです。

開発を始める前に明らかにしておくべきこと11個の質問に答える形で整理し、チーム全員で話し合い合意したものを見える化していきます。こうしてこれから向かう先や考え方を共有していきます (憲章)。もちろん状況は刻一刻と変わるので、必要に応じて定期的に更新していきます。

インセプションデッキには次の11個の質問が含まれます。

我々はなぜここにいるのか
エレベーターピッチ
パッケージデザイン
やらないことリスト
ご近所さんを探せ
技術的な解決策の概要
夜も眠れなくなる問題は何？
俺たちのAチーム
期間を見極める
トレードオフを決める
初回リリースに必要なもの

これらの質問に答えるわけですが、忘れてはいけないいちばん重要な点として、ドキュメントを作ることが目的ではないことが挙げられます。形骸化したドキュメント、使われないドキュメント、本音が隠された建前のドキュメントなどに意味はありません。インセプションデッキの目的は共通理解の形成であり、この11個の質問は共通理解を形成すべき領域を明らかにしていると考えれば良いでしょう。本稿ではインセプションデッキを作るのではなく、インセプションデッキに含まれる項目をそれぞれブレークダウンして考えて行きます。

インセプションデッキの11個の質問を共通理解を形成する観点でざっくり分類すると以下のようになります。

プロダクトに対する観点: 我々はなぜここにいるのか / エレベーターピッチ / パッケージデザイン / やらないことリスト
人に対する観点: ご近所さんを探せ / 俺たちのAチーム
技術や品質に対する観点: 技術的な解決策の概要 / トレードオフを決める
計画やマネジメントに対する観点: 夜も眠れなくなる問題は何？ / 期間を見極める / 初回リリースに必要なもの

これらの4つの観点は相互に影響を与えます。それぞれを順番に見て行きましょう。

2. プロダクトの観点

2.1 プロダクトゴールや価値の明確化

初期の段階で大事なのは、これから作るもののビジネス価値やプロダクトビジョンを明確にすることです。そしてこのビジョンは、これから作るものの責任を負っている人が誰なのかが明らかでないと決まりません。つまり人の観点に依存していると言えます。

なお、この時点では詳細な要求に踏み込まず、全体像を把握することが最優先です。

また開発以前の話としてビジネスモデルの整理をしないといけないこともあります。ビジネスモデルの整理には、例えばビジネスモデルキャンバスやリーンキャンバス、ユーザーインタビューなどのツールが利用可能です。実際の開発には多額のコストがかかります。アイデアやビジネスモデルの検討が不十分で見切り発車してしまうと、多くの時間とお金をかけたあとにニーズがないことが分かった場合に大きな損害になってしまいます。もちろん必ずプロダクトが当たるという保証などできませんが、あまい見通しだけで進めるのは無謀です（逆に半年も1年も検討だけしていても意味はありません）。

作るものの特性が分からないとどんな開発の仕方をするかは決まりません。つまり開発手法はこの時点ではスクラム一択ではありません。では、どのようにして開発の手法を選択すればよいでしょうか。

2.2 クネビンフレームワークによる問題の分類

問題の性質を分類するフレームワークの1つにスノーデン氏が作成したクネビンフレームワークがあります。このフレームワークでは問題は5つの領域のいずれかに属するものと考えています。

1つ目の明白な領域とは、正解が存在し変化の少ない領域を指します。この領域では状況を理解・分類して、過去から蓄積したベストプラクティスに基づいて進めていくのが良いでしょう。つまり過去の成功例をそのまま当てはめて進めれば良いので、ウォーターフォール型の開発と親和性が高いとも言えます。

2つ目の込み入った領域とは、正解が1つではないものの、比較的予測しやすい領域を指します。状況を専門家が分析して理解し、取り得る手を検討して進めていきます。専門家の分析によって問題がわかれば、それを踏まえて過去の経験などの中からうまくやる方法を探して、それをグッドプラクティスとして活用していきます。つまり最初に分析を行い詳細が明らかになれば、そこに対してウォーターフォールが適用可能になります。

3つ目の複雑な領域とは、問題を把握するために試行錯誤（探索）を行い、それによって状況を把握し、そのあとに次の対応を考えていく領域のことです。この場合、うまくやる方法は最初からは分からず後からわかることになります。つまり計画主導型のやり方では対応が難しく、アジャイル開発が向いている領域となります。

4つ目のカオスな領域とは、革新的なことが求められる領域で正しい答えもわからないので、まず行動してから理解していくしかない領域のことです。この領域では既存の知識が役に立たないこともあります。つまり計画を事前に十分にたてることはできません。

これから解決しようとしている問題が明白な領域や込み入った領域であれば、従来のウォーターフォール型の開発が効率的でしょう。一方で複雑な領域とカオスな領域ではアジャイル開発が適しています。問題にあった開発手法を選択する必要があるのです。

2.3 スクラムによる開発の合意

対象プロダクトの特性を踏まえてスクラムがよいのであれば、その合意をステークホルダーから取りましょう。必要に応じて関係者にはアジャイル開発やスクラムの価値観、従来型との違いを説明して理解してもらう必要があります。アジャイル開発では、従来のプロジェクトマネジメントとは考え方が大きく異なるので、合意が取れていないと後で従来型とのギャップに苦しむことになります。また、従来の報告の仕方とは異なる可能性が高いので、どのような報告が必要かを確認し、あわないものは交渉してやめるといった準備も必要です。

よくあるギャップには次のようなものがあります。

スクラムチームは変化に対応してスコープを柔軟に変更しながらプロダクトを作ると考えているが、ステークホルダーは最初に洗い出したスコープをすべて作ると考えている
スクラムチームはフィードバックを選別して意味のあるものだけを取り入れればよいと考えているが、ステークホルダーはすべてのフィードバックを取り入れるべきだと考えている
スクラムチームは開発チームの稼働できる時間（キャパシティ）や期間を固定して、その範囲で全力を尽くすと考えているが、ステークホルダーは人や労働時間を増やしても構わないと考えている
スクラムチームは必ずしもすべてのバグを修正しなければいけないとは考えていないが、ステークホルダーはすべてのバグは重大度に関係なく修正しなければいけないと考えている
スクラムチームはドキュメントは必要な分だけを作ればよいと考えているが、ステークホルダーはウォーターフォールで作るようなドキュメントをすべて作らなければいけないと考えている

これらはどちらかが悪いという話ではありません。いままでやってきたやり方にも、そのコンテキストでの合理性があって結果が出ていたのですから、一概に否定するものでもありません。あくまで考え方の違いです。ただし、ギャップを解消しないままで進めてしまうと、いずれも後になって問題を引き起こすので、開始前に期待値をすり合わせておきましょう。

2.4 初期のプロダクトバックログの準備

プロダクトのビジョンが明らかになり、アジャイル開発が向いているということになれば、それにあわせた要求の整理を進めましょう。このタイミングで大事なのは、まずは全体像を見ることです。細部に入りすぎるときりがないのでユーザーストーリーマッピングのようなツールを使って全体の把握に務めます。見える化することによって共通理解を形成するのが目的です。

多くの場合、初期に洗い出したプロダクトバックログアイテムをすべて開発することはありません。さまざまなことが明らかになっていくにつれて、不要な項目は削除され、新たな項目が追加されていきます。したがって、初期の段階ですべてが揃っている必要はありません。ただし、上位のプロダクトバックログアイテムは洗い出しておかないと、そもそも開発自体を始められません。ユーザーストーリーマッピングなどを使って抽出したプロダクトバックログアイテムの候補を着手する順番に並び替えましょう。このとき上位のプロダクトバックログアイテムほど具体的にしておきます。下位の項目はやらない可能性も高いので詳細化しすぎないようにします。

そうしてプロダクトバックログアイテムが洗い出せたら、それぞれの項目をラフに見積もっておきましょう。ストーリーポイントを使っても構いませんし、Tシャツサイズ（S / M / L / XLなど）を使っても構いません。この時点の見積りはあくまで全体の把握のためなので、あまり時間をかけずに済ませましょう。並べ終わった上位のプロダクトバックログアイテムは、スプリント1に向けて受け入れ基準を用意することになりますが、これについては別途解説します。

3. 人の観点

次に人の観点を見て行きましょう。

3.1 ロールの明確化

スクラムでは、プロダクトオーナー、開発チーム、スクラムマスターという3つのロールが定められています。この3つのロールをあわせてスクラムチームと呼びます。またチームの外側には、ステークホルダーと呼ばれる関係者がいるはずです。たとえば、顧客、ユーザー、スポンサー、営業、マネジメントチーム、スペシャリストチーム、QAチーム、運用チーム、社内管理部門、システム連携先などはステークホルダーの候補です。

まずはここから先を進めていく上で、誰がどのようなロールを担うのか明らかにしておきましょう。スクラムチームだけに限らず、ステークホルダーが今回のプロダクトにどのように関係していて、どんな利害があるのかも明らかにしておくと良いでしょう。

スクラムでは、スクラムチームとその外側に境界を設定します。境界を設定することで、開発チームは集中して成果を出すことに取り組めるようになります。外部との接点は、プロダクト面ではプロダクトオーナーが担い、プロセス面ではスクラムマスターが担うのが一般的です。つまり、プロダクトオーナーとスクラムマスターは外部と協働するのも仕事のうち、ということです。

3.2 プロダクトオーナーの決定と教育

スクラムで成果を出す上で、プロダクトオーナーはいちばん重要です。プロダクトオーナーは、プロダクトの責任者（結果責任）を取る舵取り役で、プロダクトの価値を最大化する責任を持つ1人の人（委員会ではありません。サポート役はつけても構いませんが最終決定権は1人に集約します）です。次のような責任を担います。

プロダクトの結果責任を取り、ビジネス価値を最大化する責任
プロダクトのビジョンを周りに示し理解させる責任
プロダクトバックログの管理と並び順の最終決定の責任
開発チームをうまく使う責任
開発チームの成果物の受け入れ可否を決める責任
スクラムイベントに参加して開発チームやステークホルダーと協働する責任
ステークホルダーをマネージする責任
予算の管理責任
リリース日を決める責任
スプリントのキャンセル判断をする責任

なお、開発チームのメンバーにタスクをアサインしたりやり方を指定する責任や権限はありません。

プロダクトに唯一の舵取り役なので、成果を出せるかどうかはプロダクトオーナー次第です。ステークホルダーとのやりとり、開発チームとのやりとり、プロダクトバックログアイテムの並べ替え、開発チームが作ったものの受け入れ判断など、プロダクトオーナーにはやるべきことがたくさんあります。その中でも、いちばん重要な仕事が意思決定です。

すべてのものは有限です。プロダクトの開発の予算や期間は限られています。開発チームの人数も限られていますし、その一方でやりたいことはたくさんあります。すべてをやることは絶対にできません。つまり、取捨選択の意思決定ができなければいけません。「No」を言わなければいけないのです。これができる人をプロダクトオーナーとします。ステークホルダーの言うままにすべてを行わなければいけない状況であれば、その人はプロダクトオーナーとして適任ではありません。適切な人を選び直すか、権限移譲が必要です。

プロダクトオーナーは色々な悩みや問題は尽きることはありません。しかし、それを1人で抱え込む必要はありません。すべてのことを1人でやりきれるわけでもありません。困ったことがあれば、開発チームやスクラムマスター、ステークホルダーなどに助けを求めればよいということを理解する必要があります。

プロダクトオーナーが、いつどのようなことをやるか一例を挙げておきます。

初期: 事業計画を考える / プロダクトビジョンを考える / マーケットの状況を理解する / 事業やプロダクトの承認を得る / ステークホルダーを特定する / 必要な権限を移譲してもらう / 予算を確保する / マイルストーンを考える / 非機能要件を考える / 初期のプロダクトバックログの作成をリードする
開発中: プロダクトバックログを並べ替える / 開発チームの疑問に答える / スプリントプランニングに参加する / 開発チームの作成物の受け入れ判定をする / スプリントレビューを主催する / ステークホルダーをスプリントレビューに招待する / フィードバックを受けてプロダクトバックログを更新する / ステークホルダーや顧客の満足度を定期的に確認する / スプリントレトロスペクティブに参加する / 全体の進捗や今後の見通しを明らかにする
終盤: リリース計画を考える / マーケティングやサポートなど他のステークホルダーと連携する / 社内プロセスの手配をする / クロージングに必要なプロダクトバックログアイテムをとりまとめる

3.3 開発チームの適切なメンバーの選定

プロダクトの開発を進めることが決まった時点で開発チームのメンバーも決まっていることも多いかもしれませんが、これから新しく開発チームを作る場合には、どのようなメンバーを集めれば良いか見ておきましょう。

適任者の特性は次のとおりです。

新しいことに抵抗がない
常に変化する状況にストレスを感じない
個人の責任範囲ではなく、全体の成果を気にすることができる
自分のことばかりではなく、人が困っているときに助けられる
意見や反論を言える
コードが書ける・インフラが作れる・必要な技術スキルがある

これらはスクラムに限らずアジャイル開発全般にあてはまります。アジャイル開発は変化への対応を重視しています。したがって変化することが自然だと考えるようなマインドセットは重要です。また個人ではなくチームによるコラボレーションやコミュニケーションを重視するやり方なので、周りから信頼を得られるようなふるまいができることが求められます。もちろん、実際に役にたつものをつくる上で技術力も必要です。すべてを高いレベルで満たすことはなかなかできませんが、開発チーム全体としてこれらが実現できるようにしましょう。また、開発チームの強さはさまざまな角度から物事を考えられることなので、同じキャリアや考え方に揃い過ぎないように多様性に配慮すると良いでしょう。

開発者は必ず専任でアサインします。他のプロダクトやプロジェクトを兼任していると、それに引きづられて十分にコミットできなくなってしまったり、ボトルネックになってしまい、かえって開発チームの迷惑になることもあります。開発者が地理的に分散している場合は1箇所に集めて全員同席になることが理想です。もちろん働き方の多様性も重要ですが、一緒に同じ場所で働いたことのない人たちが、同じ目的をもったチームとして働くことは難しいので、1か月程度でもよいので一緒に同じ場所で働くようにすることをお勧めします。

なお、アジャイル開発の考え方があわない人たちでチームを作ってしまうと失敗する可能性が高くなります。例えば、以下のようなケースではリスクが高くなります。

開発チーム内の開発者のパートナー比率が非常に高い
既存のチームが強力な指示型で運営されている
開発経験が非常に少ないメンバーだけで構成されている

3.4 スキルの見える化

開発チームができあがったら、開発チームのメンバーのスキルセットを明らかにしておくのは良い手です。そうすることで、成果を上げやすい技術を採用できるとともに、メンバー間でのスキルアップを進めやすくなります。

3.5 スクラムの知識レベルを揃える

また、体制がある程度見えてきたら、さまざまな活動に本格的に入っていく前に、スクラムチーム（プロダクトオーナー、開発チーム、スクラムマスター）とステークホルダーの知識レベルを揃えておきましょう。全員を集めて、アジャイル開発の価値観、仕事の流れ、イベント、作成物、ロールなどの基本的な概念を理解して、言葉があうようにします。こうすることで、これから行う活動で、従来型の考え方をそのまま持ち込んでしまってムダが発生するのを防ぎます。またこのような活動は、その後も定期的に行うと良いでしょう。全員がプロセスに対して共通理解を持っていることは非常に重要です。

3.6 ファシリティ

これからアジャイル開発を始めるにあたっては、スクラムチーム全員が集まれる場所を用意するようにしましょう。部署が違っていても同じプロダクトを開発しているのであれば、同じ場所に集まるのです。このようなやり方を全員同席と呼びます。全員同席はエクストリームプログラミング（XP）のプラクティスの1つで、コミュニケーションのオーバーヘッドを大きく削減できます。専用の部屋が用意できると心理的にも安全性を確保しやすくなります。逆に、社内で初めてのアジャイル開発を行うようなケースで、いままでの環境が日常的に静かな環境の場合、他のチームからクレームがつく場合があります。こうなってしまうと、コミュニケーションが阻害されて、成果が出にくくなってしまいます。

3.7 道具を揃える

専用の場所が用意できたら、ほかに必要なものをまとめて準備しておきましょう。よく使うのは次のようなものです。

付箋紙
模造紙
ホワイトボード
大きなディスプレイ
コーヒー
おやつ
冷蔵庫
ペン、マーカー、定規、その他文房具類
もちろん速いPC

多くの場合、いちばんコストがかかるのは人件費です。つまり人が安心して働きやすい環境を作ることは、いちばん高い「リソース」を効果的に活用する上で絶大な効果があります。

3.8 ワーキングアグリーメントを設定する

ワーキングアグリーメントとは、スクラムチームが規律を守って生産的に物事を進めるために用意するもので、仕事の働き方のルールを示したものです。 Googleなどは良いチームのポイントとして「集団規範」を挙げていますが、このような規範を明確にするものです。ワーキングアグリーメントは、スクラムチーム全員で議論して納得した内容を明文化するものであって、プロダクトオーナーやステークホルダーが強制するものではありません。

スプリント1の開始前までに用意して、以後レトロスペクティブごとに見直していくと良いでしょう。守るのに注意が必要な項目に絞り込む（ホワイトボードの脇に貼れるくらいの量）、当たり前にできるようになったことを削除するなどして、軽量に保つようにします。

働き方の合意なので、スクラムチームによって内容は異なります。例を見てみましょう。

午前9時〜午後4時がコアタイム。コアタイム外にスクラムイベントを設定しない
スクラムイベントは休暇以外は全員参加。不参加の際は意思決定を委ねる
デイリースクラムは午前10時に開始
デイリースクラムの前までにタスクの残時間を更新しておく
毎週火曜日の午前11時からスプリントレビューを実施する
レビューの準備には1時間以内
イベントやミーティングは時間通りに開始して、タイムボックス内で終了する
イベントやミーティング中は携帯に出ない
レトロスペクティブでは、スクラムマスター以外はノートPCを閉じる
プロダクトオーナーは午前11時〜午後3時まではチームの部屋にいる
テストがすべて終わったものを完成とする
ビルドが失敗した場合、修正コード以外のプッシュをしない
誰かに助けを求められたら「よろこんで」と返事する
予定休暇は1週間前までに共有する
マスターブランチへの直接プッシュは禁止
ペア作業をする場合は50分に1回10分休憩を入れる
ドキュメントはマークダウン形式でバージョン管理システムに入れる
1つのことに30分ハマったら周りに助けを求める
体調が悪い場合は無理して来ない。周りに移す方が迷惑
休日の前日午後4時以降はリリースしない

4. 技術や品質の観点

ウォーターフォールかアジャイルかに関係なく、技術や品質の観点は重要です。

プロダクトやシステムが達成すべき品質は、開発手法によって決まるのではなく、そのプロダクト自体が、誰のためにどう使われるかによって決まります。たとえば、銀行のオンラインシステムであれば、金額を間違うことも、振込が遅延することも、振込の画面でエラーがでることも許容されず、詳細なテストケースをすべて網羅しなければいけないかもしれませんが、使い捨てのキャンペーン申し込みサイトであれば、多少の不具合があっても関係ないこともあります。

つまり、どの程度の品質が必要になるかによって、開発にかかる期間やコストは大きく変わってしまいます。

4.1 非機能要件の明確化

そこで開発を始める前に行うのが非機能要件の明確化です。以下にあげるような項目(※)について、全員が共通理解を持てるようにします。

可用性（継続性、耐障害性、災害対策、回復性など）
性能・拡張性（業務処理量、性能目標値、リソース拡張性、性能品質保証など）
運用・保守性（運用時間、バックアップ、運用監視、計画停止、予防保守など）
移行性（移行時期、移行方式、移行対象データ、移行計画など）
セキュリティ（制約条件、セキュリティ診断、アクセス制限、データ秘匿など）
システム環境・エコロジー（システム特性、適合規格、環境条件など）

なお、小規模な新規プロダクトの場合などでは、上記で触れた項目をすべて考えるのは無駄になる可能性があります。プロダクトがマーケットに受け入れられるか分かっていないうちに、プロダクト以外のことに多くの時間を使うのは得策ではないので、プロダクトの成長を見ながら随時必要なタイミングで検討していけば良いでしょう。

※IPA公開の非機能要求グレードを元に作成

4.2 アーキテクチャや開発言語などの選定

非機能要件を踏まえて、アーキテクチャや開発言語の選定を行います。たとえば以下のような項目を検討すると良いでしょう。

プロダクトのアーキテクチャをどのようにするか
どの開発言語でどんなフレームワークを使うか
テスト自動化にはどんなライブラリを使うのか
インフラに何を使うか

もちろん初期の時点では決めきれず評価や検証が必要な場合もあります。すべての検証を事前に行う必要はありません。後から変更すると大きなコストがかかるようなものについては、優先順位を上げて早めに検証しておくと良いでしょう。検証の際は、タイムボックスを設定して、時間がかかりすぎないようにします。検証の結果が芳しくない場合は、早めに変更の判断をします。ほかに検証したい項目があれば、プロダクトバックログの中に入れておくようにします。

4.3 完成を定義する

完成の定義とは、プロダクトバックログアイテムが完成したと言えるために満たさなければいけない品質条件です。例えば、ユニットテストがある、統合テストが実施済である、静的解析で重大な警告がない、リリースノートが用意されている、コードがレビューされている、といったあるべき状態を定義します。プロダクトバックログアイテムは、この完成の定義を満たしてはじめて「完成」となります。定義を満たしていない場合は、プロダクトオーナーの受け入れ確認をしてはいけないですし、条件付きで完成とするようなこともできません。

類似のものとして、プロダクトバックログアイテムの受け入れ基準がありますが、受け入れ基準は、そのプロダクトバックログアイテムが持つべき機能性の確認であり、プロダクトバックログアイテムごとに異なるのに対して、完成の定義は、複数のプロダクトバックログアイテムで共通して満たす必要がある非機能性の確認となります。

完成の定義はプロダクトの性質やビジネスのゴールによって変わります。金融系のアプリケーションと使い捨てのキャンペーンサイトでは満たすべき非機能性に違いがあるのは当然です。

完成の定義は、プロダクトオーナー（最終決定者）と開発チームが中心となって考えます。プロダクトオーナーはもちろんステークホルダーと協働していく必要があります。ここでのステークホルダーには、大きな組織であれば、社内の品質管理部門などが含まれることがあるでしょう。

完成の定義を決める上では、「なぜ？」「なにを？」「誰のために？」をはっきりさせることが重要です。

完成の定義を複数設けることもあります。たとえばスプリントでの完成の定義、リリースでの完成の定義のような形です。セキュリティ試験のように毎スプリント実施するのが難しいような項目を、リリースでの完成の定義にいれるわけです。一方で、このような形にすると、スプリントで完成しても、すぐには本番にリリースができないので、状況の変化に柔軟に対応できないこともあります。理想的には、スプリントでの完成の定義とリリースの完成の定義の差分は小さくなるようにしていきましょう。ただし、そうするためには、スクラムチーム全体の成熟が必要になります。

4.4 ドキュメントの扱い

アジャイルマニフェストでは、「包括的なドキュメントよりも動くソフトウェアを」としていますが、これはドキュメントが不要という意味ではありません。「左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく」とあるように、ドキュメント自体にも価値があります。

ドキュメントもプロダクトの性質によって求められるものが変わります。保守・運用の資料はひとたび本番としてリリースしたタイミングから使われることになりますが、最初になければいけないわけではなく、リリース前までに揃っていれば良いでしょう。一方でアーキテクチャーの全体像のようなドキュメントは共通理解を形成する上で、初期から継続的にメンテナンスしていく必要があるかもしれません。つまり、初期の段階で必要なものを明らかにしつつ、必要に応じて追加したり削除していくのがアジャイルなやり方です。また、ドキュメントの作成は必ず手作業でやらなければいけないわけではありません。自動化できるものは自動化しましょう。例えば、APIドキュメントのようなものは、ツールで自動生成できるので、継続的インテグレーションに組み込むことで、一切作業することなく最新のドキュメントを用意し続けることができます。

必ず作成・更新しなければいけないドキュメントがある場合は、完成の定義に含めたり、プロダクトバックログアイテムを追加するようにしてください。

4.5 スプリントにおける活動

スクラムではコーディング作業とテスト作業は密接につながっています。つまり、コーディングやテストとやその他必要な作業が完成し、プロダクトオーナーの受け入れが終わって、はじめてその機能が完了したことになります。

完成の定義を満たしていない（非機能要求が未対応）もの、プロダクトオーナーが受け入れない（機能要求が実現されていない）ものは、スプリントでの成果と見なされません。

4.6 開発環境の作成

初期の段階では、開発に必要な環境の準備も必要です。まず、個人の開発環境を用意します。このとき、後から参加した人が簡単に開発環境を手に入れられるように仮想化や自動化などを組み合わせるようにしましょう。開発環境構築手順書を用意する方法もありますが、ドキュメントのメンテナンスコストや、実際の作業の手間を考えると無駄が多いと言えるでしょう。

個人の開発環境以外には、デモ環境やプロダクトオーナーの受け入れ確認環境も用意しておきましょう。そうすることで最初から継続的に完成したものをリリースできるようになります。そして、継続的インテグレーションサーバーやバージョン管理ツールなど、開発に必要なツールセットも用意しておきましょう。最初に用意しておくことで、統合された環境を作ることが可能になります。

ツールはメジャーなものを使います。そうすることでインターネット上で多くの情報を入手できるようになります。

4.7 テスト自動化の準備

アジャイル開発では、ソフトウェアが動く状態を維持しながら機能を追加していきます。つまり、頻繁に何度もテストをしなければいけません。

小規模リリースのたびに手動でテストすると、コードベースが大きくなるにつれて、テストのコストがどんどん膨らんでいきます。こうなると開発できる機能の量が減っていき、それに伴ってビジネスの成果も減ってしまい良くありません。

スクラムではフレームワークを定義しているだけで、テスト自動化を含む技術的なプラクティスについては一切触れていませんが、事実上はテスト自動化が必須です。品質保証計画や非機能要件を踏まえて、どのようにテストを自動化していくか考えるようにしましょう。

4.8 プラクティスの選択

スクラムを適用する場合には、3つのロール、3つの作成物、5つのイベントすべてを実施しなければいけません。

一方でエクストリームプログラミング（XP）では自分たちが必要なものを選べばよいことになっています。

前述のとおりスクラムには技術プラクティスの定義はないので、XPなどからほかに必要なプラクティスを選択するとよいでしょう。最初から盛り込みすぎると、学習コストが高すぎたり時間がかかりすぎたりするので注意します。また、一度プラクティスを適用したからといって変更できないわけではありません。機能しないプラクティスを外したり、もっとよいプラクティスが見つかれば置き換えてください。

5. 計画やマネジメントの観点

次に、計画やマネジメントの観点を見ていきましょう。

5.1 スケジュールに影響するパラメータ

これから新しいプロダクトを開発する際に、スケジュールをどうやって立てればよいでしょうか。

それを考える上で、まず、スケジュールに影響するパラメーターを見てみましょう。

ビジネス上の都合（マーケティング、新製品発売、法令改正、売上確保など）
予算
開発チーム外への依存関係（QA、セキュリティ）
開発作業のボリューム（スコープ、完成の定義）
開発チームの能力（ベロシティ）

これらは相互に関連する要素で、同時にすべてを固定にすることはできません。したがって、ビジネス上の都合を優先するのか、開発のスコープを優先するのか、など何を優先すべきか共通理解を形成することが重要です。

また初期の時点では、いかなる数字の精度も低いので、スプリントを繰り返しながら適宜見通しを更新していくと良いでしょう。このとき、既に同じチームでほかのプロダクトの開発をしたことがある場合は、チームの能力や経験をそのまま生かせるので、新たなチームで始めるよりも見積り精度は高くなります。

5.2 スプリントの長さを決める

実際にスプリントを開始する前には、スプリントの長さを決めておかなければいけません。スプリントは4週間までの固定の期間です。

期間を決定する上で影響を及ぼすのは以下のような項目です。

想定の期間
変化の度合い
フィードバックの回数
プロダクトの規模
開発チームのキャパシティや場所
完成の定義

たとえば、プロダクト開発の想定期間が3か月だとすると、4週間スプリントではフィードバックサイクルが3周しか回らないことになるので、改善効果が出ません。また不確実性が高くなればなるほど、長い期間のスプリントでは途中の変化に脆弱になってしまいます。これらを踏まえて、小規模や短期間のものであれば1〜2週間とし、大規模であれば2〜4週間にすることが一般的です。なお、直感に反するかもしれませんが、スプリント期間が長いほうが難易度は上がります。

5.3 リスクを管理する

プロダクトの開発を始めた初期の段階では不確実なこと、わからないことだらけです。それらを見ないふりをして先に進めると、途中で大きな問題になってしまうことがあるので、なんらかの形でリスクをバックログ化、見える化しておくと良いでしょう。このバックログは、プロダクトオーナーとスクラムマスターが中心となって対処していきます。

5.4 報告

組織の活動の一環としてプロダクトを開発する以上、なんらかの報告やレポートが必要になることが普通ですが、組織によって必要な内容は異なります。初期の段階で、どんな頻度で、どんな内容を、誰にレポートしないといけないのかを明らかにしておきましょう。

報告の内容は、全体像やリスクを把握できるようなものにとどめる（最初は最低限から始める）ようにしましょう。プロダクトバーンダウンチャートのようなものでも十分なことも多々あります。スプリントの活動を詳細にレポートするのは意味はありません。あくまでもプロダクトの観点やプロダクトに関係するリスクの観点に留めるようにします。

開発チームの時間を報告作業に使うと勿体無いので、自動で作るか、スクラムマスターやプロダクトオーナーが作成するのも良いでしょう。また、レポートに対するフィードバックやそれを受けてのアクションがないなら、レポート自体を廃止するようにして、無駄をなくすようにします。