厳密なプロセスによって守られるもの

ASDに限らず、アジャイル開発方法論では、一般に細かい作業のすすめ方は開発者がお互いに相談して決めることになっています。
ここも重量級方法論の立場の人達から批判の的となるポイントです。
彼らの典型的な意見は以下のようなものになるのではないでしょうか。

「なるほど、厳密なプロセスではケース・バイ・ケースの判断が必要となる複雑な状況に対応できない、というのは分かる。
しかし、複雑な状況に対して適切な判断を下すには高いスキルが必要とされるのではないか?現実のプロジェクトではそんなに優秀な開発者ばかり集められるものではない。それに優秀な開発者ほど単価も高い。
そのような状況でも会社として案件を受注している以上、ある程度の品質を保証する必要がある。実証済の厳密なプロセスに従っていれば、状況によって多少現実とそぐわなくなる部分が出て来るかもしれないが、最低限の品質は守られる。そのことが重要だ。」

この主張に対する反論を試みてみることにします。

細かく定義された成果物とワークフローは、形式知に過ぎません。それらの意義を本当に活かすには、開発者がどうしてそのような成果物が必要なのか、成果物を作成するためにそのような手順でなければならないのかを内側から理解している必要があります。

しかしそれにはスキルが必要です。

プロセスには従っているけれど内容はボロボロな設計書など、僕はいくらでもみたことがあります。

厳密なプロセスによってスキルの低い開発者でもある程度の品質のものをつくることができるという前提が間違っているのです。

そもそも品質とはユーザに納品される価値ですが、その価値の内容自体複数の要素が絡み合って状況に応じて変わる複雑な物です。
例えばバグ。もちろんバグは品質に関する重要な指標で、少ないに越したことはありませんが、開発のスピードや機能の豊富さ、価格もまた品質を構成する重要な要素です。
これらの品質を構成する要素の間にはトレードオフがあって、開発のスピードを上げようとすれば、バグは増えるし、機能も削らなくてはなりません。
そして開発のスピード、バグ、機能、価格の間の最適なバランスは作ろうとしているソフトウェアによって異なります。
例えば、原発の制御系のシステムであれば少しくらい納期が遅れてもバグが一つもないものが望ましいでしょうが、次期Windowsのリリースが2010年で価格が1CPUあたり50万円だったら嬉しいでしょうか?

実際には厳密なプロセスはマネージャが自分で責任をとらないための言い訳として機能していると思われます。
マネージャは自分で重要な判断を下したり、開発者に委ねるかわりにプロセスに従うことで次のような言い訳ができるようになります。

「確かに今回のプロジェクトはうまく行きませんでした。でも私は標準化されたプロセスに従っていました。だから私は悪くありません...」

結局のところ、厳密なプロセスが守るのは品質ではなくマネージャの心の平和なのです。

実際にアジャイル開発手法導入を説得する際にこれをいってしまうと感情的反発をくらってうまく行かないような気がするのが悩みどころです。