先日、Udemyの現役シリコンバレーエンジニアが教えるアジャイル開発を受講しました。
本記事では、その内容と学びをまとめます。

セクション1 アジャイル開発とは？

アジャイルとは？

アジャイル宣言で表された価値と原則に基づいた方法と実践
重要な概念：チームのコラボレーション、自己組織化、横のつながり

スクラムとは？

アジャイルな原則を実装するためのフレームワーク
アジャイル開発の手法の一つがスクラム

アジャイルの歴史

ウォーターフォール

要件定義 → 開発 → 統合 → テスト → デプロイ
無駄な機能を作りやすく、成功率が低い
縦割り制

アジャイル

短い「イテレーション」に分けて開発
チーム制で柔軟に対応

**以上のようなウォーターフォール型の欠点に対応したものとしてアジャイルが普及

アジャイルマニフェスト

プロセスやツール＜個々と対話
包括的なドキュメント＜動作するソフトウェア
契約交渉＜顧客とのコラボレーション
計画に従順＜変更への対応

要するに： 顧客との対話と柔軟性が重要視する考え方

アジャイルの十二の原則（一部抜粋）

早期かつ継続的な納品
変更を歓迎する
動作中のソフトウェアを頻繁に納品
シンプルさと無駄の排除
ビジネスと開発者が協働
持続可能なペース
自己組織的なチーム
定期的な振り返りと改善

セクション2 アジャイルを選ぶ理由

アジャイル：必要な機能と実装を絞り込む
ウォーターフォール：機能を全て実装する前

なので、現場が過酷になりにくい上に効率的な開発ができる

セクション3 アジャイルのフレームワーク

Lean（リーン）
Kanban（カンバン）
XP（エクストリームプログラミング）
- ペアプログラミング
- コーディング標準の遵守
Hybrid
- 仕様・要件 → イテレーション → テスト

セクション4 物理的環境・ツール

物理的環境

一緒に働く
ポッドを準備（可能なら）
モビリティ確保
ホワイトボード、掲示板、付箋などの利用

コミュニケーションツール

ビデオ会議
Slack

セクション5 スクラムの役割

開発チーム

エンジニア、デザイナー、QA
T字型スキルが求められる（ウォーターフォールでは単一の抜きん出たスキルがあれば良いが、アジャイルではそれに加えて幅広い知識が必要）

スクラムマスター

進行役・コーチ
チームの集中を阻害する要因を排除

プロダクトオーナー

プロジェクトのコスト・時間管理
ステークホルダーとの橋渡し

チームの価値観

尊敬：成果も失敗も全員の責任
オープンマインド：他者の意見を受け入れ、情報共有
コミットメント：スプリント目標達成への集中

セクション6 フィーチャーとコンポーネント

フィーチャー：ユーザーのニーズを直接満たす機能
フィーチャーズ・チーム：フィーチャーの作成に重点を置くチーム
コンポーネント：他チームが再利用するシステム部品
コンポーネント・チーム：他のチームが再利用する「コンポーネント」の作成に重点を置き、機能横断的な単一のコンポーネントに焦点を当てる。
スクラム・オブ・スクラム：リーダー間のディスカッション

セクション7 プロダクト開発の流れ

プロダクトビジョン
- 製品目標を開発 → 下書き → 共有 → 修正 → 最終版配布
プロダクトロードマップ
- 優先順位、計画、リリース決定
プロダクトバックログ

機能や改善案を洗い出してリスト化
（アーキテクチャ設計やユーザーストーリー化を含む）
良い要件の基準 = INVEST
- 独立（Independent）
- 交渉可能（Negotiable）
- 価値（Valuable）
- 見積可能（Estimable）
- 小さい（Small）
- テスト可能（Testable）
見積もり方法例
- プランニングポーカー：全員で同時に数字を出して工数感を揃える
- Tシャツサイズ：XS〜XLで規模感を共有
- ドット投票：重要項目にシールを貼って優先度を決定

リリース計画
- リリース日・範囲を特定
スプリント計画
- バックログ整理、担当アサイン
スプリント
デイリースクラム

目的

次の24時間の計画を作成する
チームの進捗と課題を共有する

概要（4W1H）

WHO：開発チーム
WHAT：次の24時間の計画を立てる
WHEN：毎日約15分
HOW：立ったまま実施（短時間で集中）

スプリント中の役割

メンバー

スプリント用タスクの遂行と完了
不明点はオーナーに確認
毎日の進捗・問題・障害を共有
レビューやサポートでメンバーを支援
自分のタスクが終わったら他の作業を手伝う

プロダクトオーナー

コスト・時間の監督とステークホルダへの報告
ステークホルダ代表として開発チームと連携
チームが集中できる環境を整える
機能の確認とフィードバック
必要に応じてバックログを更新

スクラムマスター

チームを外部から守る
チーム内の関係構築を促す
アジャイル実践をオーナーとチームに徹底させる

ポテンシャルな納入

議論
開発
テスト
レビュー
の段階が終わったものは納入する

セクション8 スプリントレビュー

目的（4W1H）

WHO：プロダクトオーナー、開発チーム、スクラムマスター
WHAT：
- スプリント中に達成した成果を示し、関係者からフィードバックを受ける
- 製品に関する議論とバックログの調整
- タイムライン・予算・リリース計画の確認
WHEN：各スプリントの最後
HOW：動作しているソフトウェアを見せながら実施

手順

「完了」と「未完了」の内容を明確化
- 開発、テスト、結合、ドキュメント化が完了しているかを確認
デモンストレーション
- 形式ばらず、パワーポイントなし
- 開発チームが直接デモを行う
製品バックログの確認・修正
- 完了していないユーザーストーリーの洗い出し
- 既存機能の変更有無を確認
- 新機能の追加要否を検討

セクション9 スプリントレトロスペクティブ

目標特定 → 話し合い → アクションプラン作成
何がうまくいったか／いかなかったか／改善案を共有

セクション10 アジャイルの神話と誤解

アジャイルは無計画ではない
ドキュメントやアーキテクチャも作成する
規律はチームで作る
IT以外の分野でも活用可能
全てを解決するわけではない

セクション11 日本とアメリカの違い

シリコンバレー：自社開発（柔軟対応しやすい）
日本：外注が多い（期限の柔軟性が低い）

セクション12 ツール選定の流れ

ニーズ定義
リサーチ
試用評価
YouTubeレビュー確認
コスト評価
実装

まとめると、、、、、

アジャイル開発とは

変化に素早く対応しながら、短いサイクルで開発を進める手法
詳細な計画よりも「動くソフトウェア」「顧客との対話」「変化への適応」を重視
代表的な価値観は アジャイル宣言（2001年）に基づく

スクラムとは

アジャイル開発の一種で、反復型・漸進型のフレームワーク
1〜4週間程度の短い期間（スプリント）で計画・開発・レビューを繰り返す
3つの役割（プロダクトオーナー／開発チーム／スクラムマスター）と、決まったイベント・成果物が特徴
自律的なチーム運営と継続的改善を重視する

感想

今回の講義で特に印象的だったのは、アジャイルは「無計画で柔軟すぎる」わけではなく、むしろ計画的かつ変化対応力を持った手法だという点です。スクラムの役割やチーム文化も具体的で、実務にすぐ活かせそうです。