アジャイルの各種手法が持つ問題と根本的な解決について論じている"agile journal"の記事の要約と、それに対するコメント。
要約
理論駆動開発：アジャイルの未来
YDD: The Future of Agile
既存の「XX駆動開発」がソフトウェア開発を狭く見すぎて、本質をとらえられていない点を指摘し、ソフトウェアの「本質的な困難さ」を扱う「理論駆動開発( theorY Driven Development - YDD)」を提唱する。
"D"の過剰
TDD, DDD, MDD, RDD, LDD, FDD, PDD, SDDなど、「XX駆動開発」ないし、「XX駆動設計」とよばれるものは数多く出てきている。これらはいずれもソフトウェア開発における重要な局面に焦点を当てたものではあるが、Brooksが提示した本質的な難しさに向き合うものではない。Brooksによれば、ソフトウェア開発において最も難しいのは、「概念的な構築物」を扱う部分である。
If agility is to realize its full potential it must incorporate practices and principles that facilitate the development, refinement, and sharing of conceptual constructs.
もし俊敏さがその潜在能力をフルに実現させようとするのならば、概念的な構築物を開発し、洗練し、共有していくためのプラクティスや原則を含まなければならないのです。
YDDはこの問題に対してアジャイルの方法論が対処してきた手法を文脈の中に位置づけるようなフレームワークを提供するものだ。
概念的な構築物＝理論
「ソフトウェアはその規模に反し、これまで人間が構築したものの中で最も複雑だ」とBrooksは主張しているが、このような概念的な構築物を持つことは、メンタルモデルを持つことだ。
To have a conceptual construct of the software you are to build means having a mental "model" of all the interlocking and interacting parts - both the parts in the machine and those in the world-at-large.
開発しようとしているソフトウェアに関する概念的な構築物を持つということは、すべての連結箇所と相関箇所に関するメンタルモデルを持つことなのです。こういった箇所は機械の中にも現実世界の中にもあるものなのですが。
これは簡単なことではないが、我々は文化や宇宙論という領域において、個人においてもグループにおいても概念的な構築物を公式化し共有することに成功している。ソフトウェア開発に関しても、「ソフトウェア開発は理論構築である」とする開発者（Peter Naur）がいる。
理論構築とアジャイル
理論構築（theory building）とは設計（design）のことだ。設計の問題は以下の通り。
- 伝統的にはアップフロントで行われなければならないとされているが、必ずしもそんなことはない。
- 設計にはプログラミング以外の知識も必要とされる。
- ソフトウェア開発はチームで行うものだから、理論をチームで共有する必要がある。
アジャイルには既にこういった問題に対応する手段が準備されている。
- 哲学的な基礎としては、Cockburnが"Agile Software Development"の中でNaurを参照している。
- 概念化（conceptualization）は理論構築であり、それを支えるアジャイル手法がバックログだ。
その他、アジャイルの各種プラクティスも理論構築という観点から説明できる。
The foundations for a theory driven approach to software development are clearly present in agile as it is practiced today. For YDD to become a reality those practices must be rearticulated stressing how they contribute to theory development and how they directly address what Brooks' called "The Essential Difficulty" of software development.
ソフトウェア開発に対する理論駆動アプローチのための基礎は明らかにアジャイル手法の中にあり、そして実践もされています。理論駆動開発が現実のものとなるためには、そのような実践が再び明言されなければいけません。その際に強調されるべきなのは、理論開発においてどう貢献できるかであり、Brooksがソフトウェア開発の「本質的な難しさ」と呼んだものに対してどう向かい合っているのかということです。
理論駆動開発を実現する際の障害
理論駆動開発の観点からすると大きな障害が２つある。
- ほとんどの開発者は、「世界というものは、一つのコンピュータである」という誤った理論に基づいている。
- 世界はそんなに簡単に理解できるものではない。
- ソフトウェア開発というものは、製造工程ではない！
- マネジメントというものはソフトウェア開発を制御しようと欲するものだ。アジャイルのマネジメント手法の目的は２つある。それは、世界に対する理論を構築する際の手助けをすることと、プロセスを支配しているという幻想を与えること。不幸なことに、後者が強調されすぎている。
コメント
フレームワークやミドルウェア、あるいは開発手法がどれほど発展しても最後に残るのは対象自体の難しさであり、それは概念的なものなのだということは、私たちが繰り返し思い知らされる真実だと思います。また、アジャイル手法が必ずしもBrooksの言う「本質的な難しさ」へのソリューションではないという指摘も、いくつかの手法に関して言えばその通りかもしれません。ただ、そういった問題を解決するために、改めて「理論（theory）」という概念を導入し、その視点から各種の手法を統合していくというやり方には若干の疑問が残ります。まず第一に、ここで「理論」という概念で表現しようとしているものが、例えばEvansがDDDの中で詳細に論じていることと、どの程度同じでどの程度違うのかが良く分からないということ。第二に、やはり各種の方法論について考える時にはこの記事のように独自の視点から地図を引き直すのではなく、そもそもその方法論が何を問題とし、どう解決しようとしているのかというコンセプトの部分から丁寧に読み解く必要があるのではないか、ということですね。それ以外にも、文化や宇宙論とソフトウェアを同列に論じてしまうなど、ちょっとナイーブ過ぎたり、あるいは自分の見解に引きつけすぎたりしている箇所は随所に見受けられます。そういったナイーブさがこの「理論」をやや疑わしいものにしている要因の一つになっているのかもしれません。
とはいえ、コメントの最初に書いた通り、著者が大切だと考えていることは間違っていないと言えます。YDDを押し進めるかどうかは別にしても、適用にあたっては形骸化しがちな各種アジャイル手法を学ぶ際の一つの補助線としては、それなりに有効な視点を含んだ記事なのではないかと思います。
※要約にあたって比較的長い記事をかなり短く切り取っています。興味を持たれた方は、ぜひ原文をご参照下さい。
関連書籍
Brooksの名著。１０年以上前の本ですが、この本の指摘は今も変わらず真実であり続けていると思います。
Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition
- 作者: Frederick P. Brooks
- 出版社/メーカー: Addison-Wesley Professional
- 発売日: 1995/08/02
- メディア: ペーパーバック
- 購入: 1人 クリック: 1回
- この商品を含むブログ (8件) を見る
