Skip to main content

学習リソース

AppProjectプロジェクトでイテレーション開発を実践するために役立つ学習リソースと基礎知識をまとめています。

イテレーション開発の基礎​

イテレーション開発とは​

イテレーション開発は、固定期間のサイクル（イテレーション）を繰り返しながら、段階的にプロダクトを開発していく手法です。各イテレーションで「計画→設計→実装→テスト→レビュー」のサイクルを回し、継続的に動作するソフトウェアを提供します。

主な特徴

  • 固定期間のサイクル: 1-4週間の短いサイクルで開発
  • 段階的な開発: 各イテレーションで動作する機能を追加
  • 継続的なフィードバック: 各サイクルで検証と改善を実施
  • 適応的な計画: 変化に柔軟に対応できる

学習リソース

ウォーターフォール開発との違い​

観点ウォーターフォールイテレーション開発
開発の進め方工程を順番に完了させる短いサイクルで繰り返す
要件の扱い最初に全要件を確定段階的に詳細化
変更への対応変更が困難でコスト高変更に柔軟に対応可能
リリース全機能完成後に一度各イテレーションで段階的
フィードバック完成後に初めて評価各サイクルで継続的に取得
リスク後半まで問題が顕在化しない早期に問題を発見・対処

ウォーターフォールが適している場合

  • 要件が明確で変更がほとんどない
  • 規制が厳格で文書化が重要
  • チーム間の依存関係が少ない

イテレーション開発が適している場合

  • 要件が変化する、または不確実性が高い
  • 早期のフィードバックが重要
  • 継続的な改善とリリースが求められる

学習リソース

スクラム開発とは​

スクラムは、イテレーション開発を実践するための具体的なフレームワークです。「スプリント」と呼ばれる固定期間（通常1-4週間）で開発を行い、明確な役割・イベント・成果物を定義しています。

スクラムの3つの役割

  • プロダクトオーナー（PO）: プロダクトの価値を最大化する責任者
  • スクラムマスター: チームがスクラムを実践できるよう支援
  • 開発チーム: プロダクトを実装する自己組織化されたチーム

スクラムの5つのイベント

  1. スプリントプランニング: スプリントで何を実現するか計画
  2. デイリースクラム: 毎日15分で進捗と課題を共有
  3. スプリントレビュー: 完成したインクリメントを関係者に公開
  4. スプリントレトロスペクティブ: プロセスを振り返り改善
  5. スプリントリファインメント: 次のスプリント候補を詳細化

スクラムの3つの成果物

  • プロダクトバックログ: プロダクトに必要な機能のリスト
  • スプリントバックログ: 現在のスプリントで実装するタスク
  • インクリメント: スプリントで完成した動作する機能

学習リソース

プロダクト開発の基本​

上流工程の重要性​

上流工程（要件定義・設計）は、プロダクト開発の成否を左右する最も重要なフェーズです。ここでの判断ミスや曖昧さは、後工程で大きなコストとなって跳ね返ってきます。

上流工程で決めるべきこと

  1. 要件定義

    • ユーザーが本当に必要としているものは何か
    • なぜその機能が必要なのか（背景・目的）
    • どのような価値を提供するのか
    • 成功の基準は何か

  2. 設計

    • どのようなアーキテクチャで実現するか
    • データ構造とフローはどうするか
    • 非機能要件（パフォーマンス、セキュリティ）をどう満たすか
    • 技術的な制約や依存関係は何か

上流工程が不十分な場合の影響

  • 手戻りの増加: 実装後に要件の誤解や漏れが発覚し、大規模な修正が必要に
  • 品質の低下: 設計が不十分なまま実装すると、バグや技術的負債が蓄積
  • スケジュール遅延: 曖昧な要件のまま進めると、後工程で予想外の作業が発生
  • コストの増大: 後工程ほど修正コストは指数関数的に増加

学習リソース

QA（品質保証）の重要性​

QAは、単なる「バグを見つける作業」ではありません。プロダクトの品質を体系的に保証し、ユーザーに価値を届けるための重要なプロセスです。

QAの役割

  1. 品質の定義

    • 何をもって「品質が高い」と判断するか基準を定義
    • 機能要件だけでなく、非機能要件も含めた品質指標の設定

  2. 品質の測定

    • テストカバレッジ、バグ密度などのメトリクスを収集
    • プロダクトが定義した品質基準を満たしているか検証

  3. 品質の改善

    • 問題の根本原因を分析し、再発防止策を提案
    • プロセスやツールの改善を通じて品質を向上

QAが不十分な場合の影響

  • クリティカルなバグの流出: ユーザー体験の著しい低下、信頼性の喪失
  • リリース後の修正コスト: 本番環境での修正は開発時の10-100倍のコスト
  • ブランドイメージの毀損: 品質問題はSNSで拡散され、長期的な影響
  • セキュリティリスク: 脆弱性の見逃しは重大なインシデントにつながる

学習リソース

イテレーション開発における上流工程とQA​

イテレーション開発では、上流工程とQAを「最初に一度だけ」行うのではなく、各イテレーションで繰り返し実施します。

上流工程の実践方法​

1. プロダクトバックログリファインメント

イテレーション外で、次のイテレーション候補の要件を詳細化します。

  • 背景と目的の明確化: なぜこの機能が必要か、誰のためか
  • 受け入れ基準の定義: 何ができれば完成とみなすか
  • 技術的検討: 実現可能性、アーキテクチャへの影響
  • 見積もりと優先順位: 工数と価値のバランスを評価

2. スプリントプランニング

スプリント開始時に、要件と設計の詳細を全員で確認します。

  • ユーザーストーリーの共有: 背景・目的・期待値を全員が理解
  • 設計の概要説明: 実装方針、データフロー、依存関係
  • タスクへの分解: 実装可能な粒度まで詳細化
  • 不明点の解消: 曖昧さを残さず、全員が同じ理解を持つ

3. Just-in-Time設計

必要なタイミングで必要な粒度の設計を行います。

  • 最小限の先行設計: アーキテクチャレベルの大枠は事前に
  • 実装直前の詳細設計: 実装着手前に具体的な設計を確定
  • 継続的なリファクタリング: 実装しながら設計を改善

学習リソース

QAの実践方法​

1. シフトレフト（早期テスト）

テストをできるだけ早い段階から開始します。

  • 要件レビュー: 要件定義の段階でテスト観点から確認
  • 設計レビュー: テスト可能な設計になっているか検証
  • 実装中のテスト: コードを書きながらユニットテストを作成

2. テストの自動化

繰り返し実行するテストを自動化し、継続的に品質を確認します。

  • ユニットテスト: 関数やメソッドレベルのテスト
  • 統合テスト: コンポーネント間の連携をテスト
  • E2Eテスト: ユーザーシナリオをエンドツーエンドでテスト
  • 回帰テスト: 既存機能が壊れていないことを確認

3. 継続的インテグレーション（CI）

コード変更のたびに自動テストを実行し、問題を早期発見します。

  • 自動ビルド: コミット時に自動でビルド
  • 自動テスト実行: すべてのテストを自動実行
  • 即座のフィードバック: 問題があればすぐに通知

4. Definition of Done（完成の定義）

何をもって「完成」とみなすか、明確な基準を設定します。

  • コードレビュー完了: 複数人によるレビューと承認
  • テストの合格: すべてのテストが成功している
  • ドキュメント更新: 必要な文書が最新化されている
  • POの承認: プロダクトオーナーが受け入れ基準を確認

学習リソース

推奨書籍​

イテレーション開発・スクラム

  • 『SCRUM BOOT CAMP THE BOOK』- 西村直人、永瀬美穂、吉羽龍太郎
  • 『スクラム実践入門』- 貝瀬岳志、原田騎郎、和智右桂
  • 『アジャイルサムライ』- Jonathan Rasmusson

要件定義・上流工程

  • 『ユーザーストーリーマッピング』- Jeff Patton
  • 『Running Lean』- Ash Maurya
  • 『リーン顧客開発』- Cindy Alvarez

QA・テスト

  • 『アジャイルテストの実践』- Lisa Crispin、Janet Gregory
  • 『実践アジャイルテスト』- Lisa Crispin、Janet Gregory
  • 『テスト駆動開発』- Kent Beck

参考記事・ブログ​

これらのリソースを活用して、チーム全体でイテレーション開発の理解を深め、より効果的な開発プロセスを実践していきましょう。