アジャイル開発に対するいくつかの反論
前回の投稿「アジャイル開発とポリティカル・コレクトネス」では、アジャイル開発に対して疑問を持ち始めた企業が、アジャイル開発から撤退を始めたようだ、というような内容を書きました。今回もその続きです。
アジャイル開発は、ウェブベースのアプリケーションにはとても良い開発手法だと思います。特に自社の商品やサービスをウェブ上で販売する会社が、社内のIT部門を使ってウェブ・アプリケーションを開発している場合（自社開発）は、アジャイル開発のROI（Return on Investments: 費用対効果）はとても高いと思います。
プラットフォーム（WindowsやiOSなど）系のアプリケーションを開発している企業も、アジャイル開発を行う利点があるかもしれません。特に自社開発でITシステムやサービスを提供している場合です。しかし顧客からの請負でITシステムやサービスを開発しているのであれば、アジャイル開発が一番なのかと問われれば、少し疑問が出てきます。ROIも低くなるでしょう。
ファームウェアを開発している企業は、それを組込む製品の特性（開発期間やリリース頻度）にもよりますが、アジャイル開発でなければならないという理由が見つかりません。
ハードウェアを開発している企業もファームウェア開発企業と同様に、1工程のサイクルタイムの長さやリリース頻度を考えても、アジャイル開発でなければならないという理由が見つかりません。ROIで言えば、リターンが少しでも出れば御の字でしょう。他にもROIの高い開発手法がたくさんあるので、そちらを検討した方が良いかもしれません。
つまりアジャイル開発はニッチなマーケット（アプリケーションや前提条件が合った場合）にはとても有効な開発手法であり、ROIも高いかもしれませんが、他の大多数にとっては、それが一番という訳ではなく、またROIも言われているほど高くはないのではないか、と思います。その理由を、アジャイルソフトウェア開発宣言とアジャイル宣言の背後にある原則を使って、あくまでの個人的な経験から説明したいと思います。
アジャイルソフトウェア開発宣言
「プロセスやツールよりも個人と対話を、」
- アジャイルを上手く運用しようと努力すればするほど、逆に決め事（ルールとプロセス）がどんどん増えていく
- アジャイル・チームの自律性に任せることで、逆に開発ツールの数がどんどん増えていく
- 個人の対話が増えても、それは問題を明るみに出すだけであって、問題を解決するわけではない
- 問題を解決しようとすると、ますます決め事（ルールとプロセス）が増えていく
「包括的なドキュメントよりも動くソフトウェアを、」
- 自社のための自社開発のシステムやサービスならともかく、顧客がある限りドキュメントは重要である
- 自社のための自社開発のシステムやサービスならともかく、規格や認証、ガイドラインを順守する必要がある製品はドキュメントが重要である
- ドキュメント（仕様書等）がなければ、動くソフトウェアを評価できない
- ドキュメントが軽んじらるようになり、重大欠陥の発見が遅れる
- 重大欠陥の発見が遅れるため、開発後期になって開発作業のやり直しが生じ、開発工程が長引く結果となる
「契約交渉よりも顧客との協調を、」
- そもそもアジャイル・チームに顧客が参画するようなプロジェクトはほとんどない
- 多くの場合、顧客とは契約で始まり、協調はドキュメント（仕様書）である
- そもそも契約交渉を望むのは顧客である
「計画に従うことよりも変化への対応を、」
- ウェブベースのアプリケーションならともかく、プラットフォーム系やファームウェア、ハードウェア開発の場合は、変化へ代償が大き過ぎる（コストや時間）
- 変化への代償を理解しない顧客が、「計画に従うよりも変化への対応を」というアジャイル開発宣言を理由に仕様の変更を迫ってくる
- 変化への対応はバックログを積むこと
「価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。 」
- アジャイル開発宣言が重きを置くその価値に近い"ニッチ"な開発対象や顧客ならば、アジャイル開発も良いかもしれない
アジャイル宣言の背後にある原則
「 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」
- ウェブベースのアプリケーションならともかく、頻繁なバージョンアップは顧客にとってはむしろ迷惑である
- 頻繁なバージョンアップが継続すれば、信頼性に問題があると思われる
- ウェブベースのアプリケーションならともかく、他の多くのアプリケーションや顧客にとって、顧客満足は仕様を満たすこと
「要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。」
- 上記アジャイルソフトウェア開発宣言「計画に従うことよりも変化への対応を、」と同様
- そもそも実際にはバックログだけが増えていくだけで、変化への対応をしていない
「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」
- そもそも開発サイクルタイムは開発対象や開発フェーズごとに違う
- 無理に開発サイクルタイムを短くすることで、無駄が多くなる
- サイクルタイムを短くすることでイノベーションの機会がなくなる
- そもそもバックログが何か月分も溜まっているような状態で、短い間隔でのリリースに意味があるのか
「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」
- そもそもビジネス側の人がアジャイル・チームに参画し、毎日一緒に働くようなプロジェクトはほとんどない
- そもそもビジネス側の人がアジャイル・チームにいて一体毎日何をするのか、むしろ邪魔なだけ
- それよりもビジネス側の人は始めにしっかりとした仕様書を作ってほしい
「意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。」
- 意欲の有無にはまったく関係なく、頭数を合わせるためにプロジェクトチームは編成される
- 実際には、十分な環境と支援（リソースや時間）が与えられることはない
- 環境と支援を与える側は、アジャイル開発を与えれば十分だと考える
「情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。」
- 多くの場合、チームメンバーが地理的に分断されている
- 多くの場合、信頼性を保証するものはドキュメントであり、話をすることではない
- 話し手と聞き手にはそれぞれ違う情報フィルターがあり、理解した内容が違う
- ファイス・トゥ・ファイスの話にはドキュメントや履歴が残らず、「言った、言わない」といった問題が後々生じる
「動くソフトウェアこそが進捗の最も重要な尺度です。」
- 短い期間に動くソフトウェアが頻繁にリリースされるのであれば、進捗管理に使えるかもしれない
- そうでなければ、動くソフトウェアを進捗管理の重要な尺度にはできない
「アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。」
- チーム編成はプロジェクトごとに変わり、開発ペースは開発フェーズによって異なる
- 自社開発のウェブベースのアプリケーションならともかく、受注開発なら持続的な開発プロセス、開発ペースはほとんど存在しないか、あっても長くて1~2年
「技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。」
- 異議なし
「シンプルさ（ムダなく作れる量を最大限にすること）が本質です。」
- 異議なし
「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。」
- 自己組織的なチームがアーキテクチャを作ることによって、実際にはフランケンシュタインのような一貫性のないアーキテクチャになってしまう
- 上記「シンプルさ」にも関連して、シンプルなデザインは計画されたアーキテクチャから生まれるものであって、自己組織的なチームから生まれるものではない
「チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。」
- レトロスペクトでは定期的に問題は認識できても、それを最適化するどころが、問題を解決することもできない
- 同じ問題が解決されずに、いつまでも改善項目として残る
- そもそもチーム員は開発だけで忙しく、問題を解決したり最適化するような余裕はない
つまり言いたいことは、「アジャイル開発は理想であって、多くの場合、理想が前提とする条件とは異なる」ということです。もし僕のチームがGAFAのようなアメリカ西海岸の文化を持ち、優秀なエンジニア達によって自社のためのウェブベースのアプリケーションを開発する理想のチームであれば、アジャイル開発はとても良いと思うのですが、実際はそうではありません。ふつうのエンジニアにとってアジャイル開発は脆弱で難し過ぎます。
「ポリティカル・コレクトネス」の人は「それは君たちがまだアジャイルに未熟だからだ」と言うでしょう。確かにそうかもしれませんが、チームがアジャイル開発に成熟するまで、それがいつとも知らず、無駄にお金と時間と労力を費やすことが、政治的に正しいのでしょうか。他にもっと簡単で有効な方法があるにも関わらず、政治的に正しいからといって、アジャイル開発だけを無暗に推し進める風潮には正直疑問を感じます。