スクラム導入で開発を取り巻く矛盾はなくなるのか？

皆さんの現場では、矛盾を抱えながら開発を進めてはいないでしょうか？
自分たち以外の誰かが決めた、スコープ、期限、コストを守るために、「絶対無理！」と
いいながら毎日残業している方もいるのではないかと思います。
ウォータフォールプロセスは、このような矛盾を含んだ開発の代名詞のように語られる
こともありますし、その対極の存在としてスクラムなどのアジャイルが語られることが
多いように思います。
私は、開発の矛盾は開発プロセスそのものには直接依存していないと考えています。
アジャイルも開発の矛盾を解消することを目的としているわけではありません。
しかし、組織の構造と開発プロセスの組み合わせが影響する場合はあるのではないかと考えています。
ヒエラルキーを持った組織とウォータフォールプロセスの組み合わせにおいては、
スコープ、期限、コストなどのコミットメントを上位に対して守らなければならない
プレッシャーが大きくなります。それゆえに、階層構造の中で上からのプレッシャーを
そのまま下に流してしまうケースが多いと感じています。
この場合、開発の矛盾は、設計、プログラミング、テストを実施する担当者のところまでほぼそのまま落ちてくることになります。こうなると、もう自分よりも階層構造が下の人がいなくなるので、その矛盾を「プロダクト」に吸収させるしかなくなってしまいます。つまり、突貫でプログラムを書いたり、十分テストができなかったりということが発生します。もちろん、プロダクトに吸収させるにも限度があるため、あまりに大きい矛盾がある場合には大きな問題になって、スコープ、工程、コストが見直されるでしょう。しかし、その見直しまでには、長い時間がかかることが多く、その間に質の悪いプロダクトを作り続けてしまいます。

では、スクラムを導入すると、この矛盾はなくなるのでしょうか？
スクラムでは、プロダクトバックログで要求に対して重複しない優先順位を付けて、それをチームの実績に基づいたベロシティでイテレーションの固定期間に実施可能なものがスコープとして設定されます。このベロシティですら、予測の道具であって、不測の事態などにより思ったり時間がかかるようなケースは、そのことを受け止めて、スコープを調整します。つまり、期限を守るために突貫で作業を実施して品質を落とすということは許されておらず、プロジェクトで目指すべき品質をきっちりと維持しつづける必要があります。そういう意味で、スクラムは「プロダクト」に矛盾を吸収させないフレームワークとも言えると思います。こう書くと確かに、スクラムは開発の矛盾を解消しているように思います。実際には、スクラムとスクラムの外の境界線付近に今までの矛盾が移動します。場合によっては、今までの組織の論理とスクラムが境界線で激しくぶつかる場合があると思います。「スクラムマスターはクビになって一人前」とRyuzeeさんがスクラムと組織についての講演でおっしゃっていましたが、そのくらいの覚悟で組織とぶつからないといけない場合もあると思います。
（もちろん、アジャイルのもつフィードバックループがうまく機能して矛盾自体が解消可能なほどに軽減して開発がうまくいくというケースは多いと思います。）

「プロダクト」に矛盾を吸収させないこと自体は、開発プロセスとは直接関係がないのでウォータフォールでも実行可能だと考えています。実際にうまくできている組織も多くあると思います。スクラムを導入するよりも、他の手段で矛盾を軽減、解消する方が向いている場合もあると思います。
もし、皆さんが開発の矛盾を解消する目的でスクラムを導入したいのであれば、その矛盾はスクラムで解消されずスクラムの境界線上に移動するということを頭に入れておいてください。スクラム境界線上の矛盾を軽減、解消するにはスクラム以外のスキル（根回しや調整能力含め）も必要になってくるでしょう。