アジャイル・DevOps 実践企業サーベイの集計結果と考察
先日、113名もの皆さまの協力を得て、「アジャイル・DevOps 実践企業サーベイ(2016)」を実施させていただきました。その集計結果を公開したいと思います。
サーベイにバイアスが入らないように、事前に公開をしていなかったのですが、本サーベイの目的は、日本に、DevOps を導入するにあたり、その前提条件である、アジャイル開発の導入がどの程度本質的に進んでいるか？ということを調査したかったというのが発端になっています。著名なIPAのサーベイ(2013)では、５１％の企業がアジャイル導入済みになっていましたが、肌感覚的には本当かな？というのがあったので、調査してみたくなりました。
今回はサーベイの結果をフル公開いたします。私もサーベイのプロではありませんし、コメントはあくまで私の見方ですので、みなさんご自由のこのサーベイの結果をご利用ください。皆様の分析を皆様のブログに書いていただいてももちろん大歓迎です。
1. テストおよびその他の自動化の達成状況
分析結果
この項目で調査したかったのは、どの程度のプロジェクトがユニットテストのコードをちゃんと書いているかです。欧米でもユニットテストがアジャイル、DevOps の自動化に関しては最も基礎であり重要なポイントになります。ユニットテストが自動化できていなければ後続の継続的インテグレーションや、継続的デリバリも実現できません。つまり、繰り返し型開発を実施しても、回帰テストがないため、大変不安定でバグなどが多くなると思われます。
上記の実態を見てみると、アジャイル実践企業のうち、32%は手動でユニットテストを手動で実施しているという、衝撃の結果があり、48% ぐらいが実質ユニットテストが継続的インテグレーションができる程度に実施されており、11%がしっかりとしたユニットテストを書く「習慣」ができた企業であるということが読み取れます。実際、継続的インテグレーションの導入も44.2%にとどまっています。
継続的デリバリや、フィーチャーフラグ、システムテストの自働化などの高度な実践は10%程度のプロジェクトが実施している目測になります。
おすすめ事項
もし、皆さまの企業で、アジャイル開発、DevOps を実施して繰り返し型の開発をしているにも関わらず、テスト駆動開発や、継続的インテグレーションを導入していないのであれば、もしよろしければ、導入をご検討ください。お勧めとしては、テスト駆動開発の経験が長いエンジニアをあなたのチームにしばらくでもいいので雇って一緒に開発するのが最も近道だと思われます。なぜなら、テストを書くことは「習慣」なので、座学だけでは身につきにくいからです。私も下記のDevOps スターターキットに、テスト駆動開発の実施イメージをビデオにして公開していますので、どんなものかイメージがわかなければごらんください。
simplearchitect.hatenablog.com
サーベイの詳細データ
2. 企業内のプロジェクト導入の割合
分析結果
先に述べたIPAのサーベイのサーベイが正しいとすると、各企業が個人的に「野良」でアジャイル開発を導入しているのか、ある程度組織として認められて実践しているのかを知りたいと思ったのがこの項目です。48% の企業が、導入が5%以下、つまり、あまり組織的な導入でないということが読み取れます。17%の企業が、アジャイル開発実践企業サーベイであるにも関わらず「0%」であるということも驚きです。一方で16%もの企業が、70%以上のプロジェクトでアジャイル開発を導入しています。
おすすめ事項
この項目では特におすすめ事項はありませんが、草の根活動のアジャイル開発やDevOps 導入を広めたい時には、事例を作って、ビジネスKPIで証明できる成果を上げることをお勧めします。日本の場合は、ある程度権限のある人に対して、説明をして、取り組みを認めてもらうのがよいと思われます。ビジネスKPIとしては、リードタイムなどが図りやすいと思います。Value Stream Mapping などの手法を用いて、Before / After の数値を比較すると、経営層の皆さまに納得してもらいやすくなります。
サーベイの詳細データ
3. アジャイル・DevOps プロジェクト導入の課題
分析結果
課題に関しては、全体的にはアジャイル導入に関する課題が多く、DevOps に関する導入課題がまだ高くないことから、多くの企業はウォータフォールからアジャイル開発へのジャーニーの部分でいまだ苦労していることが伺えます。
数が多い内容に関して記述します。
メンバーがテスト駆動開発が出来ない課題
多くの企業でユニットテストを書く習慣が出来ておらず(54%)、TDD/BDDを実践できるメンバーが少ない(57%)という課題を持っています。
アジャイル開発のマインドセットの導入の課題
マイクロマネジメントがやめられない(42.7%) つまり、自己組織化チームができないのは、アジャイル開発の生産性を大きく阻害する要素ですが、40%以上の企業がそのような課題を持っています。
経営層への説明の問題
経営層が事前に納期、機能、コストを求める(53%) 、会社のルールが、ウォータフォール前提になっており、無駄な作業が多い(43.7%) も高いスコアになっています。これは、うまく上位マネジメント層を巻き込めていないことに起因すると思われます。
技術的負債が膨らんでおりメンテナンスできない
この問題は、米国でも頻繁にあるもので特別ではありません。が解決策に関しては次に記述いたします。
おすすめ事項
テストに関する対策はすでに最初の対策で記述いたしましたので割愛します。経営層の巻き込みに関しては、経営層のわかりやすい言葉と数字で説明する必要があります。またそもそも彼らを「巻き込もう」という意思が必要です。 そのためには、Value Stream Mapping 等のビジネスKPIを明確に出せて、尚且つ本質的な改善につながるものを実施し、定期的に経営層に報告ポイントを設けることを事前合意しておくなどが効果があります。 また、技術的負債に関してはこれも実は「テストを書く習慣」にかかわってきます。しかし、すでに負債となっているものがある場合は、コードレビューなどの静的解析ツールを導入して、技術的負債を見える化するところから始めるのをおすすめします。自動のユニットテスト、そして、リファクタリングという設計変更のテクニックをチームがマスタしているとよりこのアクティビティは進みやすくなります。また、マイクロサービスの考えをつかって、少しづつ、分離できるサービスからマイクロサービスにしていくと、コードベースが小さくなるかもしれません。また、技術的負債はあきらめて、REST-APIの向こう側として扱って、インターフェイスのみ自動テストをできるようにする（せめてスモークテストでも）という手もあります。 いづれにしても難しい問題なので、ケースバイケースです。
一方、「マイクロマネージメントがやめられない」という問題は、サーバントリーダーシップや、自己組織化チームについて学ぶとよいと思います。下記にリソースを提示しておきます。下記のブログを見ると、サーバントリーダーシップや、自己組織化チームの具体例について学ぶことができるかもしれません。一つだけ言えるのは、マネジメントの経験が不要になるわけではありません。ただ、今後この新しいマネジメントスタイルを学ぶとグローバルの市場でも最後にご紹介しているサーベイの結果からも、圧倒的に有利になることは間違いないでしょう。
simplearchitect.hatenablog.com
サーベィの詳細データ
4. 所属企業の属性
この項目は、どのような属性の企業がこのサーベィに答えているか？の分析ですが、結構妥当な割合といえます。（肌感覚でしかありませんが、、、）
サーベイの詳細データ
世界の動向と日本の他のサーベイ
日本の他のサーベイでは、PMIのサーベイ(2015)（日本）では、31%の企業がアジャイル導入済みというデータがあります。先に紹介したIPAのサーベイ(2013)では51%になっています。
世界のサーベイでは、Version One の年次サーベイ(2015)では何と95%もの企業が既にアジャイル開発を導入済みになっており、世界のデファクトになっていることがうかがえます。
余談ですが、著名なSam Guckenheimer が客先訪問をしているときに「アジャイルとウォータフォールの使い分け」について質問された際、「ウォータフォールにメリットはないので、やめておいたほうが良い」とコメントしたことだけは共有しておきます。バージョンワンの世界サーベイの95%の企業がアジャイルを導入済みという数値を見てもそれは裏付けられている言っていいのかもしれません。
一方、日本のアジャイル導入の難易度は世界一高い言っても過言ではありません。
here's the chart. Fun to look at.
— Alistair Cockburn (@TotherAlistair) May 14, 2016
Scandinavia rocks.
India came out surprisingly high.@arne_mertz @RonJeffries pic.twitter.com/NVqDnCGQns
これは、Twitter でアジャイルの父として世界的に著名なアリスターコバーン氏がアジャイル導入の文化的導入難度に関して算出したものです。元のデータはアカデミックなデータに基づいています。
世界がすべて優れているわけではありませんが、少なくとも DevOps の導入に関してはデータ上もリードタイムの削減が1/200等の劇的な削減のデータが出ています。DevOps はツールを導入するだけでは達成できず、アジャイル開発を既に導入済みであることは前提条件になっています。
このデータを見てみなさんがどう感じるかは皆さんにお任せいたします。
