何かと難しいWeb制作やシステム開発の用語。
このシリーズでは、なるべくわかりやすい説明を目指しています！

---

前回のおさらい

前回の記事では、ウォーターフォール型とアジャイル型の開発方法の違いを説明しました。

従来の開発手法（ウォーターフォール型）は、「作る前に何を作るかしっかり決める」「決められた予算、スケジュール内で実行する」「後からの仕様変更はしない」という方法でした。

一方、アジャイル開発は、「おおまかに全体像や、やることを決めてからスタートする」「短期間で開発・フィードバックを繰り返して、少しずつ作る」「後からの仕様変更もできる」という開発手法です。

今回は、アジャイル開発を始める前の準備について、ステップ式で解説します！

【今回の前提（ルール）】

• アジャイル開発には「スクラム」「XP」「カンバン」など複数のやり方がありますが、今回は「スクラム」について詳しく説明します
• 今回はアジャイル開発（スクラム）を進める前段階の「プロジェクトの立上げ」について説明します

STEP1. まずはアイデアを考えよう！（インセプションフェーズ）

はじめに、「どんなプロダクトを作りたいか？」を大まかに考えます。

プロジェクトの企画やアイデアを練る段階で、プロジェクトの土台となる重要なステップです。

なお、スクラムはチームでどう開発を進めるかについてのフレームワークのため、
企画段階については特に言及されていません。
ただし、あまり時間をかけずに１～２週間程度で行うのが良いとされています。

■インセプションフェーズで実施すること

プロジェクトのビジョン設定	・作るものの目的や目指す方向性を明確にする ・目標を立てる ・KPIなどの成功指標を決める
ステークホルダー（関係者）の特定	・関与する関係者（クライアント、ユーザー、チームメンバーなど）を特定する ・みんなの役割を明らかにする
要件の収集	・ユーザー（プロダクトを使う人）の求めていることや、やりたいことを集める ・プロダクトの基本的な機能を明確にする
初期リスクの評価	リスクを見つけて、はじめの対応策を考える
プロジェクトスコープの概要作成	プロジェクト全体の範囲を大まかに設定する
ユーザーの期待値の整理	ユーザー（プロダクトを使う人）が何を期待しているかをわかるようする
大まかなスケジュールの策定	・大まかなスケジュールを考える ・主要なマイルストーンを決める 　※ウォーターフォール型のマイルストーンとは少し異なります
アジャイル開発について、みんなに説明する	・メンバーや関係者に、アジャイルの基本の考え方やスクラムの決まりについて説明する ・全員で理解をする
アジャイル開発で進めるかを考える	プロジェクトがアジャイル開発（スクラム）に適しているか？を考えて、アジャイルで進めるかを決める

■この時に、アジャイル開発で進めるかを考える

アジャイル開発を成功させるためには、いくつかの条件が必要です。

そのプロジェクトがアジャイル開発（スクラム）に適しているか？を見極めます。

• 不確定要素が多い場合（たとえば、新しい技術を使うなど）
• 要求が変化しやすい場合
• ステークホルダーやチームメンバーがアジャイル開発の基本を理解している
• チームメンバーが自己組織化（自らのタスクを管理できる、各メンバーの業務を柔軟に変更できる）でき、チーム内でのコミュニケーションが得意
• 顧客や関係者が頻繁にフィードバックできる場合
• 競争や変化が激しい市場、技術進化の早い分野

これらの内容に合っている場合には、アジャイルの柔軟性が役立ちます。

アジャイル開発が向いていそうであれば、次のステップへ進みます。

■スクラムの基本理念や方針を伝えるには？

スクラムの基本の考え方やルールを伝えるための資料として、以下のスクラムガイドの使用がおすすめです。

スクラムの聖書のような存在で、無料で公開されています。
18ページと少なく、読みやすい内容です。ぜひ一度見てみてはいかがでしょうか。

スクラムガイド（Ken Schwaber & Jeff Sutherland）2020年11⽉版

STEP2. プロダクトを作る準備をしよう！（スプリント0）

アジャイル開発（スクラム）で開発を進めることが決まったら、いきなりスプリントを始めるのではなく、まずは準備をします。

この準備のことを、「準備フェーズ」や「スプリント0」と呼びます。
プロジェクトによっては、インセプションフェーズとスプリント0を合わせて行う場合もあります。

インセプションフェーズとスプリント0はいくつかのステップに分かれていますが、
あまり時間をかけずに１～2週間、最長でも1ヵ月で終わらせることが望ましいです。

なるべく早く初めのスプリントを行い、みんなからのフィードバックを得ることが大切です。

STEP2_1. 要件の収集と事前調査

まずは要件を収集したり、事前調査を行います。

このあたりはウォーターフォール型とあまり変わりません。

ステークホルダーからの要件ヒアリング	プロダクトオーナー（PO）が、お客様やステークホルダー（利害関係者）と顔を合わせて、ビジネスの目的や課題を聞く ※プロダクトオーナー（PO）は、そのプロダクトで何を作るべきか、何が価値あることなのかをみんなに示す、プロダクトの責任者のことです
プロジェクトの方向性をチームで確認する	・そのプロジェクトで何をするのか、何を作るのかをより具体的にする ※インセプションデッキを使って明確化するのがおすすめ その他にも、 ・ペルソナ ・カスタマージャーニーマップ ・バリュープロポジションキャンバス ・業務フロー図 ・はじめのプロトタイピング、ワイヤーフレーム などはこの時に作ることが多いです
要件整理と優先順位の確認	・絶対に欲しいもの、あったらいいものを分類する ・何からやるか、優先順位をつける
技術的な事前調査・リサーチ	・チームで技術的な調査や検証をする ・むずかしい機能や、やったことのない技術を使う時は、必要に応じてプロトタイピングも行う
リスクの見積もりと対策	事前調査をもとに、プロジェクトの障壁となりそうなリスクを見つけて、対策を考える
コミュニケーションの方法	スプリント内でチームがどのようにコミュニケーションをとるか、大まかに決める

■インセプションデッキ

プロジェクトのビジョンを確認するための方法として、「インセプションデッキ」というものがあります。アジャイル開発ではプロジェクトのビジョンを明確にするために、多くのチームで最初に使われているので、使ってみると良いでしょう。

なお、GitHubでテンプレートが無料で公開されています。

インセプションデッキテンプレート

STEP2_2. チーム編成と責任

次にメンバーを集めて役割や責任を確認します。

スクラムには「３つのロール」があり、各メンバーが責任を持って開発に携わります。

それぞれの役割と責任については以下の通りです。

▼スクラムの3つのロール

ロール	役割	人数	責任
プロダクトオーナー（PO）	プロダクトの責任者	1人	・お客様やステークホルダーとのコミュニケーション ・プロダクトの価値を最大化する ・プロダクトバックログの作成（※みんなでの話し合いを元に作る） ・プロダクトバックログの並び替え ・プロダクトバックログの管理 ※プロダクトバックログの並び順、内容を変える時は、プロダクトオーナーを説得する
スクラムマスター（SM）	リーダー・進行役	1人	・チームがスクラムの理論を理解したり、使いこなすためのコーチングや手助けをする ・チームの障壁を取り除く ・チームが効率的に動けるように助ける ・スプリントの5つのイベントの企画や進行をする ・プロダクトオーナーの手助けをする
開発チーム	実行役・クリエイター	3人～9人	・スプリントバックログの作成、管理（スプリント毎の要求整理、タスクの分解、タスク管理） ・開発作業（設計、プログラミング、デザイン） ・テスト ※分業ではなく、みんなが複数のタスクをこなす

スクラムチームは、開発者、デザイナー、テスター、ビジネスアナリストなど、異なるスキルを持つメンバーの参加が理想とされていますが、開発チーム内では肩書などで明確に担当範囲を分けることはしません。

異なる専門スキルを持つメンバーが、複数の業務を行う（＝機能横断的）になることが求められます。

■プロダクトオーナーとスクラムマスターは同じ人でもよいのか？

スクラムガイドでは禁止されていませんが、一般的には同じ人がやるのは避けるべきとされています。

プロダクトオーナーはプロダクトの価値を最大化することに責任があるのに対し、
スクラムマスターはチームが効率的に動けることに責任を持ち、
お互いの目的や責任が対立することがあるからです。

STEP2_3. プロダクトバックログの作成

次にヒアリングで集めた要件をもとに、全体のやることリストを作り、優先順位を決めます。

これを「プロダクトバックログ」と言います。
タスク１つ１つは「プロダクトバックログアイテム」と言います。

プロダクトバックログは並び順が上のものから開発するので、優先度に応じて並び替えます。

そして、大体の作業量を見積ります。

■プロダクトバックログの作成は誰がする？

プロダクトバックログの作成は、プロダクトオーナーが担当します。

ただし、タスクの洗い出しはチームメンバーで話し合いながら決める方が良いでしょう。
オンライン付箋サービスなどを使って、話し合いながらタスクを洗い出し、優先順位ごとに並び替え、作業量を見積ります。

その後、プロダクトオーナーが管理がしやすいツール等に反映し、みんながいつでもプロダクトバックログを見れるように完成させるイメージです。

プロダクトオーナーはプロダクトバックログの並び替えにも責任があり、優先順位を変える時は、プロダクトオーナーを説得します。

■プロダクトバックログの形式は？

スクラムでは、プロダクトバックログの形式は特に決まりがありません。

多くのチームではユーザーストーリー形式が使われている傾向があります。
タスク形式の場合もあります。

プロダクトバックログを作る際は、詳細レベルまで作り込む必要はありませんが、
重要な項目が漏れないようにすることが大切です。

▼ユーザーストーリー形式の例

ID	ユーザーストーリー	優先度	推定作業量	説明	ステータス	受け入れ基準
PB1	ユーザーとして、アカウントを登録したい、その結果プラットフォームの機能にアクセスできるようにするため。	高	8	ユーザーがアカウントを作成できるようにする機能。	未着手	– ユーザー名、メールアドレス、パスワードを入力できる – アカウント登録後、確認メールが送信される – 登録した情報がデータベースに保存されている
PB2	既存ユーザーとして、アカウントにログインしたい、その結果自分のプロフィールや個別設定にアクセスできるようにするため。	高	5	既存ユーザーがログインできる機能。	未着手	– 正しいユーザー名とパスワードでログインできる – 誤った情報でログインした場合、エラーメッセージが表示される – ログイン後、ダッシュボードにリダイレクトされる
PB3	ユーザーとして、プロフィール情報を編集したい、その結果自分の詳細を最新の状態に保てるようにするため。	中	3	ユーザーがプロフィールを編集できるようにする。	未着手	– プロフィール編集画面が表示される – 入力した情報が正しく更新される – 更新後、成功メッセージが表示される
PB4	ユーザーとして、ログイン後にダッシュボードを表示したい、その結果重要な情報に簡単にアクセスできるようにするため。	中	8	ユーザーがログイン後に表示されるダッシュボード。	未着手	– ダッシュボードがユーザーのログイン後に表示される – 必要な情報（通知、メニュー等）が正しく表示される
PB5	ユーザーとして、パスワードをリセットしたい、その結果アカウントへのアクセスを回復できるようにするため。	中	5	ユーザーがパスワードをリセットできる機能。	未着手	– パスワードリセットリクエストが成功する – リセット用のリンクが含まれたメールが送信される – 新しいパスワードでログインできる
PB6	テスト担当者として、テスト環境用の初期データを作成したい、その結果テストがスムーズに進行できるようにするため。	低	2	テスト環境用の初期データを作成する。	未着手	– 初期データが正しくデータベースに保存される – テスト用データが利用可能である
PB7	デザイナーとして、ユーザーインターフェースの初期デザインを作成したい、その結果ユーザー体験を向上させるため。	中	5	ユーザーインターフェースの初期デザインを作成。	未着手	– デザインプロトタイプが完成している – ステークホルダーからフィードバックを受け取る
PB8	プロジェクトマネージャーとして、使用する技術を決定したい、その結果開発環境を整えるため。	高	1	使用する技術（言語、フレームワーク等）を決定する。	完了	– 技術スタックが文書化されている – 関連するチームメンバーと共有されている
PB9	プロジェクトマネージャーとして、プロジェクトの主要なマイルストーンを設定したい、その結果スケジュールを管理できるようにするため。	高	2	プロジェクトの主要なマイルストーンを設定。	完了	– マイルストーンが明確に定義されている – スケジュールに組み込まれている

▼タスク形式の例

ID	タスク名	優先度	推定作業量	説明	ステータス	受け入れ基準
PB1	ユーザー登録機能の実装	高	8	ユーザーがアカウントを作成できるようにする機能。	未着手	– ユーザー名、メールアドレス、パスワードを入力できる – アカウント登録後、確認メールが送信される – 登録した情報がデータベースに保存されている
PB2	ログイン機能の実装	高	5	既存ユーザーがログインできる機能。	未着手	– 正しいユーザー名とパスワードでログインできる – 誤った情報でログインした場合、エラーメッセージが表示される – ログイン後、ダッシュボードにリダイレクトされる
PB3	プロフィール編集機能の実装	中	3	ユーザーがプロフィールを編集できるようにする。	未着手	– プロフィール編集画面が表示される – 入力した情報が正しく更新される – 更新後、成功メッセージが表示される
PB4	ダッシュボードの作成	中	8	ユーザーがログイン後に表示されるダッシュボード。	未着手	– ダッシュボードがユーザーのログイン後に表示される – 必要な情報（通知、メニュー等）が正しく表示される
PB5	パスワードリセット機能の実装	中	5	ユーザーがパスワードをリセットできる機能。	未着手	– パスワードリセットリクエストが成功する – リセット用のリンクが含まれたメールが送信される – 新しいパスワードでログインできる
PB6	テスト用データの作成	低	2	テスト環境用の初期データを作成する。	未着手	– 初期データが正しくデータベースに保存される – テスト用データが利用可能である
PB7	フロントエンドデザインのプロトタイプ	中	5	ユーザーインターフェースの初期デザインを作成。	未着手	– デザインプロトタイプが完成している – ステークホルダーからフィードバックを受け取る
PB8	技術スタックの決定	高	1	使用する技術（言語、フレームワーク等）を決定する。	完了	– 技術スタックが文書化されている – 関連するチームメンバーと共有されている
PB9	プロジェクトスケジュールの作成	高	2	プロジェクトの主要なマイルストーンを設定。	完了	– マイルストーンが明確に定義されている – スケジュールに組み込まれている

■作業の見積もりは、誰がどのようにする？

作業の見積りは、実際に作業をする開発チームの全員で決めます。
見積り方法は決まっていませんが、多くのチームでは、お金や時間ではなく、相対的な作業量を人月やポイント制で見積ります。

ざっくり「大」「中」「小」で分けて5段階評価する方法も考えれます。
分類した後、「中」の項目から、具体的に作業がイメージできるものを1つ選び、それを5段階評価で3（＝3ポイント）と仮定します。
その3ポイントの作業をベースに、他のアイテムの作業量を評価していきます。

ウォーターフォール型とは異なり、おおよその作業量と全体のスケジュールの見通しを立てるものなので、素早く行うことが大切です。

■おおよそのスケジュールを知るには？

プロダクトバックログの項目を見積もると、どのくらいの時期に、どの程度までできるかの見通しが立てられます。

例えば、プロダクトバックログに3ポイントの作業が10個あると、合計30ポイントになります。
そして、1スプリント（2週間）で10ポイント分の作業ができると仮定します。
1スプリントでこなせる作業量を「ベロシティ」と呼びます。
すると、合計：30ポイント ÷ ベロシティ：10ポイント= 3プリントとなり、6週間が必要なことがわかります。

このような形で、スクラムの場合でも、おおよそのスケジュールがわかります。

ベロシティは過去の同様に事例を参考にしたり、実際に計測して出します。
できればスプリントが始まる前か初期に、実際にプロダクトバックログのうちの１つをやってみて、チームがどのくらいのスピードでこなせるか、計測して調整する形が良いでしょう。

STEP2_4. ツールと環境の整備

次にツールと開発環境の構築を行います。

タスク管理ツール	JIRA、Backlog、Trelloなどのタスク管理ツールを決めて各メンバーが使えるようにする
コミュニケーションツール	Slack,Chatworkなどのコミュニケーションツールを決めて、各メンバーが使えるようにする
リポジトリ	Gitリポジトリなどを準備する
開発環境のセットアップ	開発環境の構築をする

STEP2_5. スプリント計画の策定

次に実際のスプリントについてルール設定を行います。

また、このタイミングで、最低でも1回目のスプリントで取り組む内容を具体的にしておきます。

スプリントの期間設定	１～４週間の範囲で、スプリントの期間を設定する ※スプリントは毎回同じ期間となるので、プロジェクトやチームに合った期間を設定する ※あるスプリントだけ期間を変える、ということは原則できない
スプリント毎の目標設定	初回のスプリントの目標を設定する
バックログの優先順位付け	初回のスプリントで取り組むアイテムと、バックログアイテムの優先順位を決める
タスクの分解	初回スプリントで取り組むアイテムに対して、必要なタスクを大まかに分解する
リソースの準備	スプリントで必要となるリソース（環境、ツール、メンバーの役割など）を確認し、準備する
リスクの洗い出し	初期のリスクや懸念点を洗い出し、どう対処するかを考える
コミュニケーションの枠組み	チーム内のコミュニケーションや進み具合の確認方法を決める

STEP2_6. 定例ミーティングのスケジュール設定

次に各ミーティングのスケジュールを決めます。

どのくらいの頻度で、どのくらいの時間行うかを決めて多くと、チームメンバーがスムーズに参加できます。

▼ミーティングについて決めること（※目安時間は、1スプリント2週間と仮定した場合）

イベント	頻度	タイミング	目安時間	説明
スプリントプランニング	スプリントごとに1回	スプリントの開始時	2～4時間	・スプリントの目標を設定 ・スプリントバックログを作成する
デイリースクラム	毎日	毎朝	15分	・チームメンバーが1人ずつ 　・昨日やったこと 　・ ・問題や障害について共有する
スプリントレビュー	スプリントごとに1回	スプリントの最後	1～2時間	・完成したプロダクトの成果をステークホルダーにデモする ・フィードバックを受ける
スプリントレトロスペクティブ	スプリントごとに1回	スプリントの終了後	1~1.5時間	・スプリントの終了後に行われる ・チームの振り返りを行う ・何がうまくいったのか、何を改善できるのかを話し合う ・次回のスプリントに反映する

STEP2_7. 基本方針のドキュメント化

アジャイル開発では、ドキュメントは最小限を前提としていますが、重要なものはドキュメント化を行います。

以下は主な基本方針のリストです。

項目	説明
プロジェクトビジョン	プロジェクトの目的や目指す方向性を明確にする。
ステークホルダー	プロジェクトに関与する重要な関係者をリストアップし、それぞれの期待や役割を明確にする。
プロジェクトのスコープ	プロジェクトで対応する範囲（機能、要件）を定義し、何が含まれ、何が含まれないかを明確にする。
要件の収集	エンドユーザーやクライアントからの要件を収集し、ドキュメント化する。
成功基準	プロジェクトの成功をどのように測定するかを定義する（例：納期、品質、顧客満足度など）。
リスク管理方針	プロジェクトにおけるリスクの特定、評価、対策を計画する。
コミュニケーション計画	チーム内およびステークホルダーとのコミュニケーション方法、頻度、ツールを定義する。
変更管理プロセス	要件や計画の変更をどのように管理するかのプロセスを説明する。
開発プロセス	開発に使用する方法論（例：アジャイル、スクラムなど）やフレームワークを明示する。
品質管理方針	プロジェクトの品質をどのように確保するかの方針や基準を定義する。
リリース計画	プロダクトのリリースタイミングやリリースの要件について記載する。

STEP2_7. チームビルディングと信頼関係の構築

最後に、自己紹介や得意分野の共有などを行い、意見交換がしやすい雰囲気づくりを行います。

以下は、チームビルディングと信頼関係の構築によく使われているアイデアです。

活動/アプローチ	説明	目的
アイスブレイク	初対面のメンバー同士が緊張を和らげるための自己紹介や簡単なゲームを行う	メンバー間の親近感を高める
オープンな対話	意見を自由に交換できる環境を作る。メンバーが考えや懸念を気軽に話せるようにする	コミュニケーションの改善
チームイベント	業務外での交流を促進するためのイベント（飲み会、スポーツなど）を開催し、メンバー間の関係を深める	社会的なつながりを強化し、チームの親密感を高める

心理的安全性の大切さ

心理的安全性は、チームメンバーが自由に意見を言ったり、質問をしたり、間違いを恐れずに発言できる環境を指します。

スクラムではメンバー同士のコミュニケーションが大切なので、心理的安全性が確保されることで、チーム全体のパフォーマンスが向上し、より良い成果を生むことができます。

まとめ

アジャイル型でも、ウォーターフォール型と同じく、目的やゴールの明確化・要件の整理など、はじめの準備が必要となります。

あとあと大きな漏れが出ないよう、しっかりとかつ、スピード感をもって準備していきたいですね。

次回は、スクラムの基本理念や、スクラムイベント、作成物などについて解説します！

▼参考情報

SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発

スクラムガイド（Ken Schwaber & Jeff Sutherland）2020年11⽉版

スクラムガイド（LeSS版）2024年7月版

IPA アジャイル領域へのスキル変革の指針「アジャイル開発の進め方」2025年5月版

スプリント1を始める前にどんな準備をするか