【Why Agile?】なぜアジャイルなのか？｜言語化できる
この記事では改めて、なぜ「アジャイル（開発）」なのか？について考えていきます。
アジャイルが叫ばれ、導入が進んでいる背景として、大きく4つの要因があると考えています。
分かるようで分かりにくい、分かったつもりになっても実践が難しいと言われるアジャイル。せっかくアジャイルに取り組むのであれば、「なぜ？」を理解したいです。
VUCA時代（ビジネス環境のめまぐるしい変化と複雑性への対応）
VUCA（ブーカ）とは下記の略称となります。
- Volatility（変動性）
- Uncertainty（不確実性）
- Complexity（複雑性）
- Ambiguity（曖昧性）
一言で表現すると、予測不可能な世界（時代）、ということです。現在のソフトウェア開発を取り巻く環境は下記となっています。
- 市場、世界が変化する
- ビジネス要求が変化する
- ユーザーニーズが変化する
- 技術が変化する
プロダクト（ソフトウェア開発で得られるもの）はビジネスのための手段です。ビジネス環境が急速に変化するのであれば、ソフトウェア開発も俊敏に追随する必要があります。
ビジネス環境の変化がゆっくりであれば、俊敏である必要がないため、じっくりと計画を立てて、それ通りに作れば良いのです。
一方で、ビジネス環境の変化が早い場合には、それに対してソフトウェア開発も俊敏でないと、結果的にできあがったプロダクトがニーズと合わないものとなり、最悪、全てが無駄になります。
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
アジャイル宣言の背後にある原則
プロダクトをリリースしたら終わりではなく、その後もニーズが変化するため、早く継続的にエンハンスのリリースをしていく必要があります。
「Why Agile？」の答えのひとつは「ビジネスがアジリティ（俊敏性）を求めているから」となります。
従来型開発の限界（受発注側双方の苦しみからの脱却）
そもそも、アジャイル開発は従来型の開発に不満を感じ、よりより開発方法を見つけ出そうとしていた有識者たちがたどり着いたマインドセットです。
例えば下記のような不満があげられます。
- プロジェクト開始当初から失敗することが目に見えている
- 発注側、受注側、多重下請け構造となっており上下関係ができてしまっている
- コミュニケーションミスから信頼関係が崩壊する
- 要件定義工程がなかなか終わらない、詰めきれない
- 要件、仕様変更が多発する
- 必要なスキルを持った要員をアサインできない
- あと工程になって手戻り、バグが多発する
- スケジュール、コスト、スコープが固定化され超過勤務が当たり前になっている
- 動かないシステム、使われない機能を開発してしまう
- プログラマが冷遇されている
- プロジェクトに不満を持つ人が増え、機嫌が悪く、笑顔が少ない
- 高稼働のデスマーチが続き、人が倒れる
などなど、枚挙にいとまがありません。
しかし、この苦しい状況が当たり前だと思い込んで頑張ってしまう人たちがとても多いです。逃げずに頑張るのは日本人の気質かもしれません。そして、その失敗の学びが次に生かすプロセスになっていないため、同じような失敗を何度も何度も繰り返してしまいます。現在の働き方改革が叫ばれている時代から見ると、明らかに持続可能なプロジェクトではありません。ただ、その状況を憂いて受け入れた上で前向きに変えようと立ち上がろうとしていた人々の一部が「アジャイル」に辿り着きました。
また、日経ビジネスでは下記の調査結果が掲載されています。
●2003年（回答者数1746件）
プロジェクト成功率：26.7％
●2018年（回答者数1201件、プロジェクト件数1745件）
プロジェクト成功率：52.8％
日経ビジネス
上記のように2018年では成功率が上がっているものの、約半分は失敗しています。失敗してしまうと誰も幸せになりませんし、どれだけ頑張っても報われません。
成功率が上がったものの、「半数が失敗」している現状がある。2018年の調査で日経コンピュータは失敗したプロジェクトの失敗理由を調べている。それによると、満足を得られなかった理由の筆頭は「要件定義が不十分」、コストを順守できなかった理由の筆頭は「追加の開発作業が発生」、スケジュールを順守できなかった理由の筆頭は「システムの仕様変更が相次いだ」だった。スケジュールを守れなかったプロジェクトで最も苦労した工程を尋ねると「要件定義」が筆頭に来た。
日程ビジネス
上記のようにいかに「要件定義」という工程がいかに難しいのかが分かります。
その満足を得られなかった理由をアジャイルでは下記のように解釈できます。
- 要件定義が不十分：最初から全ての要件を洗い出すことは不可能
- 追加の開発作業が発生：未来がどうなるかは誰も保証できない
- システムの仕様変更が相次いだ：最初から全てを見通すことは不可能、ユーザーニーズは絶えず変化する
つまり、都合のよい理想を前提に計画を立てるのではなく、真実を受け止めて、それを前提にいかに価値の高いソフトウェアを無駄なく開発するのかを考えていくことがアジャイル開発です。
逆に要件定義工程で十分に要件を定義でき、全ての作業を見通すことができ、要件・仕様に一切に追加・変更が入らず、リリース後もエンハンス対応が不要なのであれば、従来型の開発（ウォーターフォール型）がもっとも効率の良い手法となります。
しかしながら、一定規模以上のプロジェクトで理想的なウォーターフォール開発で完了したものを見たことがありません。何らかの作業の見落としや、要件・仕様変更がほぼ必ず入ります。「プロジェクト」は独自性を持っており2つとして同じプロジェクトはありません。新規のプロジェクトに取り組むのは誰もが初心者となります。その中で、プロジェクトのキックオフからリリースまでの作業を漏れなく全て洗い出し、正確に作業を見積もることなど不可能です
このようにプロジェクトの失敗要因はアジャイルのマインドセットや原則を適用することで、解決できることが多くあります。
「Why Agile？」の答えのひとつは「従来型の開発はもう限界（持続可能ではない）だから」となります。
導入ハードルの低下（技術の進化と方法論の成熟化）
2001年当初はまだまだ「アジャイル開発」が一般的になっておらず、アジャイルに関する書籍も、インターネットもとても少ない時代でした。それがもはや、「アジャイル」のキーワードでAmazon検索、Google検索をすれば良書、良サイトに辿りつくことができます。また、「アジャイル開発」の実践者も増えているため、研修、アジャイルコーチ等も増えてきております。
方法論も様々（スクラム、XP等）なものがあり、そのメソドロジーだけでなく、それに対する実践知も蓄積されており、そのような先人たちから多くのことを学ぶことができます。
また、アジャイルの方法論だけでなく、デザイン思考やリーンスタートアップ等を組み合わせることで、よりビジネスの成功確率を高めることができたことも大きいです。
また、技術的な進化も目覚ましいものがあります。クラウド、CI/CD環境、プログラム言語の成熟等の技術的な進化にともなって、アジャイルを実践するためのコストがどんどんと下がっています。アジャイルの価値や原則を実践したくとも、それに伴うコストが価値を超えてしまうと導入することができません。しかし、コストが下がると相対的に価値の方が大きくなるため、導入ハードルの低下に繋がっています。この傾向は今後強まると考えています。
アジャイル開発の流行（グローバルでは8割以上のシェア）
グローバルにおいてはアジャイル開発のシェアは8割以上と言われています。一方で、日本ではまだまだウォーターフォール開発の方が主流となっています。
ただ、ガートナーは下記の調査結果を公表しています。
大企業では既に7割がアジャイル型によるADを採用または採用予定 環境の変化が激しいデジタル・ビジネスの時代における大企業の危機意識が表れる
ガートナー、アプリケーション開発 (AD) に関する調査結果を発表
日本でも「アジャイル」「DX（デジタルトランスフォーメーション）」などの言葉が踊り、よく分かっていなくとも何かしなければならないのではないか、という焦りも見えてきています。
「経営層や上司からアジャイルの検討をしてくれ」と指示があったが、どうすればよいか分からない、という声をよく聞きます。また、バリバリのウォーターフォール開発をずっとやっているが、将来のキャリアが不安という声もあります。同業他社の「アジャイル」や「DX」を始めた、うまくいったというニュースが流れると、先起こされるのではないかと焦る気持ちも分かります。
そのような焦りや危機感から、アジャイルを学んだり、アジャイルのコーチやコンサルタントを迎えて、アジャイルに切り替えることにチャレンジする企業も増えています。
「Why Agile？」の答えのひとつは「アジャイルが流行っており、取り残されるという危機感から」となります。
4つの答えについて書きましたがいかがでしたでしょうか。ひとつでも納得できるものがありましたら幸いです。
上司や同僚などから、「なんでアジャイルをやるのかな？」と聞かれたら、何かしらの回答ができるようになればと思います。