アジャイル開発のベストプラクティス

目次

  1. アジャイルの基本原則
  2. チームづくり
  3. プロダクトバックログ管理
  4. スプリント／イテレーションの運営
  5. 見積もりと計画
  6. 技術プラクティス
  7. 品質の確保
  8. コミュニケーションと透明性
  9. メトリクスと継続的改善
  10. よくあるアンチパターン
  11. 導入・定着のステップ
  12. チェックリスト

1. アジャイルの基本原則

アジャイルソフトウェア開発宣言の4つの価値

より重視するもの左記に比べて重視度が下がるもの
個人と対話プロセスやツール
動くソフトウェア包括的なドキュメント
顧客との協調契約交渉
変化への対応計画に従うこと

右側にも価値はあるが、左側により価値を置く、という考え方です。「ドキュメント不要」「計画不要」という意味ではありません。

押さえておきたい考え方

  • 小さく作って早く届ける：価値を短いサイクルで繰り返しリリースし、フィードバックを得る
  • 経験主義（透明性・検査・適応）：予測より実際の結果に基づいて判断する
  • 持続可能なペース：長時間労働に頼らず、一定のペースを保つ
  • シンプルさ：「やらなくて済む作業」を最大化する
  • 自己組織化：やり方はチーム自身が決める

2. チームづくり

理想的なチーム構成

  • 人数は3〜9人程度：コミュニケーションコストが急増しない規模に保つ
  • クロスファンクショナル：企画・設計・開発・テスト・デザインなど、価値を届けるのに必要なスキルをチーム内に揃える
  • 専任メンバー：複数プロジェクトの掛け持ちを避け、コンテキストスイッチを減らす
  • チームを安定させる：頻繁にメンバーを入れ替えない（チームの成熟には時間がかかる）

スクラムにおける3つの責任

役割主な責任
プロダクトオーナー（PO）プロダクトの価値最大化、バックログの優先順位付け、ステークホルダーとの調整
スクラムマスター（SM）スクラムの理解と実践の支援、障害の除去、チームのコーチング
開発者各スプリントで利用可能なインクリメントを作る、品質への責任

ベストプラクティス

  • POは意思決定の権限を持つ1人にする（委員会にしない）
  • SMは「プロジェクトマネージャー」ではなくサーバントリーダーとして振る舞う
  • 心理的安全性を最優先にする：失敗や懸念を率直に話せる場をつくる
  • チームのワーキングアグリーメント（作業の約束事）を明文化する
    • 例：コアタイム、レビューの応答時間、会議のルール、Doneの定義

3. プロダクトバックログ管理

良いバックログの特徴（DEEP）

  • Detailed appropriately：上位項目ほど詳細に、下位は粗くてよい
  • Estimated：見積もりがされている
  • Emergent：常に変化・進化している
  • Prioritized：価値に基づいて並んでいる

ユーザーストーリーの書き方

<ユーザーの種類> として、
<達成したいこと> がしたい。
なぜなら <得られる価値・理由> だからだ。

例：

ECサイトの購入者として、注文履歴を一覧で見たい。なぜなら過去に買った商品を簡単に再注文したいからだ。

良いストーリーの基準（INVEST）

頭文字意味
Independent他のストーリーから独立している
Negotiable詳細は交渉可能
Valuableユーザーや顧客に価値がある
Estimable見積もり可能
Small1スプリント内に収まる大きさ
Testableテスト（検証）可能

受け入れ基準（Acceptance Criteria）

ストーリーごとに「何ができたら完了か」を明確にします。Given-When-Then形式が便利です。

Given ログイン済みのユーザーが注文履歴ページを開いたとき
When 過去の注文が3件あれば
Then 新しい順に3件表示される

バックログリファインメント

  • スプリント中に継続的に実施する（目安：スプリント時間の10%以内）
  • 次の1〜2スプリント分の項目を「Ready」な状態にしておく
  • 大きなストーリーは縦に分割する（UI・API・DBと層で切らず、機能単位で切る）

ストーリー分割のパターン

  • ワークフローのステップ単位で分ける
  • ハッピーパスと例外ケースで分ける
  • データの種類・バリエーションで分ける
  • 操作（作成／参照／更新／削除）で分ける
  • まず簡易版を作り、後から改善する

4. スプリント／イテレーションの運営

スプリントの長さ

  • 1〜2週間が一般的。短いほどフィードバックが速い
  • 一度決めたら長さを固定し、リズムを作る
  • スプリント途中でゴールを変えない（緊急時はPOがスプリントを中止できる）

スクラムイベントとベストプラクティス

イベント目的タイムボックス目安（2週間スプリント）ポイント
スプリントプランニング何を・どうやって作るか決める最大4時間スプリントゴールを1文で決める
デイリースクラムゴールへの進捗確認と計画の調整15分報告会ではなくチームの作戦会議にする
スプリントレビュー成果物を検査し、今後を相談する最大2時間動くものを見せ、ステークホルダーの意見を聞く
レトロスペクティブプロセスを振り返り改善する最大1.5時間改善アクションは1〜3個に絞る

デイリースクラムを形骸化させないコツ

  • 個人ではなくボード上のタスク（作業の流れ） を中心に話す
  • 問題の詳細議論は終了後に関係者だけで行う
  • 「昨日・今日・障害」の3点セットにこだわりすぎない

レトロスペクティブの進め方例

  1. 場を整える：目的と心理的安全性の確認
  2. データを集める：起きた出来事を時系列で振り返る
  3. 気づきを得る：根本原因を考える（なぜなぜ分析など）
  4. アクションを決める：担当と期限を決める
  5. クローズ：振り返り自体を振り返る

代表的なフォーマット：KPT（Keep / Problem / Try）、Start / Stop / Continue、4L（Liked / Learned / Lacked / Longed for）、帆船（Sailboat）

前回のアクションが実行されたかを必ず冒頭で確認しましょう。

5. 見積もりと計画

相対見積もり

  • ストーリーポイントで、絶対時間ではなく「大きさの比較」で見積もる
  • フィボナッチ数列（1, 2, 3, 5, 8, 13…）を使い、大きいものほど不確実性を反映する
  • プランニングポーカーで全員が同時に提示し、差が大きければ理由を話し合う
  • 13以上のストーリーは分割を検討する

ベロシティの扱い方

  • チームの計画のための道具であり、評価指標ではない
  • チーム間で比較しない（ポイントの基準はチームごとに異なる）
  • 直近3〜5スプリントの平均を目安にする

noestimates という選択肢

ストーリーを十分小さく揃えられるなら、ポイントを付けず件数（スループット） で予測する方法もあります。

リリース計画

  • ロードマップはゴール・成果ベースで書く（機能リストの羅列にしない）
  • 予測は幅を持たせる（例：「8〜11スプリント」）
  • 優先順位付けには MoSCoW（Must / Should / Could / Won’t）や WSJF（遅延コスト ÷ 作業量）が有効
  • 最初に MVP（実用最小限の製品） を定義し、早く学ぶ

6. 技術プラクティス

アジャイルは「変化に強いコード」があって初めて持続します。

継続的インテグレーション／デリバリー（CI/CD）

  • メインブランチに1日1回以上統合する
  • コミットごとに自動ビルド・自動テストを走らせる
  • ビルドが壊れたら最優先で直す
  • デプロイを自動化し、いつでもリリースできる状態を保つ

ブランチ戦略

  • トランクベース開発または短命なフィーチャーブランチ（数日以内）を推奨
  • 未完成の機能はフィーチャーフラグで隠してマージする

テスト駆動開発（TDD）

  1. 🔴 失敗するテストを書く
  2. 🟢 テストが通る最小限のコードを書く
  3. 🔵 リファクタリングする

その他のプラクティス

プラクティス効果
リファクタリング技術的負債の蓄積を防ぐ
ペアプログラミング／モブプログラミング知識共有、品質向上、属人化の解消
コードレビュー品質向上と学習。小さなPRで素早く回す
シンプルな設計（YAGNI）今必要ないものは作らない
共同コード所有誰でもどのコードでも変更できる

技術的負債の管理

  • 負債を可視化してバックログに載せる
  • 各スプリントに一定割合（例：15〜20%）を改善に充てる
  • 「ボーイスカウトルール」：触ったコードは来たときより綺麗にして去る

7. 品質の確保

完成の定義（Definition of Done）

チーム全員で合意した「完了」の基準を明文化します。

例：

  • コードレビュー済み
  • 単体テストが書かれ、すべて通過
  • 受け入れ基準を満たしている
  • CIが通っている
  • 必要なドキュメントが更新済み
  • ステージング環境で動作確認済み
  • POが受け入れ済み

「ほぼ完了」は「未完了」です。DoDを満たさないものはレビューで見せません。

準備完了の定義（Definition of Ready）

スプリントに取り込む前の基準です（任意。厳しすぎるとフローを阻害するので注意）。

  • 受け入れ基準が明確
  • 見積もり済み
  • 依存関係が解消されている、または把握されている

テストピラミッド

        /\
       /E2E\        少なく
      /------\
     / 結合   \
    /----------\
   /   単体     \   多く
  /--------------\
  • 単体テストを厚く、E2Eテストは重要シナリオに絞る
  • テストは開発者がスプリント内で書く（後工程にまとめない）

8. コミュニケーションと透明性

情報の可視化

  • タスクボード（To Do / In Progress / Done など）で作業状況を共有する
  • WIP（仕掛り）制限を設け、「始める」より「終わらせる」を重視する
  • バーンダウン／バーンアップチャートで進捗を見える化する

ステークホルダーとの関係

  • スプリントレビューに実際のユーザーや意思決定者を招く
  • 悪いニュースほど早く共有する
  • 期待値の調整は「スコープ」で行う（品質を犠牲にしない）

リモート・ハイブリッド環境でのコツ

  • 会議ツールでもカメラONや反応を推奨し、対話の質を保つ
  • オンラインホワイトボードを活用する
  • 非同期コミュニケーション（チャット・ドキュメント）のルールを決める
  • 雑談の場を意図的につくる

9. メトリクスと継続的改善

有用なメトリクス

メトリクス何がわかるか
リードタイム要求から本番リリースまでの時間
サイクルタイム着手から完了までの時間
スループット単位期間あたりの完了数
デプロイ頻度どれだけ頻繁に価値を届けているか
変更失敗率リリースによる障害の割合
平均復旧時間（MTTR）障害から回復するまでの時間
顧客満足度・利用状況実際に価値が届いているか

デプロイ頻度・リードタイム・変更失敗率・復旧時間は「DORAメトリクス」として知られています。

メトリクス運用の注意点

  • 出力（アウトプット）より成果（アウトカム） を重視する
  • 個人評価に使わない（数字の操作を招く）
  • 数字は会話のきっかけとして使う

改善のサイクル

  1. レトロスペクティブで課題を見つける
  2. 小さな改善実験を設定する（仮説と期待結果を明確に）
  3. 次スプリントで試す
  4. 結果を検証し、定着 or 中止を判断する

10. よくあるアンチパターン

アンチパターン症状対策
名ばかりアジャイル（Dark Agile）イベントはやっているが中身は従来型「なぜやるのか」の目的に立ち返る
ミニウォーターフォールスプリント内で設計→開発→テストを順番に実施ストーリーを小さくし、チーム全員で1つずつ仕上げる
スプリント持ち越しの常態化毎回タスクが終わらない計画量を減らす、ストーリーを分割する、WIP制限
PO不在仕様の判断が遅れ、作業が止まるPOの時間を確保し、権限を委譲する
デイリーが報告会上司への進捗報告になっている管理者はオブザーバーにとどめ、チーム主体にする
レトロでアクションが出ない／実行されない改善が進まないアクションを絞り、担当と期限を決め、次回冒頭で確認
ベロシティの水増しポイントがインフレしていくベロシティを目標や評価に使わない
技術的負債の放置開発速度が徐々に低下改善時間を常に確保、DoDに品質基準を含める
ドキュメント完全排除知識が属人化する必要十分なドキュメント（ADR、READMEなど）は書く

11. 導入・定着のステップ

  1. 目的を明確にする：なぜアジャイルを導入するのか（速さ？品質？顧客満足？）
  2. 小さく始める：1チーム・1プロダクトでパイロット運用
  3. 型から入る：最初はスクラムガイドなどのフレームワークに忠実に従う
  4. 振り返りながら調整する：慣れてきたら自分たちに合わせて改善（守破離）
  5. 組織を巻き込む：経営層・関連部署の理解と支援を得る
  6. 成功事例を共有して広げる

大規模化する場合

複数チームでの開発には、LeSS、SAFe、Scrum@Scale、Nexus などのフレームワークがあります。ただし、まず単一チームでアジャイルがうまく回っていることが前提です。

12. チェックリスト

チーム

  • チームは10人未満で、必要なスキルが揃っている
  • POとSMが明確に決まっている
  • ワーキングアグリーメントがある
  • 率直に意見を言える雰囲気がある

プロセス

  • スプリントの長さが固定されている
  • 毎スプリント、スプリントゴールがある
  • バックログが優先順位順に並び、上位が詳細化されている
  • 完成の定義（DoD）が明文化されている
  • レトロスペクティブの改善アクションが実行されている

技術

  • CIが整備され、ビルドは常にグリーン
  • 自動テストが十分にある
  • 毎スプリント、リリース可能なインクリメントができている
  • 技術的負債を返済する時間を確保している

価値

  • スプリントレビューにステークホルダーが参加している
  • 実際のユーザーからフィードバックを得ている
  • アウトカム（成果）を測定している

参考資料

0件のページ

    バックリンク