先日、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つの役割（プロダクトオーナー／開発チーム／スクラムマスター）と、決まったイベント・成果物が特徴
- 自律的なチーム運営と継続的改善を重視する
感想
今回の講義で特に印象的だったのは、アジャイルは「無計画で柔軟すぎる」わけではなく、むしろ計画的かつ変化対応力を持った手法だという点です。スクラムの役割やチーム文化も具体的で、実務にすぐ活かせそうです。