ソフトウエアエンジニアリングの信念が初めて提出されたNATOの"ソフトウエアエンジニアリング会議"が40周年を迎え、Tom DeMarco氏はこの信念の進化を振り返った。氏は初期のソフトウエアエンジニアリングをマトリックス重視に方向づけた立役者だが、自身が果たした役割についても言及している。あらゆる箇所で引用された"計測できないものは制御できない"という格言の作者である氏は、今この方向は実際の開発の妨げになっていたのではないかと、考えている。実際の開発とは"より重要なゴールは変化を起こすこと、会社や、会社の事業、または世界をを変えるソフトウエアを作ること。"だ。IEEEソフトウエア誌の7月/8月号の"ソフトウエアエンジニアリング: 時代はやって来て、そして過ぎ去ってしまったのか" [pdf]と題された記事で、氏は結論を出している。
この記事で、DeMarco氏は"ソフトウエアエンジニアリング"を次のように定義している。
この言葉は、プロセスの定義、インスペクションやウォークスルー、要求開発、トレーサビリティ・マトリックス、マトリックス、正確な品質管理、厳格な計画と追跡、コーディングやドキュメント標準など多くの規則を包含します。これらの原則はすべて、実践と予測に一貫性が生まれることを追求します。
--Tom DeMarco
ひょっとしたらアジャイル主義者にとって、DeMarco氏は1987年に書かれたTim Lister氏との共著であり、ソフトウエア開発の人間的側面に着目したピープルウエアの著者として、知られているのかもしれない。しかし、どのくらい多く人が1982年に出版された"Controlling Software Projects: Management, Measurement, and Estimation"から受けた影響を自覚しているだろうか。DeMarco氏は、記事をこの本を振り返ることから始めている。
振り返って考えてみるに、私が疑っているのは、
答えはこうだ。ノー、ノー、そして、ノー。
- この本に書かれたアドバイスは、当時は正しかったのか。
- そして、今日的な意義もあるのか。さらに、
- 私は今でも、ソフトウエア開発を成功に導くための努力にはマトリックスが必要だと考えているか。
--Tom DeMarco
この本を振り返って、氏はより真実に近づいているが、一方で、ソフトウエアエンジニアリングの規則は、物理のような自然科学の法則とは作用のし方が異なるということにも注意している。"ソフトウエア開発の... マトリックスについては ... 割り引いて考える必要がある。" 氏は価値提供の概念とこの本を関連づけて考え続けた結果、今や次のように考えるようになった。:
"... 制御することに着目すればするほど、相対的に小さな価値を提供するプロジェクトで一生懸命働いているような気がする。 私としては、ソフトウエア開発プロジェクトを制御する方法よりも大きな問題は、一体なぜプロジェクトの多くが、とるに足らない価値しか生み出せないのか、ということだ。
--Tom DeMarco [強調は引用者]
記事の結びに、氏は率直により安定した漸進的なマネジメント方法を提案している。これはアジャイル開発チームやその顧客になじむ方法だ。
制御のない、あるいは相対的に制御されていないプロジェクトでも問題ない、と言ってしまっても許されるだろうか。私が今提案しているのは、まずは正確な制御があまり重要でないプロジェクトを選択する必要がある、ということだ。そして、正確にプロジェクトを制御可能にしようとする度合いに対する期待値を下げなければならない。たとえ実際にはどんなに一生懸命制御しようとしても、だ。
--Tom DeMarco