アジャイル開発という名の混乱
アジャイル開発という概念が日本企業に導入されて久しい。しかし、多くの現場で見られるのは「アジャイル」という名前を冠した新しい形の混乱だ。
──── マニフェストの曲解
アジャイルマニフェストは4つの価値と12の原則からなるシンプルな文書だった。
「プロセスやツールよりも個人と対話を」 「包括的なドキュメントよりも動くソフトウェアを」 「契約交渉よりも顧客との協調を」 「計画に従うことよりも変化への対応を」
これらは本来、硬直化した開発プロセスへの反省から生まれた価値観だった。
しかし、現実に起きたのは正反対の現象だ。「アジャイル」という新しい教条主義が生まれ、より複雑で硬直化したプロセスが構築された。
「スクラムマスター」「プロダクトオーナー」「スプリント計画」「デイリースタンドアップ」「レトロスペクティブ」。これらの用語に縛られ、本来の目的を見失った組織が量産されている。
──── スクラムマスター依存症
最も象徴的なのは「スクラムマスター」という役職の扱いだ。
本来、スクラムマスターはチームの自立を促進し、最終的には不要になることを目指すべき存在だった。しかし現実には、永続的な中間管理職として定着している。
スクラムマスターがいなければ会議も進行できない、課題も解決できない、意思決定もできない。これは自律的なチームとは正反対の状態だ。
「ファシリテーター」という美しい名前の下で、新しい形の官僚主義が構築されている。
──── 見積もりの茶番
アジャイル開発における「ストーリーポイント」による見積もりは、もはや儀式と化している。
「フィボナッチ数列を使って相対的に見積もる」 「プランニングポーカーで合意形成する」 「ベロシティを計測して予測精度を高める」
これらの手法は、見積もりの精度向上よりも、見積もりプロセスの複雑化に貢献している。
実際の開発では、結局のところ「いつまでにできるか」「いくらかかるか」という絶対的な数値が求められる。相対的なストーリーポイントでは経営判断はできない。
結果として、ストーリーポイントから工数への変換という新しい無駄な工程が生まれている。
──── レトロスペクティブの形骸化
「振り返り」は改善の源泉であるはずだった。しかし多くの組織では、レトロスペクティブが形式的な儀式になっている。
「良かったこと」「悪かったこと」「改善したいこと」を付箋に書いて壁に貼る。毎回同じような課題が挙がり、毎回同じような対策が議論され、毎回何も変わらない。
根本的な問題は、レトロスペクティブでは変更できない組織構造や技術的負債にある場合が多い。しかし、それらに触れることは「アジャイルの精神に反する」として避けられる。
結果として、表面的な改善提案を延々と繰り返すだけの時間の浪費が制度化されている。
──── デイリースタンドアップという名の報告会
15分間のデイリースタンドアップは、チームの同期を取る効率的な手法のはずだった。
しかし現実には、全員が順番に昨日の作業と今日の予定を報告する冗長な会議になっている。「立って話すから短くなる」という理屈は、リモートワークの普及とともに完全に意味を失った。
本来の目的である「チームの協調と課題の早期発見」は忘れ去られ、「毎日必ずやるもの」という義務に変質している。
──── アジャイルコーチという新しい利権
アジャイル開発の普及とともに、「アジャイルコーチ」という新しい職業が生まれた。
彼らは組織にアジャイルプロセスを導入し、定着させることを生業としている。しかし、ここに構造的な矛盾がある。
アジャイルコーチにとって、組織が真に自律的になることは収入源の喪失を意味する。結果として、永続的な依存関係を生み出すインセンティブが働く。
「アジャイルトランスフォーメーション」という名目で、数年間にわたって組織に居座り、複雑なプロセスを構築し続ける事例は珍しくない。
──── ツールへの過度な依存
JIRAやTrelloといったプロジェクト管理ツールが、アジャイル開発の必須要素として扱われている。
しかし、これらのツールの導入と運用に必要な時間とコストは膨大だ。チケットの作成、ステータスの更新、バーンダウンチャートの確認。本来の開発作業よりもツールの管理に多くの時間が費やされている。
「見える化」という名目で、実際の進捗よりもツール上の見た目の整合性が重視される倒錯が起きている。
──── 技術的負債の放置
アジャイル開発は「動くソフトウェア」を重視する。しかし、短期的な成果を追求するあまり、技術的負債の蓄積を正当化する理由として悪用されている。
「まずは動くものを作って、後でリファクタリングする」という方針は、永続的な応急処置の継続につながる。「後で」は決して来ない。
結果として、保守性の低いコードが量産され、長期的な開発効率は大幅に低下する。これは「持続可能な開発ペース」というアジャイルの原則と矛盾している。
──── 顧客との関係性の悪化
「顧客との協調」を謳うアジャイル開発だが、現実には顧客との関係を悪化させるケースが多い。
頻繁な仕様変更、不明確な完成基準、予測困難なスケジュール。これらはすべて「アジャイルだから仕方がない」として正当化される。
顧客にとって重要なのは、開発手法の名前ではなく、予定通りに予算内で求める品質のものが得られることだ。アジャイル開発はしばしば、その期待を裏切る。
──── 本来の価値への回帰
アジャイル開発の問題は、アジャイルという概念自体の欠陥ではない。問題は、その実装と運用にある。
重要なのは、形式的なプロセスの遵守ではなく、本来の価値の実現だ。
個人と対話を重視するなら、余計な会議を減らし、直接的なコミュニケーションを促進する。 動くソフトウェアを重視するなら、ドキュメント作成よりもコード品質に投資する。 顧客との協調を重視するなら、内部プロセスよりも顧客価値を優先する。 変化への対応を重視するなら、硬直化したスクラムプロセスを柔軟に変更する。
これらは当たり前のことのように聞こえるが、多くの「アジャイル組織」で実践されていない。
──── 混乱からの脱出
アジャイル開発という名の混乱から抜け出すためには、原点回帰が必要だ。
プロセスや手法にとらわれるのではなく、何のために開発をしているのかを常に問い直す。形式的な儀式よりも、実質的な成果を重視する。外部の権威に依存するのではなく、チーム内での自律的な判断を育成する。
「アジャイル開発をやっている」ことよりも、「価値のあるソフトウェアを効率的に開発している」ことの方が重要だ。
手法は手段であって目的ではない。この基本的な事実を忘れたとき、どんな優れた手法も混乱の源泉になる。
────────────────────────────────────────
※本記事は特定の組織や個人を批判するものではありません。アジャイル開発の構造的問題についての個人的見解です。