目次
アジャイル開発はどこまで進んでいるのか
前稿の 『ポスト「モダンPM」というけれど』 では日経systemsさんの記事をネタにしてなぜアジャイル開発をもっと前面に出すような記事をが書かないのか？ なぜアジャイル開発と似て非なる記事を書いてポスト「モダンPM」なる造語まで用意するのか？ という話をした。
皆さんの中には「既に導入済みだよ」とか「うちは当面ウォーターフォール型（以下WF型）でいくつもりだ」とお考えの方までいろいろいらっしゃると思う。 ただ、後者の皆さんの中にも「アジャイル開発って巷ではどんだけ普及しているんだい？」というちょっとした好奇心をお持ちの方が少なからずいらっしゃるのではないかと推測する。
そこで世界のアジャイル開発の導入状況などを10年にわたり調査・報告してくれているVersion Oneから今年もレポート（2016年版）が出たのでその概要をご紹介したい。
私がアジャイル開発の調査を始めたのが2000年代中頃、SCRUMを実際に推進をすることになったのが2011年。 その当時から世界のアジャイル開発の動向をしっかりと調査報告してくれる数少ない機関がVersion Oneだった（国内の事情はIPAさんの資料などを参照）。
それ以来Version Oneのレポートをことあるごとに参考にさせてもらっているが、どの調査にも多かれ少なかれいえることだが、アンケート調査に協力する会社はその対象を少なからず意識している可能性が高い。
そういう意味ではアンケート調査も実態より少し前のめりになっている傾向は頭に入れておいた方がよいだろうが、少なくとも私の体感としてはアジャイル開発を導入している企業はこの6年間で確実に増加しているという点だ。
今は小さなイノベーションが束になって世の中をどんどん変えていく、という「プチ・イノベーション爆発」(*1)が起きている中で、要件変更にも柔軟に対応できる機動的な開発体制であるアジャイル開発が車の両輪のように進展していくというのは理にかなった自然な流れだろう。
(*1)プチ・イノベーション爆発とは
筆者の造語で、当サイトのブログ名「プチイノベ論考」もここからきている。 ここでは直感的にとらえてもらえればよいが、詳細はイノベーションのカテゴリの「イノベーション論考」を参照していただきたい。
これから紹介するVersion Oneのアニュアルレポートは登録すればだれでも読むことができる。 以下のサイトかロゴをクリックすればPDFをダウンロードすることができる。（http://stateofagile.versionone.com/）
”Version One”調査レポートの概要
本レポートの冒頭のエグゼクティブサマリーでは以下の説明から始まっている。
2006年当時の回答数は1000以下だったが今年は四倍近くの3880に上った。
開発規模も10年前は三分の二が100人以下だったが、2015年の回答者の31％は1000人以上のソフトウエア開発会社だったようだ。 また三分の一以上が採用を始めてから5年以上がたっている。
・・・
この報告書の中から主な項目をピックアップして（7割程度カバーした）、アジャイル開発の専門的知識が必要な箇所には解説を加えた。
尚、私の説明はデファクトスタンダードとなったSCRUMを前提としている。
【回答企業の地域マップ】
やはりユーザー企業が直接開発をするケースが多いこともあり米国が半数以上だがアジアも11％と2ケタに乗せている。 巷の会議などに参加しているが、インドや中国などが積極的に導入を推進しているようだ。
アジャイルの地域別普及度 出展：Version One
【業種】
回答をした企業の業種はやはりISV（26％）、金融（14％）プロフェッショナルサービス（11％）で全体の半数を占める。 プロフェッショナルサービスとは専門分野に特化したSIerに近いイメージではないだろうか。
回答企業の業種 出展：Version One
【アジャイル開発導入比率】
「半分以下のチームがアジャイル開発」が最も多く53％、 「全てのチーム」（9%）と「半分以上のチーム」（34%）を合わせると「アジャイル開発がマジョリティ」だとする回答が43％に昇る。
逆に全く導入してないと回答した企業はたったの4％だったようだ。
アジャイル導入比率 出展：Version One
【アジャイル開発導入理由】
トップ３は以下の通り。
１、製品投入速度の加速：62％
２、優先順位の変更に迅速に対応可能にするため：56％
３、生産性の向上：55%
私が5年間推進した経験からアジャイル開発（SCRUM）に慣れたチームのコーディング・デバックの生産性は外部リソース（協力会社等）を利用したWF型と比較して平均3倍程度上昇した。 この生産性があるからこそ、TDD（コード量が倍になる）やペアプロ（リソースに対するアウトプットが約三分二程度に低下する）による増大するリソースを吸収してくれる。 WF型を採用するとせいぜいユニットテストどまりで、TDDやペアプロ導入はかなりハードルが高いはずだ。
アジャイル開発導入理由 出展：Version One
【導入後の効果】
ここでは比率が高いのでトップ５まで挙げておく。
１、要件の優先順位の変更が向上した：87%
２、チームの生産性向上：85%
３、プロジェクトの可視化の向上：84％
４、チームのモチベーションアップ：81%
５、リリース精度の向上：81%
【導入手法】
導入手法に関してはやはりSCRUMが最も多く（58%）、SCRUM・XPを併用を合わせると約7割の企業がSCRUMベースでアジャイル開発をしていることが分かる。 SCRUMは比較的プロセスが明確なので特にWF型に慣れた管理職にも直感的に理解しやすいというのが理由ではないかと推測する。
アジャイル手法 出展：Version One
【アジャイルテクニック（プラクティス）トップ５】
アジャイルプラクティスとしては予想通り、鉄板と言われるものが占めている。。
１、デイリースタンドアップミーティング：83%
ここで「やったこと」、「これからやること」、「課題・障害」の3つを手短にメンバー共有するんですね。
２、優先順位付けされた要件（バックログ）：82％
これから片づけなければならない要件を優先順位の高いものから並べたものをバックログと呼ぶ。プロダクトバックログと（1週間～4週間）単位のスプリントバックログがある。 これらのバックログは１スプリント（タイムボックス）ごとに最新の優先順位に並べ替えられる。
３、短いイテレーション：79％
1つのイテレーションの長さ（スプリント）はSCRUMの場合、１～２週間を推奨されているが、初めて導入するプロジェクトは1か月程度から始めてはいかがだろうか？
４、レトロスペクティブ（振り返り）：74%
レトロスペクティブという用語は、SCRUMではよく使われる「振り返り」という訳にしてみた。
これは何かというと、例えば１つのスプリントの終了後に行うチームおよびチームメンバーの為の改善活動のようなもの。
例えば、自分たちのやり方等に関して振り返りを行い、問題や課題を発見し、皆で改善策を検討しプロセスやチームの文化を成長させていく「チームによるチームの為の」重要な活動だ。
５、イテレーション計画会議（スプリント計画ミーティング）：69%
SCRUMの場合、これから始めるスプリントで何を開発するのか（プロダクトバックログの中から優先順位の高いものを選択してスプリントバックログを作成する）、どのように開発するのか、スプリント終了後に行うレビューで何を確認するかなどを話し合う。
アジャイルテクニック（プラクティス） Verion One
【アジャイル開発の失敗原因】
ここは重要な個所なので1位から5位までそのまま上げると以下のようになっているようだ。
やはり総じてアジャイルの価値観や手法への移行がうまくいってないのが分かる。
１、アジャイル開発の価値観が企業文化や理念に合わない:46%
２、アジャイル手法の経験不足：41％
３、組織的なサポート不足（管理サポート不足）：38％
４、企業文化の移行に関するサポート不足：38%
５、アジャイル開発のプラクティスとプロセスの不整合：38%
【アジャイル導入に対する障害】
導入への障害は、上記失敗原因と相関はあるものの、WF型が根付いておりあえて変更する必要がない、あるいは変更したくないと考えている回答があるのはある意味当然のことだろう。 最初から要件がカチッと決まっている場合にはWF型の方が適している（効率が良い）のは間違いないだろう。 更に多少の要件変更があったとしても、様々な工夫によりある程度吸収することはできる。
アジャイル導入に対する失敗原因 出展：Version One
１、組織文化の変革が難しい：55%
２、一般的な（どの組織でもあるような）抵抗勢力：42%
３、既存のウォーターフォール手法が確立しているから：40%
４、アジャイル開発の経験者不足：39%
５、組織的なサポート（管理サポート）の問題：38%
【アジャイルの成功基準】
何をもってアジャイルが成功したといえるか? というアンケート調査結果だ。
日程通りのリリースが58%で一意にきているのがやや意外だったが、これはWF型と比較してのことなのだろうか？
総じて言えることは「ユーザの満足するようなビジネス的に価値のある製品を日程通りにリリースすること」を成功基準として期待しているということだろう。
アジャイルの成功基準 出展：Version One
１、日程通りのリリース：58%
２、製品品質：48%
３、顧客/ユーザーの満足度：46%
４、ビジネス価値：46%
５、製品の要件（機能要件）：36%
６、生産性：31%
【アジャイルのスケール手法】
スケールは「横展開」ではなく「大規模化」ととらえた。
個人的にはSCRUMは５，６人が最適な人数とされ、10人以上になったら2つに分割するというのが定番となっている。 私の経験ではSCRUMのチームにテストエンジニア等品質評価者も加えたので６，７人で構成した。
大規模化していくと各グループ間で情報交換が必要となるのでスクラムチームが多階層化していく。 その手法にScrum of ScrumやSAFeがある。
2014年からIBM等複数の団体がこれを推進したため2014年の19％から2015年は27%に上昇している。
個人的にはScrum of Scrumは十チームを超えたあたりからチーム間のコミュニケーション爆発が起きやすいのでそれらをいかに計画して統制していくかがポイントとなる。 SAFeが伸びているのは宣伝効果と上層部に説明がしやすいことが一因だと思われる。先ずは上層部用に承認してもらうことが重要だが、実際の開発部隊がこれを導入する場合には用意周到に計画をたてるべきだろう（個人的見解）。
１、Scrum, Scrum of Scrum：72%
２、SAFe：27%
３、自分たちの独自手法：17%
４、リーンマネジメント：17%
５、Enterprise Agile、Enterprise Scrum(各9%)
【アジャイルのスケールの為のヒント】
一つだけコメントすると、最初はコンサルやトレーナーに指導してもらうことをお勧めします。
理由は価値観の変化は座学ではなかなか習得できないからです。
１、一環したプロセスとプラクティス:43%
２、共通ツールの導入:40%
３、コンサルタントとトレーナー:40%
４、経営トップからの理解と支援:37%
５、内部のアジャイルサポートチーム:35%
【 使われている一般的なツール】
スクラム タスクボード
やはりタスクボードが82%でトップ。
移動可能なホワイトボードを2枚用意し、1枚にはメンバーのタスク状況が分かるようにタスク名を書いた付箋（いわゆるポストイット™）をはり、もう一枚にはバーンダウンチャートや連絡事項、課題などを記入したりするケースが多い（基本はチームがチームの為に使えばよい）
バグトラッカーはBTS/ITS等と呼ばれるツールで、以下のようなものがある（一例）
・Redmine：Ruby on Rails で開発された OSS (GPLv2)
・Team Foundation Server：Microsoftが提供
・Trac：Python で開発されている OSS (修正BSD)
・JIRA：Atlassian 社が開発・販売している Javaベースのツール
アジャイル開発は途中で要件変更が入るため回帰テストの工数を抑えるためユニットテスト（できればTDDを推奨）や自動ビルド（所謂CIと呼ばれる継続的インテグレーションを推奨）が必須となる。（はずだが、三分の一のチームは導入してませんね、笑）
１、タスクボード：82%
２、バグトラッカー：80%
３、スプレッドシート：74%
４、Wiki：68%
５、ユニットテストツール：66%
６、自動ビルドツール：66%
【全体所感】
変化に即応するAgile
これまでアジャイル開発をやる時のツールの三種の神器はRedmine, Git, Jenkinsが鉄板だという認識だったが、世界では予想以上に様々なツールが使われているようだ。
導入企業の7割がSCRUMを採用しているのはやはり比較的プロセスが明確なので中規模以上、特に大企業でも導入がしやすいというのが理由だろう。
個人的にはSAFeは経営トップを説得するには使えそうだが（雰囲気はでている）、あの手法をそのまま開発部隊に落としてもうまくいかないことが予想されるので開発の仕組みに工夫が必要だというのが持論だ。 そんな中で特定のコンサル会社が宣伝のが稿を奏したのか、2015年に導入企業が急増した（27%）なので、その後どうなったのかを是非とも聞いてみたい。
いずれにしてもプチイノベーションが加速化してくると開発もいつまでもWF型というわけにはいかなくなってくるだろう。
一方アジャイル開発は資料などを読み込んで手法だけまねても失敗する。 自分たちでうまく運用できるようになるまでに、コンサルを入れても１～２年はかかることが予想されるので、今後ビジネスの舵をTime2Marketにシフトしていこうとお考えの方は、早めにチーム（最低でもスクラムマスター）を育てておいた方がよいだろう。
以上
2016年5月26日
