アジャイル開発とは？スクラムとJiraを使った開発の進め方
最近、業務委託エンジニアとしてジョインした会社では、アジャイル開発のフレームワークとしてスクラムを採用しています。
これまで参画した会社でもアジャイル開発やスクラムを経験したことはありましたが、正直なところ、仕組みや考え方を深く理解しないまま、なんとなく進めていました。
そこで今回を良い機会として、「そもそもアジャイル開発とは何なのか？」「スクラムではどのように開発を進めるのか？」について改めて調べ、実際の開発現場で使われているJiraの使い方も含めて整理してみました。
これからアジャイル開発やスクラムに参加する方の参考になれば幸いです☺️
1. アジャイル開発とは？
まずは、スクラムを理解する土台となる「アジャイル開発」の意味と、基本的な考え方を押さえておきましょう。
アジャイル（Agile）とは
アジャイル（Agile）は、英語で「機敏な」「素早い」といった意味を持つ言葉です。
ソフトウェア開発では、小さな単位で開発と検証を繰り返し、状況の変化に柔軟に対応しながら、ユーザーに価値を届けていく考え方を指します。
開発を進めていると、「実際に使ってみると操作しづらい」「当初の想定とは違う機能が必要だった」と気づくことがあります。
アジャイル開発では、こうした気づきを次の開発に取り入れ、プロダクトを少しずつ改善していきます。早く作ることだけでなく、作ったものから学び、必要に応じて方向を調整することが大切です。
アジャイル開発の基本的な考え方
アジャイル開発の土台となる「アジャイルソフトウェア開発宣言」では、開発において大切にする価値観が示されています。
内容をかみ砕くと、次のように整理できます。
-
人との対話を大切にする
ツールや手順だけに頼らず、チーム内で相談し、認識を合わせながら進めます。 -
実際に動くソフトウェアで確かめる
資料上の説明だけでなく、動くものを通じて、必要な機能になっているかを確認します。 -
顧客と協力して開発する
顧客や関係者と継続的にやり取りし、実現したいことへの理解を深めます。 -
変化に合わせて計画を調整する
新しい情報やフィードバックを踏まえて、対応する内容や優先順位を見直します。
もちろん、ドキュメントや計画も必要です。そのうえで、対話や実際の動作確認を通じて得られた情報を重視します。
小さな単位で開発と改善を繰り返す
アジャイル開発では、機能を小さく分け、作る → 確認する → フィードバックを得る → 改善するというサイクルを繰り返します。
例えば、ECサイトの商品検索機能を開発する場合を考えてみましょう。
-
商品名で検索できる機能を作る
まずは基本的な検索機能を、実際に動く状態にします。 -
使ってもらい、フィードバックを集める
「商品が多くて探しにくい」「価格で絞り込みたい」といった意見を確認します。 -
優先度の高い改善を加える
得られた意見をもとに、価格帯による絞り込みなどを追加します。
ここでのポイントは、単に作業を細かく分割するだけでなく、ユーザーや関係者が使って確認できる機能に区切ることです。
小さく作って確かめることで、認識のずれに早く気づき、次に何を作るべきかを判断しやすくなります。
アジャイルとスクラムの関係
アジャイルとスクラムは、一緒に使われることが多い言葉ですが、それぞれ指しているものが異なります。
アジャイルは開発における考え方や価値観であり、スクラムは、その考え方を実践するために使われるフレームワークの一つです。
フレームワークとは、チームで仕事を進めるための基本的な枠組みのことです。
スクラムでは、「スプリント」という一定の期間で開発を進め、成果を確認しながら、プロダクトとチームの進め方を改善します。そのために、チームの役割や、計画・確認・振り返りの機会などが定められています。
本記事では、アジャイルの考え方を土台に、スクラムでどのように開発を進めていくのかを紹介します。
2. スクラムとは？
スクラムの基本的な考え方
スクラムは、チームで小さく開発し、結果を確認しながら改善を繰り返すためのフレームワークです。
開発では、実際に作ってみて初めて分かることもあります。スクラムでは、その経験から学び、次の判断に生かすことを大切にします。
土台となるのが、次の3つです。
| 考え方 | 内容 |
|---|---|
| 透明性 | 作業の状況や課題を、関係者が理解できる状態にする |
| 検査 | 成果や目標への進み具合を確認する |
| 適応 | 確認した結果をもとに、計画や進め方を調整する |
例えば、開発中に仕様の認識違いが見つかった場合は、チームで共有し、必要な対応を相談します。こうした確認と調整を継続することが、スクラムの基本です。
スプリントとは？
スプリントとは、スクラムで開発を進めるための、1か月以内の固定された期間です。
例えば、2週間を1スプリントとして開発を繰り返します。
スプリントの開始時には、「今回、何を達成したいのか」というSprint Goal（スプリントゴール）を決めます。
ECサイトであれば、次のような目標が考えられます。
ユーザーが商品名で検索し、欲しい商品の詳細を確認できるようにする。
この目標に向けて、必要な作業を計画し、実装やテストを進めます。
スプリントには、開発だけでなく、計画・毎日の確認・成果の確認・振り返りも含まれます。終了したら、すぐに次のスプリントが始まります。
目指すのは、完成の基準を満たし、利用できる成果を生み出すことです。
なお、リリースをスプリント終了まで待つ必要はなく、準備が整えば途中でも提供できます。
スクラムチームの役割
スクラムチームには、次の3つの役割があります。厳密には、スクラムガイドで定められた「責任」の区分です。
1. Product Owner（プロダクトオーナー）
プロダクトの価値を最大化する責任を持つ人です。
プロダクトが目指す方向を示し、必要な機能や改善をまとめた「Product Backlog（プロダクトバックログ）」の内容と順序を管理します。
例えば、「検索機能の改善とクーポン機能の追加のどちらを優先するか」を、ユーザーのニーズや事業上の目的を踏まえて判断します。
2. Scrum Master（スクラムマスター）
チームがスクラムを理解し、効果的に実践できるよう支援する人です。
チームの進め方の改善を助け、開発を妨げる問題が解消されるよう働きかけます。
例えば、他部署への確認が滞って作業が止まっているときに、連携方法の改善を支援します。チームが自分たちで判断し、協力して進められる環境を整える役割です。
3.Developers（開発者）
各スプリントで、利用できる成果を作る人たちです。
必要な作業を計画し、品質を確保しながら開発を進めます。また、スプリントゴールの達成に向けて、日々の状況に応じて計画を調整します。
ここでいうDevelopersには、プログラマーだけでなく、成果を作るために必要なデザインやテストなどを担うメンバーも含まれます。
3. Jiraを使ったタスク管理
スクラム開発では、「何を作るのか」「誰が何を進めているのか」「どこまで完了しているのか」をチームで共有できる状態にしておくことが重要です。
そのためのタスク管理ツールとして、よく利用されているのがJiraです。
Jiraを使うと、開発する機能や修正内容をチケットとして登録し、優先順位や担当者、進捗状況などを管理できます。
スクラムでは、Product BacklogやSprintの管理にもJiraを利用できます。
Jiraとは？
Jiraは、Atlassianが提供しているプロジェクト管理・課題管理ツールです。
https://www.atlassian.com/ja/software/jira
ソフトウェア開発では、例えば次のような情報をJiraのチケットとして管理します。
- 新しく開発する機能
- 既存機能の改善
- バグ修正
- 技術的な調査
- テスト
- その他の開発作業
各チケットには、タイトルや説明だけでなく、担当者、優先度、ステータス、Story Pointなどの情報を設定できます。
Jiraの基本的な構造
Jiraでは、開発する内容をいくつかの階層に分けて管理できます。
代表的な構造は次のようなイメージです。
Epic：大きな機能・テーマ
↓
Story / Task / Bug：実際に対応する機能や作業
↓
Subtask：必要に応じて、さらに細かく分けた作業
Epicとは？
Epicは、複数のStoryやTaskをまとめる、大きな機能や開発テーマです。
通常、Epicそのものを1つのSprintですべて完了させるとは限りません。
複数のSprintにまたがって開発するような、比較的大きな単位として利用されます。
例えばECサイトであれば、次のようなものがEpicとして考えられます。
- 商品検索機能
- 会員登録機能
- 決済機能
- クーポン機能
- 管理画面改善
例えば「商品検索機能」というEpicを作成した場合、その中に、
- 商品名で検索できる
- カテゴリで検索できる
- 価格帯で絞り込める
- 検索結果を並び替えられる
といったStoryを紐づけて管理できます。
Epicを使うことで、個々のチケットだけを見るのではなく、「今、どの大きな機能を開発しているのか」を把握しやすくなります。
Story / Task / Bugとは？
Epicの下には、実際に開発・対応する単位として、Story、Task、Bugなどのチケットを作成します。
Story
Storyは、ユーザーに提供したい価値や機能を表すチケットとして利用されることが多いです。
例えば、ユーザーとして、商品名から商品を検索できるようにしたい。目的の商品をすぐに見つけるため。といった形です。
ECサイトであれば、下記がStoryになります。
- 商品名で検索できる
- カートに商品を追加できる
- 注文履歴を確認できる
Storyは、単なる「プログラムを書く作業」ではなく、ユーザーやプロダクトにとって意味のある機能単位で作ることがポイントです。
Task
Taskは、実施する必要がある具体的な作業を管理するためのチケットです。
例えば、下記のような作業です
- 外部APIの仕様を調査する
- データベースのインデックスを追加する
- 開発環境をアップデートする
- ログ監視の設定を追加する
ユーザーに直接見える機能ではなくても、開発上必要な作業をTaskとして管理できます。
Bug
Bugは、既存機能で発生している不具合を修正するためのチケットです。
例えば、下記のような作業です
- 検索結果が正しく表示されない
- ログイン後にエラー画面が表示される
- 特定のブラウザでボタンが押せない
BugもStoryやTaskと同じように、優先度を設定し、必要に応じてSprintへ追加して対応します。
なお、Story / Task / Bugの使い分けは、チームによって多少異なります。
Subtaskとは？
Subtaskは、StoryやTaskなどのチケットを、さらに細かい作業単位へ分割するためのチケットです。
Story:商品名で検索できるようにする
というStoryがあった場合、次のようにSubtaskへ分けることができます。
Subtask:検索APIを実装する
Subtask:検索フォームを実装する
Subtask:検索結果画面を実装する
Subtask:テストコードを書く
1つのStoryを複数人で分担したい場合や、必要な作業を明確にしたい場合に便利です。
Jiraでの管理イメージ
まとめると、Jiraでは次のような形でタスクを管理します。
Epic：大きな機能・テーマ
↓
Story / Task：実際に実現したい機能・作業
↓
Subtask：必要に応じてさらに細かく分割
↓
Sprintに入れて開発
Jiraは単なる「やることリスト」ではなく、プロダクトで実現したいことを開発可能な単位へ分解し、スクラムの流れの中で管理するためのツールとして利用できます。
4. スプリント開始前の準備
スプリントを始める前には、「次のスプリントで何を開発するのか」を決めるための準備を行います。
いきなりSprintへチケットを追加するのではなく、まずProduct Backlogにある項目を整理し、内容や優先順位、作業量を確認します。
大まかな流れは次のようになります。
Product Backlogを確認する
↓
Backlog Refinementでチケットを整理する
↓
Story Pointで作業量を見積もる
↓
優先順位を確認する
↓
Sprint Planningで対応するチケットを決める
Product Backlogとは？
Product Backlogは、今後対応する機能追加、改善、バグ修正などをまとめた一覧です。
Jiraでは、Story、Task、BugなどのチケットとしてBacklog上で管理します。
すべてをすぐに開発するのではなく、重要度やユーザーへの価値を考えながら優先順位をつけます。
Backlog Refinementとは？
Backlog Refinementは、Product Backlogのチケットを開発できる状態に整理する活動です。
例えば、次のような点を確認します。
- チケットの目的
- 仕様や完了条件
- 不明点の有無
- チケットの大きさ
- Story Point
大きすぎるStoryは、必要に応じて複数のStoryへ分割します。
Story Pointで作業量を見積もる
Story Pointは、作業量や複雑さ、不確実性などを相対的に表す値です。
例えば、1 / 2 / 3 / 5 / 8 / 13といった数値を使います。
Story Pointは作業時間そのものではなく、このチケットは、あのチケットよりどのくらい大きいかをチーム内で比較するために使います。
優先順位を決める
Product Ownerを中心に、Product Backlogの優先順位を整理します。
例えば、次のような観点があります。
- ユーザーへの価値
- 事業上の重要度
- 緊急度
- 他の機能への影響
- 不具合の影響範囲
基本的には、価値や重要度の高い項目から優先して検討します。
Sprint Planningで対応するチケットを決める
Sprint Planningでは、次のSprintで何を達成するのか、どのチケットに取り組むのかを決めます。
まずSprint Goalを決め、その達成に必要なProduct Backlogの項目を選びます。
その際、Story Pointや過去の開発量、チームの状況なども参考にしながら、Sprint内で対応できる範囲を決めます。
ここまで準備ができたら、Sprintを開始して開発を進めていきます。
5. スプリントを開始する
Sprint Planningで決めた目標や開発内容をJiraに反映し、スプリントを開始します。
JiraでSprintを作成する
JiraのBacklog画面でSprintを作成します。スプリント名や開始日・終了日を設定し、例えば2週間など、チームで決めた期間で開発を進めます。
Sprint Goalを設定する
Sprint Planningで合意した「今回のスプリントで達成したい目標」を設定します。
例えば、ECサイトであれば、「ユーザーが商品名で検索し、欲しい商品の詳細を確認できるようにする」といった目標です。
単にチケットを消化するのではなく、チームで共通の目標を持つことが大切です。
チケットをSprintに追加する
Product Backlogから、Sprint Planningで選んだStory、Task、BugなどのチケットをSprintに追加します。
チームの作業可能な時間や過去の開発量を参考に、無理のない範囲で計画します。目標やチケット、期間を確認したら、Sprintを開始します。
To Do / In Progress / Review / Doneで進捗を管理する
開発が始まったら、作業状況に合わせてチケットのステータスを更新します。
| ステータス | 状態 |
|---|---|
| To Do | 未着手 |
| In Progress | 作業中 |
| Review | レビュー・確認中 |
| Done | 完了 |
ボードを見ることで、誰が何を進めていて、どこで作業が止まっているのかを共有できます。
ステータスはチームによって異なりますが、Doneにするのは、必要なレビューやテストなど、チームで決めた完成の基準を満たしてからです。
6. Daily Scrumで毎日の進捗を確認する
スプリント中は、Daily Scrumで目標への進み具合を確認し、その日の作業や協力が必要なことをチームで相談します。
Daily Scrumとは？
Daily Scrumは、開発者が毎日行う15分間のミーティングです。
Sprint Goalへの進捗を確認し、必要に応じて作業計画を調整します。
Daily Scrumで何を確認するのか
主に、次のような点を確認します。
- Sprint Goalに向けて順調に進んでいるか
- 次に何を進めるか
- 困っていることや、協力が必要なことはあるか
確認した内容をもとに、優先する作業や分担を調整します。
現在進めているチケットを確認する
作業中やレビュー待ちのチケットについて、現在の状況と完了までに必要な作業を共有します。
例えば、「実装は完了しているので、今日はレビューとテストを進める」といった形で、次の行動を明確にします。
Blocker（障害）がないか確認する
Blockerとは、作業を進める妨げになっている問題です。例えば、仕様が不明、必要な権限がない、外部チームの対応を待っている、といった状況が該当します。
問題があれば共有し、誰がどのように対応するかを相談します。詳しい議論が必要な場合は、終了後に関係者で話し合います。
Jiraのボードを見ながら進捗を共有する
Jiraのボードを見ながら、In ProgressやReviewのチケットを確認します。長く止まっている作業やレビュー待ちに注目すると、協力が必要な箇所を見つけやすくなります。
目標の達成に向けて、今日チームで何を進めるかをそろえることが大切です。
7. 開発・レビュー・テストを進める
スプリントで対応するチケットをもとに、実装・レビュー・テストを進めます。作業状況はJiraに反映し、チームで共有します。
Jiraのチケットを担当する
チームで分担を相談し、対応するチケットの担当者を設定します。着手する前に、チケットの目的や仕様、完了条件を確認します。
チケットのステータスを更新する
作業を始めたら、チケットをTo DoからIn Progressへ変更します。その後も、レビュー中はReviewにするなど、実際の状況に合わせて更新します。
実装する
チケットの内容に沿って、機能の追加や修正を行います。不明点があれば、Product Ownerやチームに確認しながら進めます。
Pull Requestを作成する
変更内容を確認し、Pull Request（PR）を作成します。何を、なぜ変更したのか、どのように動作確認したのかを記載し、関連するJiraのチケットも紐づけます。
Code Reviewを行う
チームのメンバーがコードを確認し、仕様を満たしているか、不具合や保守性の問題がないかをチェックします。指摘があれば修正し、再度確認してもらいます。
テストする
機能が想定どおりに動くか、既存の機能に影響がないかを確認します。正常な操作だけでなく、入力ミスやエラー時の動作もチェックします。
なお、テストはレビュー後だけでなく、実装中にも行います。
Doneまで進める
必要なレビューやテストを終え、チームで定めたDefinition of Done（完成の定義）を満たしたら、チケットをDoneへ変更します。
コードを書き終えた時点ではなく、品質を確認し、利用できる成果になったことを確かめて完了とします。
8. Sprint Reviewを行う
スプリントの終わりに、完成した成果を関係者と確認し、次に何を進めるかを話し合います。
Sprint Reviewとは？
Sprint Reviewは、スプリントの成果を確認し、今後の開発に必要な調整を話し合う場です。
スクラムチームと関係者が参加し、成果や状況の変化を踏まえて、次に取り組む内容を検討します。
スプリントで完成した機能を確認する
Sprint Goalに対して、何を達成できたかを確認します。完成した機能に加え、未完了の項目や、開発中に分かった課題も共有します。
実際に動く機能をデモする
完成した機能を実際に操作し、動作や使い方を紹介します。
例えば商品検索機能であれば、キーワードを入力し、検索結果から商品詳細を開く流れを見せます。
Product Ownerや関係者からフィードバックを受ける
デモをもとに、使いやすさや業務上のニーズを満たしているかについて意見をもらいます。
「価格でも絞り込みたい」などの要望があれば、その背景や必要性も確認します。
フィードバックをProduct Backlogへ反映する
話し合いで見つかった改善点や新しい要望を、必要に応じてProduct Backlogへ追加・反映します。
すべてを次のスプリントで対応するのではなく、Product Ownerが価値や重要度を踏まえて順序を見直します。
9. Retrospectiveで振り返る
スプリントの終わりに、チームの仕事の進め方を振り返り、次のスプリントで取り組む改善を決めます。
Retrospectiveとは？
Retrospectiveは、チームの品質や働き方を改善するための振り返りの場です。
コミュニケーションや作業手順、ツールの使い方などを確認し、より良く開発を進める方法を話し合います。
スプリントで良かったこと
うまくいった取り組みや、継続したい工夫を共有します。
例えば、「早めに相談したことで手戻りを防げた」「レビューを分担して待ち時間を減らせた」といったことです。
問題だったこと
作業が進みにくかった原因や、困ったことを共有します。
例えば、「仕様が曖昧で実装中に確認が増えた」「レビュー待ちが長くなった」といった課題です。個人を責めず、仕組みや進め方に目を向けることが大切です。
次のスプリントで改善すること
見つかった課題から優先して取り組むものを選び、具体的な行動を決めます。
例えば、「着手前に完了条件を確認する」「毎日レビュー待ちを確認する」など、実行できる内容にします。
改善内容を次のSprintへ反映する
決めた改善は、チームの作業ルールや、必要に応じて次のSprint Backlogへ反映します。誰がいつ取り組むかも明確にします。
次の振り返りでは、改善を実行できたか、効果があったかを確認し、さらに調整していきます。
10. Velocityでチームの開発量を把握する
スプリントが終了したら、Velocityを確認し、次のSprint Planningに活用します。
Velocityとは？
Velocity（ベロシティ）とは、チームが1回のスプリントで完了できた作業量を表す指標です。
一般的には、スプリント内でDoneになったチケットのStory Pointを合計して算出します。
例えば、あるスプリントで次のStoryが完了したとします。
- 商品検索機能：8pt
- 商品詳細画面の改善：5pt
- 検索条件の追加：3pt
この場合、そのスプリントのVelocityは合計16ptです。
Story Pointとの関係
Story Pointは、チケットごとの作業量や複雑さ、不確実性を相対的に表す値です。
Velocityは、そのStory Pointをスプリント単位で集計したものです。
- Story Point：個々のチケットの大きさを表す
- Velocity：スプリントで完了したStory Pointの合計を表す
Velocityを見ることで、チームが通常どのくらいの作業を完了できるのかを把握しやすくなります。
JiraでVelocityを確認する
Jiraでは、スクラムボードのレポートからVelocity Chartを確認できます。
Velocity Chartでは、各スプリントについて、計画した作業量と実際に完了した作業量が表示されます。
これにより、次のような点を確認できます。
- スプリント開始時にどのくらいの作業を計画したか
- 実際にどのくらいの作業を完了できたか
- 計画と実績に大きな差がなかったか
過去のSprintのVelocityを確認する
Velocityは、1回のスプリントだけで判断するのではなく、複数回の実績を確認します。
例えば、過去3回のVelocityが次のとおりだったとします。
- Sprint 1：32pt
- Sprint 2：28pt
- Sprint 3：30pt
この場合、平均Velocityは約30ptです。
（32＋28＋30）÷ 3 ＝ 30pt
このチームは、1回のスプリントで30pt前後を完了できると考えられます。
次のSprint Planningに活用する
過去のVelocityは、次のSprintで対応するチケットを決める際の参考にできます。
平均Velocityが30pt前後であれば、次のスプリントでも30pt前後を一つの目安として計画します。
ただし、毎回必ず30ptのチケットを入れるわけではありません。
次のような状況も考慮する必要があります。
- 休暇を取るメンバーがいる
- チームメンバーが増減する
- 不確実性の高い開発がある
- 問い合わせ対応などの予定外作業が見込まれる
- 前回のスプリントから未完了の作業が持ち越される
Velocityとチームの状況を組み合わせて、無理のない範囲でSprint Backlogを決めます。
Velocityを見るときの注意点
Velocityは、チームの生産性を競うための数値ではありません。
特に、次のような使い方には注意が必要です。
- チーム同士の優劣を比較する
- 個人の評価に利用する
- Velocityを毎回増やすこと自体を目標にする
- Story Pointを作業時間として扱う
- 数値を上げるために見積もりを大きくする
Story Pointの基準はチームごとに異なるため、別のチームと単純に比較することはできません。
また、Velocityが高ければ、必ず多くの価値を提供できているとは限りません。
大切なのは数値を増やすことではなく、同じチームの過去の実績を参考に、現実的な計画を立てることです。
Velocityのイメージ
- Sprint 1：32pt
- Sprint 2：28pt
- Sprint 3：30pt
平均Velocity：約30pt
↓
次のSprintでも30pt前後を一つの参考値として計画する
11. Jira＋スクラムでの開発全体の流れ
ここまで紹介したJiraとスクラムを使った開発の流れをまとめると、次のようになります。
図のとおり、Jiraとスクラムを使った開発は、計画 → 開発 → 確認 → 改善の流れで進みます。スプリントごとに成果と進め方を振り返り、その結果を次のSprint Planningへ反映しながら、開発を繰り返していきます。
12. ウォーターフォール開発との違い
ウォーターフォール開発とは？
ウォーターフォール開発とは、要件定義・設計・実装・テストなどの工程を順番に進める開発手法です。
開発前に全体の仕様や計画を決めるため、要件が明確で、途中の変更が少ないプロジェクトに向いています。
開発プロセスの違い
ウォーターフォール開発では、全体の仕様を最初に決めてから、工程ごとに開発を進めます。
一方、アジャイル開発では、機能を小さく分け、短い期間で開発・確認・改善を繰り返します。
| 比較項目 | ウォーターフォール | アジャイル |
|---|---|---|
| 進め方 | 工程を順番に進める | 短い期間で開発を繰り返す |
| 仕様 | 最初に全体を決める | 開発中も見直す |
| 成果の確認 | 開発後半が中心 | 小さな単位で確認する |
仕様変更への対応方法の違い
ウォーターフォール開発では、途中で仕様を変更すると、設計やテストなど広い範囲に影響する場合があります。
アジャイル開発では、新しい要望をProduct Backlogへ追加し、優先順位を見直しながら次のスプリントで対応します。
アジャイル開発が向いているプロジェクト
アジャイル開発は、次のようなプロジェクトに向いています。
- 開発前にすべての要件を決めることが難しい
- ユーザーの反応を見ながら改善したい
- 優先度の高い機能から早く提供したい
- 市場や事業環境の変化に対応したい
新しいWebサービスやアプリなど、実際に使ってもらいながら改善するプロジェクトで特に活用されています。
13. まとめ
ざっくりですがアジャイル開発とスクラムについてまとめました。
雑記なメモなので、定期的に見返す感じが良いと思います。