（訳）

前回シカゴを訪れた時、John BrackenおよびFitzことGoogleのBrian Fitzpatrickが、マッカーサー財団、Googleおよび政府関係者何人かを含む様々なコミュニティの人々を集め、会議を開催した。

その会議で僕は、アジャイルソフトウェア開発やRuby on Railsといった比較的新しいソフトウェア開発の慣習や枠組という文脈で、革新について考えをいろいろと述べた。Reid Hoffmanがよく言っているように、「製品の初回リリースを恥に思っていないようじゃ、リリースが遅すぎだ」ということだ。Linuxの早めかつこまめなリリースという思潮と、Ruby on Railsや他の言語、枠組を使って一週間でこなせる「本当の仕事」の量を組み合わせると、初期段階の消費者インターネット投資の様相がまるで変わってくる。

一般的には、プレゼン用のデッキよりも、プロトタイプを作るほうがおそらく安上がりで早く、効率的だ。マーケティングや推測を重ねるよりも、実際のユーザーに何かをテストしてもらうほうがおそらく簡単だろう。アイディアを持っている人のほぼ誰にでも僕がおすすめしているのは、とにかくモノを作ってしまって、ユーザーがある程度食いついてくるまで実装を続け、その食いつきを元にエンジェル・インベスターに売り込みをかけるということだ。これはIETF（Internet Engineering Task Force）の古くからのモットー「大まかなコンセンサスに、実行可能なコード」に則したやり方だ。

アジャイル開発では、短いサイクルでの実装に注力し、ユーザーからの反応が以後の実装に常にフィードバックされていく。

アジャイル開発の対極にあるのは、何をやるかを長時間かけて決め、問題を事前に予測し、提案依頼書を書き、プロジェクト完了まで請負業者と作業をし、デバッグをし、そしてメンテナンスを行うという流れだ。

その場合の問題は、現実世界では事情が変化するため、この流れが終わる頃にはだいぶ見当が外れてしまっていたり、そもそも最初のバージョンが適切でなかったりするので、結果的に2年遅れで100項目の的外れな仕様を盛り込んだようなモノができてしまうわけだ。アジャイルソフトウェア開発ではユーザーと共にテストし、進化し、共鳴しつつ導いてもらうことになる。各々の「階層」ないし要素がより小規模で、テスト済みであり、簡単に単離して除去／変更可能である（はずな）ので、総じてテストとリファクタリングが容易になる。

僕にとって非常に興味深かったのが、この話し合いに対する政府関係参加者の注目ぶりだった。ある会議での誰かのコメント（面目ないが誰だったかは失念してしまった）を思い出した。大規模のソフトウェア開発や政府の政策では、要素を追加する（法律に項目を追加するようロビイングする）ことのほうが、要素を削除するよりも簡単だ、という趣旨だった。誰もが、追加したいと思っているお気に入りの要素を抱えている。そして法律やコードにいったん組み込んでしまうと、要素や複雑性を除去しようとする動機はとても弱くなってしまう。結果として、Windowsや最近の一部の携帯電話、多くの政府政策がそうであるように、巨大で、普通の人々が理解するには複雑すぎて、当初の目的さえもそんなにうまくは果たさない、お荷物的なブロートウェアができてしまうのだ。ブロートウェアは、そもそもの存在意義を見失い、運営側のエネルギーのほとんどをプロセスそのもので吸い尽くしてしまう。単位を小さくしてちゃんとしたテストの仕組み（オブジェクトレベルでのアカウンタビリティ）をもち、アジャイル開発を行うことで、ブロートウェアができてしまう要因をいくつか緩和できるはずだと僕は考えている。

また、あらゆる声に耳を貸してから巨大なプロジェクトに着手するのではなく、政府政策を固定してしまわずに要素単位で実施するというアプローチは、適切な構造および統制がとられている状況でこそ効果を発揮するのだと思う。アジャイル開発者がこれまで見つけ出したものの中には、政策や他の取り組みを考える際に参考になりそうな事項が多数あるように思える。

１）エクストリーム・プログラミング：2人組で同じ画面で作業をし、互いにチェックをしつつ、相手の生産性や種々の技を学んでいく。実装段階ごとにパートナーを交代していく。とても効果的なノウハウ共有手段だ。

２）テストの仕組み：あらゆる面で不具合が出るだろうという前提に立つ。自分がビルドしたものが不具合を出した時に、周囲の他のオブジェクトにどのように影響するかをテストする。何かが不具合を出した時に確実にそのことに気づき、原因が特定できるようにする。人的、ネットワーク的、金銭的、コンピューター的な不具合に対し堅牢なシステムを構築し、バックアップ用のシステムも構築する。テストの仕組みはシステムに変更を加えた時に何が壊れるかを特定する一助にもなり、後で何かを変更、除去、リファクタリングしたい時に役立つ。

３）小規模で実施：チームの人数を増やしすぎず、大きな問題は小さな問題に分割する。小さな問題はごく少人数のグループでもこなせるような「階層」もしくは短期間のタスクに分割する。

４）提案書、仕様書、提案依頼書はなし：タスクの把握にはPivotal Trackerのようなトラッキングシステムを使う。巨大なプロジェクトシートや、開始前に全てを決定しようとするのは避ける。各小規模グループがその領分内でコンテキストを共有すること、そして個々の小パートが正しく動作し、周囲の要素に悪影響を及ぼさないことのほうが重要である。

非直観的に思えるかもしれないけれど、多数の小グループに自らの堅牢さ、迅速性、そして相対的な自立性をもたせることに集中させたほうが、上層での決定がより容易になり、本来の目標に集中することができると僕は考えている。マイクロマネージメントは巨大で非効率だ。各小グループはシステムへの入力と、「ユーザー」からのフィードバックを提供する。区分けされていない小グループはシステム全体を、より柔軟かつ「アジャイル」（身軽）なものとし、変更の際も何も壊さない素早い適用を可能にし、構造よりもコンテキストに注力できる。

この分野に関する僕の考えの大部分は、新生銀行のJay Dvivediとそのチームを見てきたことと、Pivotal Labsの皆さんと少し仕事をしたことに端を発している。ここまでこんなに長文のブログ投稿を書いてきたわけだけど、僕はまだアジャイルソフトウェア開発の世界にはわりと新参ではあるものの、そこで形作られつつある慣習のいくつかは、政府の政策展開のみならず、様々な他分野に適用できるのではないかと考えている。