開発プロセスとサッカーの戦術

ウォータフォールは、サッカーの戦術でいうところの「カウンターサッカー」であり、我らがアジャイルは、「ポゼッションサッカー」である。

ウォータフォールは、ドキュメントという硬い壁で、基礎を固める。攻撃（仕様変更）に人数をかけてはいけない。敵（顧客）に攻撃（要件fix）させて、カウンターで攻めるのがセオリーである。
リスクをできるだけ排除し、結果を残す。エンターテイメントとしては、つまらないが、仕事は結果が全てだから、これでいいのだ。
しかし、敵の攻撃力が凄すぎて、ボロクソに点を取られたときには、どうするのであろうか？

サッカーの場合、無論、守備の数を減らしてでも、攻撃にでるはずだ。残り時間が少なくなった場合、長身の攻撃の選手を投入し、ロングボールをひたすら入れる戦術（パワープレイ）を取る場合もあるだろう。

ところが、システム開発になると、こうはなかなかいかない。
例えば、仕様変更やバグが噴出した場合でも、これまでのやり方を変えない。詳細設計書を作成したり、単体テストのエビデンスを更新したりしている。なぜか、開発者を投入してパワープレイにでるのは、やったりするのだが、大抵の場合、余計に混乱するだけなのは、ご存知の通りだろう。
監督（プロマネ）の采配のせいなのか？それとも監督やGM（営業か？）の保身のためか？

これとは、逆のケースで、せっかくガチガチのカウンターサッカー（ウォータフォール）でうまくいっているのに、後半４０分で、やらなくてもいい攻撃（仕様変更対応）をやっている場合がある。本当に必要な仕様変更であれば、対応するべきだが、いくら開発チームに余力があるからといって、安直に仕様変更をうけるべきではない。無敵のカテナチオが１点を許し、その後、だだくずれという試合はよくあることだ。

アジャイルでは、高い技術力を武器に、設計、実装、テスト、リリースのサイクルを早くこなす。高レベルの実装技術が必要だが、設計技術と何より高度なマネージメント技術が必要となる。サッカーに例えるならば、ボールを扱う技術だけでなく、高度な戦術眼が全員にもとめられる。どこにフリーの選手がいるのか？相手の弱点はどこなのか？そういったことが、チームとして統一されている必要がある。サッカーでは、そういったことができていることを「感じている」という。「感じている選手」は、チームが今、何を狙っているのかがわかっている選手のことである。「感じていない選手」は、変な所にパスを出してしまい、試合の流れを止めてしまうことが多々ある。素早いボール回しを行うスペイン代表やバルセロナなどは、まさにアジャイルなチームではないだろうか。アジャイルなチームは、一目見ただけでわかる。みんなが楽しそうにサッカーをやるからだ。
システムを開発することも、本来ものすごく楽しいことではないだろうか？
そもそも仮想敵を顧客と仮定したが、本当の敵とは、楽しいシステム開発をできなくしてしまう何かではないだろうか？