変幻する実行可能知識 18パターン II - 生きたプロセス前回はアレグザンダーのパターン本の中から「時を超えた建設の道」を読んだ. 続く「パタン・ランゲージ」は, 「時を超えた建設の道」を具体的に建物のパターン・ランゲージに応用したパターン集で, ソフトウェアには直接関係しないので, 今回は触れない (が, これはこれで大変面白い. 自分で自宅なりオフィスなりを作るようなことがあれば, といろいろ考えさせられる). 今回読むのは「パタンランゲージによる住宅の建設」である. 本書はシリーズの他の巻に較べると, よりプロセスに重点が置かれている. 本書は1975年から, メキシコ・メキシカリ市でバハ・カリフォルニア州政府のプロジェクトとして, 30戸の住宅の設計施工を行った時の記録である. そこでは次の七つの原則が用いられた. それぞれの後ろにその原則の意味を我々の言葉で簡単に言い換えてまとめてある.
これを見てExtreme ProgrammingのプラクティスやScrumのパターン言語を思い起こす人もいるだろう. たぶんその通り, この七つの原則はアジャイル・プロセスのプラクティスにも大きな影響を与えている. ただし, これは建築のプロジェクトであって, ソフトウェアのプロジェクトではない. 特にこれは住宅の建設であって, このプロジェクトの場合には住む人々自身が設計施工の過程に直接的に関わったものである. そんなソフトウェアから遠く離れた (と思える) モノ作りの, それも30年前の一事例の原則を, 今の我々の仕事に当てはめていいものだろうか? そんなことに意味はあるのだろうか? 例えば今あなたが150人規模の某社のオフコン･リプレースに伴う, 基幹システム開発を始めるところだとしよう. まぁ十中八九こういう光景が繰り広げられるのではないかと思う. 実際にシステムを使うユーザは, 最初はしつこくインタビューされるけど, その後はシステム移行のトレーニングが始まるまで放っておかれる. その間, 開発チームが話をするのはよくてユーザ企業のシステム部門担当者か, 下手すれば間に入っているSIerだけ. システムはアーキテクトがばりばりに設計してくれ, PMP資格を持ったプロジェクト･マネージャがばりばりに見積もりとプロジェクト計画を立ててくれる. その設計を見積もり通り, 計画通りに実装するのは, このユーザ企業のことなどほとんど知らない, 下請けか派遣プログラマか, もしかしたら中国やインドの誰か. 重要なのは設計通りに実装し, 計画通りに進捗させること. できあがったモノを日々使うことになるユーザは, 毎日生き生きと仕事をすることができるだろうか? 今までの経験から言って, それはかなり怪しいと思う. ここで言っているのは表面的なユーザビリティのことだけではない. もっと深い何か, でもユーザには誰でも分かっている何かのことだ. これは基幹システムであって, 住宅じゃないから仕方がないというかもしれない. しかし住宅だってこんな作られ方をすることが当たり前というわけではないのだ. アレグザンダーは言う. 「今日あるような狭い建築の見方に固執してしまい, 新しい生産プロセスが今こそ生み出されるべきでありその可能性があるということも理解せずにいるのかもしれません」(p.12) 「現在私たちが使っている生産システムでは, 物事をじっくりと適正なものにすることが難しいようなコントロール形式ができあがっているのです. というのは, ほとんど例外なく決定は誤ったところ, つまりそれが影響を与える直接具体的な場所とは離れたレベルでなされるからです」(p.37) 実はシステム開発でも「ユーザ参加」というキーワードは語られてきている. 本書とほぼ同時期 (1970年代) から北欧を中心として協調型設計 (Cooperative Design), その後北米にわたり参加型設計 (Participatory Design), ユーザ中心型設計 (User-Centered Design) などが提唱されている. JAD (Joint Application Development) という開発手法 (注1) もある. JADは後にRAD (Rapid Application Development) やアジャイル･プロセスの一つである適応型ソフトウェア開発 (注2) などへとつながっていく. 注1: "Joint Application Development", Wood, et.al, Wiley, 1995 注2: 「適応型ソフトウェア開発 - 変化とスピードに挑むプロジェクトマネージメント」, ジム・ハイスミス, 翔泳社, 2003 まず, ユーザ企業の情報システム部門の人たちに前面から退いてもらうことは可能だろうか? ユーザの想いを最初に歪めるのはまず彼らだから. ユーザに毎日一定時間, システム開発に参加してもらうことはできるだろうか? ユーザにシステムのことなんか分かりっこないという心配はあまりしなくてもいいような気がする. 彼らは既存システムに足りないところをExcelやら, Webやら, 人の頭やらを使って (我々よりずっと) 賢く解決しているコトがよくあるのだから. 練り込まれたデータベース・スキーマやガント･チャートなしで開発を始めることができるだろうか? なおかつ予算の範囲内で, 本当のユーザが使えるもの, これから10年, 20年と使い続けられるものができるだろうか? 別にシステムを一度に全部作り直す必要はないのかもしれない. まずある部署の一つの機能を実現してみるのに, それほど大それたプロジェクトや億単位の資金はなくてもいいだろう. 最後にアレグザンダーがこのメキシコでのプロジェクトでとった興味深いやり方をひとつ紹介しておこう. 普通, 建物を建てるのには建築基準法に則った認可を得る必要がある. もちろん認可を得るためには図面の作成などに多くの時間とコストが必要で, なおかつエンド･ユーザ (つまりその家に住む人) ではなく専門家が必要になる. 一度認可を得たら, その設計を現場で変更するわけにはいかない. それらの過程で多くのユーザの想いがうやむやになっていく. しかしアレグザンダーは図面を一枚も描かなかった. 彼は自治体と交渉して, 認可を個々の建物の設計に対してではなく, 建築の「プロセス」に対して得られるようにしたのである. つまり (最低限の条件を除けば) 結果としてどんな建物ができようが, それが前もって提出した, きちんとした作業手順に従って建設されてさえいればいいのである. これは我々にとっても非常に参考になるのではないだろうか. ソフトウェア開発では｢何を作るか」を基準にしたスコープ･ベースの開発契約が大きな問題を起こしている. アジャイル･プロセスでは時間枠を基準にした契約を推奨するけれども, それは発注者/受注者間の信頼関係に依存したものになりがちで, なかなか社会的に受け入れられていない. しかし, ユーザ参加とプロセスを基準にした契約は双方にとって利益のある契約形態になる可能性があると思われる. |