建築文化 2004年2月号「言葉の道具箱」特集
本江正茂（もとえまさしげ）
revised 2004.3.8
2004.1.5
Agile。アジャイル。「機敏な」とか「俊敏な」とか「はしこい」という意味の英語の形容詞である。ただし、逃げる野うさぎのように、無我夢中で一目散というのではなく、ゴールへ向かうマイケル・ジョーダンのように、刻々と変化する状況を見極め冷静に判断して迅速にとるべき行動をとる、そのめくるめく早さをさして"agile"と呼ぶようである。
さて今日、「アジャイル」という語が一番注目されているのは、ソフトウェア開発の分野である。
ソフトウェア開発の分野は、ゴールのめどが立たないまま泥縄の変更作業が延々と続いてしまう、いわゆる「死の行進」で知られている。その辛さは建築設計の分野とよく似ていて想像に難くない。もちろんこれではいけないと誰もが思う。もとより明晰な論理を愛する人々からなるソフトウェア開発のコミュニティにおいては常に、より効率的な開発プロセスを確立するための様々な開発方法論が提唱されてきた。方法論はとかく形式的になりがちなきらいがあり、入念な計画と契約にもとづき十分な文書を作成しつつ厳密な手順で開発プロセスを管理しようとする方法論が多くあったのだが、今日ではむしろ、こうした伝統的なヘビーな方法論と、もう一方の極である方法論ゼロの野放図な状態との間で、ちょうどいいライトな方法論として、アジャイルな開発方法論が注目されているのである。
具体的には、XP(eXtreme Programing)や、Scrum、Agile Modeling、ASD(Adaptive Software Development)などいろいろある。これらの方法論の提唱者らが、2001年に「アジャイル・アライアンス」を結成し、それぞれの方法論に共通する理念を整理したマニフェストを発表しているので、これを紹介したい。このマニフェストの面白いのは、いろいろあるだろうがなんにせよ俺たちにとって大事なのはこれだ、とまず価値観を表明をしている点だ。
アジャイルなソフトウェア開発のためのマニフェスト
我々は自ら実践し、またそうしようとする他の人々を支援することを通じて、ソフトウェア開発のより良き方法を見いだそうとしている。
この活動を通じて我々は：
個人とその相互関係を、プロセスやツールよりも
動くソフトウェアを、包括的なドキュメントよりも
顧客とのコラボレーションを、契約交渉よりも
変化に対応することを、計画に従うことよりも
価値あるものと考えるに至った。これは、右側の項目の価値を認めながらも、左側の項目の価値をより重視するということである。
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
(c)2001 上記の著者たち
この宣言は、この注意書きを含めた全文である限りにおいて、どのような形でも自由に複製してよい。※引用者訳。原文はhttp://agilemanifesto.org/
ソフトウェア開発のプロセスを説明するために、伝統的なエンジニアリングのプロセスとの比較がなされる場合がよくある。なかでも建築のプロセスはイメージしやすいのだろうか、よく比較対象にあげられている。
たとえばソフトウェア開発の設計書の共通仕様の確立をめざすUML(Unified Modeling Language)は、設計段階から施行の現場におけるまで一貫した標準的な仕様の建築設計図書が使われていることが、建築工事をスムースに進めるうえで非常に大きな役割を果たしていることを例にあげて説明されることが多い。UMLはデザイナーもクライアントも職人もみな共通して理解できる建築図面のようなものなのです、というわけだ。
だが、このように伝統的なエンジニアリングとソフトウェア開発を安易に同列で比較してしまう態度には批判もある。たとえば、アジャイル・アライアンスのマニフェストにも名を連ねるマーチン・フォウラーは、建築のように「設計」と「施工」を分離し、ソフトの仕様決定が「設計」で、プログラムそのもの書いていくコーディングの過程は「施工」にあたると考えるのはおかしい、むしろ書かれたコードそのものが設計書であり、（コンピュータが自動的に実行する）コンパイラーとリンカーを動かしている時間だけが「施工」なのではないか、ソフトウェア開発では「施工」の工程は無視できるほど小さく、だとすればソフトウェア開発はすべてが「設計」なのではないか、という。【注1】
フォウラーの議論は理解できる。だが、建築業界の端くれとしては、建築だってそんなにシンプルじゃないぞと反論したい気持ちになる。 もちろんソフトウェア開発における「設計」後の製造プロセスほどには小さくはないのは確かだとしても，（文脈上の要請とはいえ）建築の「施工」のプロセスが過大評価されているように思われるのである。【注2】
設計が終わり、施工が終わり、引き渡しをもって建築開発プロセスが終了する、と素朴に考えることのできた時代ではなくなっている。長いライフサイクルの中で、建築は常にその用途を見直され、使われ方を変え続ける。建築は繰り返し、その使われ方がデザインされなおされなければならない。
だから、建築の分野におけるアジャイルな方法論の可能性について考える時、それをクライアントの気まぐれに対応しつつ、手戻りなく短期で設計を終了するための方法論である、などというような矮小化されたビジョンを持つのでは不十分だろう。ソフトウェア開発において、「設計」後の製造プロセス[注3]がごく限られたものであるというのと同様に、運用のライフサイクル全体で考えれば、時間においてもコストにおいても、「施工」は必ずしも圧倒的に支配的なものとはいえないからだ。
建築の開発は、いかにも大きく重く、総身に知恵の回りかねる難しさがある。しかし、だからこそ企画・設計から運用へと永続していくプロセスにおいて、その身のこなしを十分に軽くし、アジャイルに振る舞う方法を身につけ実行していくことができるようになることで、顧客に対しても、自身に対しても、社会的責任を果たす上でも、よりよい結果を得られるのではないか。
注1：Martin Fowler, The New Methodology, http://www.martinfowler.com/articles/newMethodology.html
注3：当初発表原稿では「コーディング」となっていたが，フォウラーの議論で建築の「施工」と対置されているのは「コーディング」ではないので，このように訂正。
注2,3の訂正は，宇野信太郎さんのご指摘によります。記して感謝いたします。
revised 2004.3.8