みなさんこんにちは。@ryuzeeです。

スクラムの導入状況

Scrum Allianceが調査を行ったThe State of Scrum Reportの2017年版が公開されていますので、サマリーを見ていきましょう。なお、レポートはこちらから無料でダウンロードできます。

調査の概要

2016年秋に実施。回答者はScrum Allianceのメンバー2000人以上から回答。なおメンバーになれるのは、認定スクラムマスターや認定スクラムプロダクトオーナー等のコースを受講した人であるため、回答者の属性はスクラムの知識がある人に偏っていることを前提として認識しておく必要があります。回答者は76カ国、15以上の産業にまたがっており、40%がIT関連の仕事、26%がソフトウェア開発に携わっているそうです。質問内容は全部で44個から構成されており、アンケート回答者の属性・スクラムの導入状況・スクラムのロールとプラクティスの3つのカテゴリに分かれています。

調査結果の紹介

前述のとおり項目数が多いので、その中からいくつか特筆すべき項目について見ていくことにしましょう。なお数字はレポートからの引用、文章はその数字に対する私のコメントです。

組織の中でのスクラムの利用状況

世間にはスクラムを利用していることで知られている会社でも、実際にはごく一部のプロダクトやプロジェクトだけで使っていて、あとは従来型の開発をしているというのは良く聞く話です。アンケートの結果によればスクラムの組織内での利用状況は以下のとおりです。組織全体に適用が進んでいるのは24%なので、回答母集団の偏りを踏まえると実際にはそれより少ないと思われます。

割合	状況
61%	スクラムは使っているプラクティスの1つ
24%	スクラムは組織全体に広まっている
11%	スクラムをお試し中
2%	スクラムをやってみたがその後の方針は未定
2%	スクラムをスケールアップしようとしたが失敗した

スクラム適用で重要と思われる点

特に大きいのがいわゆるマネジメントや経営者のスポンサーシップとサポートです。スクラムは組織構造と密接な関係性があるので、ボトムアップ「だけ」で行うのは辛いこともあり妥当な結果だと思います。そもそもスクラムに限らず何かを変えていく場合には、意思決定権限やヒト・モノ・カネを扱う人からのサポートは重要です。

割合	内容
66%	上級管理職のスポンサーシップとサポート
48%	経験豊富なトレーナーやコーチの参画
48%	スクラム自体が会社の全体的な戦略やゴールに合致していること
43%	スクラムを使って達成したい明確なビジネスゴールがあること
37%	従来のやり方からの反発の少ない移行
30%	成否を測定するための明確なメトリクスの存在

スクラムを使って成果を出す上で障壁となっている点

組織構造や文化やマインドセットなどに関する項目が多いようです。

割合	内容
52%	組織構造や企業文化があわない
44%	伝統的なウォーターフォールからの移行が難しい
42%	他のプロジェクトとの兼ね合い
41%	どうやって成功を具体的に測定してよいか分からない
36%	信頼関係の欠如
34%	予測を欲しがる
32%	プロダクトオーナーや開発チームがスクラムのプラクティスに従わない
29%	透明性に対する恐怖
23%	顧客にスクラムが正しいアプローチだと理解してもらうのが難しい
18%	上級管理職がスポンサーになってくれずサポートもしてくれない

スプリントの期間

2週間スプリントが多いのは妥当な結果ですが、1週間スプリントがわずか4%しかないことは驚きです。一般的に言えば、スプリント期間が長くなるほど、計画作りが難しくなり、また改善のサイクルも長くなってしまうので、できれば短くした方が良いでしょう。個人的にはなるべく1週間スプリントを推奨するようにしています。自分の経験では、外部との依存関係が多い、プロダクトオーナーが忙しすぎる、プロジェクトの掛け持ちをしているなどの要因がある場合にスプリント期間を長くしたがる傾向にあるように思いますが、本来やるべきなのはその要因を取り除くことです。

割合	期間
4%	1週間
66%	2週間
26%	3-4週間
4%	それ以上

スクラムと併せて使っている技術プラクティス

スクラムでは技術的なプラクティスについて触れていませんが、実際に毎スプリントでリリース判断可能なインクリメントを作ろうとすると、品質を確保し続ける仕組みが必要と言えます。集計結果を見ても、それがはっきり表れています。またプロダクトバックログアイテムを上から1つづつ終わらせるには開発チームのメンバーでよってたかって終わらせる方がよいのでペアプログラミングやモブプログラミングは有効です。

割合	内容
74%	完成の定義
58%	自動化されたテスト
57%	継続的インテグレーション
54%	リファクタリング
49%	適切なツールの活用
35%	ペアプログラミング
35%	テスト駆動開発
23%	受け入れテスト駆動開発
16%	システムデザインのシンプル化
16%	技術的負債の測定
15%	Specification by Example
12%	BDD(ふるまい駆動開発)
4%	モブプログラミング