はじめに
- 翻訳は、Google翻訳で日本語にしたあと、「多分こういうことを言ってるだろう…」と解釈を加えて書き換えています。
- 英語スキルが中2のため、意味がわからないものは翻訳そのまま載せてます。わからん。
- 正確に理解されたい方は下記をご覧いただくか、英語に堪能な方のブログを待つのが良いかもしれません。
stateofagile.com
最新のトレンドまとめ
アジャイル導入に関して、組織文化はまだまだ醸成されていない
- アジャイル導入・拡大の一番の課題は組織文化だった。
- 上位5つの課題には以下の要素が大きく影響していた。
- 変化に対する組織の抵抗（48%）
- マネジメントのサポート・協力不足（43%）
- アジャイルの価値と対立する組織文化（44%）
- 不十分なリーダーシップの関与（46%）
- 75%がスクラム、またはスクラムベースのアジャイル開発を取り入れている。
- 大規模スクラムについては、回答者の35%がSAFeを使っていて一番多い。去年より5%増えている。
アジャイル導入によって、適応性・透明性が強化された
- アジャイル開発によってカイゼンされたこと、向上したことの上位には以下の要素が挙げられ、市場への適応性・透明性が向上したことがわかる。
- 不確実性を上手にマネジメントする能力（70%）
- プロジェクトの可視性を管理する能力（65%）
- ビジネス・開発の協調（65%）
- チームのモラル（59%）
- ユーザーに届くまでの速さ・時間（60%）
- チームの生産性（58%）
アジャイルに関する状況は去年から既に変わった
以下の3つの調査では、昨年と比較して10%以上の変化があった
プロジェクトコストへの意識よりも他の項目が重要さを増した
- アジャイルを導入する理由について、回答者の26%が「プロジェクトコストの削減」と回答した。これは昨年より15%も下がった。
技術への注目が増加した
- デプロイ前のテクニカルリスクの指標特定は、回答者の34%が非常に重要と回答した。昨年は22%だった。
- その理由は、適切なツールとプラクティスによって、テクニカルリスクの指標特定が成し遂げられると大きな気付きを得たからかもしれない。
- 基準点での監査の即応と管理の自動化は、昨年から10%増加して28%になった。
- これは、コンプライアンス要件が義務付けられた組織がアジャイルを幅広く取り入れたことと、アジャイルプラクティスへの意識が高まったため。
人口統計によってフィルタリングした結果
アジャイルを実践する時間の長さについて
- アジャイルを実践する時間が長くなるにつれて、以下の影響があった。
- アジャイルの成熟度が高くなった
- プロダクトの、市場投入までの時間が短縮された
- 不確実性をマネジメントする能力が向上した
- 5年以上アジャイルを実勢している場合、以下の影響があった。
- DevOpsの進捗向上
- バリューストリーム管理への関心向上
- これらの組織は、アジャイルプラクティスを使用する可能性も高くなる。
会社の規模
- 20,000人を超える企業は、少なくとも5年はアジャイルを実践しているところが多く、アジャイルプラクティスを使用することが多い。
- 1000人未満の場合、チームの全てがアジャイルを導入している割合が高い。この企業は、開発以外の領域でもアジャイルを導入する可能性が高い。
- 回答者の半数以上が、組織が現在バリューストリーム管理（VSM）を実装しているか、または実装する予定であると報告しました。
- 理解が深まり、ツールがより適切に「現金化の概念」のバリューストリームの統一を可能にするため、今後はより多くの組織がVSMを採用することを期待しています。
- 調査結果は、アジャイルが依然として大部分が開発、IT、および運用に限定されていることを示しています。
- ただし、ビジネスには、組織のすべての領域にわたる効果的なアジャイルの調整が必要であるという考えは勢いを増し続けています。
- では、未来はどうなるのでしょうか。 来年は、組織が、ソフトウェアの構築、展開、および保守に通常関連する領域を超えた領域へのアジャイルの大幅な拡大を報告すると予想されます。
- アジャイルを組織全体に拡張すると、誰もがメリットを体験できます。
回答者の統計
組織の規模
| 人数 |
割合 |
| ~ 1000人 |
41% |
| 1001 ~ 5000人 |
19% |
| 5001 ~ 20000人 |
15% |
| 20001人 ~ |
25% |
ソフトウェア組織の規模
| 人数 |
割合 |
| ~ 100人 |
33% |
| 101 ~ 500人 |
36% |
| 501 ~ 2000人 |
16% |
| 2001人 ~ |
15% |
組織の場所
Roll
| 役割 |
割合 |
| スクラムマスター or コーチ |
39% |
| プロジェクトマネージャー / プログラムマネージャー |
14% |
| 開発リーダー(VP) / ディレクター / マネージャー |
13% |
| アーキテクト / 開発者 / QA / テスター / UI or UXデザイナー |
7% |
| 外部コンサルタント / トレーナー |
7% |
| PdM / PO |
6% |
| C-Level Executive |
5% |
| ビジネスアナリスト |
4% |
| その他 |
3% |
| DevOps |
2% |
産業
| 産業 |
割合 |
| IT |
27% |
| 金融 |
17% |
| プロフェッショナルサービス |
7% |
| 行政 |
7% |
| 保険 |
6% |
| 製造 |
5% |
| 電気通信 |
5% |
| ヘルスケア＆医薬品 |
4% |
| 教育 |
4% |
| 小売り |
4% |
| メディア/エンターテイメント |
3% |
| 運輸 |
3% |
| エネルギー |
2% |
| 非営利 |
2% |
| その他 |
4% |
- 95％は、組織がアジャイル開発を実践していると報告した
| 期間 |
割合 |
| 1年未満 |
10% |
| 1 ~ 2年 |
23% |
| 3 ~ 5年 |
34% |
| 5年以上 |
27% |
| 組織内でアジャイルを実践しているチーム |
割合 |
| 全てのチーム |
18% |
| 半分以上のチーム |
33% |
| 半分以下のチーム |
44% |
| 全く取り入れていない |
5% |
| 組織内でどの領域がアジャイルを導入しているか？ |
割合 |
| ソフトウェア開発 |
37% |
| IT |
26% |
| オペレーション |
12% |
| マーケティング |
7% |
| HR |
6% |
| 営業 |
5% |
- 81％は、組織にアジャイルチームがあり、同じチームのメンバー全員が同じ場所で作業するわけではない（分散型である）。
- 71％は、組織がアジャイルを実践しており、複数の同じ場所に配置されたチームが地理的な境界を越えて協力している。
- アジャイルの実践は対面が望ましい場合があるが、回答では、組織が分散型チーム・メンバーをサポートしていることを示した。
- 2020年5月現在のコロナウイルスによる世界的な危機は、「新たな常識」として分散型チームのさらなる増加に繋がるターニングポイントになる可能性がある。
- ソフトウェアのデリバリーを加速し、不確実性を上手に管理することは、アジャイルを採用する最大の理由だった。
- 「プロジェクトコストの削減」よりも、「プロジェクトリスクの削減」を目的にアジャイルを導入している。
| アジャイル導入の理由 |
割合 |
| デリバリーの高速化 |
71% |
| 不確実性マネジメント |
63% |
| 生産性の向上 |
51% |
| ビジネス・ITの協調 |
47% |
| ソフトウェア品質の向上 |
42% |
| ソフトウェアを安定して届けるため |
39% |
| プロジェクトリスクの軽減 |
37% |
| プロジェクトの可視性の向上 |
36% |
| チームモラルの向上 |
31% |
| プロジェクトコストの削減 |
26% |
| 工学分野の改善 |
23% |
| 分散型チームのマネジメント改善 |
21% |
| 保守性の向上 |
18% |
- 大多数（84％）は、組織がアジャイルプラクティスの能力・行動特性を下回っており、トレーニングとコーチングをサポートすることで継続的な改善の機会を示していると述べた。
| アジャイル導入のメリット |
割合 |
| 不確実性をマネジメントする能力 |
70% |
| プロジェクトの可視性 |
65% |
| ビジネス・開発の協調 |
65% |
| 市場へのデリバリー速度 |
60% |
| チームのモラル |
59% |
| チームの生産性 |
58% |
| プロジェクトのリスク削減 |
51% |
| プロジェクトの予測可能性 |
50% |
| ソフトウェアの品質 |
46% |
| ENGINEERING DISCIPLINE |
44% |
| 分散型チームの管理 |
41% |
| ソフトウェアの保守性 |
35% |
| プロジェクトのコスト削減 |
26% |
| アジャイルのメソッド |
割合 |
| Scrum |
58% |
| ScrumBan |
10% |
| その他 / ハイブリッド / 複合 |
9% |
| ScrumとXPのハイブリッド |
8% |
| Kanban |
7% |
| イテレーション開発 |
4% |
| わからない |
3% |
| リーンスタートアップ |
1% |
| XP |
1% |
| アジャイルプラクティス |
割合 |
| デイリースクラム |
85% |
| ふりかえり |
81% |
| スプリントプランニング |
79% |
| スプリントレビュー |
77% |
| 短期間のイテレーション |
64% |
| KANBAN |
63% |
| プランニングポーカー / チームでの見積もり |
60% |
| 専任のプロダクトオーナー |
54% |
| リリースプランニング |
51% |
| 機能横断的な単一チーム（開発とテスト混合） |
51% |
| プロダクトロードマッピング |
49% |
| 頻繁なリリース |
48% |
| 共通の作業場所 |
42% |
| ユーザーストーリーマッピング |
37% |
| AGILE PORTFOLIO PLANNING |
33% |
| リーンUX |
24% |
採用されたエンジニアリングプラクティス
| エンジニアリングプラクティス |
割合 |
| ユニットテスト |
67% |
| コーディング規約 |
58% |
| 継続的インテグレーション |
55% |
| リファクタリング |
43% |
| 継続的デリバリー |
41% |
| 自動受け入れテスト |
36% |
| 継続的デプロイ |
36% |
| ペアプログラミング |
31% |
| テストドリヴンデベロップメント |
30% |
| コレクティブコードオーナーシップ |
29% |
| 持続的なペース |
23% |
| BEHAVIOR-DRIVEN DEVELOPMENT (BDD) |
19% |
| EMERGENT DESIGN |
13% |
外部委託された開発プロジェクトでのアジャイル
- 回答者の50％は、アジャイル手法を使用して外部委託された開発プロジェクトを管理しています。
- 回答者の42％は、今後24か月以内に外部委託開発プロジェクトでのアジャイルの使用を増やす計画を示しています。
成功の測定方法：組織のアジャイルトランスフォーメーション
| アジャイルトランスフォーメーションの指標 |
割合 |
| ユーザーの満足度 |
58% |
| ビジネスバリュー |
54% |
| 予定通りの納品 |
48% |
| 品質 |
45% |
| 達成されたビジネス目標 |
44% |
| 生産性 |
40% |
| 組織文化 / モラル |
37% |
| プロセス改善 |
35% |
| 予測可能性 |
33% |
| プロジェクトの可視性 |
29% |
| プロダクトのスコープ |
15% |
成功の測定方法：個々のアジャイルプロジェクト
- アジャイルトランスフォーメーションと同様、ビジネス価値の提供と顧客/ユーザーの満足度が成功の指標の上位2つ
| アジャイルプロジェクトの指標 |
割合 |
| 提供されたビジネスバリュー |
46% |
| ユーザーの満足度 |
45% |
| ベロシティ |
37% |
| 予算に対して実費がどうだったか |
31% |
| 計画に対してイテレーションごとの進捗がどうだったか |
31% |
| 計画に対して実際のリリーススケジュールがどうだったか |
28% |
| プロダクトの欠陥 |
26% |
| サイクルタイム |
25% |
| イテレーションのバーンダウン |
24% |
| バーンアップチャート |
22% |
| 長期的な欠陥 |
20% |
| 仕掛中の作業 |
20% |
| リリースバーンダウン |
18% |
| 欠陥の解決 |
15% |
| ユーザーのリテンション |
14% |
| 見積もりの正確さ |
13% |
| 累積フローチャート |
12% |
| 得られたバリュー |
12% |
| セールスへの影響 |
12% |
| プロダクトの利用 |
11% |
| テストのパス |
11% |
| リリースでのスコープ変更 |
9% |
| イテレーションあたりの時間 |
8% |
スケールさせる方法とアプローチ
- Scaled AgileFramework®が一番人気（昨年の30％に対して、今年は35％）
- SAFe®は、次点で人気のScrum of Scrumsを19％も上回った
| 大規模スクラムのフレームワーク |
割合 |
| Scaled Agile Framework®(SAFe®) |
35% |
| Scrum of Scrums |
16% |
| Disciplined Agile Delivery (DAD) |
4% |
| Large Scale Scrum (LeSS) |
4% |
| エンタープライズアジャイル |
4% |
| Lean Management |
4% |
| Agile Portfolio Management (APM) |
3% |
| Nexus |
3% |
| Recipes for Agile Governance in the Enterprise |
1% |
| 知らない / わからない |
28% |
大規模スクラムの導入・実践時の課題
| 大規模スクラムでの課題・障害 |
割合 |
| 変更に対する組織の抵抗 |
48% |
| リーダーシップの参加・協力不足 |
46% |
| チーム横断でのプロセス・プラクティスの一貫性の無さ |
45% |
| アジャイルがもたらすであろう価値と対立する組織文化 |
44% |
| マネジメント層の協力・サポート不足 |
43% |
| アジャイルに関するスキル・経験不足 |
41% |
| トレーニング・教育の不足 |
39% |
| ビジネスサイド・ステークホルダー・POの関与が不十分 |
36% |
| 従来の開発方法の普及 |
30% |
| 断片化されたプラクティス導入とプロジェクト関連のデータ測定 |
29% |
| コラボレーション・ナレッジシェアの不足 |
22% |
| 法規制の順守または行政の問題 |
16% |
プロジェクトの管理ツール
メジャーなツール・設定
- 多くの回答者が自動承認ツールを使用（昨年は36％に対して39％）、将来アジャイルプロジェクト管理ツールを使用する計画があると回答（昨年は9％から昨年は12％）
- 今年の調査には、新しいオプションがいくつか追加されました（ワイヤーフレーム、製品ロードマッピング、静的分析、タイムカード）
| ツール・設定 |
現在使用している割合 |
将来使用を予定している割合 |
| カンバンボード |
76% |
10% |
| タスクボード |
66% |
10% |
| バグトラッカー |
63% |
15% |
| スプレッドシート |
64% |
7% |
| アジャイルプロジェクト管理ツール |
65% |
13% |
| Wiki |
60% |
14% |
| 自動ビルドツール |
55% |
24% |
| 単体テストツール |
55% |
20% |
| 継続的インテグレーションツール |
54% |
26% |
| ワイヤーフレーム |
49% |
15% |
| プロダクトロードマッピング |
51% |
28% |
| 従来のプロジェクト管理ツール |
44% |
8% |
| 要件管理ツール |
46% |
18% |
| リリース/デプロイの自動化ツール |
45% |
31% |
| 自動受け入れテストツール |
37% |
32% |
| 静的分析 |
38% |
19% |
| プロジェクト＆ポートフォリオ管理（PPM）ツール |
39% |
26% |
| ストーリーマッピングツール |
30% |
27% |
| タイムカード |
30% |
12% |
| インデックスカード |
26% |
14% |
| リファクタリングツール |
26% |
26% |
| 顧客アイデア管理ツール |
19% |
24% |
アジャイルプロジェクトの管理ツール
| ツール |
割合 |
| Atlassian JIRA |
67% |
| Microsoft Excel |
40% |
| Microsoft Azure DevOps |
23% |
| Google Docs |
19% |
| VersionOne |
12% |
| その他 |
12% |
| Microsoft Project |
9% |
| HP Quality Center/ALM |
8% |
| 内製のツール |
8% |
| Atlassian JIRA Align |
5% |
| CA Agile Central |
5% |
| IBM Rational Team Concert |
3% |
| Bugzilla |
3% |
| CollabNet TeamForge |
2% |
| HP Agile Manager |
2% |
| Pivotal Tracker |
2% |
| LeanKit |
2% |
| Hansoft |
1% |
| Axosoft |
1% |
| Target Process |
1% |
推奨されたプロジェクト管理ツール
| ツール |
割合 |
| Atlassian JIRA |
78% |
| VersionOne |
76% |
| Atlassian JIRA Align |
57% |
| LeanKit |
54% |
| Target Process |
54% |
| Microsoft Azure DevOps |
51% |
| Google Docs |
50% |
| CA Agile Central |
48% |
| CollabNet TeamForge |
46% |
| Axosoft |
45% |
| Hansoft |
45% |
| Bugzilla |
39% |
| IBM Rational Team Concert |
35% |
| Pivotal Tracker |
32% |
| Microsoft Project |
30% |
| HP Agile Manager |
30% |
| Microsoft Excel |
26% |
| HP Quality Center/ALM |
23% |
| 内製のツール |
21% |
DevOps & バリューストリームマネジメント
DevOpsの広まり
- 76％は、現在組織内でDevOpsが広がっているか、今後12か月に1つを計画していると述べた（昨年の73％と比較）
| DevOpsの導入 |
割合 |
| 現在導入中 |
55% |
| 計画中 |
21% |
| 予定無し |
13% |
| わからない |
11% |
DevOpsトランスフォーメーションの重要性
- 90％は、DevOpsトランスフォーメーション重要だと回答
| DevOpsトランスフォーメーションの重要性 |
割合 |
| 非常に重要 |
43% |
| 重要 |
26% |
| やや大事 |
20% |
| 重要ではない |
10% |
成功の測定方法：DevOpsトランスフォーメーション
- 最も重要な指標は、品質の向上とソフトウェアの迅速な提供だった
| 指標 |
割合 |
| デリバリーの速さ |
70% |
| 品質の向上 |
62% |
| リスクの減少度合い |
48% |
| 顧客満足度の増加 |
43% |
| ビジネス目標に沿った開発・デリバリー |
39% |
| ITコストの削減 |
39% |
| ユーザーへの価値の流れの可視性の向上 |
34% |
| コンプライアンス/ガバナンスの確保 |
27% |
DevOpsプラクティスの改善*4
- 39％はビジネスバリューのフローの混乱を特定するメトリックスを持っていると答えた
- 34％は企画からリリースまでのトレーサビリティが最も価値があると答えた
| 改善 |
割合 |
| デリバリーサイクルを通じてビジネスへの価値のフローのサイクルタイム、待機時間、ボトルネックを測定する機能 |
39% |
| ビジネスイニシアチブから開発、テスト、および展開までのエンドツーエンドのトレーサビリティ |
34% |
| 導入前の技術リスクの特定と測定 |
34% |
| コントロールポイント全体の自動化された監査、コンプライアンス、およびガバナンスレポート |
28% |
バリューストリーム管理の採用
- バリューストリーム管理（VSM）は、アイデアから異種のエンタープライズソフトウェア配信パイプラインを介して（エピック、ストーリー、ワークアイテムの形式で）ビジネスバリューフローをマッピング、最適化、視覚化、測定、および管理する人、プロセス、およびテクノロジーの組み合わせです。 開発から生産まで。
- 78％は、組織がVSMに関心を持っている、VSMの実装を計画している、または現在VSM実装のある段階にあると述べています。
| バリューストリームマネジメントの計画 |
割合 |
| 拡大する予定 |
14% |
| 導入済みだが、拡大はしない |
7% |
| 現在、導入中 |
19% |
| 今後12か月で導入する予定 |
15% |
| 関心はあるが、短期的な計画はない |
23% |
| 関心がない |
7% |
| わからない |
15% |